This article briefly recapitulates the OGC standard for the catalog server, OGC 12-168r6, OGC Catalogue Services 3.0 - General Model. This document can be found here: http://docs.opengeospatial.org/is/12-168r6/12-168r6.html. It presents an overview of what the Catalog Server for the Web (CSW) is capable of and what it is used for.

A catalog server publishes metadata on geographical data, formatted as records. The standard describes what a minimal record should contain, and how communication between the catalog server and catalog client should be structured.

Record

The model describes records that contain a minimum set of information that can be useful. The core CSW:Record is based on the Dublin Core standard, with a few additions such as ows:BoundingBox and csw:TemporalExtent.

Program: An example of a csw:Record
<csw:Record
  xmlns:csw="http://www.opengis.net/cat/csw/3.0"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:dct="http://purl.org/dc/terms/"
  xmlns:ows="http://www.opengis.net/ows/2.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.opengis.net/cat/csw/3.0.0
                      ../../../csw/3.0.0/record.xsd">
  <dc:creator>U.S. Geological Survey</dc:creator>
  <dc:contributor>State of Texas</dc:contributor>
  <dc:publisher>U.S. Geological Survey</dc:publisher>
  <dc:subject>Elevation, Hypsography, and Contours</dc:subject>
  <dc:subject>elevation</dc:subject>
  <dct:abstract>Elevation data collected for the National Elevation Dataset (NED) based on 30m horizontal and 15m vertical accuracy.</dct:abstract>
  <dc:identifier>ac522ef2-89a6-11db-91b1-7eea55d89593</dc:identifier>
  <dc:relation>OfferedBy</dc:relation>
  <dc:source>http://myserver.com/csw?SERVICE=CSW&REQUEST=GetRecordById&RECORD=dd1b2ce7-0722-4642-8cd4-6f885f132777</dc:source>
  <dc:rights>Copyright © 2011, State of Texas</dc:rights>
  <dc:type>Service</dc:type>
  <dc:title>Elevation Mapping Service for Texas</dc:title>
  <dct:modified>2011-03-01</dct:modified>
  <dc:language>en</dc:language>
  <ows:BoundingBox>
    <ows:LowerCorner>-108.44 28.229</ows:LowerCorner>
    <ows:UpperCorner>-96.223 34.353</ows:UpperCorner>
  </ows:BoundingBox>
  <csw:TemporalExtent>
   <csw:begin>2011</csw:begin>
   <csw:end>2012</csw:end>
  </csw:TemporalExtent>
</csw:Record>

CSW:Record is only an example of how to represent records. A CSW server can offer metadata as any metadata model. Examples of such metadata models are ISO-19115 or ATOM.

Communication model

The LuciadLightspeed implementation of the catalog server implements the HTTP protocol binding. You can make requests using HTTP Get with key value pairs (KVP), or HTTP Post with XML. Responses are returned in XML. The server takes care of the encoding and decoding of CSW requests, responses, and metadata records.

Supported requests

GetCapabilities

As the name states, a GetCapabilities request returns what the catalog server is capable of. The response contains a number of sections. They specify:

  • The service and the server identification

  • Which requests are supported

  • What parameters are accepted per request

  • How the request should be sent (GET or POST)

  • Which constraints can be applied in the chosen query language. The OGC Filter query language should be supported by default, so in practice, this amounts to a statement of the Filter capabilities.

Each of the sections can be requested separately.

DescribeRecord

This request allows a client to discover elements of the information model through the catalog service. It applies to CSW 2.0.2 only.

The response to such a request is typically a part of an XML Schema file. This information can be used to build a GUI to construct queries for the catalog server. Note that this request describes what you can query. It does not describe what the result will look like. It is possible that the result of the query is a record that contains more information than the information that could be queried.

GetRecords

A GetRecords request is the actual query on the catalog server. It can be compared to an advanced search of a search engine on the web. The fields that can be queried are determined by the response to the GetCapabilities or DescribeRecord request. The acceptable values of these fields are determined by the response to the GetDomain request.

The response to a query is either:

  • A validation of the query

  • The number of records that comply with the query

  • All records that comply with the query

  • A pre-defined subset of the records that comply with the query, comparable to a page of hits on a web search engine query.

The response may be customized in the sense that only a subset of the fields of the records that comply with the query should be presented.

The query is expressed in a query language defined in the capabilities of the server. The LuciadLightspeed catalog server implementation supports the mandatory OGC Filter query language by default, and provides support to plug in other query languages.

Program: Example GetRecord GET requests
// return all records in full CSW format
http://localhost:8081/ogc/csw/studio-catalogue?REQUEST=GetRecords&SERVICE=CSW&version=2.0.2&resultType=results&elementSetName=full&typeNames=csw:Record&namespace=xmlns(csw=http://www.opengis.net/cat/csw/2.0.2)

