I · 02

The Z39.88-2004 Standard

A reference summary of the standard itself — its publisher, its scope, what it normatively defines, and what it deliberately leaves to communities of implementers.

OpenURL is defined by ANSI/NISO Z39.88-2004, The OpenURL Framework for Context-Sensitive Services. It was developed under the National Information Standards Organization (NISO), approved by the American National Standards Institute (ANSI) in 2004, and reaffirmed without substantive change in 2010. The reaffirmation extended the standard's currency without modifying its normative content.

Bibliographic details

Title
The OpenURL Framework for Context-Sensitive Services
Designation
ANSI/NISO Z39.88-2004 (Reaffirmed 2010)
Publisher
NISO Press, Baltimore, Maryland
Year of approval
2004 (reaffirmed 2010)
Maintenance agency
OCLC was named the Maintenance Agency at adoption; the agency operated the OpenURL Registry at openurl.info until 2022, when the Registry was deprecated.

What the standard normatively defines

The standard defines an abstract framework rather than a single fixed protocol. Within that framework it specifies five things, each of which is treated in detail on its own page:

  • An abstract architecture: the notion of a ContextObject as the payload, plus six entities (Referent, ReferringEntity, Requester, ServiceType, Resolver, Referrer) that can populate it. See The ContextObject.
  • A Registry mechanism for naming the formats, namespaces, identifiers, and profiles used inside the framework. See The OpenURL Registry.
  • Two serialization formats — the Key/Encoded-Value format (KEV) and an XML format — for representing a ContextObject. See The KEV Format and The XML Format.
  • Three transport mechanisms for moving a ContextObject from a source to a resolver: By-Value, By-Reference, and Inline. See Transports.
  • A Community Profile mechanism that allows a community of implementers to constrain the framework to a manageable subset for their use case. See Community Profiles.

What the standard does not define

Several things are explicitly outside the scope of Z39.88-2004:

  • Resolver behaviour. What a link resolver does with an incoming OpenURL — how it consults a knowledge base, how it ranks delivery options, what it shows the user — is not specified. The standard defines only the format and transport of the request.
  • Service-type vocabularies. The ServiceType entity exists in the architecture, but the catalogue of possible service types is left to communities to define.
  • Knowledge-base formats. How resolvers represent their library's holdings is a separate matter; the KBART recommended practice (NISO RP-9) addresses this. See OpenURL & KBART.
  • HTTP semantics. The standard does not redefine HTTP; an OpenURL is an ordinary HTTP request.

Structure of the published document

The standard is published in two parts:

  • Part 1, Normative Specification, defines the framework itself — the abstract model, the Registry mechanism, the constraints on serializations and transports.
  • Part 2, Initial Registry Content, defines the formats, transports, namespaces, identifiers, and Community Profiles that were registered when the standard was first published. These include the KEV and XML serializations, the four metadata formats (journal, book, dissertation, patent), and the two San Antonio Profiles.

Implementation guidelines for the KEV format were published separately by the Apps Subcommittee as The KEV Format Implementation Guidelines.

Conformance

Conformance is assessed against a Community Profile, not against the framework as a whole. A profile names the formats, transports, and entities that an implementation must support in order to be conformant. The standard itself does not certify implementations; conformance is a self-declared property.

In practice, almost all scholarly link resolvers in production today conform to the San Antonio Profile, Level 1 (SAP1), which constrains the framework to KEV-encoded bibliographic citations carried By-Value in HTTP GET requests.

Sources