I · 02
The Z39.88-2004 Standard
A reference summary of the standard itself: its publisher, its dates, how the document is organised, what it normatively defines, and what it leaves to communities of implementers.
OpenURL is defined by ANSI/NISO Z39.88-2004, The OpenURL Framework for Context-Sensitive Services. It was developed by NISO Standards Committee AX (formed in 2001), approved by the American National Standards Institute on 15 April 2005, and reaffirmed on 13 May 2010. The "2004" in the designation reflects the year the committee completed the text; ANSI approval followed in 2005. The reaffirmation did not change the normative content.
Bibliographic details
- Title
- The OpenURL Framework for Context-Sensitive Services
- Designation
- ANSI/NISO Z39.88-2004 (R2010)
- Publisher
- National Information Standards Organization (NISO), Baltimore, Maryland
- Approved
- 15 April 2005 by ANSI; reaffirmed 13 May 2010
- Identifiers
- ISBN 978-1-937522-38-4; DOI
10.3789/ansi.niso.z39.88-2004R2010 - Availability
- Free PDF from NISO's website
- Maintenance and registration agency
- OCLC, designated by NISO in 2006. OCLC operated the OpenURL Registry until it was frozen in 2022; see Registry Deprecation.
What the standard defines
Z39.88-2004 defines an abstract framework rather than one fixed URL syntax. Its core components are:
- The ContextObject, a package that describes a referenced resource (the Referent) together with up to five context Entities: ReferringEntity, Requester, ServiceType, Resolver and Referrer. See The ContextObject.
- Descriptors: four ways to describe an Entity (Identifier, By-Value Metadata, By-Reference Metadata, Private Data).
- Registry-backed core components: Namespaces, Character Encodings, Serializations, Constraint Languages, ContextObject Formats, Metadata Formats, Transports and Community Profiles. Each instance is named by an
info:ofi/identifier in the OpenURL Registry. - Two ContextObject Formats: the KEV (Key/Encoded-Value) format and the XML format.
- Three OpenURL Transports, each over HTTP or HTTPS with GET or POST: Inline, By-Value and By-Reference. See Transports.
- Community Profiles, which select a coherent subset of Registry entries for one community. See Community Profiles.
How the document is organised
| Part | Content |
|---|---|
| Sections 1–4 | Purpose and scope, referenced standards, notational conventions, definitions. |
| Part 1 | ContextObjects and Transports: the abstract model, Descriptors, the Registry, Formats, Namespaces, Transports and Community Profiles. |
| Part 2 | The KEV ContextObject Format, the Z39.88-2004 Matrix constraint language, keys and URL-encoding. |
| Part 3 | The XML ContextObject Format and its XML Schema. |
| Part 4 | OpenURL Transports: By-Reference, By-Value and Inline, each over HTTP(S) GET and POST. |
| Appendix A | Responsibilities of the Maintenance Agency (informative). |
| Appendix B | Specification of the Matrix constraint language (normative). |
| Appendices C and D | The Level 1 and Level 2 San Antonio Community Profiles, SAP1 and SAP2 (informative). |
| Appendix E | Implementation guidelines for the transports: URL length, URL-encoding, query-string parsing (informative). |
Separate implementation guidelines for the KEV format, written for NISO Committee AX by Ann Apps, were published in the Registry (version 1.7, December 2004).
What the standard does not define
- Resolver behaviour. What a link resolver does with an incoming OpenURL (which knowledge base it consults, which targets it shows) is deliberately not specified. The KEV guidelines stress that the framework "is not a protocol".
- Knowledge-base data. How holdings are exchanged is covered by the separate NISO KBART recommended practice; see OpenURL & KBART.
- Metadata formats beyond the initial set. The standard registers an initial set (journal, book, dissertation, patent, the scholarly ServiceType format and others) and leaves further formats to Registry submissions.
Conformance
Conformance is claimed against a Community Profile, not against the framework as a whole. A profile lists the Registry entries (ContextObject Format, Metadata Formats, Namespaces, Transports, Character Encodings) that a conforming resolver must be able to process. Nothing in a ContextObject indicates which profile it follows; there is no certification programme.
For scholarly linking the relevant profile is the San Antonio Level 1 Profile (SAP1): KEV ContextObjects, the journal, book, dissertation, patent and scholarly-ServiceType metadata formats, and the three OpenURL transports over HTTP. In practice nearly all traffic uses the Inline transport over HTTP(S) GET, which closely resembles OpenURL 0.1.