// return all records in ISO format, three records at a time
http://localhost:8081/ogc/csw/studio-catalogue?REQUEST=GetRecords&SERVICE=CSW&version=2.0.2&resultType=results&typeNames=gmd:MD_Metadata&namespace=xmlns(gmd=http://www.isotc211.org/2005/gmd)&outputSchema=http://www.isotc211.org/2005/gmd&startPosition=0&maxRecords=3

GetRecordById

The response to this request returns all information available on the catalog server about a record with the given unique identifier. It is assumed that a previous request has been sent to retrieve the unique identifier. The unique identifier may have been referred to in a record which was the result of a GetRecords request. You could compare this to following a link that was in a page resulting from a web search.

OpenSearch

OpenSearch is a standard for web search engine templates. CSW 3.0 supports integration with OpenSearch, and adds new functionality such as geographical and time-based queries.

An OpenSearch query is a KVP query with a pre-defined template. These templates have semantically pre-defined meanings, to allow for automated integration. Here are a few example templates for CSW:

Program: Example OpenSearch templates
<Url type="application/xml"
      template="http://cswservice.com/csw?service=CSW
&version=3.0&q={searchTerms}&maxRecords={count?}
&startPosition={startIndex?}&bbox={geo:box?}
&outputSchema=http://www.opengis.net/cat/csw/3.0
&outputFormat=application/xml"/>
<!-- Search by bbox returning ATOM -->
<Url type="application/atom+xml"
      template="http://cswservice.com/csw?service=CSW
&version=3.0&q={searchTerms}&maxRecords={count?}
&startPosition={startIndex?}&bbox={geo:box?}
&outputFormat=application/atom+xml"/>
<!-- Search by bbox returning HTML -->
<Url type="text/html"
      template="http://cswservice.com/csw?service=CSW
&version=3.0&q={searchTerms}&maxRecords={count?}
&startPosition={startIndex?}
&bbox={geo:box?},urn:ogc:def:EPSG::4326
&outputSchema=http://www.opengis.net/cat/csw/3.0
&outputFormat=application/text/html"/>
<!-- Search by bbox and time returning ATOM -->
<Url type="application/atom+xml"
      template="http://cswservice.com/csw?service=CSW
&version=3.0&q={searchTerms}
&maxRecords={count?}&startPosition={startIndex?}
&bbox={geo:box?}&time={time:start}/{time:end}
&outputFormat=application/atom+xml"/>

A template URL has a few well-known template parameters, which can easily be translated into OGC Filter queries for CSW.

Below you can find some example OpenSearch requests:

Program: Example OpenSearch requests for the templates in the previous example
//Search for records containing the word "weather", with a maximum of 10000 records
http://cswservice.com/csw?service=CSW
&version=3.0&q=weather&maxRecords=10000
&startPosition=1
&outputSchema=http://www.opengis.net/cat/csw/3.0

//Search for records containing the word "weather" from 2004 to 2010, with a maximum of 5000 records, starting from the 5000th record
http://cswservice.com/csw?service=CSW
&version=3.0&q=weather&maxRecords=5000
&startPosition=5000

//Search for records containing the word "weather" in the BBOX 10,20,30,40, with a maximum of 10000 records
http://cswservice.com/csw?service=CSW
&version=3.0&q=weather&maxRecords=10000
&startPosition=1
&bbox=10,20,30,40,urn:ogc:def:EPSG::4326

//Search for records containing the word "weather" from 2004 to 2010, with a maximum of 10000 records
http://cswservice.com/csw?service=CSW
&version=3.0&q=weather
&maxRecords=10000&startPosition=1
&time=2004/2010

Typical order of requests

The following is a typical order of requests for a catalog server:

  1. GetCapabilities returns what requests the server can handle. This includes the query language to be used and the type of records contained in the catalog server.

  2. DescribeRecord (CSW 2.0.2 only) returns the record that should be used to query the catalog server. Note that it is not necessarily the same type of record as the one in the catalog server. Nor is it necessarily the same as the type of record that is returned as a response to a query. The response to this query defines what may be queried, and can therefore be used to build a GUI for the construction of that query.

  3. GetDomain returns the acceptable values for a field in the query record.

  4. GetRecords returns the records that comply with the query stated in the request. The resulting records are metadata on geographical data, not the geographical data itself. It is up to the requestor to interpret the metadata to retrieve the geographical data.

  5. GetRecordById is an alternative to GetRecords to retrieve a record based on its ID.

Limitations

Transaction

The current implementation does not support the creation, modification or deletion of catalog records through the catalog interface. That does not imply that the set of records of the catalog server is static. They may be changed by other means.

Harvest

The current implementation does not support harvesting other services to update its records.

The catalog server contains metadata about geographic data sets and services. It can also contain information about catalog servers themselves. As such, it can pass the query on to the catalog servers about which it has metadata. This is not supported.

Asynchronous responses

The response to the GetRecords may be sent to a third party other than the requestor. This is not supported by the server.