Version 2.2
Last Modified: 02 Oct 1999
Douglas D. Nebert
U.S. Federal Geographic Data Committee
590 National Center
U.S. Geological Survey
Reston, Virginia 20192
- Introduction
- Background
- Scope
- Field of
Application
- References
- Definitions
- Z39.50
Specifications for GEO
- Version
- GEO Objects
- Communication
Services
- Z39.50 Services
- Search
- Attribute Set
- Retrieval
- Schema
- Element Sets
- Record
Syntaxes
- Preferred
Display Format
- Diagnostic
Messages
Annexes
- GEO Attribute Set
- Attribute Types
- Use Attributes
- By Attribute
Value
- By Element Name
- By SGML Tag
- Relation
Attributes
- Structure
Attributes
- Truncation
Attributes
- GEO Attribute Combinations
- Attribute
Combination Guidelines
- Mandatory
Attribute Combinations
- Use and
Structure Attributes
- Structure
and Relation Attributes
- GEO Schema
- XML DTD
- SGML DTD
- Long Element Names
- Modification History
- Changes from 2.0 to
2.1
- Changes from 2.1 to
2.2
- Changes from 2.2 to
3.x
- Changes from 3.x to
4.x
This document describes an application profile for the U.S. Federal
Geographic Data Committee's Content Standard for Digital Geospatial
Metadata [1] issued in June 1994. This
Geospatial Metadata Profile (GEO) is based on ANSI/NISO Z39.50-1995
Information Retrieval(Z39.50): Application Service Definition and
Protocol Specification [2]. The GEO
Profile includes not only the specifications for Z39.50 in the
application but also other aspects of a GEO-conformant server that are
outside the scope of Z39.50. This Profile was written based on the
specific examples and wording provided by the Application Profile for
the Government Information Locator Service [3].
The Content Standard for Digital Geospatial Metadata was developed
by the Federal Geographic Data Committee (FGDC) and the ASTM Section
D18.01.05 on Mapping and GIS to provide a standard set of data element
references for digital, geo-referenced spatial (or "geospatial")
information. Metadata is data about the content, quality, condition,
and other characteristics of data. These standard tags for information
elements are intended to bridge implementation-specific labels used in
existing geoprocessing software and to facilitate discovery, query,
retrieval, and presentation of geospatial metadata -- and the spatial
data they reference.
ASTM Section D18.01.05 started development of a standard for spatial
metadata in August 1990 with input from participants at a workshop of
the Urban and Regional Information Systems Association in San
Francisco, California. The Federal Geographic Data Committee initiated
work on the standard in June, 1992, through a forum on geospatial
metadata. At the forum, the participants agreed on the need for a
standard on the information content of metadata about geospatial data.
The committee accepted the offer of ASTM Section D18.01.05 to develop a
draft information content standard. This draft was slightly revised,
and offered for public review from October 1992 to April 1993.
Extensive comments were received from the public. The FGDC's Standards
Working Group revised the draft. The revised draft was provided for
further review and testing in July 1993. Refined drafts were offered
for review and testing in January and March 1994. The draft standard
was approved by the Federal Geographic Data Committee on June 8, 1994,
and was referenced by Executive Order 12906, "Coordinating Geographic
Data Acquisition and Access: The National Spatial Data Infrastructure,"
signed on April 11, 1994, by President William Clinton. Section 3,
Development of a National Geospatial Data Clearinghouse, paragraph (b)
states:
"Standardized Documentation of Data. Beginning 9 months from the
date of this order, each agency shall document all new geospatial data
it collects or produces, either directly or indirectly, using the
standard under development by the FGDC, and make that standardized
documentation electronically accessible to the Clearinghouse network.
Within 1 year of the date of this order, agencies shall adopt a
schedule, developed in consultation with the FGDC, for documenting, to
the extent practicable, geospatial data previously collected or
produced, either directly or indirectly, and making that data
documentation electronically accessible to the Clearinghouse
network."
This standard is the data documentation standard referenced in the
executive order. The ASTM version of this standard incorporates
specific tag references for "short names" and numeric tags for each
data element or data element grouping [4].
The short names are to be used as a guide to software implementors for
internal tags for tables, columns, or objects, and are suggested for
use as tags in extensions to the Standard Graphics Markup Language
(SGML) and HyperText Markup Language (HTML) to aid in retrieval and
presentation.
The GEO Profile fully specifies the use of ANSI/NISO Z39.50. In
addition, the GEO Profile provides the specifications for the overall
GEO application relating to the FGDC Content Standard for Digital
Geospatial Metadata including other aspects of GEO-conformant servers
that are outside the scope of Z39.50.
The GEO Profile focuses on requirements for a GEO server operating
in the Internet environment. GEO clients will be able to interconnect
with any GEO server, and these clients will behave in a manner which
allows interoperability with the GEO server. Clients that support
Z39.50 but do not implement the GEO Profile will be able to access FGDC
records with less than full GEO functionality.
The GEO Profile addresses intersystem interactions and information
interchange but does not specify user interface requirements.
The GEO Profile supports search and retrieval of geospatial metadata
entries and related geospatial data sets accessible to GEO-compliant
servers in the Internet environment. This includes local applications
of isolated TCP/IP networks, local area networks based on Ethernet
protocol, and wide-area networks using a consistent host addressing
scheme. The GEO Profile will be used by implementations of GEO server
processes as one method of providing standardized access to geospatial
metadata and as a reference to access the data they reference. It will
also be used by client developers to understand expected behaviors of
GEO servers. A GEO server accessed using Z39.50 in the Internet
environment acts primarily as a direct access point to information
stores it controls. These information stores can be accessed through an
API, such as is provided with the ZDIST software from the Clearinghouse
for Networked Information Discovery and Retrieval [5]. The target information may be managed by
operating system commands against text files, by RDBMS or OODBMS
against indexed data structures, or by geoprocessing software systems
which control spatial data and attribute information.
Data elements are also classified as Mandatory or Optional, although
optionality is dependent in several cases on the type of geospatial
data being described. For example, the number of rows and columns in a
raster data set is not an applicable property for a vector data set.
Rows and columns would be mandatory for a raster data set and not
applicable (suppressed) for vector data set descriptions.
Some of the information resources pointed to by GEO Entries may be
available electronically through other communications protocols
including the common Internet protocols that facilitate electronic
information transfer such as remote login (Telnet), File Transfer
Protocol (FTP), and electronic mail (SMTP/MIME). The use of these
protocols or other communications paths is outside the scope of the GEO
Profile.
Once connected to a GEO server, users supported by appropriate
clients that understand the GEO Profile may navigate through single or
multiple servers. GEO servers will support searching (i.e., accept a
search query and return a result set or diagnostic messages) and
support browsing (i.e., accept a well-known search query and return a
list of Entries in brief display format). Although the GEO Profile
addresses GEO servers only, it is understood that clients have roles in
the execution of these activities (e.g., browsing is also a client
function in the sense of how it interprets and presents GEO data).
The following list contains documents referenced by this Profile
that contain provisions which, through reference in this text,
constitute provisions of the GEO Profile. At the time of this
publication, the editions indicated were valid. All documents are
subject to revision.
[1] ANSI/NISO Z3950-1995. Information
Retrieval (Z39.50): Application Service Definition and Protocol
Specification. National Information Standards Organization. (1995).
Bethesda, MD: NISO Press. Electronic version of Z39.50 available at the
Z39.50 Maintenance Agency. http://lcweb.loc.gov/z3950/agency.
[2] Content Standards for Digital
Geospatial Metadata. U. S. Federal Geographic Data Committee
(1994). Reston, Virginia. FGDC Secretariat. ftp://fgdc.er.usgs.gov/pub/metadata/meta6894.ps,
http://geochange.er.usgs.gov/pub/tools/metadata/standard/940608.txt,
http://geochange.er.usgs.gov/pub/tools/metadata/standard/metadata.html.
[3] FIPS PUB 192-1, Application
Profile for the Government Information Locator Service (GILS) Version
2. U.S. Department of Commerce, Technology Administration,
National Institute of Standards and Technology (1997). http://www.usgs.gov/gils/prof_v2.html.
[4] Standard Specification for
Content of Digital Geospatial Metadata, D5714-95. American Society
for Testing and Materials (1995). West Conshohocken, PA.
[5] Clearinghouse for Networked
Information Discovery and Retrieval (1994). ZDIST Version 1.0 Server
software. Research Triangle Park, NC:CNIDR.
[6] USMARC Format for Bibliographic
Data. Washington, DC: Library of Congress, Cataloging Distribution
Service. See also http://lcweb.loc.gov/marc/.
[7] RFC 1729, Using the Z39.50
Information Retrieval Protocol in the Internet Environment.
Clifford Lynch (1994). ftp://ds.internic.net/rfc/rfc1729.txt.
[8] World Wide Web Consortium, http://www.w3.org/.
[9] Crosswalk: FGDC Content Standards
for Digital Geospatial Metadata to USMARC. Geography and Map
Division, Library of Congress (1997).
http://alexandria.sdc.ucsb.edu/public-documents/metadata/fgdc2marc.html.
For purposes of this Profile, the following definitions apply.
Client: An initiating application. This
application includes the Z39.50 origin.
Electronic Information Resource:
Information resources that are maintained in electronic, digital format
and may be accessed, searched, or retrieved via electronic networks or
other electronic data processing technologies (e.g., CD-ROM).
Extent: A
derived GEO Profile element whose value is the number of square degrees
of coverage for a given data set. It is calculated as (North Bounding
Coordinate - South Bounding Coordinate) * (East Bounding Coordinate -
West Bounding Coordinate). Extent provides the ability to locate data
sets of small, regional, continental, and global extent.
(GEO) Entry: A collection of related
metadata elements associated with a single geospatial data object or
product. Conceptually, this may equate to a thematic data layer or map
product, but may represent a collection of related themes on one
extreme, or a small set or instance of a spatial data object, such as a
reservoir, on the other. An Entry may include multiple values for a
given element.
Interoperability: A condition that exists
when the distinctions between information systems are not a barrier to
accomplishing a task that spans multiple systems.
Mandatory: An element in a GEO Entry that
must have a value provided by the record source. The GEO Profile
specifies which elements must be present from the perspective of GEO
servers.
Origin: The part of a client application
that initiates a Z39.50 association and is the source of requests
during the association.
Profile: The statement of a function(s)
and the environment within which it is used, in terms of a set of one
or more standards, and where applicable, identification of chosen
classes, subsets, options, and parameters of those standards. A set of
implementor agreements providing guidance in applying a standard
interoperably in a specific limited context.
Registered Object: An object that is
identified by a name-to-thing relationship in which the name is
recorded by a registration authority to ensure that the names can be
used unambiguously.
Server: An application that responds to an
initiating application (i.e., a client). The application that includes
the Z39.50 target.
Target: The part of an server application
that accepts a Z39.50 association.
Uniform Resource Identifier (URI): A set
of related standards for encoding resource location and identification
information for electronic and other objects. Examples include Uniform
Resource Locators (URLs) and Uniform Resource Names (URNs).
USMARC: An implementation of ANSI/NISO
Z39.2, the American National Standard for Bibliographic Information
Interchange [6]. The USMARC format
documents contain the definitions and content designators for the
fields that are to be carried in records structured according to
Z39.2.
This section details the required services available from Z39.50. It
also describes an Attribute Set for searching and Element Set Names for
server presentation of results, and prescribes the formal Record
Syntaxes to be supported by GEO servers for the transfer of
Entries.
At a minimum, GEO clients and servers must support Z39.50 Version 2
as specified in Z39.50-1995. GEO requires support for the objects
listed in section 7.2, some of which are not defined in Z39.50-1995. No
Version 3 services are required for implementation of the GEO
Profile.
The following object identifier (OID) is assigned to the Z39.50
standard:
{iso (1) member-body (2) US (840) ANSI-standard-Z39.50 (10003)}
This OID is abbreviated as: ANSI-standard-Z39.50.
Several object classes are assigned at the level immediately
subordinate to ANSI-standard-Z39.50, including:
- 3 = attribute set definitions
- 4 = diagnostic definitions
- 5 = record syntax definitions
- 13 = database schema definitions.
GEO requires support of the following objects:
- Bib-1 Diagnostic Set {ANSI-standard-Z39.50 4 1}
- Bib-1 Attribute Set {ANSI-standard-Z39.50 3 1}
- GILS Attribute Set {ANSI-standard-Z39.50 3 5}
- GEO Attribute Set {ANSI-standard-Z39.50 3 9}
- GEO Schema {ANSI-standard-Z39.50 13 4}
- HTML Record Syntax {ANSI-standard-Z39.50 5 109 3}
- SUTRS Record Syntax {ANSI-standard-Z39.50 5 101}
and optional support of the following objects:
- SGML Record Syntax {ANSI-standard-Z39.50 5 109 9}
- GRS-1 Record Syntax {ANSI-standard-Z39.50 5 105}
- USMARC Record Syntax {ANSI-standard-Z39.50 5 10}
When Transmission Control Protocol (TCP) is used as the transport
service, the specification for use of TCP is found in [7]. The use of other communication services
is not yet defined.
There are three Z39.50 (Version 2) services that are required for
conformance: Init, Search, and Present. No additional services are
required for conformance to the GEO Profile. Other Z39.50 services,
however, may be provided optionally by servers and used by clients.
Standard Z39.50 Init Service negotiation procedures control the use
of all services. In addition, GEO-conformant clients and servers must
specify the implementation id, name, and version within the Z39.50 Init
Service.
GEO clients and servers are required to support the Z39.50 Type-1
query. Support for the Boolean operators AND, OR, and AND-NOT is also
required. GEO servers should expect to process queries consisting of
Boolean combinations of textual, temporal, and spatial search
terms.
The GEO Profile requires clients and servers to support the GEO
Attribute Set. The GEO Attribute Set is a registered object.with an
Attribute Set OID of {ANSI-standard-Z39.50 3 9}. GEO servers must also
support the Bib-1 and GILS Attribute Sets to a limited extent. That is,
GEO servers must recognize the Bib-1 and GILS Attribute Sets to the
extent that a Bib-1 or GILS client may pass the Attribute Set OID in a
query and a GEO server may receive and process a query with the
OID.
The GEO Attribute Set imports the Use, Structure, Relation, and
Truncation Attribute Types from the Bib-1 Attribute Set. In addition,
the GEO Attribute Set imports selected Attributes from the Bib-1 and
GILS Attribute Sets, where the semantic meaning is equivalent. Thus,
search of GEO servers on common Bib-1 Attributes by clients familiar
with Bib-1 should be successful.
The GEO Profile defines additional Use, Structure, and Relation
Attributes to facilitate the searching of geographic and spatial
information. Each Use Attribute defined in the GEO Attribute Set
corresponds in name and semantics to a record element of the GEO
Schema. See Annex A for definitions of all
GEO Attributes, and Annex C for the
definition of the GEO Schema.
GEO servers are required to support a mandatory set of attribute
combinations from the GEO Attribute Set as specified in Annex B. GEO servers are required to recognize
the attribute combination, and a search must always result in a valid
result set (which could contain zero records). GEO servers should never
return any of following Bib-1 diagnostics when a query includes the
mandatory attribute combinations:
- Unsupported Attribute Type (113)
- Unsupported Use Attribute (114)
- Unsupported Relation Attribute (117)
- Unsupported Structure Attribute (118)
- Unsupported Attribute Combination (123)
When a GEO server receives a query term containing attribute types,
values, or combinations that are not supported by the server, the
server should fail the search (search status = failure) and return and
appropriate Bib-1 diagnostic. If other terms in the query can be
processed by the server, the server may also indicate that a subset of
search results is available (result set status = subset). A GEO server
may, if appropriate to its database, support additional attribute
types, values, and combinations from the GEO Attribute Set. See Annex A for a list of the valid attribute types
and values, and Annex B for a list of all
valid attribute combinations.
This section describes the components and procedures used by Z39.50
to return records in response to a query.
The GEO Profile specifies a GEO Schema (see Annex C). The GEO Schema is a registered object
with an OID of {ANSI-standard-Z39.50 13 4}. A schema in Z39.50 can be
modified and may evolve over time, and it is reasonable to expect the
GEO Schema will evolve.
GEO servers are required to support three element set names: B
(Brief), S (Summary), and F (Full). GEO servers will interpret the use
of the element set names to identify the following elements from the
GEO Schema (marked with their SGML tags in parentheses):
- B: includes the
Title (title) element.
- S: includes the following elements:
Title (title),
Online Linkage (onlink),
Bounding Coordinates (bounding), Extent (extent),
Publication Date (pubdate),
Beginning Date (begtime),
Ending Date (enddate),
Browse Graphic (browse),
Entity Type Label (enttypl),
Attribute Label (attrlabl), and
Data Set G-Polygon (dsgpoly). The
Browse Graphic (browse) should appear as groups of
Browse Graphic File Name (browsen),
Browse Graphic File Description (browsed), and
Browse Graphic File Type (browset).
- F: contains all elements available in the record.
The server should include in the retrieved record all of the elements
for which there is data available in the database record and which can
be encoded in the requested record syntax (e.g., some types of
locally-defined binary data may not be encodable in a USMARC or SUTRS
record).
Optionally, servers may support additional element set names,
including:
A GEO server is required to return the following diagnostic from the
Bib-1 Diagnostic Set when it receives a request for an element set name
that is not supported by the server:
- Element Set Name Not Valid (25)
The GEO Profile requires support for the following Record
Syntaxes:
- HTML {ANSI-standard-Z39.50 5 109 3}: HTML is used to obtain a GEO
Entry that is formatted by the server for eventual display by a Web
Browser. The specification for HTML is maintained by [8].
- SUTRS {ANSI-standard-Z39.50 5 101}: SUTRS is used to display a GEO
Entry in simple text. SUTRS is defined in Z39.50-1995 [1].
- XML {ANSI-standard-Z39.50 109 10}: XML can be used to exchange GEO
Entries between servers or for loading into a metadata editor or
presentation system for further processing. The XML Document Type
Definition (DTD) is included in Annex C. The
specification for XML is maintained by [8].
For GEO Entries in HTML and SUTRS Record Syntaxes, it is recommended
that GEO servers follow the guidelines outlined for the preferred display
format. HTML is the default Record Syntax to return when the client
has not specified a preferred record syntax.
For purposes of interoperability, servers may support other record
syntaxes including:
- SGML {ANSI-standard-Z39.50 5 109 9}: SGML can be used to exchange
GEO Entries between servers or for loading into a metadata editor or
presentation system for further processing. The SGML DTD is included in
Annex C.
- GRS-1 {ANSI-standard-Z39.50 5 105}: GRS-1 can be used to
encapsulate more complex bundles of information including images,
related documents, video, or other ancillary information for further
processing by the client. GRS could also be used to encapsulate an
Entry in SGML along with the reference to -- or even inclusion of -- a
DTD. GRS-1 is defined in Z39.50-1995 [1].
- USMARC {ANSI-standard-Z39.50 5 10}: The element of a GEO Entry can
be mapped into USMARC [6] using a formal
mapping of the FGDC Content Standards for Digital Geospatial Metadata
to USMARC [9].
When a GEO-conformant server is unable to return a record in the
requested record syntax, the server should return an appropriate
diagnostic from the Bib-1 Diagnostic Set, such as:
- Record Not Available in Requested Syntax (238)
- Record Syntax Not Supported (239)
The GEO Profile recommends a preferred display format for the
mandatory record syntaxes, HTML and SUTRS. A GEO Entry should be
displayed in an indented outline form with subordinate elements
indented to the appropriate level of subordination. The default
presentation format shall use the long element names as specified in Annex D, followed by a colon and a space with
the value of the element on one or more lines. At least one character
indentation shall exist for dependent or subordinate elements.
A GEO Entry in HTML may be encapsulated between <PRE>
</PRE> tags or may include local hypertext links to aid
navigation of the metadata document.
The GEO application will use the Bib-1 Diagnostic Set.
