Make a Really Basic Catalog Service for the Web (CSW)

Easy Catalogue Services for the Web

Adapted from chapter 10: HTTP protocol binding of the OpenGIS® Catalogue Services Specification version 2.0.2

Simplifications...

  • only mandatory requirements are discussed
  • only HTTP key-value-pair (KVP) requests are discussed (no XML POST or SOAP requests)

Architectural principles

The interaction between a client and a server is accomplished using a standard request-response model of the HTTP protocol. That is, a client sends a request to a server using HTTP, and expects to receive a response to the request or an exception message. Request and response messages are encoded as keyword-value pairs within a request URI or using an XML entity-body. Optionally, requests may also be embedded in a messaging framework such as SOAP.

Basic message exchange pattern

Basic CSW basic message exchange pattern

Basic CSW in a nutshell

CSW gives you overwhelming flexibility in how you return information. However, all you really MUST do is:

  1. support querying on the "core queryables", and
  2. return catalog records in a simple XML format we call csw:Record

The core queryables and csw:Record map directly to the 15 "classic" Dublin Core metadata terms, so the catalog in its basic form is pretty simple, and highly compatible with the most prevalent metadata standard in existence.

Core Queryables, and the Mapping of Dublin Core names to XML element names
OGC queryable term Dublin Core element name XML element name
Title title dc:title
  creator dc:creator
Subject subject dc:subject
Abstract description dc:description
  publisher dc:publisher
  contributor dc:contributor
Modified date dc:modified
Type type dc:type
Format format dc:format
Identifier identifier dc:identifier
Source source dc:source
  language dc:language
Association relation dc:relation
BoundingBox coverage ows:BoundingBox
  rights dc:rights

The rest of this document describes how to present this information in XML, and how to query it using CSW's primary query language. Other than that, the only thing to do is handle standard OGC service operations like GetCapabilities.

The Catalog Record

csw:Record

The heart and soul of the catalog is its representation of a catalog entry. In CSW this is called a record. The XML schema for a csw:Record is here. Notice that this schema is based on the XML schemas developed for the Dublin Core Metadata Initiative with the addition of the csw:AnyText and ows:BoundingBox elements.

csw:AnyText is a tricky element. CSW says that all elements in csw:Record MUST be available to be queried on, except csw:AnyText. This element is sort of an invisible placeholder for telling the catalog to do a full-text search of it's records. csw:AnyText SHOULD NEVER appear in a response message.

The ows:BoundingBox element, of course, is used to express the spatial extent of the record.

csw:Record contains the 10 CSW "core queryables", or which dc:identifier and dc:title are the only mandatory ones. Here is an example.

The brief view, csw:BriefRecord, consists only of dc:identifier, dc:title, dc:type, and ows:BoundingBox. Once again, only dc:identifier and dc:title are mandatory. Here is an example.

 

The csw:SummaryRecord schema

GetRecords operation (querying the catalog!)

The below example queries the catalog using a search for any occurence of the string 'pollution' in any field. The service, version, and request parameters are standard for an OGC service. The parameters that make this a catalog search are constraintlanguage, which says the query will be written in CQL, and constraint, which is the query (expressed in CQL).

example request: 
http://ex.com/csw?service=CSW&version=2.0.2&request=GetRecords&typeName=csw:Record
&constraintlanguage=CQLTEXT&constraint="csw:AnyText Like '%pollution%'"

example response:

response

Since we're using all the defaults from CSW, we know that we'll be returning csw:SummaryRecords (wrapped in a little extra CSW response XML). Therefore, we know we could have specified any of the 10 core queryables above for our search. The below example limits the query to the title and subject fields.

example request: 
http://ex.com/csw?service=CSW&version=2.0.2&request=GetRecords&typeName=csw:Record
&constraintlanguage=CQLTEXT&constraint="dc:title OR dc:subject LIKE '%pollution%'"

example response:

response

 

GetRecordById operation

This operation is a subset of the GetRecords operation, and is included as a convenient short form for retrieving and linking to records in a catalogue. The key parameter is Id, which is a comma-separated list of anyURI, allowing you to request more than one record from the catalog.

example request:

http://ex.com/csw?service=CSW&version=2.0.2&request=GetRecordById&Id=http://ex.com/2342343

example response:

response

This response will always be XML conforming to csw:SummaryRecord of MIME type application/xml.

GetCapabilities operation

The easiest way to implement the GetCapabilities operation is to create an XML file in a text editor that has all the required information. Here's an example of a basic capabilities document. The idea is to list contact information, and describe the operations the catalog supports, and what URLs to use to access those operations. You can also describe advanced query capabilities in the <ogc:Filter_Capabilities> section.

DescribeRecord operation

The mandatory DescribeRecord operation allows a client to discover elements of the information model supported by the target catalogue service. The operation allows some or all of the information model to be described. In this most basic CSW, that only supports csw:Record, the request and response to DescribeRecord are always the same:

example request:

http://ex.com/csw?service=CSW&version=2.0.2&request=DescribeRecord

example response:

response

AttachmentSize
Sample CSW Capabilities document6.38 KB

Comments

StephenRichard's picture

The getREcords request makes

The getREcords request makes POST with XML the mandatory HTTP method, so just implementing GET with KVP would appear to be technically invalid.