Catalogue Services for the Web (CSW)
Overview
Catalogue Services for the Web (CSW) provide a registry service to support the ability to publish and search collections of descriptive information (metadata) for data, services, and related information objects. Metadata registered in catalogues represent resource characteristics that can be queried and presented for evaluation and further processing by both humans and software. Catalogue services are required to support the discovery and binding to registered information resources within an information community.
Figure 1 – Essential interactions in a service-oriented architecture
CSW specifies the interfaces between clients and catalogue services, through the presentation of abstract and implementation-specific models. CGDI registries are based on CSW. For most registries, CSW will require the development of specific profiles before they can be used.
Standard
OpenGIS® Catalogue Service Implementation Specification
Related Information
Notes
The OpenGIS® Catalogue Service Implementation Specification and related Profiles and Registry Services documents listed on the OGC® CSW implementation specification web page were developed by the Open Geospatial Consortium (OGC).
Users may find the following OGC® tutorial useful: CSW.
Additional Information: Catalogue Services on the Web (CSW)
CSW Metadata
Catalogue services, and particularly service registries, contain metadata that include the type of services available and how to access each particular service.
The OGC CSW Registry Service is a profile of the CSW part of the OpenGIS® Catalogue Service Implementation Specification. It applies the CSW interfaces to a registry information model, providing a general and flexible web-based registry service that enables users—human or software—to locate, access, and make use of resources in an open, distributed system; it facilitates the retrieval, storage, and management of many kinds of resource descriptions. An extension mechanism permits registry content to be tailored for more specialized application domains.
A service-oriented architecture must support some fundamental interactions: publishing resource descriptions so that they are accessible to prospective users; discovering resources of interest according to some set of search criteria; and then interacting with the resource provider to access the desired resources. Within such an architecture, a registry service plays the essential role of matchmaker by providing publication and search functionality, thereby enabling a requester to dynamically discover and communicate with a suitable resource provider without requiring the requester to have advance knowledge about the provider.
The service registry profile imposes some constraints on the use of the base specifications and introduces additional search, retrieval, and registry management capabilities. It provides facilities for advertising and discovering a wide variety of information resources. While such resources are often labelled as “metadata”, it is rarely possible to maintain an absolute distinction since what is deemed data in one context may well be treated as metadata in another.
The terms ‘catalogue’ and ‘registry’ are often used interchangeably, but the following distinction can be made: a registry is a specialized catalogue that exemplifies a formal registration process such as those described in applicable ISO standards. A registry is typically maintained by a registration authority, such as the OGC or GeoConnections, who assumes responsibility for complying with a set of policies and procedures for accessing and managing registry content.
OGC Catalogue
The OGC® has developed a catalogue profile that specifies the content of a basic extension package to be supported by all conforming services. The package includes extension elements of general utility that may be used to characterize a wide variety of geographic information resources, with a focus on service-oriented metadata management. It concentrates on the provision of service-related information in support of geospatial applications and adopts concepts from a variety of sources, including several ISO standards.
The OGC® package is formally identified by the absolute URI “urn:ogc:def:ebRIM-RegistryPackage:OGC:Basic”.
CGDI Catalogue
A CGDI-compliant Service Registry consists of one or more databases that contain information to describe services that can be found on the Internet. These databases contain information such as the name of the service, the type of service, and the location (URL) where the service can be accessed. A Service Registry contains information about the service instances that are part of the CGDI.
Service providers publish information about their services in one or more service registries. Clients search the contents of these registries to find CGDI-compliant services. Clients and service providers interact with the service registry through the use of a Service Registry Service.
The table below indicates the minimum metadata fields that are required for any CGDI-compliant Service Registry. For each CGDI-compliant service, the contents of each of these standard fields should be completed. (Note that some fields are optional. These fields do not have to be filled for every service.)
Fields Required for a CGDI-compliant Service Registry/Catalogue
| Field Name | Mandatory or Optional (M) or (O) | Description |
|---|---|---|
| About | M | The URI of the service instance being described. |
| Publisher | M | The name of the institution that owns the service. |
| Title | M | The name of the service. |
| Description | M | A brief description of the service in plain text, as much as a whole paragraph in length. |
| Service | M | The type of service, chosen from a list of well-known types defined by a CGDI Service Type Service. For a non-standard service, the content should be identified as "OTHER". |
| Specification | O | The URI of the Specification (in HTML) that describes the content and behavior unique to this specific implementation of the service. This is a human-readable description. It may be the same URI as defined below in Documentation. |
| Documentation | O | The URI of the Documentation (in RDF) that describes the specific implementation of the service. |
| Capabilities | O | The URI that returns the GetCapabilities document for the service (for many services, this is similar to the “about” URI above, with “?GetCapabilities” appended). |
| WSDL | O | The URI of the WSDL description of the service. |
| Constraints | M | Access control restrictions to the service. |
| Language | M |
Language of this service description, where:
|
| Contact | M | A technical contact (which should include name, email, phone number or a link to a URI for this information). |
| Status | M | Operational status of this service in a free text format (7x24, production, testing, etc.). |
| Date | M | Publication date of this service description. |
Page details
- Date modified: