USGIN U.S. Geoscience Information Network

 

Title:

USGIN Metadata Profile: Use of ISO metadata specifications to describe geoscience information resources

Latest released version:

http://usgin.github.io/usginspecs/USGIN_ISO_Metadata.htm

Creator:

USGIN Standards and Protocols Drafting Team

Editors:

Stephen M. Richard and Wolfgang Grunberg

Creation date:

8/18/2009

Last revision date:

2018-06-25 11:45

Document Status:

Version 1.3 tag

Publisher:

Arizona Geological Survey

Description:

This document describes recommended practices for using ISO19139 xml encoding of ISO 19115 and ISO 19119 metadata to describe a broad spectrum of geoscience resources. The document provides guidance for the population of ISO19139 encoded metadata documents to enable interoperability of catalog service clients with multiple servers conforming to this profile.

Contributor:

See acknowledgements

Document Identifier:

gin2010-009.1.3 http://repository.usgin.org/uri_gin/usgin/dlio/337

Neither the USGIN project, nor any of the participating agencies, take any position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither do they represent that there has been any effort to identify any such rights.

This document and the information contained herein is provided on an "AS IS" basis and USGIN DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 

 

Version	Date	Comments	By
0.1	2009-08-18	Initial draft document	Wolfgang Grunberg
0.7	2009-10-28	Revisions, addition of material, re-title, focus on use of ISO 19139. Revising adding material done, circulate for review, comment. No discussion of serviceIdentification section as yet; this will have to be added, at which point the file title will be revised.	Stephen Richard
0.7.1	2009-11-19	Revisions, crosschecked with ISO 19139 and NAP Profile, added dataset metadata example	Wolfgang Grunberg
0.8	2009-11-24	SMR review, editing based on W. Grunberg comments	Stephen Richard
0.8.1	2009-11-30	Codelist review, approved previous tracked changes	Wolfgang Grunberg
0.9	2009-12-03	Add section on distribution and distributor, review and accept changes	Stephen Richard
0.9.1	2009-12-04	First public release of draft dataset and dataset series profile, Word and PDF file preparation	Wolfgang Grunberg
0.9.3	2009-12-11	Review edits and comments. Split out data identification element into separate tables for MD_DataIdentification and SV_ServiceIdentification; add service metadata elements.	Stephen Richard
1.0.0	2010-01-11	Review dataset and service metadata sections; update metadata examples. Second public release of draft dataset and dataset series profile, Word and PDF file preparation	Wolfgang Grunberg
1.0.1	2010-01-20	Additional examples, codeList overhaul	Wolfgang Grunberg
1.1.0	2010-02-02	Change recommendation for codelist usage to use ISO identifiers; update codelist discussion. Update distribution format discussion. Review and formatting. Public release, Word and PDF file preparation	Stephen Richard, Wolfgang Grunberg
1.1.1	2010-03-04	Review, title page changes	Stephen Richard
1.1.2	2010-03-04	AZGS Contributed Reports release, Word and PDF file preparation	Wolfgang Grunberg
1.1.3	2010-11-16	Minor edits and bug fixes, modify title and title page text.	Wolfgang Grunberg, Stephen Richard
1.1.4	2010-11-18	Correct example document for distribution element conventions, add simple data quality statement, funding acknowledgement, update use case section	Stephen Richard
	2011-12-28	add 'Recommended practices' to title. Update language in distribution section.	Stephen Richard
	2013-06-13	Finish major review and edit of text to bring in alignment with practice that has evolved since 2009. Remove 'Recommended practices' in title, add 'USGIN Metadata Profile'. Remove 'service metadata example, it was too deeply flawed to fix. May add a service metadata example later.	Stephen Richard
1.2	2013-10-08	Create v. 1.2 tag
	2014-01-23	Add hierarchyLevelName string values for use in metadata document in Table 1. Add Cat-Interop link for strings to use for various service-related property values	Stephen Richard
	2016-02-25	Update link to current version, increment version number to 1.3-draft, update copyright date. Update serviceType to use Cat-Interop conventions	Stephen Richard
1.3	2018-06-25	Change convention for metadataStandardName to use GeoNetwork value for name, put USGIN information in metadataStandardVersion. Update contacts.	Stephen Richard

 

Many individuals and organizations have contributed to or inspired the development of these Guidelines.

The USGIN Standards and Protocol Drafting Team include (alphabetically):

Ryan Clark - AZGS
Wolfgang Grunberg -- AZGS
Dominic Owen - AZGS
Stephen M. Richard -- AZGS

Funding Provided by (chronologically):

National Science Foundation under EAR-0753154 to the Arizona Geological Survey acting on behalf of the Association of American State Geologists; 2009.

U.S. Department of Energy under award DE-EE0001120 to Boise State University; 2009.

U.S. Department of Energy under award DE-EE1002850 to the Arizona Geological Survey acting on behalf of the Association of American State Geologists, 2010.

Special Thanks to (alphabetically):

ANZLIC
INSPIRE
MEDIN
NAP
NOAA

Contact Information

U. S. Geoscience Information Network

Steve.richard@usgin.org, smrTucson@gmail.com

Email

metadata@usgin.org

Online

http://usgin.org
http://lab.usgin.org

 

1 Introduction. 8

1.1 Normative References. 8

1.2 Purpose. 9

1.3 Terminology. 9

1.4 ISO Schemas Location. 10

2 Overview of the Profile. 12

2.1 Quick Reference. 12

2.1.1 Non-service resources. 14

2.1.2 Service Resources. 14

2.2 USGIN specification constraints and recommendations. 15

2.3 USGIN specification extensions. 15

2.4 General Objectives. 15

2.5 Requirements. 16

2.6 Use cases to be supported. 16

2.7 Resources of interest 17

3 USGIN Usage of Metadata Elements. 23

3.1 Core spatial dataset, dataset series, and service elements. 23

3.2 Dataset Identification properties (MD_DataIdentification) 40

3.3 Service identification elements (SV_ServiceIdentification) 50

4 Usage notes for Metadata Elements. 63

4.1 Metadata file identifier 63

4.2 Metadata hierarchy. 63

4.3 Metadata Contact vs. Resource Citation vs. Resource Contact 63

4.4 Resource Title. 64

4.5 Resource Abstract 64

4.6 Resource Type. 64

4.7 Resource Locator 65

4.8 Unique Resource Identifier 65

4.9 Browse Graphics. 65

4.10 Resolution and equivalentScale. 66

4.11 Resource Language. 66

4.12 Encoding of Vertical Extents. 66

4.13 Content information: Entities and Attributes. 66

4.14 Use of MD_Distribution and MD_Distributor 67

4.15 Distribution Format 69

4.15.1 Digital resources. 69

4.15.2 Non digital resources. 70

4.16 CI_OnlineResource. 72

4.16.1 CI_OnlineResource protocol 73

4.16.2 CI_OnlineResource applicationProfile. 73

4.16.3 CI_OnlineResource name and description. 73

4.16.4 CI_OnlineResource function property. 74

4.16.5 Scoped name in service distributions. 75

4.17 Responsible parties and logos. 75

4.18 Extensions to CharacterString. 76

4.18.1 Web extensions. 76

4.18.2 Language localization. 76

4.18.3 Codelists. 77

4.19 Geographic bounding box. 84

4.20 Data Quality. 84

4.20.1 Simple quality statement 84

4.21 Lineage. 84

4.22 Temporal extents. 86

4.23 Operation metadata. 87

5 Abbreviations. 88

6 References. 89

6.1 Cited literature. 89

7 Codelists. 90

7.1 ServiceType. 90

7.2 Linkage name conventions. 92

8 Examples. 94

8.1 USGIN ISO 19139 Minimum Dataset Metadata. 94

8.2 USGIN ISO 19139 Dataset Metadata. 102

8.3 ISO19110 Feature Catalog example. 125

Table 1. Summary of resource types described by metadata for US Geoscience Information Network catalogs.. 14

Table 2. Description best practices for ISO19139 metadata elements in USGIN profile.. 18

Table 3. Dataset Identification properties (MD_DataIdentification) 34

Table 4. Service Identification properties (SV_ServiceIdentification) 43

Table 5. Example format strings for digital files.. 61

Table 6. USGIN Distribution formats for non digital resources. 62

Table 7. OnlineFunctionCode values from NAP (INCITS 453) and ESRI Geoportal toolkit v. 3.1.. 63

Table 8. Codelist crosswalk between ISO, NAP and USGIN. 69

Table 9. Usage of data quality scope description elements. 75

Table 10. Inspire spatial data service type 82

Table 11. USGIN service type vocabulary.. 82

Table 12. USGIN Names to identify special linkage URL's for CI_Online Resource. 83

Figure 1. gmd:MD_Distribution_Type diagram.. 60

 

 

1       Introduction

A key component of a distributed information network is a catalog system, a collection of resources that allow data and service providers to register resources, and data consumers to locate and use those resources. Currently, many online catalogs are web pages with collections of URLs for services, or services are discovered accidently or by word of mouth. The vision is to enable a web client (portal) to search across one or more metadata registries without having to configure the client individually for each of the registries that will be searched. Thus, metadata providers can focus on data development, without having to also develop web clients to enable search of that metadata.

The Open Geospatial Consortium (OGC) Catalog Service for the Web (CSW) specification defines a collection of basic operations for searching catalogs of metadata via the web. Engineering the desired interoperability requires adding additional constraints on CSW operation; one of the major constraints is selection of the xml schema that will be used to encode metadata for the service. The core CSW specification requires use of a basic xml schema that includes content defined by the Dublin Core Metadata specification [Dublin Core, 2008-01-14]. This document concerns use of the ISO19115 and ISO19119 content models implemented using the ISO19139 xml schema for encoding of metadata content. Some more specific constraints on use of this implementation may be included in a separate document (USGIN, 2012) describing metadata constraints for different kinds of resources.

1.1 Normative References

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO 19115 designates these two normative references:

             ISO 19115:2005, Geographic information - Metadata

             ISO 19115/Cor.1:2006, Geographic information -- Metadata, Technical Corrigendum

ISO 19119 designates these normative references:

             ISO 19119:2005, Geographic information - Services

             ISO 19119:2005/Amd 1:2008, Extensions of the service metadata model ISO 19108 designates:

             ISO 19108:2005, Geographic information -- Temporal Schema

 

ISO 639-2, Codes for the representation of names of languages - Part 2: Alpha-3 code control ISO 8601, Data elements and interchange formats - Information interchange - Representation of dates and times

ISO/TS 19139:2007, Geographic information - Metadata -- XML Schema Implementation

OGC 07-006r1, OpenGIS Catalog Services Specification version 2.0.2, Corrigendum 2 release, 2007

OGC 07-045, OpenGIS Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile, Version 1.0.0, 2007

INCITS 453-2009, North American Profile of ISO 19115:2003 -- Geographic Information -- Metadata (NAP-Metadata), 2009, American National Standards Institute, Inc.

ISO 10646-1, Information technology ― Universal Multiple-Octet Coded Character Set (UCS) ― Part 1: Architecture and Basic Multilingual Plane

RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, Network Working Group, 1997.

1.2 Purpose

The USGIN uses the ISO 19115/19119 specifications for metadata content, and the ISO 19139 XML schema for encoding this content search results provided by USGIN CSW services. This profile conforms to most of the provisions of the North American Profile of ISO metadata (INCITS 453-2009, referred to as NAP), except it allows multiple distributor-format-transferOptions bindings for resource distribution, and recommends use of ISO19115 codelist values. This USGIN document is meant to provide guidance on the use of the ISO19139 XML schema to encode metadata for geoscience resources, with sufficient detail that application developers can produce software clients that utilize the metadata for automated discovery, evaluation, and utilization workflows. The focus of the profile is to enable interoperable catalog services for discovery, evaluation, and access to information resource of interest to geoscientists.

1.3 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in Internet RFC 2119.

 

