OpenURL + OpenSearch


OpenSearch provides a description document that specifies query parameters for a search interface, using a URL template or the Parameter extension:

<Url type="application/atom+xml" template="{searchTerms}"/>
<Url type="application/atom+xml" template="">
  <p:Parameter name="q" value="{searchTerms}"/>

The standard fields are "searchTerms" (the query terms), "count" (the number of items to return) and "startPage"or "startIndex" (the page or index to start results from).

OpenSearch also makes those description documents autodiscoverable:

<link rel="search" type="application/opensearch+xml" href="opensearch-description.xml"/>

For any class of object that can be described using a standard set of fields, OpenSearch extensions provide a way to map those fields to query parameters:

<Url xmlns:geo="" type="application/atom+xml" template="{searchTerms}&lat={geo:lat}&lon={geo:lon}

(the namespace prefix would be declared at the start of the document, but I've put it here for brevity)

OpenURL provides a way to specify a standard set of fields that describe a class of object, such as journals and journal articles. These fields are combined as key/value pairs—with a couple of boilerplate parameters to specify the version and format of OpenURL being used—into a standardised query string:


This query string can then be used to query any search interface that is OpenURL-compliant.

Dan Chudnov demonstrated using the Parameter extension to describe an OpenURL-compliant search interface using an OpenSearch description document.
It's unwieldy, though, as you have to repeat all those parameters for every output format that the search results are available in. It's also redundant, because a) it's mapping fields to query parameters with exactly the same names and b) those fields need to be standardised by being defined in an OpenSearch extension, when they're already defined in an OpenURL KEV matrix.

While talking with Tony Hammond about how to make it easier to query multiple search interfaces in search of a particular object, a solution presented itself: instead of duplicating the OpenURL KEV matrix in an OpenSearch extension for each class of object, why not have an OpenSearch extension that would allow a description document to say "this search interface supports OpenURL query parameters for these classes of objects"?

Thus an OpenSearch description document for an OpenURL-compliant search interface would look like this:

<OpenSearchDescription xmlns="" 
  <Url type="application/atom+xml" template="">
    <!-- The OpenURL version(s) that this search interface supports, "Z39.88-2004" as the default. -->
    <!-- The OpenURL Matrices that this search interface supports, i.e. classes of objects that can be queried. -->
      using the Parameter extension rather than an inline URL template for the 
      optional standard fields, as it's easier to add extra parameters this way 
    <p:Parameter name="start" value="{startIndex}" minimum="0"/>
    <p:Parameter name="count" value="{count}" minimum="0"/>

Leaving out the optional elements, the OpenSearch description document could be as simple as this:

<OpenSearchDescription xmlns="" xmlns:openurl="">
  <Url type="application/atom+xml" template="">

If the search results were also standardised to use the same field names in their output (whether XML or JSON), it would then be simple to discover, query and parse search results from all OpenURL-compliant search interfaces.


  • This could almost be accomplished using <link rel="openurl" type="application/atom+xml" href=""/>, but how to define which types of object are available? Perhaps that's not too important?
  • Standardising the response format is also important.
  • I'm trying to avoid the complexity of SRU, if possible.
  • This would be useful for Playdar, using an OpenURL KEV Matrix for Audio, particularly in combination with COinS.
  • Having something similar that says "this search interface supports SPARQL queries" (autodiscovery) would be useful, too. SPARQL service descriptions are currently accessible using DNS - the service type description for SPARQL is very similar to what would be needed for OpenURL queries.