Document Actions
Z39.50 Application Profile for Geospatial Metadata or "GEO"
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
Contents
- Introduction
- Background
- Scope
- Field of Application
- References
- Definitions
- Z39.50 Specifications for GEO
Annexes
1. Introduction
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].
2. Background
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.
3. Scope
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.
4. Field of Application
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).
5. References
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.
6. Definitions
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.
7. Z39.50 Specifications for GEO
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.
7.1. Version
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.
7.2. GEO Objects
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}
7.3. Communication Services
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.
7.4. Z39.50 Services
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.
7.4.1. Search
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.
7.4.1.1. Attribute Set
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.
7.4.2. Retrieval
This section describes the components and procedures used by Z39.50 to return records in response to a query.
7.4.2.1. Schema
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.
7.4.2.2. Element Sets
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)
7.4.2.3. Record Syntaxes
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)
7.5. Preferred Display Format
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.
7.6. Diagnostic Messages
The GEO application will use the Bib-1 Diagnostic Set.