Application profile: a schema that consists of data elements drawn from one or more namespaces, combined together by implementers, and optimized for a particular local application. (Rachel Heery and Manjula Patel, 2000, http://www.ariadne.ac.uk/issue25/app-profiles/)

Catalog application: Software that implements a searchable metadata registry. The application must support the ability to register information resources, to search the registered metadata, to support the discovery and binding to registered information resources within an information community.

Codelist (also as Code list): a controlled vocabulary that is used to populate values for an XML element.

Data product specification: a definition of the data schema and value domains for a dataset. The data schema specifies entities (features), properties associated with each entity, the data type used to specify property values, cardinality for property values, and if applicable, other logical constraints that determine data validity. Value domains are specified for simple data types--strings or numbers, and may include controlled vocabularies for terminology required to specify some properties.

Dataset series: collection of datasets sharing the same product specification (ISO 19115). ISO 19115 does not define product specification. For the purposes of USGIN, a product specification defines a data schema, any required controlled vocabularies, and recommended practices for use of schema (see Data product specification).

Dataset: an identifiable collection of data (ISO19115). USGIN extends the concept of data items to include physical artifacts like books, printed maps and diagrams, photographs, and material samples--any identifiable resource of interest. DCMI definition is "Data encoded in a defined structure" with additional comment "Examples include lists, tables, and databases. A dataset may be useful for direct machine processing." A digital dataset is a collection of data items in which individual data items are identified and accessible. Metadata for the collection is a different type than metadata for individual items in the collection (dataset vs. features). Criteria for what unifies the collection are variable (topic, area, author...). Data items may represent intellectual content -- information content and organization (data schema) -- or may represent particular manifestations (formats) of an intellectual artifact.

Interoperability: "The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units." ISO/IEC 2382-01 (SC36 Secretariat, 2003)

Metadata element: a discrete unit of metadata (ISO 19115), an attribute of a metadata entity. A metadata element contains some content specifying the value of the element; this content may be simple--a number or string, or may be another metadata entity.

Metadata entity: a named set of metadata elements describing some aspect of a resource.

Metadata register: an information store that contains a collection of registered metadata records, maintained by a metadata registry. (ISO 11179)

Metadata registry: an information system for assignment of unambiguous identifiers to administered metadata records. (ISO 11179)

Metadata section: Part of a metadata document consisting of a collection of related metadata entities and metadata elements (ISO 191115).

Metadata: data about a resource in some context. Generalize from ISO 11179 definition of metadata, which constrains the scope to data about data. For USGIN purposes, metadata may describe any resource--including electronic, intellectual, and physical artifacts. Metadata specify characteristics that can be queried and presented for evaluation and further processing by both humans and software.

Profile: set of one or more base standards and - where applicable - the identification of chosen clauses, classes, subsets, options and parameters of those base standards that are necessary for accomplishing a particular function [ISO 19101, ISO 19106]

Resource: An identifiable thing that fulfills a requirement. Usage here is closer to definition used in RDF (www.w3.org/TR/REC-rdf-syntax), generalized from ISO19115, which defines resource as an 'asset or means that fulfills a requirement' without defining asset or means. "An object or artifact that is described by a record in the information model of a catalogue" (OGC 07-006r1)

Service metadata: metadata describing the operations and information available from a server.

Source Specification: The specification or standard that is the subject of a profile.

User Community: A group of agents who decide to make a similar usage of a source specification in order to be able to interoperate.

 

Note that throughout this document, the names of XML elements are shown in this typecase. Long X-paths have been broken with non-breaking hyphen characters. Note that hyphens are not used in any XML attribute or element name, so if they appear in the text, they are strictly for better text wrapping. In Xpath expressions /../ indicates that some elements have been omitted from the path.

1.4 ISO Schemas Location

ISO I9139 xml schemas are hosted by the International Organization for Standardization (ISO) at http://standards.iso.org/ittf/PubliclyAvailable-Standards/ISO_19139_Schemas/gmd/. The ISO Technical Committee 211 (TC211) also hosts the schemas at http://www.isotc211.org/2005/gmd/. These schema implement ISO Technical Specification 19139:2007 (dated 2007 Apr 17), which appears to include the changes from ISO 19115:2003 Cor 1;2006(E), but do not include any of the service metadata content.

The Open Geospatial Consortium (OGC) hosts a copy of the schemas in an online repository at http://schemas.opengis.net/iso/19139/. In the OGC repository, two versions are posted: 20060504 and 20070417. Unfortunately, these two directories both contain schema with the same target namespace, so there is no clear way to distinguish applications that are based on one or the other. The medatadaEntity.xsd in the two directories is identical; other schema have not been compared (but see discussion paper gin2009-005 at http://lab.usgin.org/node/269 ). The 20070417 directory contains schema implementing ISO Technical Specification 19139:2007 (dated 2007 Apr 17), apparently identical to that in the ISO repositories, but this is not declared in any included documentation (need metadata on the metadata schema!).

The 20070417 version of the ISO 19139 schemas references GML 3.2.1. However, there is no mention of the SRV namespace (http://www.isotc211.org/2005/srv) in this schema. The SRV namespace is required to specify information about dynamic, online services such as WFS and WMS, so the 20070417 version is not useful for metadata catalogs that register services.

In order to create metadata for both static datasets and dynamic, online services and for use with CSW, the OGC created an xml schema that merges the schema for ISO19115 (dataset metadata) and ISO19119 (service metadata) (see section D.1.5, page 105 in OGC 07-045). The way that was accomplished was by creating a schema located at http://schemas.opengis.net/csw/2.0.2/profiles/apiso/1.0.0/apiso.xsd. The original version of this schema (2007) imported .. iso/19139/20060504/gmd/gmd.xsd and .. iso/19139/20060504/srv/srv.xsd.

 

Update 2018: The current version (updated 2018-03-01, version 1.0.1 in the xs:schema root element, but file name is still 1.0.0) imports the gmd namespace from http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd and srv namespace from http://schemas.opengis.net/iso/19139/20070417/srv/1.0/srv.xsd  thus using gml 3.2.  The apiso.xsd schema should be used for documents intended for application in CSW services.

2.1 Quick Reference

This section provides a summary of the rules for an ISO 19139 XML document to be considered a valid USGIN metadata record

1. MD_Metadata/fileIdentifier/gco:CharacterString must be present, and may be interpreted by client applications as a string that is unique to each particular metadata record in the scope of the catalog from which it was obtained. This is typically a UUID autogenerated by the metadata editing tool or import process
2. MD_Metadata/language/gco:CharacterString will be assumed to be 'eng' (English) unless another value is specified. Any characters after the first three letters in this character string may be ignored by client applications.
3. Unless otherwise specified, the character set element will be assumed to be:

<gmd:characterSet>

<gmd:MD_CharacterSetCode codeListValue="utf8">UTF-8</gmd:MD_CharacterSetCode> </gmd:characterSet>

 

4.  Unless otherwise specified MD_Metadata/hierarchyLevel/MD_ScopeCode will be assumed to be:

<gmd:hierarchyLevel>

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

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

</gmd:hierarchyLevel>

 

Metadata with scope code values that are not in the set {collectionHardware, collectionSession, dataset, series, nonGeographicDataset, dimensionGroup, fieldSession, software, service, model, tile} will be considered out of scope and may be ignored by a harvesting catalog.

5.    MD_Metadata/hierarchyLevelName/gco:CharacterString is mandatory to identify the USGIN resource type from Table 1 (above). Default value is "Dataset". Encode hierarchy by including hierarchyLevelName elements for all broader resource categories. E.g. default should also include a hierarchyLevelName="Collection" element.

 

6.    USGIN requires at least one MD_Metadata/contact/CI_ResponsibleParty with role.CI_RoleCode@codeListValue = "originator" or "pointOfContact" that should identify the original source of the metadata record. The CI_ResponsibleParty element must include a contact e-mail address (electronicMailAddress) or telephone number (voiceTelephone), and one of individualName, organisationName, or positionName must be present.

7.    USGIN profile requires a MD_Metadata/dateStamp/gco:DateTime (Note this contrasts with INSPIRE mandate to use dateStamp/gco:Date) that specifies the date and time when the metadata record was created or last updated.

8. MD_Metadata/metadataStandardName/gco:CharacterString must be the string "ISO 19115:2003/19139" to identify a metadata record as a valid instance of ISO19139 XML metadata. (note change from version 1.2 of this profile)

9.    MD_Metadata/metadataStandardVersion/gco:CharacterString must be the string " ISO-USGIN-1.3" to identify a metadata record as conforming to the version 1.3 USGIN ISO metadata profile. (note change from version 1.2 of this profile)

10. MD_Metadata/identificationInfo/MD_Identification/citation/CI_Citation/title is mandatory. A meaningful title that is unique within the scope of the catalog should be provided for each resource that is described by a metadata record. This may be in a MD_DataIdentification or SV_ServiceIdentification element.
11. MD_Metadata/identificationInfo/MD_Identification/citation/CI_Citation/date is mandatory, and must be specified as an xml DateTime data type: YYYY-MM-DDThh:mm:ssZ. Some validators require time zone as well; recommend GMT indicated by 'Z', other time zones are indicated by "+" or "-" integer offset from GMT, e.g. "+7" for US MST.
12. MD_Metadata/identificationInfo/MD_Identification/citation/CI_Citation/responsibleParty is mandatory with role CI_RoleCode@codeListValue one of {originator, principalInvestigator, processor, author}. This element identifies the agent responsible for the intellectual content of the described resource. The CI_ResponsibleParty element must include a contact e-mail address (electronicMailAddress) or telephone number (voiceTelephone), and one of individualName, organisationName, or positionName must be present.
13. identificationInfo/MD_Identification/abstract is mandatory, but nilable. Should include a description of resource content and any other information that will help users evaluate and use the resource.
14. identificationInfo/MD_Identification/-extent/EX_Extent/-geographicElement/-EX_Geographic­BoundingBox is mandatory if the resource has a geographic footprint. Geographic extent must be represented by bounding box in WGS 84 decimal degrees. Non-geographic resources are given a place keyword 'non-geographic'.

2.1.1 Non-service resources

Any resource that is not a service is described by a metadata record with a MD_DataIdentification as the concrete implementation of the abstract MD_Identification element.

1. If the metadata describes a physical resource, identificationInfo/MD_DataIdentification/-pointOfContact/CI_ResponsibleParty must provide contact information for the agent who is the resource steward. Count of (individualName + organisationName + positionName) must be > 0. The CI_ResponsibleParty/role/CI_RoleCode is from CI_RoleCode codelist. ISO role codes for physical resource point of contact are {custodian, owner, pointOfContact}.
2. MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorContact/­CI_Res­ponsibleParty is mandatory with role.CI_RoleCode@codeListValue = "pointOfContact" (CI_RoleCode element value = "pointOfContact") that provides a contact point to report problems with accessing the resource through distributions associated with the distributor. The CI_ResponsibleParty element must include a contact e-mail address (electronicMailAddress) or telephone number (voiceTelephone), and one of individualName, organisationName, or positionName must be present.
3. MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributionOrderProcess/MD_StandardOrderProcess is mandatory if the described resource is not available online. This should be a free text explanation of how to access the described resource.
4. MD_Metadata/distributionInfo/MD_Distribution/distributor/MD_Distributor/distributorTransferOptions/-MD_DigitalTransferOptions/online/CI_OnlineResource/linkage/URL is mandatory if the described resource is available online. Note that if online access is through a service, additional CI_OnlineResource properties may be required to provide sufficient information to allow software agents to use the metadata to connect to the service.

2.1.2 Service Resources

Service metadata records in the USGIN profile are intended to describe a particular service instance from the point of view of a service implementation and endpoint. Each dataset exposed by the service should be described by a separate metadata record with MD_HierarachyLevel = 'Dataset'.

1. The srv:ServiceType element value must be populated from a string in the USGIN ServiceType codelist (Table 11).
2. Service status is required. Value is from MD_ProgressCode codelist. ISO Code names applicable to services include {completed, obsolete, onGoing, planned, required, underDevelopment}.
3. Service metadata records must provide a coupling type attribute specifying 'tight', 'mixed', or 'loose' coupling with particular data.
4. If coupling type is 'tight' or 'mixed' a at least one coupled­Resource element is mandatory.
5. At least one service operation MUST be described with the operationDescription/­Character­String = 'serviceDescription'. The identificationInfo/SV_ServiceIden­tification/­contains­Operations/­­SV_OperationMetadata/­connectpoint link for this operation MUST retrieve the service-specific self description document (e.g. WSDL, GetCapabilities, WADL). The CI_OnlineResource in this connectPoint elment must have CI_OnlineResource/name = "serviceDescription" (from the table in section 7.2 Linkage name conventions).

2.2 USGIN specification constraints and recommendations

Recommended practices

• DatasetURI if there is one. Nilable if not available.
• All resources should have a point of contact responsible party that specifies the agent currently responsible for curation and maintenance of the resource.
• Allow multiple distributor-format-transfer option combinations for a single resource. This is critical information for enabling automated access to resources based on the metadata content. The ISO metadata model allows different approaches to binding between a distributor and resource distributions from that distributor when there are multiple distributors and distributions. This profile defines conventions for documenting those bindings.
• Representation of aggregated resources done using identificationInfo/­MD_Data­Identification/­aggregationInfo/MD_AggregateInformation¸ not MD_Metadata/parentIdentifier

• Vertical resource extent may use an elevation convention or a depth convention. CRS referenced to mean sea level, meters, measured positive up.
• Resolution expressed using equivalentScale/MD_Representative­Fraction/denominator is mandatory.
• Recommended distribution format codes (Table 6) for distributionFormat/name introduced for categorization of physical resources, like a book, rock sample, paper document. USGIN recommends use of MIME types if they are registered for the format, and provides a recommended syntax for file formats that do not have corresponding MIME types.
• Table 12 is a list of recommended CI_OnlineResource/name strings used to identify special online resources link icons for branding.
• Use of a controlled vocabulary for a CharacterString data type value is indicated by including an xsi:type=" gml:CodeType" on the gco:characterString element, which then requires a codeSpace attribute (see 4.14.2-Non digital resources and 7.2-Linkage name conventions). This codeSpace should be the URI for the vocabulary used. The CharacterString element value MUST then be an identifier from that vocabulary. This convention turns the gco:CharacterString value into a GML scoped name or gco:LocalName element.
• If the metadata resource is not specific to a geographic extent, the MD_identification/extent/-EX_Extent/geographicElement/ should have a nilReason="inapplicable" attribute and the place keyword 'non-geographic' should be included in a descriptiveKeywords element.

2.3 USGIN specification extensions

Extensions to ISO19115, ISO119, ISO19139 introduced by USGIN profile:

Allow use of identificationInfo/SV_ServiceIdentification/coupledResource/­SV_CoupledResource/ScopedName defined by OGC 07-045 ISO profile for CSW 2.0.2, use to provide WMS layer names or WFS feature names for service requests.

2.4 General Objectives

The Profile defines:

·         mandatory and conditional metadata sections, metadata entities, and metadata elements

·         the minimum set of metadata elements for any resource in order to conform to the Profile

·         the core metadata for geographic datasets

·         optional metadata elements that allow for a more extensive standard description of resources

·         some recommended practices to increase the utility and interoperability of metadata.

2.5 Requirements

M (mandatory). Metadata element must have a valid value.

C (conditional). Metadata element is mandatory based on values of other metadata elements in the metadata record.

O (optional). Metadata element may be null in a valid document.

X (not used). Metadata element is not used by a Profile. The element may be included where it is schema valid, but may be ignored by applications implementing the profile.

2.6 Use cases to be supported

This section includes a number of user scenarios for how we intend USGIN metadata to be used, and discussion of several basic approach requirements that guide metadata content recommendations. At its heart, the problem is to find resources of interest via the internet, based on criteria of topic, place, or time, evaluate resources for an intended purpose, and learn how to access those resources. Detailed metadata describing a resource data schema, describing service or application operation, or providing detailed descriptions of analytical techniques and parameter are outside the scope intended for USGIN metadata. Our contention is that this more domain/resource specific type information is better accounted for with linked documents utilizing schema appropriate to those specific resource. Some examples include OGC getCapabilities, WSDL, and ISO 19110 feature catalogs. For more in depth discussion of use cases, scenarios, and requirements, see Metadata Recommendations for Geoscience Resources (Richard and Grunberg, 2010).

·         A user specifies a geographic bounding box or one or more text keywords to constrain the resources of interest, and searches a metadata catalog using these criteria. The user is presented with a web page containing a list of resources that meet the criteria, with links for each resource that provide additional detailed metadata, and direct access to the resource if an online version is accessible, e.g. as a web page, Adobe Acrobat document, or online application (see Accessing Resources, below).

·         A client application provides user with a map window that contains some simple base map information (political boundaries, major roads and rivers). User wishes to assemble a variety of other data layers for a particular area for some analysis or data exploration, e.g. slope steepness, geologic units, bedding orientation, and vegetation type for a hazard assessment. User centers map view on area of interest, then using an 'add data' tab, accesses a catalog application that allows them to search for web services that provide the desired datasets. After obtaining the results and reviewing the metadata for the located services, user selects one or more to add to the table of contents for the client application. Response from catalog has sufficient information to enable the client application to load and use the resource (e.g. serviceType, OnlineResourceLinkage). More concrete instances of this case would be finding Web Map services to add as layers in an ESRI ArcMap project, borehole Web Feature Services to post borehole logs in a 3-D mapping application, or water chemistry data Web Feature Service to bring data into a spreadsheet or database.

·         A catalog operator wishes to import and cache catalog records from a collaborating catalog that have been inserted or updated during the last month (harvest). This operation requires knowledge of the metadata standard and version used for the returned records.

·         A user discovers an error in a metadata record for a resource that they have authored, and wishes to contact the metadata producer to request correction.

·         A search returns several results that appear to contain the desired content, and user must select the most likely to meet their needs. Metadata should provide sufficient information to guide this decision.

·         A project geologist at Company X is searching for data relevant to a new exploration target, and wishes to restrict the search to resources that are publicly available.

2.7 Resources of interest

Table 1 summarizes the geoscience information resources of interest to the community that can be registered and discovered using this metadata profile. Note that this collection of resource types includes several kinds of resources that are not typically associated with ISO19115/ISO19119, which were created specifically for geospatial resources.

Table 1. Summary of resource types described by metadata for US Geoscience Information Network catalogs. Resource type names in bold have been prioritized for implementation in version one catalogs. The Resource type names include the type hierarchy encoded with the broader (parent) resource type indicated in the Broader Resource Type column.

 

3.1 Core spatial dataset, dataset series, and service elements

Table 2 is a listing of ISO19115 metadata elements used to describe any resource. Tables 3 and 4 provide specifics for describing datasets and services. Note that in the USGIN context, dataset is construed quite broadly to include any kind of georeferenced information resource, including physical samples and hard copy documents. The service metadata elements are defined by ISO19119. The root element of ISO XML-encoded metadata is MD_Metadata. Elements are discussed in this table in the order that they appear in the metadata document. Not all elements are discussed in detail. In a number of places where USGIN makes no specific provisions, we defer to recommendations in the North American Profile for ISO metadata (INCITS 453, referred to as NAP). Note that throughout this and the subsequent tables, the names of XML elements are shown in this typecase. Long X-paths have been broken with non-breaking hyphen characters. Hyphens are not used in any XML attribute or element name, so if they appear in the text, they are strictly for text wrapping.

Table 2. Description best practices for ISO19139 metadata elements in USGIN profile. This table includes base elements. Elements are in the order that they appear in a metadata instance.

ISO 19115 (M/C/O) xPath from MD_Metadata	NAP-USGIN M/C/O	Comments
Metadata file identifier (O) fileIdentifier	M-M	Identifier for the metadata record, as opposed to DatasetURI, which identifies the described resource. A unique metadata record identifier must be included to allow CSW operations such as GetRecordById or harvest transactions. This identifier should be copied during harvest operations. Ideally there is one metadata record describing each resource, such that there should be a one-to-one mapping between metadata fileIdentifiers and DatasetURIs. However, not all described resources will have a DatasetURI, and the metadata record is a different resource from the resource it describes, and thus should not have the same identifier. The protocol used to generate the identifier does not matter, as long as it generates globally unique identifier strings. Services that rely on natural keys (e.g. serviceURL and layerID) are expected to put the key values in this field. Although there is technically no limit on the length of the identifier string, suggested best practice is to keep the string length less than 255 so the string will fit in legacy database string value fields. USGIN, ANZLIC, and the OGC CSW profiles for ISO metadata (OGC 07-045) recommend the use of the UUID (Universally Unique Identifier) for the fileIdentifier. The fileIdentifier is used to identify duplicate copies of metadata records, to reference one metadata record from another (via MD_Data­Iden­tification/­aggregationInfo), or to reference metadata from a described resource (e.g. DS_Dataset/has/MD_Metadata). If there is a difference between the two metadata records then one can determine the appropriate version by the content of other elements in the metadata record. The authoritative metadata record should be the only one made publicly available in metadata search systems such as a catalog service.
Metadata language (M) language	M-M	The language string is composed of a three lower-case letter language code (ISO639-2/T). Most CSW client and server applications only support the three letter language code. (Note: The recommended USGIN practice is different from the NAP, which recommends including an alpha3 country code (ISO3166-1), given in uppercase, with syntax "<ISO639-2/T three letter language code><;><blank space><ISO3166-1 three letter country code>", e.g. fra; CAN. Language searches for the three letter ISO639 code and a wildcard character will work with either convention.)
Metadata character set (C) characterSet	M-M	USGIN recommends use of ISO codelists: codeListValue="utf8" codelist= "http://standards.­iso.org/­ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/­Codelist/ML_gmx­Codelists.xml#­CI_CharacterSetCode. See 4.17.3 Codelists for discussion of codelist usage. USGIN requires that a character set code is specified, but this will normally be a default value for all records in a catalog.
Parent metadata record (O) parentIdentifier	O-X	Not used in USGIN profile. USGIN CSW service implementations do not require clients to be able to navigate parent links to obtain inherited metadata properties, or to process filters using parent links, so this element is not used. To represent relationships between described resources use MD_Identification/aggregationInfo.
Resource type (C) hierarchyLevel	M-M	Cardinality is 1...*. NAP and ISO codelists are equivalent. See 4.17.3 Codelists for discussion of encoding of codelist values. Due to interoperability problems, USGIN mandates use of ISO codelists. At least one MD_ScopeCode codelist value is required; default is 'dataset'. For USGIN catalog metadata, the codelist is {collectionHardware, collectionSession, dataset, series, nonGeographicDataset, dimensionGroup, fieldSession, software, service, model, tile}; other values from the ISO 19115 Scope Code list will be considered out of scope for USGIN catalog metadata and the metadata record may be ignored by harvesting catalogs. The European INSPIRE Implementing Rules (MD_IR_and_ISO_20090218) proscribes the code list for the first hierarchyLevel xml element in an MD_Metadata document to be one of {dataset, service, series}, or the metadata set will be considered out of scope for the directive (see section 4.6 Resource Type); in order to maintain compatibility with INSPIRE catalogs, it is recommended to use a scope code from this subset. ISO Example -- dataset metadata: <gmd:hierarchyLevel> <gmd:MD_ScopeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode> </gmd:hierarchyLevel>
Resource hierarchy level name (C) hierarchyLevelName	O-M	USGIN makes this property mandatory to identify the USGIN resource type from Table 1 (above). Default USGIN hierarchyLevelName.CharacterString is "Dataset". Encode hierarchy by including hierarchyLevelName elements for all broader resource categories. E.g. default should also include a hierarchyLevelName="Collection" element. For services USGIN hierarchyLevelName.CharacterString is "Service". As use cases develop that provide rationale for definition of sub-categories of service, the resource category list will be expanded. (ISO 19115 assumes that the metadata hierarchy level name defaults to "dataset" if it is not documented. NAP does not use it.)   Example -- dataset metadata: <gmd:hierarchyLevelName> <gco:CharacterString>Dataset</gco:CharacterString> </gmd:hierarchyLevelName>   <gmd:hierarchyLevelName> <gco:CharacterString>Collection</gco:CharacterString> </gmd:hierarchyLevelName>
Metadata point of contact (M) contact/CI_ResponsibleParty	M-M	Cardinality on contact is 1..*. USGIN requires at least one CI_ResponsibleParty with role.CI_RoleCode@codeListValue = "originator" (CI_RoleCode element value = "originator") that identifies the original source of the metadata record. If the point of contact for users to report errors, updates to metadata, etc. is different than the originator, an additional contact/CI_ResponsibleParty element may be included with role.CI_RoleCode@­code­List­Value = "pointOfContact" (CI_RoleCode element value="pointOfContact"). If the service providing the metadata records wishes to identify itself in result records, this information should be included in an additional MD_Metadata/contact/­CI_ResponsibleParty element, with role.CI_RoleCode@­code­List­Value = "distributor". See 4.17.3 Codelists for discussion of encoding of codelist values. ISO Role codes applicable in this context include: {distributor, originator, pointOfContact}. The CI_ResponsibleParty element must include a contact e-mail address (electronicMailAddress) or telephone number phone/CI_Telephone/voice), and count of (individualName + organisationName + positionName) > 0. If the contactInfo/CI_Contact/onlineResource/CI_OnlineResource element for the CI_Res­ponsibleParty with role.CI_RoleCode@codeListValue = "originator" has CI_Online­Resource/­name = "icon", the CI_OnlineResource/linkage/URL will be assumed to points to an icon image file (e.g. tif, png, jpg) for the metadata originator. This Icon will be displayed in search results to credit the metadata originator. Metadata harvesters must harvest and maintain all metadata originator information so that the origin of metadata records can be credited, and should harvest the point of contact information if it is different. Other responsible party roles applying to the metadata record (not the described resource) may be ignored by harvesting catalogs.
Metadata date stamp (M) dateStamp	M-M	USGIN profile requires use of dateStamp/gco:DateTime (Note this contrasts with INSPIRE mandate to use dateStamp/gco:Date). This is the date and time when the metadata record was created or updated (following NAP). The dateStamp is assumed to be updated to reflect any change in the metadata record that the metadata publisher wishes to propagate through the USGIN catalog system. This is the time stamp that will be used by harvesters to determine if a metadata needs to be updated in a harvesting catalog.
Metadata standard name (O) metadataStandardName	M-M	ISO19115/19139 conformant metadata is indicated by using "ISO 19115:2003/19139" The strings "ISO-NAP-USGIN" and "ISO-USGIN" have been used in the past and will also be recognized, but their use should be discontinued. Use is mandatory to indicate that the metadata record conforms to this profile.
Metadata standard version (O) metadataStandardVersion	O-M	For this version of the USGIN profile, Must use the string "ISO-USGIN-1.3". Use is mandatory to specify the version of the profile used
DataSet Identifier (O) dataSetURI	O-O	This is a string that uniquely identifies the described resource. If the resource has an identifier, it should be included here; if the resource will be referenced from other metadata, it must have an identifier here. Any kind of resource (not only datasets) may have an identifier. The protocol for the identifier is not specified, but some sort of documented scheme to assure uniqueness should be used (UUID, URN...). USGIN is attempting to make the semantics of identifiers clear, with the provision (see Unique resource identifier in Table 3, below) that the identifier in MD_DataIdentification/citation/CI_Citation/­identifier/MD_Identifier identifies the cited resource. This may be identical with the resource described by the metadata, in which case its value is identical to MD_Metadata/dataSetURI, or it may be a publication that is the intellectual source of the described resource, in which case it is a different identifier. The MD_Distribution/transferOptions/MD_DigitalTransferOptions/online/CI_OnlineResource is used to specify URLs for access to the resource, even if the datasetURI is an HTTP URI that will dereference to obtain a representation of the described resource. The dataSetURI should be considered an opaque identifier. This will avoid ambiguity about where to find URLs for online access to a described resource. If the dataset is coupled to a service, the value of the MD_Metadata/dataSetURI attribute is the unique resource identifier used by srv:coupledResource to link the service with the dataset. The OpenGIS® Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile (OGC 07-045) Annex F recommends that MD_DataIdentification/citation/CI_Citation/­identifier/­MD_Identifier/­code match the identifiers specified by SV_ServiceIdentification/operatesOn and SV_Service­Identification/­coupledResource for linking a described service to datasets that the service operates on. As discussed for fileIdentifier (above), this requires that a MD_DataIdentification/­citation/­­CI_Citation/identifier that identifies the described resource is included in the metadata record; its value must be the same as MD_Metadata/dataSetURI.
Other languages (C) locale	C-X	Other languages used in metadata free text description. If description in more than one language is provided, this property should indicate what those languages are. The primary language used for metadata description is identified with MD_Metadata/­language and characterSet and any additional languages are identified by MD_Metadata/locale/­PT_locale elements, in which the language is provided according to ISO 639-2/T three-letter terminology codes in lowercase, and an optional country is provided according to ISO 3166-1 three-letter codes in uppercase, and mandatory characterEncoding. See 4.17.3 Codelists for discussion of encoding of codelist values. USGIN Catalogs must harvest and process metadata content in the primary language specified by MD_Metadata/language and characterSet, and may ignore other language localized content.
[role] Resource spatial representation (O) spatialRepresentationInfo	O-O	Best practice is to include metadata for spatial representation if the described resource is a georeferenced dataset. Metadata for Spatial data representation are derived from ISO 19107. Metadata is instantiated as one or more of MD_GridSpatialRepresentation, MD_VectorSpatialRepresentation, MD_Georectified, or MD_Georeferenceable classes. USGIN profile follows NAP for spatial representation metadata. Vector Spatial Representation should be provided if point or vector objects exist in the dataset. If MD_VectorSpatialRepresentation is used, either spatialRepresentationInfo/MD_VectorSpatial­Representation/topologyLevel or spatialRepresentationInfo/MD_VectorSpatial­Representation/­geometricObjects shall be provided, or both." (NAP) MD_GridSpatialRepresentation or one of its subtypes (MD_Georectified, or MD_Georeferenceable ) should be provided if dataset objects are gridded. MD_Georectified should be used if the grid (image) is georeferenced, and MD_Georeferenceable is used if the grid (image) can be georeferenced. Follow NAP optionality if these elements are used.
Resource spatial representation vector topology (O) spatialRepresentationInfo/-MD_VectorSpatialRepresentation/topologyLevel	C-C	Code that specifies the degree of complexity of spatial relationships between features in a dataset. Value is from ISO codelist MD_TopologyLevelCode. (Code names in this list include {geometryOnly, topology1D, planarGraph, fullPlanarGraph, surfaceGraph, fullSurfaceGraph, topology3D, fullTopology3D, abstract}. See 4.17.3 Codelists for discussion of encoding of codelist values. It is unclear precisely what these values mean in terms of the topology encoding. To be useful, assertion that topology is present should indicate that topological relationships that may be implicit in the encoded vector geometry are explicitly represented (e.g. by correlation tables--left poly, right poly for a polyline) in the data. This clarification should be included in the resource abstract. Mandatory if MD_VectorSpatialRepresentation is present.
Resource spatial representation vector geometric objects (O) spatialRepresentationInfo/-MD_VectorSpatialRepresentation/geometricObjects	C-C	"Identification of the objects used to represent features in the dataset." Provides a geometry type and count for the number of objects of each type. Use the ISO MD_GeometricObjectTypeCode codelist. Code names in this list are: {complex, composite, curve, point, solid, surface}. See 4.17.3 Codelists for discussion of encoding of codelist values. Mandatory if MD_VectorSpatialRepresentation is present.
[role] Resource's spatial reference system (O) referenceSystemInfo	O-O?	Description of the spatial and/or temporal reference systems used in the dataset. Follow NAP rule: { (identificationInfo/spatialRepresentationType/MD_SpatialRepresentationTypeCode= "vector") or (../MD_SpatialRepresentationTypeCode = "grid") or (../MD_SpatialRepresentationTypeCode = "tin") implies count referenceSystemInfo >= 1) }. See 4.17.3 Codelists for discussion of encoding of codelist values. Use ISO codelist.
Reference System identifier code (O) referenceSystemInfo/-MD_ReferenceSystem/-referenceSystemIdentifier/-RS_Identifier/code	C-C	If referenceSystemInfo is included, then the RS_Identifier element must include at least a code value. For USGIN the code should be a value from the EPSG Geodetic Parameter Dataset register (http://www.epsg-registry.org/) in the form "EPSG:nnnn" where nnnn is the EPSG code number for the CRS. If the CRS is not defined in the EPSG registry, then the procedure specified in the NAP profile should be followed, e.g. the CRS shall be described according to ISO 19111 and ISO/TS 19127, assigned an identifier, and registered with an authority such that it may be referenced here. The RS_Identifier/codespace in this case should identify the registry authority where the CRS definition is registered, such that the definition can be located. Best Practice for USGIN purposes is to provide georeferenced data using one of the EPSG defined coordinate reference systems if this is possible.
Metadata extension information (O) metadataExtensionInfo	X-X	Not used in this profile.
Resource identification information (M) identificationInfo	M-M	Cardinality 1..*. The content of this element identifies the described resource. For resources that are not services, use MD_DataIdentification (see Table 3), otherwise SV_ServiceIdentification is required (see Table 4).
[role] Content information (O) contentInfo	O-O	Characteristics describing the feature catalog, coverage, or image data. MD_Content­Information is an abstract class. One or more of MD_FeatureCatalogueDescription or MD_CoverageDescription or MD_ImageDescription elements may be used to specify this content. MD_FeatureCatalogue­Description describes content in a feature service or dataset like an ESRI geodatabase that may have more than one feature, e.g. geologic unit outcrop polygons, fault line features, and point observation locations for strike and dip data. Entity-attribute metadata for dataset should be documented using ISO19110; XML schema are located at http://www.isotc211.org/2005/gfc/gfc.xsd. The ISO19139 XML implementation of ISO19115 does not allow inclusion of the feature catalog inside the metadata record, but provides a citation element in the gmd:contentInfo/gmd:MD_Feature­Catalogue­Description element. The USGIN profile provision is to link to the feature catalog using an xlink:href attribute on the gmd:featureCatalogueCitation, identified as such by an accompanying xlink:title attribute with the value "Link to ISO19110 feature catalog". Code Example 2 shows recommended encoding. An example feature catalog description using ISO19110 XML is included in section 8.4, ISO19110 Feature Catalog example. MD_Coverage­Description is for datasets that are one of the types listed in MD_CoverageContentTypeCode: image, thematicClassification, physical­Measurement. A coverage is a data structure that acts as a function to return values from its range for any direct position within its spatiotemporal domain (OGC 07-067r5). Image coverages return values for light intensity in a given wavelength range, thematicClassification coverages return codes corresponding to some domain concept, and physicalMeasurement coverages return values representing some physical quantity like magnetic susceptibility, density, resistivity.
[role] Resource distribution information (O) distributionInfo	O-M	This element provides information to inform users how to obtain or access the described resource, which is considered part of the minimum useful content that should be provided by a metadata record. USGIN profile specifies that at least one MD_Distribution/distributor and one MD_Distribution/transferOptions element are required, and the specified distributor provides the specified transfer options. See section 4.13 'Use of MD_Distribution and MD_Distributor' for instructions for more complicated combinations of distributor, format, transfer options, and ordering instructions.
Resource distribution format (O) distributionInfo/-MD_Distribution/­distributionFormat	O-O	Information on the format or physical manifestation of the resource. ·        If the resource is a physical (not electronic) resource, like a book, rock sample, paper document, the distributionFormat/MD_Format/name is mandatory, and must be from the Table 6. USGIN Distribution formats for non digital resources. URI for this codelist is http://resources.usgin.org/registry/­distribution­FormatNames201001. ·        For digital resources, the format specifies the file type, either using a MIME type, or formatted string. Pattern for digital resources that do not have a registered MIME type: [vendor:ap­plicationName]/fileExtension. The vendor and application names may not be applicable, and could be omitted, but the '/' and file extension should always be present. ·        If the format consists of a single file, the file extension is a three letter file-type abbreviation assigned by the vendor.
Resource distributor information (O) distributionInfo/-MD_Distribution/­distributor/-MD_Distributor/	O-C	USGIN differs from NAP in this case (but not with ISO19115) by allowing multiple distributors, and binding between distributors, transfer options, and formats. For USGIN profile, each distributor/MD_Distributor is a binding between one or more transfer options and the distributor formats that are available through that/those transfer options (MD_DigitalTransferOptions/onLine/­CI_Online­Resource in particular). If different formats are available from the same distributor, or have different transfer options, these should be represented as different distributor/MD_Distributor instances. See section 4.13 'Use of MD_Distribution and MD_Distributor' for instructions on use of these elements.
Resource distributor responsible party (O) distributionInfo/-MD_Distribution/­distributor/MD_Distributor/­distributorContact/­CI_ResponsibleParty	C-M	MD_Distributor is required, which requires one CI_ResponsibleParty. A responsible party with role.CI_RoleCode@codeListValue = "pointOfContact " (CI_RoleCode element value = "pointOfContact ") is mandatory, to provide a contact point to report problems with accessing the resource through distributions associated with the distributor. The CI_ResponsibleParty element must include a contact e-mail address (electronicMailAddress) or telephone number (electronicMailAddress), and one of individualName, organisationName, or positionName must be present. Other distributorContacts with different roles may be ignored by USGIN catalogs. ISO Role codes applicable in this context include: {resourceProvider, distributor, pointOfContact}. See section 4.17.3 'Codelists' for details on codelist encoding.
Resource distributor order process (O) distributionInfo/-MD_Distribution/distributor/-MD_Distributor/-distributionOrderProcess/-MD_StandardOrderProcess	O-C	Information on the availability of the resource including at least one of fees, available date and time, ordering instructions, or turnaround. For physical resources, ordering instructions are mandatory as these will typically indicate the method of accessing the resource.
Resource distributor format (O) distributionInfo/-MD_Distribution/distributor/-MD_Distributor/-distributorFormat/MD_Format	O-O	See section 4.14 'Distribution Format ' for instructions on use of these elements.
Resource distribution transfer options (O) distributionInfo/-MD_Distribution/-transferOptions/-MD_DigitalTransferOptions	C-C	MD_DigitalTransferOptions provides information on digital distribution of resource. See section 4.13 ' Use of MD_Distribution and MD_Distributor' for instructions on use of this element. If distribution information is included (MD_Distribution is not null), then at least one one MD_Distribution/transferOptions element is required.
Resource distributor online distribution linkage (O) distributionInfo/-MD_Distribution/-transferOptions/-MD_DigitalTransferOptions/-online/-CI_OnlineResource/linkage	M-M	Digital transfer options are "Technical means and media by which a dataset is obtained from the distributor." The CI_OnlineResource/linkage/URL element must contain the complete URL to access the resource directly (see sections 4.13 to 4.15 for more explanation).
Resource distributor online distribution linkage (O) distributionInfo/-MD_Distribution/-transferOptions/-MD_DigitalTransfer­Options/-online/­CI_OnlineResource/protocol	M-O	The CI_OnlineResource/protocol element is mandatory if access to the resource requires additional protocol information that is stacked on the protocol specified by the CI_OnlineResource/linkage/URL prefix (e.g. http:, ftp:). Typically this will be service type like WMS-1.3.0, OpenSearch-1.1, or DAP-2.0. Ideally these strings should be URIs that can be dereferenced to learn something about the service specification.
Resource distributor online distribution linkage (O) distributionInfo/-MD_Distribution/-transferOptions/-MD_DigitalTransfer­Options/online/­CI_OnlineResource/name	O-O	The CI_OnlineResource/name element may duplicate the file name if the URL is a link to a file, but it is recommended to provide a user-friendly label for the file that could be presented in a user interface. For links to resource distribution end points (distributionInfo//CI_OnlineResource) that are not simple file access URLs, like services, online order forms, mailto links to e-mail a request for the resource, the name property has special values defined in Table 13.
Resource distributor online distribution application profile (O) distributionInfo/-MD_Distribution/-transferOptions/-MD_DigitalTransferOptions/-online/CI_OnlineResource/-applicationProfile	C-O	applicationProfile is mandatory if the CI_OnlineResource/linkage does not connect to an HTML web page (or other standard format that will be recognized by web browsers), if another software application is needed to use a linked file resource, or the target resource is a service instance conforming to a profile. The applicationProfile character string should specify the software using the following recommended syntax: "vendor:application name/application version", e.g. "Microsoft:Word/2007", or "ESRI:ArcGIS/9.3". For links to documents for which the service type and base protocol prefix on the link URL do not provide sufficient information to guide client software, the applicationProfile property is used to indicate a profile on the serviceType or some variation in document encoding or content conventions. See section 4.15 CI_OnlineResource for more explanation.
Resource distributor online distribution function (O) distributionInfo/-MD_Distribution/-transferOptions/-MD_DigitalTransferOptions/-online/CI_OnlineResource/-function	O-O	CI_OnlineResource/function is mandatory if the linkage is not a simple HTTP link to a downloadable file. USGIN recommended values for CI_OnlineFunctionCode in this role are summarized in Table 7. If the resource is accessible as a web service, the metadata for the service should be separate metadata record with the dataset(s) exposed through the service identified in the service metadata record as coupledResources.
[role] Data quality information (O) dataQualityInfo	C-O	Either dataQualityInfo/DQ_DataQuality/report or dataQualityInfo/DQ_DataQuality/lineage is mandatory if a dataQualityInfo element is present. dataQualityInfo/­DQ_Data­Quality/­scope is required, with value from MD_ScopeCode: {collectionHardware, collectionSession, dataset, series, nonGeographicDataset, dimensionGroup, fieldSession, software, service, model, tile}. See 4.17.3 Codelists for discussion of encoding of codelist values. See section 4.19 Data Quality for discussion of data quality with resource parts.
Data quality scope (O) dataQualityInfo/DQ_DataQuality/scope	C-C	Mandatory if DQ_DataQuality is not null. Specifies the extent of characteristics for which data quality information is reported. Value is from MD_ScopeCode: {collectionHardware, collectionSession, dataset, series, nonGeographicDataset, dimensionGroup, fieldSession, software, service, model, tile}. See 4.17.3 Codelists for discussion of encoding of codelist values.
Data quality scope level description (O) dataQualityInfo/-DQ_DataQuality/-scope/levelDescription	C-X	Not used by USGIN. See section 4.19 Data Quality for more discussion of levelDescription.
Data quality report (O) dataQualityInfo/-DQ_DataQuality/report	C-C	In this profile, data quality information is optional, but if included, the mandatory content for data quality information is a free text explanation of data quality considerations. The DQ_DataQuality[1]//­report[1]//­­explanation/CharacterString element should contain a free text discussion/description of data quality considerations for the indicated scope. The use of any specific data quality element to contain this explanation is arbitrary and should not be considered meaningful in this context. Other data quality information should be preserved by USGIN catalogs harvesting metadata that includes these elements, and presented when the user views the full metadata record. Each DQ_DataQuality/­report element requires that at least one of the 15 possible data quality elements must be present, and multiple report elements are allowed within each DQ_DataQuality element. Each of these AbstractDQ_element subtypes has optional nameOfMeasure, measureIdentification, measureDescription, evaluationMethodType, evaluationMethodDescription, evaluationProcedure, and dateTime elements, and one or two required result elements. The AbstractDQ_element /result is either a DQ_ConformanceResult or a DQ_QuantitativeResult, each of which has required and optional sub-elements. Inclusion of this report metadata should follow recommendations in NAP.
Data quality lineage (O) dataQualityInfo/-DQ_DataQuality/lineage	C-O	Not applicable to services. USGIN recommended practice is described in section 4.19.
Data quality lineage statement (O) dataQualityInfo/-DQ_DataQuality/lineage/-LI_Lineage/statement	C-C	If lineage information is included, a lineage/LI_Lineage/statement is mandatory, which specifies a "General explanation of the data producer's knowledge of the dataset lineage" (NAP). USGIN recommended practice is described in section 4.19.
Data quality lineage source (O) dataQualityInfo/-DQ_DataQuality/lineage/-LI_Lineage/source	C-O	Each source/LI_Source element describes a source data resource that is input into a processStep. NAP provision is that LI_Source/description is mandatory if LI_Source/sourceCitation and LI_Source/sourceExtent are not provided. If used, the LI_Source/description includes the source medium name from the CodeList MD_MediumNameCode, followed by <;><blank space> and a free text description, e.g. "dvd; source satellite image." If the source is part of a processing chain, the LI_Source/processStep/LI_ProcessStep provides "Information about an event related to the creation process for the source data." (INCITS 453). This is interpreted to mean that the link from a source to a process step is to a process step for which the described source is an output. USGIN recommended practice is described in section 4.19.
Data quality lineage process step (O) dataQualityInfo/-DQ_DataQuality/lineage/-LI_Lineage/processStep	C-O	An event in the development of the dataset. Each step requires a free text description, and may have a free text rationale, dateTime stamp when process was complete, 0 to many CI_ResponsibleParty elements identifying parties involved in the process, and finally 0 to many source/LI_Source associations to identify data that is input into the process step. Best practice recommended for USGIN is that source association from a process step is to inputs to a process, and processStep associations from a source element link an output resource to a process step that produced it. See USGIN recommended practice is described in section 4.19.
[role] Portrayal catalog information (O) portrayalCatalogueInfo	O-O	portrayalCatalogueInfo/MD_PortrayalCatalogReference/portrayalCatalogueCitation/CI_Citation element identifying a catalogue that contains symbols and rules to depict a resource. A portrayal catalog is a collection of defined symbols used to depict, to humans, features on a map. No documentation in ISO19115 about how this is supposed to work. ISO 19117 defines the structure of a Portrayal Catalogue. No USGIN recommended practices have been adopted.
[role] Metadata constraint information (O) metadataConstraints	O-O	This element specifies use constraints for access to the metadata record. Use constraints for accessing the describe resource are in resourceConstraint/MD_Constraint in MD_DatasetIdentification or MD_ServiceIdentification. Follow NAP for specification of access constraints. NAP provision is that metadataConstraints/MD_Constraints/useLimitation is mandatory when MD_Constraints is used to specify metadataConstraints. When one of the subtypes MD_LegalConstraints or MD_SecurityConstraints is used, useLimitation is optional. MD_LegalConstraints are specified by MD_RestrictionCode. ISO codelist values are {copyright, patent, patentPending, trademark, license, intellectualPropertyRights, restricted, otherRestrictions}. See 4.17.3 Codelists for discussion of encoding of codelist values. otherConstraints is a free text element required if accessConstraints or useConstraints is set to "otherRestrictions." For an example: "Data only to be used for the purposes for which they were collected." MD_SecurtyConstraints has various optional free text values, and a required MD_SecurityConstraints/classification from ISO MD_ClassificationCode: {unclassified, restricted, confidential, secret, topSecret}. See 4.17.3 Codelists for discussion of encoding of codelist values.
[role] Application schema information (O) applicationSchemaInfo	O-O	Information about the information schema of the resource applicationSchemaInfo/MD_Application­SchemaInformation element has mandatory name/CI_Citation, schemaLanguage free text, and constraintLanguage free text. The MD_ApplicationSchemaInformation element also allows inclusion of an actual schema document as ASCII, or a binary graphicsFile or softwareDevelopmentFile. Multiple applicationSchemaInfo elements may be used for different presentations of a single schema, or for different kinds of schema (e.g. physical, logical, conceptual).
[role] Metadata maintenance information (O) metadataMaintenance	O-O	This element provides information about the maintenance schedule or history of the metadata record. Only one MD_MaintenanceInformation element may be included, with a required MD_MaintenanceFrequencyCode. The ISO codelist is {continual, daily, weekly, fortnightly, monthly, quarterly, biannually, annually, asNeeded, irregular, notPlanned, unknown}. See 4.17.3 Codelists for discussion of encoding of codelist values. Additional metadataMaintenance/MD_MaintenanceInformation/maintenanceNotes may be added to metadata records to document updates to the the content of the record. USGIN catalogs should use metadata maintenance notes to document any modifications made to harvested metadata records; ideally a link to the original metadata record should be provided.
[role] Series information (O) series	X-X	The MD_Metadata/series element that appears in the ISO19139 schema appears to implement the metadata application model in ISO19115:2003 Figure 3, which is a UML class diagram defining the classes of geographic information to which metadata applies. Not Used by USGIN.
[role] Described resource (O) describes	X-X	The MD_Metadata/describes element that appears in the ISO19139 schema appears to implement the metadata application model in ISO19115:2003 Figure 3, which is a UML class diagram defining the classes of geographic information to which metadata applies. Not used by USGIN.
[role] Property type description (O) propertyType	X-X	The MD_Metadata/propertyType element that appears in the ISO19139 schema appears to implement the metadata application model in ISO19115:2003 Figure 3, which is a UML class diagram defining the classes of geographic information to which metadata applies. Not used by USGIN.
[role] Feature type description (O) featureType	X-X	Although an MD_Metadata/featureType element that appears in the ISO19139 schema appears to implement the metadata application model in ISO19115:2003 Figure 3, which is a UML class diagram defining the classes of geographic information to which metadata applies. Not used by USGIN.
[role] Feature attributes (O) featureAttribute	X-X	Although an MD_Metadata/featureAttribute element that appears in the ISO19139 schema appears to implement the metadata application model in ISO19115:2003 Figure 3, which is a UML class diagram defining the classes of geographic information to which metadata applies. Not used by USGIN.

 

3.2 Dataset Identification properties (MD_DataIdentification)

The difference between metadata for services, and metadata for other resources is in the identificationInfo part of the ISO19139 xml schema. This section documents use of MD_DataIdentification for metadata describing resources of interest in the geoscience information network that are not services. Service metadata utilizes the SV_ServiceIdentification element to provide a description and identification of a service (see 3.3 Service identification elements).

Note that the USGIN approach to metadata is predicated on the idea that the users first interest is finding information about some particular topic; how that information is accessed or acquired is a secondary consideration. Thus metadata records are about information resources (mostly datasets and other data products or publications) at the FRBR work level [FRBR, 2004]. Information on accessing data resources through service interfaces is considered a kind of distribution of the resource. The MD_DataIdentification part of a metadata record describes the information resource, and multiple distributionInformation elements specify access to that data through one or more services, or as various kinds of packaged, downloadable files. Given that a metadata record is about exactly one 'work', each metadata record has exactly one MD_DataIdentification element. Metadata records about services are targeted for the rather unusual situation in which a user is primarily interested in a specific kind of service and the details of its operation, typically this will be for web processing or brokering services. In practice, service protocols typically specify some kind of service specific self-description document (e.g. WSDL, WADL, OGC GetCapabilities, OpenSearch Description) that client software is more likely to understand than an ISO SV_ServiceIdentification element.

Table 3. Dataset Identification properties (MD_DataIdentification)

ISO 19115 (M/C/O) xPath from MD_Metadata	NAP-USGIN M/C/O	Comments on MD_DataIdentification
Resource citation (M) identificationInfo/-MD_DataIdentification/-citation/CI_Citation	M-M	CI_Citation cardinality exactly one required. The citation attribute provides information that identifies the intellectual origin of the content in the described resource, along the lines of a citation in a scientific journal. Required content for a CI_Citation element are title, date, and responsibleParty. NOTE: if multiple identificationInfo sections are provided, USGIN catalogs may ignore all but the first instance.
Resource title (M) identificationInfo/-MD_DataIdentification/-citation/­CI_Citation/title	M-M	A meaningful title that is unique within the scope of the catalog should be provided for each resource that is described by a metadata record. USGIN recommends using titles that inform the human reader about the dataset's content as well as its context.
Resource reference date (M) identificationInfo/-MD_DataIdentification/-citation/CI_Citation/date/-CI_Date/date/	M-M	Best practice is to include at least the date of publication or creation of the resource. The date of the resource reported in the citation corresponds to the most recent update of the resource's content. CI_Date content includes a date and dateType. Date for USGIN profile uses xs:dateTime data type, The dateTime data type is specified in the following form "YYYY-MM-DDThh:mm:ss". timezoneOffset is optional (http://www.w3.org/TR/xmlschema11-2). Example date encoding: 2000-12-12T12:00:00+13:00, 2006-10-01T03:27:00Z. If the month or day is not known, encode as '01', for example '2006-01-01'. DateType specifies the event used for the temporal aspect of the resource, and must be a value from the list {creation, publication, revision}, which is a subset of the ISO DateTypeCode codelist. This date is distinct from the dateStamp for the metadata record (date and time of most recent metadata update), or the EX_Extent/temporalElement that specifies the time period to which the resource content is applicable.
Unique resource identifier (O) identificationInfo/­MD_DataIdentification/­citation/CI_Citation/­identifier/­MD_Identifier	C-C	For USGIN, if the Citation has an identifier that is different from the identifier for the described resource (MD_Metadata/dataSetURI), it must be included here. This element content value should be an identifier for the cited resource, without any assumption that it will use http protocol. The identifier may be resolvable to a URL, if a protocol prefix specifies an identifier scheme that is resolvable (e.g. http, doi...), but this is not necessary for a valid document, and should not be assumed when processing metadata documents. The USGIN profile requires the use of MD_Identifier element to identify resources; RS_Identifier must not be used. If additional codespace and version content is associated with the identifier, it should be encoded as MD_Identifier/authority/­CI_Citation/­alternateTitle and MD_Identifier/­authority/­CI_Citation/­edition
Resource responsible party (O) identificationInfo/-MD_DataIdentification/-citation/CI_Citation/-citedResponsibleParty	M-M	USGIN requires that the citation include at least one CI_ResponsibleParty for which the count of (individualName + organisationName + positionName) must be > 0. The citation responsible party should identify the agent responsible for the intellectual content of the described resource. In this context, the CI_ResponsibleParty/role/CI_RoleCode@codeListValue is from {originator, principalInvestigator, processor, author}, a subset of the ISO CI_RoleCode codelist. See 4.17.3 Codelists for discussion of encoding of codelist values. For most intellectual content, the responsible party is what would normally be considered the author of a work. Best practice is to include point of contact information for the resource in MD_DataIdentification/pointOfContact/CI_ResponsibleParty. Guidance on use of role codes would be helpful for consistency, but has not been developed as yet. {author, coauthor, editor, contributor} View compiler and editor as equivalent roles, since codelist do not include compiler. Use the ISO19115-1 codelist.
Resource presentation form (O) identificationInfo/-MD_DataIdentification/-citation/CI_Citation/-presentationForm	O-O	The form in which the original cited resource is available. Note that the citation is to the original source of intellectual content in the described resource, and its presentation may be different from the format for distribution described in the metadata. This element should be specified if there is a difference between the cited resource presentation format and the distribution format(s) listed in the distributionInfo/MD_Distribution section of the metadata record. This information is mostly for documentation; for discovery and data access, the distribution formats are more relevant. presentationForm uses CodeList = CI_PresentationFormCode, with ISO code names {documentDigital, document­Hardcopy, imageDigital, imageHardcopy, mapDigital, mapHardcopy, modelDigital, modelHardcopy, profileDigital, profileHardcopy, tableDigital, tableHardcopy, videoDigital, videoHardcopy, audioDigital}. See section 4.17.3 Codelists for details on codelist encoding.
Resource series (O) identificationInfo/-MD_DataIdentification/-citation/CI_Citation/series	O-O	Information about the (publication) series or collection of which the resource is a part. NAP rule (name + issueIdentification) > 0 should be followed.
Resource other citation details (O) identificationInfo/-MD_DataIdentification/-citation/CI_Citation/-otherCitationDetails	O-O	A complete recommended bibliographic citation should be specified in this element.
Resource collective title (O) identificationInfo/-MD_DataIdentification/-citation/CI_Citation/-collectiveTitle	O-C	Title of the combined resource that the cited resource is part of, for example the cited resource may be a paper in an anthology, in which case the anthology title would be the collective title. Required if the cited resource is part of such a collective work.
Resource abstract (M) identificationInfo/­MD_DataIdentification/abstract	M-M	A free text summary of the content, significance, purpose, scope, etc. of the resource. Exactly one value. Content from metadata harvested in other formats (EML, FGDC CSDGM...) that does not map into ISO metadata elements can be included as free text in the abstract.
Resource purpose (O) identificationInfo/­MD_DataIdentification/purpose	O-O	"Summary of the intentions for which the dataset was developed. Purpose includes objectives for creating the dataset and what the dataset is to support." Free text.
Resource status (O) identificationInfo/­MD_DataIdentification/status	O-O	Value is from MD_ProgressCode codelist. ISO values are {completed, historicalArchive, deprecated, onGoing, planned, required, underdevelopment}. For USGIN discovery metadata, values should be restricted to {completed, onGoing, deprecated}. See section 4.17.3 Codelists for details on codelist usage.
Resource point of contact (O) identificationInfo/­MD_DataIdentification/­pointOfContact	O-C	Contact information for the agent who is currently the steward for the resource. This information is mandatory for physical resources such as core, cuttings, samples, manuscripts. Count of (individualName + organisationName + positionName) must be > 0. The CI_Responsible­Party/­role/­CI_RoleCode is from CI_RoleCode codelist. ISO role codes for physical resource point of contact are {custodian, owner, pointOfContact}; other point of contact role codes may apply for other resources. See section 4.17.3 Codelists for details on codelist usage.
Resource maintenance (O) identificationInfo/-MD_DataIdentification/-resourceMaintenance	O-O	This element provides information about the maintenance schedule or history of the resource (or some subset/part of the resource specified by the scope and scope description) described by the metadata record. 0 to many MD_MaintenanceInformation elements may be included. Different MD_MaintenanceInformation elements are required to have different napMD_ScopeCode or MD_ScopeDescription. Usage of MD_ScopeDescription is poorly described, and no actual examples of usage could be found; it would appear to allow identification of a set of attribute or features (by name?), or feature instances or attribute instances (identified how?), or a dataset, to which the maintenance information applies. Use MD_MaintenanceFrequencyCode codelist. ISO values are {continual, daily, weekly, fortnightly, monthly, quarterly, biannually, annually, asNeeded, irregular, notPlanned, unknown}. See section 4.17.3 Codelists for details on codelist usage.
Graphic overview of resource (O) identificationInfo/-MD_DataIdentification/­graphicOverview	O-O	Highly recommended to include a URL providing a web-accessible visual representation of the resource if it is applicable to the described resource, particularly for geographic datasets that may be represented by maps. If MD_BrowseGraphic is included, MD_BrowseGraphic/filename character string is mandatory. USGIN Recommended practice is to provide a complete URL as a gco:characterString value for the filename property. fileType/CharacterString should be a registered MIME type or standard file extension abbreviation (e.g. napMD_FileFormatCode). This is a repeatable element; multiple values may present different resolutions, or different parts of resource. Names associated with overview should provide sufficient information for user to distinguish these.
Resource format (O) identificationInfo/-MD_DataIdentification/­resourceFormat	X-X	This element is not used by NAP or USGIN; this information is encoded in MD_Metadata/distributionInfo/MD_Distribution/ in USGIN metadata (see 4.13 Use of MD_Distribution and MD_Distributor).
Resource keywords (O) identificationInfo/-MD_DataIdentification/­descriptiveKeywords/MD_Keyword	O-O	Keywords should be provided to facilitate the discovery of metadata records relevant to the user. Keywords should be grouped according to Keyword Type - allowed values from MD_KeywordTypeCode {discipline, place, stratum, temporal, theme}, and the thesaurus in which they are defined (if applicable). See section 4.17.3 Codelists for details on codelist usage. USGIN requires that MD_Keyword/keyword contain a CharacterString (see section 4.16). USGIN best practice is to include keywords in English.
Condition applying to access and use of resource (O) identificationInfo/­MD_DataIdentification/­resourceConstraints/	O-O	Restrictions on the access and use of a resource or metadata. Follow NAP for specification of resourceConstraints. This attribute provides information for access control to the described resource itself. In some situations, the metadata may allow a user to learn of the existence of a resource that they may not actually be able to access without further clearance. Constraints may be represented by MD_Constraint, MD_LegalConstraint, or MD_SecurityConstraint.
Aggregation information (O) identificationInfo/-MD_DataIdentification/­aggregationInfo/-MD_AggregateInformation	O-O	This element includes either a citation for or identifier of an associated dataset, along with the type of association between the datasets, and optionally the activity that produced the dataset. MD_Aggregate­Information requires either aggregateDataSetName/CI_Citation or aggregateDataSet­Iden­tifier/­MD_Identifier. MD_AggregateInformation/associationType is mandatory, from DS_As­sociation­TypeCode. ISO codelist includes {cross­Reference, largerWorkCitation, partOfSeamlessDatabase, source, stereoMate}. See section 4.17.3 Codelists for details on codelist usage. USGIN recommended practice is to include a dereferenceable URI for that resource in aggregateDataSet­Iden­tifier/­MD_Identifier/code. [note this text updated 2013-10-25 to reflect the information we're actually getting]. For related resources that do not have a metadata record, aggregateData­Set­Name/­­CI_Citation may be used; this element is optional if aggregateDataSetIdentifier has a value. For USGIN profile, this property, rather than MD_Metadata/parent­Identifier, should be used to indicate relationships between described resources.
Spatial Representation Type (O) MD_DataIdentification/spatialRepresentationType/	O-O	value from MD_SpatialRepresentationTypeCode list. ISO codelist includes {vector, grid, textTable, tin, stereoModel, video}. See section 4.17.3 Codelists for details on codelist usage.
Resource spatial resolution (O) MD_DataIdentification/-spatialResolution/-MD_resolution/equivalentScale/MD_RepresentativeFraction/-denominator	C-C	If the spatial representation type code is vector, grid, textTable or tin, an equivalentScale/../denominator MUST be provided to express spatial resolution (this is an arbitrary convention proposed to facilitate interoperablity). If a equivalentScale/../distance is available, that should be supplied as well. The resolution distance represents the smallest length between two resolvable points in the dataset. To calculate equivalentScale given a resolution distance, recommended practice is to divide the resolution distance in meters by 0.0005. This assumes that the smallest distance resolvable in a map display for human usage is 0.5 mm.
Resource language (O) identificationInfo/-MD_DataIdentification/language	M-O	Language for content of described resource. Default value is 'eng'. If language is not applicable to the described resource, a nilReason='notApplicable' attribute can be included on an empty language element. Multiple instances of this element indicate that the linguistic content of the resource is available in multiple languages. Use the three-letter language code from the ISO 639-2/T three letter language codelist, in lowercase. ISO 639 codelists are available at http://www.loc.gov/standards/iso639-2/php/code_list.php.
Topic category identificationInfo/-MD_DataIdentification/-topicCategory	C-C	A topicCategory code must be provided when hierarchyLevel is set to "dataset" or "dataset series". Codes are from MD_TopicCategoryCode, the ISO codelist includes {farming, biota, boundaries, climatologyMeterologyAtmosphere, economy, elevation, environment, geo­scientific­Information, health, imageryBaseMapsEarthCover, intelligence­Military, inlandWater, location, oceans, planningCadastre, society, structure, transportation, utilitiesCommunication}. See section 4.17.3 Codelists for details on codelist usage. Most USGIN resources will have MD_TopicCategoryCode = "geoscientificInformation", which is the default value for this profile. More specific topic categorization should be done using keywords.
Resource content extent identificationInfo/-MD_DataIdentification/extent/-EX_Extent	C-C	Defines the spatial (horizontal and vertical) and temporal region to which the content of the resource applies. For USGIN, a geographicElement/geographicBoundingBox must be provided for any resource with content related to some geographic location. For geoscience resources, temporal extent expressed using named time ordinal eras from a geologic time scale should be specified as thematic keywords. If the described resource is not related to a geographic area, the place keyword 'non-geographic' should be included in the descriptiveKeywords element. In some situations, geographic location may be indicated using location keywords, but this is strongly discouraged because location-based searches using geographic coordinates will not find such records. In such cases, geocoding tools from services like Google can often be used to obtain an approximate bounding box.
Resource content extent description identificationInfo/-MD_DataIdentification/extent/-EX_Extent/description	C-O	Free text that describes the spatial and temporal extent of the dataset. Note that if geographic place names are used to express the geographic extent, USGIN profile specifies that these should be encoded using keyword with keyword type code = 'place.' Geographic names may be duplicated in the EX_Extent/description.
Resource content extent bounding box identificationInfo/-MD_DataIdentification/extent/-EX_Extent/geographicElement/-EX_GeographicBoundingBox	O-C	USGIN profile requires that if an EX_Extent/geographicElement is supplied, it include a geographic bounding box with bounding latitude and longitude expressed using World Geodesic System WGS 84 decimal degrees. The corner coordinates for the geographic bounding box must not coincide in one point, because this may result in fatal errors with some CSW implementations. Point locations must thus be represented as tiny rectangles. USGIN recommended practice is to place the actual point location in the lower left corner of the rectangle.
Resource content extent geographic description identificationInfo/-MD_DataIdentification/extent/-EX_Extent/geographicElement/-EX_GeographicDescription	C-X	Not used by USGIN profile. In USGIN metadata this information should be encoded using keywords for which the MD_KeywordTypeCode = 'place'; the thesaurus/CI_Citation has the same content as EX_GeographicDescription/authority/CI_Citation, and the keyword is the same as the EX_GeographicDescription/code.
Resource content extent bounding polygon identificationInfo/-MD_DataIdentification/extent/-EX_Extent/geographicElement/-EX_BoundingPolygon	C-O	To improve interoperability, USGIN mandates the use of Geographic Bounding Box instead of bounding polygon, if a bounding polygon is included it may be ignored by harvesting catalogs. If only a bounding polygon is provided, a minimum bounding box must be calculated and inserted in the EX_GeographicBoundingBox element when the record is harvested into a USGIN catalog.
Resource temporal extent (O) identificationInfo/-MD_DataIdentification/extent/-EX_Extent/temporalElement/-EX_TemporalExtent/extent/-TimePeriod	O-O	Property contains information about temporal extent to which resource is applicable. For many geoscience resources, this would be the geologic time period(s) to which the resource applies. USGIN mandates use of gml:TimePeriod with bounds described by gml:begin and gml:end elements for all temporal extents. The default reference system for gml:TimeInstant is @frame = "#ISO-8601". For geologic time extents, USGIN requires the values for gml:begin/gml:TimeInstant/gml:timePosition and gml:end/gml:TimeInstant/gml:timePosition to be populated using numeric time coordinates in Ma, measured positive increasing older with an origin at 1950 CE (see Temporal extents). The default @frame attribute value for geologic time coordinates is "urn:cgi:trs:CGI:StandardGeologicTimeMa" Example with default values: <gml:TimePeriod gml:id="IdModern2010"> <gml:name>Year 2010</gml:name> <gml:begin>   <gml:TimeInstant frame="#ISO-8601">     <gml:timePosition>2010-01-00T00:00:00</gml:timePosition>   </gml:TimeInstant> </gml:begin> <gml:end>   <gml:TimeInstant frame="#ISO-8601">      <gml:timePosition>2010-12-31T24:00:00</gml:timePosition>   </gml:TimeInstant> </gml:end> </gml:TimePeriod>     Geologic Time Example: <gml:TimePeriod gml:id="IdJurassic"> <gml:name>Jurassic</gml:name> <gml:begin>   <gml:TimeInstant frame="urn:cgi:trs:CGI:StandardGeologicTimeMa">     <gml:timePosition>203</gml:timePosition>   </gml:TimeInstant> </gml:begin> <gml:end>   <gml:TimeInstant frame="urn:cgi:trs:CGI:StandardGeologicTimeMa">      <gml:timePosition>135</gml:timePosition>   </gml:TimeInstant> </gml:end> </gml:TimePeriod>
Resource spatio-temporal extent (O) identificationInfo/-MD_DataIdentification/extent/-EX_Extent/temporalElement/-EX_SpatialTemporalExtent/	O-X	Not used. Conventions for temporal extent will be followed on gmd:extent part and for spatial extent on the gmd:spatialExtent part.
Resource vertical extent (O) identificationInfo/-MD_DataIdentification/extent/-EX_Extent/verticalElement/-EX_VerticalExtent	O-O	Vertical extent is used to describe the elevation location of resource content, if applicable. Common geoscience examples are resources related to vertical location in a borehole or depth in a water body. The borehole trace is the vertical coordinate reference system (CRS) within which described resources are located using coordinates measured in linear distance from the collar (or ground level, or Kelly bushing) of the borehole. EX_VerticalExtent has minimumValue, maximumValue that are real numbers, and a verticalCRS. For interoperability, USGIN mandates that if vertical extent is specified as an elevation, the verticalCRS xlink:href attribute value must be "http://www.spatialreference.org/ref/epsg/5714/" (replaces URN "urn:ogc:def:crs:EPSG::5714", this value may appear in older metadata); this is the VerticalCRS with origin at World mean sea level (MSL), with elevations measured up positive in meters(http://www.epsg-registry.org/). If vertical extent is specified using depth, the verticalCRS xlink:href attribute value must be an identifier for a well or depth sounding that can be dereferenced to get information on the borehole or sounding geometry.

 

 

3.3 Service identification elements (SV_ServiceIdentification)

Table 4. Service Identification properties (SV_ServiceIdentification). See discussion of the use of MD_DataIdentification and SV_ServiceIdentification preceding Table 3.

ISO 19115 and 19119 (M/C/O) xPath from MD_Metadata	NAP-USGIN M/C/O	Comments on SV_ServiceIdentification
Resource service citation (M) identificationInfo[1]/-SV_ServiceIdentification/-citation/CI_Citation	M-M	The citation attribute provides information for citing the described service. Note that for scientific citation purposes, a citation for the intellectual content of the information presented by the service would be found in the MD_DataIdentification/citation/CI_Citation for datasets identified in the operatesOn section of SV_ServiceIdentification. Citation is defined by Webster as "an act of quoting". For USGIN purposes, this should be viewed as information to identify the intellectual origin or authority for the content in the described resource, along the lines of a citation in a scientific journal. The purpose of the citation for the service is to identify a particular service instance as a unique entity. Required content for a CI_Citation element are title, date, and responsibleParty.
Resource title (M) identificationInfo[1]/-SV_ServiceIdentification/-citation/CI_Citation/title	M-M	USGIN recommends that the title in a service identification citation should uniquely identify the particular service instance, and inform the human reader about the service content, function, and context.
Resource reference date (M) identificationInfo/-SV_ServiceIdentification/-citation/CI_Citation/date/-CI_Date/date/	M-M	The citation date for a service may indicate the creation date, when the service first became operational, the publication date, when the service first became public, or the revision date, which specifies the date of most recent update. If the service is no longer online, a notAvailable or superseded date may be specified. The DateType attribute is used to specify the signficance of a reported date. This date is distinct from the dateStamp for the metadata record, or the EX_Extent/temporalElement that specifies the time period to which the resource content is applicable. The data type for the date element is xs:date, defined thus "date uses the date/time SevenPropertyModel, with ·hour·, ·minute·, and ·second· required to be absent. ·timezoneOffset· remains ·optional" (http://www.w3.org/TR/xmlschema11-2). Example date encoding: 2000-12-12+13:00, 2006-10-01. If the month or day is not known, encode as '01', for example '2006-01-01'. ISO CI_DateTypeCode names that apply to services include {creation, publication, revision}. See section 4.17.3 Codelists for details on codelist usage.
Unique resource identifier (O) identificationInfo/­SV_ServiceIdentification/­citation/CI_Citation/­identifier/­MD_Identifier	C-O	For USGIN, because the Citation is for the service, this identifier should be identical to MD_Metadata/dataSetURI, and is therefore optional. For USGIN purposes, this element content value is only an identifier for the citation; it is not a URL for accessing the service. The USGIN profile requires the use of MD_Identifier element to identify resources. RS_Identifier may substitute for MD_Identifier in the ISO19139 schema, but the USGIN profile requires use of MD_Identifer. If additional codespace and version content is associated with the identifier, it should be encoded as MD_Identifier/authority/CI_Citation/alternateTitle and MD_Identifier/authority/CI_Citation/edition
Resource responsible party (O) identificationInfo/-SV_ServiceIdentification/-citation/CI_Citation/-citedResponsibleParty	M-M	USGIN requires at least one CI_ResponsibleParty with a rule that count of (individualName + organisationName + positionName) > 0. For a service, the point of contact information for questions or reporting problems should be in SV_ServiceIdentification/pointOfContact/CI_ResponsibleParty. The service citation responsible party should identify the parties responsible for creating (implementing) and publishing the service. ISO Role code names applicable to a service citation include {originator, principal­Investigator, processor, author, publisher}. Other ISO codelist values {resourceProvider, custodian, owner} should be specified in the SV_ServiceIdentification/pointOfContact element. See section 4.17.3 Codelists for details on codelist usage.
Resource presentation form (O) identificationInfo/­SV_ServiceIdentification/­citation/CI_Citation/­presentationForm	O-O	The form in which the service is available, which in the case of a service is only through the service implementation described by the metadata record, so the information here is not generally very useful. This profile specifies no convention for its use. Note that the citation to the original source of intellectual content in the datasets operated on by the service should be in MD_DataIdentification/citation/CI_Citation elements that are the target of srv:operatesOn associations. presentationForm uses the CI_PresentationFormCode codelist; ISO code names that are applicable to a service citation include {documentDigital, imageDigital, mapDigital, modelDigital, profileDigital, tableDigital, videoDigital, audioDigital}. NAP adds {multimediaDigital, diagramDigital}. See section 4.17.3 Codelists for details on codelist usage.
Resource series (O) identificationInfo/-SV_ServiceIdentification/-citation/CI_Citation/series	O-O	Information about the series or collection of which the cited service is a part. NAP rule: (name + issueIdentification) > 0. At this point there is not much precedent for aggregating services into a formal series, so in general this element is probably not applicable to services. This profile specifies no convention for its use.
Resource other citation details (O) identificationInfo/-SV_ServiceIdentification/-citation/CI_Citation/-otherCitationDetails	O-O	Free text information useful to identify and cite the described service instance. This profile specifies no convention for its use.
Resource collective title (O) identificationInfo/­SV_ServiceIdentification/­citation/CI_Citation/­collective­Title	O-O	Free text title of a "combined resource of which the service is a part." At this point there is not much precedent for aggregating services into a collections, so in general this element is probably not applicable to services. This profile specifies no convention for its use.
Resource abstract (M) identificationInfo/-SV_ServiceIdentification/-abstract	M-M	A free text summary of the content, significance, purpose, scope, etc. of the service described by this metadata. Exactly one value.
Resource purpose (O) identificationInfo/-SV_ServiceIdentification/-purpose	O-O	Text summary of the intentions for which the service was developed, including objectives for creating the service and use cases it is designed to support. One value optional.
Resource status (O) identificationInfo/-SV_ServiceIdentification/-status	M-M	Value is from MD_ProgressCode codelist. ISO Code names applicable to services include {completed, obsolete, onGoing, planned, required, underDevelopment}. Obsolete is synonymous with deprecated for this profile. See section 4.17.3 Codelists for details on codelist usage.
Resource point of contact (O) identificationInfo/-SV_ServiceIdentification/-pointOfContact	O-OR	pointOfContact/CI_ResponsibleParty element for service metadata should contain information for a point of contact to report problems with the service. Element is optional but highly recommended! USGIN rule that count of (individualName + organisationName + positionName) > 0. The CI_ResponsibleParty/role/CI_RoleCode@codeListValue is from CI_RoleCode; applicable name for the point of contact party are from the ISO codelist {resourceProvider, custodian, owner}. Due to interoperability problems with NAP identifiers different from ISO identifiers for the same codelist elements, USGIN mandates use of ISO codelists. See section 4.17.3 Codelists for details on codelist usage.
Resource maintenance (O) identificationInfo/-SV_ServiceIdentification/-resourceMaintenance	O-O	This element provides information about the maintenance schedule or history of the service described by the metadata record. For a service, only one MD_MaintenanceInformation elements may be included; for which the MD_ScopeDescription MD_ScopeCode will be 'service'. If MD_MaintenanceInformation is present, then maintenanceAndUpdateFrequency is mandatatory, populated by a MantenanceFrequencyCode; ISO names in this codelist are {continual, daily, weekly, fortnightly, monthly, quarterly, biannually, annually, asNeeded, irregular, notPlanned, unknown}. See section 4.17.3 Codelists for details on codelist usage. USGIN recommends following the NAP-specified best practice that when SV_ServiceIdentification/­status is set to "onGoing," either the attribute MD_Maintenance­Information/­dateOfNextUpdate or MD_MaintenanceInformation/­user­Defined­Maintenance­Frequency must be provided. Maintenance information specific to particular data the service presents should be included in the dataset metadata for coupleResources associated with the service.
Graphic overview of resource (O) identificationInfo/­SV_ServiceIdentification/­graphicOverview	O-OR	Highly recommended to include a small image visual representation of the resource provided by a map or image service. For geographic feature or data services, a graphic overview might show the geographic distribution of available data. If MD_BrowseGraphic is included, MD_BrowseGraphic/filename character string is mandatory. USGIN Recommended practice is to provide a complete URL as a gco:characterString value for the filename property. Use napMD_FileFormatCode code values (http://www.fgdc.gov/nap/metadata/­register/codelists.html#IC_115) in fileType/CharacterString. See section 4.17.3 Codelists for details on encoding of the file format code, which is special because this is a NAP extension to the ISO base specification. Repeatable element; multiple values may present different resolutions, or different parts of resource. Names associated with overview should provide sufficient information for user to distinguish these.
Resource format (O) identificationInfo/­SV_ServiceIdentification/­resourceFormat	O-X	The format of service response documents varies at the operation level, and for a particular operation, different output formats may be requested. A listing of all possible options here without bindings to the operations that respond with that format is not useful.
Resource keywords (O) identificationInfo/-SV_ServiceIdentification/-descriptiveKeywords/MD_Keyword	O-O	Best Practice for USGIN profile metadata is to supply keywords to facilitate the discovery of metadata records relevant to the user. USGIN Keywords: USGIN keyword vocabularies are in development. Future versions of this profile may include required keyword vocabularies. Other Keywords: Keyword Type - allowed ISO values from MD_KeywordTypeCode: {discipline, place, stratum, temporal, theme}. See section 4.17.3 Codelists for details on codelist usage. MD_Keyword/keyword MUST contain a CharacterString element (see section 4.16); USGIN best practice is to include keywords in English.
Resource specific usage (O) identificationInfo/-SV_ServiceIdentification/-resourceSpecificUsage/	O-X	Property not used by USGIN. Content may be ignored by clients.
Condition applying to access and use of resource (O) identificationInfo/­SV_ServiceIdentification/­resourceConstraints/	O-O	Information specifying restrictions on the access to and use of the described service. Constraints may be represented by MD_Constraint, MD_LegalConstraint, or MD_SecurityConstraint. The attribute MD_Constraint/useLimitation is mandatory unless MD_Legal­Constraint or MD_SecurityConstraint is provided. ISO19119 duplicates this property as SV_Service­Identification/­restrictions. Follow NAP specification that SV_ServiceIden­tification/­resourceConstraints is to be used, and SV_ServiceIdentification/restrictions is not to be used. The metadataConstraints may allow a user to learn of the existence of a resource that they may not actually be able to access without further clearance.
Aggregation information (O) identificationInfo/­SV_ServiceIdentification/­aggregationInfo/­MD_AggregateInformation	O-O	This element includes either a citation for or identifier of an associated service or dataset, along with the type of association, and optionally the activity that produced the dataset. MD_AggregateInformation requires either aggregateDataSetName/CI_Citation or aggregateData­Set­Identifier/­MD_Identifier. associationType is mandatory, from DS_AssociationTypeCode. ISO code names deemed applicable to service aggregation by this profile are {crossReference, largerWorkCitation, source, }. See section 4.17.3 Codelists for details on codelist usage. Aggregation might be used to associate metadata for individual layers with metadata for a service that provides a collection of layers (largerWorkCitation), to cross reference services that can be chained, or to identify a resource that provides input to a service. If the related resource has an associated metadata record, USGIN recommended practice is to include the identifier for that metadata record in aggregateDataSetIdentifier/MD_Identifier. For related resources that do not have a metadata record, aggregateDataSetName/CI_Citation may be used; this element is optional if aggregateDataSetIdentifier has a value. For USGIN profile, this property, rather than MD_Metadata/parent­Identifier, should be used to indicate relationships between described resources. No testing has been done on use of this element, or examples found for actual usage.
Resource service type (M) identificationInfo/­SV_ServiceIdentification/­serviceType	M-M	Exactly one value required. USGIN mandates use of a LocalName value (http://schemas.opengis.net/iso/­19139/20060504/­srv/service­Metadata.xsd allows either localName or ScopedName). There is not as yet a standard registry of service types and identifiers that can serve as an authority for serviceTypes. An interim list of service types and identifiers is included in section 7.1 ServiceType (with the ad hoc codespace URI 'http://resources.usgin.org/registry/serviceType201001'). Valid values for OGC services are {WMS, WFS, WCS, CSW, ...} Example: <srv:serviceType> <gco:LocalName codeSpace= "http://resources.usgin.org/registry/serviceType201001">WMS</gco:LocalName> </srv:serviceType>
Resource service type version (O) identificationInfo/-SV_ServiceIdentification/-serviceTypeVersion	O-C	Multiple serviceTypeVersion tags may not be implemented in some harvesting server applications - USGIN recommends a reverse chronological order for supported versions. Constraint: if various versions are available, it is mandatory to list versions that are supported. Default is oldest version of service.
Resource service access properties (O) identificationInfo/-SV_ServiceIdentification/-accessProperties	O-O	Optional MD_StandardOrderProcess element to provide information on the availability of the service which include: fees, available date and time, ordering instructions, turnaround. Ordering instructions and turnaround are not applicable to web services.
Resource service restrictions (O) identificationInfo/-SV_ServiceIdentification/-restrictions	O-X	Not used by USGIN; use resourceConstraints as per NAP.
Keywords (O) identificationInfo/-SV_ServiceIdentification/-keywords	O-X	Not used by USGIN; use descriptiveKeywords as per NAP
Resource service content extent (O) identificationInfo/-SV_ServiceIdentification/-extent/EX_Extent	C-C	Defines the spatial (horizontal and vertical) and temporal region to which resources offered by the service apply. USGIN requires. Best Practice for USGIN is to include a geographic bounding box that specifies the extent to which resource content applies for any resource related to some geographic location. For geoscience resources, the temporal extent may be expressed using time ordinal eras from a geologic time scale if the resource is related to some particular geologic time. USGIN specifies count(description + geographicElement + temporal­Element) >0
Resource service content extent description ( ) identificationInfo/-SV_ServiceIdentification/-extent/EX_Extent/description	C-C	Free text that describes the spatial and temporal extent of the dataset. USGIN specifies that description is mandatory if a geographicElement or temporalElement is not provided. If geographic place names are used to express the geographic extent they MUST be encoded using keywords with keyword type code = 'place'. Geographic names may be duplicated in the EX_Extent/description.
Resource service content extent bounding box ( ) identificationInfo/-SV_ServiceIdentification/-extent/EX_Extent/-geographicElement/-EX_GeographicBoundingBox	O-C	USGIN profile requires that if an EX_Extent/geographicElement is supplied, it include a geographic bounding box with bounding latitude and longitude expressed using WGS 84 decimal degrees. The corner coordinates for the geographic bounding box must not coincide in one point, because this may result in fatal errors with some CSW implementations. Point locations must thus be represented as tiny rectangles. USGIN recommended practice is to place the actual point location in the lower left corner of the rectangle.
Resource service content extent geographic description ( ) identificationInfo/­SV_ServiceIdentification/­extent/EX_Extent/­geographic­Element/­EX_Geographic­Description	C-X	Not used by USGIN profile, use keyword with type code = 'place'. For USGIN metadata, this information should be encoded using keywords, for which the MD_KeywordTypeCode = 'place'; the thesaurus/CI_Citation has the same content as EX_GeographicDescription/­authority/­CI_Citation, and the keyword is the same as the EX_GeographicDescription/code.
Resource service content extent bounding polygon ( ) identificationInfo/­SV_ServiceIdentification/­extent/EX_Extent/-geographicElement/-EX_BoundingPolygon	C-X	To improve interoperability, USGIN mandates use of Geographic Bounding Box; bounding polygons may be present, but may be ignored by harvesters.
Resource service temporal extent (O) identificationInfo/­SV_ServiceIdentification/­extent/EX_Extent/temporal­Element/EX_TemporalExtent/­extent/TimePeriod	O-O	Information specifying the temporal extent to which resource is applicable. For many geoscience resources, this would be the geologic time period(s) to which the resource applies. Although the ISO19139 xml schema allows temporal extents to be instants, intervals, or ordered eras, TimePeriod MUST be used for temporal extent in USGIN profile metadata in order to make metadata interoperable. Values for beginPosition@frame and endPosition@frame MUST be populated if a temporal extent is provided. The default frame property value is "#ISO-8601", for standard calendar date and time. For geologic time extents, USGIN requires the values for beginPosition@frame and endPosition@frame to be populated using numeric time coordinates in Ma, measured positive increasing older with an origin at 1950 CE (see Temporal extents). The default frame attribute value for geologic time coordinates is "urn:cgi:trs:CGI:StandardGeologicTimeMa". See section 4.21, below.
Resource service spatio-temporal extent (O) identificationInfo/­SV_ServiceIdentification/­extent/EX_Extent/­temporalElement/­EX_SpatialTemporalExtent/	O-X	Although use of EX_SpatialTemporalExtent is allowed by ISO19139 and NAP, USGIN best practice is to encode space time location with EX_TemporalExtent and EX_GeographicBounding­Box. Other optional extent elements may be included, but they may be ignored by client implementations processing the metadata document.
Resource service vertical extent (O) identificationInfo/-SV_ServiceIdentification/-extent/EX_Extent/-verticalElement/-EX_VerticalExtent	O-O	Vertical extent is used to describe the elevation location of resources offered by the described service instance, if applicable. Common geoscience examples are resources related to vertical location in a borehole or depth in a water body. The borehole trace is the vertical coordinate reference system (CRS) within which described resources are located using coordinates measured in linear distance from the collar (or ground level, or Kelly bushing) of the borehole. EX_VerticalExtent has minimumValue, maximumValue that are real numbers, and a verticalCRS. For interoperability, USGIN mandates that if vertical extent is specified as an elevation, the verticalCRS xlink:href attribute value must be "http://www.spatialreference.org/ref/epsg/5714/"; this is the VerticalCRS with origin at World mean sea level (MSL), with elevations measured up positive in meters (http://www.epsg-registry.org/). If vertical extent is specified using depth, the verticalCRS xlink:href attribute value must be an identifier for a well or depth sounding that can be dereferenced to get information on the borehole or sounding geometry. In the absence of other information, reported depths should be assumed to be true vertical depth relative to the mean elevation of the geographic extent reported for the resource. In the absence of other information, reported depths should be assumed to be true vertical depth relative to the mean elevation of the geographic extent reported for the resource.
Coupled Resource ( ) identificationInfo/-SV_ServiceIdentification/-coupledResource	O-O	This element correlates operations (identified by operationName) with datasets (identified by identifier). For logical consistenty, and SV_coupledResource/identifier values should be equal to MD_DataIdentification/citation/CI_Citation/­identifier/­MD_Identifier/­code for a dataset that is the target of a SV_ServiceIdentification/operatesOn element (either in an inline MD_DataIdentification/citation../code element, or a @uuidref attribute). This element is necessary to implement the many-to-many relationship between data sources and operations in a single service.
Coupled Resource operation name (M) identificationInfo/-SV_ServiceIdentification/-coupledResource/-SV_CoupledResource/-operationName	M-C	Mandatory if operations are specific to particular coupled resources. String, the name of the service operation: GetMap, GetFeature, etc. There is no internal check in the metadata record that the given operation name is valid.
Coupled Resource identifier (M) identificationInfo/-SV_ServiceIdentification/-coupledResource/­SV_CoupledResource/identifier	M-C	Mandatory in service metadata record if coupling type is tight or mixed. Identifier of a given tightly coupled dataset. Equal to MD_DataIdentification/citation/CI_Citation/ identifier/MD_Identifier/code for a dataset that is the target of a SV_ServiceIdentification/­operatesOn element (either in an inline MD_DataIdentification/citation../code element, or a @uuidref attribute).
Coupled Resource scoped name (X) identificationInfo/-SV_ServiceIdentification/-coupledResource/­SV_CoupledResource/ScopedName	X-O	OGC 07-045 application profile for ISO metadata using CSW 2.0.2 extends SV_CoupledResource with a ScopedName, defined as a scoped identifier of the resource in the context of the given service instance (e.g. layer name or featureTypeName). This is necessary for users to generate service requests (like GetMap or GetFeature) based on ISO service metadata.
Service coupling type (M) identificationInfo/-SV_ServiceIdentification/-couplingType	M-M	Type of coupling between service and associated data, if applicable. Codelist values used by USGIN: loose - Service instance is not associated with a specific dataset or datasetcollection. Loosely coupled services may have an association with data types through the service type definition; no MD_DataIdentification class has to be described. mixed - Service instance is associated with a specific dataset or dataset collection, but this can also be used with external data (i.e. data that is not described by the operatesOn association). MD_DataIdentification describes the associated data instance. tight - Service instance only operates with specific data; MD_DataIdentification element MUST be provided for the coupled data.
Service operations (M) identificationInfo/-SV_ServiceIdentification/-containsOperations	M-M	This element describes operations performed by the service, but the ISO19119 model includes insufficient detail to completely describe all parameters necessary to automate connection to a service. Widely used xml formats exist to describe service function, including OGC getCapabilities.xml and W3C Web Service Description Language (WSDL). srv:containsOperations is a required element in a valid SV_ServiceIdentification element instance. At least one service operation MUST be described with the operationDescription/­Character­String = 'serviceDescription'. The identificationInfo/SV_ServiceIden­tification/­contains­Operations/­­SV_OperationMetadata/­connectpoint link for this operation MUST retrieve the service-specific self description document (e.g. WSDL, GetCapabilities, WADL).
Service operation name (M) identificationInfo/-SV_ServiceIdentification/-containsOperations/-SV_OperationMetadata/-operationName	M-M	Operation name following convention of the described service; mandatory instance is associated with SV_OperationMetadata element with the operationDescription/­Character­String = 'serviceDescription'.
Service operation distributed computing platforms (M) identificationInfo/-SV_ServiceIdentification/-containsOperations/-SV_OperationMetadata/DCP	M-M	mandatory instance is associated with SV_OperationMetadata element with the operationDescription/­Character­String = 'serviceDescription'. USGIN profile makes no provision for use of this element.
Service operation description (O) identificationInfo/-SV_ServiceIdentification/-containsOperations/-SV_OperationMetadata/-operationDescription	O-M	mandatory instance is associated with SV_OperationMetadata element with the operationDescription/­Character­String = 'serviceDescription'.
Service operation invocation name (O) identificationInfo/-SV_ServiceIdentification/-containsOperations/-SV_OperationMetadata/-invocationName	O-O	service instance specific string to use in requests to invoke an operation.
Service operation online resource (M) identificationInfo/-SV_ServiceIdentification/-containsOperations/-SV_OperationMetadata/-connectpoint	M-C	For loosely coupled services, operations and endpoints need to be described. A service information endpoint (CI_OnlineResource) that returns a service self description document MUST always be provded. The CI_OnlineResource/linkage URL should be a complete request if a single http GET request is sufficient. If the request requires special headers, or message package, or does not use standard web protocols, the CI_OnlineResource/description MUST provide instructions for executing the request.
Service operates on (O) identificationInfo/-SV_ServiceIdentification/-operatesOn	O-C	"Provides information on the datasets that the service operates on" (ISO 19119). If SV_ServiceIdentification/-couplingType is 'tight' or 'mixed', then operatesOn elements must include a valid MD_DataIdentification element inline or by @uuidref attribute value that explicitly links to an existing dataset metadata record that describes the coupled dataset. The value of SV_ServiceIdentification/operatesOn@uuidref or SV_ServiceIdentification/operatesOn/­MD_Data­Iden­tification/citation/CI_Citation/identifier/MD_Identifier/code must correspond to one of the SV_ServiceIdentification/coupledResource/MD_CoupledResource/identifier values. If the metadata record for the coupled dataset is a separate gmd:MD_Metadata record, the service described in the service metadata record should be identified as a distribution for the dataset. Explicitly linked reference example: <srv:operatesOn uuidref="13ce1e84-c887-4fd8-b888-8d021b1fa4c2" xlink:href=http://resources.azgs.org/geonetwork/srv/en/metadata.show?id=8717 xlink:title="azgs:azgeochron"/>

4       Usage notes for Metadata Elements

This section presents additional information and discussion to supplement that in Table 2, Table 3, and Table 4.

4.1 Metadata file identifier

MD_Metadata/fileIdentifier is unique identifier for the metadata file. Some metadata profiles suggest that the metadata file identifier ID should be the same as the ID for the described resource. In the USGIN scheme, the metadata record is considered a separate resource, with a distinct identifier, from the resource it describes. The described resource identifier is the Unique resource identifier (DatasetURI, 4.8, below).

4.2 Metadata hierarchy

The ISO19115 specification (especially Annex H) discusses the use of metadata hierarchy, in which a resource may inherit metadata properties from parent metadata records in the hierarchy. For example a dataset in a dataset series might inherit all of the metadata content from the parent dataset series metadata record, except for dataset-specific data quality metadata. The linkage would be made through MD_Metadata/parentIdentifier. This kind of nesting, effectively database normalization, makes sense in a data management environment, but in a discovery environment, it present problems. Many queries would require joins with the parent metadata record, and software clients would be required to navigate the parent links to acquire 'inherited' properties from 'parent' records. For catalog service purposes, USGIN mandates that in metadata records returned by services, all inherited properties in such a hierarchy should be included explicitly in the metadata document, as opposed to implicitly through the parentIdentifier link. Internal document links may be used where allowed by the xml schema for identified elements repeated in a single response document. Resolvable xlink:href links to external resource are technically possible, but require that client software is xlink-aware, which is not always the case.

4.3 Metadata Contact vs. Resource Citation vs. Resource Contact

There are various locations to store contact information within an ISO 19139 metadata record. Here is a summary of the required contact properties and their significance as it pertains to the USGIN Profile.

• MD_Metadata/contact/CI_ResponsibleParty or "metadata point of contact" describes how to contact the party responsible for the metadata record to allow users to report errors, updates to metadata etc. The mandatory CI_RoleCode is set to "pointOfContact".
• MD_Metadata/identificationInfo/[MD_DataIdentification || SV_ServiceIdentification]/­citation/CI_Citation/citedResponsibleParty/CI_ResponsiblerParty provides information to identify the intellectual origin of the content in the described resource. This is straight forward when citing library resources (books, journals, etc.) but less clear when defining the intellectual origin of, for example, physical samples. The mandatory CI_RoleCode is set to one of the ISO codelist values {custodian, owner, distributor, originator, pointOfContact, principalInvestigator, publisher, author}.
• MD_Metadata/identificationInfo/[MD_DataIdentification || SV_ServiceIdentification]/­pointOfContact/CI_ResponsibleParty or "resource point of contact" contains information on who to contact to access the described resource. The mandatory CI_RoleCode is set to one of the ISO codelist values {resourceProvider, custodian, owner, user, distributor, originator, pointOfContact, principalInvestigator, processor, publisher, author}.

Additional contact information in the distribution section of the metadata provides point of contact for individual distribution processes to report problems with access to resources via different distributions.

4.4 Resource Title

Resource titles should provide sufficient information to distinguish the resource from other similar resources. They are not required to be globally unique, but bear in mind that users will be presented only with the resource title in typical brief search response documents. It is thus a disservice to have significant duplication of title strings or uninformative titles.

4.5 Resource Abstract

Ideally the resource abstract provides a succinct summary of the content of the resource, the purpose for which it was originally created, some indication of important quality parameters to help evaluate fitness for other purposes, any significant constraints on use of the resource, and a list of distribution options. After reading the abstract a user should have a good idea of whether the described resource contains the information they need and is accessible in a fashion that they can use.

4.6 Resource Type

The ISO 19115 MD_Metadata/hierarchyLevel property provides a high level categorization of resource types. The European INSPIRE Implementing Rules (MD_IR_and_ISO_20090218) proscribes the code list for the first hierarchyLevel xml element in an MD_Metadata document to be one of {dataset, service, series}, or the metadata set will be considered out of scope for the directive. Thus, metadata meant to be utilized by INSPIRE catalogs must follow this rule. The full ISO MD_ScopeCode list has a wider (and more useful) variety of resource categories; one or more hierarchyLevel elements using these codes could follow the first one with an INSPIRE-valid code in the first element to maintain INSPIRE compliance.

Table 1 in this document includes a more geoscience-domain-specific list of resource types, and values from this list should be used in one or more hierarchyLevelName elements. To enable resource-category-type searches to find narrower subcategories without complex query processing, hierarchyLevelName elements for the resource type and all broader/more general resource type categories should be included. The hierarchical categorization of the resources is encoded with the most specific category first, and progressively broader categories listed subsequently. Thus, harvesters that only take the first hierarchy­LevelName element will get the most specific value. For example, if the resource is a photograph:

<gmd:hierarchyLevelName>

<gco:CharacterString>Photograph</gco:CharacterString>

</gmd:hierarchyLevelName>

<gmd:hierarchyLevelName>

<gco:CharacterString>StillImage</gco:CharacterString>

</gmd:hierarchyLevelName>

<gmd:hierarchyLevelName>

<gco:CharacterString>Image</gco:CharacterString>

</gmd:hierarchyLevelName>

<gmd:hierarchyLevelName>

<gco:CharacterString>Document</gco:CharacterString>

</gmd:hierarchyLevelName>

Note that the distinction of resource type and format is not always clear. Table 1 attempts to define resource types that are not specifically bound to a particular format, but are defined based on the kind of content. Format is interpreted as relating to specific approaches to encoding content and committing it to some sort of media.

4.7 Resource Locator

URL's for online access to resources are encoded in USGIN ISO 19139 metadata documents in the element MD_Distribution/transferOptions/MD_DigitalTransferOptions/­online/CI_Online­Resource. Consistent use of this rule eliminates ambiguity on where to locate the URL to access a resource. Conventions for use of the CI_OnlineResource subelements protocol, applicationProfile, name, description, and function to enable metadata clients to reliably access referenced resources are discussed in section 4.15 CI_OnlineResource.

4.8 Unique Resource Identifier

The MD_Metadata/DataSetURI property should be a globally unique identifier for the described resource. The protocol used for this identifier is not specified by the USGIN Profile, but if it does not have a know resolution service, the capabilities document for a CSW service providing the metadata should have at least a text explanation of how to resolve URI's used by the service. Protocols with available resolvers include http (use the WWW DNS system) and doi (http://dx.doi.org/). Some authorities using urn: protocols are also implementing or have resolver services in place.

4.9 Browse Graphics

Links to browse graphics are useful to assist users evaluate resources that have a graphical aspect. The MD_BrowseGraphic element includes a fileType attribute that is important to inform client software accessing and displaying the graphic. For the USGIN profile, use standard MIME types in the gmd:fileType/gco:CharacterString. See the official Internet Assigned Numbers Authority (IANA) Mime Media Type registry at http://www.iana.org/assignments/media-types for a list of registered MIME types and their scope.

<gmd:MD_BrowseGraphic>

<gmd:fileName>

<gco:CharacterString>http://publicdocs.mnr.gov.on.ca/View.asp?­Document_ID=9632&Attachment_ID=18204</gco:CharacterString>

</gmd:fileName>

<gmd:fileDescription>

<gco:CharacterString>Base Map from OMNR</gco:CharacterString>

</gmd:fileDescription>

<gmd:fileType> <!-- This is a MIME Type --> <gco:CharacterString>image/jpg</gco:CharacterString>

</gmd:fileType>

</gmd:MD_BrowseGraphic>

Code example 1. Encoding url, display name and file type for browse graphic.

4.10 Resolution and equivalentScale

For spatial datasets, some indication of the resolution of the data is very useful for evaluating fitness for use. From a data perspective, resolution in a spatial dataset specifies the the smallest resolvable distance between two points in the Earth for that dataset. For a grid or coverage, this would be the average distance between sample points. From data portrayal perspective, an equivalentScale is reported, representing the scale at which the portrayal was intended to be viewed when it was constructed. If the spatial representation type code is vector, grid, textTable or tin, an equivalentScale/../denominator MUST be provided to express spatial resolution. This is an arbitrary convention adopted to facilitate interoperablity. If a equivalentScale/../distance is available, that should be supplied as well. To calculate equivalentScale given a resolution distance, recommended practice is to divide the resolution distance in meters by 0.0005. This assumes that the smallest visually resolvable distance in a map display for human usage is 0.5 mm.

4.11 Resource Language

USGIN metadata is assumed to use American English and metadata documents should be returned in that language. The ISO 19139 XML includes elements and provisions to implement multiple languages in a single metadata package using PT_Text and LocalizedCharacterString, but in order to avoid complexity with USGIN recommended practice is to implement metadata search for different languages as different services. Each service would provide CharacterStrings in the same, single language, specified by the MD_Metadata/language element in returned metadata records.

4.12 Encoding of Vertical Extents

EX_VerticalExtent has minimumValue, maximumValue that are real numbers, and a verticalCRS. The vertical coordinate reference system (CRS) specifies how the bounds of the vertical extent are georeferenced. The USGIN profile accepts two approaches. Elevation is reported with reference to Earth mean sea level, measured positive upward. On the other hand, subsurface or subaqueous data are typically referenced relative to a borehole trace or sounding, measured positive downward from a local datum at the borehole or sounding orgin. The origin is typically a borehole collar at the ground surface, the Kelly bushing or drill floor on a drilling rig, or a ship deck., For to facilitate interoperability.

For interoperability, USGIN mandates that both elevation and depth vertical extent bounds MUST be specified in meters. In addition, if vertical extent is specified as an elevation, the verticalCRS xlink:href attribute value MUST be "http://www.spatialreference.org/ref/epsg/5714/"; this is the VerticalCRS with origin at World mean sea level (MSL), with elevations measured up positive in meters (http://www.epsg-registry.org/). If vertical extent is specified using depth, the verticalCRS xlink:href attribute value must be an identifier for a well or depth sounding that can be dereferenced to get information on the borehole or sounding geometry.

4.13 Content information: Entities and Attributes

One of the major deficiencies of the ISO 19115/19139 specifications is the absence of model elements to describe the entities and attributes in standard tabular datasets. Description of dataset schema using the ISO Technical Committee 211 (TC211) framework requires use of ISO19110. A standard XML schema for implementing this specification has recently become available, and entity-attribute metadata for dataset should be documented using the schemas located at http://www.isotc211.org/2005/gfc/gfc.xsd. The ISO19139 XML implementation of ISO19115 does not allow inclusion of the feature catalog inside the metadata record, but provides a citation element in the gmd:contentInfo/gmd:MD_Feature­CatalogueDescription element. The USGIN profile provision is to link to the feature catalog using an xlink:href attribute on the gmd:featureCatalogueCitation, identified as such by an accompanying xlink:title attribute with the value "Link to ISO19110 feature catalog". Code Example 2 shows recommended encoding. Section 8.4, ISO19110 Feature Catalog example, provides an example encoding of entity-attribute information for a feature dataset.

<gmd:contentInfo>
<gmd:MD_FeatureCatalogueDescription>
<gmd:includedWithDataset>
<!-- true if a FeatureCatalog document is packaged with the dataset -->
<gco:Boolean>false</gco:Boolean>
</gmd:includedWithDataset>

<!-- a dataset may contain multiple feature types. For an MS Access type database, each table could be considered a featue type -->
<gmd:featureTypes>
<!-- the codespace is the namespace URI, should dereference to obtain XML schema (if applicable)-->
<gco:LocalName codeSpace=" http://xmlns.geosciml.org/geosciml-portrayal/2.0">GeologicContact_2</gco:LocalName>
</gmd:featureTypes>
<!-- follow pattern used by Stanford library http://opengeoportal.org/­archives/­category/­uncategorized); href is to an ISO19110 feature catalog,
with featuretype identified by fragment ID -->
<gmd:featureCatalogueCitation xlink:href=" http://schemas.usgin.org/featurecatalog/12.xml#geologiccontact"
xlink:title="Link to ISO19110 feature catalog"/> </gmd:MD_FeatureCatalogueDescription>

</gmd:contentInfo>

Code Example 2. Encoding of feature catalog link for entity attribute description of datasets. See 8.4 ISO19110 Feature Catalog example for and example instance document.

4.14 Use of MD_Distribution and MD_Distributor

The ISO19115 model provides two possible paths for specifying information about how a user can access the resource. The MD_Distribution element may have 0 to many distributionFormat, distributor, and transferOptions child elements (see Figure 1). On the other hand, each of the distributor child elements may have 0 to many distributorFormat and distributor­Trans­ferOption elements. Several major existing applications that consume ISO19139 xml metadata files are configured to expect format and transfer option information to be at the MD_Distribution/­distribution­Format and MD_Distribution/­trans­fer­Options path. This works fine as long as there are not different format or transfer options from different distributors, or different transfer options for different formats. In these cases, a binding between distributor, format, and transfer options necessitates use of the MD_Distribution/­distributor/­MD_Dis­tributor path to distributorFormat and distributor­Trans­ferOptions (and distributionOrderProcess) information that works together.

In order to accommodate both existing applications that utilize content in the MD_Distribution/­dis­tributionFormat and MD_Distribution/transferOptions elements, and situations that require binding between distributor, order process, format, and transfer options, the USGIN profile mandates that if multiple MD_Distribution/distributionFormat or MD_Distribution/transferOptions elements are included in a document, all formats must be available via all the specified transfer options, and the content of these elements should be included in line. If multiple MD_Distri­bution/­distributor elements are present, without child MD_Distributor/distributorFormat or MD_Distributor/­dis­tributor­TransferOptions elements, then all formats and transfer options are available from all distributors.

To specify different bindings between distributor, order process, format, and transfer options, a separate MD_Distribution/distributor/MD_Distributor instance is included for each binding. At least one MD_Distribution/­dis­tributionFormat and one MD_Distribution/transferOptions element MUST be included for applications that expect content in these elements, and the format and transfer options specified by these elements should apply to the first distributor/MD_Distributor element. Repeated CI_ResponsibleParty, MD_StandardOrderProcess, MD_Format or MD_DigitalTransferOption elements in the distributor/MD_Distributor elements should be specified by reference (xlink:href to gml:id of first occurrence of the element within the document). The implication is that the distributionOrderProcess/­MD_StandardOrderProcess, distributorFormat/MD_Format, and distributorTransferOptions/­MD_Digital­TransferOptions child elements of a single MD_Distributor are all compatible with each other. Following this convention will produce schema valid metadata, and the distributor elements after the first can be ignored by applications expecting only a single distributor element.

In summary, for the USGIN profile, each distributor/MD_Distributor is a binding between one or more transfer options and the distributor formats that are available through that/those transfer options (MD_DigitalTransfer­Options/­onLine/CI_Online­Resource in particular). If different formats are available from the same distributor, but have different transfer options, these should be represented as different distributor/­MD_Distributor instances.

 

Figure 1. gmd:MD_Distribution_Type diagram

4.15 Distribution Format

If the resource distribution is a physical object, like a book, rock sample, paper document, the distribution/../MD_Format/name MUST be a term from the USGIN distribution format codelist (see Table 6). Note that format is partially orthogonal from resource type (Table 1). A document may be available in various digital (pdf, tiff, doc, txt) or non-digital (book, loose sheets) formats.

4.15.1 Digital resources

The format vocabulary needs to be designed to work in the framework of the distribution/../­MD_DigitalTransferOptions, which provides protocol, applicationProfile, name, and function subelements for online resources (CI_OnlineResource), and MD_MediumNameCode and MD_Medium­FormatCode for offline electronic resources (MD_Medium). For digital resources it provides terms to specify file-format information that does not have any other obvious home. Examples in INCITS 453, INSPIRE 19115/19, and ANZLIC 2007 populate MD_Format/name with values like 'ESRI ARC/INFO Coverage', 'ESRI shapefile', 'ESRI ARC/INFO Export e00', and 'MapInfo MID/MIF' all pertain to digital resources. If a MIME format (http://www.iana.org/assignments/media-types/) is defined for a digital file format, the MIME media-type code should be used. If no appropriate MIME type is registered with IANA, USGIN mandates that the distribution format for digital resources should specify the file format using a pattern that includes vendor, application name, and file extension.

Pattern for digital resources: [vendor:applicationName]/fileExtension. The vendor and application names may not be applicable, and could be omitted, but the '/' and file extension should always be present. If the format consists of a single file, the file extension is a three letter file-type abbreviation assigned by the vendor. If the format consists of a package of files (e.g. an ArcGIS file geodatabase), the file extension is a name that in most cases should be obvious from vendor usage. The accompanying MD_Format/version value should indicate the version of application software if the format is specific to some version.

Service metadata describes a service as a resource, in which case distribution is effectively equivalent to the set of operations accessible at the service instance endpoint. The ISO 19119 service metadata model does not provide a clear way to associate individual operation responses with possible output formats for those responses. If all output formats are applicable to all service requests, they can be listed in distributioninfo as a collection of distributionFormat/MD_Format elements, but this is not a general solution. Another approach (e.g. GeoNetwork OpenSource, v. 2.4) to documenting output formats is to put format information in a collection of srv:connectPoint/CI_OnlineResource/protocol elements, with connectPoint elements for each format available on each operation. The USGIN profile convention is that operation metadata is best conveyed to metadata consumers by providing a link to a service-specific description file (getCapabilities or WSDL, see 4.22 Operation metadata), and this MUST be provided in a service metadata record by a SV_OperationMetadata element with an operationDescription value of 'serviceDescription'. The output formats offered by the service should be listed in a distributionInfo element as a collection of distributionFormat/MD_Format elements if all formats are applicable to all service requests, or if the mapping between requests and formats is obvious. Encoding of the format name should use whatever convention is used by the service to specify that output format in requests made to the service.

Table 5. Example format strings for digital files. These are to be used only if an appropriate MIME type is not defined.

4.15.2 Non digital resources

The MD_Format element is the only format information for resources that do not have digital transfer options, and USGIN proposes Table 6 as a vocabulary for use to specify format of non-digital resources. Although this codelist could be implemented as a schema extension, for the time being we propose to use it as a controlled vocabulary specified by profile and practice, rather than schema. Use of such controlled vocabulary can be indicated by using xsi:type on the gco:characterString element to make the type gml:CodeType, which then requires a codeSpace attribute. The distribution format Identifier from Table 6 should be used as the element value. Example encoding:

<gmd:MD_Format>

<gmd:name>

<gco:CharacterString xsi:type="gml:CodeType" codeSpace="http://resources.usgin.org/registry/distributionFormatNames201001">
sample:core</gco:CharacterString>

</gmd:name>

<gmd:version nilReason="notapplicable"/>

<gmd:MD_Format>

 

 

Table 6. USGIN Distribution formats for non digital resources. URI for this codelist is http://resources.usgin.org/registry/distributionFormatNames201001

4.16 CI_OnlineResource

The CI_OnlineResource element is used in a variety of contexts in ISO19115 content (see Table 7). This complex-content-element provides a linkage to some online resource related to the metadata or the described context resource. It is thus analogous to atom:link (IETF RFC-4287) or the link element described in IETF RFC-5988. For links that locate online documents accessible using standard browser and file type resolution technology, the link can be as simple as a single URL element that retrieves a representation of the resource. There are many other kinds of related resources that the onlineResource element may point to, including web services that provide access to a dataset resource, metadata for related or source resources, specifications for standards or extensions to standards.

Table 7. Contexts for CI_OnlineResource elements

Context	usage
contactInfo/onlineResource	Link to online resource to assist contacting a referenced individual or organization.
distributionInfo/transferOptions	link to a representation of the resource that is the subject of the metadata record
metadataExtension	link to document describing specifications for elements and attributes extending the base standard.

For the USGIN, it is desired that such links are accompanied by sufficient description that the linked resource can be accessed and provided to the metadata user automatically, with little or no operator intervention other than clicking on a link in a presentation of the metadata. A content specification for such machine-actionable links is discussed in a separate USGIN discussion paper (current version). This approach essentially considers the metadata as a sort of hypermedia in which the CI_OnlineResource elements define the 'affordances', or actions that are available to a client.

The CI_OnlineResource element contains 6 child elements. The only required content is a URL that will access the online resource. All other properties are optional. The protocol, applicationProfile, name and description properties are all free text with loosely defined semantics as indicated by the element names.

4.16.1 CI_OnlineResource protocol

Since the base level web locator scheme (ftp, http) is indicated by the prefix of the URL (IETF RFC 1738), USGIN metadata uses the protocol attribute to specify a higher-level protocol in the network stack, e.g. a serviceType for data accessed through remote-procedure-call-on-HTTP type services.

4.16.2 CI_OnlineResource applicationProfile

The use of applicationProfile for file-based resources accessed via URL is discussed in Table 2. For links to documents for which the service type (encoded in the CI_OnlineResource/protocol property) and base protocol prefix in the CI_OnlineResource/link URL (e.g. 'http:') do not provide sufficient information to guide client software, the applicationProfile property is used to indicate a profile on the serviceType or some variation in document encoding or content conventions. For example WFS services may offer different features in different namespaces or encoding schemes, a catalog may offer different metadata encoding, or a resource-oriented service may offer representations using different encoding schemes. The same scheme may be used with different conventions, for instance different profiles for the use of ISO19139 or csw:record XML metadata encoding. RDF representations may be offered in XML, Turtle, or N3 encoding. Although these variations may be deducible using content negotiation or by accessing and parsing a service description document, much simple client logic is possible if the information is provided up front with the link. The actual string value that should be provided to specify an application profile should be defined by the agent originating the profile.

4.16.3 CI_OnlineResource name and description

In order to provide further clarity and guidance for the utilization of linked resources USGIN recommends use of the CI_OnlineResource/name property as indicated in Table 13. In order to identify the linkage element that locates the service description document (see 4.22 Operation metadata), USGIN mandates using CI_OnlineResource/name = "serviceDescription" in the CI_OnlineResource element with the linkage to the service description. The assumption is that any client that can connect to the service will know what to expect as the service description provided by that service.

The description property may be used to provide information about the online resource, and more usefully, to provide an explanation of how the other content of the CI_OnlineResource element is to be used to access the resource. The linkage/description should provide any necessary additional information in a text narrative as well. In some cases the protocol, applicationProfile and name properties may be insufficient to enable machine access to the resource through the provided link. The CI_OnlineResource/description element may include key values pairs to provide additional necessary information. USGIN recommendataion is to encode these in a 'parameter' object using JSON syntax. The parameters value is a list of key:value pairs enclosed in curly brackets ('{key:"value", key1:"value1"...}'). The keys should be the exact string that is required for the data access request parameter. For example, a dataset distributed through a particular layer in a multi-layer WMS:

<gmd:description>

<gco:CharacterString>

Whatever descriptive text you want.

parameters:{layers:"gtp_datagap_well_data_collection"}

</gco:CharacterString>

</gmd:description>

In the case of a dataset distributed through a particular feature type in a multi-feature WFS:

<gmd:description>

<gco:CharacterString>

Whatever descriptive text you want.

parameters:{ typeName:"BoreholeLithInterval2.0"}

</gco:CharacterString>

</gmd:description>

 

4.16.4 CI_OnlineResource function property

The function property is populated from a codelist (see Table 8) and is used to indicate the expected action that actuating the link will trigger. (see section 4.17.3 Codelists).

Table 8. OnlineFunctionCode values from NAP (INCITS 453) and ISO 19115. '(ISO)' after the text in column 2 indicates function codes from ISO19115 (2006).

4.16.5 Scoped name in service distributions

A distribution option for a dataset might be through a Web Map Service that contains one or more layers portraying the described dataset, along with layers portraying other datesets. Likewise, a dataset may be distributed as a particular feature type in a Web Feature Service that offers multiple features. Analogous internal knowledge may be required for various other service protocols. To completely specify access to the correct data representation requires knowing the layer name, feature type name, or some other information in addition to the base service connection information provided by the existing properties. USGIN recommended practice for this common situation is to include a parameters section in the linkage/description (see 4.16.3 CI_OnlineResource name and description, above).

4.17 Responsible parties and logos

Metadata should include a URL that locates a thumbnail logo for organizations related to the metadata origination, the organization hosting the catalog that returned the metadata, the organization that originated the data, and the organization hosting online services that provide access to the data. The standard place to put URL's in ISO19139 metadata is in the CI_Contact/onlineResource/­CI_Online­Resource/­linkage attribute. For URL's that indicate icon thumbnails, the CI_OnlineResource/name should be 'icon'.

The metadata originator information should be in a MD_Metadata/contact/CI_ResponsibleParty element with role code 'originator' to identify the original source of the metadata record, for which the CI_Contact/..­/CI_OnlineResource/­linkage is a URL that points to an Icon for the metadata originator. This Icon will be displayed in search results to credit the metadata originator. Metadata harvesters should harvest and maintain this information so that the origin of metadata records can be credited.

The organization hosting the catalog that returned the metadata record should specified in a MD_Metadata/contact/CI_ResponsibleParty element with role code 'distributor', for which the CI_Contact/../CI_OnlineResource/­linkage is a URL that points to an Icon for the metadata server hosting organization. This information need not be harvested, because it will be replaced by information describing the harvesting catalog service.

The organization that originated the data is specified by MD_Metadata/identificationInfo/­MD_Data­Identification/­citation/../CI_ResponsibleParty with RoleCode ='originator', and /CI_Online­Resource/name='icon'. This will distinguish the citation responsible party element containing the icon linkage from CI_ResponsibleParty elements with RoleCode='author' or 'editor', which would provide an online linkage directly to the responsible party as specified by CI_OnlineResource protocol, application­Profile, name, function, and description elements.

The organization hosting a service providing online access to described data is specified by MD_Metadata/distributionInfo/­MD_Distribution/distributor/MD_Distributor/­distributor­Contact/­CI_ResponsibleParty with RoleCode ='resourceProvider' or 'distributor', and ../CI_Online­Resource/name='icon'. Because the cardinality of distributorContact responsible party and online resources is 1, only one linkage can be provided for a distributor, and the metadata author must decide whether that will be a link to an icon, or a link to a web site or other resource related to the distributor.

<gmd:contact>

  <gmd:CI_ResponsibleParty>

    <gmd:organisationName>

      <gco:CharacterString>Arizona Geological Survey</gco:CharacterString>

    </gmd:organisationName>

    <gmd:contactInfo>

      <gmd:CI_Contact>

        <gmd:onlineResource>

          <gmd:CI_OnlineResource>

            <gmd:linkage>

              <gmd:URL>http://www.azgs.az.gov/logo/metadata/azgs.png</gmd:URL>

            </gmd:linkage>

          <gmd:name>

            <gco:CharacterString>icon</gco:CharacterString>

           </gmd:name>

          </gmd:CI_OnlineResource>

        </gmd:onlineResource>

      </gmd:CI_Contact>

    </gmd:contactInfo>

    <gmd:role>

      <gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode"

codeListValue="originator">originator</gmd:CI_RoleCode>

    </gmd:role>

  </gmd:CI_ResponsibleParty>

</gmd:contact>

4.18 Extensions to CharacterString

4.18.1 Web extensions

ISO 19139 defines several extensions to gco:CharacterString in the gmx namespace. These are defined as members of an xml substitution group for gco:CharacterString, and include gmx:Anchor, gmx:FileName, and gmx:MimeFileType. gmx:Anchor is used for URL's linking to online web resources, and include a URI attribute associated with the character string that is the human-readable label for the link. gmx:FileName adds a filename URI attribute that specifies a machine-readable absolute path to the location of the file, the human readable file name specified by the character string. gmx:MimeFileType adds a MIME type/subtype attribute to a character string that specifies a human readable file type. The gmx namespace is not imported into other ISO19139 schema in the normative schema. In order to create schema-valid documents that use these extensions, explicit namespace-declaration must be made to the gmx schema in instance documents. For the USGIN profile, these extension classes are not recommended, and may be ignored by client software.

4.18.2 Language localization

ISO 19139 defines an extension to gco:CharacterString that allows substitution by PT_FreeText or LocalisedCharacterString. LocalisedCharacterString adds a locale/PT_Locale property to the CharacterSTring element that can specify the language, country, and character encoding for the string. PT_FreeText allow substitution of a collection of LocalisedCharacterString elements for any CharacterString, each localized to a different language/country.

These various possibilities create potential to break interoperability. To avoid this problem, and to avoid complexity with PT_Text and LocalizedCharacterString, USGIN profile practice is to implement services for different languages as different catalog service instances, each of which serves CharacterStrings in a single language specified by the MD_Metadata/language element.

4.18.3 Codelists

ISO 19139 defines a "CodeListValue_Type" XML Class Type with three attributes:

codeList: contains a URL that references a codeList definition within a registry or a codelist catalogue. As currently used in the metadata services we have studied, the codeList is not used to identify a vocabulary; rather it provides a locator (functionally equivalent to xlink:href) for an online resource, typically a web page or xml file, that contains a listing of the codelist with the code values and scope notes. Different services provide different URL's, possibly linking to different kinds of resources (e.g. web page or xml file), for the same codelist. Thus, in practice, the values in this attribute can not be used for automated determination of the code list in use in a metadata document.

codeListValue: carries the value from the 'name' column of the codelist tables in ISO 19115, Annex B. This value serves to identify the codelist meaning in the context of the codelist catalogue (or registry) located by the codeList attribute. The codelist catalogue is expected to contain an explicit name and definition of the value in the default language of the metadata, as well as alternate expressions in different code spaces, some of them corresponding to the different locales supported by the metadata.

The codeSpace attribute is an optional identifier (URI); when present it refers to an alternative expression of the codelist value definition. In the example in ISO19139, section 8.5.5.1 (p. 30), the codeSpace URI for the domain code is the string "domainCode", and the value from the domainCode column in a codelist definition table in ISO 19115, Annex B is included as the value of the xml CodeList element in this case. This appears to be an attempt to allow alternate codeListValue strings to be associated with the codelist value concept for language localization or use of alternate identifiers. Values are not used by USGIN clients and will generally be ignored.

Codelist elements in the ISO19139 XML schema are assigned to type CodeListValue_Type, and also included in a substitution group for gco:CharacterString. These codeList elements are thus substitutable for elements typed gco:CharacterString. Consequently, any CodeList instance is an XML element that takes a string value (corresponding to the element value for a gco:CharacterString), and has three XML attributes defined by the CodeListValue_Type XML Class Type. A corresponding XML Class Property Type is defined for each of these CodeList elements, and this property type is used to restrict the values in XML CharacterString attributes to the code list.

The ISO specification uses an unfortunate choice of name for the 'codeListValue' attribute that is defined to be a identifier, apparently with the intention that it is a language-neutral concept identifier that might be associated with various language-localized labels for the concept. NAP CodeList registries (http://www.fgdc.gov/nap/metadata/register) contrast with the codelists defined in the tables in ISO 19115 Annex B in that the identifier (the 'name' column the ISO19115 Annex B tables) is an integer identifier with the prefix 'RI_'. This would appear to correspond functionally to the 'domainCode' values in the ISO19115 Annex B tables, which ISO19139 indicates should be the codeListValue when the code­Space="domainCode".

NAP and INSPIRE usage is consistent with the ISO19139 definition of codeListValue as an identifier, with the name or label for the codeList concept included as the value of the CodeListValue attribute. The 'name' column in ISO 19115, Annex B tables, which is described as the content for the codeListValue by ISO19139, contains English words that are the same as the labels one would use in English. In the CT_CodeListCatalogues in the ISO publicly available standards registry for ISO 19139 (http://standards.iso.org/ittf/PubliclyAvailable­Standards/­ISO_19139_Schemas/resources/), the CodeListDictionary/codeEntry/CodeDefinition elements only include gml:description and gml:identifier elements, but no gml:name elements. Based on this ISO guidance, USGIN profile mandates that controlled vocabulary terms from codelists are encoded thus:

 

Example 1:

<gmd:CI_DateTypeCode codeList=" http://standards.iso.org/ittf/PubliclyAvailableStandards/­ISO_19139_Schemas/­resources/#CI_DateTypeCode"
codeListValue="creation"/>

 

Example 2

<gmd:MD_CharacterSetCode
codeList=" http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode"
codeListValue="utf8"/>

 

Or

<gmd:MD_CharacterSetCode
codeList=" http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode"
codeListValue="utf8">UTF-8</gmd:MD_CharacterSetCode>

The alternate version of example 2 includes label string for the codelist concept as the element value string. Most applications appear to use only the codeListValue string for querying and content inspection. In order to indicate that standard ISO codelists are being used, the codeList attribute value MUST be " http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml ", which is the web location for the authoritative codelist dictionary XML document. Including the fragment identifier name for the particular codelist is informative only; this is the terminal token of the URL after the '#' character, and will be ignored by browsers.

The use of other codelists is implemented by providing a codeList attribute that points to the codelist actually used. The following example shows use of a DateTypeCode from the code list in the North American Profile:

<gmd:CI_DateTypeCode
codeList="http://www.fgdc.gov/nap/metadata/register/register­ItemClasses.html#IC_87"
codeListValue="superseded">superseded</gmd:CI_DateTypeCode>

Note that the ISO codelists use the name value for the codeListValue attribute. This is consistent with ISO codelist practice but is in contrast to the NAP codeList example encoding in Appendix E of NAP profile document (INCITS 453, 2009). In these examples the codeListValue is the 'Item identifier' from the NAP registry specified by the codeList, with the prefix 'RI_' added.

The ISO codelists are in much wider use at this time than the NAP codelists (as far as we can tell from surveying existing services), but we recognize that some of the terms added in the NAP code­lists may be required for metadata describing some of the resources in the USGIN scope (Table 1). Table 8 summarizes differences between the ISO and NAP codelists. The recommended practice is to use ISO codelists wherever possible, encoded as in the examples above. NAP codes may be used where necessary, with the appropriate codeList URL: " http://www.fgdc.gov/­nap/metadata/register/registerItemClasses.html" and optional codelist-specific document fragment token (e.g. #IC_87)

If a new codelist is created to restrict text in an ISO element whose type is simply CharacterString (e.g. HierarchyLevelName), then characterString element values are encoded by soft-typing the element that takes the character string using the xsi:type attribute. The following example uses the FileFormatCodeList, which is the only code list vocabulary added to the collection of codelists defined by ISO 19115 by the North American Profile.

<gmd:fileType xsi:type="gml:CodeType"
codeList="http://www.fgdc.gov/nap/metadata/register/registerItemClasses.html#IC_115"
codeListValue="jpg">

<gco:CharacterString>jpg</gco:CharacterString>

</gmd:fileType>

As a convention for using controlled vocabularies on gco:characterString elements without the overhead of a defining a new namespace and xml schema, USGIN proposes that use of a controlled vocabulary be indicated by adding the attribute xsi:type="gml:CodeType" on the gco:CharacterString element. The type gml:CodeType requires a codeList attribute (see 4.14.2 Non digital resources and 7.2 Linkage name conventions), which MUST be the URI for the vocabulary used, with the implication that the gco:CharacterString element value and the codeListValue attribute will then be an identifier from that vocabulary. This essentially turns the CharacterString into a GML scoped name or gco:LocalName element.

Table 9. Codelist crosswalk between ISO, NAP and USGIN.

Codelist (ISO / NAP)	Coded Values/Names	Comments
CI_DateTypeCode napCI_DateTypeCode	creation, publication, revision	ISO 19115 (B.5.2)
	..., notAvailable, inForce, adopted, deprecated, superseded	NAP expansion
CI_OnLineFunction-Code napCI_OnLineFunction-Code	download, information, offlineAccess, order, search	ISO 19115 (B.5.3)
	..., upload, webService, emailService, browsing, fileAccess, webMapService	NAP expansion
CI_PresentationForm-Code napCI_PresentationForm-Code	documentDigital, documentHardcopy, imageDigital, imageHardcopy, mapDigital, mapHardcopy, modelDigital, modelHardcopy, profileDigital, profileHardcopy, tableDigital, tableHardcopy, videoDigital, videoHardcopy, audioDigital	ISO 19115 (B.5.4)
	..., audioHardcopy, multimediaDigital, multimediaHardcopy, diagramDigital, diagramHardcopy	NAP expansion
CI_RoleCode napCI_RoleCode	resourceProvider, custodian, owner, user, distributor, originator, pointOfContact, principalInvestigator, processor, publisher, author	ISO 19115 (B.5.5)
	..., collaborator, editor, mediator, rightsHolder	NAP expansion
DQ_EvaluationMethod-TypeCode napDQ_Evaluation-MethodTypeCode	directInternal, directExternal, indirect	ISO 19115 (B.5.6)
DS_AssociationType-Code napDS_Association-TypeCode	crossReference, largerWorkCitation, partOfSeamlessDatabase, source, stereoMate	ISO 19115 (B.5.7)
	..., isComposedOf	NAP expansion
DS_InitiativeType-Code napDS_Initiative-TypeCode	campaign, collection, exercise, experiment, investigation, mission, sensor, operation, platform, process, program, project, study, task, trial	ISO 19115 (B.5.8)
MD_CellGeometryCode napMD_CellGeometry-Code	point, area	ISO 19115 (B.5.9)
	..., voxel	NAP expansion
MD_CharacterSetCode napMD_CharacterSet-Code	ucs2, ucs4, utf7, utf8, utf16, 8859part1, 8859part2, 8859part3, 8859part4, 8859part5, 8859part6, 8859part7, 8859part8, 8859part9, 8859part10, 8859part11, 8859part13, 8859part14, 8859part15, 8859part16, jis, shiftJIS, eucJP, usAscii, ebcdic, eucKR, big5, GB2312	ISO 19115 (B.5.10)
MD_Classification-Code napMD_ClassificationCode	unclassified, restricted, confidential, secret, topSecret	ISO 19115 (B.5.11)
	..., sensitive, forOfficialUseOnly	NAP expansion
MD_CoverageContent-TypeCode napMD_Coverage-ContentTypeCode	image, thematicClassification, physicalMeasurement	ISO 19115 (B.5.12)
MD_DataTypeCode not used by NAP and USGIN	class, codelist, enumeration, codelistElement, abstractClass, aggregateClass, specifiedClass, datatypeClass, interfaceClass, unionClass, metaClass, typeClass, characterString, integer, association	ISO 19115 (B.5.13) -- The MD_MetadataExtensionInformation element and its codelists are not used by NAP and USGIN.
MD_DimensionName-TypeCode napMD_DimensionName-TypeCode	row, column, vertical, track, crossTrack, line, sample, time	ISO 19115 (B.5.14)
MD_GeometricObject-TypeCode napMD_Geometric-ObjectTypeCode	complex, composite, curve, point, solid, surface	ISO 19115 (B.5.15)
MD_ImagingCondition-Code napMD_Imaging-ConditionCode	blurredImage, cloud, degradingObliquitty, fog, heavySmokeOrDust, night, rain, semiDarkness, shadow, snow, terrainMasking	ISO 19115 (B.5.16)
MD_KeywordTypeCode napMD_KeywordType-Code	discipline, place, stratum, temporal, theme	ISO 19115 (B.5.17)
	..., product, subTopicCategory	NAP expansion
MD_Maintenance-FrequencyCode napMD_Maintenance-FrequencyCode	continual, daily, weekly, fortnightly, monthly, quarterly, biannually, annually, asNeeded, irregular, notPlanned, unknown	ISO 19115 (B.5.18)
	..., semimonthly	NAP expansion
MD_MediumFormatCode napMD_MediumFormat-Code	cpio, tar, highSierra, iso9660, iso9660RockRidge, iso9660AppleHFS	ISO 19115 (B.5.19)
	..., UDF	NAP expansion
MD_MediumNameCode napMD_MediumNameCode	cdRom, dvd, dvdRom, 3halfinchFloppy, 5quarterInchFloppy, 7trackTape, 9trackTape, 3480Cartridge, 3490Cartridge, 3580Cartridge, 4mmCartridgeTape, 8mmCartridgeTape, digitalLinearTape, onLine, satellite, telephoneLink, hardcopy, hardcopyDiazoPolyester08, hardcopyCardMicrofilm, hardcopyMicrofilm240, hardcopyMicrofilm35, hardcopyMicrofilm70, hardcopyMicrofilmGeneral, hardcopyMicrofilmMicrofiche, hardcopyNegativePhoto, hardcopyPaper	ISO 19115 (B.5.20)
	..., hardcopyDiazo, hardcopyPhoto, hardcopyTracedPaper, hardDisk, USBFlashDrive, 1quarterInchCartridgeTape	NAP expansion
MD_ObligationCode not used by NAP and USGIN	mandatory, optional, conditional	ISO 19115 (B.5.21) - The MD_MetadataExtensionInformation element and its codelists are not used by NAP and USGIN.
MD_PixelOrientation-Code napMD_Pixel-OrientationCode	center, lowerLeft, lowerRight, upperRight, upperLeft	ISO 19115 (B.5.22)
MD_ProgressCode napMD_ProgressCode	completed, historicalArchive, obsolete, onGoing, planned, required, underDevelopment	ISO 19115 (B.5.23)
	..., proposed	NAP expansion
MD_RestrictionCode napMD_Restriction-Code	copyright, patent, patentPending, trademark, license, intellectualPropertyRights, restricted, otherRestrictions	ISO 19115 (B.5.24)
	..., licenseUnrestricted, licenseEndUser, licenseDistributor, privacy, statutory, confidential, sensitivity	NAP expansion
MD_ScopeCode napMD_ScopeCode	attribute, attributeType, collectionHardware, collectionSession, dataset, series, nonGeographicDataset, dimensionGroup, feature, featureType, propertyType, fieldSession, software, service, model, tile	ISO 19115 (B.5.25)
MD_Spatial-RepresentationTypeCode napMD_Spatial-RepresentationTypeCode	vector, grid, textTable, tin, stereoModel, video	ISO 19115 (B.5.26)
MD_TopicCategoryCode napMD_TopicCategory-Code	farming, biota, boundaries, climatologyMeterologyAtmosphere, economy, elevation, environment, geoscientificInformation, health, imageryBaseMapsEarthCover, intelligenceMilitary, inlandWater, location, oceans, planningCadastre, society, structure, transportation, utilitiesCommunication	ISO 19115 (B.5.27)
MD_TopologyLevelCode napMD_TopologyLevel-Code	geometryOnly, topology1D, planarGraph, fullPlanarGraph, surfaceGraph, fullSurfaceGraph, topology3D, fullTopology3D, abstract	ISO 19115 (B.5.28)
SV_CouplingType napSV_CouplingType	loose, mixed, tight	ISO 19119 (Amendment 1; C.2.8)
SV_Parameter-Direction napSV_Parameter-Direction	in, out, in/out	ISO 19119 (Amendment 1; C.2.9
LanguageCode	see http://www.loc.gov/standards/iso639-2/php/code_list.php	no complete NAP or ISO registry found
not used by ISO nap_DCPList	XML, CORBA, JAVA, COM, SQL, WebServices	NAP specific codelist -- not used by USGIN due to poorly defined semantics and use.
not used by ISO napMD_FileFormatCode	bil, bmp, bsq, bzip2, cdr, cgm, cover, csv, dbf, dgn, doc, dwg, dxf, e00, ecw, eps, ers, gdb, geotiff, gif, gml, grid, gzip, html, jpg, mdb, mif, pbm, pdf, png, ps, rtf, sdc, shp, sid, svg, tab, tar, tiff, txt, xhtml, xls, xml, xwd, zip, wpd	NAP specific codelist -- not formally used by USGIN, but these character strings should are to be used to populate fileType elements.

4.19 Geographic bounding box

USGIN profile requires that if an EX_Extent/geographicElement is supplied, at least one geographic bounding box with bounding latitude and longitude expressed using WGS 84 decimal degrees MUST be provided.

The corner coordinates for the geographic bounding box must not coincide in one point, because this may result in fatal errors with some CSW implementations. Point locations must thus be represented as tiny rectangles. USGIN recommended practice is to place the actual point location in the lower left corner of the rectangle.

4.20 Data Quality

4.20.1 Simple quality statement

For resource evaluation purposes, to answer a user's question 'is the described resource good enough for my purposes?', a free text statement is generally sufficient in place of a detailed xml document. For example, this might be a statement something like “These data were compiled by the authors from field sheets and notes by scanning paper copies, georeferencing and digitizing on screen. Station locations are based on Garmin 12 GPS readings, except locally where they have been adjusted for consistency with the base map. Original GPS coordinates are reported in the station table. These data have been reviewed for completeness of description and internal consistency, but have not been independently field checked." This is the only kind of quality information available for many resources; it is neither a quantitative measure nor technically a conformance result. A simple qualityStatement would suffice and provide significant value. There is no ISO19115 element for such a quality statement.

To implement this simple case, the proposed solution is that the first report conformance explanation in each DQ_DataQuality element instance would contain a free text discussion of data quality considerations for the indicated scope for that element. Thus, text at the XPath DQ_Data­Quality//­report[1]//result[1]//­explanation/­CharacterString will be interpreted as a self-explanatory quality statement. The use of any specific data quality element (e.g. DQ_Quan­titative­­Attribute­Accuracy, DQ_RelativeInternal­Positional­Accuracy..) to contain this explanation is arbitrary and may be ignored by client applications.

4.21 Lineage

Lineage in data quality section is a collection of processing steps that describe the provenance of a resource. Each step has some input resources, identified by source citations associated with the process step. The LI_ProcessStep element does not directly identify its output resource, so in a lineage that involves a chain of steps with intermediate resources, the sourceStep association from LI_Source links a resource to a processing step that it is output from.

A LI_Lineage element that contains a source but no processStep elements is redundant; this source information should be represented with the MD_DataIdentification/citation/CI_Citation element.

A GIS dataset originally digitized from a published geologic map, put online, obtained by an online download, and reprojected would report one processStep (reprojection) with source/LI_Source that has a CI_Citation for the downloaded data. This LI_Source would have a sourceStep pointing to an LI_ProcessStep for the original digital conversion from the paper map, and the LI_ProcessStep/source/LI_Source would contain the citation for the original paper map.

In order to enable XPath queries for any of the sources or processSteps in a processing chain, all related LI_Source and LI_ProcessStep elements should be directly nested within the LI_Lineage element, and the processStep/source and LI_Source/sourceStep associations should be by internal document references (see Code Example 3).

 

Code Example 3: A complex processing and source history using LI_Lineage.

<?xml version="1.0" encoding="UTF-8"?>

<LI_Lineage

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

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

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

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

xsi:schemaLocation="http://www.isotc211.org/2005/gmd http://schemas.opengis.net/iso/19139/20070417/gmd/dataQuality.xsd">

<statement>

<CharacterString>The digital data described by this metadata was originally compiled digitally from two published maps; this digital dataset was then reprojected to produce the described resource.</CharacterString>

</statement>

<processStep>

<LI_ProcessStep id="1">

<description>

<CharacterString>digital compilation of 2 Maps</CharacterString>

</description>

<source xlink:href="#10"/>

<source xlink:href="#20"/>

</LI_ProcessStep>

</processStep>

<processStep>

<LI_ProcessStep id="2">

<description>

<CharacterString>digital map compilation reprojected, should have some way to specify projection parameters?, output is LI_Source id=70 </CharacterString>

</description>

<source xlink:href="#40"/>

</LI_ProcessStep>

</processStep>

<source>

<LI_Source id="40">

<description>

<CharacterString>a digital compilation of 2 maps, output of processStep ID=1, input into reprojection process</CharacterString>

</description>

<sourceStep xlink:href="1"/>

</LI_Source>

</source>

<source>

<LI_Source id="10">

<description>

<LocalisedCharacterString>ultimate source--somepublishedmap</LocalisedCharacterString>

</description>

<!--no source processing recorded for production of paper map so no sourceStep-->

</LI_Source>

</source>

<source>

<LI_Source id="20">

<description>

<LocalisedCharacterString>another published map</LocalisedCharacterString>

</description>

</LI_Source>

</source>

<source>

<LI_Source id="70">

<description>

<LocalisedCharacterString>a reprojected version of the digital compilation</LocalisedCharacterString>

</description>

<sourceStep xlink:href="2"/>

</LI_Source>

</source>

</LI_Lineage>

An LI_Lineage may be constructed that involves a number of resources and processing steps, and this lineage may be referenced by metadata for all the resources involved in the processing. The LI_Lineage/source/LI_Source/sourceCitation/CI_Citation/identifier/MD_Identifier is a reference to the MD_Metadata/fileIdentifier for the metadata for each resource in the chain. This approach allows the metadata record to record relationships through process steps between resources.

4.22 Temporal extents

Resource temporal extent (identificationInfo/MD_Data­Identification/extent/EX_Extent/­temporalElement/EX_TemporalExtent/extent/TimePeriod) is used to specify the temporal interval to which the content of a resource applies. Default reference frame for time is calendar date and time encoded using ISO-8601:

<gml:TimePeriod gml:id="Id2010">

<!-- Note that gml:TimePeriod requires a gml:id string that must be unique

in the scope of the instance document, and must have an alphabet

character ('a-z', 'A-Z') as its first character -->

<!-- USGIN requires the beginPosition and endPosition's frame property to be defined. The default value is #ISO-8601. -->

<gml:beginPosition frame="#ISO-8601">2010-01-00T00:00:00Z </gml:beginPosition>

<gml:endPosition frame="#ISO-8601">2010-12-31T24:00:00Z</gml:endPosition>

</gml:TimePeriod>

<gml:endPosition indeterminatePosition="now"/> is the correct way to represent "Present" in ISO or GML as one of the boundaries of a timePeriod.

The ISO 19139 xml schema allows temporal location to be quantified by a gml:TimeInstant or gml:TimePeriod element. In order to promote interoperability, the USGIN profile mandates use of gml:TimePeriod for specifying temporal extent for a resource.

For geologic time extents, the time coordinates for the beginPosition and endPosition should be expressed numerically in Ma. This convention allows search for resources pertinent to intervals of geologic time using simple numeric comparisons instead of the complex hierarchical concept expansions that would be necessary to use named eras from a stratigraphic time scale. Encoding example:

<EX_TemporalExtent>

<extent>

<gml:TimePeriod gml:id="y34096">

<gml:beginPosition

frame="urn:CGI:TemporalCRS:cgi:standardGeologyMa">220</gml:beginPosition>

<gml:endPosition

frame="urn:CGI:TemporalCRS:cgi:standardGeologyMa">140 </gml:endPosition>

</gml:TimePeriod>

</extent>

</EX_TemporalExtent>

The frame for the beginPosition and endPosition is a URI for standard geologic time, measured positive getting older, with an origin at 1950 CE, in units of millions of years.

4.23 Operation metadata

See the discussion on the use of service metadata in the USGIN profile above, preceding Table 3. The srv namespace elements based on ISO 19119 provide insufficient information and guidelines to access data through services without apriori knowledge of the service protocol. This is due in part to weakly defined semantics and use cases for the elements that are there (DCP, applicationProfile, protocol, MD_Format, serviceType, operationName vs. invocationName, connectPoint), and partly due to incomplete content model (where to put allowed outputFormat parameter values or supported query operations for CSW or WMS, what is syntax for delimiting parameters, are http request headers used). The ISO 19119 model for service metadata does not include a mechanism to specify valid values for operation parameters. For instance, OGC WMS and CSW services both support an output format parameter, and OGC capabilities documents provide a listing of the supported output formats, but where do these go in ISO19139 xml documents? Does the described service support http POST or GET method? This information is necessary in order to compose valid service requests.

Based on these considerations, the USGIN profile mandates that a service metadata record MUST include at least one service operation with the operationDescription/­Character­String = 'serviceDescription'. The identificationInfo/SV_ServiceIden­tification/­contains­Operations/­­SV_OperationMetadata/­connectpoint link for this operation MUST retrieve the service-specific self description document (e.g. WSDL, GetCapabilities, WADL). The CI_OnlineResource in this connectPoint elment must have CI_OnlineResource/name = "serviceDescription" (from the table in section 7.2 Linkage name conventions).

WSDL and getCapabilities were designed to describe service operation, and it seems counterproductive to invent another scheme to do the same thing. Service metadata for processing services that are not coupled to particular input datasets should provide srv:SV_Operation­Metadata to describe the operations offered by the service to inform human users. Because of the difficulty in creating usable abstract model that accounts for any and all possible services, it makes more sense to allow service description documents specific to different service frameworks to describe all the details in a machine-actionable format.

CSW	Metadata Catalog for the Web. Also abbreviated as CS-W and CS/W
GeoSciML	Geoscience Markup Language
GML	Geographic Markup Language
GUID	Global Unique Identifier
IEC	International Electrotechnical Commission
ISO	International Organization for Standardization
UML	Unified Modeling Language
URI	Universal Resource Identifier
USGIN	U.S. Geoscience Information Network
WCS	Web coverage Service
WFS	Web Feature Service
XML	eXtensible Markup Language
XSD	XML Schema Definition
XSL	eXtensible Stylesheet Language
XSLT	XSL Transformations
XLink	XML Linking Language

 

6.1 Cited literature

[ANZLIC, 2007] ANZLIC Metadata Profile Guidelines, Version 1.0: Turner, ACT, ANZLIC - the Spatial Information Council, ISBN: 978-0-646-46940-9, 372 p., available at http://www.osdm.gov.au/Metadata/ANZLIC+metadata+resources/default.aspx (accessed 2010-11-18).

[Dublin Core] 2008-01-14 Dublin core Metadata Element Set, Version 1.1: Dublin Core Metadata Initiave, accessed at http://dublincore.org/documents/dces/.

[INSPIRE ISO19115/119] Drafting Team Metadata and European Commision Joint Research Centre, 2009-02-18, INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119,v. 1.1: European Commission Joint Research Centre, MD_IR_and_ISO_20090218, available at http://inspire.jrc.ec.europa.eu/index.cfm/pageid/101 (accessed 2010-11-18).

Franklin, Michael, Halevy, Alon, and Maier, David, 2005, From databases to dataspaces: a new abstraction for information management: ACM SIGMOD Record, V. 34, No. 4, ISSN:0163-5808.

[FRBR] Tillett, Barbara, 2004-03-02, What is FRBR?: Washington, DC, Library of Congress Cataloging Distribution Service, 8 pages. (originally published in Technicalities v. 25, no. 5, 2003), available at http://www.loc.gov/cds/downloads/FRBR.PDF (accessed 2013-06-12).

Heaney, Michael, 2000-01-14, An analytical model of Collections and their Catalogues: UK Office for Library and Information Networking, Third Issue, available at http://www.ukoln.ac.uk/metadata/-rslp/model/amcc-v31.pdf (accessed 2013-03-18).

Richard, S. M., and Grunberg, Wolfgang, editors, 2010, Metadata Recommendataions for Geoscience Resources: U.S. Geoscience Information Network Best Practices Document, Doc ID gin2010-11, v. 1.0.3, available at http://lab.usgin.org/profiles/doc/metadata-content-recommendations (accessed 2010-11-18).

7.1 ServiceType

INSPIRE metadata Implementing Rules (OJ L 326, 4.12.2008) section D3 mandate the use of the value domain listed in Table 11 to categorize spatial data service types. These values are better suited for CI_OnlineFunctionCode used to specify CI_OnlineResource/online/Function. The USGIN team interprets the ISO scope notes to allow more useful content for service type, specifying an actual service specification like OGC WMS. USGIN draft ServiceType vocabulary is reported in Table 12.

 

Table 11. INSPIRE SPATIAL DATA SERVICE TYPE (for information only, not used by USGIN)

Table 12. USGIN service type vocabulary use identifier strings specified at https://github.com/OSGeo/Cat-Interop.

Identifier	Name	Description
OGC:WMS[smr1]	OGC Web Map service	provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed. The response to the request is one or more geo-registered map images (returned as JPEG, PNG, etc) that can be displayed in a browser application. The interface also supports the ability to specify whether the returned images should be transparent so that layers from multiple servers can be combined or not. (http://www.opengeospatial.org/standards/wms)
OGC:WFS	OGC Web Feature service	WFS offers direct fine-grained access to geographic information at the feature and feature property level; allows clients to retrieve or modify specific data items. That data can then be used for a wide variety of purposes, including purposes other than their producers' intended ones. http://www.opengeospatial.org/standards/wfs
OGC:WCS	OGC Web coverage service	interface and operations that enable interoperable access to geospatial "coverages" [http://www.opengeospatial.org/ogc/­glossary/c]. The term "grid coverages" typically refers to content such as satellite images, digital aerial photos, digital elevation data, and other phenomena represented by values at each measurement point.
OGC:CSW	OGC Web catalog service	publish and search collections of descriptive information (metadata) about geospatial data, services and related resources. Providers of resources use catalogues to register metadata that conform to the provider's choice of an information model; such models include descriptions of spatial references and thematic information. (http://www.opengeospatial.org/standards/cat)
OGC:SOS	OGC Sensor observation service	manage deployed sensors and retrieve sensor data, specifically "observation" data. E.g. in-situ sensors (e.g., water monitoring) or dynamic sensors (e.g., satellite imaging). (http://www.opengeospatial.org/standards/sos)
OGC:WPS	OGC Web Processing service	rules for standardizing how inputs and outputs (requests and responses) for geospatial processing services, such as polygon overlay, are exchanged on the web to link services; defines how a client can request the execution of a process, and how the output from the process is handled, and an interface to register geospatial processes and for client to discovery and bind to those processes. (http://www.opengeospatial.org/standards/wps)
OGC:SPS	OGC Sensor planning service	interfaces for exchanging information about the capabilities of a sensor and how to task the sensor; designed to support queries to determine the feasibility of a sensor planning request, to submit such a request, to inquire about the status of such a request, to update or cancel such a request, and to request information about other OGC Web services that provide access to the data collected by the requested task.
OPeNDAP:OPeNDAP	Open source data access protocol	(http://opendap.org/) a protocol for requesting and transporting data across the web. DAP 2.0 uses HTTP to frame the requests and responses. For details on DAP, see Data Access Protocol (DAP), version 2 which is a technical description of the Data Access Protocol.
OAI-PMH	Open Archives Initiative Protocol for Metadata Harvesting	provides an application-independent interoperability framework based on metadata harvesting.

Example usage:

<srv:serviceType>

<gco:LocalName codeSpace="http://resources.usgin.org/registry/serviceType201001"> OGC:WMS</gco:LocalName>

</srv:serviceType>

7.2 Linkage name conventions

The cardinality of the online element in DigitalTransferOptions is 0..*. In order to distinguish the nature of various linkages that might be provided, above and beyond function, protocol, and applicationProfile, USGIN profile mandates use of the following names to associate with links to identify important linkages.

Table 13. USGIN Names to identify special linkage URL's for CI_Online Resource. CodeList URI = http://resources.usgin.org/registry/linkageName201001

 

Example usage:

 

<gmd:CI_OnlineResource>

<gmd:linkage>

<gmd:URL>http://75.101.143.247:8080/gsvr/wms?SERVICE=WMS&amp;REQUEST=getCapabilities</gmd:URL>

</gmd:linkage>

<gmd:protocol>

<gco:CharacterString>OGC:WMS</gco:CharacterString>

</gmd:protocol>

<gmd:name>

<gco:CharacterString xsi:type="gml:CodeType"

codeSpace="http://resources.usgin.org/registry/linkageName201001">

serviceDescription</gco:CharacterString>

</gmd:name>

</gmd:CI_OnlineResource>

 

Use of such controlled vocabulary can be indicated by using xsi:type on the gco:characterString element to make the type gml:CodeType, which then requires a codeSpace attribute. The distribution format Identifier from Table 6 should be used as the element value. For compatibility with systems that can not process this encoding, the code identifier should be included as the element value as well as the codeListValue.

8.1 USGIN ISO 19139 Minimum Dataset Metadata

In the following listing, text in green is comments; XML elements are in blue, XML attributes are in black, and attribute values are in purple.

This example metadata record describes itself.

<?xml version="1.0" encoding="UTF-8"?>

<!--*************************************************************************************************

*** Minimum example of a ISO 19139 Geospatial Dataset Metadata

*** based on the USGIN v1.2 Profile

*** by USGIN Standards and Protocols Drafting Team

*** U.S. Geoscience Information System (USGIN) - http://lab.usgin.org

*** Contributors: Wolfgang Grunberg, Stephen M Richard

*** 2013-06-13

***

*** DISCLAIMER: this is not an authoritative metadata example but an aide to get started.

*** Refer to the USGIN profile document for more specific and complete guidelines.

***

*** Validated against http://www.isotc211.org/2005/gmd (ISO 19115, CSW 2.0.2 AP ISO 1.0).

*** Follows the USGIN ISO 19139 Dataset Metadata Profile v1.2.

***

*** NOTES:

*** - Codelists:

*** Most ISO metadata profiles and applications use ISO codelists or codelists that use ISO's codelist names.

***

*** - Language code:

*** Use ISO <ISO639-2/T three letter language code - lower case> formatting.

***

*** KEY: (NAP-USGIN) - M/C/O/X (Mandatory, Conditional, Optional, Not Used)

***

**********************************************************************************************-->

<!-- USGIN ISO 19139 geospatial dataset metadata record -->

<gmd:MD_Metadata

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

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

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

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

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

xsi:schemaLocation="http://www.isotc211.org/2005/gmd http://schemas.opengis.net/csw/2.0.2/profiles/apiso/1.0.0/apiso.xsd">

<!-- (M-M) Metadata file identifier - A unique File Identifier (GUID) - USGIN recommends using a valid Universally Unique Identifier (UUID) -->

<gmd:fileIdentifier>

<gco:CharacterString>08fb00c8-0882-4bf7-b07f-fd37050c5efc</gco:CharacterString>

</gmd:fileIdentifier>

<!-- (M-M) Metadata language - ISO <ISO639-2/T three letter language code - lower case formatting. -->

<gmd:language>

<gco:CharacterString>eng</gco:CharacterString>

</gmd:language>

 

<!-- (M-M) Metadata character set - USGIN requires that a character set code is defined to facilitate CSW servers (deegree, GeoNetwork, etc.). -->

<gmd:characterSet>

<!-- MD_CharacterSetCode names: {ucs2, ucs4, utf7, utf8, utf16, 8859part1, 8859part2, 8859part3, 8859part4, 8859part5, 8859part6, 8859part7, 8859part8, 8859part9, 8859part10, 8859part11, 8859part13, 8859part14, 8859part15, 8859part16, jis, shiftJIS, eucJP, usAscii, ebcdic, eucKR, big5, GB2312} -->

<gmd:MD_CharacterSetCode

codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_CharacterSetCode" codeListValue="utf8">UTF-8</gmd:MD_CharacterSetCode>

</gmd:characterSet>

<!-- (M-M) Resource type - Define if this record is a: dataset (default), service, feature, software, etc. -->

<gmd:hierarchyLevel>

<!-- MD_ScopeCode code names: {attribute, attributeType, collectionHardware,collectionSession, dataset, series, nonGeographicDataset, dimensionGroup, feature, featureType, propertyType, fieldSession, software, service, model, tile}. -->

<gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode>

</gmd:hierarchyLevel>

<!-- (O-M) Resource hierarchy level name - USGIN makes this property mandatory to identify the USGIN resource type (see USGIN Profile, "Resources of Interest"). Default CharacterString is “Dataset" Encode hierarchy by including hierarchyLevelName elements for all broader resource categories. E.g. default should also include a hierarchyLevelName="Collection" element. For services USGIN hierarchyLevelName/CharacterString is “Service". -->

<gmd:hierarchyLevelName>

<gco:CharacterString>Dataset</gco:CharacterString>

</gmd:hierarchyLevelName>

<gmd:hierarchyLevelName>

<gco:CharacterString>Collection</gco:CharacterString>

</gmd:hierarchyLevelName>

<!-- (M-M) Metadata point of contact - Point of contact for the metadata record, e.g. for users to report errors, updates to metadata, etc. -->

<gmd:contact>

<gmd:CI_ResponsibleParty>

<!-- (M-M) (individualName + organisationName + positionName) > 0 -->

<!-- only one is mandatory, this example has organisationName -->

<gmd:organisationName>

<gco:CharacterString>Arizona Geological Survey</gco:CharacterString>

</gmd:organisationName>

 

<!-- Metadata contact information, either a phone number or e-mail address is required.

This example has an e-mail address. ISO19115 makes contact role mandatory as well. -->

<gmd:contactInfo>

<gmd:CI_Contact>

<gmd:address>

<gmd:CI_Address>

<!-- (O-M) Metadata point of contact e-mail address to meet profile requirement -->

<gmd:electronicMailAddress>

<gco:CharacterString>metadata@azgs.az.gov</gco:CharacterString>

</gmd:electronicMailAddress>

</gmd:CI_Address>

</gmd:address>

</gmd:CI_Contact>

</gmd:contactInfo>

<!-- (M-M) ISO 19139 Mandatory: contact role -->

<gmd:role>

<!-- CI_RoleCode names: {resourceProvider, custodian, owner, user, distributor, originator, pointOfContact, principalInvestigator, processor, publisher, author} -->

<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="pointOfContact">point of contact</gmd:CI_RoleCode>

</gmd:role>

</gmd:CI_ResponsibleParty>

</gmd:contact>

<!-- (M-M) Metadata date stamp - USGIN profile requires use of dateStamp/gco:DateTime (Note this contrasts with INSPIRE mandate to use dateStamp/gco:Date). This is the date and time when the metadata record was created or most recently updated (following NAP). -->

<gmd:dateStamp>

<!-- Requires an extended ISO 8601 formatted combined UTC date and time string (YYYY-MM-DDTHH:MM:SS) Some validators require time zone as well; recommend using GMT indicated by 'Z' -->

<gco:DateTime>2010-01-14T10:00:00Z</gco:DateTime>

</gmd:dateStamp>

<!-- (M-M) metadata standard - USGIN profile conformant metadata is indicated by the string “ISO-USGIN" -->

<gmd:metadataStandardName>

<gco:CharacterString>ISO-USGIN</gco:CharacterString>

</gmd:metadataStandardName>

<!-- (O-M) USGIN profile version -->

<gmd:metadataStandardVersion>

<gco:CharacterString>1.2</gco:CharacterString>

</gmd:metadataStandardVersion>

<!-- (M-M) Resource identification information - At least one of MD_DataIdentification (dataset, dataset series) or SV_ServiceIdentification (service) is required. -->

<gmd:identificationInfo>

<!-- Resource Dataset or Dataset Series Identification -->

<gmd:MD_DataIdentification>

<!-- (M-M) Resource citation - Information to identify the intellectual origin of the content in the described resource, along the lines of a citation in a scientific journal. Required content for a CI_Citation element are title, date, and responsibleParty. If the subject of the metadata record is derived from other sources, such that it is not considered identical with those sources, the provenance should be documented in LI_Lineage//LI_Source elements. -->

<gmd:citation>

<gmd:CI_Citation>

<!-- (M-M) Resource title - Use titles that inform the human reader about the dataset's content; titles should be unique in the context of the metadata catalog that contains the metadata record. -->

<gmd:title>

<gco:CharacterString>USGIN minimum metadata example XML file.</gco:CharacterString>

</gmd:title>

<!-- (M-M) Resource reference date - Best practice is to include at least the date of publication or creation of the resource. The date of the resource reported in the citation corresponds to the resource's last update version according to its update frequency. CI_Date content includes a date and dateType. Date for USGIN profile uses gco:DateTime. -->

<gmd:date>

<gmd:CI_Date>

<gmd:date>

<!-- Requires an extended ISO 8601 UTC date and time string (YYYY-MM-DDTHH:MM:SS) Some validators require time zone as well; recommend GMT indicated by 'Z' -->

<gco:DateTime>2010-01-14T09:30:47Z</gco:DateTime>

</gmd:date>

<!-- dateType is mandatory per ISO19115 -->

<gmd:dateType>

<!-- CI_DateTypeCode names: {creation, publication, revision}. -->

<gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode"codeListValue="publication">publication</gmd:CI_DateTypeCode>

</gmd:dateType>

</gmd:CI_Date>

</gmd:date>

<!-- (M-M) Resource responsible party - The citation attribute provides information for citing the intellectual origin of the described resource, analogous to a citation in a scientific journal. The citedResponsibleParty should specify the individual(s) and organizations responsible for the creation or origination of the resource. For most intellectual content, the responsible party is what would normally be considered the author of a work. -->

<gmd:citedResponsibleParty>

<gmd:CI_ResponsibleParty>

<!-- (M-M) (individualName + organisationName + positionName) > 0 -->

<!-- only one is mandatory, this example has organisationName -->

<gmd:organisationName>

<gco:CharacterString>Arizona Geological Survey</gco:CharacterString>

</gmd:organisationName>

<!-- cited responsible party contact information, either a phone number or e-mail address is required. This example has a voice telephone number. ISO19115 makes contact role mandatory as well. -->

<gmd:contactInfo>

<gmd:CI_Contact>

<gmd:phone>

<gmd:CI_Telephone>

<gmd:voice>

<gco:CharacterString>520-770-3500</gco:CharacterString>

</gmd:voice>

</gmd:CI_Telephone>

</gmd:phone>

</gmd:CI_Contact>

</gmd:contactInfo>

<!-- (M-M) ISO 19139 Mandatory: contact role -->

<gmd:role>

<!-- CI_RoleCode names: {resourceProvider, custodian, owner, user, distributor, originator, pointOfContact, principalInvestigator, processor, publisher, author} -->

<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode"codeListValue="pointOfContact">point of contact</gmd:CI_RoleCode>

</gmd:role>

</gmd:CI_ResponsibleParty>

</gmd:citedResponsibleParty>

</gmd:CI_Citation>

</gmd:citation>

 

<!-- (M-M) Resource Abstract - A free text summary of the content, significance, purpose, scope, etc. of the resource. Exactly one value. -->

<gmd:abstract>

<gco:CharacterString>Example for the minimum required elements in a USGIN dataset metadata record. Note that this example includes conditional minimum elements that may or may not apply to a specific resource and its metadata. Although the resource is non-geographic, and extent element is included for example purposes.</gco:CharacterString>

</gmd:abstract>

<!-- (O-C) Resource point of contact (access contact) - CI_ResponsibleParty element here would contain information for point of contact to access the resource. This information is mandatory for physical resources such as core, cuttings, samples, manuscripts. This example metadata record is not about a physical resource, so the element is empty (included here only to anchor this comment... -->

<gmd:pointOfContact/>

<!-- (O-C) Descriptive Keywords - Only required if the described resource is non-geographic, in which case the single keyword 'non-geographic' is mandatory. This example instance is about itself, and example metadata record, and is thus non-geographic so the keyword is mandatory. Note that and example bounding box is included for information purposes as well. -->

<gmd:descriptiveKeywords>

<gmd:MD_Keywords>

<gmd:keyword>

<gco:CharacterString>non-geographic</gco:CharacterString>

</gmd:keyword>

<gmd:type>

<!-- Keyword Type - allowed values from MD_KeywordTypeCode names: {discipline, place, stratum, temporal, theme} -->

<gmd:MD_KeywordTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_KeywordTypeCode" codeListValue="place">place</gmd:MD_KeywordTypeCode>

</gmd:type>

</gmd:MD_Keywords>

</gmd:descriptiveKeywords>

<!-- (M-M) Resource language - Multiple instances of this element indicate that the linguistic content of the resource is available in multiple languages -->

<gmd:language>

<!-- ISO 639-2/T three-letter language code (http://www.loc.gov/standards/iso639-2/). -->

<gco:CharacterString>eng</gco:CharacterString>

</gmd:language>

<!-- (C-C) Topic category - A topicCategory code must be provided when hierarchyLevel is set to "dataset" (this example document) or "dataset series". Most USGIN resources will have MD_TopicCategoryCode = "geoscientificInformation", which is the default value for this profile. More specific topic categorization should be done using keywords. -->

<gmd:topicCategory>

<!-- MD_TopicCategoryCode names: {farming, biota, boundaries, climatologyMeterologyAtmosphere, economy, elevation, environment, geoscientificInformation, health, imageryBaseMapsEarthCover, intelligenceMilitary, inlandWater, location, oceans, planningCadastre, society, structure, transportation, utilitiesCommunication} -->

<gmd:MD_TopicCategoryCode>geoscientificInformation</gmd:MD_TopicCategoryCode>

</gmd:topicCategory>

<!-- (C-C) Resource content extent - Defines the spatial (horizontal and vertical) and temporal region to which the content of the resource applies. For USGIN, a geographicElement/­geographic­BoundingBox must be provided for any resource with content related to some geographic location. If the described resource is not related to a geographic area, the place keyword 'non-geographic' should be included in the descriptiveKeywords element. -->

<!-- note that although this example record is about a non-geographic resource, bounding boxes are anticipated for most resources so an example element is included, but it is not required. -->

<gmd:extent>

<gmd:EX_Extent>

<!-- (O-C) Resource content extent bounding box -USGIN profile requires that if an EX_Extent/geographicElement is supplied, it include a geographic bounding box with bounding latitude and longitude expressed using WGS 84 decimal degrees. The corner coordinates for the geographic bounding box must not coincide in one point, because this may result in fatal errors with some CSW implementations. Point locations must thus be represented as tiny rectangles. USGIN recommended practice is to place the actual point location in the lower left corner of the rectangle. -->

<gmd:geographicElement>

<gmd:EX_GeographicBoundingBox>

<gmd:westBoundLongitude>

<gco:Decimal>-109.911001</gco:Decimal>

</gmd:westBoundLongitude>

<gmd:eastBoundLongitude>

<gco:Decimal>-109.910999</gco:Decimal>

</gmd:eastBoundLongitude>

<gmd:southBoundLatitude>

<gco:Decimal>34.772899</gco:Decimal>

</gmd:southBoundLatitude>

<gmd:northBoundLatitude>

<gco:Decimal>34.772901</gco:Decimal>

</gmd:northBoundLatitude>

</gmd:EX_GeographicBoundingBox>

</gmd:geographicElement>

</gmd:EX_Extent>

</gmd:extent>

</gmd:MD_DataIdentification>

</gmd:identificationInfo>

<!-- Distribution (O-M) This element provides information to inform users how to obtain or access the described resource, which is considered part of the minimum useful content that should be provided by a metadata record. USGIN profile specifies that at least one MD_Distribution/distributor and one MD_Distribution/transferOptions element are required, and that the specified distributor provides the specified transfer options. -->

<gmd:distributionInfo>

<gmd:MD_Distribution>

<gmd:distributor>

<gmd:MD_Distributor>

<!-- (O-C) distributor point of contact - CI_ResponsibleParty element here would contain information on who to contact if there is a problem with accessing the resource following the instructions in this distribution element. This information is mandatory, requiring at least a name (one of individual, organization, or position) and a voice telephone number or e-mail address. This example includes a position name and e-mail address. -->

<gmd:distributorContact>

<gmd:CI_ResponsibleParty>

<gmd:positionName>

<gco:CharacterString>Web Master</gco:CharacterString>

</gmd:positionName>

<gmd:contactInfo>

<gmd:CI_Contact>

<gmd:address>

<gmd:CI_Address>

<gmd:electronicMailAddress>

<gco:CharacterString>webmaster@usgin.org</gco:CharacterString>

</gmd:electronicMailAddress>

</gmd:CI_Address>

</gmd:address>

</gmd:CI_Contact>

</gmd:contactInfo>

<gmd:role>

<!-- CI_RoleCode names: pointOfContact is mandatory for at least one distributor responsible party -->

<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode"codeListValue="pointOfContact">point of contact</gmd:CI_RoleCode>

</gmd:role>

</gmd:CI_ResponsibleParty>

</gmd:distributorContact>

</gmd:MD_Distributor>

</gmd:distributor>

<gmd:transferOptions>

<gmd:MD_DigitalTransferOptions>

<gmd:onLine>

<gmd:CI_OnlineResource>

<!-- The CI_OnlineResource/linkage/URL element must contain complete URL to access the resource -->

<gmd:linkage>

<gmd:URL>http://repository.usgin.org/uri_gin/usgin/dlio/337</gmd:URL>

</gmd:linkage>

</gmd:CI_OnlineResource>

</gmd:onLine>

</gmd:MD_DigitalTransferOptions>

</gmd:transferOptions>

</gmd:MD_Distribution>

</gmd:distributionInfo>

</gmd:MD_Metadata>

8.2 USGIN ISO 19139 Dataset Metadata

In the following listing, text in green is comments; XML elements are in blue, XML attributes are in red, and attribute values are in purple.

This example metadata record describes a scanned well log document.

<?xml version="1.0" encoding="UTF-8"?>

<!--*************************************************************************************************

*** Example ISO 19139 Geospatial Dataset Metadata based on the USGIN v1.2 Profile

*** by USGIN Standards and Protocols Drafting Team

*** U.S. Geoscience Information System (USGIN) - http://lab.usgin.org

*** Contributors: Wolfgang Grunberg, Stephen M Richard

*** 2013-06-14

***

*** DISCLAIMER: this is not an authoritative metadata example but an aide to get started; refer to

*** the USGIN profile document for more specific and complete guidelines.

***

*** Validated against http://www.isotc211.org/2005/gmd (ISO 19115, CSW 2.0.2 AP ISO 1.0).

*** Follows the USGIN ISO 19139 Dataset Metadata Profile v1.2.

***

*** NOTES:

*** - Codelists:

*** Most ISO metadata profiles and applications use ISO codelists. The codeList attribute points to a Uniform Resource Locator (URL) that locates a resource describing the code list values. It can be a URN or a URL.

***

*** KEY: - M/C/O/X (Mandatory, Conditional, Optional, Not Used)

***

**********************************************************************************************-->

<!-- USGIN ISO 19139 geospatial dataset metadata record -->

<gmd:MD_Metadata xmlns="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gmi="http://www.isotc211.org/2005/gmi" xmlns:gml="http://www.opengis.net/gml" xmlns:gmx="http://www.isotc211.org/2005/gmx" xmlns:gts="http://www.isotc211.org/2005/gts" xmlns:srv="http://www.isotc211.org/2005/srv" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.isotc211.org/2005/gmd http://schemas.opengis.net/csw/2.0.2/profiles/apiso/1.0.0/apiso.xsd">

<!-- (M) Unique Identifier for the metadata record - USGIN recommends using a valid Universally Unique Identifier (UUID) -->

<gmd:fileIdentifier>

<gco:CharacterString>00C02E67-F1ED-473DA240068CCB041A73</gco:CharacterString>

</gmd:fileIdentifier>

<!-- (M) Metadata language ISO639-2/T three letter language code - lower case. --> <gmd:language>

<gco:CharacterString>eng</gco:CharacterString>

</gmd:language>

<!-- (M) Metadata character set - default is "utf8", USGIN requires that a character set code is defined to facilitate CSW servers (deegree, GeoNetwork, etc.). -->

<gmd:characterSet>

<!-- MD_CharacterSetCode names: {ucs2, ucs4, utf7, utf8, utf16, 8859part1, 8859part2, 8859part3, 8859part4, 8859part5, 8859part6, 8859part7, 8859part8, 8859part9, 8859part10, 8859part11, 8859part13, 8859part14, 8859part15, 8859part16, jis, shiftJIS, eucJP, usAscii, ebcdic, eucKR, big5, GB2312}. -->

<gmd:MD_CharacterSetCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_CharacterSetCode" codeListValue="utf8">UTF-8</gmd:MD_CharacterSetCode>

</gmd:characterSet>

 

<!-- (M-M) Resource type - Define if this record is a: dataset (default), service, feature, software, etc. -->

<gmd:hierarchyLevel>

<!-- MD_ScopeCode code names: {attribute, attributeType, collectionHardware, col-lectionSession, dataset, series, nonGeographicDataset, dimensionGroup, feature, fea-tureType, propertyType, fieldSession, software, service, model, tile}. -->

<gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode>

</gmd:hierarchyLevel>

<!-- (O-M) Resource hierarchy level name - USGIN makes this property mandatory to identify the USGIN resource type (see USGIN Profile, "Resources of Interest"). Default USGIN hierarchyLevelName CharacterString is “Dataset". Encode hierarchy by including hierarchyLevelName elements for all broader resource categories. E.g. default should also include a hierarchyLevelName="Collection" element. For services USGIN hierarchyLevelName.CharacterString is “Service" -->

<gmd:hierarchyLevelName>

<gco:CharacterString>Dataset</gco:CharacterString>

</gmd:hierarchyLevelName>

<gmd:hierarchyLevelName>

<gco:CharacterString>Collection</gco:CharacterString>

</gmd:hierarchyLevelName>

<!-- (M-M) Metadata point of contact - Point of contact use- to report errors, updates to metadata -->

<gmd:contact>

<gmd:CI_ResponsibleParty>

<!-- (M-M) (individualName + organisationName + positionName) > 0 -->

<gmd:individualName>

<gco:CharacterString>Stephen Richard</gco:CharacterString>

</gmd:individualName>

<gmd:organisationName>

<gco:CharacterString>Arizona Geological Survey</gco:CharacterString>

</gmd:organisationName>

<gmd:positionName>

<gco:CharacterString>Metadata Czar</gco:CharacterString>

</gmd:positionName>

<gmd:contactInfo>

<gmd:CI_Contact>

<gmd:phone>

<gmd:CI_Telephone>

<gmd:voice>

<gco:CharacterString>520.770.3500</gco:CharacterString>

</gmd:voice>

<gmd:facsimile>

<gco:CharacterString>520.770.3505</gco:CharacterString>

</gmd:facsimile>

</gmd:CI_Telephone>

</gmd:phone>

<gmd:address>

<gmd:CI_Address>

<gmd:deliveryPoint>

<gco:CharacterString>416 W. Congress St., Suite 100</gco:CharacterString>

</gmd:deliveryPoint>

<gmd:city>

<gco:CharacterString>Tucson</gco:CharacterString>

</gmd:city>

<gmd:administrativeArea>

<gco:CharacterString>Arizona</gco:CharacterString>

</gmd:administrativeArea>

<gmd:postalCode>

<gco:CharacterString>85701-1381</gco:CharacterString>

</gmd:postalCode>

<gmd:country>

<gco:CharacterString>USA</gco:CharacterString>

</gmd:country>

<!-- (O-M) Metadata point of contact e-mail address - mandatory if voice phone number not supplied -->

<gmd:electronicMailAddress>

<gco:CharacterString>metadata@azgs.az.gov</gco:CharacterString>

</gmd:electronicMailAddress>

</gmd:CI_Address>

</gmd:address>

<!-- (O-O) online resources - this is the online resource to contact the metadata person-->

<gmd:onlineResource>

<gmd:CI_OnlineResource>

<gmd:linkage>

<gmd:URL>http://www.azgs.az.gov</gmd:URL>

</gmd:linkage>

<gmd:protocol>

<gco:CharacterString>http</gco:CharacterString>

</gmd:protocol>

<gmd:description>

<gco:CharacterString>Arizona Geological Survey Web Site</gco:CharacterString>

</gmd:description>

</gmd:CI_OnlineResource>

</gmd:onlineResource>

<gmd:hoursOfService>

<gco:CharacterString>8 AM to 5 PM Mountain Standard time (no daylight savings)</gco:CharacterString>

</gmd:hoursOfService>

<gmd:contactInstructions>

<gco:CharacterString>Contact Steve Rauzi [Ste-ve.Rauzi@azgs.az.gov] or call Oil and Gas Commission Staff at Arizona Geological Survey, 520-770-3500.</gco:CharacterString>

</gmd:contactInstructions>

</gmd:CI_Contact>

</gmd:contactInfo>

<!-- (M-M) ISO 19139 Mandatory: contact role -->

<gmd:role>

<!-- a responsible party with role=pointOfContact is manda-tory for metadata contact -->

<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="pointOfContact">pointOfContact</gmd:CI_RoleCode>

</gmd:role>

</gmd:CI_ResponsibleParty>

</gmd:contact>

<!-- (X-O) Metadata should include a URL that locates a thumbnail logo for organizations related to the metadata origination, the organization hosting the catalog that returned the metadata, the organization that originated the data, and the organization hosting online services that provide access to the data. -->

<gmd:contact>

<gmd:CI_ResponsibleParty>

<gmd:organisationName>

<gco:CharacterString>Arizona Geological Survey</gco:CharacterString>

</gmd:organisationName>

<gmd:contactInfo>

<gmd:CI_Contact>

<gmd:address>

<gmd:CI_Address>

<gmd:electronicMailAddress gco:nilReason="missing">

<gco:CharacterString>metadata@usgin.org</gco:CharacterString>

</gmd:electronicMailAddress>

</gmd:CI_Address>

</gmd:address>

<gmd:onlineResource>

<gmd:CI_OnlineResource>

<!-- Icon image file (e.g. tif, png, jpg, gif) for the metadata originator. This Icon will be displayed in search results to credit the metadata originator. -->

<gmd:linkage>

<gmd:URL>http://www.azgs.az.gov/logo/metadata/azgs.png</gmd:URL>

</gmd:linkage>

<!-- URL that locates an icon thumbnails, the CI_OnlineResource/name MUST be 'icon' -->

<gmd:name>

<gco:CharacterString>icon</gco:CharacterString>

</gmd:name>

</gmd:CI_OnlineResource>

</gmd:onlineResource>

</gmd:CI_Contact>

</gmd:contactInfo>

<!-- none of the codelist roles are applicable -->

<gmd:role gco:nilReason="inapplicable"/>

</gmd:CI_ResponsibleParty>

</gmd:contact>

<!-- (M-M) Metadata date stamp - USGIN profile requires use of dateS-tamp/gco:DateTime (Note this contrasts with INSPIRE mandate to use dateS-tamp/gco:Date). This is the date and time when the metadata record was created or up-dated (following NAP). -->

<gmd:dateStamp>

<gco:DateTime>2009-11-17T10:00:00</gco:DateTime>

</gmd:dateStamp>

<!-- (M-M) USGIN profile conformant metadata is indicated by using “ISO-USGIN" -->

<gmd:metadataStandardName>

<gco:CharacterString>ISO-USGIN</gco:CharacterString>

</gmd:metadataStandardName>

<!-- (O-M) USGIN profile version, mandatory in this profile -->

<gmd:metadataStandardVersion>

<gco:CharacterString>1.2</gco:CharacterString>

</gmd:metadataStandardVersion>

<!-- (O-C) Dataset Identifier - For USGIN, this is a string that uniquely identifies the de-scribed resource. If the resource has an identifier, it should be included here; if the re-source will be referenced from other metadata, it must have an identifier here. If the da-taset is coupled to a service, the value of the MD_Metadata/dataSetURI attribute is the unique resource identifier used by srv:coupledResource to link the service with the da-taset. For the USGIN profile, the MD_Distribution/transferOptions/MD_DigitalTransferOptions/ online/CI_OnlineResource is used to specify URLs for access to the resource. -->

<gmd:dataSetURI>

<gco:CharacterString>http://azgs.az.gov/resource/00C02E67-F1ED-473D-A240-068CCB041A73</gco:CharacterString>

</gmd:dataSetURI>

<!-- gmd:local would be here, but USGIN profile convention is that each catalog service is specific to one language, rather that expecting clients to be able to process gmd:PT_Locale and gmd:LocalisedCharacterString. gmd:local elements may be ignored by USGIN clients -->

<!-- (O-O) Resource spatial representation - Spatial representation information for the da-taset (resource). Best practice is to include metadata for spatial representation if the de-scribed resource is a georeferenced dataset. -->

<!-- in this example, the described resource is a document that does not contain geolo-cated data items, so spatial representation is not applicable -->

<gmd:spatialRepresentationInfo gco:nilReason="inapplicable"/>

<!-- (O-O) Resource's spatial reference system - Description of the spatial and/or tem-poral reference systems used in the dataset. If {/MD_SpatialRepresentationTypeCode = "vector") or (../MD_SpatialRepresentationTypeCode = "grid") or (../MD_SpatialRepresentationTypeCode = "tin") then count referenceSystemInfo >= 1) }not applicable to the document described by this record -->

<gmd:referenceSystemInfo gco:nilReason="inapplicable"/>

<!-- ****************************************************************************** -->

<!-- (M-M) Resource identification information - At least one of MD_DataIdentification (da-taset, dataset series) or SV_ServiceIdentification (service) is required. -->

<gmd:identificationInfo>

<!-- Resource Dataset or Dataset Series Identification. In practice, anything that is not a service is described using MD_DataIdentification -->

<gmd:MD_DataIdentification>

<!-- (M-M) Resource citation - Information to identify the intellectual origin of the content in the described resource, along the lines of a citation in a scientific journal. Required content for a CI_Citation element are title, date, and responsibleParty. If the subject of the metadata record is derived from other sources, such that it is not considered identical with those sources, the provenance should be documented in LI_Lineage//LI_Source elements. -->

<gmd:citation>

<gmd:CI_Citation>

<!-- (M-M) Resource title - Use titles that inform the human reader about the da-taset's content; titles should be unique in the context of the metadata catalog that contains the metadata record. -->

<gmd:title>

<gco:CharacterString>

Scanned Borehole Compensated Sonic Log for 0391, Kerr-McGee08 Navajo

</gco:CharacterString>

</gmd:title>

<!-- (M-M) Resource reference date - Best practice is to include at least the date of publi-cation or creation of the resource. The date of the resource reported in the citation corre-sponds to the resource's last update version according to its update frequency. CI_Date content includes a date and dateType. Date for USGIN profile uses gco:DateTime. -->

<gmd:date>

<gmd:CI_Date>

<gmd:date>

<!-- Requires an extended ISO 8601 UTC date and time string (YYYY-MM DDTHH:MM:SS) Some validators require time zone as well; recommend GMT indicated by 'Z' -->

<gco:DateTime>2001-12-17T09:30:47</gco:DateTime>

</gmd:date>

<gmd:dateType>

<!-- dateType is mandatory per ISO19115 -->

<!-- CI_DateTypeCode values in citation context: {creation, publication, revision}. -->

<gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="publication">publication</gmd:CI_DateTypeCode>

</gmd:dateType>

</gmd:CI_Date>

</gmd:date>

<!-- (C-C) Unique resource identifier - For USGIN purposes, this element content value should be considered an identifier for the citation, without any assumption that it will use http protocol. The identifier may be resolvable to a URL, if a protocol prefix specifies an identifier scheme that is resolvable (e.g. http, doi...), but this is not necessary for a valid document, and should not be assumed when processing metadata documents. IF the Ci-tation has an identifier that is different from the identifier for the described resource (MD_Metadata/dataSetURI), it must be included here. The USGIN profile requires use of MD_Identifer. If additional codespace and version content is associated with the identifier, it should be encoded as MD_Identifier/authority/ CI_Citation/ alternateTitle and MD_Identifier/ authority/ CI_Citation/ edition -->

<gmd:identifier>

<gmd:MD_Identifier>

<gmd:code>

<!-- 13 digit ISBN example -->

<gco:CharacterString>isbn:000-0-000-00000-0</gco:CharacterString>

</gmd:code>

</gmd:MD_Identifier>

</gmd:identifier>

<!-- (M-M) Resource responsible party - The citation attribute provides information for cit-ing the intellectual origin of the described resource, analogous to a citation in a scientific journal. The citedResponsibleParty should specify the individual(s) and organizations re-sponsible for the creation or origination of the resource. For most intellectual content, the responsible party is what would normally be considered the author of a work. -->

<!-- in the context of the well log described by this example, the originator should be considered the operator who ran the log (individualName), or the logging company that ran the log; the drilling operator migh also be considered as originator. Unfortuantely, in this case that information is missing, so the provided contact information is for the custodian, not the author or originator. -->

<gmd:citedResponsibleParty>

<gmd:CI_ResponsibleParty>

<!-- (M-M) (individualName + organisationName + positionName) > 0 -->

<gmd:individualName>

<gco:CharacterString>Steve Rauzi</gco:CharacterString>

</gmd:individualName>

<gmd:organisationName>

<gco:CharacterString>Arizona Geological Survey</gco:CharacterString>

</gmd:organisationName>

<gmd:positionName>

<gco:CharacterString>Oil and Gas Administrator</gco:CharacterString>

</gmd:positionName>

<!-- cited responsible party contact information, either a voice phone number or e-mail address is required. Everything else is optional -->

<gmd:contactInfo>

<gmd:CI_Contact>

<gmd:phone>

<gmd:CI_Telephone>

<gmd:voice>

<gco:CharacterString>520-770-3500</gco:CharacterString>

</gmd:voice>

<gmd:facsimile>

<gco:CharacterString>520-770-3505</gco:CharacterString>

</gmd:facsimile>

</gmd:CI_Telephone>

</gmd:phone>

<gmd:address>

<gmd:CI_Address>

<gmd:deliveryPoint>

<gco:CharacterString>416 W. Congress St., Suite 100</gco:CharacterString>

</gmd:deliveryPoint>

<gmd:city>

<gco:CharacterString>Tucson</gco:CharacterString>

</gmd:city>

<gmd:administrativeArea>

<gco:CharacterString>Arizona</gco:CharacterString>

</gmd:administrativeArea>

<gmd:postalCode>

<gco:CharacterString>85701</gco:CharacterString>

</gmd:postalCode>

<gmd:country>

<gco:CharacterString>USA</gco:CharacterString>

</gmd:country>

<gmd:electronicMailAddress>

<gco:CharacterString>Steve.rauzi@azgs.az.gov</gco:CharacterString>

</gmd:electronicMailAddress>

</gmd:CI_Address>

</gmd:address>

</gmd:CI_Contact>

</gmd:contactInfo>

<!-- (M-M) ISO 19139 Mandatory: contact role -->

<gmd:role>

<!-- CI_RoleCode values in this context: {originator, principalInvestigator, processor, author, custodian} -->

<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="custodian">custodian</gmd:CI_RoleCode>

</gmd:role>

</gmd:CI_ResponsibleParty>

</gmd:citedResponsibleParty>

<!-- (O-C) Dataset Presentation Form - The form in which the original cited resource is available. Note that the citation is to the original source of intellectual content in the de-scribed resource, and its presentation may be different from the format for distribution de-scribed in the metadata. This element should be specified if there is a difference between the cited resource presentation format and the distribution format(s) listed in the distribu-tionInfo/MD_Distribution section of the metadata record. This information is mostly for documentation; for discovery and data access, the distribution formats are more relevant. -->

<!-- in this example, the original log was acquired by a pen on a strip chart recorder... -->

<gmd:presentationForm>

<!-- CI_PresentationFormCode names: {documentDigital, documentHardcopy, im-ageDigital, image-Hardcopy, mapDigital, mapHardcopy, modelDigital, model-Hardcopy, profileDigital, profileHardcopy, tableDigital, tableHardcopy, videoDigital, videoHardcopy, audioDigital} -->

<gmd:CI_PresentationFormCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_PresentationFormCode" codeListValue="documentHardcopy">hardcopy on pa-per</gmd:CI_PresentationFormCode>

</gmd:presentationForm>

<!-- (O-O) Resource series - Information about the series or collection of which the cited resource is a part. -->

<gmd:series>

<gmd:CI_Series>

<gmd:name>

<!-- Name of the publication series or aggregate dataset of which the referenced dataset is a part. -->

<gco:CharacterString>AZGS well log library</gco:CharacterString>

</gmd:name>

</gmd:CI_Series>

</gmd:series>

<!-- (O-O) Resource other citation details; Recommended practice: a complete recommended bibliographic citation should be specified in this element. -->

<gmd:otherCitationDetails>

<gco:CharacterString>

Scanned Borehole Compensated Sonic Log for 0391, Kerr-McGee08 Navajo,1967: Tucson, AZ, Arizona Geological Survey Well Log Li-brary, scanned log file, 1 pdf document.

</gco:CharacterString>

</gmd:otherCitationDetails>

<!-- (O-C) Resource collective title - Title of the combined resource that the cited resource is part of, for example the cited resource may be a paper in an anthology, in which case the anthology title would be the collective title. Required if the cited resource is part of such a collective work. -->

<gmd:collectiveTitle gco:nilReason="inapplicable"/>

</gmd:CI_Citation>

</gmd:citation>

<!-- (M-M) Resource Abstract - A free text summary of the content, significance, purpose, scope, etc. of the resource. Exactly one value. -->

<gmd:abstract>

<gco:CharacterString>Digital files containing Tiff images of scanned logs. Scanned using Neutra scanner hardware. Well penetrates Co-conino, Hermosa, Mississippian, Devonian (McCraken, Aneth) and bottoms in Precambrian. Total depth 3647 feet. No other logs were run. Well abandoned in 1973. </gco:CharacterString>

</gmd:abstract>

<!-- (O-O) Resource purpose - Summary of the intentions for which the dataset was developed. Purpose includes objectives for creating the dataset and what the dataset is to support. No USGIN conventions for use of this element. -->

<gmd:purpose/>

<!-- (O-O) Resource Status - -->

<gmd:status>

<!-- MD_ProgressCode: For USGIN discovery metadata, values should be re-stricted to {completed, onGoing, deprecated}. Obsolete is synonymous with deprecated. -->

<gmd:MD_ProgressCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ProgressCode" codeListValue="completed">completed</gmd:MD_ProgressCode>

</gmd:status>

<!-- (O-C) Resource point of contact - CI_ResponsibleParty element contains information for point of contact to access the resource. This information is mandatory for physical resources such as core, cuttings, samples, manuscripts -->

<gmd:pointOfContact>

<gmd:CI_ResponsibleParty>

<!-- (M-M) (individualName + organisationName + positionName) > 0 -->

<gmd:individualName>

<gco:CharacterString>Steve Rauzi</gco:CharacterString>

</gmd:individualName>

<gmd:organisationName>

<gco:CharacterString>Arizona Geological Survey</gco:CharacterString>

</gmd:organisationName>

<gmd:positionName>

<gco:CharacterString>Oil and Gas Administrator</gco:CharacterString>

</gmd:positionName>

<!-- (O-C) Contact Information - If a resource point of contact is required then (phone + deliveryPoint + electronicMailAddress) > 0. -->

<gmd:contactInfo>

<gmd:CI_Contact>

<gmd:phone>

<gmd:CI_Telephone>

<gmd:voice>

<gco:CharacterString>520-770-3500</gco:CharacterString>

</gmd:voice>

<gmd:facsimile>

<gco:CharacterString>520-770-3505</gco:CharacterString>

</gmd:facsimile>

</gmd:CI_Telephone>

</gmd:phone>

<gmd:address>

<gmd:CI_Address>

<gmd:deliveryPoint>

<gco:CharacterString>416 W. Congress St., Suite 100</gco:CharacterString>

</gmd:deliveryPoint>

<gmd:city>

<gco:CharacterString>Tucson</gco:CharacterString>

</gmd:city>

<gmd:administrativeArea>

<gco:CharacterString>Arizona</gco:CharacterString>

</gmd:administrativeArea>

<gmd:postalCode>

<gco:CharacterString>85701</gco:CharacterString>

</gmd:postalCode>

<gmd:country>

<gco:CharacterString>USA</gco:CharacterString>

</gmd:country>

<gmd:electronicMailAddress>

<gco:CharacterString>Steve.rauzi@azgs.az.gov</gco:CharacterString>

</gmd:electronicMailAddress>

</gmd:CI_Address>

</gmd:address>

</gmd:CI_Contact>

</gmd:contactInfo>

<!-- (M-M) ISO 19139 Mandatory: contact role -->

<gmd:role>

<!-- CI_RoleCode names: ISO role codes for physical resource point of contact are {custodian, owner, pointOfContact}; other point of contact role codes may apply for other resources. -->

<gmd:CI_RoleCode codeList=http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode codeListValue="pointOfContact">point of contact</gmd:CI_RoleCode>

</gmd:role>

</gmd:CI_ResponsibleParty>

</gmd:pointOfContact>

 

<!-- (O-O) Resource Maintenance - This element provides information about the mainte-nance schedule or history of the resource (or some subset/part of the resource specified by the scope and scope description) described by the metadata record. 0 to many MD_MaintenanceInformation elements may be included. -->

<gmd:resourceMaintenance>

<gmd:MD_MaintenanceInformation>

<gmd:maintenanceAndUpdateFrequency>

<!-- MD_MaintenanceFrequencyCode names: {continual, daily, weekly, fort-nightly, monthly, quarterly, biannually, annually, asNeeded, irregular, not-Planned, un-known} -->

<gmd:MD_MaintenanceFrequencyCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_MaintenanceFrequencyCode" codeListValue="asNeeded">as need-ed</gmd:MD_MaintenanceFrequencyCode>

</gmd:maintenanceAndUpdateFrequency>

</gmd:MD_MaintenanceInformation>

</gmd:resourceMaintenance>

<!-- (O-O) Graphic overview of resource - USGIN best practice is to provide xlink:href URL to file if it is available online, as an attribute of the MD_BrowseGraphic element. If MD_BrowseGraphic is included, MD_BrowseGraphic/filename character string is manda-tory. Recommended practice is to use the Anchor extension of CharacterString xml ele-ment from ISO19139, which provides a url as an attribute and a text string as a label for the link. -->

<gmd:graphicOverview>

<gmd:MD_BrowseGraphic>

<!-- file name is required. USGIN Recommended practice is to provide a com-plete URL as the CharacterString value -->

<gmd:fileName>

<gco:CharacterString>

http://azgs.az.gov/resource/00C02E67-F1ED-473D-A240-068CCB041A73/preview.jpg

</gco:CharacterString>

</gmd:fileName>

<gmd:fileDescription>

<gco:CharacterString>preview of scanned well log</gco:CharacterString>

</gmd:fileDescription>

<!-- Recommended practice is to provide a registered MIME type -->

<gmd:fileType>

<gco:CharacterString>image/jpg</gco:CharacterString>

</gmd:fileType>

</gmd:MD_BrowseGraphic>

</gmd:graphicOverview>

<!-- (X-X) Resource Format - This element is not used by NAP or USGIN; this information is encoded in MD_Metadata/distributionInfo/MD_Distribution/ in USGIN metadata. -->

<gmd:resourceFormat/>

<!-- (O-O) Resource keywords - Best Practice for USGIN profile metadata is to supply keywords to facilitate the discovery of metadata records relevant to the user. USGIN re-quires that MD_Keyword/keyword contain a CharacterString. USGIN best practice is to include keywords in English -->

<!-- Theme keywords -->

<gmd:descriptiveKeywords>

<gmd:MD_Keywords>

<gmd:keyword>

<gco:CharacterString>Scanned Gamma Ray Neutron</gco:CharacterString>

</gmd:keyword>

<gmd:keyword>

<gco:CharacterString>NMAL</gco:CharacterString>

</gmd:keyword>

<gmd:keyword>

<gco:CharacterString>borehole</gco:CharacterString>

</gmd:keyword>

<!-- Keyword Type: allowed values from MD_KeywordTypeCode names:{discipline, place, stratum, temporal, theme} -->

<gmd:type>

<gmd:MD_KeywordTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MDKeywordTypeCode" codeListValue="theme">theme</gmd:MD_KeywordTypeCode>

</gmd:type>

</gmd:MD_Keywords>

</gmd:descriptiveKeywords>

<!-- Temporal keywords -->

<gmd:descriptiveKeywords>

<gmd:MD_Keywords>

<gmd:keyword>

<gco:CharacterString>Frasian</gco:CharacterString>

</gmd:keyword>

<gmd:keyword>

<gco:CharacterString>Upper Devonian</gco:CharacterString>

</gmd:keyword>

<gmd:keyword>

<gco:CharacterString>Devonian</gco:CharacterString>

</gmd:keyword>

<gmd:keyword>

<gco:CharacterString>Paleozoic</gco:CharacterString>

</gmd:keyword>

<!-- Keyword Type - allowed values from MD_KeywordTypeCode names: {discipline, place, stratum, temporal, theme} -->

<gmd:type>

<gmd:MD_KeywordTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_KeywordTypeCode" codeListValue="temporal">temporal</gmd:MD_KeywordTypeCode>

</gmd:type>

</gmd:MD_Keywords>

</gmd:descriptiveKeywords>

<!-- Place keywords; if a resource is not associated with a spatial location, the key-word 'non-geographic' should be included as a place keyoword -->

<gmd:descriptiveKeywords>

<gmd:MD_Keywords>

<gmd:keyword>

<gco:CharacterString>Arizona</gco:CharacterString>

</gmd:keyword>

<gmd:keyword>

<gco:CharacterString>T41N R27E S22 NE NE</gco:CharacterString>

</gmd:keyword>

<gmd:type>

<!-- Keyword Type - allowed values from MD_KeywordTypeCode names: {discipline, place, stratum, temporal, theme} -->

<gmd:MD_KeywordTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_KeywordTypeCode" codeListValue="place">place</gmd:MD_KeywordTypeCode>

</gmd:type>

</gmd:MD_Keywords>

</gmd:descriptiveKeywords>

<!-- (O-O) Condition applying to access and use of resource - Follow NAP for specifica-tion of resourceConstraints. This attribute provides information for access control to the described resource itself. In some situations, the metadata may allow a user to learn of the existence of a resource that they may not actually be able to access without further clearance. Constraints may be represented by MD_Constraint, MD_LegalConstraint, or MD_SecurityConstraint.

Example here of license statement. -->

 

<gmd:resourceConstraints>
<gmd:MD_LegalConstraints>
<gmd:useLimitation>
<gco:CharacterString>License: CC-BY 4.0 (http://creativecommons.org/licenses/by/4.0/):
Attribution -- You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
No additional restrictions -- You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
Notices: You do not have to comply with the license for elements of the material in the public domain or where your use is permitted by an applicable exception or limitation.
No warranties are given. The license may not give you all of the permissions necessary for your intended use. For example, other rights such as publicity, privacy, or moral rights may limit how you use the material.

</gco:CharacterString>
</gmd:useLimitation>
<gmd:useConstraints>
<gmd:MD_RestrictionCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#CI_RestrictionCode" codeListValue="license"/>
</gmd:useConstraints>
</gmd:MD_LegalConstraints>
</gmd:resourceConstraints>

 

<!-- (O-O) Aggregation information - The citation for or name of an aggregate dataset, the type of aggregate dataset, and optionally the activity which produced the dataset. -->

<gmd:aggregationInfo>

<!-- MD_AggregateInformation requires either aggregateDataSetName/CI_Citation or aggregateDataSetIdentifier/MD_Identifier. -->

<gmd:MD_AggregateInformation>

<!-- Related dataset name -->

<gmd:aggregateDataSetName>

<gmd:CI_Citation>

<gmd:title>

<gco:CharacterString>Related Resource's Title</gco:CharacterString>

</gmd:title>

<gmd:date>

<gmd:CI_Date>

<gmd:date>

<gco:DateTime>2001-12-17T09:30:47</gco:DateTime>

</gmd:date>

<gmd:dateType>

<gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_DateTypeCode" codeListValue="publication">publication</gmd:CI_DateTypeCode>

</gmd:dateType>

</gmd:CI_Date>

</gmd:date>

</gmd:CI_Citation>

</gmd:aggregateDataSetName>

<!-- Data Set Identifier -->

<gmd:aggregateDataSetIdentifier>

<gmd:MD_Identifier>

<gmd:code>

<gco:CharacterString>00000000-0000-0000-0000-000000000000</gco:CharacterString>

</gmd:code>

</gmd:MD_Identifier>

</gmd:aggregateDataSetIdentifier>

<!-- (M-M) Association Type is mandatory.. -->

<gmd:associationType>

<!-- Use DS_AssociationTypeCode names: {crossReference, largerWorkCitation, partOfSeamlessDatabase, source, stereoMate} -->

<gmd:DS_AssociationTypeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#DS_AssociationTypeCode" codeListValue="crossReference">cross reference</gmd:DS_AssociationTypeCode>

</gmd:associationType>

</gmd:MD_AggregateInformation>

</gmd:aggregationInfo>

<!-- (M-M) Resource language - Multiple instances of this element indicate that the lin-guistic content of the resource is available in multiple languages -->

<gmd:language>

<!-- use ISO639-2/T three letter language code in lower case. -->

<gco:CharacterString>eng</gco:CharacterString>

</gmd:language>

<!-- character encoding of resource content. Not applicable to scanned image -->

<gmd:characterSet gco:nilReason="inapplicable"/>

<!-- (C-C) Topic category - A topicCategory code must be provided when hierarchyLevel is set to "dataset" (this example document) or "dataset series". Most USGIN resources will have MD_TopicCategoryCode = "geoscientificInformation", which is the default value for this profile. More specific topic categorization should be done using keywords. -->

<gmd:topicCategory>

<!-- MD_TopicCategoryCode names: {farming, biota, boundaries, climatologyMeterol-ogyAtmosphere, economy, elevation, environment, geoscientificInformation, health, im-ageryBaseMapsEarthCover, intelligenceMilitary, inlandWater, location, oceans, planning-Cadastre, society, structure, transportation, utilitiesCommunication} -->

<gmd:MD_TopicCategoryCode>geoscientificInformation</gmd:MD_TopicCategoryCode>

</gmd:topicCategory>

<!-- (C-C) Resource content extent - Defines the spatial (horizontal and vertical) and tem-poral region to which the content of the resource applies. For USGIN, a ge-ographicElement/geographic-BoundingBox must be provided for any resource with con-tent related to some geographic location. If the described resource is not related to a geo-graphic area, the place keyword 'non-geographic' should be included in the descriptive-Keywords element. -->

<gmd:extent>

<gmd:EX_Extent>

<!-- (C-C) Resource Content extent description - Free text that describes the spatial and temporal extent of the dataset. Note that if geographic place names are used to express the geographic extent, USGIN profile specifies that these should be encoded using key-word with keyword type code = 'place.' Geographic names may be duplicated in EX_Extent/description.-->

<gmd:description>

<gco:CharacterString>Some spatial/temporal description.</gco:CharacterString>

</gmd:description>

<gmd:geographicElement>

<!-- (O-C) Resource content extent bounding box -USGIN profile requires a geographic bounding box with bounding latitude and longitude expressed using WGS 84 decimal de-grees. The corner coordinates for the geographic bounding box must not coincide in one point, because this may result in fatal errors with some CSW implementations. Point loca-tions must thus be represented as tiny rectangles. USGIN recommended practice is to place the actual point location in the lower left corner of the rectangle. -->

<gmd:EX_GeographicBoundingBox>

<gmd:extentTypeCode>

<gco:Boolean>1</gco:Boolean>

</gmd:extentTypeCode>

<gmd:westBoundLongitude>

<gco:Decimal>-109.911001</gco:Decimal>

</gmd:westBoundLongitude>

<gmd:eastBoundLongitude>

<gco:Decimal>-109.910999</gco:Decimal>

</gmd:eastBoundLongitude>

<gmd:southBoundLatitude>

<gco:Decimal>34.772899</gco:Decimal>

</gmd:southBoundLatitude>

<gmd:northBoundLatitude>

<gco:Decimal>34.772901</gco:Decimal>

</gmd:northBoundLatitude>

</gmd:EX_GeographicBoundingBox>

</gmd:geographicElement>

</gmd:EX_Extent>

 

<!-- (C-X) Resource content extent geographic description - Not used by USGIN profile, use keyword with type code = 'place' (with thesaurus if necessary). -->

<!-- (C-X) Resource content extent bounding polygon - Not used by USGIN profile. To improve interoperability, USGIN mandates the use of Geographic Bounding Box; if bounding polygons are available they may be included, but clients may ignore content in this element. -->

<!--

<gmd:geographicElement>

<gmd:EX_BoundingPolygon/>

</gmd:geographicElement> -->

</gmd:extent>

<!-- (O-O) Resource temporal extent - -->

<gmd:extent>

<gmd:EX_Extent>

<gmd:temporalElement>

<gmd:EX_TemporalExtent>

<gmd:extent>

<!-- Geologic time frame example -->

<gml:TimePeriod gml:id="IdJurassic">

<gml:name>Jurassic</gml:name>

<!-- USGIN requires the beginPosition and endPosition's frame property to be defined. urn:cgi:trs:CGI:StandardGeologicTimeMa identifies the standard Geologic time scale frame. -->

<gml:beginPosition frame="urn:cgi:trs:CGI:StandardGeologicTimeMa">203</gml:beginPosition>

<gml:endPosition frame="urn:cgi:trs:CGI:StandardGeologicTimeMa ">135</gml:endPosition>

</gml:TimePeriod>

</gmd:extent>

</gmd:EX_TemporalExtent>

</gmd:temporalElement>

</gmd:EX_Extent>

</gmd:extent>

<!-- (O-X) Resource spatio-temporal extent - Not used. USGIN mandates encoding space time location with EX_TemporalExtent and EX_GeographicBoundingBox -->

<!-- (O-O) Resource vertical extent -->

<gmd:extent>

<gmd:EX_Extent>

<gmd:verticalElement>

<gmd:EX_VerticalExtent>

<gmd:minimumValue>

<gco:Real>-100</gco:Real>

</gmd:minimumValue>

<gmd:maximumValue>

<gco:Real>200</gco:Real>

</gmd:maximumValue>

<!-- Use EPSG register of geodetic parameters such as at http://www.epsg-registry.org/. The default VerticalCRS is World mean sea level (MSL): http://www.spatialreference.org/ref/epsg/5714/ (replaces urn:ogc:def:crs:EPSG::5714) -->

<gmd:verticalCRS xlink:href="http://www.spatialreference.org/ref/epsg/5714/">

</gmd:verticalCRS>

</gmd:EX_VerticalExtent>

</gmd:verticalElement>

</gmd:EX_Extent>

</gmd:extent>

</gmd:MD_DataIdentification>

</gmd:identificationInfo>

<!-- **************************************************************** -->

<!-- (O-O) Content information - Characteristics describing the feature cataloguecatalog, coverage, or image data. Not applicable to this resource. -->

<gmd:contentInfo gco:nilReason="inapplicable"/>

<!-- (O-O) Resource distribution information - This element provides information to inform users how to obtain or access the described resource. NOTE: there are several ways el-ements can be nested within MD_Distribution, please read the MD_Distribution sections in the USGIN profile document. -->

<gmd:distributionInfo>

<gmd:MD_Distribution>

<!-- (O-O) Resource distribution format - Information on the format or physical manifesta-tion of the resource. If the resource is a physical resource, like a book, rock sample, paper document, the distributionFormat/MD_Format/name is mandatory, and must be from the USGIN distribution format codelist. Value is optional for this document resource. -->

<gmd:distributionFormat>

<gmd:MD_Format>

<gmd:name>

<gco:CharacterString>application/pdf</gco:CharacterString>

</gmd:name>

<gmd:version>

<gco:CharacterString>8.0</gco:CharacterString>

</gmd:version>

</gmd:MD_Format>

</gmd:distributionFormat>

<!-- (O-C) Resource distributor information - USGIN differs from NAP in this case (but not with ISO19115) by allowing multiple distributors, and binding between distributors, transfer options, and formats. -->

<gmd:distributor>

<!-- For USGIN profile, each distributor/MD_Distributor is a binding between one or more transfer options and the distributor formats that are available through that/those transfer options (MD_DigitalTransferOptions/onLine/CI_OnlineResource in particular). If different formats are available from the same distributor, or have different transfer options, these should be represented as different distributor/MD_Distributor instances. See the USGIN Profile section 'Use of MD_Distribution and MD_Distributor' for instructions on use of these elements. -->

<gmd:MD_Distributor>

<gmd:distributorContact>

<!-- contact point for questions, comments, problems with accessing the resource through this distribution -->

<gmd:CI_ResponsibleParty>

<gmd:organisationName>

<gco:CharacterString>Arizona Geological Survey</gco:CharacterString>

</gmd:organisationName>

<gmd:contactInfo>

<gmd:CI_Contact>

<gmd:address>

<gmd:CI_Address>

<gmd:electronicMailAddress>

<gco:CharacterString>metadata@usgin.org</gco:CharacterString>

</gmd:electronicMailAddress>

</gmd:CI_Address>

</gmd:address>

</gmd:CI_Contact>

</gmd:contactInfo>

<gmd:role>

<!-- CI_RoleCode codes applicable in this context include: {resourceProvider, dis-tributor, pointOfContact} -->

<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="distributor">distributor</gmd:CI_RoleCode>

</gmd:role>

</gmd:CI_ResponsibleParty>

</gmd:distributorContact>

<!-- (O-C) Resource distributor format - USGIN profile specifies that the distributionIn-fo/MD_Distribution/distributionFormat may be included in the document (its schema val-id...), but distribution format information must be duplicated in a distributionInfo/distributor/MD_Distributor/distributorFormat element or the content can be lost -->

<gmd:distributorFormat>

<gmd:MD_Format>

<!-- Use USGIN distribution format code values. See "Online resource format names" in USGIN Profile -->

<gmd:name>

<-- registered MIME type IETF RFC-3778 -->

<gco:CharacterString>application/pdf</gco:CharacterString>

</gmd:name>

<gmd:version>

<gco:CharacterString>8.0</gco:CharacterString>

</gmd:version>

</gmd:MD_Format>

</gmd:distributorFormat>

<gmd:distributorTransferOptions>

<gmd:MD_DigitalTransferOptions>

<gmd:onLine>

<gmd:CI_OnlineResource>

<gmd:linkage>

<!-- The linkage element should contain the complete URL to access the resource direct-ly. CI_OnlineResource requires a Linkage element that is a gmd:URL. --> <gmd:URL>http://azgs.az.gov/resource/00C02E67-F1ED-473D-A240-068CCB041A73/borehole_report.pdf</gmd:URL>

</gmd:linkage>

<gmd:protocol>

<!-- The protocol element defines a valid internet protocol used to access the resource. Recommended best practice (NAP) is that the protocol mnemonic should be taken from the controlled list of Official Internet Protocol Standards at http://www.rfc-editor.org/rfcxx00.html or the Internet Assigned Numbers Authority (IANA) at http://www.iana.org/protocols. 'ftp' or 'http' are common values. -->

<gco:CharacterString>http</gco:CharacterString>

</gmd:protocol>

<gmd:name>

<!-- The CI_OnlineResource/name element may duplicate the file name if the URL is a link to a file, but it is recommended to provide a user-friendly label for the file for presenta-tion in a user interface. -->

<gco:CharacterString>borehole_report.pdf</gco:CharacterString>

</gmd:name>

<!-- The CI_OnlineResource/description element may include a [[CDATA] section with key values pairs to provide additional necessary information. USGIN recommendataion is to encode these using JSON syntax. -->

<gmd:description>

<gco:CharacterString>Downloadable PDF document</gco:CharacterString>

</gmd:description>

<!-- (O-C) Resource distributor online distribution function - CI_OnlineResource/function is required by USGIN to indicate how linkage is to be used. If the resource is accessible as a web service, the metadata for the service should be separate metadata record with the dataset(s) exposed through the service identified in the service metadata record as cou-pledResources. -->

<gmd:function>

<!-- CI_OnlineFunctionCode names: {download, information, offlineAccess, order, search} -->

<gmd:CI_OnLineFunctionCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_OnLineFunctionCode" codeListValue="download">download</gmd:CI_OnLineFunctionCode>

</gmd:function>

</gmd:CI_OnlineResource>

</gmd:onLine>

</gmd:MD_DigitalTransferOptions>

</gmd:distributorTransferOptions>

</gmd:MD_Distributor>

</gmd:distributor>

<!-- (C-C) Resource distribution transfer options - MD_DigitalTransferOptions provides in-formation on digital distribution of resource. See USGIN Profile 'Use of MD_Distribution and MD_Distributor' for instructions on use of this element. Details on encoding for MD_DigitalTransferOptions are above in the distributorTransferOptions elements description. -->

<gmd:transferOptions>

<gmd:MD_DigitalTransferOptions>

<gmd:onLine>

<gmd:CI_OnlineResource>

<gmd:linkage>

<!-- The linkage element should contain the complete URL to access the resource directly. CI_Online-Resource requires a Linkage element that is a gmd:URL. -->

<gmd:URL>http://azgs.az.gov/resource/00C02E67-F1ED-473D-A240-068CCB041A73/borehole_report.pdf</gmd:URL>

</gmd:linkage>

<gmd:protocol>

<!-- The protocol element defines a valid internet protocol used to access the resource. Recommended best practice (NAP) is that the protocol mnemonic should be taken from the controlled list of Official Internet Protocol Standards at http://www.rfc-editor.org/rfcxx00.html or the Internet Assigned Numbers Authority (IANA) at http://www.iana.org/protocols. 'ftp' or 'http' are common values. -->

<gco:CharacterString>http</gco:CharacterString>

</gmd:protocol>

<!-- (C-C) Resource distributor online distribution application profile - applicationProfile is required if the CI_OnlineResource/linkage does not connect to a web page, and another software application is needed to use the indicated file resource. The applicationProfile character string should specify the software using the following recommended syntax: “vendor:application name/application version", e.g. “Microsoft:Word/2007", or “ESRI:ArcGIS/9.3" -->

<gmd:applicationProfile>

<gco:CharacterString>Adobe:Acrobat/8.0</gco:CharacterString>

</gmd:applicationProfile>

<gmd:name>

<!-- The CI_OnlineResource/name element may duplicate the file name if the URL is a link to a file, but it is recommended to provide a user-friendly label for the file that could be presented in a user interface. -->

<gco:CharacterString>borehole_report.pdf</gco:CharacterString>

</gmd:name>

<gmd:description>

<gco:CharacterString>Downloadable PDF document</gco:CharacterString>

</gmd:description>

<!-- (O-C) Resource distributor online distribution function - CI_OnlineResource/function is required by USGIN to indicate how linkage is to be used. If the resource is accessible as a web service, the metadata for the service should be separate metadata record with the dataset(s) exposed through the service identified in the service metadata record as cou-pledResources. -->

<gmd:function>

<!-- CI_OnlineFunctionCode names: {download, information, offlineAccess, order, search} -->

<gmd:CI_OnLineFunctionCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_OnLineFunctionCode" codeListValue="download">download</gmd:CI_OnLineFunctionCode>

</gmd:function>

</gmd:CI_OnlineResource>

</gmd:onLine>

</gmd:MD_DigitalTransferOptions>

</gmd:transferOptions>

</gmd:MD_Distribution>

</gmd:distributionInfo>

<gmd:dataQualityInfo>

<!-- In this profile, data quality information is optional, but if included, the mandatory content for data quality information is a free text explanation of data quality considerations. The DQ_DataQuality[1]//report[1]//explanation/CharacterString element should contain a free text discussion/description of data quality considerations for the indicated scope. The use of any specific data quality element to contain this explanation is arbitrary and should not be considered meaningful in this context. -->

<gmd:DQ_DataQuality>

<gmd:scope>

<gmd:DQ_Scope>

<gmd:level>

<!-- MD_ScopeCode values for discovery metadata: {collectionHardware, collec-tionSession, dataset, series, dimensionGroup, fieldSession, software, service, model, tile} -->

<gmd:MD_ScopeCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode>

</gmd:level>

<!-- (C-C) Data quality scope level description - Not used by USGIN -->

</gmd:DQ_Scope>

</gmd:scope>

<report>

<!-- This is a container for a free text discussion/description of data quality considerations for the indicated scope. The use of any specific data quality element (e.g. DQ_DomainConsistency here) to contain this explanation is arbitrary and should not be considered meaningful in this context. -->

<DQ_DomainConsistency>

<result>

<DQ_ConformanceResult>

<specification gco:nilReason="notApplicable"/>

<explanation>

<gco:CharacterString>Quality Statement: Original paper quality was poor quality, parts of scan are difficult to read. Scan resolution is 300 dpi.

</gco:CharacterString>

</explanation>

<pass gco:nilReason="inapplicable"/>

</DQ_ConformanceResult>

</result>

</DQ_DomainConsistency>

</report>

<!-- (C-C) Resource lineage - count(lineage/LI_Lineage/source + line-age/LI_Lineage/sourceStep + lineage/LI_Lineage/statement ) >0 for spatial dataset and spatial dataset series. Not applicable to services. -->

<gmd:lineage>

<gmd:LI_Lineage>

<!-- (C-C) Data quality lineage statement - General explanation of the data producer's knowledge of the dataset lineage. This is probably the most useful thing to supply. -->

<gmd:statement>

<gco:CharacterString>

This dataset is maintained by the Arizona Geological Survey. Paper logs were obtained from the permitee and are on file at the Arizona Geological Survey. Logs were scanned in 2005 by S. J. Rauzi. Digital files are archived at the Arizona Geological Survey.

</gco:CharacterString>

</gmd:statement>

<!-- (C-C) Data quality lineage process step - An event in the development of the dataset. Best practice recommended for USGIN is that source association from a process step is to inputs to a process, and processStep associations from a source element link an output resource to a process step that produced it. -->

<gmd:processStep>

<gmd:LI_ProcessStep>

<gmd:description>

<gco:CharacterString>A detailed description of the scanning process could be included here. </gco:CharacterString>

</gmd:description>

</gmd:LI_ProcessStep>

</gmd:processStep>

<!-- (C-C) Data quality lineage source - not applicable in this example -->

<gmd:source/>

</gmd:LI_Lineage>

</gmd:lineage>

</gmd:DQ_DataQuality>

</gmd:dataQualityInfo>

<!-- (O-O) Metadata constraint information - This element specifies use constraints for access to the metadata record. -->

<gmd:metadataConstraints>

<!-- Constraints -->

<gmd:MD_Constraints>

<!-- metadataConstraints/MD_Constraints/useLimitation is mandatory when MD_Constraints is used to specify metadataConstraints. -->

<gmd:useLimitation>

<gco:CharacterString>fair use</gco:CharacterString>

</gmd:useLimitation>

</gmd:MD_Constraints>

</gmd:metadataConstraints>

<!-- Legal constraint -->

<gmd:metadataConstraints>

<gmd:MD_LegalConstraints>[smr2]

<!-- When one of the subtypes MD_LegalConstraints or MD_SecurityConstraints is used, useLimitation is optional. -->

<gmd:useLimitation>

<gco:CharacterString>one</gco:CharacterString>

</gmd:useLimitation>

<gmd:accessConstraints>

<!-- MD_RestrictionCode names: {copyright, patent, patentPending, trademark, license, intellectualPropertyRights, restricted, otherRestrictions} - NAP expands with {licenseUnrestricted, licenseEndUser, licenseDistributor, privacy, statutory, confidential, sensitivity}. -->

<gmd:MD_RestrictionCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode" codeListValue="otherRestrictions">other restrictions</gmd:MD_RestrictionCode>

</gmd:accessConstraints>

<gmd:useConstraints>

<!-- MD_RestrictionCode names: {copyright, patent, patentPending, trademark, license, intellectualPropertyRights, restricted, otherRestrictions} -->

<gmd:MD_RestrictionCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_RestrictionCode" codeListValue="otherRestrictions">other restrictions</gmd:MD_RestrictionCode>

</gmd:useConstraints>

<!-- (C-C) otherConstraints is a free text element required by NAP if accessConstraints or useConstraints is set to "otherRestrictions." -->

<gmd:otherConstraints>

<gco:CharacterString>

Data only to be used for the purposes for which they were collected.

</gco:CharacterString>

</gmd:otherConstraints>

</gmd:MD_LegalConstraints>

</gmd:metadataConstraints>

<gmd:metadataConstraints>

<!-- Security constraints; in general these will be in applicable to USGIN resources -->

<gmd:MD_SecurityConstraints>

<gmd:classification>

<!-- MD_SecurtyConstraints has various optional free text values, and a required MD_SecurityConstraints/classification from MD_ClassificationCode names: {unclassified, restricted, confidential, secret, topSecret} -->

<gmd:MD_ClassificationCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ClassificationCode" codeListValue="unclassified">unclassified</gmd:MD_ClassificationCode>

</gmd:classification>

</gmd:MD_SecurityConstraints>

</gmd:metadataConstraints>

<!-- (O-O) Metadata maintenance information - This element provides information about the maintenance schedule or history of the metadata record. -->

<gmd:metadataMaintenance>

<gmd:MD_MaintenanceInformation>

<gmd:maintenanceAndUpdateFrequency>

<!-- Only one MD_MaintenanceInformation element may be included, with a required MD_MaintenanceFrequencyCode names: {continual, daily, weekly, fortnightly, monthly, quarterly, biannually, annually, asNeeded, irregular, not-Planned, unknown} -->

<gmd:MD_MaintenanceFrequencyCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_MaintenanceFrequencyCode" codeListValue="asNeeded">as needed</gmd:MD_MaintenanceFrequencyCode>

</gmd:maintenanceAndUpdateFrequency>

<gmd:maintenanceNote>

<gco:CharacterString>This metadata record has been processed by the iso-19115-to-usgin-19115-data XSLT to ensure that all mandatory content for USGIN profile has been added.2013-04-04T12:00:00</gco:CharacterString>

</gmd:maintenanceNote>

</gmd:MD_MaintenanceInformation>

</gmd:metadataMaintenance>

</gmd:MD_Metadata>

 

 

 

 

 

 

8.3 ISO19110 Feature Catalog example

Example encoding of entity attribute information using the xml implementation of ISO 19110. Comments in green provide some explanation.

<?xml version="1.0" encoding="ISO-8859-1"?>

<gfc:FC_FeatureCatalogue xmlns="http://www.isotc211.org/2005/gfc" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gfc="http://www.isotc211.org/2005/gfc" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gmx="http://www.isotc211.org/2005/gmx" xmlns:gsr="http://www.isotc211.org/2005/gsr"
xmlns:gss="http://www.isotc211.org/2005/gss" xmlns:gts="http://www.isotc211.org/2005/gts"
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="FC001" xsi:schemaLocation="http://www.isotc211.org/2005/gfc http://www.isotc211.org/2005/gfc/gfc.xsd" uuid="99ffdfd0-775a-11e0-a1f0-0800200c9a34">

<!-- mandatory -->
<gmx:name>
<gco:CharacterString>Feature Catalogue for Provisional Processed CTD Data from the Deepwater Horizon Incident Response in the Gulf of Mexico May 08, 2010 through November 15 ,2010
</gco:CharacterString>
</gmx:name>
<!-- mandatory 1..* -->
<gmx:scope gco:nilReason="unknown"/>

<!-- mandatory -->
<gmx:versionNumber gco:nilReason="unknown"/>
<!-- mandatory -->
<gmx:versionDate gco:nilReason="unknown"/>
<gmx:language>
<gco:CharacterString>eng</gco:CharacterString>
</gmx:language>
<gmx:characterSet>
<gmd:MD_CharacterSetCode

codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_CharacterSetCode" -"utf8">UTF-8</gmd:MD_CharacterSetCode>
</gmx:characterSet>
<!-- can put subCatalog here, but its unclear what the use case is -->
<!-- mandatory -->
<gfc:producer>
<!-- could use xlink:href to resource contact -->
<gmd:CI_ResponsibleParty>
<gmd:individualName>
<gco:CharacterString>No Name Was Given</gco:CharacterString>
</gmd:individualName>
<gmd:organisationName>
<gco:CharacterString>Arizona Geological Survey</gco:CharacterString>
</gmd:organisationName>
<gmd:contactInfo>
<gmd:CI_Contact>
<gmd:phone>
<gmd:CI_Telephone>
<gmd:voice>
<gco:CharacterString>520-770-3500</gco:CharacterString>
</gmd:voice>
</gmd:CI_Telephone>
</gmd:phone>
<gmd:address>
<gmd:CI_Address>
<gmd:deliveryPoint>
<gco:CharacterString>

416 W. Congress St., Suite 100

</gco:CharacterString>
</gmd:deliveryPoint>
<gmd:city>
<gco:CharacterString>Tucson</gco:CharacterString>
</gmd:city>
<gmd:administrativeArea>
<gco:CharacterString>AZ</gco:CharacterString>
</gmd:administrativeArea>
<gmd:postalCode>
<gco:CharacterString>85701</gco:CharacterString>
</gmd:postalCode>
<gmd:electronicMailAddress>
<gco:CharacterString>metadata@azgs.az.gov</gco:CharacterString>
</gmd:electronicMailAddress>
</gmd:CI_Address>
</gmd:address>
</gmd:CI_Contact>
</gmd:contactInfo>
<gmd:role>
<gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#CI_RoleCode" codeListValue="curator">curator</gmd:CI_RoleCode>
</gmd:role>
</gmd:CI_ResponsibleParty>
</gfc:producer>
<!-- mandatory 1..* -->
<gfc:featureType>
<!-- the id attribute should be used as a fragment identifer in URLs for the feature catalog citation in ISO 19115 metadata -->
<gfc:FC_FeatureType id="fragmentIdentifer">
<!-- mandatory -->
<gfc:typeName>
<gco:LocalName>Name of the feature</gco:LocalName>
</gfc:typeName>
<gfc:definition>
<gco:CharacterString>CTD Header Information</gco:CharacterString>
</gfc:definition>
<gfc:code>
<gco:CharacterString>URI for feature type--handy if there is a registry</gco:CharacterString>
</gfc:code>
<!-- mandatory. Indicates if the feature type is abstract or not. default is FALSE-->
<gfc:isAbstract>
<gco:Boolean>false</gco:Boolean>
</gfc:isAbstract>

<!-- mandatory. pointer to containing catalog; UUID is defined in root element for this catalog-->
<gfc:featureCatalogue uuidref="87ffdfd0-775a-11e0-a1f0-0800200c9a66"/>
<gfc:carrierOfCharacteristics>
<gfc:FC_FeatureAttribute>
<!-- mandatory -->
<gfc:memberName>
<gco:LocalName>Name of attribute1</gco:LocalName>
</gfc:memberName>
<gfc:definition>
<gco:CharacterString>explanation of attribute 1</gco:CharacterString>
</gfc:definition>
<!-- mandatory -->
<gfc:cardinality>
<gco:Multiplicity>
<gco:range>
<gco:MultiplicityRange>
<gco:lower>
<gco:Integer>0</gco:Integer>
</gco:lower>
<gco:upper>
<!-- I guess this is how one would say as many as you want... -->
<gco:UnlimitedInteger isInfinite="true">

5</gco:UnlimitedInteger>
</gco:upper>
</gco:MultiplicityRange>
</gco:range>
</gco:Multiplicity>
</gfc:cardinality>
<!-- optional -->
<gfc:definitionReference>
<gfc:FC_DefinitionReference>
<gfc:definitionSource>
<gfc:FC_DefinitionSource>
<!-- most likely this will be the same as the citation for the catalog producer -->
<gfc:source
xlink:href="#UUID of citation for containing catalog"/>
</gfc:FC_DefinitionSource>
</gfc:definitionSource>
</gfc:FC_DefinitionReference>
</gfc:definitionReference>
<!-- optional -->
<code>
<gco:CharacterString>

URI for this attribute if it is registered somewhere

</gco:CharacterString>
</code>
</gfc:valueMeasurementUnit>
<!-- optional -->
<valueType>
<gco:TypeName>
<!-- its unclear how this scheme is supposed to be used for complex datatypes -->
<gco:Name>
<gco:CharacterString>

datatype name for quantifying this attribute suggest using xs:types if applicable, but might be URI for a complex element

</gco:CharacterString>
</gco:Name>
</gco:TypeName>
</valueType>
<!-- if valueType is an enumeration, there may be collection of FC_listedValues documenting the choices -->
</gfc:FC_FeatureAttribute>
</gfc:carrierOfCharacteristics>
<carrierOfCharacteristics>
<FC_FeatureAttribute>
<memberName>

<gco:LocalName codeSpace="http://stategeothermaldata.org/uri-gin/aasg/xmlschema/activefault/1.2">FeatureURI</gco:LocalName>

</memberName>
<definition>

<gco:CharacterString>

unique identifier for this feature. Best practice is to define an http URI that will dereference to a normative description of the feature

</gco:CharacterString>

</definition>
<cardinality>
<gco:Multiplicity>
<gco:range>
<gco:MultiplicityRange>
<gco:lower>
<gco:Integer>1</gco:Integer>
</gco:lower>
<gco:upper>
<gco:UnlimitedInteger>1</gco:UnlimitedInteger>
</gco:upper>
</gco:MultiplicityRange>
</gco:range>
</gco:Multiplicity>
</cardinality>
<valueType>
<gco:TypeName>
<gco:Name>

<gco:CharacterString>xs:string</gco:CharacterString>

</gco:Name>
</gco:TypeName>
</valueType>
</FC_FeatureAttribute>
</carrierOfCharacteristics>
<!-- other attributes -->
</gfc:FC_FeatureType>
</gfc:featureType>
<!-- the catalog may document many feature types -->
</gfc:FC_FeatureCatalogue>