ONIX for Books Implementation and Best Practice Guide Release 3.0.2 January 2014

Introduction

This ONIX for Books Implementation and Best Practice Guide is intended to be read in conjunction with the ONIX for Books Product Information Format Specification, and section numbering is compatible between the two documents.

This guide documents ‘best practice’, not ‘common practices’, and its aim is to improve the quality of communication using ONIX, industry-wide, by ensuring ONIX users implement the standard in a consistent and effective fashion.

‘Best practice’ is dynamic: as data providers and recipients improve their capabilities, as business models develop, and as market conditions change, the nature and extent of these best practice guidelines is liable to evolve. And the guidance in this document is not entirely limited to the data content of individual ONIX elements, but includes some comments on reasonable expectations for how that data should be treated by both data suppliers and recipients.

Within this Implementation and Best Practice Guide, the ONIX for Books message Header and each Block or Group of a Product record is considered in turn. Each of these sections begins with a boxed summary of the best practice, and is followed by one or more extended and annotated examples, and more detailed discussion of each composite or data element.

Throughout this guide, Reference names are used in text descriptions, diagrams and discussions of best practice. In all cases, equivalent Short tags are equally good practice, and examples given show both alternatives.

It is recognized that this Implementation and Best Practice Guide may be – for some ONIX users – somewhat beyond the current capabilities of their internal IT systems, and initial implementations of ONIX 3.0 may not meet all aspects of this best practice. However, implementors are encouraged to plan to comply with all aspects of best practice as a minimum, even if this plan involves a multi-phase implementation.

This guide does not set out to define a ‘minimum’ set of data elements for valid ONIX – technically, that minimum set is inherent in the ONIX schema, and is all but useless. In reality, the minimum set of elements is the set that meets your business requirements – and real business requirements will inevitably require use of a larger set of data elements than any technical minimum. These best practices go well beyond any technical minimum, and outline a set of data elements that are likely to be the most commercially relevant in a broad range of circumstances.

Omission of any data element from this Implementation and Best Practice Guide does not imply that all data providers should simply omit the data element from their ONIX messages – the uses to which ONIX data is put by data recipients vary widely, and the range of potentially useful data content that might be carried in ONIX messages should be discussed between providers and recipients. For certain types of product and particular trading arrangements, individual data elements may be of great importance, yet may not be covered in this guide. For example, it may be highly advantageous for the publisher to supply details of the product classification using the UNSPSC (UN Standard Product and Service Classification), WCO (World Customs Organization) Harmonized Commodity Coding or another commodity coding scheme to overseas distributors as an indication of the customs or tax status of the product. Equally, this best practice guide does not cover use of the <ReligiousText> composite, which of course would be critical to a publisher or reseller specializing in religious publications. However, this document provides guidance on those data elements that will be found most commonly useful to the broad range of supply chain partners – the ‘core content’ of an ONIX message.

: Although ONIX 2.1 is considered a legacy format, this Guide can provide useful help for 2.1 in areas where there are no differences, or only modest changes, between 2.1 and 3.0. An appendix lists these changes.

Introduction to Release 3.0 revision 1 (3.0.1)

This revision of the Implementation and Best Practice Guide includes a number of updates taking into account additions made in Release 3.0 revision 1 (3.0.1) of the ONIX for Books Product Information Format Specification. Many of these changes are intended primarily for use with East Asian writing systems, or with multilingual metadata, but other additions are of more general use. The earliest release of the codelists suitable for use with version 3.0.1 is Issue 16.

Introduction to Release 3.0 revision 2 (3.0.2)

This revision of the Guide includes a number of updates taking into account additions made in Release 3.0 revision 2 (3.0.2) of the ONIX for Books Product Information Format Specification. Some data elements introduced in version 3.0.2 require use of Codelists Issue 24 or later.

Document history

14 April 2011: Working draft.
30 June 2011: Initial release.
26 July 2011: Added appendix listing key changes between ONIX 2.1 and ONIX 3.0.; Added stronger recommendation to use UTF‑8 encoding, and a note on omission of BOM with UTF‑16 encodings.; Added advice against including a DOCTYPE declaration or any reference to local schema files in transmitted messages.; Added note on use of the textformat attribute, and either CDATA or escaping of < characters in HTML.; Added guidance on preferred format for <SentDateTime> and datestamp.; Added note on sequence numbering for <UnnamedPersons> element.; Minor changes for clarity and style.
22 August 2011: Added note about use cases.; Added appendix checklist for new data feeds.; Added ‘At a glance’ diagrams.; Fixed section P.19.14.; Minor changes for clarity and style.
13 Sept 2011: Added appendix on codelists and internationalization.; Added notes about delivery of collateral resources.; Correction to <Header> At a glance diagram.; Correction to <Tax> composite example.; Minor changes for clarity and style.
4 Oct 2011: Added diagram illustrating semantics of List 64.; Minor changes for clarity and style.
21 Oct 2011: Added example illustrating use of <ProductFormFeature> for describing accessibility features of an e-book.; Minor updates to take into account other additional codes in Codelists Issue 15.; Added example showing use of publisher and publishing group.; Update of XML namespace used by ONIX messages.; Added notes on governance.; Minor changes for clarity and style.
13 Dec 2011: Corrections to Collection and Sender ‘At a glance’ diagrams.; Added appendix on development and support lifecycle.; Minor changes for clarity and style.
27 Jan 2012: Revised release, to accompany Release 3.0 revision 1 of ONIX for Books.; Added notes and examples related to provision of textual metadata in multiple ‘parallel’ languages, provision of transliterated names, inclusion of glosses in Chinese and Japanese, and provision of phonetic information for sorting names and titles in non-alphabetic writing systems.; Added notes relating to the <CollectionSequence> composite, the <SequenceNumber> within the <TitleElement> composite and the <ProductContact> composite.; Modified ‘At a glance’ diagrams to include new data elements introduced in ONIX 3.0.1.; Added examples showing wholesale and temporary ‘special offer’ pricing, and provision of multiple publishing dates for an e-book.; Minor changes for clarity and style.
10 Feb 2012: Added notes to some ‘At a glance’ diagrams.; Change to appendix to reflect the ONIX International Steering Committee decision and EDItEUR’s announcement that ONIX 2.1 support will be reduced at the end of 2014.; Minor changes for clarity and style.
18 Apr 2012: Added example showing versioned e-publication file format.; Updated best practice for ISBN-A.; Minor changes for clarity and style.
25 Apr 2012: Additions in P.7 to recommend use of the newly-published ISNI.
14 Aug 2012: Added paragraphs in Section 2 on the ‘metadata supply chain’, on the use of EDItX or EDI P&A update messages, and on user interfaces.; Added typical schema references and DOCTYPE declarations for validation.; Clarifications in use of the <TitleElement> composite and <ImprintIdentifier>.; Corrected minor errors in examples showing use of <Language> and <NameIDType>.; Added notes on use of rolling and instantaneous datetimes.; Added notes on CI/RI/CX/RX combinations in <Territory>.; Added example showing multiple, qualified prices.; Updated diagrams to reflect recent tightening of schema requirements.; Other minor changes for clarity and style.
19 Oct 2012: Added further clarification on naming of imprints and publishers.; Documented subset of List 65 likely to be applicable to digital products.; Added further clarification of best practices for tax-inclusive and tax-exclusive pricing.; Strengthened advice on use of narrow audience age ranges.; Extended example showing usage constraints in P.3.; Added example of review quote in P.14.; Added Sales outlet ID to example in P.21.; Added note on 2-series GTIN-13s.; Added note on RTL scripts.; Minor updates for clarity and style, and to align with Codelists Issue 19.; Fixed SVG to work around a problem with Firefox 17 (and later).
25 Jan 2013: Added sections on <Barcode> and <ContributorPlace> for North America.; Added section on specifying rental prices using <PriceCondition>.; Added examples of <RelatedWork> for an omnibus edition, and of use of et al.; Added diagrams for common packaging.; CSS improvements for printing.; Other minor changes for clarity and style, and updates to align with Codelists Issue 20.
26 Apr 2013: Added note on overseas territories and dependencies.; Added tables showing associations between <ProductFormDetail> and <ProductFormFeature>, and <ProductForm>.; Expanded notes on best practice with hierarchical subject categorization.; Added note on sort order.; Added example differentiating perpetual licenses and rentals of e-books.; Other minor changes for clarity and style, and updates to align with Codelists Issue 21.
19 Jul 2013: Added notes on encoding of versions, version history, extended XHTML recommended subset to include <dl>.; Added note on relative URIs in <ResourceLink>.; Added note on avoiding special characters in <RecordReference>.; Other minor changes for clarity and style, and updates to align with Codelists Issue 22.; Fixed error in labelling of ‘At a glance’ diagram in P.14.
18 Oct 2013: Added example of use of track count for extent of an audiobook.; Added example of retailer exclusion.; Added section on use of <ProductClassification>.; Other minor updates to align with Codelists Issue 23.
24 Jan 2014: Revised release, to accompany Release 3.0 revision 2 of ONIX for Books.; Added further notes on message sequence numbers, added para and example on <NoProduct/> and modified ‘At a glance’ diagram.; Added section on <EpubLicense>.; Added para on <NoPrefix/>, modified ‘At a glance’ diagram and updated examples.; Added note to <ContributorPlace>, modified ‘At a glance’ diagram and updated examples.; Added para on <PrizeStatement>, modified ‘At a glance’ diagram and updated example.; Modified section on <SalesRestriction>, modified ‘At a glance’ diagram and updated examples.; Added section on <CopyrightStatement>, added ‘At a glance’ diagram and added example.; Added section on <PriceIdentifier>, modified ‘At a glance’ diagram and updated examples.; Added para and example on linked prices in <PriceCondition>.; Added note on contrast between 3.0 handling of sales rights, markets, suppliers and prices, and equivalent in 2.1.; Added appendix sections on character sets and encodings, and on XHTML tagging.; Other minor updates to align with Codelists Issue 24.
29 Mar 2014: Corrected diagrammed cardinality of <AgentRole> in P.25 (it is mandatory).; Corrected second example in P.26.; Added definition of market publication date.; Added para on gaming the keywords.; Added note on conventions for decimal places in <PriceAmount>.; Minor updates to align with Codelists Issue 25.
11 Jul 2014: Added example to illustrate US ‘Common Core’ curriculum alignment in <Subject>.; Added example to illustrate use of <SupplierOwnCoding>.; Added example illustrating rental extensions and upgrades.; Modified ‘At a glance’ diagrams to highlight deprecated elements with pink tint.; Added section on <Stock> composite.; Added examples and diagrams to illustrate use of contributor dates and professional affiliations.; Corrections to ‘At a glance’ diagram showing structure of <ProductClassification> and of Block 6.; Extended notes on whitespace normalization, CDATA and escaping HTML in <BiographicalNote>.; Extended notes on <ProductRelationCode> relationships.; Other minor changes for clarity, and updates to align with Codelists Issue 26.
17 Oct 2014: Added aside on manifestations and works.; Other minor changes and updates to align with Codelists Issue 27.
24 Jan 2015: Added ‘DOI per chapter’ example in <ContentDetail>.; Added notes on digital exclusivity.; Elaborated example showing change of publisher of a product.; Noted that there is no longer a need to remove the xmlns attribute from <ONIXMessage> prior to DTD validation.; Added references to new ONIX Acknowledgement Message.; Other minor changes and updates to align with Codelists Issue 28 and the sunset date for ONIX 2.1.
26 Mar 2015: Added example of windowing around subscription services in P.24.; Added some text on Complexity measures.; Added appendix section on integer and real number data elements.; Other minor changes and updates to align with Codelists Issue 29.
29 Jul 2015: Added example of back cover copy as separately-downloadable supporting resource.; Added example of POD information, including order time.; Added example of revenue-share market using Unpriced item type.; Other minor changes and updates to align with Codelists Issue 30.

The ONIX for Books framework

ONIX for Books provides a standardized framework for transfer of rich bibliographic and product information between computer systems within the book and e-book supply chains.

The framework consists of an XML-based message specification – the ONIX for Books Product Information Format Specification (‘the Specification’), a message acknowledgement specification (‘the Acknowledgement Specification’), and the accompanying XML schemas – plus a set of regularly-updated controlled vocabularies (the ‘Codelists’) used in conjunction with the specifications, and various guidelines for implementation and best practice including this document (‘the Guide’). In addition, some national book trade bodies provide further guidance or certification schemes to denote compliance with the framework and with the wider needs of the supply chain.

The ONIX for Books documentation and various XML software tools are downloadable from the EDItEUR website:

the Specification is available as PDF and HTML files;
XML schemas are available in DTD, XSD and RNG formats;
an ‘in-development’ Schematron for extended validation is available for testing;
codelists are available in human-readable PDF and HTML, as CSV, TXT (tab-separated) and a proprietary XML format for integration into proprietary applications, and DTD, XSD and RNG formats to work with the main ONIX schema files;
the Acknowledgement Specification is available as PDF and HTML files;
this Guide is only available as an HTML file.

All documentation and tools are available free of charge, no registration process is necessary, and there are no charges or royalties payable if you use the ONIX framework – although use is covered by EDItEUR’s permissive license.

All implementors should take care to use the latest documentation – the Specification, this Guide, and the XML schemas and Codelists available from the EDItEUR website.

Wherever possible, organizations that implement ONIX for Books should establish contact with a National Group, and are encouraged to take an active role within such groups.

Implementors should join the ONIX_implement e-mail listserver. This is a discussion forum for ONIX-related questions, and any updates to documentation, schemas and codelists are announced here. Implementors may also wish to subscribe to EDItEUR’s regular newsletter.

Ongoing development and maintenance of the ONIX framework is managed by EDItEUR, in response to business requirements identified by its stakeholders. Although EDItEUR is a membership-based organization, ‘stakeholders’ encompasses all participants in the global book and e-book supply chains.

EDItEUR has established a governance model for ONIX that ensures a balance between responsiveness to changing business requirements and stability of the standards. ONIX for Books standards are developed and maintained in consultation with a network of ONIX National Groups – essentially committees of ONIX users and other stakeholders such as trade associations – that have been set up in many countries. National Groups are each represented on the ONIX International Steering Committee (ISC), which meets twice per year at the London and Frankfurt International Book Fairs. The ISC provides overall direction for development of the framework. Terms of reference for National Groups and for the ISC can be found on the EDItEUR website.

Change requests or proposals for new developments can be submitted by any stakeholder, either via a National Group or direct to EDItEUR. Most such requests can be met through supplementing the ONIX codelists. More rarely, a change to the Specification and associated XML schemas is required. In either case, requests are reviewed by EDItEUR and the National Groups, and major developments must be approved by the ISC. After approval, major developments are carried through in line with the ONIX development and support lifecycle.

Codelists are revised and extended on a regular basis (three or four times per year), and from time to time, minor corrections and revisions are incorporated into documentation and schemas. Such updates are announced via the EDItEUR website and the ONIX_implement e-mail listserver.

ONIX is founded partly on principles developed within the <indecs> project and upon the EPICS data dictionary, but is firmly rooted in real-world use cases and the practices of book supply chains in many countries. Typical use cases for ONIX messages include:

a publisher needs to provide information about its catalog of products to a distributor, wholesaler, retailer or other supply chain partner;
- this can include both current and forthcoming products;
- it may cover basic product information and a wide range of collateral material;
- the scope extends over the full lifecycle for book, e-book and other products (ie it includes post-publication updates to price and availability);
a specialist data aggregator, distributor, wholesaler or other organization providing data services needs to receive metadata from many sources, and redistribute consolidated data about products to supply chain partners;
- this may include managing the ‘authority’ of data received from multiple data suppliers. Any data recipient might receive data about a particular product from multiple sources – recipients need to manage the data according to its source, currency and reliability;
a distributor, wholesaler, retailer or library needs to receive metadata from its suppliers to populate its internal or customer-facing product catalog, and to enable its distribution and retail business;
- again, recipients may need to manage data about a particular product from multiple suppliers.

Although all of these supply chain partners are likely to maintain databases of product information, ONIX is primarily a message format, and is not in itself a specification for a database. ONIX specifies a range of key data elements or fields that might be stored in such a database. But the data structures defined by the ONIX specification are designed for communication of data. They are not necessarily a good match for either storage or management of product data. Databases optimized for management of bibliographic data would ideally have a more normalized (relational) or hierarchical structure to reduce the duplication of data (and thus the duplication of data management effort). Nonetheless, the ONIX specification is often used to inform the design of a database schema. And while ONIX codelists are often used as controlled vocabularies or lists of options in a database-backed application, the way ONIX encodes options (usually as numbers drawn from the codelists) is not ideal for presentation.

Implicit in the design of ONIX is the idea of a ‘metadata supply chain’. Product information is created alongside the product itself (though not necessarily by the same staff) and flows to the eventual retailer, possibly via one or more intermediary organizations – much as the products themselves do. But the metadata may take a different route, and may be managed and enhanced along the chain: no one department at the publisher, and no single organization in the chain, controls all the metadata elements. For example, within a publisher, product information may be drawn from editorial, production, advertising and promotion, the contracts or rights departments, and from sales. The distributor or wholesaler may contribute further information, and the eventual distribution of the data is sometimes accomplished by a data aggregator or other intermediary. Complete, accurate and timely metadata is the result of good business process and clear ‘ownership’ of each data element, and collating the metadata efficiently from the disparate sources may depend on a high level of process and application integration within an organization.

The metadata supply chain may be complex: publishers may need to provide data direct to retailers, indirectly to retailers via intermediaries such as data aggregators, distributors and wholesalers, and to other service providers such as e-book conversion vendors and online marketing organizations.

And because ONIX is about communication – unambiguous and consistent computer-to-computer communication suitable to support automation of business processes – precise semantics are important. Each party in the metadata supply chain must understand the meaning of the data supplied. A price is not simply ‘the price’: buyers and sellers must know whether that price includes or excludes relevant taxes, whether it is a fixed price or may be reduced by the retailer, and whether it applies to all classes of customer or is a special price for one specific class (such as for schools). This semantic precision should allow a single ONIX data feed to meet the needs of multiple recipients – if one party wants the extent of a book expressed as ‘the number of physical pages including unnumbered pages and blanks’ and another demands the extent as ‘the highest page number’, then both can be included in the ONIX message. And of course, to maintain this semantic precision, senders should never put data into a field simply because they want it displayed in a particular way by a specific recipient (for example putting a publisher name into a series or collection title field so that the recipient displays it more prominently).

A word on terminology. As noted above, ONIX draws upon the <indecs> framework. ONIX Product records describe <indecs> manifestations – these are ‘products’. A hardback, a large-format paperback, mass-market paperback, PDF e-book, EPUB e-book are all distinct manifestations, and in ONIX, each of these must have a separate Product record and a separate identity. There may of course be thousands of identical copies or instances of any one of these products or manifestations, but as far as the supply chain is concerned, these instances of each are identical and interchangeable. ISBNs identify manifestations.

Products are the manifestations of works – abstract entities comprising the intellectual property embodied in a manifestation. Each product manifests a work, and a work may be made manifest in several products. Works are also related to other works: a new work can be derived from an existing work by translation, revision, abridgement, compilation and so on. A third edition is a new work, derived (by revision) from the preceding second edition work, and a translated novel in English is a new work that is derived (by translation) from the original work in another language. ISTCs identify works.

Each manifestation is a set of essentially identical instances (or copies), and each work is a cluster of ‘identical’ manifestations (identical at least in terms of their content). Works themselves also gather in groups or chains, related by their derivation from earlier works.

Note that in library contexts derived from FRBR, the term expression is sometimes used to denote what ONIX and <indecs> define as a work, and a FRBR work is a broader and yet more abstract entity from which related expressions (ie the original, translated and abridged works above) are derived. Within the <indecs> model, while such a broad entity might plausibly be defined, it carries no relevant metadata.

In principle, a single ONIX message that meets the best practices described here should be suitable for any recipient able to accept ONIX 3.0. In practice, of course, business sensitivities may mean that one recipient should not receive details of a particular product that is exclusive to a competitor, or e-book retailers may wish not to receive details of physical products they cannot retail – which means that the content of messages can become recipient- or channel-specific. However, this specificity is limited to the selection of Product records included in the message, and the exact content of each Product record should not need to be varied.

Every ONIX recipient should be able to receive and process any correctly-constructed ONIX message, irrespective of whether they use every particular data element. For data senders, there should be no need to omit or include elements or whole composites on a recipient-by-recipient basis. As a simple example, if a particular retailer requires the book’s subject expressed using a code from a particular subject classification scheme, it should not reject messages that also contain codes from other schemes. At the very least, a recipient should be able to ignore elements and composites it does not wish to process. In a more complex case, there are some elements of ONIX data that may apparently be communicated in two different ways, but with the ‘correct’ option depending on the exact circumstances: for example, a collection title might be included in Group P.5 or in Group P.6. Suppliers and recipients should ensure they enable both options, rather than supporting only one and thus forcing business partners to use an incorrect option.

High-level message structure and conformance

ONIX for Books is an XML-based standard, and it is obviously an overriding requirement that ONIX messages are well-formed according to the XML syntax rules and valid according to the ONIX schema, and that they conform to the ONIX for Books Message Format Specification (including conforming to any ‘business rules’ described in the specification but not expressed in the DTD, XSD or RNG schemas – some of these rules may be enforced by future versions of the schemas). However, within that, there is huge scope for variation in what is considered valid ONIX for Books data. This document is intended to guide implementors, with the intention of narrowing the range of variation between implementations (particularly between different countries) and making it simpler for data senders and recipients to exchange ONIX data – adherence to agreed guidelines and best practice means less need for testing when establishing new data relationships, less tailoring of messages for individual recipients, and fewer ‘special cases’ built into recipient’s systems – all of which lower costs.

Consistent use of the ONIX data elements – putting the right data in the right boxes – is clearly paramount. And consistent use of codes drawn from the ONIX codelists is vital in this regard.

All ONIX for Books release 3.0 messages must begin with a standard XML declaration and message start tag. The <ONIXMessage> start tag must of course be balanced by an </ONIXMessage> tag at the end of the message. Between the two, there must be a <Header> and either one or more <Product> records or a single <NoProduct/> tag. The message header contains information about the message itself – which organization sent it, when and to whom – and each ‘Product record’ contains information describing a single product.

This diagram shows the highest-level composites and data elements within an ONIX message – other similar diagrams show lower-level composites and elements within specific parts of the message. Composites have a darker blue background, individual data elements have a pale blue background, and most are clickable – they link either to a diagram showing the internal structure of the composite, or to detailed notes about the composite or data element. Elements or composites that are not included in EDItEUR’s ‘best practice’ guidelines (though they may still be needed to meet specific business requirements – for example the need to send supplier-specific codes using <SupplierOwnCode> or ‘empty update’ delta messages using the <NoProduct/> element), are grey rather than blue. The small number of deprecated elements such as <DateFormat> are tinted pink.

The arrows indicate the required sequence of data elements and composites within the message, and whether a particular element is optional (the arrow bypasses the element) or repeatable (the arrow loops back). Note that the diagram shows more information than the simple cardinality statement in the Specification – the cardinality of <Product> is nominally 0…n, but the diagram clearly indicates that if <Product> is omitted then <NoProduct/> must be included, and that they may not both occur in the same message.

message start, including optional (but recommended) encoding and namespace declarations
using Reference names
`<?xml version="1.0" encoding="UTF-8"?>`
`<ONIXMessage release="3.0" xmlns="http://ns.editeur.org/onix/3.0/reference">`	upper case M

using Short tags
`<?xml version="1.0" encoding="UTF-8"?>`
`<ONIXmessage release="3.0" xmlns="http://ns.editeur.org/onix/3.0/short">`	lower case m

The choice between <ONIXMessage> (upper case M) and <ONIXmessage> (lower case m) in the message start dictates the use of either Reference names or Short tags throughout the remainder of the message.

message end
using Reference names
`</ONIXMessage>`

using Short tags
`</ONIXmessage>`

The encoding declaration is technically optional, but is effectively mandatory if your message does not use UTF‑8 or -16, and it is best practice to include it even if it does. UTF‑8 is the recommended encoding for ONIX data, although recipients should also accept other encodings in common use in particular markets, for example ISO 8859‑15 (ISO Latin‑9) or Windows‑1252 (Windows codepage 1252). If a message uses UTF‑16, the encoding should be declared explicitly as UTF‑16BE or UTF‑16LE, and a byte order mark should not be included at the beginning of the data file.

The XML namespace declaration is also optional, but may be included as an xmlns attribute of the <ONIXMessage> element. The namespace declaration is usually required for validation of the ONIX message using the XSD or RNG schemas. It is not required for validation using the DTD, but if present it may remain in place. (Versions of the DTD dated before 2015-01-24 required any xmlns attribute be removed, but this is no longer necessary.)

ONIX 3.0 messages as transmitted may include the namespace declaration (the xmlns attribute), but should not include any reference to a schema file location (the xsi:schemaLocation attribute), since these are likely to be inaccessible to the recipient of the ONIX data. In particular – and unlike earlier versions of ONIX – transmitted messages should not include a DOCTYPE declaration. Of course such references may need to be added when files are validated and processed internally. (For validation with the DTD, any xmlns namespace declaration would need to be removed and a DOCTYPE declaration may need to be added. For validation with an XSD schema, the xmlns attribute must be present, and for some validation tools, the xmlns:xsi and xsi:schemaLocation attributes also need to be added to the <ONIXMessage> element, giving the local network location of the schema file.)

message start with namespace declaration and reference to location of the XSD schema file, for validation purposes only
using Reference names
`<?xml version="1.0" encoding="UTF-8"?>`
`<ONIXMessage release="3.0" xmlns="http://ns.editeur.org/onix/3.0/reference" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/onix/3.0/reference http://intranet/onix/ONIX_BookProduct_3.0_reference.xsd">`

using Short tags
`<?xml version="1.0" encoding="UTF-8"?>`
`<ONIXmessage release="3.0" xmlns="http://ns.editeur.org/onix/3.0/short" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ns.editeur.org/onix/3.0/short http://intranet/onix/ONIX_BookProduct_3.0_short.xsd">`

The actual location of the XSD schema file, which is the second part of the value of the xsi:schemaLocation attribute – a location on the local intranet in the example – needs to be adjusted depending on local circumstance. The reference style required for the RNG schema is different. The xmlns:xsi and xsi:schemaLocation attributes should be removed before transmission of the message, since the location of the schema file will be different for any recipient.

message start with DOCTYPE reference and location of the DTD file, for validation purposes only
using Reference names
`<?xml version="1.0" encoding="UTF-8"?>`
`<!DOCTYPE ONIXMessage SYSTEM "http://intranet/onix/ONIX_BookProduct_3.0_reference.dtd">`
`<ONIXMessage release="3.0">`

using Short tags
`<?xml version="1.0" encoding="UTF-8"?>`
`<!DOCTYPE ONIXmessage SYSTEM "http://intranet/onix/ONIX_BookProduct_3.0_short.dtd">`
`<ONIXmessage release="3.0">`

The actual location of the DTD file – on the local intranet in the example – needs to be adjusted depending on local circumstances. The entire DOCTYPE line should be removed before transmission.

For more on validating XML – the technical process of checking ONIX messages meet the syntactic requirements of the standard – see DIY Schema Validation for Workmanlike ONIX, a comprehensive set of instructions for validation beginners by Tom Richardson of BookNet Canada. While it’s focused on ONIX 2.1, the same principles apply to ONIX 3.0.

21 ONIX XML hints and tips

ONIX messages should use the UTF‑8 character encoding for messages intended to be exchanged with a global range of recipients, and should include an explicit encoding declaration. UTF‑8 allows (effectively) any character, in any language or script to be included within the ONIX data, without having to use numeric character references (and note also that named character entities like ‘é’ cannot be used in ONIX 3.0);
but for practical purposes, data senders should still maintain some control over the range or repertoire of characters used in their data – the Windows‑1252 or ISO 8859‑15 character sets would be good choices in North America and Western Europe, for example. A Russian, Japanese or Arabic ONIX user would choose a different set of characters, but still encode them for transmission in UTF‑8;
all ONIX markup – the various tags used in an ONIX message and all attribute names – and all code values in the ONIX codelists must use only ASCII characters (Unicode characters 32 to 126). Numeric dates and integer or real number data elements must also be limited to a subset of ASCII characters (the digits 0–9, plus the period character ‘.’ as the decimal separator for real numbers, and ‘+’, ‘-’, ‘T’ and ‘Z’ in certain date or datetime elements);
ONIX implementors must pay attention to case, in both markup and data. XML is case sensitive: <Contributor> is different from <contributor>. But case sensitivity extends to codelist values – it’s BC, not bc or Bc in <ProductForm> – and to codes derived from external lists such as the ISO Country, Currency, Language and Script codes – it’s FR (country), EUR (currency), fre (language) and Latn (script);
the order of the XML data elements in the message is critical. In any Product Record, elements must occur in the correct order, as defined in the ONIX schemas and DTD. For example, all elements from Group P.12 must occur before any elements from Group P.13, and within an <Audience> composite in P.13, <AudienceCodeType> must come before <AudienceCodeValue>. Out-of-order elements will make a message unusable;
in contrast, the order of particular repeats of repeatable data elements or composites is not meaningful – which is why <Contributor> composites contain sequence numbers to make the ordering or priority of multiple contributors explicit. So <EditionType> LTE (large type) followed by <EditionType> ABR (abridged) means the same as it would if the order of the two elements were reversed. However, it’s good practice to assume that recipients may inadvertently use the order of repeatable data elements such as <Subject> to indicate relative importance in their internal systems, so put the ‘most important’ first;
senders should ensure that their ONIX messages are structured correctly by validating them using the XSD or RNG schemas. However, ONIX is not defined by the schema files alone, and implementors should also ensure messages meet the other requirements of the Specification too;
ONIX messages should make use of attributes – language, textformat, textcase, dateformat and so on – to provide ‘data about metadata’;
senders should avoid the continued long-term use of deprecated data elements or deprecated codes from codelists (even though they remain valid);
both senders and recipients should keep reasonably up-to-date with new issues of the ONIX codelists (these are typically released quarterly), and with minor revisions of ONIX 3.0 itself (3.0.1, 3.0.2… etc);
many textual data elements have recommended maximum character lengths that should not be exceeded;
messages must never include any empty XML elements in the message, except those few specifically defined to be empty such as <NoEdition/> or <MainSubject/>. If there’s no data available, you should leave the entire data element out. Of course that means that if there is no data available for a mandatory element, you may need to omit a whole composite. There are a very few data elements without which a sensible Product record cannot be constructed, but one such is <ProductForm>: if you don’t know what form the product is intended to take, you cannot send an initial ONIX message to ‘announce’ it. To avoid any doubt, an empty element can be expressed as either <NoEdition/> or as <NoEdition /> – the extra space is optional in XML syntax, but the version without a space is more common in ONIX (one exception to this is the <br /> tag in any embedded XHTML, where an extra space is strongly recommended for compatibility reasons). But while <NoEdition></NoEdition> is syntactically identical, it should not be used in ONIX;
ONIX senders should avoid extraneous white space characters (spaces, tabs, carriage returns, new lines) between data elements: while examples in this document are indented for readability and to emphasize structure, don’t indent real messages with tabs or extra spaces. (Note that even new lines between data elements are unnecessary, but can be useful if ONIX messages ever need to be read ‘by eye’ in a text editor.) Additional white space characters can increase the amount of memory and time the recipient requires to parse the XML, and in some circumstances can even count against the suggested length limits on text fields;
for similar reasons, senders should not include any leading or trailing white space within data elements – avoid ‘<b012> BC </b012>’ and use ‘<b012>BC</b012>’ instead (in fact, leading or trailing white space in data elements using a codelist will not validate);
and because white space characters such as tabs or new lines within a data element will not be treated consistently by all recipients, don’t rely on multiple spaces, new lines, carriage returns or tab characters to align text or create multiple paragraphs within a text data element such as <Text> – you should avoid tabs, returns and multiple consecutive spaces, and use simple XHTML markup instead;
you should not use <![CDATA[ … ]]>, unless there is a specific need to embed HTML or XML markup within the ONIX message. If you are surrounding ordinary data (plain text, codes from codelists, numbers or dates) or XHTML-tagged text with <![CDATA[ … ]]> tags, it is entirely unnecessary, and can lead to the possibility of inserting bad data into your trading partners’ systems – your unnecessary CDATA tag may circumvent their data validation process. And if you’re using <![CDATA[ … ]]> with HTML tagging, consider whether you could use XHTML (without <![CDATA[ … ]]>) instead;
you should limit XHTML markup elements to a simple subset of possible tags – to be cautious, use only <p>, <br />, <em>, <strong>, <i>, <b>, <ul>, <ol>, <li>, plus possibly <dl>, <dt> and <dd>, <sub> and <sup>, and <ruby>, <rb>, <rp> and <rt> in specialized circumstances;
aside from the initial <?xml … ?>, you should not include XML processing instructions (anything surrounded by <? … ?>) in the ONIX message;
don’t include more than a small number of XML comments () in a production file. Liberal comments can be useful in initial phases of testing ONIX output, where the file may need to be checked ‘by eye’, but these should be removed before the output is put into production use;
data recipients should ignore valid ONIX data elements that they choose not to use, and should not ask for them to be removed from the data feed. Recipients should also avoid imposing non-standard requirements or limitations on data element content, and must not require non-standard data elements be inserted into ONIX messages. ONIX messages should be broadly interoperable;
all implementors should note the license agreement that governs the use of ONIX.

Organization of data delivery

ONIX data files are sent from a ‘sender’ to a ‘recipient’ – for example from a publisher to a retailer. One data file, or ‘message’, may contain information about many products, and may form part of a sequence or feed of ONIX messages.

There is a separate – and entirely optional – Acknowledgement message which may be returned from recipient to sender, to confirm receipt and processing of the data. Use of the Acknowledgement message should be agreed between parties involved in a message exchange.

A single ONIX data file or ‘message’ includes a snapshot of the sender’s data about a range of products at the moment the message was created – and that snapshot can be transferred into the recipient’s system. But within the sender’s in-house systems, that data is subject to change. For example, as a forthcoming product approaches publication, more comprehensive bibliographic data becomes available, and previously collected data is corrected or refined. Thus exchanges of ONIX data are better thought of as ‘data feeds’ consisting of an ongoing sequence of messages – either a series of complete snapshots of the entire set of data, or (more likely) a series of changes between one snapshot and the next.

For a published product, aside from fixing any genuine errors, some elements of an ONIX Product record are effectively ‘frozen’ – the title or author cannot really change post-publication. However, other parts of the record – particularly collateral, price and availability elements that are mostly in Block 2 and Block 6 – remain subject to change throughout the life of the product. A subsequent message would include any new or updated data.

It is best practice to begin to deliver data about a planned product to supply chain partners several months in advance of actual availability. However, an initial Product record, produced eight or six months prior to publication, is not expected to be complete or final in all respects: at that point in the product’s lifecycle, many parts of the Product record would be subject to change – or missing altogether. Data suppliers should continue to update the Product record as information is confirmed or becomes available, and it is best practice for senders to ensure that all key information is available to recipients at least four months prior to publication. ONIX National Groups may operate compliance or certification schemes that specify more detailed (and perhaps earlier) targets for the delivery of comprehensive metadata prior to publication.

Certain information may only become available or be confirmed after manufacture of a physical product – an exact weight, for example. Data senders should continue to send updates and incorporate the latest available data in their data feed. And of course, although much of the bibliographic data in a Product record is in effect ‘frozen’ as the product is published, price and availability, collateral material such as reviews, relations to other works and products and other data elements should continue to be updated post-publication and throughout the product lifecycle.

Any exchange of ONIX data must be based (at least implicitly) on an agreed set of criteria for selecting a range of Product records from the data supplier’s in-house system – an agreed ‘catalog’ of products. These criteria may vary – how far in advance of publication should products be included, and should out of print products be included? Should the catalog include all markets and all types of product, or be tailored to include only those markets and products suitable for a specific class of recipient (or even a single recipient)? Each distinct set of selection criteria and catalog creates a distinct ‘data feed’, a sequence of messages, and in some circumstances, a particular set of selection criteria may be unique to a single ONIX data recipient.

Data senders should be particularly careful about products that initially fall within the selection criteria, where a subsequent change such as postponement of publication date means they fall outside the critera – such products should continue to be included in the feed. It is a common error to omit them from the subsequent feed, thus leaving the old (and incorrect) data relict in the recipient’s system.

ONIX for Books envisions three different ‘modes’ for a data feed:

Full update – supply of the complete set of Product records that fall within the feed’s selection criteria;
- any ongoing exchange of ONIX data would at least have to begin with a full data feed;
- each Product record carries all available information about that product, even if the entire Product record is unchanged from a previous message;
- implementing a data feed which is simply a series of full updates is simple as there is no need to track when updates are made in the sender’s system, and no need for the recipient to ensure that all messages are received and processed in order. Missed messages, and messages processed out of order are ‘self-correcting’ when the next message is dealt with;
- recipients should first match each received record with existing records on the basis of the <RecordReference>, then replace any and all existing data previously associated with each product with the new data in the latest message (this means that any data previously held for a matched product, but not included in the new full update, should be deleted);
- full update files can be large, and the repeated supply of unchanged Product records places an unnecessary processing burden on recipients;
Delta update – supply of the set of Product records that fall within the feed’s selection criteria and where there has been a change to some data element within the record since a previous full feed or delta update. The message itself has the same structure as a full feed, and the method of processing is identical to a full feed;
- each Product record carries all available information about that product;
- but the message size is significantly reduced because unchanged Product records are omitted entirely, which greatly decreases the processing burden for recipients;
- the sender must maintain a modification date or a full journal of changes for each Product record so unchanged records can be suppressed from each message, and must also manage a <MessageNumber> for each distinct data feed;
- recipients should first match each received record with existing records on the basis of the <RecordReference>. The data in matched records should be replaced with the new data in the delta update message. Unmatched records are new and should be added. Existing records that are not matched should be left unchanged;
- each recipient must ensure every message is parsed and processed in the order they were sent;
- omission of a previously-supplied record from a delta update carries the implication that the previously-supplied data is still correct, and so any datestamps attached to the old records in the recipient’s system should be updated;
Block-level update – a refined type of delta update, new in ONIX 3.0. The body of an Product record consists of six more or less independent groups of data elements, or ‘blocks’. There are blocks dedicated to describing the nature of product itself, to marketing collateral, to publishing details and territorial rights, etc. These Blocks 1–6 are preceded by data elements in Groups P.1 and P.2 containing information about the record itself and the identifiers (often ISBNs) for the product it describes. This preamble is sometimes informally termed ‘block zero’. A Block-level update message contains only those Product records where data has changed, and for those records, includes only Groups P.1 and P.2 (‘block zero’) plus whichever of Blocks 1–6 contain data that has changed:
- this minimizes the message size because unchanged Blocks are omitted;
- but note that updates cannot be more granular than ‘whole block’ – you cannot send an update that consists of just the data element that has changed;
- block-level updates are more complex to implement for both sender and recipient – for example, journalling of changes must be more granular than for ordinary delta updates;
- many recipients forget that a block update of one or more blocks also signifies no change in all other blocks, which means that the <SentDateTime> of the block update in fact applies to the modified record as a whole. Omission of a block carries the implication that previously-supplied data is still correct, and so any datestamps attached to the old blocks in the recipient’s system should be updated;
- note that block-level updates and ‘full record’ updates can be freely mixed within the same delta update message, as they are differentiated at record level (see <NotificationType> within Group P.1);
- it is likely that some initial ONIX 3.0 implementations will not support block-level updates, so senders and recipients should discuss their capabilities prior to using block-level updates, to ensure that the integrity of the data can be maintained;
- previous versions of ONIX for Books specified a compact Supply Update message format, which was intended to make delivery of price and availability updates more efficient. For ONIX 3.0, a simple price and availability update is not a distinct message type, but a normal block-level update message consisting of Groups P.1 and P.2, plus Block 6.

An important caveat: where recipients are receiving ONIX data (about the same products) from more than one source, then ‘replacement’ of old data with new should be conditional on both the message source and the relative age of the data, as indicated by the sourcetype, sourcename and datestamp attributes (where they are supplied), or by both the <Sender> identity and <SentDateTime>, as it is not always the case that the most reliable data is the latest to arrive. Recipients should generally maintain a ‘hierarchy of trust’ that guides whether data from a particular source should overwrite earlier data from a different and possibly more trusted source – and this hierarchy may differ from data element to element.

And special requirements may apply to Block 6: a recipient may receive price and availability information from multiple sources in separate ONIX feeds, and may wish to maintain them in parallel. For example a retailer may wish to track stock availability from multiple wholesalers.

When dealing with large numbers of products, full update ONIX files can be large. The comprehensive sample message included in the ONIX Specification is a little over 16 kilobytes for a single Product record: comprehensive Product records in languages other than English and non-Latin based scripts may be larger. And ONIX messages containing tens of thousands of Product records are not unknown. However, use of delta updates greatly diminishes the typical size and complexity of files: most products are simply omitted from most messages, because they have not been updated (the frequency of updates to a single product is much less than the frequency of update messages). Block-level updates reduce the amount of data per record and per message even more. ‘Size’ here is a rough proxy for ‘effort required to parse and ingest the data into the recipient’s database’, or the number of insert and update operations that need to be performed on the recipient’s database.

If the concern is filesize itself (rather than the burden of parsing and ingestion), then using Short tags also helps a little – it usually reduces the message size by around a third – but zipping files before transfer to the recipient is more effective. Zipping can reduce the size by a further factor of three or more. A zipped version of the sample message with short tags is only a little over 4 kilobytes. Ratios are a little different in languages other than English and non-Latin based scripts, and of course neither short tags nor zipping significantly affect the difficulty of the parsing and ingestion process.

: Reference names are more commonly used that Short tags, but both are fully supported in ONIX 3.0.; There is a Tagname Converter available, a short XSLT script to translate an ONIX message between Reference names and Short tags (or vice versa). Many XML software tools are available to process the XSLT. The Converter is available from www.editeur.org/93/Release-3.0-Downloads/#Tools.

ONIX messages are normally exchanged via FTP, with the data sender depositing files on a server maintained by the recipient (‘push’), or by the sender maintaining a file on a server that one or multiple recipients download. The latter ‘pull’ approach is considerably more difficult to combine with delta and block-level updates, as the sender has no control over the frequency that fresh data is downloaded by the recipient – though it might be possible by providing a full file at the beginning of each month, then retaining that file plus all subsequent delta or block-level updates on the server until the end of the month, and only deleting all the updates and adding a replacement full update file at the beginning of the next month.

As an alternative to FTP, transferring messages as e-mail attachments may be suitable for messages with small numbers of Product records (fewer than about 100 records).

: The mime type for such e-mail attachments should typically be ‘application/xml’, or ‘application/xml+zip’ if the file is zipped before sending.

The naming of ONIX files transferred from sender to recipient is not defined by the standard. Clearly, naming schemes have to be agreed between sender and recipient up front, but a practical naming scheme would probably combine a name for the sender (since the recipient may be receiving files from many senders), plus an element that indicates the order in which multiple files must be parsed, such as:

a year and ordinal day number (a number from 1 to 365 or 366). This cannot be used if intra-day updates might be required;
the Message sequence and Repeat numbers (the <MessageNumber> and <MessageRepeat> data elements included in the message header);
the Message creation date and time (the <SentDateTime> data element from the message header).

ONIX file names commonly include the ‘.xml’, ‘.onix’ or ‘.onx’ suffix (the first two are preferred).

RHGUK2010345.xml (a file sent by Random House UK, on 11th Dec [day 345] of 2010)

Templar_286_2.onix (second repeat of file number 286 from Templar Publishing)

LBBG20101211.xml (file from Little Brown Book Group sent on 11th December 2010)

In addition to transferring the ONIX message data from sender and recipient, supply chain partners need to exchange supporting resources such as cover images (see Group P.16). The ideal method here is the ‘pull’ model, in which the recipient downloads the collateral resource from a URL provided within the ONIX Product record (and the download would be triggered based on the ‘last updated’ date attached to the resource metadata in the ONIX). In practice, it is more common for recipients to push collateral resources to an FTP server maintained by the recipient – in effect a separate feed, perhaps with the filename provided in the ONIX metadata.

Sender and recipient may also need to agree a method for exchange of post-publication price and availability information. While this can be carried very effectively within a continuing series of ONIX messages – and clearly ONIX implementors are encouraged to use this mechanism – it is also common for post-publication price and availability updates to use other message standards. EDItEUR maintains a family of XML-based message formats under the EDItX banner, and a family of older EDIFACT EDI formats. Other EDI formats such as ANSI X.12 or Tradacoms might also be used. Great care is needed to ensure that if EDItX or an EDI method is used for price and availability updates, there is no conflict with information in a post-publication ONIX message sent to update information other than price or availability – in many cases, because the risk of conflict cannot be eliminated, when EDItX or EDI is in use for post-publication price and availability, Block 6 should not be sent in ONIX records sent post-publication.

Implied license to use ONIX data

Certain data included within, cited by or linked from an ONIX message – for example, excerpts from the product, tables of contents, cover or contributor images and other resources – is likely to be subject to copyright. The data in an ONIX message may also be the subject of other property rights, for example a sui generis database right.

ONIX data sent to a recipient is sometimes accompanied by an explicit and formal license covering use of that data. However – even in the absence of an explicit license – when a data supplier provides an ONIX message to a data recipient, there is a clear invitation extended to the recipient with an ‘implied license’ to use the product data supplied for the purposes of cataloging, trading in, merchandising, promoting and selling the products described, both internally within the recipient organization and in customer-facing applications. ONIX data recipients should treat the implied license as non-transferable, non-sub-licensable, and should not redistribute or provide access to the data to third parties either commercially or non-commercially without express permission. ONIX recipients should also treat compliance with Embargo, Valid From/Until and Announcement dates, Audience limitations, display of required credits and the like as a duty of the implied license, and should ensure reasonable efforts are made to process data updates from the supplier in a timely way (including requests to remove the data from public view in the case of legal or other issues). A typical retailer might not require anything beyond this implied license.

For the avoidance of doubt, it is strongly recommended that recipients wishing to make modifications to any data (as opposed to using the data as supplied) and/or intending to redistribute the data to a third party in any manner should secure an explicit license from the data supplier rather than relying solely on the implied license.

Formal agreements such as would be required for commercial or non-commercial redistribution of data supplied in an ONIX message (eg by a data aggregator) or for provision of third-party access to the data (eg via an API) should be concluded separately between data supplier and recipient. These agreements might cover both permitted use of the supplied data and the duties and service level expectations placed upon data supplier and recipient.

Checking your messages meet best practice

If you are an experienced XML developer, then you will have a range of software tools to validate the structure of any ONIX file against one or other of the ONIX schemas (these are available in XSD, RNG and DTD format, though the XSD and RNG are strongly recommended in preference to the DTD). EDItEUR uses the oXygen XML editor but other, similar software tools are equally suitable. Validation is an essential discipline.

But even XSD and RNG schemas check only the structure of the ONIX file and the content of those data elements which use controlled vocabularies from the codelists – they do not validate the content of free text data elements or the check digits of identifiers, nor can such schemas check for potential internal inconsistencies in the Product record. Validation with a schema is not – in itself – enough.

: EDItEUR is developing an extended schema (using Schematron) that does check identifier check digits, internal inconsistencies (‘co-occurence constraints’), and provides warnings based on some of the best practice outlined in this Guide.

If you are not experienced with XML, then it can be difficult to judge whether your ONIX data is structured correctly and contains data in line with these best practices. However, XML is only a text file: in principle, it can be read and edited by plain text editors such as Notepad++ (on Windows), or TextWrangler (on Mac OS), and it can be viewed (but not edited) in a web browser. Even the simple built-in Notepad (Windows) or TextExit (Mac OS) applications can be used – but do not be tempted to use a word processor. If you do aim to check your ONIX data this way, it is best to stick to a very small ONIX file – no more than than a couple of dozen Product records.

Opening a small ONIX file in a modern web browser (Firefox 4+, Chrome 9+, Safari 5.1+, IE9+) or text editor (Notepad++, TextWrangler) produces a display like this:

▼ <Product>
       <RecordReference>com.globalbookinfo.onix.01734529</RecordReference>
       <NotificationType>03</NotificationType>
       <RecordSourceType>04</RecordSourceType>
    ▼ <RecordSourceIdentifier>
           <RecordSourceIDType>06</RecordSourceIDType>
           <IDValue>0614141800001</IDValue>
       </RecordSourceIdentifier>
       <RecordSourceName>Global Bookinfo</RecordSourceName>
    ▼ <ProductIdentifier>
           <ProductIDType>03</ProductIDType>
           <IDValue>9780007232833</IDValue>
       </ProductIdentifier>
    ▼ <ProductIdentifier>
           <ProductIDType>15</ProductIDType>
           <IDValue>9780007232833</IDValue>
       </ProductIdentifier>
    ▼ <DescriptiveDetail>
           <ProductComposition>00</ProductComposition>
           <ProductForm>BC</ProductForm>
           <ProductFormDetail>B105</ProductFormDetail>
        ► <Measure> … </Measure>
        ▼ <Measure>
               <MeasureType>02</MeasureType>
               <Measurement>130</Measurement>
               <MeasureUnitCode>mm</MeasureUnitCode>
           </Measure>

This highlights the markup (colored), the data (black) and the nesting structure (via indenting). Clicking on the triangles (▼ or ►) hides or reveals the contents of the composite elements – the first of the two <Measure> composites has been collapsed in the example above.

Web browsers add the indentation automatically, and often appear to show extra new lines within data elements containing text with XHTML markup:
  ▼ <BiographicalNote textformat="05">
      ▼ <p>
            <strong>Maj Sjöwall</strong>
            was born in Stockholm…
These extra new lines are not present in the ONIX data, and are only added for display purposes. The original data most likely reads:
    <BiographicalNote textformat="05"><p><strong>Maj Sjöwall</strong> was born in Stockholm…

Text editors like Notepad++ and TextWrangler do similar syntax coloring and collapsing of composites (sometimes called ‘code folding’), and they also helpfully number each line of the XML. They do not (usually) add automatic indentation to highlight the XML structure or add misleading line breaks within text elements using XHTML. The basic built-in Notepad and TextEdit applications do not do coloring, folding, line numbering or automatic indentation.

This very basic technique makes it straightforward – though laborious – to check your ONIX file against the examples given in this guide, or to discover how data elements in a publisher’s internal application are expressed in the ONIX messages that the application sends.

It’s often simple to associate database fields in an internal application with XML data elements in an ONIX message. If the application’s user interface for a contributor contains several data fields like those shown below, the mapping from user interface field to ONIX data element is quite clear: Title goes into <TitlesBeforeName>, Given name goes into <NamesBeforeKey>, Family name is used to populate <KeyNames> and the Role field is used to work out the code carried in the ONIX <ContributorRole>. The application might also calculate the <PersonName> and <PersonNameInverted> data elements by combining the parts of the name in the correct order.

This application could generate the following ONIX XML:

`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A01</ContributorRole>`
`<PersonName>Prof. Steve Jones</PersonName>`
`<PersonNameInverted>Jones, Prof. Steve</PersonNameInverted>`
`<TitlesBeforeNames>Prof.</TitlesBeforeNames>`
`<NamesBeforeKey>Steve</NamesBeforeKey>`
`<KeyNames>Jones</KeyNames>`
`</Contributor>`

However this simple user interface also suggests that the application might not properly support Hungarian or east Asian names, since there is no apparent way to populate the relevant <NamesAfterKey> ONIX data element. The application may not be able to differentiate corporate from personal names. And the application may impose a limitation of one role per contributor that prevents the ONIX from complying with best practice when, for example, a single contributor is both author and illustrator.

What can complicate such seemingly-straightforward mappings between parts of an application’s interface and the ONIX messages that the application might send or receive is that many applications use a relational or hierarchical structure to make managing metadata more efficient. Changing a single data field in the user interface (say the Family name) may affect many ONIX Product records, not just a single record. And since ONIX messages may contain data owned or managed by several different departments within a sender organization, the ONIX may be assembled from data taken from several different applications.

Mapping between data elements in an ONIX Product record and database columns in an internal application applies to ONIX recipients too: each distributor, data aggregator or retailer has to parse the ONIX data it receives, and insert the data from its suppliers into the internal database (product catalog). The structure of a retailer’s internal product catalog is likely to be very different from the structure of the database the publisher used to create the ONIX data: since there is usually much less need to manage the data actively, a retailer is less likely to use a highly normalized database structure and may opt for judicious denormalization to gain some performance improvements.

It’s important to understand that creating usable ONIX for Books data is not simply a matter of creating a file that conforms to the structural requirements of ONIX. Ensuring the right data is embedded in each data element, ensuring the data is accurate and that there are no internal inconsistencies, and ensuring that each Product record contains all the data that ONIX recipients require – and that it’s delivered in a timely fashion — are all vital. The business process and workflow challenge inherent in introducing ONIX to an organization is usually much greater than the technical challenge.

ONIX for Books Message header

Header composite

Every ONIX for Books message must contain message header information in the <Header> composite. The header:

must specify the sender of the message in a <Sender> composite;
- <Sender> should contain an organization name, plus any applicable organization identifiers;
- details for a technical contact able to deal with queries about the message should be included;
should specify the recipient(s) of the message in an <Addressee> composite when the ONIX message is tailored for a specific addressee, for example through a specific selection of products that would not be suitable for other recipients;
should specify message sequence number when the ONIX message is a ‘delta file’;
must specify the date the message was sent, and should specify the time in UTC;
should not include various defaults that control how certain elements in the remainder of the message are interpreted: equivalent information should be included within each Product record instead.

sending a <Header>
using Reference names
`<Header>`
`<Sender>`
`<SenderIdentifier>`
`<SenderIDType>06</SenderIDType>`	GLN
`<IDValue>5030670137992</IDValue>`
`</SenderIdentifier>`
`<SenderIdentifier>`
`<SenderIDType>07</SenderIDType>`	SAN
`<IDValue>0137995</IDValue>`
`</SenderIdentifier>`
`<SenderName>HarperCollins UK</SenderName>`
`<ContactName>Jane King</ContactName>`
`<EmailAddress>jbk@hcp.co.uk</EmailAddress>`
`</Sender>`
`<Addressee>`
`<AddresseeIdentifier>`
`<AddresseeIDType>06</AddresseeIDType>`	GLN
`<IDValue>5030670090754</IDValue>`
`</AddresseeIdentifier>`
`<AddresseeIdentifier>`
`<SAddresseeIDType>07</AddresseeIDType>`	SAN
`<IDValue>0090751</IDValue>`
`</AddresseeIdentifier>`
`<AddresseeName>Gardners Books</AddresseeName>`
`</Addressee>`
`<MessageNumber>262</MessageNumber>`
`<SentDateTime>20100510</SentDateTime>`
`</Header>`

using Short tags
`<header>`
`<sender>`
`<senderidentifier>`
`<m379>06</m379>`
`<b244>5030670137992</b244>`
`</senderidentifier>`
`<senderidentifier>`
`<m379>07</m379>`
`<b244>0137995</b244>`
`</senderidentifier>`
`<x298>HarperCollins UK</x298>`
`<x299>Jane King</x299>`
`<j272>jbk@hcp.co.uk</j272>`
`</sender>`
`<addressee>`
`<addresseeidentifier>`
`<m380>06</m380>`
`<b244>5030670090754</b244>`
`</addresseeidentifier>`
`<addresseeidentifier>`
`<m380>07</m380>`
`<b244>0090751</b244>`
`</addresseeidentifier>`
`<x300>Gardners Books</x300>`
`</addressee>`
`<m180>262</m180>`
`<x307>20100510</x307>`
`</header>`

Sender composite

The <Sender> composite is mandatory, and identifies the sender of the ONIX message file.

It is best practice to include:

any applicable identifiers for the sender organization in one or more repeats of the <SenderIdentifier> composite;
the business name of the sender organization in the <SenderName> element;
- in many cases, the same identifier and name are repeated in <RecordSourceIdentifier> and <RecordSourceName>, where the message as a whole is created by the organization that is also responsible for the data within each Product record;
the name and e-mail address of a contact person who is responsible for the technical and operational aspects of the ONIX message, in the <ContactName> and <EmailAddress> elements.

The preferred identifier for international use is the GLN (Global Location Number), although in many countries, there are also local and industry-specific identifiers that are widely used, and these should also be supplied – for example, in many Anglophone countries, the SAN (Standard Address Number) is well established and in other countries, company or tax registration numbers are commonly used. The GLN is a global, cross-industry scheme administered by GS1 for identifying physical addresses. The SAN is an earlier, publishing-specific identifier for physical addresses maintained by Bowker, and is likely to be superseded by the GLN over the next few years. However, SANs are built into many widely-used electronic trading systems, and it is best practice to provide both wherever possible. Note with both SAN and GLN, the referent is an address rather than an organization. The organization is identified only by implication or proxy, as operating at that address. A single organization may have several address identifiers, each identifying a different physical location (for example the publishing office and a distribution warehouse), and care should be taken to ensure the correct identifiers are used.

: SANs and GLNs are – to some degree – interoperable. Some SANs may be prefixed with a six-digit magic number, then the check digit recalculated to create a valid GLN. If you have a SAN but no GLN, contact your SAN Agency to discuss conversion.

The business name of the sender organization should not include suffixes such as ‘Inc’, ‘SA’ or ‘Ltd’, unless they are required to distinguish similarly-named organizations. However, where a single organization has several business units that send ONIX messages independently, a suffix should be added to indicate which business unit is responsible for the message.

Providing a contact name and e-mail address is important as this may be used for automated notification of receipt of the message, or when a recipient has a query about the content of the message.

Addressee composite

The <Addressee> composite is optional. However, it is best practice to include it when ONIX messages are prepared for specific recipients – for example where the message contains details of retailer-specific products – and it can be repeated if the message is intended for a specific set of recipients (eg for several bibliographic data aggregators, or for multiple wholesalers). The composite should be omitted if a single message file is made generally available, for example if it is placed on an FTP site for downloading by any supply chain partner.

If one or more <Addressee> composites are included, then each should include:

any applicable identifiers for the recipient organization in one or more repeats of the <AddresseeIdentifier> composite;
the business name of the recipient organization in the <AddresseeName> element.

These data elements mirror those in the <Sender> composite, and similar recommendations apply.

H.13 Message sequence number

A message sequence number is optional. However, for practical purposes, it must be included in any data exchange where delta files are used – that is, where ONIX messages contain only those Product records where some change has occurred since the previous message – and its inclusion is strongly encouraged even when full (not delta) data files are used. It is vital that the recipient processes received messages in the correct order, and is able to identify whenever a message has been missed.

The message sequence number is a simple integer that increments by 1 for each new message in a particular data feed. Note that where an organization is generating multiple messages tailored for specific recipients or sets of recipients, the message sequence number for each recipient or set of recipients must be managed independently, and the <Addressee> composite used consistently to identify individual data feeds. Thus a publisher may send out a sequence of ‘generic’ messages without any <Addressee> composites, plus a sequence of tailored messages with an <Addressee> composite identifying retailer X, using the following message sequence numbers:

message 123 sent to all recipients
message 261 sent to X
message 124 to all
message 125 to all
message 262 to X
message 126 to all
message 263 to X

In this way, any recipient can identify whenever a message is missing or duplicated. While this is complex, using a simpler scheme based on, say, the day number lacks clarity when events like public holidays intervene – was there meant to be a message on day 125 (Cinco de Mayo)? – or when messages are sent irregularly. A sequence number makes it clear that if message 126 arrives while the recipient is expecting 125, then a message has been missed. And if 125 arrives when 126 is expected, it’s a duplicate message. Similarly, if updates are sent to a regular schedule but the sender deliberately skips a message (perhaps because no records need updating), upon receipt of the ‘next’ regular update, the sequence numbers make it clear that the recipient did not miss a message.

If there is any reason to ensure a regular schedule of messages is maintained, even when no Product records require updating, it is possible to send an ‘empty update’ – a delta file containing no Product records. In addition to the normal <Header> elements, this uses the <NoProduct/> element to provide a positive indication that the message is solely intended as a placeholder. The message sequence number should be incremented as normal, and the only net effects of the empty update upon the recipient system should be to confirm that all previously-received data remains correct, and to increment the expected value of the next message number in the sequence of messages.

Senders sometimes maintain a data feed consisting of a sequence of delta files interspersed with occasional full feed files, perhaps daily deltas and a full file once per four weeks. This ensures that if anything goes amiss with the processing of the deltas, it is automatically corrected at the next full feed. In this case, the sequence numbers of the delta files should increment as normal. If the full feed at the end of the month takes the place of one of the deltas (ie there are 27 deltas and one full feed in a 28 day period, and the full feed must be processed because it may contain updates that are not included in any delta) then it should be given the next sequential number. If the full feed serves only to confirm (ie there are 28 daily deltas plus one full feed in a 28 day period, and the full feed does not contain any updates that are not included in the deltas), the full feed should be given the same sequence number as the last delta. This emphasizes that the end result should be the same whether the recipient processes the full file, or processes all deltas including the last.

H.15 Message creation date/time

The <SentDateTime> element is mandatory.

Where a sender sends out no more than one message per day (in any particular data feed), and the recipient receives data exclusively from the sender, then the format YYYYMMDD is usually adequate. Where a sender may send multiple messages per day, or the recipient needs to aggregate data from multiple sources, then a more precise time should be included. Either of the formats:

YYYYMMDDThhmmZ (exact time expressed as UTC)
YYYYMMDDThhmm±hhmm (exact time, with a timezone offset)

are recommended. Similar formats with second precision (YYYYMMDDThhmmss±hhmm or YYYYMMDDThhmmssZ) are available, but times to the nearest second are unlikely to be needed. Formats including a time but without timezone information (such as YYYYMMDDThhmm) can be ambiguous and are not recommended. These considerations also apply to the datestamp attribute that acts as a datestamp on individual data elements (a datestamp should be included when the ‘age and reliability’ of a particular data element is significantly different from that of the overall message, such as when data from disparate sources is compiled into an aggregated data feed).

sent on 14th August at 3:10pm in a time zone four hours behind UTC, for example Toronto on Eastern Daylight Time (Eastern Standard Time, with Daylight Saving in operation)
using Reference names
`<SentDateTime>20120814T1510-0400</SentDateTime>`

using Short tags
`<x307>20120814T1910Z</x307>`

The two times here are the same – 3:10pm EDT is 19:10 UTC. Use of UTC times is preferred.

No dateformat attribute is required or allowed with the <SentDateTime> element or with a datestamp attribute, and the possible date and time formats are a small subset of those that may be used in other parts of an ONIX message (see List 55). Dates within <SentDateTime> and datestamp (ie the YYYYMMDD part) must always use the Gregorian calendar, even if other dates within the message use other calendars. Times within <SentDateTime> and datestamp (ie the hhmm or hhmmss part) can be specified in any timezone (the ±hhmm part), but using UTC is strongly preferred (the time is suffixed with Z).

Note that in the absence of datestamp information attached to individual data elements or composites, the <SentDateTime> element may be used to indicate when the data in the message was correct (according to the sender), and it is assumed there is no significant delay between generation of the message and its availability to the recipient. In general, in any data feed, the order of messages indicated by <SentDateTime> will be the same as the order indicated by <MessageNumber>. However, in a scenario where delta files are used, <SentDateTime> cannot be used by a recipient to identify when a message has been missed, so <MessageNumber> should be used for ensuring messages are processed in the correct sequence.

H.17 to H.19 Message defaults

It is best practice to omit any <DefaultLanguageOfText>, <DefaultPriceType> and <DefaultCurrencyCode> elements from the header, and to ensure the equivalent information is included within each Product record instead.

ONIX for Books Product record

Product composite

Every ONIX for Books message must contain at least one repeat of the <Product> composite. Each <Product> composite – a ‘Product record’ – contains a mandatory preamble comprising data element Groups P.1 and P.2 that together identify the record itself and the product to which it refers (the preamble is sometimes informally called ‘block zero’). This is followed by some or all of Blocks 1–5 (each Block is optional), plus an optional and repeatable Block 6.

There are two typical types of Product record, distinguished by their <NotificationType> element. The first and (currently) most common type, contains all applicable information for the product: thus it contains Groups P.1 and P.2 plus most or all of the Blocks 1–6. This type of Product record may be supplied in the context of a ‘full’ data feed where the ONIX message contains Product records for all the supplier’s products, or it may be supplied in the context of a ‘delta’ feed where a message contains only Product records which contain data that has been updated since a previous message was sent. In either case, all previously-supplied data for the product should be entirely replaced by the new data in the message. Data from any previously-supplied records relating to products not included in a delta message should continue to be used unchanged.

Note that, for recipients, the treatment of the records in the message is the same, whether the message is a full-feed or a delta – the difference between the two is simply in the selection of records included in the message.

The second type, as yet not in widespread use, is a ‘block-level partial update’ (or simply, ‘block update’) record that contains Groups P.1 and P.2 (which are sometimes informally referred to as ‘block zero’) plus only those of Blocks 1–6 which contain data that has changed since a previous Product record was supplied. If a particular Product record contains only Groups P.1, P.2 and Block 4, it means that recipients should update information based on the Groups and Blocks supplied, and any previously-supplied data from Blocks 1–3, 5 and 6 should continue to be used unchanged. This type of Product record may be supplied only in the context of a ‘delta’ feed, and must also be distinguished with <NotificationType> code 04.

Note that for a block-level partial update, if any of the data in a block has changed, the whole block must be supplied. Granularity of updates does not extend below block level.

This update strategy means that if a previously-supplied data element is not supplied in any update (full or partial), then the previously-supplied data should be deleted from the recipient’s systems. For example, if a previous message included three contributors, and the update contains only two, the third contributor should be deleted (and in fact, it’s more correct to say that all three previous contributors should be deleted, then the newly-supplied two should be re-inserted).

Block 6 consists of the repeatable <ProductSupply> composite: for the purposes of sending block-level partial updates, a record containing several repeats of <ProductSupply> has only one Block 6. If one particular repeat must be updated, all repeats must be included in the block-level update. But for recipients, Block 6 is exceptional: a recipient may receive supply detail information from several sources (eg a retailer may receive data from a distributor and from several wholesalers). For Blocks 1–5, one particular source of data is likely to be definitive or more trusted. But for Block 6, the recipient should probably treat each feed separately – the wholesaler’s Block 6 may need to be retained in parallel with the Block 6 received from the distributor.

P.1 Record reference, type and source

identifying a Product record (using a meaningless internal ID)
using Reference names
`<!-- record 71 of 246 -->`
`<RecordReference>com.xyzpublishers.onix.32032</RecordReference>`
`<NotificationType>02</NotificationType>`
`<RecordSourceType>01</RecordSourceType>`
`<RecordSourceName>XYZ Publishers</RecordSourceName>`

using Short tags
`<!-- record 71 of 246 -->`	XML comment
`<a001>com.xyzpublishers.onix.32032</a001>`	Row ID from internal database
`<a002>02</a002>`	Advance notification
`<a194>01</a194>`	From publisher
`<a197>XYZ Publishers</a197>`

identifying a Product record (using a UUID)
using Reference names
`<!-- record 31 of 46 -->`
`<RecordReference>f3a85abd-f29e-4e0b-92cc-2fa6a0833022</RecordReference>`
`<NotificationType>04</NotificationType>`
`<RecordSourceType>01</RecordSourceType>`
`<RecordSourceName>XYZ Publishers</RecordSourceName>`

using Short tags
`<!-- record 31 of 46 -->`
`<a001>f3a85abd-f29e-4e0b-92cc-2fa6a0833022</a001>`	Type 4 UUID
`<a002>04</a002>`	Block-level update
`<a194>01</a194>`	From publisher
`<a197>XYZ Publishers</a197>`

identifying a Product record sent for testing purposes
using Reference names
`<!-- record 1 of 1 (test) -->`
`<RecordReference>com.xyzpublishers.onix.9932032</RecordReference>`
`<NotificationType>89</NotificationType>`
`<RecordSourceType>01</RecordSourceType>`
`<RecordSourceName>XYZ Publishers</RecordSourceName>`

using Short tags
`<!-- record 1 of 1 (test) -->`
`<a001>com.xyzpublishers.onix.9932032</a001>`	Test ID should not match any previously-sent live ID
`<a002>89</a002>`	Test record
`<a194>01</a194>`	From publisher
`<a197>XYZ Publishers</a197>`

deleting a Product record that was issued in error
using Reference names
`<RecordReference>com.a2b.wms.01234567</RecordReference>`
`<NotificationType>05</NotificationType>`
`<DeletionText>Record issued in error – use record com.a2b.wms.01234574 instead</DeletionText>`
`<RecordSourceType>03</RecordSourceType>`
`<RecordSourceName>A2B Logistics</RecordSourceName>`

using Short tags
`<a001>com.a2b.wms.01234567</a001>`
`<a002>05</a002>`	Deletion
`<a199>Record issued in error – use record com.a2b.wms.01234574 instead</a199>`
`<a194>03</a194>`	From wholesaler
`<a197>A2B Logistics</a197>`

In addition, a complete Product record for a deletion requires a <ProductIdentifier> composite, but no other part of the Product record is necessary.

P.1.1 Record reference

The <RecordReference> element is mandatory in every Product record. It serves to identify the Product record itself, so it must obviously be unique within a particular ONIX message file, and must not change if the Product record (with either identical or modified data) is resupplied in a subsequent message. Note the record reference does not identify the product, but rather the collection of metadata that describes the product. For this reason, the record reference should not be (or look like) a product identifier such as an ISBN. However, the record reference may include a product identifier within some longer string of characters, where for example the publisher’s internal product management system relies on the ISBN as a key field.

: Reliance on an external public identifier as a key field in an internal database is generally considered bad practice. Database keys should be unique and persistent of course, but ideally also meaningless (ie have low affordance). In an internal database design, ISBNs are best treated as attributes of each record, and arbitrary row IDs or UUIDs generated by the database, or purely internal product numbers would be ideal key fields – this maximizes the flexibility of the database design, and of course ensures that records can be added to the database prior to ISBN assignment.

Data recipients may receive Product records relating to a single product from multiple sources – for example, a retailer may receive different records for the same product from several wholesalers. In order to ensure these records can be distinguished and – if necessary – managed separately, record references should as far as possible be globally unique: to ensure uniqueness, it is a good practice to use a record reference that includes a reversed Internet domain name (for example, ‘com.xyzpublisher’). Ideally this should be suffixed with an internal product identifier, or with a product identifier such as the ISBN. An arbitrary internal identifier (such as a record ID in an internal database) is somewhat better than an ISBN, as it will remain unchanged in the rare case where an ISBN may need to be corrected. Alternatively, a UUID (Universally Unique Identifier) constructed in accordance with RFC 4122 would make a good Record reference (types 1 or 4 are best).

When creating unique record references in this way, avoid the characters /, \, $, *, %, ? plus the space and colon characters. Why? Because the record reference can be used to construct filenames for supporting resources (see Group P.16) and these characters often have special meanings or are not allowed in filenames.

Where a single organization has more than one IT system that generates ONIX messages, the record reference should also include an indication of which system the record was generated by.

See P.1.4 Record source type code for details of how data aggregators/redistributors should handle record references.

P.1.2 Notification or update type code

The mandatory <NotificationType> element specifies the ‘type’ of Product record – whether the Product record contains pre-publication data that is subject to significant change, or whether it contains data confirmed upon or subsequent to publication.

The notification type changes in Product records issued at different times in the product’s lifecycle. Later Product records may be matched with their predecessors by matching the <RecordReference> element. An initial ONIX record may be issued a few months in advance of expected publication, with <NotificationType> 01 or 02 (values are taken from List 1). This may be followed by successive updated records with the matching <RecordReference> and with <NotificationType> 02 or 04 (the former for a full update of the whole record, the latter for a block-level partial update containing P.1, P.2 plus only those of Blocks 1–6 that have been updated). It is best practice to issue a full update with type 03 to confirm publication, even when block-level updates are used otherwise, and even when nothing other than the <PublishingStatus> in Block 4 and the <ProductAvailability> in Block 6 have changed. Any post-publication updates – for example price and availability updates – would be types 03 or 04.

Note that List 1 contains other notification type codes for various special purposes: code 05 should be used to indicate a record (as identified by its <RecordReference>) should be deleted (but also see <DeletionText> in P.1.3), and codes 08 and 09 should be used to provide notice of sale and acquisition of products (as identified by a product identifier in P.2, not the <RecordReference>, since it is unlikely the two publishers concerned will use the same Record reference). Code 08, a notice of sale that is sent by the former publisher, should if possible be dealt with as a block-level update by senders and recipients, since best practice for this record type is to include P.1, P.2 and Block 4 only. Code 09, a notice of acquisition, should be treated as a full update, and should be sent by the acquiring publisher. Records containing notification type codes 88 and 89 should always be ignored if they appear in a live data feed – they are intended for use in test messages only, and it is highly inadvisable to mix test and live records in the same ONIX message.

The diagram shows the <NotificationType> codes of two possible sequences of matching product records within a series of ONIX messages, the left timeline starting with an initial message sent more than six months in advance of expected publication and using only ‘full update’ Product records, and the right timeline starting with an initial message sent fewer than six months in advance of publication and using block-level ‘partial update’ Product records.

When using a potentially very long series of block updates, it is still a useful practice to provide a full update (type 03) at the time of publication for confirmation purposes. This ensures that the record is corrected around publication time, even if earlier updates were applied wrongly for any reason.

Note that the very first inclusion of a particular product in a data feed does not necessarily use <NotificationType> 01 – the notification type indicates the ‘age’ relative to the publication date, and thus provides some measure of confidence in the data. Data in records with <NotificationType> 01 should be treated as highly provisional, and some recipients may choose not to use type 01 records in consumer-facing contexts. If the first notification is later than six months prior to publication, confidence in the data should be higher, and type 02 should be used immediately even if this is the first time the record has been included in a feed. Type 03 should indicate a very high degree of confidence in the data – though this still does not preclude future post-publication correction of genuine errors, updates of data elements such as price and availability, or enhancement of the data by addition of extra information.

For recipients, the treatment of Product records with notification types 01, 02 and 03 is identical. First check whether a Product record with a matching Record reference has been received earlier. If so, it is a record update, and all data in the existing record should be replaced by the newly-received information (this might be through deleting the old record and creating a new one). Otherwise, a new record should be created using the newly-received information. For a record with notification type 04, only certain parts of the existing record should be updated, according to which Blocks are newly-received.

Note that Product records with differing <NotificationType> codes can be freely mixed within a single ONIX for Books message. However, senders should check with recipients before introducing any block-level partial updates, since not all recipients can cope with records of this type. And it is inadvisable to mix live and test records in a single message.

P.1.3 Reason for deletion

When the <NotificationType> code is 05, the reason for deletion should be included. Deletion refers to deletion of a metadata record, not to ‘deletion’ of a product – for example, deletion might be used to resolve a problem where two records have inadvertently been issued for the same product. Abandonment or cancellation of a planned and announced product, or declaring an existing product out of print are not reasons for deletion of a Product record from recipient systems (they should be treated as changes of <PublishingStatus> in Group P.20 or <MarketPublishingStatus> in Group P.25).

Deletions should be extremely rare, and are likely to be processed manually by data recipients.

<DeletionText> is one of a number of textual data elements that are repeatable in order that parallel text may be provided in multiple languages. See the notes with <BiographicalNote> for a fuller explanation.

P.1.4 Record source type code

<RecordSourceType>, <RecordSourceName> and – if possible – <RecordSourceIdentifier> should be set, particularly when they indicate that the record source is different from the <Sender> organization. This happens when data from multiple sources is aggregated and redistributed, for example by a distributor, wholesaler or bibliographic data supplier.

Where an organization aggregates and redistributes product data, the Product records within the redistributed data might retain the same <RecordReference> as the data supplied to the aggregator, or the aggregator may attach new a <RecordReference> to each record. The choice here should be guided by whether the aggregator simply resends exactly what is received, or whether the data is actively managed before redistribution. In the former case, where aggregation is a purely technical exercise, the original record reference should be retained, and the original source of each record should be indicated in <RecordSourceType>, <RecordSourceName> and possibly <RecordSourceIdentifier> data elements. The aggregator should use the <Sender> information, or the <RecordSourceType>, <RecordSourceName> and <RecordSourceIdentifier> elements, from the received records to populate these data elements. In addition, the <SentDateTime> from the received records may be reused as a datestamp attribute attached to the <Product> element in the sent data to indicate the age of the data.

Conversely, if the aggregator actively manages the data prior to redistribution, the aggregator assumes effective responsibility for the data. As a result, it should use a new <RecordReference> and record source information on each record. This clearly indicates that the aggregator is responsible for the redistributed data. This way, the combination of <Sender> information in the <Header> of a message containing redistributed data and the Record source information within each Product record indicate where responsibility for the data content lies.


: The preferred <RecordSourceIDType> for international use is the GLN (code 06 from List 44).

P.2 Product numbers

identifying a product with an ISBN and proprietary SKU
using Reference names
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`	GTIN-13
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`	ISBN
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>01</ProductIDType>`	Proprietary
`<IDTypeName>BookPoint Wholesale SKU</IDTypeName>`
`<IDValue>BP0054321</IDValue>`
`</ProductIdentifier>`

using Short tags, with additional ISBN-A
`<productidentifier>`
`<b221>03</b221>`	GTIN-13
`<b244>9780001234567</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780001234567</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>01</b221>`	Proprietary
`<b233>BookPoint Wholesale SKU</b233>`
`<b244>BP0054321</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>06</b221>`	DOI
`<b244>10.978.000/1234567</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>26</b221>`	ISBN-A
`<b244>10.978.000/1234567</b244>`
`</productidentifier>`

Product identifier composite

At least one repeat of the <ProductIdentifier> composite is mandatory. Typically this will carry a standard identifier such as the ISBN that can be used for orders or sales reports within a trading relationship, but the whole composite is repeatable and other standard identifiers, and proprietary identifiers or SKUs may be sent in addition.


: Do not bypass <IDTypeName> if <ProductIDType> is proprietary (code 01). Conversely, omit <IDTypeName> for non-proprietary identifier types. This applies to proprietary identifiers in similar composites throughout ONIX 3.0.

For any item that carries an ISBN, it is best practice to include the identifier twice, in separate repeats of the <ProductIdentifier> composite with <ProductIDType> codes 03 and 15. Why? Because some recipients are looking specifically for an ISBN, others for any GTIN-13. The same applies to a product carrying an ISMN (use codes 03 and 25). If instead the product carries a GTIN-13 that is not an ISBN or ISMN, this should be carried in a composite with <ProductIDType> code 03. ISBNs, ISMNs and GTIN-13s should not include hyphens or spaces.

Very occasionally, a product has both an ISBN and a separate GTIN-13 that is not an ISBN. While the assignment of a separate GTIN to an item with an ISBN is entirely unnecessary (the ISBN is by definition also a valid GTIN-13), it sometimes happens that a stationery item which has a GTIN-13 enters the books supply chain where some organization requires an ISBN. If this is unavoidable, the ISBN should be carried with <ProductIDType> code 15 and the ‘other’ GTIN-13 should be carried with code 03.

If the product’s ISBN is also registered as an ISBN-A (‘Actionable ISBN’), this should be carried in two further composites with type code 06 (ie as a DOI) and code 26 (ie specifically as an ISBN-A) – just as with ISBN and GTIN-13. And note that for a DOI or ISBN-A, the period and slash (/) characters plus any hyphens and other puctuation characters are an essential part of the identifier. A <ProductIdentifier> composite carrying an ISBN-A should always be accompanied by a composite carrying the matching ISBN – thus it is best practice to include three <ProductIdentifier> composites alongside a composite carrying an ISBN-A (the ISBN-A itself, plus the generic DOI, the ISBN and the generic GTIN-13). All, of course, carry essentially the same number.

In some trading relationships, the GTIN-14 identifier is useful. Broadly, the GTIN-14 identifies trade items, whereas the GTIN-13 identifies retail items. So where an ONIX record describes multiple retail items in a trade-only pack, the pack may be identified with a GTIN-14. The GTIN-14 may be specified in the metadata record (for the pack) using <ProductIDType> code 14 (and within this record, the GTIN-13 of the items in the pack should be carried inside <ProductPart>). There may also be a separate metadata record for the individual retail items in the pack, and that record should not include the GTIN-14. Note that although any GTIN-13 may be expressed as a GTIN-14 simply by prefixing it with a zero, an ONIX record should not carry a GTIN-14 constructed ‘artificially’ in this way, unless the product actually carries a GTIN-14 barcode (which uses a different barcode ‘symbology’ from the GTIN-13).

The continued use of obsolete identifiers such as the ISBN-10 is strongly discouraged, but they may still be needed by certain recipients within the context of a specific trading relationship. If provided, they should be carried alongside an ISBN or GTIN-13.

Use of non-product specific ‘identifiers’ such as price-point GTIN-12s (formerly called UPCs or UCC-12s) as the only identifier is not sufficient as these do not identify specific tradeable items. However, item-specific GTIN-12s or UPCs do identify tradeable items, and should be included in the metadata when (and only when) the product carries a UPC number or barcode, and should use <ProductIDType> code 04. Although any GTIN-12 may be expressed as a GTIN-13 by prefixing the GTIN-12 with a zero, an ONIX record should not carry a GTIN-13 constructed in this way (as for example it would imply the use of a different barcode symbology).

If a proprietary identifier such as a publisher’s internal product identifier, a catalog number or a wholesaler’s SKU is used (<ProductIDType> code 01), then a ‘namespace’ – a consistent name for that identifier – should always be included in the <IDTypeName> element. This applies to all uses of proprietary identifiers or proprietary coding schemes within ONIX for Books – a name for the scheme or identifier should always be included. When minting such names, the data provider should try to promote uniqueness by (for example) including an appropriate organization or domain name, and some indication of what is being identified. ‘PubID’ and ‘SKU’ are not a good names – too likely to be used by others and thus likely not to be unique – whereas ‘Olive Press SKU’ or ‘com.duckhouse.product.id’ are much better. The <IDTypeName> data element has a suggested maximum length of 50 characters.

Many supply chain organizations (correctly) allocate so-called ‘2-series’ GTIN-13s as proprietary identifiers. These numbers (thirteen digits beginning with a 2 and ending with the usual GTIN calculated check digit) come from a range of GTINs designated ‘for internal use only’. Such proprietary identifiers should not usually be included in ONIX records, since they are not intended for communication between organizations. If they are included, in the context of an agreed one-to-one exchange of ONIX data between parties, they must be treated as proprietary IDs, with <ProductIDType> 01 and a suitable, likely-to-be-unique name in <IDTypeName>, and not as GTIN-13s with <ProductIDType> 03.

The <ProductIdentifier> composite is also used to deliver various identifiers that are not used for supply chain transactions, but are important to particular groups of data users – for example library identifiers such as Library of Congress control numbers, OCLC identifiers and national legal deposit numbers. Where these are included in the Product record, they should be accompanied by one or more standard product identifiers.

Barcode composite

This composite specifies whether the product carries a printed barcode, and if so, its symbology and optionally its position. Although in most countries the use of GTIN-13 barcodes on physical products is ubiquitous and need not be stated, in North America the continued use of GTIN-12s means that the symbology is valuable information for retailers. It should be repeated where a product carries more than one barcode.

The composite can also be used to provide a positive indication that the product does not carry a barcode, even when it might be expected (perhaps because the product is of unusually small size).

standard ISBN (GTIN-13) barcode on back cover
using Reference names
`<Barcode>`
`<BarcodeType>02</BarcodeType>`
`<PositionOnProduct>01</PositionOnProduct>`
`</Barcode>`

using Short tags
`<barcode>`
`<x312>02</x312>`	GTIN-13 symbology (no extension)
`<x313>01</x313>`	on Cover 4 (outside back cover)
`</barcode>`

no barcode
using Reference names
`<Barcode>`
`<BarcodeType>00</BarcodeType>`
`</Barcode>`

using Short tags
`<barcode>`
`<x312>00</x312>`	No barcode on product
`</barcode>`

Block 1: Product description

Descriptive detail composite

Block 1 of the Product record is intended to carry the core information about the physical or digital nature of the product, its title and authorship, content and subject matter, and it’s target audience.

P.3 Product form

If the Product record contains a <DescriptiveDetail> composite, then that composite must contain some data elements from P.3. The <DescriptiveDetail> composite:

must include the <ProductComposition> and <ProductForm> elements:
- if the record represents a multi-item product (or collection) with <ProductComposition> codes 10, 11 or 30, then P.4 Product part information should also be included in the Product record;
should include any relevant <ProductFormDetail> and (where it conveys an important product attribute) <ProductFormFeature> information:
- for a digital product, <ProductFormDetail> should specify the file format. Where file formats are versioned (eg EPUB 2, EPUB 3) then the version information should be included in a <ProductFormFeature> composite;
- <ProductFormFeature> should include any relevant hazard warnings and product safety information;
for a physical product:
- should describe any packaging using the <ProductPackaging> element;
- should include details of the product content using the <PrimaryContentType> and <ProductContentType> elements, particularly if the product is not a simple textual product;
- should include linear dimensions, and whenever possible, the weight of the product using the <Measure> composite;
- should include the country of manufacture;
for a digital product:
- should include details of any technical requirements (hardware or software) etc in the <ProductFormFeature> composite;
- should include details of technical protection measures incorporated in the product, and any usage constraints (whether enforced by technical measures or not), using the <EpubTechnicalProtection> element and the <EpubUsageConstraint> composite;
- should include details of the product content using the <PrimaryContentType> and <ProductContentType> elements, particularly if the product is an ‘enhanced e-book’ or is not a simple textual product;
for a cartographic product should include the <MapScale> data element.

Additional guidance on the description of digital products in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Describe Digital Products in ONIX 3.

describing the form of a simple paperback book product
using Reference names, with measurements provided in both Imperial and metric units for broad international use including North America
`<ProductComposition>00</ProductComposition>`
`<ProductForm>BC</ProductForm>`
`<ProductFormDetail>B101</ProductFormDetail>`	Rack-size paperback
`<Measure>`	7⅛ × 4¼ in, ⅝ in spine
`<MeasureType>01</MeasureType>`
`<Measurement>7.125</Measurement>`
`<MeasureUnitCode>in</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>02</MeasureType>`
`<Measurement>4.25</Measurement>`
`<MeasureUnitCode>in</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>03</MeasureType>`
`<Measurement>0.625</Measurement>`
`<MeasureUnitCode>in</MeasureUnitCode>`
`</Measure>`
`<Measure>`	Weight 6⅞ oz
`<MeasureType>08</MeasureType>`
`<Measurement>6.875</Measurement>`
`<MeasureUnitCode>oz</MeasureUnitCode>`
`</Measure>`
`<Measure>`	Same measurements
`<MeasureType>01</MeasureType>`	using mm and gr
`<Measurement>181</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>02</MeasureType>`
`<Measurement>108</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>03</MeasureType>`
`<Measurement>16</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>08</MeasureType>`
`<Measurement>195</Measurement>`
`<MeasureUnitCode>gr</MeasureUnitCode>`
`</Measure>`
`<CountryOfManufacture>US</CountryOfManufacture>`	Manufactured in USA

using Short tags, with measurements provided in metric units only, for international use excluding North America
`<x314>00</x314>`	Single-item product
`<b012>BC</b012>`	Paperback
`<b333>B106</b333>`	Trade paperback (UK usage)
`<measure>`	Traditional ‘Demy’ size
`<x315>01</x315>`	216 × 138 mm, 19 mm spine
`<c094>216</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`
`<x315>02</x315>`
`<c094>138</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`
`<x315>03</x315>`
`<c094>19</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`	Weight 345 gr
`<x315>08</x315>`
`<c094>345</c094>`
`<c095>gr</c095>`
`</measure>`
`<x316>GB</x316>`	Made in UK

US usage of ‘trade paperback’ is close to UK usage of ‘B-format’. UK usage of ‘trade paperback’ indicates a paperback produced in a larger size (typically a Demy or Royal size).

describing a packaged multi-item product (small book and audio CD in a blister pack)
using Reference names
`<ProductComposition>10</ProductComposition>`
`<ProductForm>SA</ProductForm>`
`<ProductPackaging>22</ProductPackaging>`
`<Measure>`
`<MeasureType>01</MeasureType>`
`<Measurement>145</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>02</MeasureType>`
`<Measurement>195</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>03</MeasureType>`
`<Measurement>11</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>08</MeasureType>`
`<Measurement>195</Measurement>`
`<MeasureUnitCode>gr</MeasureUnitCode>`
`</Measure>`
`<!-- P.4 Product parts must be included, with -->`
`<!-- separate Country of Manufacture per item -->`

using Short tags
`<x314>10</x314>`	Multi-item product
`<b012>SA</b012>`	Packaging unspecified
`<b225>22</b225>`	Blister pack
`<measure>`
`<x315>01</x315>`	Pack is 145 × 195 mm,
`<c094>145</c094>`	11 mm thick
`<c095>mm</c095>`
`</measure>`
`<measure>`	Note shape is ‘landscape’
`<x315>02</x315>`
`<c094>195</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`
`<x315>03</x315>`
`<c094>11</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`	Weight 195 gr
`<x315>08</x315>`
`<c094>195</c094>`
`<c095>gr</c095>`
`</measure>`
`<!-- P.4 Product parts must be included, -->`
`<!-- with separate x316 per item -->`

providing e-book details for an enhanced EPUB format product, with usage constraints enforced by technical protection measures (‘DRM’)
using Reference names
`<ProductComposition>00</ProductComposition>`
`<ProductForm>ED</ProductForm>`
`<ProductFormDetail>E101</ProductFormDetail>`
`<ProductFormDetail>E201</ProductFormDetail>`
`<ProductFormDetail>E202</ProductFormDetail>`
`<ProductFormFeature>`
`<ProductFormFeatureType>15</ProductFormFeatureType>`
`<ProductFormFeatureValue>101B</ProductFormFeatureValue>`
`</ProductFormFeature>`
`<PrimaryContentType>10</PrimaryContentType>`
`<ProductContentType>06</ProductContentType>`
`<ProductContentType>13</ProductContentType>`
`<EpubTechnicalProtection>03</EpubTechnicalProtection>`
`<EpubUsageConstraint>`
`<EpubUsageType>05</EpubUsageType>`
`<EpubUsageStatus>01</EpubUsageStatus>`
`</EpubUsageConstraint>`
`<EpubUsageConstraint>`
`<EpubUsageType>03</EpubUsageType>`
`<EpubUsageStatus>02</EpubUsageStatus>`
`<EpubUsageLimit>`
`<Quantity>10</Quantity>`
`<EpubUsageUnit>05</EpubUsageUnit>`
`</EpubUsageLimit>`
`</EpubUsageConstraint>`
`<EpubUsageConstraint>`
`<EpubUsageType>06</EpubUsageType>`
`<EpubUsageStatus>02</EpubUsageStatus>`
`<EpubUsageLimit>`
`<Quantity>1</Quantity>`
`<EpubUsageUnit>10</EpubUsageUnit>`
`</EpubUsageLimit>`
`<EpubUsageLimit>`
`<Quantity>14</Quantity>`
`<EpubUsageUnit>09</EpubUsageUnit>`
`</EpubUsageLimit>`
`</EpubUsageConstraint>`
`<EpubUsageConstraint>`
`<EpubUsageType>02</EpubUsageType>`	Printing
`<EpubUsageStatus>03</EpubUsageStatus>`	Is disallowed
`</EpubUsageConstraint>`

using Short tags (additionally, printing is allowed but restricted)
`<x314>00</x314>`	Single-item product
`<b012>ED</b012>`	Digital download
`<b333>E101</b333>`	EPUB format
`<b333>E201</b333>`	Fixed format
`<b333>E202</b333>`	Does not require network connection (the video and audio resources are packaged within the EPUB itself)
`<productformfeature>`
`<b334>15</b334>`	File format version code
`<b335>101B</b335>`	EPUB 3.0
`</productformfeature>`
`<x416>10</x416>`	Eye-readable text
`<b385>06</b385>`	Enhanced with video
`<b385>13</b385>`	and audio content
`<x317>03</x317>`	ACS4 DRM
`<epubusageconstraint>`
`<x318>05</x318>`	Text to speech
`<x319>01</x319>`	Is unrestricted
`</epubusageconstraint>`
`<epubusageconstraint>`
`<x318>03</x318>`	Copy/paste
`<x319>02</x319>`	Is limited
`<epubusagelimit>`
`<x320>10</x320>`	Ten
`<x321>05</x321>`	Percent
`</epubusagelimit>`
`</epubusageconstraint>`
`<epubusageconstraint>`
`<x318>06</x318>`	Lending
`<x319>02</x319>`	Is limited
`<epubusagelimit>`
`<x320>1</x320>`	Only one
`<x321>10</x321>`	Occasion
`</epubusagelimit>`
`<epubusagelimit>`
`<x320>14</x320>`	For fourteen
`<x321>09</x321>`	Days
`</epubusagelimit>`
`</epubusageconstraint>`
`<epubusageconstraint>`
`<x318>02</x318>`	Printing
`<x319>02</x319>`	Is limited
`<epubusagelimit>`
`<x320>64</x320>`	Max of 64 pages
`<x321>04</x321>`
`</epubusagelimit>`
`<epubusagelimit>`
`<x320>72</x320>`	Max of 72dpi
`<x321>21</x321>`
`</epubusagelimit>`
`</epubusageconstraint>`

providing both folded and flat dimensions, plus scales, for a road map with larger-scale inset city map panels
using Reference names
`<ProductComposition>00</ProductComposition>`
`<ProductForm>CB</ProductForm>`
`<Measure>`
`<MeasureType>01</MeasureType>`
`<Measurement>245</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>02</MeasureType>`
`<Measurement>140</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>10</MeasureType>`
`<Measurement>980</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>11</MeasureType>`
`<Measurement>1120</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>08</MeasureType>`
`<Measurement>125</Measurement>`
`<MeasureUnitCode>gr</MeasureUnitCode>`
`</Measure>`
`<CountryOfManufacture>ES</CountryOfManufacture>`
`<MapScale>500000</MapScale>`
`<MapScale>25000</MapScale>`

using Short tags
`<x314>00</x314>`	Single-item product
`<b012>CB</b012>`	Sheet map, folded
`<measure>`	Folded size
`<x315>01</x315>`	245 × 140 mm
`<c094>245</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`
`<x315>02</x315>`
`<c094>140</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`
`<x315>10</x315>`	980 × 1120 mm flat
`<c094>980</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`
`<x315>11</x315>`
`<c094>1120</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`
`<x315>08</x315>`	Weight 125 gr
`<c094>125</c094>`
`<c095>gr</c095>`
`</measure>`
`<x316>ES</x316>`	Manufactured in Spain
`<b063>500000</b063>`	Scale 1cm to 5km
`<b063>25000</b063>`	Insets at 4cm to 1km

trade pack containing multiple books
using Reference names
`<ProductComposition>30</ProductComposition>`
`<ProductForm>XL</ProductForm>`
`<Measure>`
`<MeasureType>01</MeasureType>`
`<Measurement>395</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>02</MeasureType>`
`<Measurement>260</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>03</MeasureType>`
`<Measurement>180</Measurement>`
`<MeasureUnitCode>mm</MeasureUnitCode>`
`</Measure>`
`<Measure>`
`<MeasureType>08</MeasureType>`
`<Measurement>1950</Measurement>`
`<MeasureUnitCode>gr</MeasureUnitCode>`
`</Measure>`
`<ProductPart>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductForm>BC<ProductForm>`
`<ProductFormDetail>B105</ProductFormDetail>`
`<NumberOfCopies>48</NumberOfCopies>`
`<CountryOfManufacture>GB</CountryOfManufacture>`
`</ProductPart>`

using Short tags
`<x314>30</x314>`	Multi-item trade pack
`<b012>XL</b012>`	Shrink-wrapped pack
`<measure>`
`<x315>01</x315>`	197 × 130 mm, 18mm spine,
`<c094>394</c094>`	packed 2 × 2 × 12
`<c095>mm</c095>`	(48 copies total)
`</measure>`
`<measure>`
`<x315>02</x315>`
`<c094>260</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`
`<x315>03</x315>`
`<c094>216</c094>`
`<c095>mm</c095>`
`</measure>`
`<measure>`
`<x315>08</x315>`
`<c094>1950</c094>`
`<c095>gr</c095>`
`</measure>`
`<productpart>`
`<productidentifier>`
`<b221>03</b221>`	GTIN-13 and…
`<b244>9780001234567</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN of the book inside the pack
`<b244>9780001234567</b244>`	(the ISBN or GTIN-14 of the pack must be different)
`</productidentifier>`
`<b012>BC<b012>`	B-format paperback
`<b333>B105</b333>`
`<x323>48</x323>`	48 copies
`<x316>GB</x316>`
`</productpart>`

book-as-toy with safety warnings (EU Toy Safety Directive)
using Reference names
`<ProductComposition>00</ProductComposition>`
`<ProductForm>BK</ProductForm>`
`<ProductFormDetail>B213</ProductFormDetail>`
`<ProductFormDetail>B215</ProductFormDetail>`
`<ProductFormFeature>`
`<ProductFormFeatureType>13</ProductFormFeatureType>`
`<ProductFormFeatureValue>01</ProductFormFeatureValue>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>13</ProductFormFeatureType>`
`<ProductFormFeatureValue>07</ProductFormFeatureValue>`
`<ProductFormFeatureDescription>http://www.livrescoccinelle.fr/4123/CEdéclaration.pdf</ProductFormFeatureDescription>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>13</ProductFormFeatureType>`
`<ProductFormFeatureValue>03</ProductFormFeatureValue>`
`<ProductFormFeatureDescription>Not suitable for children under 36 months, due to small parts</ProductFormFeatureDescription>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>13</ProductFormFeatureType>`
`<ProductFormFeatureValue>05</ProductFormFeatureValue>`
`<ProductFormFeatureDescription>Not tested on animals</ProductFormFeatureDescription>`
`</ProductFormFeature>`
`<!-- <Measure> omitted for brevity -->`
`<CountryOfManufacture>CN</CountryOfManufacture>`

using Short tags, with safety warning text provided in two parallel languages (English and French)
`<x314>00</x314>`	Single item product
`<b012>BK</b012>`	Novelty book
`<b333>B213</b333>`	Book-as-toy
`<b333>B215</b333>`	Fuzzy felt book
`<productformfeature>`
`<b334>13</b334>`	EU Toy Safety
`<b335>01</b335>`	Carries ‘CE’ logo
`</productformfeature>`
`<productformfeature>`
`<b334>13</b334>`	EU Toy Safety
`<b335>07</b335>`	‘CE’ Declaration of Conformity
`<b336>http://www.livrescoccinelle.fr/4123/CEdéclaration.pdf</b336>`	URL of full document
`</productformfeature>`
`<productformfeature>`
`<b334>13</b334>`	EU Toy Safety hazard warning
`<b335>03</b335>`	Carries ‘0–3’ logo and warning
`<b336 language="eng">Not suitable for children under 36 months, due to small parts</b336>`	Publisher’s exact wording of warning
`<b336 language="fre">Ne convient pas aux enfants de moins de 3 ans, contient de petites pièces susceptibles d’être ingérées</b336>`
`</productformfeature>`
`<productformfeature>`
`<b334>13</b334>`	EU Toy Safety
`<b335>05</b335>`	Associated non-warning text
`<b336 language="eng">Not tested on animals</b336>`	Publisher’s exact wording of associated text
`<b336 language="fre">Non testé sur les animaux</b336>`
`</productformfeature>`
`<!-- <measure> omitted for brevity -->`
`<x316>CN</x316>`	Made in China

Where text is provided in parallel languages, the language attribute must be included for each language. Where only a single language is provided, the attribute is optional.

P.3.1 Product composition

The <DescriptiveDetail> composite must begin with a mandatory <ProductComposition> element, to specify whether the product:

is a solus item (codes 00 or 20 from List 2);
contains multiple items (for example, several volumes in a set retailed as one product, or a ‘classroom pack’ of textbooks, with code 10);
contains multiple items that are expected to be retailed individually (code 30);
Code 11 is an exception in that it describes a collection that is not itself a product.

If the record is not a solus item (ie <ProductComposition> codes 10, 11 or 30) then P.4 Product part information should always be included in the Product record.

Note that products such as an audiobook that consists of multiple CDs are usually not treated as a multi-item retail product (ie it is common to use <ProductComposition> code 00, and the number of discs may be included in <ProductFormDescription>). This is somewhat inconsistent, as a multi-volume collection available as a single item – for example, a boxed set – is generally treated as a multiple-item retail product (ie use <ProductComposition> code 10). However, individual discs are almost never available separately, they have essentially no value without the remainder of the discs, nor do they have individual product identifiers, so treating a multi-disc audiobook as a multi-item product and enumerating the discs using a single repetition of <ProductPart> may be viewed as unnecessary:

describing a multi-disc audiobook as a multi-item retail product
using Reference names
`<ProductComposition>10</ProductComposition>`
`<ProductForm>SA</ProductForm>`
`<ProductPackaging>05</ProductPackaging>`
`<!-- <Measure> omitted for brevity -->`
`<CountryOfManufacture>AT</CountryOfManufacture>`
`<ProductPart>`
`<!-- discs not individually identified -->`
`<ProductForm>AC</ProductForm>`
`<ProductFormDetail>A101</ProductFormDetail>`
`<NumberOfItemsOfThisForm>5</NumberOfItemsOfThisForm>`
`</ProductPart>`

using Short tags
`<x314>10</x314>`	Multi-item product
`<b012>SA</b012>`	Packaging unspecified
`<b225>05</b225>`	In jewel case
`<!-- <measure> omitted -->`
`<x316>AT</x316>`	Pressed in Austria
`<productpart>`
`<!-- discs not individually identified -->`
`<b012>AC</b012>`	CD-Audio
`<b333>A101</b333>`	‘Red book’
`<x322>5</x322>`	5 discs
`</productpart>`

describing a multi-disc audiobook as a single-item product
using Reference names
`<ProductComposition>00</ProductComposition>`
`<ProductForm>AC</ProductForm>`
`<ProductFormDetail>A101</ProductFormDetail>`
`<ProductPackaging>05</ProductPackaging>`
`<ProductFormDescription>5 discs</ProductFormDescription>`
`<!-- <Measure> omitted for brevity -->`
`<CountryOfManufacture>AT</CountryOfManufacture>`
`<!-- no ProductPart composite required -->`

using Short tags
`<x314>00</x314>`	Single-item product
`<b012>AC</b012>`	CD-Audio
`<b333>A101</b333>`	‘Red book’
`<b225>05</b225>`	In jewel case
`<b014>5 discs</b014>`
`<!-- <measure> omitted -->`
`<x316>AT</x316>`	Pressed in Austria
`<!-- no productpart composite -->`

These two examples have exactly equivalent meanings, but the latter, simpler version is preferred, unless the multiple discs are (or could plausibly become) available separately or there is some other reason to describe the discs individually.

P.3.2 Product form code

This element is mandatory within the <DescriptiveDetail> composite, and for single-item products specifies the nature of the product.

It is generally not good practice to use any of the ‘generic’ codes from List 150, for example code BA for ‘Book – detail unspecified’ or code PA for ‘Miscellaneous print – detail unspecified’, unless the product is being described many months before publication and the detail is genuinely undecided. In this case, the generic Product form code must be updated in a later ONIX message. Occasionally, an unusual product might need both a <ProductForm> code and a full description of the product in <ProductFormDescription>.

For multi-item products with <ProductComposition> codes 10 and 11, codes SB–SF from List 150 describe the way that the items are packaged together for retail sale (eg slipcased, shrinkwrapped or with smaller items physically enclosed within the largest item). However, the <ProductPackaging> data element is more flexible, and may be used with <ProductForm> code SA. This implies there are two acceptable ways to describe multi-item products, for example the product form and packaging of several related volumes in a slipcase (commonly termed a ‘boxed set’):

describing a boxed set without using <ProductPackaging>
using Reference names
`<ProductComposition>10</ProductComposition>`
`<ProductForm>SC</ProductForm>`

using Short tags
`<x314>10</x314>`	Multi-item product
`<b012>SC</b012>`	In slip-case

using <ProductPackaging> to describe a boxed set
using Reference names
`<ProductComposition>10</ProductComposition>`
`<ProductForm>SA</ProductForm>`
`<!-- intervening elements not shown -->`
`<ProductPackaging>11</ProductPackaging>`

using Short tags
`<x314>10</x314>`	Multi-item product
`<b012>SA</b012>`	Packaging unspecified
`<!-- intervening elements not shown -->`
`<b225>11</b225>`	Slip-cased set

These two examples have exactly equivalent meanings, but the former method is preferred. However, the latter method may be used whenever codes SB–SF do not adequately describe the packaging method.

For multi-item trade packs with <ProductComposition> code 30, codes XC, XE and XL from List 150 should always be used, rather than using code XA plus <ProductPackaging>. If <ProductPackaging> is included, this should refer to the packaging of each item within the trade pack, not to the trade pack itself. If codes XC, XE or XL do not adequately describe the outer packaging of the trade-only pack, use code XA plus descriptive text in <ProductFormDescription>.

P.3.3 Product form detail

Although this is an optional data element, for certain values of <ProductForm> it provides vital extra detail.

And where such detail is provided, <ProductFormDetail> is also repeatable – there may be several properties of the product that are important. For this and other repeatable simple data elements (eg <MapScale>), it is obviously an error to repeat the same information, and although validation via the DTD or schema will not reject such repetition, extended schema validation may do so.

For audio products:

use <ProductForm> code AC only for CD-Audio (in the sense of ‘Red Book’ CD-Audio or SACD discs) products, which are eligible to carry the relevant standards compliance logos;
- then use <ProductFormDetail> codes A101 and A102 to differentiate CD-Audio and SACD products
use <ProductForm> code AE for data discs which contain audio data in other data formats. Two good examples are ‘MP3 CDs’, which should not carry the Compact Disc Digital Audio logo but which are playable in some CD or DVD player devices, and DAISY books distributed on CD media;
- then use other <ProductFormDetail> codes to specify the format of the audio data on the disc (WAV, MP3, AAC etc);
- reserve <ProductForm> code DB for other types of CD-Rom that contain non-audio data;
use <ProductForm> code ED in preference to code AJ for downloadable digital audio products:
- then use other <ProductFormDetail> codes to specify the data format – for example code A109 for proprietary Audible.com format, A103 for a ‘generic’ MP3 format or A107 for an AAC file;
- in addition, as with e-books, you may include <EpubTechnicalProtection> and <EpubUsageConstraint> information to describe any limitations on usage of the downloaded data, and any DRM or other technical protection measures.

For printed book products:

where <ProductForm> is BB or BC, <ProductFormDetail> B1xx codes may be used to indicate common named categories of product which indicate a certain combination of product form, physical size and sometimes also target market and terms of trade. Physical sizes may be approximate: in contrast, exact measurements should be given in the <Measure> composite;
note the different meaning of ‘Trade paperback’ in the US and UK, and the very similar ‘Paperback (DE)’ in the German book trade;
other <ProductFormDetail> codes should be included to specify any other important feature of the product – for example a feature of a children’s book such as die-cutting or pop-up engineering, or features of fine binding such as the use of real leather or half-binding.

For e-publications such as e-books, mobile apps including book text, <ProductFormDetail> is used to specify either:

a non-proprietary file format such as EPUB (a standard maintained by the IDPF), where any usage constraints and any technical protection measures (DRM) that enforce those usage constraints should be specified separately using the <EpubTechnicalProtection> element and <EpubUsageConstraint> composite;
a proprietary file format, which may include platform-specific technical protection. Any usage constraints and technical protection should be be specified using <EpubTechnicalProtection> and the <EpubUsageConstraint> composite;
further repeats of <ProductFormDetail> can be used to specify whether the text within the e-book reflows or is ‘fixed-format’, what shape of screen a fixed-format e-book is optimized for, whether there are any network-based resources that form a part of the e-book, or whether content present in an equivalent printed publication has been omitted from the e-book (a common occurrence with trade non-fiction books subsequently converted to e-book, where illustration rights cannot be obtained).

Owing to the rapid evolution of e-publication types, this distinction in the treatment of proprietary and non-proprietary file formats is not a strict rule. Additional guidance on the description of digital products in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Describe Digital Products in ONIX 3.

There are common-sense affinities between values of <ProductForm> and values of <ProductFormDetail>. As illustration, these values for <ProductFormDetail> are intended for use only in combination with listed values for <ProductForm>.

Description	ProductForm	ProductFormDetail
CD-Audio	AC	A101–A102
Digital audio files	AA, AE, AJ–L, AZ, D, E	A103–A112 A201–A212
All audio	A, D, E*	A301–A304
Paperback books	BC	B101–B107 B113–B114, B116–B118 B504
Hardback books	BB	B115 B306–B307, B315 B401–B402
Loose leaf	BD	B301–B303
Spiral-bound	BE	B311–B314
Fine binding	BG	B308–B309 B403–B406
All printed books	B*	B108–B112, B119–B130 B201–B215 B304–B305, B310 B409–B415 B501–B503, B505–B510 B601–B602 B701–B707
Digital video files	D, E, VA, VZ	D101–D105
Digital on carrier	D*	D201–D207 D301–D316
e-books and ‘apps’	D, E	E1xx E2xx
Calendars	PC	P101–P113
Calendars or organizers	PC, PS	P114
Stationery	PA, PB, PF, PL, PR, PS, PZ	P201–P204
Analogue video	VA, VI–K, VZ	V201–V203

The associations listed in the table are not enforced by the XSD or RNG schemas, but may be enforced by an extended schema. Other combinations might superficially ‘work’, but do not make sense: for example the combination of Product form AG (Sony’s proprietary MiniDisc) might not be entirely incompatible with Product form detail A103 or A107 (MP3 or AAC format audio) – in that MiniDiscs can be used to store arbitrary data files – but in practice, any commercial MiniDisc products used Sony’s own ATRAC recording format.

Spiral binding types:

Product form feature composite

It is best practice to use the <ProductFormFeature> composite wherever necessary to convey other product attributes that may be significant to the eventual purchaser. To illustrate this, <ProductFormFeature> should be used to specify:

any hazard warnings associated with the product (eg CPSIA or EU Toy Safety Directive hazard warnings), as there may be a legal requirement for the warning to be displayed in an online store catalog;
the binding material used in a fine binding, or the cover color of a hymnal or other religious text (a congregation may wish to purchase matching colors), or where similar products are available in contrasting colorways (eg boy and girl versions);
the text typeface and size used in a large print product, where the exact details may determine suitability of a physical book for a particular print-impaired reader;
any required operating system or other technical requirements, for example for an educational software product or mobile ‘app’;
where an e-publication file format is versioned (eg EPUB 2 and EPUB 3);
‘accessibility’ features provided by an e-publication, such as provision of alternative textual descriptions attached to images within the e-book, or inclusion of mathematical content using MathML rather than embedding equations as images, that may determine the suitability of the product for a print-impaired reader.

In contrast, <ProductFormFeature> is not expected to be used to specify the cover color or typeface name and size of – for example – a typical fiction hardback, where these details are largely immaterial to the purchaser.

Publishers or printers may use <ProductFormFeature> to state the product complies with FSC or PEFC scheme requirements related to the use of paper and board made in an environmentally-responsible way. But they should exercise particular care in claiming FSC or PEFC compliance, where the provenance of raw materials for future manufacturing batches might be uncertain. If a particular impression is for any reason manufactured with non-compliant material, the scheme logo must of course be omitted from those copies. However, all metadata records must also be updated to remove the compliance statement in a timely way. This applies both to metadata held by the publisher or printer, but also metadata held by supply chain partners and third parties. Statements that are not (or cannot) be updated and removed when necessary (which might be on an impression-by-impression basis) may affect future auditing and re-certification of the organization.

Within the <ProductFormFeature> composite, <ProductFormFeatureDescription> is repeatable in order that parallel text may be provided in multiple languages. See the notes with <BiographicalNote> for a fuller explanation, and the example above showing EU Toy Safety Directive warnings.

<ProductFormFeatureDescription> is mandatory with some values of <ProductFormFeatureType> (eg codes 03, 07), and <ProductFormFeatureValue> is omitted. Other Product form feature type codes need no additional description, and <ProductFormFeatureDescription> should be omitted unless it provides greater detail beyond that encoded in <ProductFormFeatureValue>

Description	ProductForm	ProductFormFeature…
		Type	Value ¹	Descr ¹
All printed books	B*	01, 02, 04 03, 08	1 0	0…n 1…n
Regionalized video	VI, VO	05	1	0
Electronic products	A* (except AB, AC, AF), D, E	06 07	1 0	0…n 1…n
e-books and ‘apps’	D, E	09, 10, 15	1	0…n
Hazardous products	any	12, 13, 14	1	0…n
Paper products	B, C, P*	30 31–37 40	0 1 0	0 0…n 0…n

¹ 0 = must be omitted, 1 = mandatory, 0…n = optional and repeatable, 1…n = mandatory and repeatable

specifying color of cover binding material
using Reference names – single color
`<ProductFormFeature>`
`<ProductFormFeatureType>01</ProductFormFeatureType>`
`<ProductFormFeatureValue>PNK</ProductFormFeatureValue>`
`</ProductFormFeature>`

using Short tags – multiple color
`<productformfeature>`
`<b334>01</b334>`	Color of cover
`<b335>MUL</b335>`	Multicolored
`<b336>Pale blue with green panel</b336>`
`</productformfeature>`

specifying the typeface of a large print product
using Reference names
`<ProductFormFeature>`
`<ProductFormFeatureType>03</ProductFormFeatureType>`
`<ProductFormFeatureDescription>Tiresias LP, 18pt</ProductFormFeatureDescription>`
`</ProductFormFeature>`
`. . . .`
`<EditionType>LTE</EditionType>`

using Short tags
`<productformfeature>`
`<b334>03</b334>`	Text font
`<b336>Tiresias LP, 18pt</b336>`
`</productformfeature>`
`. . . .`
`<x419>LTE</x419>`	Large print edition

book manufactured with certified environmentally-responsible paper
using Reference names
`<ProductFormFeature>`
`<ProductFormFeatureType>32</ProductFormFeatureType>`
`<ProductFormFeatureValue>SGS-COC-002061</ProductFormFeatureValue>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>36</ProductFormFeatureType>`
`<ProductFormFeatureValue>35</ProductFormFeatureValue>`
`</ProductFormFeature>`

using Short tags
`<productformfeature>`
`<b334>32</b334>`	FSC-certified, mixed sources
`<b335>SGS-COC-002061</b335>`	Chain of Custody reference (Clays Ltd)
`</productformfeature>`
`<productformfeature>`
`<b334>36</b334>`	FSC-certified pre- and post-consumer waste
`<b335>35</b335>`	Percentage
`</productformfeature>`

specifying the accessibility features of a fixed-format e-book
using Reference names
`<ProductFormDetail>E101</ProductFormDetail>`
`<ProductFormDetail>E201</ProductFormDetail>`
`<ProductFormDetail>E210</ProductFormDetail>`
`<ProductFormDetail>E222</ProductFormDetail>`
`<ProductFormFeature>`
`<ProductFormFeatureType>15</ProductFormFeatureType>`
`<ProductFormFeatureValue>101A</ProductFormFeatureValue>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>09</ProductFormFeatureType>`
`<ProductFormFeatureValue>10</ProductFormFeatureValue>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>09</ProductFormFeatureType>`
`<ProductFormFeatureValue>11</ProductFormFeatureValue>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>09</ProductFormFeatureType>`
`<ProductFormFeatureValue>13</ProductFormFeatureValue>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>09</ProductFormFeatureType>`
`<ProductFormFeatureValue>15</ProductFormFeatureValue>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>09</ProductFormFeatureType>`
`<ProductFormFeatureValue>97</ProductFormFeatureValue>`
`<ProductFormFeatureDescription>Tested with Adobe Digital Editions 1.8 and JAWS screen reader on Windows, and with VoiceOver on Mac</ProductFormFeatureDescription>`
`</ProductFormFeature>`

using Short tags
`<b333>E101</b333>`	EPUB
`<b333>E201</b333>`	Fixed format
`<b333>E210</b333>`	optimized for landscape
`<b333>E222</b333>`	4:3 aspect ratio
`<productformfeature>`
`<b334>15</b334>`	e-publication version code
`<b335>101A</b335>`	EPUB 2.0.1
`</productformfeature>`
`<productformfeature>`
`<b334>09</b334>`	e-publication accessibility detail
`<b335>10</b335>`	No reading system options disabled
`</productformfeature>`
`<productformfeature>`
`<b334>09</b334>`
`<b335>11</b335>`	Navigation via table of contents
`</productformfeature>`
`<productformfeature>`
`<b334>09</b334>`
`<b335>13</b335>`	Single logical reading order
`</productformfeature>`
`<productformfeature>`
`<b334>09</b334>`
`<b335>15</b335>`	Full alternative text descriptions
`</productformfeature>`
`<productformfeature>`
`<b334>09</b334>`
`<b335>97</b335>`	Compatibility testing
`<b336>Tested with Adobe Digital Editions 1.8 and JAWS screen reader on Windows, and with VoiceOver on Mac</b336>`
`</productformfeature>`

specifying operating system and other technical requirements
using Reference names
`<ProductForm>DI</ProductForm>`
`<!-- <ProductFormDetail>D202</ProductFormDetail> -->`
`<ProductFormFeature>`
`<ProductFormFeatureType>06</ProductFormFeatureType>`
`<ProductFormFeatureValue>10</ProductFormFeatureValue>`
`<ProductFormFeatureDescription>Vista or Windows 7</ProductFormFeatureDescription>`
`</ProductFormFeature>`
`<ProductFormFeature>`
`<ProductFormFeatureType>07</ProductFormFeatureType>`
`<ProductFormFeatureDescription>Requires at least 2GB of memory, DirectX 9-compatible graphics</ProductFormFeatureDescription>`
`</ProductFormFeature>`

using Short tags
`<b012>DI</b012>`	DVD-Rom
`<!-- <b333>D202</b333> -->`	MS Windows
`<productformfeature>`
`<b334>06</b334>`	Operating system
`<b335>10</b335>`	MS Windows
`<b336>Vista or Windows 7</b336>`
`</productformfeature>`
`<productformfeature>`
`<b334>07</b334>`	Other system requirements
`<b336>Requires at least 2GB of memory, DirectX 9-compatible graphics</b336>`
`</productformfeature>`

Some operating systems can be specified in either <ProductFormFeature> or <ProductFormDetail> (as shown in the commented line above). <ProductFormFeature> is preferred wherever possible, as more specific version requirements may be included.

CPSIA choking hazard warning on boxed book plus toy
using Reference names
`<ProductForm>SB</ProductForm>`
`<ProductFormFeature>`
`<ProductFormFeatureType>12</ProductFormFeatureType>`
`<ProductFormFeatureValue>01</ProductFormFeatureValue>`
`</ProductFormFeature>`

using Short tags
`<b012>SB</b012>`	Boxed multiple-item retail product
`<productformfeature>`
`<b334>12</b334>`	CPSIA choke hazard warning
`<b335>01</b335>`	Small parts, not for children under 3
`</productformfeature>`

If the warning text in List 143 is not suitable, the exact text of a warning can be carried in <ProductFormFeatureDescription> (though <ProductFormFeatureValue> must not be omitted).

P.3.7 Product packaging type code

This should be used with any packaged product to specify the nature of any packaging – for example to describe whether a CD is packaged in a card sleeve, a jewel case, a Digipak, an Amaray-style keep case or some other form of packaging, or to describe a book or a collection of books in a slipcase, or a book plus an audio CD in a blister pack. The data element may be omitted if the product is not contained within any separate packaging.

: Common packaging types, and the codes used from List 80:

If a product has multiple levels of packaging – for example a slip-cased book that is also shrinkwrapped, use <ProductPackaging> to describe the primary packaging (in this case, it would be the slip-case), and add text in <ProductFormDescription> to describe any secondary packaging.

Note that the height, width and thickness (spine width) dimensions and weights in the <Measure> composite should include any packaging.

See P.3.2 Product form code for notes relating to the packaging of multi-item products and trade packs.

P.3.9 Trade category code

Although not necessarily a recommended best practice, the Trade category is important in some particular circumstances, as it is used, inter alia, to clarify the legal status of particular publications, which may affect their tax status.

specifying a livre scolaire
using Reference names
`<TradeCategory>08</TradeCategory>`

using Short tags
`<b384>08</b384>`	French livre scolaire, within the context of Decree 2004–922

P.3.10, P.3.11 Primary and Product content type codes

These elements are primarily intended to describe the type of content included within e-publications including e-books, mobile ‘apps’ and other downloadable or online products. For example, a simple e-book may contain just eye-readable text, and this would be specified using <PrimaryContentType> code 10.

‘Enhanced’ e-books or mobile apps that contain both book text and additional content not included in a related ‘unenhanced’ product should be described the same way, but the nature of the enhancements may be specified using a combination of the <PrimaryContentType> and <ProductContentType> elements – <ProductContentType> is repeatable for products that contain several types of additional content or enhancements. ‘Enhanced’ products may also carry the ENH code in <EditionType>. Note that an enhanced edition requires the existence of an ‘unenhanced’ edition – without the latter, the enhanced edition is simply the normal product and should not carry the <EditionType> code ENH. However, the use of additional repeats of <ProductContentType> does not depend on the existence of an ‘unenhanced’ version.

However, the use of these data elements is not limited to e-publications. They may also be used to differentiate between, say, audiobooks containing a single voice reading of a book, and multi-voice ‘dramatized’ audio. It may also be used with multi-item products, where for example product may contain both a book (with eye-readable text) and an audio version of the text, or with ‘multimedia’ educational software products. In general, if omitted from the Product record, the contents of the product should be assumed to be primarily textual.

Measure composite

The <Measure> composite should be included for all physical products.

The whole composite is repeatable, and at minimum, the height and width (across the front cover) dimensions should be provided for all physical products. This may be based on specifications provided in advance to the manufacturer (the printer and binder), or measured from the finished book-in-hand. Thickness (spine width) may not be known until production details such as the page extent and paper caliper are finalized, or until finished copies are available, and it may subsequently vary slightly between different impressions of the same product due to variations in the density and water content of the paper used. In a similar way, weight may not be known accurately until physical manufacture and is subject to equivalent variations. However, estimates of weight and spine width made prior to manufacture may still be useful to recipients and should be provided whenever possible: if weight and spine width measurements are provided greater than two months prior to publication, recipients should treat them as estimates, and senders should send updated data as soon as accurate measurements are available.

Never provide zero measurements: if a measurement is unknown, omit it.


: The primary linear measurement dimensions, and the codes used from List 48:

Product height, width, thickness (spine width) and weight measurements should include any retail packaging – for a retailer, if a book is sold in a slipcase or box, then it is the dimensions of the slipcase or box that determine whether or not it can be conveniently shelved or shipped. This is doubly important for multi-item products. (Packaging expected to be discarded before retail should not be included.)

For broad international use outside USA, metric units should be used for linear dimensions (millimetres) and weight (grams). For products sold only in USA, Imperial units (inches, ounces) should be used instead. If a product is sold in both USA and elsewhere (for example, globally, or simply in both USA and Canada), inclusion of the same dimensions in both metric and Imperial is clearly the best option, but if only one set of dimensions can be provided, metric is preferred over Imperial. Note that if a book is manufactured to a particular nominal size, there is a certain commercially-acceptable tolerance and the exact size of the finished copies may vary a little: typically, linear measurements should not be specified more precisely than the nearest 1mm or ⅛in. Recipients should treat linear measurements as having an expected accuracy within ±2mm or ±⅛in, and weights with an accuracy of ±5gr or ±¼oz. Similarly, whenever unit conversions are necessary, the results should be rounded sensitively to avoid misleadingly precise measurements (eg conversion of 197mm to Imperial units indicates a size of 7.756in, but round to 7¾ (ie to 7.75) inches).

For hardbacks, note that the overall width and height are not the same as the trimmed page size (trimmed leaf size), as the cover boards overhang the book block. Trimmed leaf size may be provided in separate repeats of the <Measure> composite.

For products such as maps, both folded (or rolled) and flat measurements should be included whenever possible, but if only one set of dimensions can be included, the folded (or rolled) sizes used at retail are preferred.

For multi-item products – both those that are retailed as such (<ProductComposition> code 10–11 and <ProductForm> codes SA–SF), and those that are split before retail (<ProductComposition> code 30 and <ProductForm> codes XA, XC, XE, XL) – measurements should relate to the full multi-item product. For those products that are split before retail, the measurements of a single item must be obtained from the Product record for the individual product.

P.3.15 Country of manufacture

This information is required in some countries to meet legal requirements, so it is best practice to include it for all physical products available internationally. For a physical book, the country of manufacture is the country where it is printed and bound, not the country in which the publisher is based (though of course they may be the same).

If the product is a multi-item product, the country of manufacture should instead be specified individually for each of the physical components in the product, in P.4, especially if different items are manufactured in different countries or if the items in a multi-item trade pack are intended to be retailed individually. For a multi-item product or pack, a pack-level country of manufacture could be interpreted as the country in which the items were packaged together, rather than where they were each manufactured.

P.3.16 Digital product technical protection

This element should be used to specify any technical protection measures applied to the product, and should be used for all downloadable and (where appropriate) other digital products – including the case when no technical protection is applied.

: <EpubTechnicalProtection> is not relevant solely to e-books in EPUB format. The ‘Epub’ is simply a contraction of ‘e-publication’, and elements so named are relevant to all types of e-publication.

Some types of e-publication are defined by their unique combination of file format (eg .epub or .xps, specified in <ProductFormDetail>) and type of technical protection (eg Apple or Adobe DRM). For these products, specification of the technical protection type is clearly vital.

Note that technical protection need not necessarily be used for enforcement. Customer-specific ‘watermarking’ (which normally identifies the purchase transaction, rather than the actual person) or other ‘social DRM’ may be applied to digital files at the moment of sale, so that individual digital copies of a product may be linked with a purchaser, without this being associated with any enforcement measures embodied in the product itself.

: It is common with e-publications to question whether the <EpubTechnicalProtection> element and the <UsageConstraint> composite describe the file the publisher supplies to the retailer (or retail platform), or the file the retailer sends to the end customer. It is the latter. So in a common case where the publisher-supplied file does not have DRM, and the retail platform adds the DRM wrapper before delivery to the end customer, the ONIX Product record should indicate the product is DRM-protected.

Usage constraint composite

The <EpubUsageConstraint> composite should be used to specify the license terms which apply to a digital product, whether or not these terms are enforced by any technical protection measures. Multiple repeats of the composite should be included to give a clear picture of what a purchaser may and may not do (legitimately) with the content of the product.

Note that there are no default usage rights or constraints: if no usage constraints are specified in the Product record, it means only that there is no information, and does not imply an unconstrained usage right. Data providers should aim to specify at least those usages and constraints that vary between products on the ‘retail platform’ the product will be sold through.

One unusual feature of many e-publications is that the range of possible uses or potential constraints may change post-publication, as the technical capabilities of the reading platform may be modified through software upgrades. For example, the addition of text-to-speech or temporary lending to a platform may affect prior purchases on that platform. But there needs to be a clear understanding of whether any capability or constraint is associated with the reading platform or the product. Where these new capabilities are ‘optional’, and controllable at a per-product level, they should be specified in an ONIX (update) message, whether the publisher of the product chooses to opt in or opt out of enabling the new feature. Where these capabilities are added to all products on that platform, without any ‘opt-out’ or per-product control, then no change to ONIX metadata is required: the new capability is a reading platform feature, rather than an attribute of the product.

Similarly, capabilities and constraints may in some cases be somewhat platform-specific, even for a single product usable with multiple reading platforms. Where the same product is usable on multiple reading platforms, a constraint that is wholly related to the platforms should not be listed. For example, for a single product that is usable with two e-book reading platforms, where text-to-speech is enabled for all products without exception on one platform, but is completely unavailable on the other – perhaps because that platform lacks audio output of any kind – text-to-speech should not be included in the list of constraints.

Library-lendable e-book
using Reference names: the book can be loaned out up to 52 times, only one borrower can be loaned the book at any one time, for a maximum of a fortnight. Printing is prohibited, text-to-speech is allowed, and these constraints are protected by DRM
`<EpubTechnicalProtection>01</EpubTechnicalProtection>`
`<EpubUsageConstraint>`
`<EpubUsageType>02</EpubUsageType>`
`<EpubUsageStatus>03</EpubUsageStatus>`
`</EpubUsageConstraint>`
`<EpubUsageConstraint>`
`<EpubUsageType>05</EpubUsageType>`
`<EpubUsageStatus>01</EpubUsageStatus>`
`</EpubUsageConstraint>`
`<EpubUsageConstraint>`
`<EpubUsageType>06</EpubUsageType>`
`<EpubUsageStatus>02</EpubUsageStatus>`
`<EpubUsageLimit>`
`<Quantity>52</Quantity>`
`<EpubUsageUnit>10</EpubUsageUnit>`
`</EpubUsageLimit>`
`<EpubUsageLimit>`
`<Quantity>14</Quantity>`
`<EpubUsageUnit>09</EpubUsageUnit>`
`</EpubUsageLimit>`
`<EpubUsageLimit>`
`<Quantity>1</Quantity>`
`<EpubUsageUnit>07</EpubUsageUnit>`
`</EpubUsageLimit>`
`</EpubUsageConstraint>`

using Short tags: the book can be loaned out up to 52 times, but with unlimited concurrency (ie 52 sequential loans stretching over two years or more, or 52 ‘parallel’ loans over two weeks). Printing is prohibited, text-to-speech is allowed, and DRM enforces these limitations
`<x317>01</x317>`	DRM-protected
`<epubusageconstraint>`
`<x318>02</x318>`	Printing
`<x319>03</x319>`	Is prohibited
`</epubusageconstraint>`
`<epubusageconstraint>`
`<x318>05</x318>`	Text-to-speech
`<x319>01</x319>`	Is unrestricted
`</epubusageconstraint>`
`<epubusageconstraint>`
`<x318>06</x318>`	Lending
`<x319>02</x319>`	Is limited
`<epubusagelimit>`
`<x320>52</x320>`	Up to 52
`<x321>10</x321>`	Occasions
`</epubusagelimit>`
`<epubusagelimit>`
`<x320>14</x320>`	For fourteen
`<x321>09</x321>`	Days
`</epubusagelimit>`
`<epubusagelimit>`
`<x320>0</x320>`	Unlimited
`<x321>07</x321>`	Concurrent users
`</epubusagelimit>`
`</epubusageconstraint>`

Zero concurrent users is a special case indicating there is no limit on the number of concurrent users. A maximum of 52 concurrent users would have the same meaning in this particular case. If the number of concurrent users is not specified, there can be only one concurrent user.

e-book purchase
using Reference names: the product is an e-book ‘purchase’ – in reality, the purchase of a perpetual license to the product. The product is watermarked
`<EpubTechnicalProtection>02</EpubTechnicalProtection>`
`<EpubUsageConstraint>`
`<EpubUsageType>07</EpubUsageType>`
`<EpubUsageStatus>01</EpubUsageStatus>`
`</EpubUsageConstraint>`

using Short tags: perpetual license
`<x317>02</x317>`	Watermarked
`<epubusageconstraint>`
`<x318>07</x318>`	Time limit
`<x319>01</x319>`	Is unrestricted
`</epubusageconstraint>`

e-book rental – 30-day time-limited license to the product, enforced by DRM
using Reference names
`<EpubTechnicalProtection>03</EpubTechnicalProtection>`
`<EpubUsageConstraint>`
`<EpubUsageType>07</EpubUsageType>`
`<EpubUsageStatus>02</EpubUsageStatus>`
`<EpubUsageLimit>`
`<Quantity>30</Quantity>`
`<EpubUsageUnit>09</EpubUsageUnit>`
`</EpubUsageLimit>`
`</EpubUsageConstraint>`

using Short tags
`<x317>03</x317>`	Adobe Content Server DRM
`<epubusageconstraint>`
`<x318>07</x318>`	Time limit
`<x319>02</x319>`	Is restricted
`<epubusagelimit>`
`<x320>30</x320>`
`<x321>09</x321>`	To 30 days
`</epubusagelimit>`
`</epubusageconstraint>`

Differentiating rentals from purchases in this way relies on using separate product identifiers for each. If only a single identifier is used for purchase and one or more rental periods, see <PriceCondition>.

Digital product license composite

This composite can be used to deliver details of the license terms for a digital product. The license must have a name or title, and if the license is available on the internet, a link to the actual license may be provided (there may be several links to different expressions of the same license – for example a link to a legal document and a separate link to a summary intended for consumers).

Links to machine-readable license expressions – for example using ONIX-PL – are likely to become valuable in the future, particularly in library contexts.

Open Access e-book available under a CC-By license
using Reference names
`<EpubLicense>`
`<EpubLicenseName>Creative Commons Attribution 4.0 International Public License</EpubLicenseName>`
`<EpubLicenseExpression>`
`<EpubLicenseExpressionType>02</EpubLicenseExpressionType>`
`<EpubLicenseExpressionLink>http://creativecommons.org/licenses/by/4.0/legalcode</EpubLicenseExpressionLink>`
`</EpubLicenseExpression>`
`</EpubLicense>`
`. . .`
`<TextContent>`
`<TextType>20</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text>Open access under CC-By license</Text>`
`</TextContent>`
`. . .`
`<Publisher>`
`<PublishingRole>01<PublishingRole>`
`<PublisherName>Manchester University Press</PublisherName>`
`</Publisher>`
`<Publisher>`
`<PublishingRole>14<PublishingRole>`
`<PublisherName>Knowledge Unlatched</PublisherName>`
`</Publisher>`
`<Publisher>`
`<PublishingRole>15<PublishingRole>`
`<PublisherIdentifier>`
`<PublisherIDType>32</PublisherIDType>`
`<IDValue>10.13039/100004440</IDValue>`
`</PublisherIdentifier>`
`<PublisherName>Wellcome Trust</PublisherName>`
`</Publisher>`
`. . .`
`<Website>`
`<WebsiteRole>29</WebsiteRole>`
`<WebsiteDescription>OAPEN Repository</WebsiteDescription>`
`<WebsiteLink>http://www.oapen.org/download?type=document&docid=341341</WebsiteLink>`
`</Website>`
`. . .`
`<UnpricedItemType>01</UnpricedItemType>`

using Short tags – with links to both human-readable and professional license expressions
`<epublicense>`
`<x511>Creative Commons Attribution 4.0 International Public License</x511>`
`<epublicenseexpression>`
`<x508>01</x508>`	Human readable
`<x510>http://creativecommons.org/licenses/by/4.0/deed</x510>`
`</epublicenseexpression>`
`<epublicenseexpression>`
`<x508>02</x508>`	‘Professional’ readable
`<x510>http://creativecommons.org/licenses/by/4.0/legalcode</x510>`
`</epublicenseexpression>`
`</epublicense>`
`. . .`
`<textcontent>`
`<x426>20</x426>`	Open access statement
`<x427>00</x427>`
`<d104>Open access under CC-By license</d104>`
`</textcontent>`
`. . .`
`<publisher>`
`<b291>01<b291>`	Publisher
`<b081>Manchester University Press</b081>`
`</publisher>`
`<publisher>`
`<b291>14<b291>`	Publication funder
`<b081>Knowledge Unlatched</b081>`
`</publisher>`
`<publisher>`
`<b291>15<b291>`	Research funder
`<publisheridentifier>`
`<x447>32</x447>`	FundRef DOI
`<b244>10.13039/100004440</b244>`
`</publisheridentifier>`
`<b081>Wellcome Trust</b081>`
`</publisher>`
`. . .`
`<website>`
`<b367>29</b367>`	Full content available from
`<b294>OAPEN Repository</b294>`
`<b295>http://www.oapen.org/download?type=document&docid=341341</b295>`
`</website>`
`. . .`
`<j192>01</j192>`	Free of charge

The <EpubLicense> composite is not applicable only to Creative Commons and proprietary ‘open access’ licenses – it may also be used for commercial and limited licenses as well. However, for open access and other free at the point of use digital products only, an ‘open access statement’ should always be provided in Group P.14 (use <TextType> code 20). Presence of this statement acts as a ‘flag’ to indicate the product is open access, and the statement text can be displayed as a one line summary of the license terms. For limited and commercial licenses, there should be no open access statement. Open access materials would normally also name the funder(s) in the <Publisher> composite, and are likely to be free of charge (denoted using <UnpricedItemType>). They may also specify a location from which the digital product can be downloaded. The <Website> composite might link to a repository managed by the author, funder, publisher, supplier or another party, and the composite should be used in the appropriate context.

P.3.21 Map scale

The main scale of a cartographic product should always be provided. If the map contains multiple panels at different scales, repeats of the <MapScale> element may be used to express the scales used in the significant panels – for example the Product record for a road map with inset city center street maps might include two <MapScale> elements.

When a cartographic product such as an atlas is comprised of maps at just one or a small number of scales, the same approach should be followed. If the maps in an atlas are drawn at a wide variety of scales, it is not useful to specify them all individually: specify only the two or three scales used most widely in the product.

Product classification composite

The <ProductClassification> composite can be used in international trading to indicate the customs or tax status of the product, most often using the World Customs Organization’s ‘Harmonized system’ of product classification, or one of its regional or national variations or extensions. This can be critical in international trading, and where prices are typically communicated exc-tax, the recipient of the ONIX data can usually decide the local tax rate or any tariffs that are applicable to the product based on the commodity code.

Product classification for an atlas
using Reference names
`<ProductClassification>`
`<ProductClassificationType>10</ProductClassificationType>`
`<ProductClassificationCode>49059100</ProductClassificationCode>`
`</ProductClassification>`

using Short tags
`<productclassification>`
`<b274>10</b274>`	Mercosul NCM commodity code
`<b275>49059100</b275>`	for an atlas
`</productclassification>`

Product classification for a multi-component product
using Reference names
`<ProductClassification>`
`<ProductClassificationType>01</ProductClassificationType>`
`<ProductClassificationCode>490199</ProductClassificationCode>`
`<Percent>75</Percent>`
`</ProductClassification>`
`<ProductClassification>`
`<ProductClassificationType>01</ProductClassificationType>`
`<ProductClassificationCode>852432</ProductClassificationCode>`
`<Percent>25</Percent>`
`</ProductClassification>`

using Short tags
`<productclassification>`
`<b274>01</b274>`	WCO Harmonized system
`<b275>490199</b275>`	Book / other
`<b337>75</b337>`	75% of value
`</productclassification>`
`<productclassification>`
`<b274>01</b274>`	WCO Harmonized system
`<b275>852432</b275>`	Recorded media for sound
`<b337>25</b337>`	25% of value
`</productclassification>`

Most product classification types are expressed with periods separating the number into fields (eg 4901.99.00 in the first example above). The period characters are not usually included in the ONIX data.

The value percentage is a percentage of the overall price excluding tax. Tax may then have to be added based on the product classification itself.

Note that for multi-component products using <ProductPart>, the Product classification has to be described in P.3, not within each <ProductPart>. If the product consists of components that have different classifications – for example a children’s picture book bundled with an audio CD – then the <ProductClassification> composite is repeated, and the <Percent> element can be used to carry the percentage of the value of the product represented by each component.

P.4 Product parts

If the Product record describes a multi-item or multi-component product, then multiple repeats of the <ProductPart> composite are used to identify and describe the form of the various components of the product. As a result, much of the structure of the composite is identical to P.3, and similar best practices apply. Use of <ProductPart> implies nothing about whether each individual part or component within the product is available separately, and it may be used whether the various parts are of similar or different Product form.

If the Product record describes a single-item, single-component product, then <ProductPart> should be omitted entirely.

Product part composite

The <ProductPart> composite:

should be used if <ProductComposition> indicates the product is a multi-item product (ie with codes 10, 11, 30, 31 from List 2). <ProductPart> should not be included in records with other <ProductComposition> code values;
should include the <PrimaryPart/> flag to indicate whenever one specific part is deemed the most important of the several items in the product;
should use the <ProductIdentifier> composite to provide separate identifiers for each item in the product, whenever such identifiers exist. This is vital where those items are also available as single-item products. Where separate identifiers are not available, parts may be described in groups of similar Product form;
must specify a <ProductForm> for each item (or group of items) in the product;
should include any relevant <ProductFormDetail> and (where it conveys an important item attribute) <ProductFormFeature> information;
must use either <NumberOfItemsOfThisForm> or <NumberOfCopies> to specify the number of items in the multi-item product;
should include the country of manufacture for each item within the product, unless it is supplied for the product as a whole in P.3.

<ProductPart> specifies a relationship between a product and a component of that product that might otherwise – if the component is also for sale separately – be included in <RelatedProduct> in Block 5 using <ProductRelationCode> 02 (product includes related product). It is good practice to include identifiers for the individual saleable parts within multi-item products in <ProductPart>, and not to repeat them in <RelatedProduct>. ONIX recipients wishing to identify related products should use identifiers from <ProductPart> alongside those listed in Group P.23.

three-volume work, paperback, in box (not a slip-case), individual parts not identified separately
using Reference names
`<ProductComposition>10</ProductComposition>`
`<ProductForm>SA</ProductForm>`
`<ProductPackaging>09</ProductPackaging>`
`<!-- <Measure> omitted for brevity -->`
`<CountryOfManufacture>DE</CountryOfManufacture>`
`<ProductPart>`
`<!-- volumes not individually identified -->`
`<ProductForm>BC</ProductForm>`
`<ProductFormDetail>B102</ProductFormDetail>`
`<NumberOfItemsOfThisForm>3</NumberOfItemsOfThisForm>`
`</ProductPart>`

using Short tags
`<x314>10</x314>`	Multi-item product
`<b012>SA</b012>`	Packaging unspecified
`<b225>09</b225>`	In box (not slipcase)
`<!-- <measure> omitted for brevity -->`
`<x316>DE</x316>`	Made in Germany
`<productpart>`
`<!-- volumes not individually identified -->`
`<b012>BC</b012>`	Paperback
`<b333>B102</b333>`	Trade paperback (US usage)
`<x322>3</x322>`	Three vols
`</productpart>`

trade-only pack of 8 copies each of two different hardback books, to be retailed as 16 individual items
using Reference names
`<ProductComposition>30</ProductComposition>`
`<ProductForm>XL</ProductForm>`
`<!-- <Measure> omitted for brevity -->`
`<ProductPart>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductForm>BB</ProductForm>`
`<NumberOfCopies>8</NumberOfCopies>`
`<CountryOfManufacture>IT</CountryOfManufacture>`
`</ProductPart>`
`<ProductPart>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780001234584</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780001234584</IDValue>`
`</ProductIdentifier>`
`<ProductForm>BB</ProductForm>`
`<NumberOfCopies>8</NumberOfCopies>`
`<CountryOfManufacture>IT</CountryOfManufacture>`
`</ProductPart>`

using Short tags
`<x314>30</x314>`	Multiple-item trade pack
`<b012>XL</b012>`	Shrink-wrapped pack
`<!-- <measure> omitted -->`
`<productpart>`
`<productidentifier>`
`<b221>03</b221>`	GTIN-13
`<b244>9780001234567</b244>`	(of book A)
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780001234567</b244>`
`</productidentifier>`
`<b012>BB</b012>`	Hardback
`<x323>8</x323>`	Eight copies
`<x316>IT</x316>`
`</productpart>`
`<productpart>`
`<productidentifier>`
`<b221>03</b221>`
`<b244>9780001234584</b244>`	GTIN-13
`</productidentifier>`	(of book B)
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780001234584</b244>`
`</productidentifier>`
`<b012>BB</b012>`	Hardback
`<x323>8</x323>`	Eight copies
`<x316>IT</x316>`	Printed in Italy
`</productpart>`

softback book with two-disc audiobook in sleeve attached to inside back cover (the audio version is not available as a separate product)
using Reference names
`<ProductComposition>10</ProductComposition>`
`<ProductForm>SF</ProductForm>`
`<!-- <Measure> omitted for brevity -->`
`<ProductPart>`
`<PrimaryPart/>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`<ProductForm>BC</ProductForm>`
`<NumberOfCopies>1</NumberOfCopies>`
`<CountryOfManufacture>ES</CountryOfManufacture>`
`</ProductPart>`
`<ProductPart>`
`<!-- no separate identifier available -->`
`<ProductForm>AC</ProductForm>`
`<ProductFormDetail>A101</ProductFormDetail>`
`<NumberOfItemsOfThisForm>2</NumberOfItemsOfThisForm>`
`<CountryOfManufacture>AT</CountryOfManufacture>`
`</ProductPart>`

using Short tags
`<x313>10</x313>`	Multi-item retail product
`<b012>SF</b012>`	Part(s) enclosed within largest item
`<!-- <measure> omitted -->`
`<productpart>`
`<x457/>`	Book is primary part
`<productidentifier>`
`<b221>03</b221>`	GTIN-13
`<b244>9780001234567</b244>`	(of book as single product)
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780001234567</b244>`
`</productidentifier>`
`<b012>BC</b012>`	Paperback
`<x323>1</x323>`	One book
`<x316>ES</x316>`	Printed in Spain
`</productpart>`
`<productpart>`
`<!-- no separate identifier available -->`
`<b012>AC</b012>`	CD-Audio
`<b333>A101</b333>`	‘Red Book’ audio format
`<x322>2</x322>`	Two discs
`<x316>AT</x316>`	Pressed in Austria
`</productpart>`

The <Measure> composite cannot be included inside <ProductPart> (although some size information may be included within <ProductFormDetail>). The exact physical size of each item in a multi-item product or (more relevantly) in a trade-only pack must be expressed in separate ONIX records for the individual items.

The use of <ProductPart> is required whenever <ProductComposition> indicates a multi-item product. But for some legacy systems, it may not be possible to provide full details of each component within the product. What is the minimum amount of component information that can be supplied?

Within <ProductPart>, only the <ProductForm> element plus one of <NumberOfItemsOfThisForm> or <NumberOfCopies> are mandatory. So the absolute minimum information required is – in effect – the number of components there are:

using Reference names
`<ProductPart>`
`<ProductForm>BA</ProductForm>`
`<NumberOfItemsOfThisForm>3</NumberOfItemsOfThisForm>`
`</ProductPart>`

using Short tags
`<productpart>`
`<b012>BA</b012>`	Book – detail unspecified
`<x322>3</x322>`
`</productpart>`

In this case, the only information about the components is that there are three different components, and that they are books (it is not stated whether they are hardcovers or paperbacks). Three identical components would use <NumberOfCopies> instead.

Providing such minimal information about multi-component products is obviously poor practice, and enhancing the data so it at least clearly specifies the product form of the components should be a priority.

P.4.1 ‘Primary part’ indicator

This should only be used with multi-item retail products (<ProductComposition> code 10), and when one item within that multi-item product can be considered the primary part. Omission implies that all parts are of similar importance.

Product identifier composite (product part)

It is recommended that the <ProductIdentifier> composite is used for any item within a multiple-item product that carries any kind of separate identifier, even if that identifier cannot be used for separate ordering of a single item from within the multi-item product. For example, the individual volumes within a boxed set may or may not be available individually, but in either case may have individual ISBNs.

See Product identifier composite within P.2 for best practice guidance.

P.4.5 Product form code (product part)

The <ProductForm> element is mandatory within each repeat of the <ProductPart> composite.

P.4.6 Product form detail (product part)

See P.3.3 Product form detail for best practice guidance.

Product form feature composite (product part)

See Product form feature composite within Group P.3 for best practice guidance.

Note that product form features such as safety warnings should normally be described at product level, even if they apply to only one part of a multi-item product. Safety warnings should only be carried within Group P.4 for multi-item trade packs that are intended to be broken into individual products before retail.

P.4.12, P.4.13 Number of items or copies

Either <NumberOfItemsOfThisForm> or <NumberOfCopies> should be included in every <ProductPart> composite:

<NumberOfCopies should be used when a <ProductPart> composite is describing a particular item within a multi-item product (there may be one or several copies of that particular item within the multi-item product). There would normally be a <ProductIdentifier> composite within the <ProductPart> composite;
<NumberOfItemsOfThisForm> should be used only when a single <ProductPart> composite is used to describe several different – but undifferentiated – items of identical Product form included within a multi-item product. The most common use case would be in describing a product such as a boxed set comprised of several volumes which are not themselves available individually. Note that if they were available separately, they would each have product identifiers, and so in describing the boxed set, separate <ProductPart> composites for each volume (and each of those with <NumberOfCopies> set to 1) would be more appropriate.

P.4.14 Country of manufacture (product part)

See P.3.15 Country of manufacture for best practice guidance.

P.5 Collection

Group P.5 consists of the <Collection> composite and the <NoCollection/> flag. The <Collection> composite may be used to carry details of any ‘bibliographic collection’ to which a product belongs – a collection might formally be termed a ‘set’ or a ‘series’, or might be a more informal grouping of related products. Alternatively, similar bibliographic collection details may be carried in Group P.6.

Collections can be prescribed by the publisher, or ascribed to a range of independent products by a party other than the publisher – for example by a wholesaler or data aggregator. In the former case, details of the collection will usually appear formally on the product’s title page, whereas the latter may be an ad hoc grouping of products created for marketing or merchandising reasons.

Members of a collection share a collective identity, including at least a common collection title, and may share other attributes. For example, each product in a collection might have the same contributors, and collections usually have a consistent physical form, size and design style. Each member of a collection also has a unique identity – the ‘unshared’ title text. A collection may have an identifier for the collection as a whole, and the whole collection may be available as a single product, or as many individual products – ONIX makes no distinction. It is possible – though relatively rare – for a single product to be included in more than one collection, in which case multiple <Collection> composites may be used.

Collection identifiers and the shared identity of ascribed collections are always carried in P.5. A prescribed collection’s shared identity might be carried in either of Groups P.5 or P.6. Choosing between P.5 or P.6 can be tricky:

the collective identity – the shared parts of the title – are the ‘collection-level title details’;
- where one collection is nested inside another, larger collection, these may be arranged hierarchically, in collection, sub-collection, sub-sub-collection fashion;
- collections sit logically ‘within’ imprints (see Group P.19), rather than spanning imprints;
the unique, unshared parts of the title are the ‘product-level title details’;
if the product-level title is sufficiently distinct on its own, then the collection-level title is carried in Group P.5, and the product-level title in P.6;
if the product-level title always needs to be qualified with the collection-level title to provide context, because it is not distinctive enough on its own, then both collection- and product-level titles should be carried in Group P.6;
a collection-level title should never appear in both P.5 and P.6.

As an illustration, if a product-level title is ‘Workbook 6’, then it makes little sense without the collection-level title ‘Focus on Mathematics’ that expresses which student course Workbook 6 is a part of – there may be a ‘Workbook 6’ in ‘Focus on Physics’ too. In this case, both collection- and product-level titles should be in Group P.6. If the title is ‘The Beautiful and Damned’, then that is sufficiently distinctive on its own, and any collection title (such as ‘Penguin Modern Classics’) should be carried in Group P.5:

The Beautiful and the Damned (illustrating the structure of collection- and product-level title elements only)
`<!-- Group P.5 -->`
`<Collection>`
`<TitleDetail>`
`<-- collection-level title element = Penguin Modern Classics -->`
`</TitleDetail>`
`</Collection>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<-- product-level title element = The Beautiful and the Damned -->`
`</TitleDetail>`

Focus on Mathematics – Workbook 6
`<!-- Group P.6 -->`
`<TitleDetail>`
`<-- collection-level title element = Focus on Mathematics -->`
`<-- product-level title element = Workbook 6 -->`
`</TitleDetail>`

Choosing to use the second method does not necessarily mean there is no <Collection> composite – it may still be present, if for example it contains a collection identifier or collection sequence composite.

A recipient of the data is expected to display details from P.6 as ‘the title’, and this may include collection-level title detail. Other collection-level title information from P.5 should also be displayed, but is logically separate.

Where the products within a collection have a particular enumeration or sequence indicated on the product itself and considered to be part of the title, the <PartNumber> data element (or perhaps the <YearOfAnnual> element) should be used. However, this is not part of the collective identity: it is product-level data. Thus while typically a part or volume number will appear in the same Group as the collection-level title (either P.5 or P.6, depending on whether the product-level title always needs to be qualified with the collection-level information), it appears in a separate repeat of <TitleElement> with a different (ie a product-level) Title element level.

In contrast, where products within a collection have a particular sequence that is not indicated on the product (or occasionally, is indicated but is not considered to be part of the title), the <CollectionSequence> composite should be used.

And in some circumstances, it is useful to include <CollectionSequence> in addition to <PartNumber> – for example if the Part number is in Roman numerals or words. Supplying a numeric collection sequence number make such collections much simpler to sort into order.

The <NoCollection/> empty element indicates that the product does not belong to any type of collection (ie it indicates that there are no collection details in either P.5 or P.6). <NoCollection/> does not simply indicate there is no <Collection> composite – so it’s entirely possible to have no P.5 content at all in an ONIX Product record. It is also possible that a collection identifier or collection sequence number be included in P.5, even when the collection title is supplied in P.6.

Additional guidance and extensive examples on the description of collections are included in a separate document ONIX for Books: Product Information Format: How to describe sets, series and multiple-item products.

A <Collection> composite:

should be used to describe the collective identity a product shares with other products in a collection, except when that collective identity is fully described in P.6;
must include a <CollectionType> to indicate whether the collection is prescribed or ascribed;
should include any relevant collection identifiers (such as an ISSN or a series identifier issued by a national library) in one or more <CollectionIdentifier> composites;
ordered collections should include the <CollectionSequence> composite, to specify the ordinal position of the product within the collection, particularly where the ordinal position is not trivially discernible from the title elements (eg where the <PartNumber> includes words, roman numerals, or where the product is part of a subcollection);
should include any shared titles for the collection in one or more <TitleDetail> composites, unless they are included in P.6.

A <NoCollection/> flag should be included in records that contain neither a <Collection> composite nor any collection description in P.6.

Any product in a collection should also make use of repeated <RelatedProduct> composites in Group P.23 to link to other products in the collection using <ProductRelationCode> code 30. In addition, if the collection is available as a single product (eg a boxed set), the individual product can link to the set product using relation code 02 (‘is part of’) (and in reverse, the set product can link to the individual product using relation code 01).

product that is part of an unordered collection
using Reference names
`<Collection>`
`<CollectionType>10</CollectionType>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>02</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix textcase="02">Oxford World’s Classics</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`</Collection>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<TitlePrefix textcase="02">The</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">Lost World</TitleWithoutPrefix>`
`<Subtitle textcase="01">Being an account of the recent amazing adventures of Professor George E. Challenger, Lord John Roxton, Professor Summerlee, and Mr E. D. Malone of the Daily Gazette</Subtitle>`
`</TitleElement>`
`<TitleDetail>`

using Short tags
`<collection>`
`<x329>10</x329>`	Publisher’s collection
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>02</x409>`	Collection level
`<x501/>`
`<b031 textcase="02">Oxford World’s Classics</b031>`
`</titleelement>`
`</titledetail>`
`</collection>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`
`<titleelement>`	Distinctive title
`<x409>01</x409>`	Product level
`<b030 textcase="02">The</b030>`
`<b031 textcase="02">Lost World</b031>`
`<b029 textcase="01">Being an account of the recent amazing adventures of Professor George E. Challenger, Lord John Roxton, Professor Summerlee, and Mr E. D. Malone of the Daily Gazette</b029>`
`</titleelement>`
`<titledetail>`

product that is part of an ordered collection. Le jour du soleil is the first book in the XIII series
using Reference names
`<Collection>`
`<CollectionType>10</CollectionType>`
`<CollectionSequence>`
`<CollectionSequenceType>02</CollectionSequenceType>`
`<CollectionSequenceNumber>1</CollectionSequenceNumber>`
`</CollectionSequence>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>02</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix textcase="01">XIII</TitleWithoutPrefix>`
`</TitleElement>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<PartNumber>Tome 1</PartNumber>`
`</TitleElement>`
`</TitleDetail>`
`</Collection>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<TitlePrefix textcase="01">Le</TitlePrefix>`
`<TitleWithoutPrefix textcase="01">jour du soleil</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`

using Short tags
`<collection>`
`<x329>10</x329>`
`<collectionsequence>`
`<x479>02</x479>`	Title order (confirmation)
`<x481>1</x481>`
`</collectionsequence>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>02</x409>`	Collection level
`<x501/>`
`<b031 textcase="01">XIII</b031>`
`</titleelement>`
`<titleelement>`
`<x409>01</x409>`	Product level
`<x410>Tome 1</x410>`	First item in collection
`</titleelement>`
`</titledetail>`
`</collection>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>01</x409>`	Product level
`<b030 textcase="01">Le</b030>`
`<b031 textcase="01">jour du soleil</b031>`
`</titleelement>`
`</titledetail>`

Note that the collection title XXXI is carried as a title (in <TitleWithoutPrefix>) even though it superficially resembles a part number.

The part number itself (Tome 1) is product-level attribute, not a part of the collective identity, so it occurs with a <TitleElementLevel> code 01, but it occurs within P.5, because the product level title in P.6 is distinctive enough without it.

product is part of a nested subcollection. The History of Greek Philosophy is in several volumes, of which The Fifth Century Enlightenment is the third. This third volume comes in two Parts, of which this product is the second
using Reference names
`<Collection>`
`<CollectionType>10</CollectionType>`
`<CollectionSequence>`
`<CollectionSequenceType>02</CollectionSequenceType>`
`<CollectionSequenceNumber>3.2</CollectionSequenceNumber>`
`</CollectionSequence>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>02</TitleElementLevel>`
`<TitlePrefix textcase="02">A</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">History of Greek Philosophy</TitleWithoutPrefix>`
`</TitleElement>`
`<TitleElement>`
`<TitleElementLevel>03</TitleElementLevel>`
`<PartNumber>Volume 3</PartNumber>`
`<TitlePrefix textcase="02">The</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">Fifth Century Enlightenment</TitleWithoutPrefix>`
`</TitleElement>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<PartNumber>Part 2</PartNumber>`
`</TitleElement>`
`</TitleDetail>`
`</Collection>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix>Socrates</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`

using Short tags
`<collection>`
`<x329>10</x329>`	Publisher collection
`<collectionsequence>`
`<x479>02</x479>`	Title order (confirmation)
`<x481>3.2</x481>`	Two-level numbering
`</collectionsequence>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>02</x409>`	Collection level
`<b030 textcase="02">A</b030>`
`<b031 textcase="02">History of Greek Philosophy</b031>`
`</titleelement>`
`<titleelement>`
`<x409>03</x409>`	Subcollection level
`<x410>Volume 3</x410>`
`<b030 textcase="02">The</b030>`
`<b031 textcase="02">Fifth Century Enlightenment</b031>`
`</titleelement>`
`<titleelement>`
`<x409>01</x409>`	Product level
`<x410>Part 2</x410>`
`</titleelement>`
`</titledetail>`
`</collection>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>01</x409>`	Product level
`<x501/>`
`<b031>Socrates</b031>`
`</titleelement>`
`</titledetail>`

It is certainly possible to argue that the collection and subcollection details in the example above should be presented in Group P.6: in cases like this, the choice between P.5 and P.6 is not clear cut.

collection identifier only in Group P.5, collection title supplied in Group P.6
using Reference names
`<Collection>`
`<CollectionType>10</CollectionType`
`<CollectionIdentifier>`
`<CollectionIDType>02</CollectionIDType>`
`<IDValue>00173231</IDValue>`
`</CollectionIdentifier>`
`</Collection>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>02</TitleElementLevel>`
`<TitleText textcase="02">Granta</TitleText>`
`<Subtitle textcase="01">The magazine of new writing</Subtitle>`
`</TitleElement>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<PartNumber>109</PartNumber>`
`<TitleText textcase="02">Work</TitleText>`
`</TitleElement>`
`</TitleDetail>`

using Short tags
`<collection>`
`<x329>10</x329`	Publisher collection
`<collectionidentifier>`
`<x344>02</x344>`	ISSN
`<b244>00173231</b244>`
`</collectionidentifier>`
`</collection>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>02</x409>`	Collection level
`<b203 textcase="01">Granta</b203>`	Title
`<b029 textcase="01">The magazine of new writing</b029>`	Subtitle
`</titleelement>`
`<titleelement>`
`<x409>01</x409>`	Product level
`<x410>109</x410>`	Number within collection
`<b203 textcase="01">Work</b203>`	Title
`</titleelement>`
`</titledetail>`

In this case, the sender’s system is unable to distinguish reliably between titles with non-sorting prefixes and those without, so it uses <TitleText> rather than a combination of <NoPrefix/> and <TitleWithoutPrefix> to hold the collection-level and product-level titles (respectively, Granta and Work).

a product that is not a part of any collection
using Reference names
`<NoCollection/>`

using Short tags
`<x411/>`

Collection composite

Much of the structure of the <Collection> composite is shared with the <TitleDetail> composite, and similar best practices apply.

Although it is possible to identify contributors to the collection (eg a series editor) within the <Collection> composite – and this may be normal practice in some countries – it is best practice to identify all contributors in Group P.7 in international usage.

P.5.1 Collection type code

The <CollectionType> element is mandatory within a <Collection> composite. It is best practice to use only codes 10 or 20 from List 148, and also to include a source for any ascribed collection in the <SourceName> element. Source names need not be supplied for ‘publisher’ collections, as they are always prescribed by the publisher.

Collection identifier composite

This composite should be used to specify any relevant identifiers for the collection as a whole. It is unlikely that any formal identifiers exist for ascribed collections, but it would be possible to include a proprietary ID for an ascribed collection.

Note that collection identifiers can only be carried in Group P.5, and may be included in P.5 even when the title text for the collection is carried in P.6.

Collection sequence composite

Where the collection is ordered in some way, this composite should be used to provide or confirm that ordering. An order or enumeration may be more or less explicit in the title (‘Volume 7’ is likely to be the seventh in the collection) and this should be included in <TitleDetail> – but it may be repeated here for confirmation, using <CollectionSequenceType> code 02 – this is particularly useful when the ordering is described in Roman numerals or in words (eg The Ersatz Elevator, ‘Book the Sixth’ in A Series of Unfortunate Events), because such collections are difficult to sort. However, the main use for this composite is to provide sequence information that is not shown on the product, for example, a narrative order for a fiction collection, or an original publication order for collected works previously published independently.

It is possible for the products in a collection to have more than one order – for example the narrative order of a collection of fiction products may not be the same as the order the products are published in, and in this case, multiple <CollectionSequence> composites may be supplied. It’s also common for the sequence number of an existing product to be changed as a result of publication of later products.

The numbering provided in <CollectionSequence> is not intended for display by data recipients – what should be displayed is provided in <TitleDetail>. But the numbering provided in <CollectionSequence> should be used to sort the items in the collection.

‘prequel’ – separate narrative and publication orders
using Reference names
`<CollectionSequence>`
`<CollectionSequenceType>03</CollectionSequenceType>`
`<CollectionSequenceNumber>3</CollectionSequenceNumber>`
`</CollectionSequence>`
`<CollectionSequence>`
`<CollectionSequenceType>04</CollectionSequenceType>`
`<CollectionSequenceNumber>1</CollectionSequenceNumber>`
`</CollectionSequence>`

using Short tags
`<collectionsequence>`
`<x479>03</x479>`	Publication order
`<x481>3</x481>`	Third
`</collectionsequence>`
`<collectionsequence>`
`<x479>04</x479>`	Narrative order
`<x481>1</x481>`	First
`</collectionsequence>`

In simple collections, the collection sequence number is an integer (1, 2, 3…). However, for sub-collections that are nested within larger collections, a multi-level number can be used – for example sequence number 3.2 may indicate the second item in a sub-collection, where the sub-collection is sequentially third in the larger collection.

Note that the first-published item in a collection need not have the sequence number 1 (except of course when collection sequence type is 03). If a later ‘prequel’ is planned from the outset, the initial publication might be sequence number 2. A prequel that was not planned from the outset may require revision of previously-supplied metadata for already-published products in the collection, as their narrative order will be affected. A multi-level number like 0.5 or 0.1 should not be used to indicate a prequel added before item 1 in the collection.

Multi-level numbers can also be used to indicate intercalations. A collection may have three items in narrative sequence, with matching print and e-publications. But an additional publication might be added as an optional bonus, perhaps as a digital exclusive, and without being critical to the overall narrative. If the additional publication has a suggested sequential position, this can be indicated with a multi-level number (eg 2.1 would indicate the first e-publication intercalated between items 2 and 3 in the collection, and 0.1 could be used to indicate an intercalation before the first main publication). If the numbering is two-level, while the collection information indicates only a simple one-level collection, the sequence number clearly indicates an intercalation.

For products that are in an ordered collection but outside the sequential ordering of that collection (such items are termed « hors série » in French), the <CollectionSequence> composite should be omitted. Such products are normally sorted after the ordered products in the collection.

Title detail composite

The structure of this composite is identical to <TitleDetail> in Group P.6, but it should be used here to specify a title for the collection (unless it is provided in P.6). The composite must include a <TitleType> – typically, this will be code 01 (Distinctive title), but other types of collection title may be specified. The <TitleDetail> composite must also include at least one repeat of the <TitleElement> composite to carry the actual title.

Title element composite

The <TitleElementLevel> data element may be used to differentiate between a collection title (code 02) and a subcollection title (code 03, used where one collection is nested inside another). Occasionally, most commonly in children’s publishing, a collection also carries a ‘master brand’ (code 05), which might be used across many non-book products. Other values from List 149 may not be used within Group P.5, and code 03 should not be used without an accompanying repeat of <TitleElement> that uses code 02.

Any of P.5.7 Part number through P.5.12 Title text without prefix may carry information about the collection title. In addition, the P.5.13 Subtitle element may be used to carry a subtitle that is shared by all items in the collection. Typically, the title of the collection would be in either <TitleText>, or in a combination of <TitlePrefix> and <TitleWithoutPrefix> – do not use both of these options. See the note about the use of <TitlePrefix> in section Group P.6 <TitleElement> composite.

See the note about the <PartNumber> and <YearOfAnnual> data elements in Group P.6 <TitleElement> composite.

Spacing and punctuation should follow that used on the book itself. However, see the note about the case of text in section Group P.6 <TitleElement> composite.

Occasionally, the product’s collection- and product-level titles do contain some repetition. Repetition of title elements on the product itself should be replicated in the metadata.

repetition of title elements on the product itself should be followed in the metadata
using Reference names
`<Collection>`
`<CollectionType>10</CollectionType>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>05</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix textcase="02">Barbie™</TitleWithoutPrefix>`
`</TitleElement>`
`<TitleElement>`
`<TitleElementLevel>02</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix textcase="02">Easy Reader with Large Print</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`</Collection>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix textcase="02">Barbie as a Pilot</TitleWithoutPrefix>`
`</TitleElement>`
`<TitleDetail>`

using Short tags
`<collection>`
`<x329>10</x329>`	Publisher’s collection
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>05</x409>`	Master brand
`<x501/>`
`<b031 textcase="02">Barbie™</b031>`
`</titleelement>`
`<titleelement>`
`<x409>02</x409>`	Collection level
`<x501/>`
`<b031 textcase="02">Easy Reader with Large Print</b031>`
`</titleelement>`
`</titledetail>`
`</collection>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`
`<titleelement>`	Distinctive title
`<x409>01</x409>`	Product level
`<x501/>`
`<b031 textcase="02">Barbie as a Pilot</b031>`
`</titleelement>`
`<titledetail>`

The repetition in this case potentially also encompasses the <Edition> information – the publisher should decide whether ‘with Large Print’ is a part of the collection identity, or whether it should be described as a large print edition (code LTE from List 21 in <EditionType>, within Group P.9). This may depend on whether there is a ‘normal print’ version as well.

P.5.64 “No collection” indicator

This is one of the few ONIX for Books data elements that are defined as empty (or ‘void’) XML elements. The ‘self-closing’ or minimized XML syntax should always be used (ie use <NoCollection/>, not <NoCollection> followed by </NoCollection>).

P.6 Product title detail

Group P.6 consists primarily of the <TitleDetail> composite, which carries the title of the product. Every Product record must carry a title.

It is best practice to deliver title text in a structured and granular fashion, rather than simply providing text with punctuation to indicate the difference between collection, main title and subtitle. By providing the title in a structured way, it ensures the recipient of the data can store and process it in the most appropriate way in their own system. With products that have both a shared ‘collection’ title and an individual product-level title, these should be delivered in separate repeats of the <TitleElement> composite having different values in the <TitleElementLevel> data element. (Note that collection-level titles might be provided in Group P.5 instead.)

Do not add extra information to the title that properly appears elsewhere in the ONIX record. For example, there is often a temptation to add information about the product form, edition or audience to the title ‘because the title is always displayed prominently in the online store.’

For products which are known under more than one title – for example the distinctive title that is on the product, plus a former title that the work was previously known by – the entire <TitleDetail> composite is repeatable, with different values of <TitleType>.

There must be at least one <TitleDetail> composite, to carry the primary title of the product. The composite:

must include a <TitleType> and typically this should indicate it is a distinctive title;
must carry one or more <TitleElement> composites carrying details of the product title;
should include any collection-level title details that are not included in Group P.5. If collection-level title details are provided in P.6, they should be differentiated from the product-level title details in a separate <TitleElement> composite;
should not carry extra information about the product form, edition etc.

Where the product is well-known under a different title, the alternative title should be provided in addition to the primary title, in a separate repeat of the <TitleDetail> composite.

simple product not part of a collection (sending system *cannot* reliably distinguish between titles with prefixes and without)
using Reference names
`<!-- Group P.5 -->`
`<NoCollection/>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<TitleText textcase="02">Mordsfreunde</TitleText>`
`</TitleElement>`
`</TitleDetail>`

using Short tags
`<!-- Group P.5 -->`
`<x411/>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>01</x409>`	Product level
`<b203 textcase="02">Mordsfreunde</b203>`
`</titleelement>`
`</titledetail>`

simple product with title and subtitle (sending system *can* reliably distinguish between titles with prefixes and without)
using Reference names
`<!-- Group P.5 -->`
`<NoCollection/>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix>خريف الغضب</TitleWithoutPrefix>`
`<Subtitle>قصة بداية ونهاية السادات</Subtitle>`
`</TitleElement>`
`</TitleDetail>`

using Short tags
`<!-- Group P.5 -->`
`<x411/>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>01</x409>`	Product level
`<x501/>`
`<b031>خريف الغضب</b031>`	Title
`<b029>قصة بداية ونهاية السادات</b029>`	and subtitle
`</titleelement>`
`</titledetail>`

simple product with an alternative title
using Reference names
`<!-- Group P.5 -->`
`<NoCollection/>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix textcase="02">Slumdog Millionaire</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`<TitleDetail>`
`<TitleType>08</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix textcase="02">Q & A</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`

using Short tags
`<!-- Group P.5 -->`
`<x411/>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>01</x409>`	Product level
`<x501/>`
`<b203 textcase="02">Slumdog Millionaire</b203>`
`</titleelement>`
`</titledetail>`
`<titledetail>`
`<b202>08</b202>`	Former title
`<titleelement>`
`<x409>01</x409>`	Product level
`<x501/>`
`<b031 textcase="02">Q & A</b031>`	Must use entity for ‘&’
`</titleelement>`
`</titledetail>`

product that is part of a collection specified in Group P.5
using Reference names
`<!-- Group P.5 -->`
`<Collection>`
`<CollectionType>10</CollectionType>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>02</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix textcase="02">Larousse Petits Classiques</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`</Collection>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<TitlePrefix textcase="02">Les</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">Misérables</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`

using Short tags
`<!-- Group P.5 -->`
`<collection>`
`<x329>10</x329>`	Publisher collection
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>02</x409>`	Collection level
`<x501/>`
`<b031 textcase="02">Larousse Petits Classiques</b031>`
`</titleelement>`
`</titledetail>`
`</collection>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>01</x409>`	Product level
`<b030 textcase="02">Les</b030>`
`<b031 textcase="02">Misérables</b031>`
`</titleelement>`
`</titledetail>`

omnibus edition of three novels, without a distinctive title of its own
using Reference names
`<!-- no Group P.5 -->`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<SequenceNumber>1</SequenceNumber>`
`<TitleElementLevel>01</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix>Sense and Sensibility / Pride and Prejudice / Northanger Abbey</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`

using Short tags
`<!-- no Group P.5 -->`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`
`<titleelement>`
`<b034>1</b034>`
`<x409>01</x409>`
`<x501/>`
`<b031 textcase="02">Sense and Sensibility / Pride and Prejudice / Northanger Abbey</b031>`
`</titleelement>`
`</titledetail>`

If the omnibus edition has a distinctive title of its own (something like The Jane Austen Omnibus, Part One), that should be used in preference. The constituent titles could then be listed as a subtitle if necessary. Multiple titles are conventionally separated by spaced slash characters. A more sophisticated alternative would make use of <ContentDetail> (see Block 3), but this would be unnecessary in a simple case like this.

manga novel with collection title included in P.6
using Reference names
`<!-- no Group P.5 -->`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<SequenceNumber>1</SequenceNumber>`
`<TitleElementLevel>02</TitleElementLevel>`
`<NoPrefix/>`
`<TitleWithoutPrefix textcase="02">Kobato.</TitleWithoutPrefix>`
`</TitleElement>`
`<TitleElement>`
`<SequenceNumber>2</SequenceNumber>`
`<TitleElementLevel>01</TitleElementLevel>`
`<PartNumber>3</PartNumber>`
`</TitleElement>`
`<TitleStatement>Kobato. 3</TitleStatement>`
`</TitleDetail>`

using Short tags
`<!-- no Group P.5 -->`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<b034>1</b034>`
`<x409>02</x409>`	Collection level
`<x501/>`
`<b031 textcase="02">Kobato.</b031>`
`</titleelement>`
`<titleelement>`
`<b034>2</b034>`
`<x409>01</x409>`	Product level
`<x410>3</x410>`
`</titleelement>`
`<x478>Kobato. 3</x478>`
`</titledetail>`

The part number is the only product-level title information for this product – there is no product level title text. The title statement is somewhat unnecessary here, since it is a simple concatenation of the title elements, but is provided for the avoidance of doubt about the nature of the product-level title.

Title detail composite

At least one <TitleDetail> composite is mandatory, to carry the product title. The composite must include a <TitleType> – typically, this will specify code 01 (Distinctive title) – and at least one repeat of the <TitleElement> composite.

Multiple repeats of the whole <TitleDetail> composite can be used to carry different types of title – for example a former title of a product whose name has been changed, or the original language title of a product published in translation. While a recipient might not display such alternative titles, they can be helpful as search terms.

: Contrast the titles of the Shakespeare plays Twelfth Night, or What You Will, where the full title itself contains an ‘alternative’ name for the play, and Much Ado About Nothing which is occasionally known by the genuine alternative title of Benedick and Beatrice. The latter requires two <TitleDetail> composites, the former just one, with the complete title text in a single <TitleText> element.

It may also be useful to specify the distributor’s title: this is often abbreviated or truncated in order to fit on a single line on order confirmations, invoices and other documents, or sized to fit a fixed-length database field in a legacy sales order processing system – it is common for distribution systems to limit the length of a title to 30 or so characters. Such titles often also mix collection and product-level elements, or other non-title details such as binding type, edition and so on (eg 12th N sch ed w. class no 30pk). Thus a Distributor’s title can appear somewhat cryptic, and specifying it can be an aid if any matching against other documents (eg invoices) is required.

Title element composite

Any of P.6.3 <PartNumber> through P.6.8 <Subtitle> may carry information about the product title.

Conceptually, each of the elements of a title belongs to either ‘product’ or ‘collection’ level – that is, it is part of the identity of the product itself, or is part of the identity of a group of products.

Multiple repeats of the <TitleElement> composite within one <TitleDetail> are often needed if the product belongs to a collection and the full collection details are not included in Group P.5 (ie there are two or more <TitleElement> composites with different levels), or if the title contains several largely independent parts – for example an annual or yearbook may have both a textual title and a year or date (ie there are two or more <TitleElement> composites with the same level).

Where the presentation order of multiple title elements at different levels is important, then the <SequenceNumber> data element should be included within each repeat of <TitleElement> – thus <SequenceNumber> should be used to guide data recipients on whether a collection title should ideally be displayed before or after the product-level title. However, their display order (eg on a web page) may be dictated by the recipient’s screen design. Despite this, never carry a collection title in the <Subtitle> element ‘to ensure it is displayed after the main title’.

Where a title has multiple data elements at the same level – say it has a <PartNumber>, <TitleText>, plus a <Subtitle>, which are all at ‘product level’ – then these can be expressed in a single <TitleElement> composite, or in two separate repeats of <TitleElement> within a single <TitleDetail> (note that a <TitleElement> containing only a subtitle is not valid). Either is acceptable. Data recipients might concatenate these three elements for display purposes in a common-sense order (part number first, subtitle last), or – if each separate <TitleElement> contains a <SequenceNumber> – should follow the guidance of the <SequenceNumber>.

multiple title elements at the same level: a book entitled Best Season Ever: 1998 in a collection Baseball Year by Year
using Reference names
`<!-- collection title carried in Group P.5 -->`
`<TitleElement>`
`<SequenceNumber>1</SequenceNumber>`
`<TitleElementLevel>01</TitleElementLevel>`
`<TitleText textcase="02">Best Season Ever</TitleText>`
`</TitleElement>`
`<TitleElement>`
`<SequenceNumber>2</SequenceNumber>`
`<TitleElementLevel>01</TitleElementLevel>`
`<YearOfAnnual>1998</YearOfAnnual>`
`</TitleElement>`

using Short tags
`<!-- collection title carried in Group P.5 -->`
`<titleelement>`
`<b034>1</b034>`	First part of
`<x409>01</x409>`	product-level title
`<b203 textcase="02">Best Season Ever</b203>`
`</titleelement>`
`<titleelement>`
`<b034>2</b034>`	Second part of
`<x409>01</x409>`	product-level title
`<b020>1998</b020>`
`</titleelement>`

This approach is better than putting the title text and year of annual in the same <TitleElement> composite, because it ensures the recipient understands that the title is not 1998: Best Season Ever.

The sender’s system is unable to distinguish reliably between titles with and without prefixes, so it uses <TitleText> instead of <NoPrefix/> and <TitleWithoutPrefix>.

multiple title elements at different levels: a book called Descent: Book 3 of The Exo Cycle
using Reference names
`<TitleElement>`
`<SequenceNumber>1</SequenceNumber>`
`<TitleElementLevel>01</TitleElementLevel>`
`<NoPrefix/>`
`<TitleText textcase="02">Descent</TitleText>`
`</TitleElement>`
`<TitleElement>`
`<SequenceNumber>2</SequenceNumber>`
`<TitleElementLevel>01</TitleElementLevel>`
`<PartNumber>Book 3</PartNumber>`
`</TitleElement>`
`<TitleElement>`
`<SequenceNumber>3</SequenceNumber>`
`<TitleElementLevel>02</TitleElementLevel>`
`<TitlePrefix textcase="02">The</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">Exo Cycle</TitleWithoutPrefix>`
`</TitleElement>`

using Short tags
`<titleelement>`
`<b034>1</b034>`	First part of
`<x409>01</x409>`	product-level title
`<x501/>`
`<b031 textcase="02">Descent</b031>`
`</titleelement>`
`<titleelement>`
`<b034>2</b034>`	Second part of title
`<x409>01</x409>`	(at product level)
`<x410>Book 3</x410>`
`</titleelement>`
`<titleelement>`
`<b034>3</b034>`
`<x409>02</x409>`
`<b030 textcase="02">The</b030>`	Third part of title
`<b031 textcase="02">Exo Cycle</b031>`	(at collection level)
`</titleelement>`

This makes it clear that the collection title is best placed after the product-level title (ie not The Exo Cycle – Book 3: Descent). Positioning of the collection title within P.6 rather than in P.5 is a complex decision. See the guidance in P.5 Collection.

In this case, the sender’s system can distinguish reliably between titles with and without prefixes that are ignored for sorting purposes. Thus the collection-level title The Exo Cycle uses <TitlePrefix> and the product-level title Descent makes use of <NoPrefix/> and <TitleWithoutPrefix>.

Optionally, if the title is particularly complex, and simple concatenation of the various title elements (in the order specified) is not enough, then a <TitleStatement> can be used (always in addition to the granular title elements). For recipients, if a title statement is provided, this should be used for display purposes wherever possible, while the individual title elements may be used for more advanced search or collation purposes. Note that a title statement should include the subtitle, and any intermediate punctuation, but should not include the text of any alternative titles – alternative titles may have a title statement of their own.

Typically, the main text of a title element would be in one of:

a combination of <NoPrefix/> and <TitleWithoutPrefix> or
a combination of <TitlePrefix> and <TitleWithoutPrefix> or
<TitleText>

The last of these options – <TitleText> – is reserved for use when the sending system cannot differentiate between titles that include a prefix and titles that do not. The other two choices should be used when the system can differentiate. <TitlePrefix> is used when the title begins with a prefix that should be ignored for collation purposes (depending on the language of the title text: in English, ‘A’, ‘An’ or ‘The’ are ignored for collation, in Spanish, «El», «La», «Las», «Lo», «Los», «Un», «Una», «Unas», «Unos»). <NoPrefix/> is an empty element that provides positive indication that there is no prefix. Note that a title beginning with ‘A to Z’ or with a place name like ‘El Paso’ would not normally use <TitlePrefix>, since ‘A’ or ‘El’ are not ignored for collation purposes in these circumstances. Titles beginning with quotation marks, an apostrophe or initial punctuation like ¡ or ¿ do not use <TitlePrefix> even though those marks are ignored for collation purposes. In rare cases where there is both initial punctuation and a non-sorting prefix, such as the title Spanish ¿La madre también?, <TitlePrefix> would be used for «¿La».

If limitations in internal systems mean that a data supplier genuinely cannot distinguish titles that carry prefixes from those that do not – and thus cannot use <TitlePrefix>, <NoPrefix/> and <TitleWithoutPrefix> correctly – then <TitleText> should be used. This means that a recipient which wishes to take definite account for prefixes when sorting titles needs to inspect all records using <TitleText>.

For languages which do not normally use definite and indefinite articles – for example Norwegian or Swedish – the <NoPrefix/> element should be used.

When a title is not in the same language as the main text content of the product itself, the language attribute should be included.

product in English, with title in French – compare with the Larousse Petits Classiques version (above), which is in French throughout. Distributor’s title also included
using Reference names
`<!-- Group P.5 -->`
`<Collection>`
`<CollectionType>10</CollectionType>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>02</TitleElementLevel>`
`<TitleText textcase="02">Penguin Classics</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`</Collection>`
`<!-- Group P.6 -->`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<TitlePrefix language="fre" textcase="02">Les</TitlePrefix>`
`<TitleWithoutPrefix language="fre" textcase="02">Misérables</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`<TitleDetail>`
`<TitleType>10</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<TitleText>LES MISERABLES (PENG CLASS B)</TitleText>`
`</TitleElement>`
`</TitleDetail>`

using Short tags
`<!-- Group P.5 -->`
`<collection>`
`<x329>10</x329>`	Publisher collection
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>02</x409>`	Collection level
`<b203 textcase="02">Penguin Classics</b203>`
`</titleelement>`
`</titledetail>`
`</collection>`
`<!-- Group P.6 -->`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>01</x409>`	Product level
`<b030 language="fre" textcase="02">Les</b030>`	Title is in French…
`<b031 language="fre" textcase="02">Misérables</b031>`	not translated into English as ‘The Wretched Ones’ or similar, and is in Title case
`</titleelement>`
`</titledetail>`
`<titledetail>`
`<b202>10</b202>`	Distributor’s title
`<titleelement>`
`<x409>01</x409>`	Product level
`<b203>LES MISERABLES (PENG CLASS B)</b203>`
`</titleelement>`
`</titledetail>`

The Collection title given is paired with the Distinctive title, not the Distributor’s title, on the basis that they carry the same code in <TitleType>.

It is not normally expected that metadata provided by publishers follows formal library cataloging rules (for example the AACR2 or RDA content rules). With the exception of the case of the text, the title information provided in an ONIX record should follow the title as it is provided on the product title page (or equivalent). Acronyms and initialisms should be capitalized and punctuated as they are on the product’s title page.

In scripts with distinct upper and lower case (including Latin, Cyrillic etc, but not for example Arabic or Japanese Kanji), the textcase attribute is important with textual data elements such as <TitleText>, <TitlePrefix>, <TitleWithoutPrefix> and <Subtitle>. It is best practice to follow the conventions of the language of the title, and to include the textcase attribute. In many languages using a cased script, it is normal style to present titles and similar textual data in ‘sentence case’ (first word and all proper nouns carry an initial capital – note this means that the first character of <TitleWithoutPrefix> is lower case, unless it is a proper noun or a capitalized acronym). In English and some other cased languages, it is normal style to supply titles – but not subtitles – in ‘title case’ (all words carry an initial capital except for articles, most prepositions and most conjunctions that appear mid-sentence). Subtitles should always be presented in sentence case. Titles and similar textual data should never be presented in ALL UPPER CASE, and in instances where this is unavoidable (for example, with legacy data), use the textcase attribute with code 03.

: Upper case titles constructed solely from acronyms or initialisms (eg ‘VAX FORTRAN’) are correct in both title and in sentence case, and should not usually marked with textcase code 03.

In scripts where the sort order is not essentially alphabetic – for example in Japanese Kanji where names and titles are sorted phonetically, or in Traditional or Simplified Chinese Hanzi where Pinyin or Zhuyin phonetics or (occasionally) the number of brush strokes in individual characters control the collation order – the collationkey attribute can be included. This would typically contain a phonetic transliteration of the data element (in Hiragana, Katakana, Pinyin or Zhuyin etc).

When the language of the title is not the expected language of the message, then the language attribute should also be provided.

Note that <PartNumber> indicates a sequential position within a collection, and should not be used unless details of the collection are included (either in Group P.5 or in P.6). A volume or part number is normally product-level information, not part of the shared identity of a collection, and would thus appear with <TitleElementLevel> 01 – and it might appear either in the same repeat of <TitleElement> as the product-level title or as a separate title element. It is a common error to supply a part number or year at collection level, when it belongs at product level. However, <PartNumber> may occasionally be sub-collection level information where one collection is nested inside another.

<PartNumber> might be a simple number, or might convey the ‘type’ of the item within the collection – a volume, a part, a book, a tome and so on. If anything more than a simple number is used, ensure the terminology matches that on the product, and that the text is presented consistently (including consistent spacing and abbreviation) so that items in the collection will sort correctly into order whenever possible. In this circumstance, it is good practice also to provide the ordinal position of the product within the collection in the <CollectionSequence> composite in Group P.5. Where it is provided, recipients should use <CollectionSequence> to sort members of a collection into order, in preference to using <PartNumber>. This composite is particularly useful with sub-collections.

<PartNumber>3</PartNumber> (number 3 in a series)

<PartNumber>Part 3</PartNumber> (a named Part 3)

<PartNumber>Volume 3</PartNumber> (a named Volume 3)

<PartNumber>Book III</PartNumber> (note that neither roman numerals nor a named ‘Book Three’ sort into the correct order alphabetically)

<PartNumber>Parts 3–5</PartNumber> (Parts 3, 4 and 5 of a collection in a single item)

Similar considerations apply to the use of <YearOfAnnual>, which might contain a simple year (‘2011’), or something qualified such as ‘2009/10 Season’. Consistency is important, or the individual products of a collection will not sort into the correct order (even when simple sorting is possible).

P.7 Authorship

The various contributors to a product are listed in repeats of the <Contributor> composite. It is best practice to include at least all the contributors named on the book’s title page (or those named with equivalent prominence on another type of product). However, it is normal to omit those such as ‘ghost writers’ not named on the product itself.

If there are no repeats of the <Contributor> composite, the <NoContributor/> empty element gives a positive indication that there are no contributors.

Contributor composite

Each contributor to a product should be named within a <Contributor> composite. The composite:

should include a sequence number to indicate the order in which multiple contributor names should be presented;
must indicate the role of that contributor in the creation of the product;
should carry any available identifiers for the contributor in the <NameIdentifier> composite;
should carry the name of the person or corporate contributor in the form it appears on the product, or an <UnnamedPersons> element;
- personal names should be carried in one or more of the following forms (in order of preference):
  1. a fully structured name using P.7.11–P.7.18;
  2. an inverted name using <PersonNameInverted>;
  3. the contributor name in <PersonName>;
- corporate names should be carried in <CorporateName> and ideally also in <CorporateNameInverted>, particularly if the name includes a prefix that should be ignored for collation;
- there should be an <UnnamedPersons> element for contributors unnamed because their identity is unknown, who wish to remain anonymous, or who are unnamed as a matter of policy (eg ‘no more than three named authors’);
should include an <AlternativeName> composite if the form of a name that appears on the product is not the usual or most familiar form used by that contributor.

It is always extremely valuable to provide a short biographical note for named contributors. In some countries, the <ContributorPlace> composite is also recommended, to help promote ‘local’ contributors.

In some cases, a machine-generated list of individual contributor roles and names may not produce a satisfactory description of the authorship for display to a customer. In this event, a <ContributorStatement> should be included. Where it is provided, recipients should use <ContributorStatement> for display purposes.

If there are no contributors to a product (either in P.7 or in Group P.5, where contributors to a collection can be listed), then the <NoContributor/> empty element should be included instead.

Personal naming schemes are complex, sensitive and vary greatly between cultures, so data suppliers and recipients should take great care that names are presented correctly. The ONIX data elements for structured names attempt to isolate the parts of the name used for cataloging, advanced searching and sorting purposes, rather than trying to specify the ‘genealogical’ or familial structure of a name. Consider for example, three names, Sharon Stanton Russell, Anna Margaret Lindholm and Carmen Conde Abellán. For the (American) name Sharon Stanton Russell, Stanton is her unmarried family name (maiden name) retained after marriage, whereas for (British) Anna Margaret Lindholm, Margaret is a second given name. ONIX does not differentiate between these cases – ‘Russell’ and ‘Lindholm’ are the <KeyNames>, and Sharon Stanton and Anna Margaret would both be treated as <NamesBeforeKey>, even though one contains only given names and the other contains a family name. In the case of the (Spanish) name Carmen Conde Abellán, the <KeyNames> are ‘Conde Abellán’, since both are family names used for sorting purposes.

single contributor, contributor identifiers (including an ISNI) and all three forms of name provided
using Reference names
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A01</ContributorRole>`
`<NameIdentifier>`
`<NameIDType>16</NameIDType>`
`<IDValue>0000000020691583</IDValue>`
`</NameIdentifier>`
`<NameIdentifier>`
`<NameIDType>01</NameIDType>`
`<IDTypeName>Ullstein Buchverlage Autor ID</IDTypeName>`
`<IDValue>01381</IDValue>`
`</NameIdentifier>`
`<PersonName>Nele Neuhaus</PersonName>`
`<PersonNameInverted>Neuhaus, Nele</PersonNameInverted>`
`<NamesBeforeKey>Nele</NamesBeforeKey>`
`<KeyNames>Neuhaus</KeyNames>`
<BiographicalNote textformat="05"><p><strong>Nele Neuhaus</strong> wurde 1967 als zweites von vier Kindern der Familie Löwenberg in Münster/Westfalen geboren. Sie wuchs in Paderborn auf, bevor sie im Alter von 11 Jahren mit ihrer Familie in den Taunus zog, als ihr Vater Landrat wurde. Schon seit frühester Kindheit schrieb Nele Neuhaus, zuerst handschriftlich in Schulhefte, später mit Reiseschreibmaschine und Computer.</p><p>Durch ihre Leidenschaft für Pferde lernte sie auf einem Reitturnier ihren Mann kennen, mit dem sie heute in Kelkheim/Taunus lebt.</p></BiographicalNote>
`</Contributor>`

using Short tags
`<contributor>`
`<b034>1</b034>`	First contributor
`<b035>A01</b035>`	Written by
`<nameidentifier>`
`<x415>16</x415>`	ISNI
`<b244>0000000020691583</b244>`
`</nameidentifier>`
`<nameidentifier>`
`<x415>01</x415>`	Proprietary ID
`<b233>Ullstein Buchverlage Autor</b233>`
`<b244>01381</b244>`
`</nameidentifier>`
`<b036>Nele Neuhaus</b036>`
`<b037>Neuhaus, Nele</b037>`
`<b039>Nele</b039>`
`<b040>Neuhaus</b040>`
<b044 textformat="05"><p><strong>Nele Neuhaus</strong> wurde 1967 als zweites von vier Kindern der Familie Löwenberg in Münster/Westfalen geboren. Sie wuchs in Paderborn auf, bevor sie im Alter von 11 Jahren mit ihrer Familie in den Taunus zog, als ihr Vater Landrat wurde. Schon seit frühester Kindheit schrieb Nele Neuhaus, zuerst handschriftlich in Schulhefte, später mit Reiseschreibmaschine und Computer.</p><p>Durch ihre Leidenschaft für Pferde lernte sie auf einem Reitturnier ihren Mann kennen, mit dem sie heute in Kelkheim/Taunus lebt.</p></b044>	Text uses XHTML markup, and message uses UTF‑8 encoding so non-ASCII characters such as ‘ü’ need not be expressed as numerical character references (and must not be carried as HTML entities such as ‘ü’)
`</contributor>`

single corporate contributor, name provided in both normal and inverted form
using Reference names
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A09</ContributorRole>`
`<CorporateName>CLAMP</CorporateName>`
`<CorporateNameInverted>CLAMP</CorporateNameInverted>`
`<BiographicalNote textformat="05"><p><strong>CLAMP</strong> is a renowned all-female mangaka collective. Over more than 20 years, it has created many internationally successful series, including <em>xxxHolic</em>, <em>Tsubasa Reservoir Chronicles</em>, <em>Card Captor Sakura</em>, <em>Magic Knight Rayearth</em>, <em>Chobits</em> and <em>Tokyo Babylon</em>.</p></BiographicalNote>`
`</Contributor>`

using Short tags
`<contributor>`
`<b034>1</b034>`
`<b035>A09</b035>`	Created by
`<b047>CLAMP</b047>`
`<x443>CLAMP</x443>`
`<b044 textformat="05"><p><strong>CLAMP</strong> is a renowned all-female mangaka collective. Over more than 20 years, it has created many internationally successful series, including <em>xxxHolic</em>, <em>Tsubasa Reservoir Chronicles</em>, <em>Card Captor Sakura</em>, <em>Magic Knight Rayearth</em>, <em>Chobits</em> and <em>Tokyo Babylon</em>.</p></b044>`
`</contributor>`

single contributor with alternative name (and alternative name identifier)
using Reference names
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A01</ContributorRole>`
`<NameIdentifier>`
`<NameIDType>01</NameIDType>`
`<IDTypeName>HCP Author ID</IDTypeName>`
`<IDValue>6108</IDValue>`
`</NameIdentifier>`
`<PersonNameInverted>Westmacott, Mary</PersonNameInverted>`
`<NamesBeforeKey>Mary</NamesBeforeKey>`
`<KeyNames>Westmacott</KeyNames>`
`<AlternativeName>`
`<NameType>04</NameType>`
`<NameIdentifier>`
`<NameIDType>01</NameIDType>`
`<IDTypeName>HCP Author ID</IDTypeName>`
`<IDValue>1067</IDValue>`
`</NameIdentifier>`
`<PersonNameInverted>Christie, Agatha</PersonNameInverted>`
`<NamesBeforeKey>Agatha</NamesBeforeKey>`
`<KeyNames>Christie</KeyNames>`
`</AlternativeName>`
`<BiographicalNote textformat="05"><p><strong>Mary Westmacott</strong> was a pseudonym used on six novels by the ‘Queen of Crime’ Agatha Christie.</p><p>Agatha Christie was born in Torquay in 1890 and became, quite simply, the best-selling novelist in history, outsold only by The Bible and Shakespeare.</p><BiographicalNote>`
`</Contributor>`
`<ContributorStatement>Agatha Christie, writing as Mary Westmacott</ContributorStatement>`

using Short tags
`<contributor>`
`<b034>1</b034>`	First contributor
`<b035>A01</b035>`	Written by
`<nameidentifier>`
`<x415>01</x415>`	Proprietary
`<b233>HCP Author ID</b233>`
`<b244>6108</b244>`
`</nameidentifier>`
`<b037>Westmacott, Mary</b037>`
`<b039>Mary</b039>`	Name as on product
`<b040>Westmacott</b040>`	(a pseudonym)
`<alternativename>`
`<x414>04</x414>`	Real name
`<nameidentifier>`
`<x415>01</x415>`	Proprietary
`<b233>HCP Author ID</b233>`
`<b244>1067</b244>`
`</nameidentifier>`
`<b037>Christie, Agatha</b037>`
`<b039>Agatha</b039>`	Real name
`<b040>Christie</b040>`	of author
`</alternativename>`
`<b044 textformat="05"><p><strong>Mary Westmacott</strong> was a pseudonym used on six novels by the ‘Queen of Crime’ Agatha Christie.</p><p>Agatha Christie was born in Torquay in 1890 and became, quite simply, the best-selling novelist in history, outsold only by The Bible and Shakespeare.</p><b044>`
`</contributor>`
`<b049>Agatha Christie, writing as Mary Westmacott</b049>`	Text to be used for display purposes

In this case, the proprietary <NameIdentifier> is different for the two names, even though they refer to the same person, and (arguably) to the same public identity.

multiple contributors
using Reference names
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>B01</ContributorRole>`
`<!-- <NameIdentifier> omitted for brevity -->`
`<PersonNameInverted>Jones, Steve</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>2</SequenceNumber>`
`<ContributorRole>B01</ContributorRole>`
`<PersonNameInverted>Martin, Robert</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>3</SequenceNumber>`
`<ContributorRole>B01</ContributorRole>`
`<PersonNameInverted>Pilbeam, David</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>4</SequenceNumber>`
`<ContributorRole>B15</ContributorRole>`
`<PersonNameInverted>Bunney, Sarah</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>5</SequenceNumber>`
`<ContributorRole>A24</ContributorRole>`
`<PersonNameInverted>Dawkins, Richard</PersonNameInverted>`
`</Contributor>`

using Short tags
`<contributor>`
`<b034>1</b034>`	Contributor 1
`<b035>B01</b035>`	Edited by
`<!-- <nameidentifier> omitted for brevity -->`
`<b037>Jones, Steve</b037>`
`</contributor>`
`<contributor>`
`<b034>2</b034>`	Contributor 2
`<b035>B01</b035>`	Edited by
`<b037>Martin, Robert</b037>`
`</contributor>`
`<contributor>`
`<b034>3</b034>`	Contributor 3
`<b035>B01</b035>`	Edited by
`<b037>Pilbeam, David</b037>`
`</contributor>`
`<contributor>`
`<b034>4</b034>`	Contributor 4
`<b035>B15</b035>`	Editorial coordination by
`<b037>Bunney, Sarah</b037>`
`</contributor>`
`<contributor>`
`<b034>5</b034>`	Contributor 5
`<b035>A24</b035>`	Introduction by
`<b037>Dawkins, Richard</b037>`
`</contributor>`

It is normal to provide a combined biographical note for multiple contributors in Group P.14 (<TextType> code 12 from List 153).

an unnamed contributor
using Reference names
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A01</ContributorRole>`
`<UnnamedPersons>02</UnnamedPersons>`
`</Contributor>`

using Short tags
`<contributor>`
`<b034>1</b034>`	First contributor
`<b035>A01</b035>`	Written by
`<b249>02</b249>`	Anonymous
`</contributor>`

no contributors
using Reference names
`<NoContributor/>`

using Short tags
`<n339/>`

P.7.1 Contributor sequence number

<SequenceNumber> contains a simple sequential integer: the first contributor listed on the product’s title page (or its equivalent on a non-book product) should be number 1, and subsequent contributors numbered 2, 3 and so on. The sequence number should always reflect the order used on the product, and not, for example, alphabetical order or an order based on their roles.

This sequence number should always be used by ONIX recipients to collate and display contributors. Do not rely on the order that contributors are listed within the ONIX file, although where possible ONIX senders should arrange files so that the sequence numbers do occur in order in the Product record.

If there are also contributors listed in P.5, their sequence numbers should form part of the same sequence – sequence numbers should be unique within the whole Product record – and this may mean the order contributors occur within the file is not their correct collation order.

P.7.2 Contributor role

The contributor role specifies the function of a contributor in the creation of the product. Note that the <ContributorRole> element is repeatable, and it should be repeated where a single contributor has multiple roles in relation to the product – do not list the same contributor twice.

using Reference names
`<ContributorRole>A24</ContributorRole>`	Introduced and
`<ContributorRole>B06</ContributorRole>`	translated by…

using Short tags
`<b035>A01</b035>`	Written and
`<b035>A12</b035>`	illustrated by…

Repetition of roles can conflict with the arrangement of contributors in their correct sequence – for example, ‘Written by Charles Smith and Jonathan Green, read by Charles Smith’. In this case, Charles Smith is Contributor 1 (with two roles), and Jonathan Green is Contributor 2. There should be no Contributor 3: Charles Smith should not be repeated. This is a case where the <ContributorStatement> data element is valuable.

Name identifier composite

There is as yet no well-established public standard for name identifiers. There is ongoing development of the relatively new ISNI (International Standard Name Identifier), and support for it is growing. There are also many well-developed library name identifiers such as the LCCN or VIAF (to which ISNI is closely linked), but none is widely used within the book trade.

Over seven million contributor names have been assigned an ISNI, and this is the preferred name identifier within ONIX.

: The ISNI (like some other ‘name identifiers) is in fact an identifier for a ‘public identity’ or a ‘persona’, rather than for a single name: one ISNI can be associated with many names or name variations that are used by a single persona, and a single public identity may in fact be shared by more than one real person (eg a writing team may use a single pseudonym). A named ONIX contributor is a single persona, and an ISNI identifies that persona, rather than a particular name or name variation used by that contributor – so it is best practice to associate an ISNI with the primary name of a contributor. Note that an ISNI does not directly identify the ‘person’ or ‘party’ that uses the name in the way that an ID like a Social Security number does.

However, since few publishers have yet adopted the ISNI, even internal identifiers used by publishers can be helpful to ONIX data recipients who wish to collocate products by a contributor, or distinguish products by two contributors with identical names. The form of a name may change on successive products by a single contributor (Steve Jones, Dr. Steve Jones, Prof. Steve Jones etc). A name may be very similar or identical to that used by a quite different contributor (one UK publisher publishes two separate authors called Professor Richard Holmes), or a contributor may use one or more pseudonyms without any particular wish for anonymity (eg Ruth Rendell and Barbara Vine). Names change over time (eg through marriage, legal changes, or through the addition of titles, qualifications and honors), and the exact form of a name used on a product may also be influenced by marketing requirements – a popular dieting book and an academic treatment of nutrition may use subtly different forms of name for the same contributor. In all of these cases, collocation is aided even by proprietary identifiers. Of course, a public identifier such as an ISNI is of greater utility for cases where multiple publishers are involved or when a contributor is active in other creative fields too (a specific feature of ISNI is that it bridges between books, music and other fields). When providing a proprietary identifier, always include a consistent name for the identifier in the <IDTypeName> element, so it can be distinguished from proprietary identifiers controlled by other organizations.

P.7.9, P.7.10 Personal names

It is strongly preferred to supply personal contributor names in a fully-structured manner, using the elements P.7.11 to P.7.18, ideally with both <PersonName> and <PersonNameInverted> as well. However, publisher’s systems may not support such granularity. If structured names are not available, then there is great value in providing both <PersonName> and <PersonNameInverted>. Recipients may then use the former for display and the latter for collation (and possibly both for search). And if only one type of unstructured name can be included, the ‘inverted’ form of the name with family name before given name in <PersonNameInverted> is preferred to the use of <PersonName> alone.

The ‘inverted’ order is the normal order for Chinese, Japanese and many other Eastern naming systems, and for Hungarian names – and for these names, <PersonName> and <PersonNameInverted> would be identical.

<PersonName> alone is the ‘worst case’ option, used only when contributor names cannot be supplied in any other form. Note that names provided in this form cannot reliably be collated (ie sorted into alphabetical order).

The primary name supplied should be the name as it is used on the product, and should be the name used by recipients for display purposes. If the publisher wishes, alternative forms of the same name – or alternative names for the same contributor – can be provided in the <AlternativeName> composite. Providing alternative names and name identifiers can help collocation, where different forms of the same name are used on different products. In the rare case where two names for the same contributor are used on the same product, then the primary name should be the name used most prominently, with the less prominent name supplied as an <AlternativeName>.

<PersonName>	<PersonNameInverted>	(key names in bold)
Dame Ngaio Marsh	Marsh, Dame Ngaio
Henry of Huntingdon	Huntingdon, Henry of
Henriette d’Angeville	Angeville, Henriette d’
Mary O’Connor	O’Connor, Mary
Máire ó Conchobhair	Conchobhair, Máire ó
Gabriel Garcia Márquez	Garcia Márquez, Gabriel
Megan Lloyd George	Lloyd George, Megan
Luo Guanzhong	Luo Guanzhong	(family name first)
村上春樹	村上春樹	(Haruki Murakami, family name first)
Björk Guðmundsdóttir	Björk Guðmundsdóttir	(patronymic is not key name)
प्रेमचंद	प्रेमचंद	(Premchand, only a single name)
שפרה הורן	הורן, שפרה	(Shifra Horn, text runs right to left)
Abu al-Hasan Ali ibn al-Husayn ibn Ali al-Mas'udi	Mas'udi, Abu al-Hasan Ali ibn al-Husayn ibn Ali al-	(أبو الحسن علي بن الحسين بن علي المسعودي)

For names and any other text in a script written right to left (Arabic, Hebrew etc), no special care need be taken over the character ordering in the data file: the first character of an RTL name occurs immediately following the > of <PersonName> in the file, even though when the ONIX data is printed or viewed on screen, the first character of the name appears immediately before the < of </PersonName>. So for שפרה הורן (Shifra Horn), the order of characters in the ONIX message is <PersonName>שפרה הורן</PersonName>. Those characters ש, פ, ר, ה etc are then displayed from right to left as שפרה הורן

Author names (and product titles) often have to be presented in alphabetical order, and <PersonNameInverted> or the various parts of a structured name usually facilitate this. But sorting text in a variety of scripts – and for text other than names – languages, and determining the correct ‘alphabetical’ order is dependent on the locale and expected user experience when the text is displayed. There is no single, canonical order: Ö sorts after Z in a Swedish context, but immediately follows O words in a German context, and in a English language context, O and Ö are likely to be intermixed. A Swedish reader will expect a name beginning with Ö to appear after Z in a list even if the name is that of a German author. The sort order is not entirely intrinsic to the data itself, is not purely a feature of language or script, and in particular it’s almost never exactly the same as the numerical order of Unicode characters. Sort order is a feature of the user interface. Even converting between lower and upper case prior to sorting can be problematic – in Turkish, the upper case version of i is İ (with a dot above), and the lower case version of I is ı (a dotless i). For more on sorting, see the Unicode Collation Algorithm specification and the Common Locale Data Repository.

For non-alphabetic writing systems such as Chinese or Japanese, the collationkey attribute is important, and it should be used to provide phonetic or other sort order information for machine processing.

providing a sort order in Japanese
using Reference names
`<PersonNameInverted collationkey="むらかみはるき">村上春樹</PersonNameInverted>`

using Short tags
`<b037 collationkey="むらかみはるき">村上春樹</b037>`

Japanese personal names are written in Kanji and are conventionally sorted according to their phonetic reading. The name may be spelled out phonetically using Hiragana or Katakana characters. But many Kanji characters have multiple readings, so 彰 can be read as しよう (‘Shō’) or あきら (‘Akira’), and the chosen reading affects the sort order. The collationkey attribute provides the correct phonetic rendering. (It is also the case that one phonetic reading such as あきら (‘Akira’) may have many Kanji renderings including 明 or 晃). For Chinese names, Pinyin or Zhuyin phonetics would be used.

In cases where the reading of the name needs to be clarified for human readers, rather than for automated sorting, the phonetic information is provided in a ruby gloss. A gloss can be incorporated using either the XHTML <ruby> markup element – in ONIX data elements that allow XHTML – or using Unicode interlinear annotation delimiters in data elements that do not. Where phonetics are needed for both human reading and for sorting purposes, both a collationkey and a ruby text should be included.

<b037 collationkey="むらかみはるき">￹村上春樹￺むらかみはるき￻</b037>

This uses Unicode interlinear annotation delimiters (￹, ￺ and ￻) to separate the Kanji from the ruby text Hiragana, as the <PersonNameInverted> element cannot use XHTML <ruby> markup. In other data elements where it is allowed, the equivalent XHTML markup must be used. The name above should be displayed as 村上春樹むらかみはるき.

Unicode interlinear annotation delimiters cannot be rendered on-screen unless an application provides specific support for them. In order to display the name with its gloss in a web browser using XHTML 1.1 (or non-standard HTML4), an application might:

replace ￹ with ‘<ruby><rb>’;
change ￺ to ‘</rb><rp> (</rp><rt>’;
and substitute ‘</rt><rp>)</rp>’ for ‘￻’.

For HTML5, correct practice would be to omit the <rb> and </rb> tags. However, this will prevent validation of the ONIX XML – implementation of <ruby> in ONIX is based on XHTML 1.1, and the <rb> tag is required.

In summary, there are three ways of incorporating phonetic glosses into ONIX data:

if the gloss is intended to be used for automated sorting purposes;
- method 1 – use the collationkey attribute;
- the attribute can only be included on elements that are likely to be used for sorting;
if the gloss is intended to be used for display purposes, either:
- method 2 – use <ruby> where XHTML markup is allowed within the ONIX data element; or
- method 3 – use Unicode interlinear annotation delimiters where XHTML is not allowed;
- glosses for display can be incorporated into any textual data element.

Occasionally, as in the example above, a single data element may need a gloss provided as an attribute for sorting, and as a display gloss.

P.7.11 Titles before names

Parts of names in bold would be carried in this element.

Pope Benedict XVI
His Holiness the Dalai Lama
HRH Prince Charles
Dame Ngaio Marsh
General Sir Peter de la Billière

P.7.12 Names before key names

Dame Ngaio Marsh
General Sir Peter de la Billière
Henriette d’Angeville
Gabriel Garcia Márquez
Robert Louis Stephenson
Megan Lloyd George
Фёдор Достоевский	(Fyodor Dostoyevsky)
Haruki Murakami	(when name is Westernized)
علاء الأسواني	(Alaa al-Aswany)
שפרה הורן	(Shifra Horn)

P.7.13 Prefix to key names

His Holiness the Dalai Lama
General Sir Peter de la Billière
Henriette d’Angeville
Máire ó Conchobhair
علاء ال أسواني	(Alaa Al Aswany)
Eric van Lustbader
Melissa de la Cruz

P.7.14 Key names

All names presented in fully-structured style must have a Key name – this is the part of the name that is used first for collation purposes. Note that although names are conventionally sorted using the family or inherited name, there are exceptions for names that include titles, where for example a given name (Charles), a taken name (Benedict) or a title (Dalai Lama) may be used as the key, and for other names that do not have a family component (such as Icelandic names, which consist of given name and patronymic). When constructing a structured name, always start with the key name element and arrange other parts of the name around it.

Pope Benedict XVI
His Holiness the Dalai Lama
HRH Prince Charles
Dame Ngaio Marsh
General Sir Peter de la Billière
Henriette d’Angeville
Mary O’Connor
Máire ó Conchobhair
Gabriel Garcia Márquez
Robert Louis Stephenson
Megan Lloyd George
Фёдор Достоевский	(Fyodor Dostoyevsky)
Haruki Murakami	(Westernized name order)
村上春樹	(Haruki Murakami, name order not Westernized)
علاء ال أسواني	(Alaa Al Aswany)
שפרה הורן	(Shifra Horn)
Eric van Lustbader
Melissa de la Cruz
Madonna
Björk Guðmundsdóttir	(given name is key name)
प्रेमचंद	(Premchand)
Luo Guanzhong	(罗贯中, name order not Westernized)
Petőfi Sándor	(Hungarian, name order not Westernized)

Exactly what constitutes the key name varies according to the culture from which the name arises. Prefixes like de, ó or van often get incorporated into the key name as the name passes from its original culture into another, so for example Máire ó Conchobhair becomes Mary O’Connor, the Dutch name ‘de Groot’ becomes ‘De Groot’ or the French name ‘de la Mare’ becomes the English ‘Delamere’. But this is a cultural shift, not a matter of language, and many also choose to retain their name structure (for example, English poet Walter de la Mare).

: Except with names such as Madonna or Premchand which have no other parts, if <KeyNames> is used, all other parts of the name should be included in the relevant elements – <NamesBeforeKey>, <PrefixToKey> and so on. <KeyNames> is not intended merely to indicate which part of the name in <PersonName> is to be used for sorting.

P.7.15 Names after key names

村上春樹	(Haruki Murakami, name order not Westernized)
Björk Guðmundsdóttir	(patronymic follows key name)
Luo Guanzhong	(罗贯中, name order not Westernized)
Petőfi Sándor	(name order not Westernized)

P.7.16 Suffix after key names

This element is only used for simple suffixes such as ‘Jr.’, ‘fils’ or ‘XVI’.

P.7.17 Qualifications and honors after names

This element is used to list qualifications (‘PhD’, ‘MD’ etc), and for honors and memberships (‘OBE’, ‘TD’, ‘FRCS’ etc).

P.7.18 Titles after names

This element is used to list titles and honorifics that follow a person’s names. Note that often, there is some choice about how names that include titles may be presented:

King Philip II of Spain

Philip II, King of Spain

Presentation of primary names should follow the form used on the product. A publisher may provide an alternative name when another form is more familiar.

P.7.19, P.7.20 Corporate contributor names

Corporate names should be carried in <CorporateName>, unless they begin with a prefix that should be ignored for collation purposes – in which case it is best practice to (also) include <CorporateNameInverted>. If there is a prefix, there is some value in providing both forms (as with personal names). Corporate names should not include suffixes such as ‘Inc’, ‘SA’ or ‘Ltd’, unless they are used on the product itself.

no prefix (on the product)
`<CorporateName>World Health Organization</CorporateName>`

name with a prefix
`<CorporateName>The editors of Rolling Stone Magazine</CorporateName>`
`<CorporateNameInverted>Rolling Stone Magazine, The editors of</CorporateNameInverted>`

Alternative name composite

The <AlternativeName> composite provides a way of delivering another name (or an alternative form of the same name) for a contributor. Potential uses might include providing a previous name (where the contributor’s name has changed by marriage, for example, or the corporation has undergone a rebranding), an authority-controlled or otherwise standardized form of a name where the name on the actual product is presented in an unusual form, or where both a real name and a pseudonym are involved. Such alternative names can provide important search term matches, aiding discovery of the product online or within retailer systems.

While the primary contributor name (in P.7.9 to P.7.20) should always be the name as it appears on the product, the alternative name may be one of several types. It is mandatory to specify a <NameType> within <AlternativeName>. In contrast, the P.7.5 <NameType> element is not required (and is usually omitted) for the primary name.

The remainder of <AlternativeName> is identical to the data elements that carry the primary name, and similar best practice applies. Note that <AlternativeName> can include an alternative <NameIdentifier> composite, as well as any of the data elements holding the fully-structured, inverted or normal contributor name.

In general, each <AlternativeName> composite should contain a name with a different name type. However, it is also possible to provide transliterations of a name in two repeats with the same name type, or a single <AlternativeName> may contain a transliteration of the primary name. Transliterations are often useful where the recipient of the data may not be able to cope with the characters in the native script – for example selling a book in Russian, with a Cyrillic author name, in a country where many data recipients might only be able to deal with Latin characters. It is obviously preferable to supply the primary name in Cyrillic, for those recipients that can make use of it, and a Latin transliteration for those that cannot.

transliterated version of the primary name
using Reference names
`<Contributor>`
`<ContributorRole>A01</ContributorRole>`
`<PersonName>다니엘 돔샤이트-베르크</PersonName>`
`<PersonNameInverted>돔샤이트-베르크, 다니엘</PersonNameInverted>`
`<AlternativeName>`
`<NameType>05</NameType>`
`<PersonName textscript="Latn">Daniel Domscheit-Berg</PersonName>`
`<PersonNameInverted textscript="Latn">Domscheit-Berg, Daniel</PersonNameInverted>`
`</AlternativeName>`
`</Contributor>`

using Short tags
`<contributor>`
`<b035>A01</b035>`	Written by
`<b036>다니엘 돔샤이트-베르크</b036>`	Hangul script used on the book
`<b037>돔샤이트-베르크, 다니엘</b037>`
`<alternativename>`
`<x414>05</x414>`	Transliteration of primary name
`<b036 textscript="Latn">Daniel Domscheit-Berg</b036>`	Latin script
`<b037 textscript="Latn">Domscheit-Berg, Daniel</b037>`
`</alternativename>`
`</contributor>`

ONIX takes the pragmatic view that while most textual metadata can be expressed in different languages, organizational or contributor names are not ‘in’ a particular language. However, names can be expressed in different scripts – فيودور دوستويفسكي and Фёдор Достоевский and Fyodor Dostoyevsky. So while <BiographicalNote> may carry a language attribute (see below), <PersonName> carries a textscript attribute instead.

Although in this particular case the author (Daniel Domscheit-Berg) is German by nationality, the book is in the Korean language, the majority of the metadata is in Korean, and the author name is listed on the book in Hangul (Korean script). Thus the primary name is in Hangul, and the name is also provided transliterated into Latin script in the <AlternativeName> composite. By contrast, a German or English language copy of the book would list the primary author’s name in Latin script, and if that copy were for sale in Korea, the transliteration into Hangul might be given: for this book, the Hangul and Latin versions of the name would be switched around.

Provision of transliterated names is quite different from provision of phonetic information for sorting (which would use the collationkey attribute), or provision of ruby glosses to disambiguate the reading of a name (which would use Unicode interlinear annotation delimiters): see the notes on Personal names in Group P.7.

Contributor date composite

Birth and death dates are often use in libraries to distinguish between authors of the same name. They are not typically made explicit in book trade metadata, but equivalent information may be incoporated into any biographical notes. In general, providing a name identifier such as an ISNI is better for disambiguation purposes.

Jane Austen (1775–1817)
using Reference names
`<ContributorDate>`
`<ContributorDateRole>50</ContributorDateRole>`
`<Date dateformat="05">1775</Date>`
`</ContributorDate>`
`<ContributorDate>`
`<ContributorDateRole>51</ContributorDateRole>`
`<Date>18170717</Date>`
`</ContributorDate>`

using Short tags
`<contributordate>`
`<x417>50</x417>`	Born…
`<b306 dateformat="05">1775</b306>`	Format is YYYY
`</contributordate>`
`<contributordate>`
`<x417>51</x417>`	Died…
`<b306>18170717</b306>`	Default format is YYYYMMDD
`</contributordate>`

Professional affiliation composite

Affiliations – effectively a job title and organization name – are used when the professional position of the author is important to the market positioning of the product – for example to emphasize the credentials of academic author, or the credibility of any other expert.

multiple affiliations for an academic author
using Reference names
`<ProfessionalAffiliation>`
`<ProfessionalPosition>Emeritus Professor of Social Geography</ProfessionalPosition>`
`<Affiliation>School of Geography and the Environment, University of Oxford</Affiliation>`
`</ProfessionalAffiliation>`
`<ProfessionalAffiliation>`
`<ProfessionalPosition>Professor of Social Geography</ProfessionalPosition>`
`<Affiliation>Institute for Social Change, Manchester University</Affiliation>`
`</ProfessionalAffiliation>`

using Short tags
`<professionalaffiliation>`
`<b045>Emeritus Professor of Social Geography</b045>`
`<b046>School of Geography and the Environment, University of Oxford</b046>`
`</professionalaffiliation>`
`<professionalaffiliation>`
`<b045>Professor of Social Geography</b045>`
`<b046>Institute for Social Change, Manchester University</b046>`
`</professionalaffiliation>`

P.7.42 Biographical note

Any named contributor – personal or corporate – may be associated with a short biography. Typically these are relatively short, perhaps no more than 200 to 400 words – around 1500–3000 characters. Although there is no specified maximum, a practical upper limit of perhaps 5000 characters is reasonable for senders. The <BiographicalNote> element is best used when there are a small number of contributors (say three or fewer). A single combined biography for multiple contributors is best provided in the <TextContent> composite in Group P.14.

Simple biographical notes can be provided as plain text. However, because of the differing XML treatment of white space characters (including tabs, line feeds and carriage returns) among different XML parsers and in different databases, multi-paragraph text cannot reliably be delivered into a recipient’s system this way. For this and other reasons, <BiographicalNote> and other ONIX data elements can accept not only plain text but also text with embedded XHTML markup. Embedded markup is the only reliable way to deliver multi-line or multi-paragraph text.

By default, XML data is processed by ‘normalizing’ whitespace characters – spaces, tabs, line breaks and so on – so they are all treated as single spaces. Leading and trailing whitespace is also often ‘trimmed’. ONIX data should be processed this way too (ie with the the xml:space attribute set to its default value). These:

<BiographicalNote> Umberto Eco_↩ is a novelist.</BiographicalNote>
<BiographicalNote> Umberto Eco is a novelist.</BiographicalNote>
<BiographicalNote>Umberto Eco is a novelist.</BiographicalNote>

(where _↩ is an explicit new line in the data) are equivalent. Data senders should aim to send only the third option, and recipients should normalize whitespace characters they receive.

This behaviour applies to all ONIX tags, not just to <BiographicalNote>. But where a tag is intended to allow multiple lines or paragraphs of text, embedded markup provides the solution.

If you have only plain text, and want to include multi-paragraph biographies, then you must include some markup within the data element. The simplest process would be to:

prefix the text of the biographical note with ‘<p>’ and suffix it with ‘</p>’;
replace any paragraph breaks with ‘</p><p>’;
add the textformat attribute with value 05.

adding minimal XHTML markup
using Reference names – original plain text
`<BiographicalNote>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists. As well as novels, he also writes children’s books and academic works.</BiographicalNote>`
preferred alternative including XHTML markup
`<BiographicalNote textformat="05"><p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></BiographicalNote>`

using Short tags – original plain text
`<b044>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists. As well as novels, he also writes children’s books and academic works.</b044>`	paragraph breaks are likely to be lost
preferred alternative using XHTML markup
`<b044 textformat="05"><p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></b044>`	XHTML markup should ensure paragraphs remain separate as data is processed by the recipient

XHTML markup is strongly preferred to HTML, as it can be properly validated using the ONIX for Books schemas.

But not all XHTML markup tags are usable. First, there are limitations on what XHTML tags can be used within ONIX. Second, recipients will often strip out some tags, or might even ignore the supplied text altogether because they are reluctant to include the supplied tags on their website (even though they might be technically valid). In practice, the following should be usable without problems:

<p> and <br /> for paragraphs and newlines;
<em>, <strong>, <i>, <b>, <sub> and <sup>;
<ul>, <ol> and <li> for unordered and ordered lists;
<dl>, <dt> and <dd> for description lists;
<ruby>, <rb>, <rt> and <rp> for glosses;
<address>, <abbr>, <small>, <q>, <cite>, <code>, <samp>, <var> and <dfn> for limited ‘semantic’ markup of text, plus <rbc> and <rtc> for complex glosses, should be okay, but it is good practice to avoid them;
- this list is not exhaustive. A complete list is given in the Appendix.

Headings, tables, <div> and <span> containers, image tags, links and imagemaps using the <a> or <map> tags, and attributes like style are also technically valid within the ONIX schema, but will often cause problems with recipients. Avoid them.

Forms, embedded objects, scripts, any tags that can only exist in the <head> section (eg <title>), any tags with event attributes like onclick and – critically – named character entities like ‘ö’ are valid in XHTML itself, but cannot be used in XHTML embedded within ONIX.

The ‘top level’ XHTML elements must be block-level elements:

not valid – no outer block-level element
`<BiographicalNote textformat="05">some text</BiographicalNote>`
`<BiographicalNote textformat="05"><strong>some text</strong></BiographicalNote>`

valid – <p> and <ul> are both block-level
`<BiographicalNote textformat="05"><p>some text</p></BiographicalNote>`
`<BiographicalNote textformat="05"><p>some text</p><ul><li>a list</li></ul></BiographicalNote>`

To be ultra-cautious, stick to the very simplest tags:

<p>, <br />
<b> and <i>, <strong> and <em>
<ul>, <ol> and <li>
plus possibly <dl>, <dt>, <dd>
<sub> and <sup>
and <ruby>, <rb>, <rt> and <rp> if required

…of which <p>, <ul>, <ol> and <dl> are block-level.

Where markup is used in an element with a length limit, it is included in any character count.

While embedding XHTML is the preferred option, it is not the only method of embedding markup in ONIX data elements. If it is impossible to use XHTML for any reason, then ordinary HTML can be included in one of two ways:

embedding HTML markup
using Reference names – HTML in CDATA option
`<BiographicalNote textformat="02"><![CDATA[<p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.<p>As well as novels, he also writes children’s books and academic works.</p>]]></BiographicalNote>`
escaped HTML option
`<BiographicalNote textformat="02"><p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.<p>As well as novels, he also writes children’s books and academic works.</p></BiographicalNote>`

using Short tags – HTML in CDATA option
`<b044 textformat="02"><![CDATA[<p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.<p>As well as novels, he also writes children’s books and academic works.</p>]]></b044>`	Enclose HTML within CDATA
escaped HTML option
`<b044 textformat="02"><p>Umberto Eco, professor of semiotics at the University of Bologna, and author of ‘The Name Of The Rose’ and ‘Foucault’s Pendulum’, is one of the world’s bestselling novelists.<p>As well as novels, he also writes children’s books and academic works.</p></b044>`	Replace < character with < (optionally, also replace > with >)

The CDATA method is strongly preferred over escaped HTML, though neither is a best practice and XHTML (without either CDATA or escaping of the markup) is preferred to both. HTML markup should be limited to a similar set of simple tags as XHTML – and also limited to those data elements where XHTML is an option. CDATA should never be used except to embed HTML markup.

Although they are not recommended, named character entities like … or ö should work within HTML text inside CDATA. They are not valid within ‘ordinary’ ONIX 3.0 data, but may be used within HTML (and of course, numerical character references like … or ö will also work).

For the CDATA method, use the named entity or numerical reference as normal.

For the escaped HTML option, named entities are not valid – use numerical references instead.

For the escaped HTML option, it might appear that a named entity such as … or numerical reference like … might require the ampersand to be escaped – just as the < character in the HTML markup is escaped to <, the ampersand character in a named character entity or numerical reference could also be escaped, so a single ellipsis becomes &hellip; or &#x2026;. This is sometimes termed ‘double-escaping’, and it is strongly discouraged. Only the < character in the HTML markup needs do be modified (and you might also replace < that is not part of the HTML markup by <).

If using named character entities or numerical references in this manner (ie escaped within embedded HTML markup), ensure proper end-to-end testing with each ONIX recipient. The likelihood of confusion and error with escaped characters and double-escaped named character entities and numerical references is one reason why the CDATA method is preferred in ONIX 3.0. (In earlier versions of ONIX, the CDATA and escaped HTML methods were equally acceptable.)

Within HTML (but not within XHTML), the unescaped & character is valid. However, it is strongly recommended that the named entity & is used instead, for both the CDATA and escaped HTML options. Using an unescaped & character in escaped HTML (ie without CDATA) will prevent the ONIX message validating.

Like many textual data elements, the <BiographicalNote> data element is repeatable in order that the same text can be carried in multiple languages. Of course, in most cases, textual metadata is provided in the same language used in the book. Parallel metadata in multiple languages might be required in territories where multiple languages are in everyday use (for example, Switzerland), in language learning and gift giving scenarios where a book might be purchased by someone who cannot read the language used in the book itself, and in cases where the product itself contains parallel text. If parallel textual metadata is provided, then each repeat of <BiographicalNote> must carry a language attribute. This allows a recipient to either accept and process the multiple languages, or to select the single language that is most appropriate for their needs.

providing text in parallel languages
using Reference names
`<BiographicalNote language="eng" textformat="05"><p><strong>Umberto Eco</strong>, professor of semiotics at the University of Bologna, and author of <em>The Name Of The Rose</em> and <em>Foucault’s Pendulum</em>, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></BiographicalNote>`
`<BiographicalNote language="ita" textformat="05"><p><strong>Umberto Eco</strong>, professore di semiotica all’Università di Bologna e autore di <em>Il nome della rosa</em> e <em>Il pendolo di Foucault</em>, è uno dei romanzieri più venduto al mondo.</p><p>Così come romanzi, lui scrive anche libri per bambini e opere accademici.</p></BiographicalNote>`

using Short tags
`<b044 language="eng" textformat="05"><p><strong>Umberto Eco</strong>, professor of semiotics at the University of Bologna, and author of <em>The Name Of The Rose</em> and <em>Foucault’s Pendulum</em>, is one of the world’s bestselling novelists.</p><p>As well as novels, he also writes children’s books and academic works.</p></b044>`
`<b044 language="ita" textformat="05"><p><strong>Umberto Eco</strong>, professore di semiotica all’Università di Bologna e autore di <em>Il nome della rosa</em> e <em>Il pendolo di Foucault</em>, è uno dei romanzieri più venduto al mondo.</p><p>Così come romanzi, lui scrive anche libri per bambini e opere accademici.</p></b044>`

P.7.47 Unnamed person(s)

A product that has no specific named contributors may still have unnamed contributors – they may be unknown, anonymous, or indeed artificial – for example, a book may be written by ‘Anonymous’, and an audiobook or DAISY title using synthesized but prerecorded speech should carry an <UnnamedPersons> element with a contributor role code indicating ‘read by’.

Unnamed contributors can also be combined with named contributors, and this is relatively common when the number of named contributors is limited by editorial policy – for example, if only three names are allowed, the fourth and fifth may be unnamed, and <UnnamedPersons> would carry the code value 03 (‘et al’). Note that in this case, a single <UnnamedPersons> composite stands for multiple contributors. In general, an unnamed et al contributor should be the last contributor as defined by the <SequenceNumber>, or at least the last contributor with a particular role (where other, named contributors with different roles follow). In very rare cases, a product might have more than one <UnnamedPersons> element, in different repeats of <Contributor> with different contributor roles.

audiobook read by a synthesized voice
using Reference names
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A01</ContributorRole>`
`<PersonNameInverted>Angeville, Henriette d’</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>2</SequenceNumber>`
`<ContributorRole>E07</ContributorRole>`
`<UnnamedPersons>06</UnnamedPersons>`
`</Contributor>`

using Short tags
`<contributor>`
`<b034>1</b034>`	First contributor
`<b035>A01</b035>`	Written by
`<b037>Angeville, Henriette d’</b037>`
`</contributor>`
`<contributor>`
`<b034>2</b034>`	Second contributor
`<b035>E07</b035>`	Read by
`<b249>06</b249>`	Female synthesized voice
`</contributor>`

multiple contributors, with *et al*
using Reference names
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>B01</ContributorRole>`
`<PersonNameInverted>Jones, Steve</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>2</SequenceNumber>`
`<ContributorRole>B01</ContributorRole>`
`<PersonNameInverted>Martin, Robert</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>3</SequenceNumber>`
`<ContributorRole>Z98</ContributorRole>`
`<UnnamedPersons>03</UnnamedPersons>`
`</Contributor>`
`<ContributorStatement textformat="05"><p>Edited by Steve Jones, Robert Martin <em>et al</em></p></ContributorStatement>`

using Short tags
`<contributor>`
`<b034>1</b034>`	First contributor
`<b035>B01</b035>`	Edited by
`<b037>Jones, Steve</b037>`
`</contributor>`
`<contributor>`
`<b034>2</b034>`	Second contributor
`<b035>B01</b035>`	Edited by
`<b037>Martin, Robert</b037>`
`</contributor>`
`<contributor>`
`<b034>3</b034>`	Remaining contributors
`<b035>Z98</b035>`	(Various roles)
`<b249>03</b249>`	et al
`</contributor>`
`<b049 textformat="05"><p>Edited by Steve Jones, Robert Martin <em>et al</em></p></b049>`

Compare this example with the previous multiple contributor example.

This data element may also be used with products that are compilations or anthologies, where the contributors may be described as ‘Various’ – and in this case, repeats of the <ContentItem> composite in Group P.18 may be used to provide more information on the authorship of each section.

Contributor place composite

Although not a core part of global best practice, the <ContributorPlace> composite is a key part of some national schemes to promote local authors. It should be included, for example, on products sold in Canada where a contributor is a Canadian citizen. Retailers value it – and particularly <LocationName> – as a way of supporting ‘local author’ promotions.

Although the ONIX schema allows use of both Country and Region codes together, it is strongly recommended that only one or the other is used in a particular <ContributorPlace> composite. Region codes already include the relevant country designation. A location name cannot be used without also including either a country or region code.

designating a contributor as Canadian
using Reference names
`<ContributorPlace>`
`<ContributorPlaceRelator>08</ContributorPlaceRelator>`
`<CountryCode>CA</CountryCode>`
`</ContributorPlace>`

using Short tags, also indicating residency
`<contributorplace>`
`<x418>08</x418>`	Citizen of
`<b251>CA</b251>`	Canada
`</contributorplace>`
`<contributorplace>`
`<x418>04</x418>`	Currently lives in
`<b398>CA-NL</b398>`	Newfoundland and Labrador
`<j349>Stephenville</j349>`	and specifically, in Stephenville
`</contributorplace>`

More detailed information about where a contributor lives may also be incorporated into <BiographicalNote>, but the structured information in <ContributorPlace> can be particularly useful.

P.7.51 Contributor statement

This data element should be used to carry readable text showing how the contributor’s names and roles should be displayed. This is particularly critical when a simple concatenation of the contributor’s roles and names would not give satisfactory results – for example when one contributor has multiple roles, or when for example a familial relationship between two contributors may alter how their names are presented.

The contributor statement should not include any collection-level contributors listed separately in Group P.5 (although best practice is to avoid collection-level contributors altogether, and to include all contributors in Group P.7).

<ContributorStatement>Written and illustrated by Colin and Jacqui Hawkins. Series edited by Cliff Moon</ContributorStatement>

<ContributorStatement>By Richard and Alastair Fitter, illustrated by Marjorie Blamey</ContributorStatement>

Recipients of ONIX records that contain this element should use the supplied contributor statement for display, while using the names supplied in the <Contributor> composite for search, collation, collocation and other processing. The same applies to the equivalent <ContributorStatement> within Group P.5, though that should only be used where specific national practice requires contributors such as series editors to be identified at collection level.

In common with many other textual data elements, <ContributorStatement> is repeatable if supplying parallel text in multiple languages, and may also include XHTML markup.

P.7.52 “No authorship” indicator

This element should be used to give a positive indication that there are no contributors, either named or unnamed, in either P.7 or in P.5 where contributors to a collection can be listed.

This is one of the few ONIX for Books data elements that are defined as empty elements. The ‘self-closing’ XML syntax should always be used (ie <NoContributor/>, not <NoContributor></NoContributor>).

P.8 Conference

If the product is not linked to a particular conference, this Group can be ignored entirely. But if the ONIX record describes a product such as the proceedings of a conference, then the Group P.8 should be used to specify details about the conference – the name, theme, date and so on. These details may be important for certain publishers, particularly in the academic and technical sectors, and for library cataloging.

In many cases, the conference details may repeat information that is also included in the title of the product.

Conference composite

Proceedings of the Frontiers in Science Education Research Conference
using Reference names
`<Conference>`
`<ConferenceName>Frontiers in Science Education Research Conference</ConferenceName>`
`<ConferenceAcronym>FISER ’09</ConferenceAcronym>`
`<ConferenceDate dateformat="06">2009032220090324</ConferenceDate>`
`</Conference>`

using Short tags
`<conference>`
`<b052>Frontiers in Science Education Research Conference</b052>`
`<b341>FISER ’09</b341>`
`<b054 dateformat="06">2009032220090324</b054>`	22–24 March 2009
`</conference>`

P.9 Edition

An ‘edition’ generally means all copies of a book that contain the same content, usually published by the same publisher. More loosely, an ‘edition’ may be a product produced for a specific sales channel or market segment – a book club edition, library edition, large print edition and so on. So different editions may be distinguished by their content (by the addition, revision or removal of material), or more occasionally by some other aspect of their product form or nature.

Group P.9 is used to specify three different sorts of edition information:

various edition types (of the same work);
- facsimile, special or prebound editions, where editions generally imply little or no change of content, but emphasise some other aspect of the product that differs from a previous or parallel version of the same work;
- Braille, large print, digital original, limited (numbered) or media tie-in editions, where the edition type is simply a feature or attribute somewhat related to the product form, and does not necessarily imply the existence of any previous or parallel version – though where such other versions do exist, there is little or no change of content;
- other distinctions that are merely differences of product form are not distinct ‘editions’: metadata that differentiates a ‘hardback edition’ from a ‘paperback edition’ lies within Group P.3 Product form;
various edition types (which imply a different but closely-related work);
- abridged, illustrated, annotated, enlarged, revised, enhanced, student and teacher’s editions, where editions generally do imply some material difference in content between this and some previous or parallel product;
- omnibus (combined) editions are works in their own right, derived from multiple ‘parent works’;
- reprints or reissues that incorporate only minor corrections are not new editions;
ordinal numbered editions;
- in <EditionNumber>, second, third edition etc – where editions imply significant revisions to the content of a previous product (and are always different works);
- in <EditionVersionNumber>, minor revisions (of a digital product) that denote mostly technical fixes or minor updates that do not significantly revise the content.

The historical meaning of ‘edition’ (which is synonymous with ‘impression’ or ‘print run’, and which is still sometimes used in book collecting – as in ‘a valuable first edition’) is generally not used in ONIX, as ONIX is not normally concerned with individual impressions or manufacturing batches (the exceptions: ‘limited edition’, and sometimes also minor updates in <EditionVersionNumber>).

Group P.9 is also used to convey detailed information about religious texts.

Abridged edition
using Reference names
`<EditionType>ABR</EditionType>`

using Short tags
`<x419>ABR</x419>`

IVth edition
using Reference names
`<EditionNumber>4</EditionNumber>`
`<EditionStatement>IVth edition</EditionStatement>`

using Short tags
`<b057>4</b057>`
`<b058>IVth edition</b058>`

Centenary edition
using Reference names
`<EditionType>SPE</EditionType>`
`<EditionStatement language="eng">Centenary edition</EditionStatement>`
`<EditionStatement language="fre">Édition du centenaire</EditionStatement>`

using Short tags
`<x419>SPE</x419>`
`<b058 language="eng">Centenary edition</b058>`	Parallel text in English
`<b058 language="fre">Édition du centenaire</b058>`	and French

Facsimile first edition
using Reference names
`<EditionType>FAC</EditionType>`
`<EditionNumber>1</EditionNumber>`

using Short tags
`<x419>FAC</x419>`
`<b057>1</b057>`

Limited and numbered edition
using Reference names
`<EditionType>NUM</EditionType>`
`<EditionStatement>Limited edition of 100 copies, individually numbered and signed by the author</EditionStatement>`

using Short tags
`<x419>NUM</x419>`
`<b058>Limited edition of 100 copies, individually numbered and signed by the author</b058>`

Use code SPE for a limited and/or signed, but unnumbered, edition.

P.9.1 Edition type code

Most edition type codes from List 21 are self-explanatory.

Codes STU (Student) and TCH (Teacher) should be used for two editions of a school or college textbooks, where only the teacher’s edition contains model answers to questions and/or other notes for the teacher. Code SCH should be used where there is a special school or college edition of a book that is different from the ‘normal’ trade edition – for example, a school version of a work of classic literature that is separate from the normal version might have extra footnotes or annotations, or it may be exactly the same as the main edition but have a lower price and some limitations on how it can be sold (eg may only be sold direct to schools or through education sales channels).

Use codes UBR (Unabridged), ILL (Illustrated) or ENH (Enhanced, for digital products) only to avoid doubt, when an abridged, non-illustrated or ‘un-enhanced’ edition also exists – or when it might be expected to exist. For example, because many audiobooks on CD are abridged, an unabridged product may carry the UBR Edition type code, even when no abridged version is available. Note that an abridged version must carry the ABR code. Conversely, DGO (digital original) should be used to indicate that no physical counterpart of a digital product exists (because the normal expectation is that a physical version does exist), or where a physical counterpart does exist, that the digital version was published a significant time before the physical version (because the normal expectation is that the physical and digital versions were published together or that the physical version came first).

: It is a common error to use DGO to indicate ‘digital exclusive’. ‘Digital original’ is a permanent feature of a product – if the digital version was published before a paper version, it remains the original, but is not digital exclusive. For products that are true digital exclusives, see Group P.14. and <TextType> code 21.

Use code SPE (Special edition) when no more specific code applies, and use <EditionStatement> to describe the nature of the edition.

Codes NED (New edition) and REV (Revised) should be used with care, and ideally only when editions are not numbered. If combined with an <EditionNumber>, then the meaning is somewhat unclear: a ‘third revised edition’ is not the same as a ‘revised third edition’. Where such a usage is unavoidable – that is, when the third edition has been revised, but not revised enough to justify naming it the fourth edition, and a distinction needs to be drawn with the unrevised third edition – always include an <EditionStatement> that makes the meaning clear – for example ‘Updated version of 3rd Edition’. When the ‘third revised edition’ simply means the second edition has been revised to create the third, do not use an unnecessary Edition type code like NED or REV – use only <EditionNumber> 3.

Note that <EditionType> is repeatable, to describe an edition that is, as an example, both Abridged (code ABR) and Large type (LTE).

P.9.2 Edition number

This data element should be included (as an integer, 2, 3, 4…) even when editions are numbered using Roman numerals (II, III, IV…) on the product itself. If Roman numerals are used on the product, use a normal integer in <EditionNumber>, and include the Roman edition number in <EditionStatement>.

It is best practice not to include the Edition number for ‘first’ editions, unless this is a particular feature of a product produced after a subsequent edition has been released, for example with a facsimile edition, when the first edition and a later edition are both orderable or available at the same time, or when using <EditionVersionNumber>. Thus occasionally, it may be necessary to populate <EditionNumber> with 1.

Edition number may also be used to carry a version number for a software product, where for example numbered major revisions of the software are released and the number is not considered part of the title. Minor revisions of the software version can also be carried in <EditionVersionNumber> if required.

using Reference names
`<EditionNumber>3</EditionNumber>`
`<EditionVersionNumber>2</EditionVersionNumber>`

using short tags
`<b057>3</b057>`	v3.2 of a software product, or
`<b217>2</b217>`	second minor update of a 3rd edition of a book

An e-book publisher may choose to maintain a two- or three-level version numbering scheme, such as is common with software products. A change of edition number would indicate a major revision of the content – and a change of the product and work identifiers – as with the first edition followed by the second edition of a conventional book. Within a given edition, smaller updates can be designated using the edition version number, so a version 3.0.2 is the second minor update of the Third edition. Typically, minor updates would contain only fixes to typos in the text or small technical corrections in the e-book files (eg to fix layout errors). For a version 3.0.2, the <EditionNumber> would be 3 and the <EditionVersionNumber> would be 0.2. A version 3.1 is a more significant update of the Third edition, with some new content or added functionality – more significant than just corrections, though not significant enough to trigger a change of the Edition number and of the product identifiers. Some e-book vendors may choose to push these smaller updates out to previous purchasers automatically, whereas other vendors make them available to previous purchasers if they specifically choose to re-download.

Occasionally – in the case of a minor update to a first or unnumbered edition – the use of <EditionVersionNumber> requires the use of <EditionNumber> 1, where normally edition 1 would be omitted. This serves to emphasize that what has been updated does not constitute a new edition.

P.9.4 Edition statement

An <EditionStatement> element should be included whenever a simple concatenation of the edition type and number is not sufficient for display purposes: it should be complete in itself and incorporate the edition type and number information, and should not occur if both <EditionType> and <EditionNumber> are omitted (it augments rather than replaces them). When provided, recipients should use the <EditionStatement> for display, while using any edition type or number for search and collation purposes.

The Edition statement may be repeated in multiple, parallel languages if required. If it is repeated, the language attribute much be included with each repeat.

P.9.5 “No edition” indicator

This element should be included whenever there is no other edition information. It is one of the few ONIX data elements that is defined as an empty element.

P.10 Language

Group P.10 consists solely of the <Language> composite.

Language composite

For books in a single language, this is entirely straightforward – the <Language> composite specifies the language, and its ‘role’ (language of the text, code 01 from List 22), and for translated works, a second repeat of the composite specifies the original language from which the text was translated.

If a book contains only a few individual phrases, small passages or quotations in a second language, then that second language should not be listed in a <Language> composite.

But if a product contains significant content in more than one language (eg a bilingual dictionary that can be used for translation ‘both ways’, or a book with parallel texts in two or more languages), then separate repeats of the <Language> composite with <LanguageRole> code 01 (Language of text) are appropriate. For example, a full bilingual dictionary with Spanish-to-English and English-to-Spanish sections would have two <Language> composites, specifying <LanguageRole> code 01 for both English and Spanish languages. It would be equally useful for native Spanish readers and native English readers.

Products like phrasebooks or textbooks for foreign language learning need different treatment. While it might contain significant content in both Spanish and English, a book designed for use by Spanish students learning English should be coded using only one <Language> composite, with <LanguageRole> code 01 and <LanguageCode> code spa (Spanish). Such a book would not be useful to an English student trying to learn Spanish!

One way of clarifying this is to ask, ‘Is the book in a particular language, or about a particular language?’ In the former case, the language should be listed in a <Language> composite. If it’s about a language, it should not – although the secondary language may be indicated using some subject classification schemes. A second useful criterion – for such language teaching products and phrasebooks – is the language of the primary readership the product is intended for.

Using this second criterion, it’s also possible to classify a translation dictionary containing, for example, only Spanish-to-English (ie Spanish headwords with their English equivalents), although fine judgement is required about the target market or likely audience for the product. It contains significant text in both languages, and might be useful (in slightly different circumstances) for both English and Spanish readers. But if it’s for casual use (ie it’s akin to a phrasebook) or is a beginner-level dictionary for the teaching of English to Spanish readers), then it’s ‘in’ Spanish. If it’s for professional or scholarly use, then it’s more likely to be used by English translators translating from Spanish, so is ‘in’ English.

Two final uses for the <Language> composite are to define a regional variant of a language using <CountryCode>, and the script that the product uses in <ScriptCode>. Some languages – a well-known example being Serbian – can be expressed in two entirely separate scripts, in this case both Latin and Cyrillic. Other languages have distinct regional variation, for example there are well-known differences between British English and US English, Iberian Spanish and Mexican Spanish, Québécois (ie Canadian) French and Metropolitan French, or Brazilian and Iberian Portuguese. Where such distinctions are an important product attribute, they should be specified.

However, Braille can also be treated as as script in the relevant ISO code list. It is not recommended that Braille books be described or discovered only or primarily via a script code. For Braille, see <EditionType> in Group P.9 and <ProductFormDetail> in Group P.3 for the preferred methods of description.

work written and published in Portuguese
using Reference names
`<Language>`
`<LanguageRole>01</LanguageRole>`
`<LanguageCode>por</LanguageCode>`
`</Language>`

using Short tags, additionally specifying Brazilian Portuguese
`<language>`
`<b253>01</b253>`	Language of text
`<b252>por</b252>`	Portuguese
`<b251>BR</b251>`	Brazilian variant
`</language>`

work written in Portuguese, translated and published in English
using Reference names
`<Language>`
`<LanguageRole>01</LanguageRole>`
`<LanguageCode>eng</LanguageCode>`
`</Language>`
`<Language>`
`<LanguageRole>02</LanguageRole>`
`<LanguageCode>por</LanguageCode>`
`</Language>`

using Short tags
`<language>`
`<b253>01</b253>`	Language of text
`<b252>eng</b252>`
`</language>`
`<language>`
`<b253>02</b253>`	Original language
`<b252>por</b252>`
`</language>`

tourist phrasebook for German tourists visiting Japan
using Reference names
`<Language>`
`<LanguageRole>01</LanguageRole>`
`<LanguageCode>ger</LanguageCode>`
`</Language>`

using Short tags
`<language>`
`<b253>01</b253>`	Language of text
`<b252>ger</b252>`
`</language>`

Use <Subject> to specify Japan and/or Japanese.

Braille novel in French
using Reference names
`<EditionType>BRL</EditionType>`
`. . .`
`<Language>`
`<LanguageRole>01</LanguageRole>`
`<LanguageCode>fre</LanguageCode>`
`</Language>`

using Short tags
`<x419>BRL</x419>`	Braille edition
`. . .`
`<language>`
`<b253>01</b253>`	Language of text
`<b252>fre</b252>`
`</language>`

An English-language Braille edition should additionally use <ProductFormDetail> to indicate the use of Contracted or Uncontracted Braille. Similar codes indicating the grade of Braille for other languages are not yet defined.

P.11 Extents and other content

Group P.11 is primarily used to specify the extent of a product – the number of pages, or the running time of an audiobook. It also covers ancillary content such as illustrations.

The Product record for:

a book product or an e-publication with fixed pagination (eg PDF format) should contain an <Extent> composite specifying the number of pages;
- multiple <Extent> composites providing separate extents for the front matter, main content, back matter and any unnumbered inserts are preferred;
an audiobook should contain an <Extent> composite specifying the running time;
a ‘reflowable’ e-publication with no fixed pagination (eg typical EPUB format) should contain an <Extent> indicating the number of pages in any print counterpart, or a notional number of pages if it is a digital-only product;
a downloadable e-publication should also include an indication of the filesize.

Major ancillary content included in a book that is primarily text – for example, illustrations, plates, maps, extensive tabular material, a bibliography or an index should be listed in the <AncillaryContent> composite, or in an <IllustrationsNote> data element. The former is strongly preferred.

page count of a simple book with no significant front or back matter
using Reference names
`<Extent>`
`<ExtentType>11</ExtentType>`
`<ExtentValue>245</ExtentValue>`
`<ExtentUnit>03</ExtentUnit>`
`</Extent>`

using Short tags
`<extent>`
`<b218>11</b218>`	Content page count
`<b219>245</b219>`
`<b220>03</b220>`	Pages
`</extent>`

running time of an audiobook
using Reference names
`<Extent>`
`<ExtentType>09</ExtentType>`
`<ExtentValue>285</ExtentValue>`
`<ExtentUnit>05</ExtentUnit>`
`</Extent>`

using Short tags
`<extent>`
`<b218>09</b218>`	Running time
`<b219>285</b219>`	4 hours 45 mins
`<b220>05</b220>`	In minutes
`</extent>`

page count of a book with extensive front and back matter plus a plate section
using Reference names, ancillary content listed in simple <IllustrationsNote>
`<Extent>`
`<ExtentType>00</ExtentType>`
`<ExtentValue>245</ExtentValue>`
`<ExtentUnit>03</ExtentUnit>`
`</Extent>`
`<Extent>`
`<ExtentType>03</ExtentType>`
`<ExtentValue>12</ExtentValue>`
`<ExtentValueRoman>xii</ExtentValueRoman>`
`<ExtentUnit>03</ExtentUnit>`
`</Extent>`
`<Extent>`
`<ExtentType>04</ExtentType>`
`<ExtentValue>14</ExtentValue>`
`<ExtentValueRoman>xiv</ExtentValueRoman>`
`<ExtentUnit>03</ExtentUnit>`
`</Extent>`
`<Extent>`
`<ExtentType>12</ExtentType>`
`<ExtentValue>16</ExtentValue>`
`<ExtentUnit>03</ExtentUnit>`
`</Extent>`
`<Extent>`
`<ExtentType>11</ExtentType>`
`<ExtentValue>287</ExtentValue>`
`<ExtentUnit>03</ExtentUnit>`
`</Extent>`
`<IllustrationsNote>8 color plates, 15 mono plates, 2 maps. Includes index</IllustrationsNote>`

using Short tags, using <AncillaryContent>
`<extent>`
`<b218>00</b218>`	Main content page count
`<b219>245</b219>`
`<b220>03</b220>`	Pages
`</extent>`
`<extent>`
`<b218>03</b218>`	Front matter page count
`<b219>12</b219>`
`<x421>xii</x421>`
`<b220>03</b220>`	Pages
`</extent>`
`<extent>`
`<b218>04</b218>`	Back matter page count
`<b219>14</b219>`
`<x421>xiv</x421>`
`<b220>03</b220>`	Pages
`</extent>`
`<extent>`
`<b218>12</b218>`	Unnumbered insert page count
`<b219>16</b219>`
`<b220>03</b220>`	Pages
`</extent>`
`<extent>`
`<b218>11</b218>`	Content page count
`<b219>287</b219>`
`<b220>03</b220>`	Pages
`</extent>`
`<ancillarycontent>`
`<x423>24</x423>`	Color plates
`<b257>8</b257>`
`</ancillarycontent>`
`<ancillarycontent>`
`<x423>23</x423>`	Mono plates
`<b257>15</b257>`
`</ancillarycontent>`
`<ancillarycontent>`
`<x423>14</x423>`	Maps
`<b257>2</b257>`
`</ancillarycontent>`
`<ancillarycontent>`
`<x423>25</x423>`	Index
`<!-- number of index pages unspecified -->`
`</ancillarycontent>`

The 8 color and 15 mono plates make up the 16-page unnumbered insert (plate section). The maps and index are counted within the main content page count.

filesize of a downloadable e-publication, with extent of print counterpart
using Reference names
`<Extent>`
`<ExtentType>22</ExtentType>`
`<ExtentValue>1.4</ExtentValue>`
`<ExtentUnit>19</ExtentUnit>`
`</Extent>`
`<Extent>`
`<ExtentType>08</ExtentType>`
`<ExtentValue>320</ExtentValue>`
`<ExtentUnit>03</ExtentUnit>`
`</Extent>`

using Short tags
`<extent>`
`<b218>22</b218>`	Filesize
`<b219>1.4</b219>`
`<b220>19</b220>`	In megabytes
`</extent>`
`<extent>`
`<b218>08</b218>`	Extent of print counterpart
`<b219>320</b219>`
`<b220>03</b220>`	Pages
`</extent>`

Extent composite

The <Extent> composite carries the page count of a book or e-publication, or a similar measure such as running time for an audio product (including downloadable audio) or filesize – and possibly the word count – for a downloadable product. The composite should contain a mandatory <ExtentType>, a number for the extent in <ExtentValue>, and must specify the units the value is measured in (pages, minutes, megabytes etc) in the <ExtentUnit> element.

For books where front and back matter are relatively insignificant and there are no inserts – for example, most novels – it is best practice to provide only a single extent, and the preferred measure is the content page count (code 11 from List 23). In very simple cases, this extent might be equal to the highest page number.

Where a book contains any significant front or back matter, or an insert / plate section, it is best practice to specify the page count for the key parts of a book individually:

front matter – for example, the title page, introduction and preface, often termed the ‘prelims’ (code 03 from List 23);
the main content (code 00 from List 23);
- this might include a few blank pages, where for example blanks are included to ensure all chapters start on a recto page, or where pages are intended to be filled in by the consumer, but it does not include any unnumbered pages in an insert or plate section;
unnumbered pages in any insert(s) such as plate sections (code 12 from List 23);
back matter – notes and appendices, index etc (code 03 from List 23);
- this excludes any blank pages or advertising pages that are included to ensure a convenient signature size during manufacture;
if the front matter, main content and back matter page counts cannot be provided separately, then a total count of numbered pages may be provided (code 05), together with a count of any unnumbered pages in inserts or plate sections (code 12);
the content page count (code 11) should always be provided when the more granular combinations of extents are not available, and could be provided in addition to the granular extents for recipients who want just a simple, single number.

Where for any reason a publisher can only provide a single repeat of the <Extent> composite, the preferred measure is the content page count (which includes any unnumbered inserts or plate sections) or – if this is genuinely unavailable – the total numbered page count (which excludes unnumbered inserts or plate sections). Note that neither of these necessarily matches the highest page number in the book (which in most cases will be the total numbered page count minus any Roman-numbered front matter). Nor do they match the production page count.

For front matter (and possibly back matter) that is numbered with Roman numerals, the extent should be stated as an Arabic integer as normal, in <ExtentValue>, but may additionally be stated in Roman numerals in <ExtentValueRoman>. It is not best practice to supply only Roman numerals. Recipients should accept Roman numerals in either upper or lower case, though lower case is more usual when numbering pages.

For audio running times, values in minutes are preferred to hours and minutes or just hours (ie 195 minutes is preferred to 3 hours and 15 minutes or simply three hours). The unit of measure should be included in the <ExtentUnit> element.

For e-publications that have a fixed pagination (ie they are not ‘reflowable‘), the extent should be provided exactly as for printed books, or by specifying the absolute page count (code 07). For reflowable e-publications without a fixed pagination, then the extent should be specified either by providing the extent of the printed counterpart (code 08) or by providing a ‘notional’ extent (ie what would be the extend of the print version, if such a counterpart existed).

For downloadable e-publications such as e-books or downloadable audio, the size of the downloadable file (or total size of some downloadable package of files) should be included, measured in kilobytes for filesizes below 1MB (code 18 from List 24 in the <ExtentUnit> element), and in megabytes (code 19) for larger files. There is no real benefit in a precision greater than two significant digits (ie 220 kilobytes or 1.3 megabytes, not 223.75 kilobytes and 1.325 megabytes).

Extents can also be specified by the number of words. However, while the weightiness of a 200,000 word manuscript is familiar to some within the publishing industry, word counts are not always simple for consumers to interpret. They are not recommended as the only indication of extent – though they may become more useful in future as reflowable publications become the norm.

List 23 allows the number of pages in a book (or an e-publication) to be specified in various ways: the diagram illustrates the relationship between the parts of the book in spine order, and the various page counts. For example, the total page count (List 23 code 05) counts all numbered pages in the front matter, the main content and back matter, but excludes unnumbered pages in any insert or plate section. In contrast, the content page count (code 11) includes those unnumbered pages.

Best practice is to provide one of the combinations of extents A or B in repeats of <Extent> – codes 03, 00, 04 plus 12 (if relevant) make up combination A, and codes 05 plus 12 (if relevant) make up combination B. The diagram is in rough order of preference, so combination A is preferred to combination B, and B is preferred to C (code 11 alone) because the former is more granular, and recipients who receive granular data but wish to use only a single figure can easily sum the various extents provided in a combination.

¹ Absolute, counterpart and notional page counts are only used with e-publications, but word counts may be more appropriate
² Back matter may not include advertising pages
³ ‘Blank’ pages may include advertising pages

It is likely that the exact extent – whether a page count or a running time – will not be known until relatively late in the production of a new product. Extents provided more than three months prior to publication should be treated as estimates, and publishers should provide more accurate values as early as possible. Filesizes are unlikely to be finalized more than a month prior to publication.

Audiobook products on CD are commonly divided into many tracks – the equivalent of songs on a music CD – typically around three to six minutes per track. These tracks are important for navigation, as CD players typically don’t maintain a ‘bookmark’ or current playback position if playback is stopped and restarted later. It may sometimes be useful to be able to declare the number of tracks in the metadata – though this should never be at the expense of describing the actual running time.

Number of physical tracks in a CD audiobook
using Reference names, a 12-track CD
`<Extent>`
`<ExtentType>09</ExtentType>`	Duration
`<ExtentValue>12</ExtentValue>`
`<ExtentUnit>11</ExtentUnit>`	12 tracks
`</Extent>`

using Short tags, a 92½ minute, 20 track CD with the first track being introductory music and the final track being cast credits or other end matter
`<Extent>`
`<b218>09</b218>`	Duration (total running time)
`<b219>92.5</b219>`
`<b220>05</b220>`	92½ minutes
`</Extent>`
`<Extent>`
`<b218>13</b218>`	Duration of introduction
`<b219>1</b219>`
`<b220>11</b220>`	1 track
`</Extent>`
`<Extent>`
`<b218>14</b218>`	Duration of main content
`<b219>18</b219>`
`<b220>11</b220>`	18 tracks
`</Extent>`

‘Tracks’ is treated as – in effect – a unit of time, equivalent to something between 3 and 6 minutes.

Physical CD tracks have an equivalent with downloadable audio files, when a single book is delivered as a collection of individual MP3 files (or similar audio files).

For multi-item products which are sold as a single item (with <ProductComposition> code 10), the extent is the total of the extents of the items included in the product. (This is necessary because <Extent> cannot be included within Block 3 <ContentDetail>.) So a product which consists of four 300-page volumes in a slipcase has a combined extent of 1200 pages. And a product that includes both a book and an audio version of the text might have both a page extent and a running time. However, you should not include extents for multi-item products that are sold individually at retail (<ProductComposition> codes 11 or 30). A trade pack of four copies of a 300-page book does not have a combined extent of 1200 pages.

P.11.7 Illustrations and other contents note

Where <AncillaryContent> cannot be supplied for any reason, any illustrations and other important non-textual content such as an extensive tabular material, a bibliography or an index should be listed here. <IllustrationsNote> is not just for describing the number and type of any included illustrations.

Note this is a text field that can accept XHTML encoding: this could be used to provide a marked-up bulleted list of the ancillary content – but it is unlikely that a data provider would be able to provide that level of detail, yet not be able to provide the data in the <AncillaryContent> composite.

However, if various repeats of the <AncillaryContent> composite are used to specify non-textual content, it may still be beneficial to include a description of the non-text content in <IllustrationsNote>, for recipients who are not able to make use of the <AncillaryContent> composite, or to provide a more ‘readable’ alternative where a simple concatenation of various <AncillaryContent> elements would not produce a suitable description. If provided in this way, recipients should use <IllustrationsNote> for display purposes, while using the granular data in <AncillaryContent> for processing.

<IllustrationsNote>Includes 32 full-page color reproductions of the artist’s work printed on high-quality paper, and 20 further full-color images</IllustrationsNote>

Note there is some overlap between detailed text that might be included in <IllustrationNote>, descriptive text about the product that might be included in the <TextContent> composite within Block 2: Marketing collateral. <IllustrationNote> should be very brief, and is not intended to be heavily formatted (even though XHTML markup is valid in this element).

Ancillary content composite

This composite is the preferred way of listing details of the number and type of any graphical and other material within a primarily textual product. It can be used to highlight extensive tabular content, maps, charts and diagrams, or the presence and extent of any bibliography or index. Repetitions of the composite are used to specify ancillary content of more than one type.

The composite must contain an <AncillaryContentType> element to specify the type of the ancillary content, and may contain a <Number> element to specify the amount of that type of content. The ‘measure’ used is primarily ‘number of…’ – so 16 graphs or diagrams or plates, not 16 pages of graphs, diagrams or plates. However, for bibliographies and indexes (<AncillaryContentType> codes 25 and 26), the measure is the number of pages that content comprises. If an <AncillaryContent> composite is supplied without a <Number> element, then it simply serves as a flag that some content of the specified type is present.

<AncillaryContent> is not generally used to specify the number of maps with products like atlases, where the non-textual content is the primary content of the product, but can be used to specify additional larger-scale inset maps within a cartographic product. Gazetteer content within an atlas may be counted as an index.

The code values in List 25 specify the type of ancillary content in the <AncillaryContentType> data element. But because of differences in terminology used in different countries, the meanings of the common codes for images included in a book are not always clear. The primary distinction is whether the images occur within the ‘main content’ of the book (illustrations – they might be photos, graphs, diagrams, charts, inset maps etc), or whether they occur in an insert (plates – these are usually photos, and the insert usually uses a higher-quality paper than the remainder of the book). The secondary distinction is whether they are color (using multiple inks) or mono (using a single ink, thus usually a black and white image). The tertiary distinction is whether they use a halftoning process (thus allowing graduated shades or tints) or are line art (solid ink only, no halftoning). This is primarily a ‘production’ classification, which takes no account of the editorial function of each illustration or plate:

List 25 code values ‘production-led’ classification of ancillary content
	location	color		mono		unspecified
		halftone	line art	halftone	line art	halftone	line art
‘plates’	insert	24	–	23	–	22	–
‘illustrations’	main content	04	06	03	05	10	12
tabular material	main content	08		07		11
printed music	main content	–		–		20
bibliography	main content	–		–		26
index	main content	–		–		25

It is also possible to use an ‘editorial’ classification with some types of ancillary content, which emphasizes the nature of (in particular) illustrations. Unfortunately in this case, the distinctions between tables, figures, diagrams, graphs and charts are not at all clear cut, and usage of these terms varies:

List 25 code values ‘editorially-led’ classification of ancillary content
	color	mono	unspecified
photographs / similar images	02	01	09
figures	–	–	17
diagrams	–	–	16
graphs	–	–	21
charts	–	–	18
maps	–	–	14
inset maps	–	–	27
tabular material	08	07	11
printed music	–	–	20
bibliography	–	–	26
index	–	–	25

Do not mix the two types of classification – use either a production- or editorially-led approach. Note there are a couple of ‘special case’ codes not included in the above tables.

P.12 Subject

This Group is used to describe what or who the product is about, independent of the physical or digital nature of the product.

Every Product record should include one or more <Subject> composites, to specify the subject of the product.

There are many subject classification schemes, often endemic to a particular territory: none is both commercially-focused and globally-accepted – although this is the explicit aim of the new Thema scheme, and it should eventually reduce the need to use multiple schemes. Meantime, the record should include repeated <Subject> composites to specify the subject using each scheme commonly used in the territories in which the product is sold.

For each scheme used:

the data should conform to the best practices established for that scheme;
if a classification within a particular scheme makes use of multiple classification codes, one should be flagged as being primary with the <MainSubject/> empty element.

In addition, the subject matter, theme or content should be indicated using keywords, words or short phrases that are not part of a controlled vocabulary.

A <NameAsSubject> composite should be included for products where a real person or organization forms the subject matter of the product.

Note the <Subject> composite is also used to carry some classifications that are not strictly subject categories – for example the (UK) Publishers Association’s Children’s Book Marketing Code (CBMC) in the UK – and a variety of proprietary subject classifications.

product about the architecture of the English Arts and Crafts movement, classified using both BIC and BISAC subject classification schemes, plus keywords
using Reference names
`<Subject>`
`<MainSubject/>`
`<SubjectSchemeIdentifier>12</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>2.0</SubjectSchemeVersion>`
`<SubjectCode>AMX</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>12</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>2.0</SubjectSchemeVersion>`
`<SubjectCode>ACVN</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>13</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>2.0</SubjectSchemeVersion>`
`<SubjectCode>1DBKE</SubjectCode>`
`</Subject>`
`<Subject>`
`<MainSubject/>`
`<SubjectSchemeIdentifier>15</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>2.0</SubjectSchemeVersion>`
`<SubjectCode>3JH</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>15</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>2.0</SubjectSchemeVersion>`
`<SubjectCode>3JJ</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>20</SubjectSchemeIdentifier>`
`<SubjectHeadingText>William Morris; John Ruskin; Philip Webb; Charles Voysey; Red House; Edwin Lutyens; Edward Schroeder Prior; Voewood</SubjectHeadingText>`
`</Subject>`
`<Subject>`
`<MainSubject/>`
`<SubjectSchemeIdentifier>10</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>2009</SubjectSchemeVersion>`
`<SubjectCode>ARC005070</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>10</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>2009</SubjectSchemeVersion>`
`<SubjectCode>ART015030</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>11</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>2009</SubjectSchemeVersion>`
`<SubjectCode>1.1.2.2.0.0.0</SubjectCode>`
`</Subject>`

using Short tags
`<subject>`
`<x425/>`	Main
`<b067>12</b067>`	BIC subject category
`<b068>2.0</b068>`	(latest is 2.1)
`<b069>AMX</b069>`	History of architecture
`</subject>`
`<subject>`
`<b067>12</b067>`	BIC subject category
`<b068>2.0</b068>`
`<b069>ACVN</b069>`	Art and design styles: Arts and Crafts
`</subject>`
`<subject>`
`<b067>13</b067>`	BIC geographical qualifier
`<b068>2.0</b068>`
`<b069>1DBKE</b069>`	England
`</subject>`
`<subject>`
`<x425/>`	Main
`<b067>15</b067>`	BIC time period qualifier
`<b068>2.0</b068>`
`<b069>3JH</b069>`	19th Century
`</subject>`
`<subject>`
`<b067>15</b067>`	BIC time period qualifier
`<b068>2.0</b068>`
`<b069>3JJ</b069>`	20th Century
`</subject>`
`<subject>`
`<b067>20</b067>`	Keywords
`<b070>William Morris; John Ruskin; Philip Webb; Charles Voysey; Red House; Edwin Lutyens; Edward Schroeder Prior; Voewood</b070>`	Selection of likely search terms, though the book is not specifically ‘about’ any individual architect
`</subject>`
`<subject>`	Main
`<x425/>`
`<b067>10</b067>`	BISAC Subject Heading
`<b068>2009</b068>`	(latest is 2011)
`<b069>ARC005070</b069>`	Architecture / History / Modern (late 19th Century to 1945)
`</subject>`
`<subject>`
`<b067>10</b067>`	BISAC Subject Heading
`<b068>2009</b068>`
`<b069>ART015030</b069>`	Art / European
`</subject>`
`<subject>`
`<b067>11</b067>`	BISAC regional theme
`<b068>2009</b068>`
`<b069>1.1.2.2.0.0.0</b069>`	England
`</subject>`

There can be only one subject nominated as ‘main’, per scheme.

If the product concentrated on a particular architect, their name should be included in a <NameAsSubject> composite, and BIC and BISAC subject coding would also differ (probably AMB and ARC006020, respectively).

using the new *Thema* global subject classification scheme for a product about Gauguin and the Pont Aven school
using Reference names
`<Subject>`
`<MainSubject/>`
`<SubjectSchemeIdentifier>93</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>1.1</SubjectSchemeVersion>`
`<SubjectCode>AGA</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>93</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>1.1</SubjectSchemeVersion>`
`<SubjectCode>AFCL</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>94</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>1.1</SubjectSchemeVersion>`
`<SubjectCode>1DD-FR-FB</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>96</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>1.1</SubjectSchemeVersion>`
`<SubjectCode>3MNQX</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>99</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>1.1</SubjectSchemeVersion>`
`<SubjectCode>6SV</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>20</SubjectSchemeIdentifier>`
`<SubjectHeadingText>Pont Aven</SubjectHeadingText>`
`</Subject>`
`<NameAsSubject>`
`<NameIdentifier>`
`<NameIDType>16</NameIDType>`
`<IDValue>000000012100026X</IDValue>`
`</NameIdentifier>`
`<PersonNameInverted>Gauguin, Paul</PersonNameInverted>`
`</NameAsSubject>`
`<NameAsSubject>`
`<PersonNameInverted>Bernard, Émile</PersonNameInverted>`
`</NameAsSubject>`

using short names
`<subject>`
`<x425/>`	Main
`<b067>93</b067>`	Thema subject classification
`<b068>1.1</b068>`
`<b069>AGA</b069>`	History of art
`</subject>`
`<subject>`
`<b067>93</b067>`
`<b068>1.1</b068>`
`<b069>AFCL</b069>`	Painting in oil
`</subject>`
`<subject>`
`<b067>94</b067>`
`<b068>1.1</b068>`
`<b069>1DDF-FR-FB</b069>`	Finistère
`</subject>`
`<subject>`
`<b067>96</b067>`
`<b068>1.1</b068>`
`<b069>3MNQX</b069>`	1880s
`</subject>`
`<subject>`
`<b067>99</b067>`
`<b068>1.1</b068>`
`<b069>6SV</b069>`	Synthetism
`</subject>`
`<subject>`
`<b067>20</b067>`	Keywords
`<b070>Pont Aven</b070>`
`</subject>`
`<nameassubject>`
`<nameidentifier>`
`<x415>16</x415>`	ISNI
`<b244>000000012100026X</b244>`
`</nameidentifier>`
`<b037>Gauguin, Paul</b037>`
`</nameassubject>`
`<nameassubject>`
`<b037>Bernard, Émile</b037>`
`</nameassubject>`

Thema is the international, multi-lingual subject classification for a global book trade. For futher details, see the EDItEUR website. It is available in languages including Arabic, Danish, English, French, German, Italian, Japanese, Polish, Spanish, Norwegian, Swedish, and other translations are in preparation.

Subject composite

Repeats of the <Subject> composite must each contain either a code drawn from one of the many classification schemes listed in List 27, or a classification drawn from a proprietary subject code list, or a set of keywords. In all cases, the scheme used must be identified in <SubjectSchemeIdentifier>, and for proprietary schemes, the name of the scheme should be carried in <SubjectSchemeName>. The composite should include:

For an established classification scheme;
- <SubjectSchemeIdentifier> (almost any code from List 27);
- <SubjectSchemeVersion> (as far as possible with an individual scheme, this should be a simple number, and should not incorporate words such as ‘version’ or ‘release’);
- <SubjectCode> (in whatever format specified by the individual scheme);
  - <SubjectHeadingText> is unnecessary;
For a proprietary subject scheme;
- <SubjectSchemeIdentifier> (codes 23 or 24 from List 27);
- <SubjectSchemeName>;
- <SubjectSchemeVersion>;
- one or both of <SubjectCode> and <SubjectHeadingText>;
For a list of keywords;
- <SubjectSchemeIdentifier> (code 20 from List 27);
- <SubjectHeadingText> (semicolon-separated keyword terms).

For established classification schemes which use codes (including Thema, BIC, BISAC etc), there is no need to embed the name or heading text of the selected category in <SubjectHeadingText> – that text is made explicit in the authority list for the scheme, and there is no great value in repeating it. However, the version or revision number of the scheme should usually be included in <SubjectSchemeVersion>, because many schemes regularly introduce new categories or deprecate old ones.

For less well-known schemes which may not be understood by recipients, or for schemes which do not specify a code for each heading, the heading text should be included in <SubjectHeadingText>.

Commonly-used subject schemes and <SubjectSchemeVersion> numbers
Scheme	Current	Selected previous versions
BIC	2.1	2.0, 1.1
BISAC	2014	2011, 2010, 2.9, 2.6
CCE	2.0
CLIL	2014	2010, 2006
Thema	1.1	1.0
Warengruppen-Systematik	2.0

Where classification schemes allow multiple classifications to be supplied, ensure one is labelled as the primary classification using <MainSubject/>, and it is good practice to list the others in order of importance (this makes it more likely that a data recipient which accepts only a limited number of codes accepts the most important).

It is common to provide two, three or more subject classifications from a single scheme. But note there is diminishing value in providing more and more codes: two or three thoughtfully-chosen, detailed and relevant subject categories are more useful to a retailer – and to a potential purchaser – than 12 or 13 that are less relevant or overly broad. Do not supply multiple classifications simply in an attempt to get the product listed under as many headings as possible within a retail system. And with hierarchical schemes such as BIC, BISAC or Thema, do not provide a broad classification where you also provide a more specific code – always use the most specific classification that is appropriate.

Many major subject classification schemes have a hierarchical structure. Where this is the case, it is best practice to ‘use the most specific classification that is appropriate’. Including a ‘general’ or less specific code where the book also carries a more specific code should be avoided.

If the book is Historical fiction, do not also classify it as Fiction.

For a more detailed illustration of this principle, consider a book that is correctly classified using the BISAC subject category scheme as MAT007020 (ie it is about partial differential equations). The BISAC scheme is hierarchical, with – in effect – three levels, and MAT007020 is Mathematics / Differential Equations / Partial. This code is automatically included in any selection of ‘all books about maths’ (which would be a selection of any books that match MAT******). Conversely, it would not be included in a selection of general books that cover all aspects of mathematics – for that, you can search for MAT000000.

If the partial differential equations book were classified as both MAT007020 and MAT000000, it ‘pollutes’ the search for general maths books (where the book would not be suitable, because it is much too specialized and clearly not what the potential purchaser is searching for).

Thus following best practice allows a differentiation between ‘all books about any aspect of maths’ and ‘any books about all aspects of maths’.

If the book’s subject encompasses both partial differential equations and game theory, it should be classified as MAT007020 and MAT011000 – still not as MAT000000. At least in principle, high-level codes such as MAT000000 imply the subject matter covers all sub-categories of MAT****** – algebra, geometry, topology, statistics and probability etc, as well as differential equations and game theory.

For proprietary classifications – <SubjectSchemeIdentifier> codes 23 or 24 from List 27 – the name of the proprietary scheme should always be included in a consistent and likely-to-be-unique way in <SubjectSchemeName>. Proprietary schemes may also need version numbering. Code 23 should be used for publisher’s own categorizations, and code 24 for proprietary schemes that may be applied to multiple publishers’s products (eg a distributor’s, wholesaler’s or retailer’s own scheme). If the scheme is coded, then the meaning of each code and the structure of the scheme must clearly be shared in advance with ONIX recipients. Alternatively, the classification text may be explicit in <SubjectHeadingText>. In the latter case, it is still good practice to share details of the scheme up front with recipients.

incorporating publisher’s and retailer’s proprietary subject category schemes
using Reference names
`<Subject>`
`<SubjectSchemeIdentifier>23</SubjectSchemeIdentifier>`
`<SubjectSchemeName>FantasyBooks LLC Subject</SubjectSchemeName>`
`<SubjectSchemeVersion>1.1</SubjectSchemeVersion>`
`<SubjectCode>405</SubjectCode>`
`<SubjectHeadingText>Steampunk</SubjectHeadingText>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>24</SubjectSchemeIdentifier>`
`<SubjectSchemeName>BigBooks Inc Merchandising Category</SubjectSchemeName>`
`<SubjectSchemeVersion>2009</SubjectSchemeVersion>`
`<SubjectHeadingText>Science Fiction</SubjectHeadingText>`
`</Subject>`

using Short tags
`<subject>`
`<b067>23</b067>`	Publisher’s own category
`<b171>FantasyBooks LLC Subject</b171>`
`<b068>1.1</b068>`
`<b069>405</b069>`
`<b070>Steampunk</b070>`
`</subject>`
`<subject>`
`<b067>24</b067>`	Proprietary subject scheme
`<b171>BigBooks Inc Merchandising Category</b171>`
`<b069>2009</b069>`
`<b070>Science Fiction</b070>`
`</subject>`

The publisher’s scheme is coded, but the text of the category heading is also included. The proprietary scheme is not coded, but is simply a controlled vocabulary of subject headings.

When supplying keywords, the keywords should be carried in a single semicolon-separated list, which makes it possible to have ‘keyword’ terms that are in fact short phrases including spaces or other punctuation. Keywords can be invaluable as matches for natural language search terms: for fiction, choose character names, historical settings, locations, perhaps even narrative themes; for non-fiction, key terms of art, locations, events, periods and people can all be used to drive search results in an online context.

Choose keywords that are likely to be used as search terms by potential book buyers. While there’s often a temptation to include a very large number of keywords, experience shows that five to ten carefully-chosen keywords are more valuable than 20 or 50 that are poorly-chosen. Be mindful that while overly-generic terms may generate more search ‘hits’, those hits will be of lower quality (ie your book will be found, but so will thousands of others). Keywords should not repeat words from the title of the product or from contributor names, nor should they simply repeat words already included in the subject heading text of the subject categories in any other <Subject> composite, or the names in <NameAsSubject> composites. For recipients, keywords should be a source of matchable search terms in addition to the content of other structured metadata elements – and most of those other elements are likely to be weighted more highly than the unstructured keywords. One possible exception is that you may wish to repeat words from the short or long description, or the table of contents, as keywords. Some recipients automatically index the whole of the descriptive text to provide matchable search terms, but others do not.

For senders, there should be no need to supply many variations on the same root word – for example ‘catalyst; catalysis; catalyse’ – as recipients are likely to implement stemming of search terms (that is, a single term like ‘catalyst’ would be matched by any word based on that root). Search engines also deal well with variant spellings, so only one of ‘organisation’ and ‘organization’ need be supplied as a keyword.

In particular, avoid trying to ‘game’ the system. Do not include keywords that have little or nothing to do with the book’s subject matter, just because they are popular online search targets – don’t list 50 Shades of Grey, ‘cute cats’, Harry Potter, ‘free’ or ‘bestseller’ as keywords for every product. Doing so is likely to result in recipients rejecting the entire list of keywords. (Some retailers restrict or disallow the use of obviously promotional keywords like ‘free’ or ‘bestseller’. And note that genuine competitive, comparable or related titles can be listed using the <RelatedProduct> composite.)

It is common to include spaces following each separator semi-colon. Spaces make the keywords easier to read in a single list, but recipients should not rely on either the presence or absence of spaces. Either is acceptable.

`<SubjectHeadingText>Unity Church;Fallingwater;Taliesin;Guggenheim Museum</SubjectHeadingText>`
`<SubjectHeadingText>Unity Church; Fallingwater; Taliesin; Guggenheim Museum</SubjectHeadingText>`

There should be only one repeat of the <Subject> composite containing keywords (and thus a <MainSubject/> flag is inappropriate). Note that the suggested limit of 250 characters on the P.12.6 <SubjectHeadingText> element is adequate for a practical set of at least 10–15 keywords, but clearly means that some recipients will have to truncate the list if, say, 40 separate keywords are sent. There is little practical value in such long lists of keywords.

And although <SubjectHeadingText> is repeatable within a single <Subject> composite, each keyword does not occupy an individual <SubjectHeadingText> element – keywords are provided in a single list. Normally, the ability to repeat <SubjectHeadingText> is not used, as there is little benefit in providing keywords in multiple languages, and although a few subject schemes provide heading text in multiple languages (UDC for example), there is little reason to provide <SubjectHeadingText> at all for standard schemes. In rare cases, keywords in multiple languages may be useful where the product itself uses multiple languages (eg a bilingual or or parallel text edition). In this case, the language attribute must be included for each <SubjectHeadingText>.

For educational books, it may be useful to list specific alignments with common or national curricula, alongside the usual trade-focused subject schemes. This can be particularly valuable information for schools or teachers selecting resources for classroom use.

alignment with US Common Core State Standards and BISG Educational Objectives Taxonomy
using Reference names
`<Subject>`
`<MainSubject/>`
`<SubjectSchemeIdentifier>10</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>2013</SubjectSchemeVersion>`
`<SubjectCode>EDU029010</SubjectCode>`
`</Subject>`
`<Subject>`
`<MainSubject/>`
`<SubjectSchemeIdentifier>A4</SubjectSchemeIdentifier>`
`<SubjectCode>CCSS.MATH.CONTENT.4.MD.A.1</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>A4</SubjectSchemeIdentifier>`
`<SubjectCode>CCSS.MATH.CONTENT.4.MD.A.2</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>B1</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>1.0</SubjectSchemeVersion>`
`<SubjectCode>EDTX530</SubjectCode>`
`</Subject>`
`<Subject>`
`<SubjectSchemeIdentifier>B1</SubjectSchemeIdentifier>`
`<SubjectSchemeVersion>1.0</SubjectSchemeVersion>`
`<SubjectCode>EDTX550</SubjectCode>`
`</Subject>`

using Short tags
`<subject>`
`<x425/>`
`<b067>10</b067>`	BISAC subject scheme
`<b068>2013</b068>`
`<b069>EDU029010</b069>`	Education / Teaching methods and materials / Maths
`</subject>`
`<subject>`
`<x425/>`
`<b067>A4</b067>`	Common Core State Standards
`<b069>CCSS.MATH.CONTENT.4.MD.A.1</b069>`	Relates particularly to requirements for Fourth Grade maths involving measurement and conversion of units
`</subject>`
`<subject>`
`<b067>A4</b067>`
`<b069>CCSS.MATH.CONTENT.4.MD.A.2</b069>`	…and to arithmetic problems involving distance, time, mass, volume etc
`</subject>`
`<subject>`
`<b067>B1</b067>`	BISG Educational Objectives Taxonomy
`<b068>1.0</b068>`
`<SubjectCode>EDTX530</SubjectCode>`	Model with mathematics
`</subject>`
`<subject>`
`<b067>B1</b067>`
`<b068>1.0</b068>`
`<b069>EDTX550</b069>`	Perform contextualized problem solving using graphs, tables and equations
`</subject>`

The CCSS scheme uses the full dot notation rather than the abbreviated notation or URI/GUID options to identify CCSS learning requirements. This allows US state-specific variations of CCSS to be included as well, where they include compatible notations.

For locations, there are a number of coding schemes, including BIC or Thema Geographical qualifiers, BISAC Regional themes and GeoNames IDs.

incorporating a GeoName ID for a novel set in Brazzaville, Congo Republic
using Reference names
`<Subject>`
`<SubjectSchemeIdentifier>86</SubjectSchemeIdentifier>`
`<SubjectCode>2260535</SubjectCode>`
`<SubjectHeadingText>Brazzaville</SubjectHeadingText>`
`</Subject>`

using Short tags
`<subject>`
`<b067>86</b067>`	GeoNames ID
`<b069>2260535</b069>`
`<b070>Brazzaville</b070>`
`</subject>`

It is a common error to try to use the <Subject> composite to specify the language of a book. Many subject schemes contain entries for languages (for example, Thema has a hierarchy of language qualifiers). These language entries should be used to describe the language the book is about, and the <Language> composite in Group P.10 should be used to specify the language the book is in. A book about the Japanese language may be written in (or translated into) English – so <Subject> would specify Japanese and <Language> would specify English.

Name as subject composite

Where a product is about or partly about a real person or organization – a biography, memoir, or corporate history, for example – then <NameAsSubject> should be used to carry the name of the subject of the product.

The structure of the <NameAsSubject> composite is essentially the same as the <AlternativeName> composite in Group P.7, and the same best practices apply. For example, for a biography of George Orwell, two repeats of <NameAsSubject> could be supplied, giving both his ‘real’ name Eric Blair and his pen name.

Where a product is closely concerned with several people, then several repeats of <NameAsSubject> may be used. A historical examination of some event might list the key participants, but with a practical limit of around five names.

<NameAsSubject> should not be used to carry names of fictional characters.

P.13 Audience

Group P.13 consists primarily of the <Audience> and <AudienceRange> composites, which provide a way of describing the intended readership – not necessarily the intended commercial market – for the product. To illustrate the difference, a picture book may be aimed at an audience 3- to 4-year old children, but the commercial target market is their parents. A textbook might be intended for an audience of Grade 7 school students, but the purchasers of the book would in most cases be their school.

Every Product record should include one or more <Audience> composites, to specify the intended readership for the product. (This is true even though some subject classification schemes incorporate some limited audience details.) At minimum, the audience should be described using the ONIX audience codes in List 28.

As with subject coding, there are many audience classification schemes, endemic to different territories, so the record should include repeated <Audience> composites to specify the audience using each scheme commonly used in the territories in which the product is sold.

Product records for children’s and school education titles should include an <AudienceRange> composite to specify the intended reading age and/or interest age range, school grade or year range precisely. Where possible, <AudienceRange> should also be used to specify an intended higher education application.

Product records for school education titles should also include a <Complexity> composite wherever appropriate: quantitative text levelling is of increasing importance to educators’ book selection process.

simple audience description using only an ONIX code
using Reference names
`<Audience>`
`<AudienceCodeType>01</AudienceCodeType>`
`<AudienceCodeValue>06</AudienceCodeValue>`
`</Audience>`

using Short tags
`<audience>`
`<b204>01</b204>`	Using ONIX audience codes
`<b206>06</b206>`	Professional and scholarly
`</audience>`

The ONIX audience code from List 28 can be delivered using the <AudienceCode> data element, but using the <Audience> composite is strongly preferred. Use of the <AudienceCode> element is deprecated.

book generally suitable for adults, but with a content warning
using Reference names
`<Audience>`
`<AudienceCodeType>01</AudienceCodeType>`
`<AudienceCodeValue>01</AudienceCodeValue>`
`</Audience>`
`<Audience>`
`<AudienceCodeType>22</AudienceCodeType>`
`<AudienceCodeValue>04</AudienceCodeValue>`
`</Audience>`

using Short tags
`<audience>`
`<b204>01</b204>`	Using ONIX audience codes
`<b206>01</b206>`	Non-specialist adult audience
`</audience>`
`<audience>`
`<b204>22</b204>`	ONIX Adult audience rating
`<b206>04</b206>`	Content warning (violence)
`</audience>`

ONIX Adult audience ratings from List 203 are intended to be applied by the publisher only when the content is likely to offend a particular section of the adult audience. It is not the intent that every romance has a ‘sexual content’ warning, or every thriller a ‘violence’ warning. If a book is suitable for a juvenile or young adult audience (codes 02 or 03 from List 28, or their equivalent in other schemes) a content warning is never appropriate, nor are content warnings appropriate in educational or professional settings.

multiple coded audience descriptions
using Reference names
`<Audience>`
`<AudienceCodeType>01</AudienceCodeType>`
`<AudienceCodeValue>03</AudienceCodeValue>`
`</Audience>`
`<Audience>`
`<AudienceCodeType>23</AudienceCodeType>`
`<AudienceCodeValue>C2</AudienceCodeValue>`
`</Audience>`
`<Audience>`
`<AudienceCodeType>02</AudienceCodeType>`
`<AudienceCodeTypeName>BookBag Audience Group</AudienceCodeTypeName>`
`<AudienceCodeValue>BB-LM</AudienceCodeValue>`
`</Audience>`

using Short tags
`<audience>`
`<b204>01</b204>`	ONIX audience code
`<b206>03</b206>`	Young adult
`</audience>`
`<audience>`
`<b204>23</b204>`	Common European Framework for Language Learning
`<b206>C2</b206>`
`</audience>`
`<audience>`
`<b204>02</b204>`	Proprietary code
`<b205>BookBag Audience Group</b205>`
`<b206>BB-LM</b206>`
`</audience>`

senior year college textbook
using Reference names
`<Audience>`
`<AudienceCodeType>01</AudienceCodeType>`
`<AudienceCodeValue>05</AudienceCodeValue>`
`</Audience>`
`<AudienceRange>`
`<AudienceRangeQualifier>11</AudienceRangeQualifier>`
`<AudienceRangePrecision>01</AudienceRangePrecision>`
`<AudienceRangeValue>16</AudienceRangeValue>`
`</AudienceRange>`

using Short tags
`<audience>`
`<b204>01</b204>`	Using ONIX audience codes
`<b206>05</b206>`	College/Higher education
`</audience>`
`<audiencerange>`
`<b074>11</b074>`	US school grade range
`<b075>01</b075>`	Exact
`<b076>16</b076>`	College Senior
`</audiencerange>`

audience description for a primary/elementary education product
using Reference names
`<Audience>`
`<AudienceCodeType>01</AudienceCodeType>`
`<AudienceCodeValue>04</AudienceCodeValue>`
`</Audience>`
`<AudienceRange>`
`<AudienceRangeQualifier>17</AudienceRangeQualifier>`
`<AudienceRangePrecision>03</AudienceRangePrecision>`
`<AudienceRangeValue>12</AudienceRangeValue>`
`<AudienceRangePrecision>04</AudienceRangePrecision>`
`<AudienceRangeValue>14</AudienceRangeValue>`
`</AudienceRange>`
`<AudienceRange>`
`<AudienceRangeQualifier>18</AudienceRangeQualifier>`
`<AudienceRangePrecision>03</AudienceRangePrecision>`
`<AudienceRangeValue>9</AudienceRangeValue>`
`<AudienceRangePrecision>04</AudienceRangePrecision>`
`<AudienceRangeValue>10</AudienceRangeValue>`
`</AudienceRange>`
`<Complexity>`
`<ComplexitySchemeIdentifier>06</ComplexitySchemeIdentifier>`
`<ComplexityCode>HL680L</ComplexityCode>`
`</Complexity>`

using Short tags
`<audience>`
`<b204>01</b204>`	Using ONIX audience codes
`<b206>04</b206>`	Primary and secondary/elementary and high school
`</audience>`
`<audiencerange>`
`<b074>17</b074>`	Interest age
`<b075>03</b075>`	From
`<b076>12</b076>`	Age 12
`<b075>04</b075>`	To
`<b076>14</b076>`	Age 14
`</audiencerange>`
`<audiencerange>`
`<b074>18</b074>`	Reading age
`<b075>03</b075>`	From
`<b076>9</b076>`	Age 9
`<b075>04</b075>`	To
`<b076>10</b076>`	Age 10
`</audiencerange>`
`<complexity>`
`<b077>05</b077>`	Lexile measure
`<b078>HL680L</b078>`	‘high-low’ title
`</complexity>`

This is a so-called ‘high-low’ title with an interest age higher than the reading age, suitable for reluctant readers.

Audience composite

Specifying the ‘ONIX-style’ intended audience using <Audience> is strongly preferred to using <AudienceCode>. Use <AudienceCodeType> code 01 from List 29, and the relevant value from the ONIX Audience code list, List 28.

The <Audience> composite must include an <AudienceCodeType> and an <AudienceCodeValue>.

For a proprietary audience code scheme, <AudienceCodeType> code 02 from List 29, a consistent name for the scheme should be included in <AudienceCodeTypeName>, and the meanings of the code values in the scheme must be shared in advance with the data recipients.

For products aimed at a general adult audience only (not those aimed at young adults, or those intended to be used in an educational or academic context), an additional content rating may also be supplied, using List 203. When it is supplied by the publisher, this rating can help libraries provide improved automated selections to their borrowers, or inform retailers that the product may require sensitive or specialist merchandising.

Audience range composite

Like the <Audience> composite, <AudienceRange> describes the intended readership of the product. The difference is that <AudienceRange> is intended to carry considerably more detailed specification of the suitability of a product, particularly for children and within school education.

<AudienceRange> and some audience coding schemes may reflect a separation between the ‘interest age’ of a product and the ‘reading age’ of the intended audience. Reading age is primarily a proxy measure of the complexity of the text and its relative difficulty of comprehension, and Interest age is a measure of the appeal of the subject matter of the text. With most products, the two are broadly aligned – a book of interest to seven year olds is usually written in a style suitable for seven year olds. However, the two diverge when books are intended for ‘reluctant readers’ or for emergent adult literacy, where the subject matter may be of interest to an age group notably above the reading age of the text. Titles for teenage reluctant readers may well tackle typical teen or young adult subject matter, but using language that is more normally appropriate for say, an eleven-year old.

General products (not specifically educational) aimed at a children’s or young adult audience should specify reading age and/or interest age rather than calendar age. Educational products (including those intended for home-schooling) can be specified similarly in terms of reading and/or interest age, or more specifically in terms of school year or grade within various national education systems. School year or grade is preferred where the product is closely related to a defined curriculum (primarily, textbooks), and reading/interest age if the product is a more general title for independent reading. Formal or quantitative measures of text complexity – based on intrinsic features of the text such as word length, sentence construction and vocabulary – can also be specified, in the <Complexity> composite.

When providing audience age or grade ranges, data suppliers should be as precise as possible – ranges on children’s or educational material should rarely exceed two years at the lower end of the age range, reflecting the core appeal or purpose of the content of the product. The range can be wider, perhaps three or four years, at the upper end of the children’s age range. An overly broad range – say, ages 6–11, or grades 2–7 – or open-ended ranges such as ‘ages 6+’ or ‘up to grade 7’ are much less realistic and are considerably less useful to the data recipient than a narrow range of ‘ages 8–9’. However an open-ended range such as 12+ that shades into young adult can be useful for certain types of book. Do not use overly broad ranges such as 6–11 even if the book might be applicable to a few 6- or 11-year-olds – limit the range to the core audience for the book.

Complexity composite

The <Complexity> composite is used to convey specific quantitative measures of text complexity or other objective ‘levelling’ assessments. Such information is used to select suitable material for teaching reading, matching books to the reading ability of the learner. The levelling may be carried out by the publisher – usually according to a third-party formula – or by an assessment agency. Since different educators tend to prefer different levelling schemes, it is common to provide multiple complexity measures using repeats of the <Complexity> composite.

Typical levelling or readability metrics take account of average word length or syllable count, sentence length, word frequencies such as the ratio of rare to common words, and sometimes the complexity of the sentence construction or grammar and the use of specific graded vocabularies. Presence or absence of illustrations, signposting and design, and any intertextual dependencies can also be taken into account.

A particular educational aim of some schemes is to highlight books whose text level is mismatched to its subject matter – for example where the reading age is well below or well above the interest age – as these books are particularly suitable for reluctant or advanced readers. For example, the Lexile scheme labels some books as HL (high interest age, low reading age, for reluctant readers) or NC (non-conforming, where the text and vocabulary is above the interest age of the subject mater).

ATOS text complexity scheme
using Reference names
`<Complexity>`
`<ComplexitySchemeIdentifier>07</ComplexitySchemeIdentifier>`
`<ComplexityCode>7.6</ComplexityCode>`
`</Complexity>`

using Short tags
`<complexity>`
`<b077>07</b077>`	ATOS for Books scheme, used in
`<b078>7.6</b078>`	Accelerated Reader scheme
`</complexity>`

<Complexity> was previously deprecated in ONIX 3.0, but that deprecation has now been removed. It is the recommended way of communicating formal or quantitative measures of text complexity or reading difficulty using metrics such as Lexile, Fountas and Pinnell or the Fry Readability formula.

Block 2: Marketing collateral detail

Collateral detail composite

The supply of rich descriptive and illustrative collateral material for each product is fundamental to the business rationale for ONIX.

Block 2 is intended to carry information related to marketing material associated with a product. This collateral material may be intended for either business-to-business use or business-to-consumer use – it may be aimed at the distributor’s sales team or wholesaler buyer, at the retailer or the retailer’s customer, at the librarian or the library reader. This material may include a variety of descriptive text, sample images or pages from the product, or links to material such as published reviews. Three different types of collateral material may be used:

P.14 <TextContent> composites contain descriptive text that is included within the ONIX message itself;
P.15 <CitedContent> composites contain links to third-party cited content such as published reviews;
P.16 <SupportingResource> composites contain links to first-party supporting resources such as sample images or pages.

The provision of rich descriptive and illustrative collateral material for each product is fundamental to the business rationale for ONIX. It’s use in an online consumer-facing context is clear, where descriptive metadata is a key part of engaging the customer with your product. But equally, buyers for wholesalers, retailers and libraries all need to understand the products they are purchasing.

Note that whatever collateral materials are included or linked to, they are assumed to be ‘globally’ applicable – that is, they are not intended to be specific to individual geographical markets. So for example, ONIX does not currently support the provision of different, individually-tailored front cover images for each market (where the individual markets themselves can be specified in Block 6).

P.14 Descriptions and other supporting text

Every Product record should include one or more <TextContent> composites, carrying descriptive details of the product. It is best practice to provide at least two repeats of the composite, carrying:

a short description (<TextType> code 02), a short (up to around 40 words, maximum 350 characters) description that might be displayed alongside the product in a list or group of search results;
a long description (code 03), a longer (no length restriction) description that might be displayed alongside the product on a solus catalog web page;
- where only one description can be provided and its length cannot be controlled, code 03 should be used, irrespective of its length.

Many other valuable types of text should be supplied wherever possible, including a table of contents (<TextType> code 04) and short quotations from product reviews (<TextType> code 06).

Each repeat of the composite:

must use <TextType> to specify the type of description;
must include an indication of the intended audience for the description. Recipients should take great care to limit access to the description to the specified group;
must carry the descriptive text itself in the <Text> data element;
- XHTML markup should be used within the <Text> element if anything other than a single line or paragraph of plain text is required. Use the textformat attribute to indicate the presence of any markup;
- where a particular type of descriptive text is provided in more than one language, the <Text> element should include the language attribute;
should include <TextAuthor>, <SourceTitle> or both, where the supplied text is a review or an endorsement;
it is a good practice to provide a date when the collateral text was last updated, using the <ContentDate> composite.

In some cases, publishers might place a time limitation on when a recipient can display the supplied text (particularly in a consumer context). Recipients should take great care to comply with any limits supplied in the <ContentDate> composite.

If a Product record is prepared and distributed some months before planned publication of the product, it is possible that no descriptive text of any sort is available. In this case, the entire Group can be omitted. Later updates of the ONIX message should include descriptive text.

brief product summary, formatted back cover copy and celebrity endorsement
using Reference names
`<TextContent>`
`<TextType>02</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text textformat="05"><p>The essential pocket guide to UML 2.0, now updated to cover the very latest in UML.</p></Text>`
`</TextContent>`
`<TextContent>`
`<TextType>05</TextType>`
`<ContentAudience>00</ContentAudience>`
<Text textformat="05"><p>Dan Pilone’s <em>UML 2.0 Pocket Reference</em> is a handy-sized aid for software developers who use the Unified Modelling Language.</p><p>Updated to cover the very latest in UML, it includes coverage of all the main UML diagram types:</p><ul><li>Class diagrams</li><li>Component diagrams</li><li>Sequence diagrams</li><li>Communication diagrams</li><li>Deployment diagrams</li><li>Use case diagrams</li><li>State diagrams</li></ul><p><em>UML 2.0 Pocket Reference</em> is intended for developers who are already familiar with UML, and provides a convenient, detailed reference guide.</p></Text>
`</TextContent>`
`<TextContent>`
`<TextType>09</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text textformat="05"><p>‘There no better quick reference guide for UML modellers.’</p></Text>`
`<TextAuthor>Richard Ayton, CEO, Universal Consulting LLP</TextAuthor>`
`</TextContent>`

using Short tags
`<textcontent>`
`<x426>02</x426>`	Short description
`<x427>00</x427>`	For any audience
`<d104 textformat="05"><p>The essential pocket guide to UML 2.0, now updated to cover the very latest in UML.</p></d104>`
`</textcontent>`
`<textcontent>`
`<x426>05</x426>`	Flap / cover copy
`<x427>00</x427>`	For any audience
`<d104 textformat="05">`
`<p>Dan Pilone’s <em>UML 2.0 Pocket Reference</em> is a handy-sized aid for software developers who use the Unified Modelling Language.</p>`	XHTML split over several lines for clarity only
`<p>Updated to cover the very latest in UML, it includes coverage of all the main UML diagram types:</p>`
`<ul>`
`<li>Class diagrams</li>`
`<li>Component diagrams</li>`
`<li>Sequence diagrams</li>`
`<li>Communication diagrams</li>`
`<li>Deployment diagrams</li>`
`<li>Use case diagrams</li>`
`<li>State diagrams</li>`
`</ul>`
`<p><em>UML 2.0 Pocket Reference</em> is intended for developers who are already familiar with UML, and provides a convenient, detailed reference guide.</p>`
`</d104>`
`</textcontent>`
`<textcontent>`
`<x426>09</x426>`	Endorsement
`<x427>00</x427>`	For any audience
`<d104 textformat="05"><p>‘There no better quick reference guide for UML modellers.’</p></d104>`
`<d107>Richard Ayton, CEO, Universal Consulting LLP</d107>`
`</textcontent>`

The short description and endorsement could have been provided without a textformat attribute – they contain (effectively) no markup, and the default is unformatted text. However, the cover copy requires markup such as the XHTML shown to format the multiple paragraphs and bulleted list, so the attribute must be specified.

The XHTML content in the Short tags example is formatted with extra line breaks and indented for clarity only – the unbroken XHTML in the Reference names example is exactly equivalent, except that extra white space characters (line breaks, tabs or spaces) have been added to the content of the <d104> tag. The XHTML tags and any extra white space are treated as data content by recipients, not as markup and will therefore count against any limitations on the length of text that can be stored by the recipient. As a result, the unbroken form used in the Reference example is preferred.

Although XHTML itself allows the use of named character entities like é or € (for é and €), they are not allowed within ONIX textual data with textformat 05. You can use the native characters (providing they are available in whatever encoding you declared at the top of the ONIX file) or equivalent numeric entities é and € (or the hexadecimal equivalents é or €).

Text content composite

The <TextContent> composite is the only constituent of Group P.14, and since it is optional, P.14 can be omitted if no collateral text is available. This is likely if an initial Product record is released several months in advance of publication. As descriptive text is written and approved, it should be added to the Product record, and an updated ONIX message distributed.

P.14.1 Text type code

Within each repeat of the <TextContent> composite, a <TextType> data element is mandatory, to signal the type of text included in <Text>.

Multiple repeats of the <TextContent> composite can be used to carry different types of descriptive text, distinguished by different code values from List 153 in the <TextType> data element, and possibly also by different code values from List 154 in <ContentAudience>.

In addition to the short and long descriptions, it is good practice to supply additional text types:

table of contents (code 04), particularly valuable for non-fiction products;
- use the <ContentDetail> composite (which constitutes Block 3) instead when a more detailed and structured description of the contents is required – for example where the authorship of each chapter is important, or where the product is an omnibus edition;
review quotes (codes 06, 07 or 08) and endorsements (code 09);
- reviews and endorsements should be provided with one review quote or endorsement per <TextContent> composite. It is a common error to combine several short review quotes into a single <Text> element (although sometimes this is unavoidable due to limitations within legacy data management systems);
- for review quotes and endorsements, the text in <Text> should include appropriate quotation marks;
  - use the marks suitable for the language of the quotation itself – for example ‘…’ or “…” for English, « … » for French, „…“ or ‚…‘ for German, and 「…」 or 『…』 for Japanese;
- quotations should be short, and suitable for promotional use without further permission from the copyright holder;
- where multiple quotations are provided, the order of the quotations is not significant (though equally, data recipients have little reason to change the order, and those that accept only a limited number may ignore those provided last);
- review quotes, endorsements and other text not authored by the publisher should be accompanied by a <TextAuthor> data element and – particularly for reviews – by a <SourceTitle> element;
biographical note (code 12), a combined biography of multiple contributors (but see the <BiographicalNote> element in Group P.7 for the biography of a single contributor. It is a common error to include a single contributor’s biography in Group P.14).

For some values of <TextType> there should be only a single <TextContent> composite. For some other text types, multiple <TextContent> composites can be included so long as their <ContentAudience> codes differ. For the remaining types, multiple <TextContent> composites can be included with the same or different audiences:

one – only a single <TextContent> composite with a <TextType> of 04 or 15 etc and <ContentAudience> 00 is expected, since the table of contents or index clearly cannot be varied by audience. This would apply to text types 04, 05, 15, 19, 20, 21;
one per audience – there may be multiple <TextContent> composites with a <TextType> of 02 or 03 (short or long description), but each should have a unique <ContentAudience> – so typically, either a single composite of a specific type for an unrestricted general audience, or one intended for a end-customer audience plus one tailored for the trade or press etc would be included. As far as possible the audiences should not overlap. This would apply to text types 02, 03, 12, 16, 17;
multiple – there may be multiple <TextContent> composites with a <TextType> of 06 or 09 and <ContentAudience> of 00, since for example there may be several reviews or endorsements intended for the general audience, or multiple publisher statements for the booktrade audience. This would apply to text types 06, 07, 08, 09, 10, 11, 13, 14, 18, 22.

Where a specific item of text is intended for multiple audiences, <ContentAudience> is repeatable.

There is no upper limit on the length of the <Text> element, and depending on the type of text – a review, a long description, a combined biography of several contributors, a table of contents or an except from the work itself – typical lengths vary. Short descriptions have an explicit limit of 350 characters (which is about 50 words in English). Promotional headlines, open access and digital exclusivity statements are not explicitly limited, but senders might in practice apply the same 350 character limit. Review quotations, endorsements and feature text are usually also quite short, though again not explicitly limited: a practical limit of 1000 characters (around 150 words in English) might be reasonable for senders to apply. Long descriptions and combined biographies are typically 200–400 words (or 1500–3000 characters), and a practical upper limit of 5000 characters might be reasonable for senders. Tables of contents are also unlikely to require a greater number of characters than this.

It is also possible to include a substantial excerpt of text from the product – for example the text of a first chapter, or the entire index. However, it is unreasonable to expect recipients to accept an unlimited amount of text: it is good practice to limit each excerpt <Text> element to 25,000 characters or fewer – around 3500 words in English. For larger excerpts, prior discussion with the data recipient is likely to be necessary.

Short review quotations are likely to be covered by acceptable ‘fair use’ or ‘fair dealing’ – quoting a single sentence of a review is generally fine without having to seek permission. But quoting a whole review article, or a substantial section of a review, would generally require permission to be sought from the original publisher or author of a review, and such review text should not be included in the ONIX unless permission has been obtained. (In contrast, linking to a review using Group P.15 does not require permission, but is not as often used by ONIX recipients.)

If a short description contains embedded markup (XHTML or HTML, though the former is strongly preferred), the markup counts as a part of the data – and thus must count against the 350 character limit for short descriptions. For example:

<Text textformat="05"><p>Some text.</p></Text>

contains 17 characters of data, not 10. And depending on details of the recipient’s system, any leading or trailing spaces may count too, so avoid them.

The 350 character length limit on short descriptions is fixed. For other text types, there are no fixed limits, but practical limits for senders are suggested – and delimiters such as the semicolons within a list of keywords or any embedded XHTML or HTML markup count towards these practical limits too.

Length limits are specified in characters, not bytes, as character limits are independent of the technical details of the sender and recipient systems. For example, text stored in UTF‑16 will take up a different number of bytes than the same text stored in UTF‑8 (the ratio is nearly 2:1 for simple English text, but smaller for most other languages).

A few text type codes carry special significance, in particular any Open Access statement (code 20) or statement of digital exclusivity (code 21). The very presence of these codes acts as a ‘flag’ to indicate some kind of open access or digital exclusivity. Note that the text in the <Text> element may not be blank – the <Text> element is mandatory, and may not be empty – but it may be minimal. The text should be suitable for display to the expected audience, and might simply say ‘Open access’ or ‘Digital exclusive’, or it may give further details, for example noting the type of open access (‘Available under a Creative Commons CC-By v4.0 license’) or the limits of exclusivity (‘Exclusively available as an EPUB until 15th May’). The latter – the ending of digital exclusivity – should also be confirmed with a <ContentDate> composite.

Digital exclusive
using Reference names
`<TextContent>`
`<TextType>21</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text>Exclusively available as an EPUB until 15th May</Text>`
`<ContentDate>`
`<ContentDateRole>15<ContentDateRole>`
`<Date>20140515</Date>`
`</ContentDate>`
`</TextContent>`

using Short tags
`<textcontent>`
`<x426>21</x426>`	Digital exclusivity
`<x427>00</x427>`	For any audience
`<d104>Exclusively available as an EPUB until 15th May</d104>`
`<contentdate>`
`<x429>15<x429>`	Until
`<b306>20140515</b306>`
`</contentdate>`
`</textcontent>`

In the example, digital exclusivity lasts until 15th May. It could reasonably be assumed that the publication date of a related print product is 16th May.

P.14.2 Text audience

The <ContentAudience> element must be used to specify that the text in a particular repeat of the <TextContent> composite is intended for a specific audience – typically, most text supplied is unrestricted and suitable for all audiences, but the <ContentAudience> code is particularly important where the text is intended exclusively for trade or press use, or where the text has been tailored for a specific set of potential customers – teachers, students or librarians for example.

It is particularly valuable to provide short and/or long descriptions tailored for use within the trade (ie a business-to-business description of the product), and separate descriptions tailored for presentation to the end customer.

Recipients of ONIX data must take great care that when an audience is specified, they limit visibility of the text to that particular audience. If a recipient cannot do this because of limitations in their internal systems, then they should ignore any text provided that is not marked as Unrestricted or for general end-customer use (codes 00 or 03 in List 154).

The <ContentAudience> element is repeatable, so for example, text intended for librarians and teachers – but not students – can be specified without using separate repetitions of <TextContent>.

P.14.3 Text

Every <TextContent> composite requires a <Text> element.

Text included in the <Text> element comes with an express invitation for the data recipient to use it for purposes of marketing or sale of the product. Senders including text items such as review excerpts, where rights in the text are controlled by a third party, should ensure that the excerpts are sufficiently short that they do not infringe those rights.

Simple textual material can be provided as plain text, either without a textformat attribute, or by including the attribute with value 06 (plain text). However, because of the differing XML treatment of white space characters (including tabs, line feeds and carriage returns) among different XML parsers and in different databases, multi-paragraph text or other formatting cannot reliably be delivered into a recipient’s system. For this reason, this and some other ONIX data elements can accept not only plain text but also text with embedded XHTML markup (with textformat code 05) or embedded HTML markup (with textformat code 02). If you wish to deliver multi-paragraph text or other formatting, then you must include some markup within this data element, and XHTML is strongly preferred to HTML (or other XML).

What XHTML markup can be embedded? The ONIX schema allows anything that XHTML 1.1 itself allows inside an XHTML document <body>, excluding forms, scripts, event attributes or other ‘active’ elements, and excluding special characters as named entity references. In practice, ONIX recipients are unlikely to accept such a broad range of markup, given that they are likely to embed the provided data in their own web pages. So stick to the very simplest markup: see the notes in P.7.42 for details.

Using simple XHTML markup makes it possible to provide a formatted table of contents for the product or a version history for an e-book that has been updated:

providing a simple table of contents
using Reference names – XHTML broken up for clarity
`<TextContent>`
`<TextType>04</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text textformat="05">`
`<ul>`
`<li>Preface</li>`
`<li>Chapter I – Living things</li>`
`<li>Chapter II – The plant kingdom</li>`
`<li>Chapter III – Historical survey</li>`
`<li>Chapter IV – The flowering plant</li>`
`<li>Chapter V – Special forms and functions of plant organs</li>`
`<li>Chapter VI – Food of living things</li>`
`<li>Chapter VII – Some other plant products</li>`
`<li>Chapter VIII – Enzyme action and digestion</li>`
`<li>Chapter IX – Protoplasm and the colloidal state</li>`
`<li>Chapter X – Internal organization of living things</li>`
`<li>… </li>`
`<li>Chapter XXX – Classification of angiosperms</li>`
`<li>Index</li>`
`</ul>`
`</Text>`
`</TextContent>`

using Short tags – XHTML compacted for efficiency
`<textcontent>`
`<x426>04</x426>`	Table of contents
`<x427>00</x427>`	For any audience
<d104 textformat="05"><ul><li>Preface</li><li>Chapter I – Living things</li><li>Chapter II – The plant kingdom</li><li>Chapter III – Historical survey</li><li>Chapter IV – The flowering plant</li><li>Chapter V – Special forms and functions of plant organs</li><li>Chapter VI – Food of living things</li><li>Chapter VII – Some other plant products</li><li>Chapter VIII – Enzyme action and digestion</li><li>Chapter IX – Protoplasm and the colloidal state</li><li>Chapter X – Internal organization of living things</li><li>… </li><li>Chapter XXX – Classification of angiosperms</li><li>Index</li></ul></d104>
`</textcontent>`

providing a version history
using Reference names
`<EditionNumber>3</EditionNumber>`
`<EditionVersionNumber>0.2</EditionVersionNumber>`
`. . .`
`<TextContent>`
`<TextType>19</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text textformat="05">`
`<dl>`
`<dt>3.0.2</dt>`
`<dd>Added an extra section in chapter 2</dd>`
`<dd>Added animated diagrams in chapter 4</dd>`
`<dd>`
`<p>Also fixed the following technical issues:</p>`
`<ul>`
`<li>inconsistent margin size</li>`
`<li>scrolling problem with tables in Chapter 7</li>`
`</ul>`
`</dd>`
`<dt>3.0.1</dt>`
`<dd>Corrected typos in the initial text of the Third Edition</dd>`
`</dl>`
`</Text>`
`<TextContent>`

using Short tags
`<b057>3</b057>`	Third edition
`<b217>0.2</b217>`	version 0.2
`. . .`
`<textcontent>`
`<x426>19</x426>`	Version history
`<x427>00</x427>`	For any audience
`<d104 textformat="05"><dl><dt>3.0.2</dt><dd>Added an extra section in chapter 2</dd><dd>Added animated diagrams in chapter 4</dd><dd><p>Also fixed the following technical issues:</p><ul><li>inconsistent margin size</li><li>scrolling problem with tables in Chapter 7</li></ul></dd><dt>3.0.1</dt><dd>Corrected typos in the initial text of the Third Edition</dd></dl></d104>`
`<textcontent>`

XHTML should usually be sent without extra spaces or tabs, which are used in the Reference names examples above for clarity only. Any extra ‘whitespace’ characters are unnecessary, and count against any character limits imposed for particular data elements.

Where a particular type of descriptive text needs to be delivered in multiple languages, separate repeats of the <Text> element can be used, with differing language attributes attached to each element. For example, books in both French and English are popular in France. When selling a book in English, a French online retailer may wish to display a description of the book in both French (the native language of most customers) and English (the language of the product itself):

providing the same <TextContent> in multiple languages
using Reference names
`<TextContent>`
`<TextType>02</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text language="eng" textformat="05"><p>On the eve of his death, Dr. Watson feels a duty to set down the last adventure of Sherlock Holmes…</p></Text>`
`<Text language="fre" textformat="05"><p>A la veille de sa mort, le docteur Watson se sent le devoir de coucher sur le papier la dernière aventure de Sherlock Holmes…</p></Text>`
`</TextContent>`

using Short tags
`<textcontent>`
`<x426>02</x426>`	Short description
`<x427>00</x427>`	For any audience
`<d104 language="eng" textformat="05"><p>On the eve of his death, Dr. Watson feels a duty to set down the last adventure of Sherlock Holmes…</p></d104>`	In English
`<d104 language="fre" textformat="05"><p>A la veille de sa mort, le docteur Watson se sent le devoir de coucher sur le papier la dernière aventure de Sherlock Holmes…</p></d104>`	…and in French
`</textcontent>`

If there is more than one repeat of the <Text> element within a <TextContent> composite, every one must carry a language attribute, and each should be unique.

It is not currently possible to target the text more precisely than by language (for example, it is not possible to list one text for Castillian Spanish and another for Latin American Spanish, since both would use code spa for the language attribute).

If for any reason HTML markup must be used – and it cannot be converted to XHTML – then the textformat attribute should be set to 02, and either:

the HTML content must be enclosed within an XML ‘CDATA section’, or
all HTML tags must have their initial ‘<’ character replaced by ‘<’;
the former is preferred;
see the notes on embedding HTML within P.7.42.

P.14.4 to P.14.6 Text source

Where the descriptive text in the <Text> element is a short excerpt from a review, or an endorsement, the source of the quotation should be specified. Endorsements should specify the name of the endorser in the <TextAuthor> element, and review quotes should specify the source publication in <SourceTitle>, and possibly also the name of the reviewer in <TextAuthor>.

providing multiple review quotes, naming the review authors and publications
using Reference names
`<TextContent>`
`<TextType>08</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text>‘a deeply felt and intelligently told tale, expressed in the taut style of an experienced journalist, yet conveying more — much more — than mere facts.’</Text>`
`<TextAuthor>Nuala O’Carroll</TextAuthor>`
`<SourceTitle>Financial Times</SourceTitle>`
`</TextContent>`
`<TextContent>`
`<TextType>06</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text>‘Sharp and pacy, it reads like a thriller.’</Text>`
`<TextAuthor>Evan Moore</TextAuthor>`
`<SourceTitle>City AM</SourceTitle>`
`</TextContent>`

using Short tags
`<textcontent>`
`<x426>08</x426>`	Quote from review of previous work
`<x427>00</x427>`
`<d104>‘a deeply felt and intelligently told tale, expressed in the taut style of an experienced journalist, yet conveying more – much more – than mere facts.’</d104>`	No textformat attribute or markup, so the text is in the default plain text format using encoding specified at top of file
`<d107>Nuala O’Carroll</d107>`	Review author
`<x428>Financial Times</x428>`	Review published in
`</textcontent>`
`<textcontent>`
`<x426>06</x426>`	Quote from review of this product
`<x427>00</x427>`
`<d104>‘Sharp and pacy, it reads like a thriller.’</d104>`
`<d107>Evan Moore</d107>`
`<x428>City AM</x428>`
`</textcontent>`

Where <TextAuthor> and possibly a <SourceTitle> are provided for a review or endorsement, the <Text> content would normally be enclosed in quotation marks.

<TextAuthor> is repeatable when there are multiple authors for a single review.

Where the text author is a corporate author, <TextSourceCorporate> may be used instead of <TextAuthor>. It should not be used for the corporate affiliation of the text author – affiliations should be included inside <TextAuthor> (see the example at the beginning of Section P.14).

For other types of descriptive text, the source of the text should be assumed to be the publisher and may be omitted.

Content date composite

The most critical function of the <ContentDate> composite is to specify date limits that a publisher may set to control use of any descriptive text – and specifically, to set an embargo date on the use of any text extract from the product. The composite should also be used to indicate when the collateral text was last updated.

Note also that if an sales embargo date (also known as a ‘strict on-sale date’) is specified in the <PublishingDate> composite in Group P.20 or the equivalent <MarketDate> composite in Group P.25, that embargo date applies also to any excerpt or preview of the product (ie where <TextType> is code 14 from List 153). If both sales embargo date and a specific From date are supplied, then the From date applies to the excerpt or preview material. Sales embargo dates do not affect the use of other text types.

<ContentDate> with a Content date role code 14 from List 155 (From date) is used to specify an embargo on use of the collateral text. Role code 15 (Until date) indicates when use of the supplied collateral text should end, and in particular, an Until date in the past shows the text should be taken down from any consumer-facing website.

An indication of when the collateral text was added or last updated is immensely useful for data recipients. Processing may include editorial comparisons needing expensive and time-consuming human judgement. On receipt, any Last updated date can be compared with a stored date, and unnecessarily reprocessing unchanged text can be avoided.

excerpt last updated 25th February, but embargoed until 7th March 2011
using Reference names
`<TextContent>`
`<TextType>14</TextType>`
`<ContentAudience>00</ContentAudience>`
`<Text textformat="05"><h1>Chapter 1</h1><p>It was a dark and stormy night…</p></Text>`
`<ContentDate>`
`<ContentDateRole>17</ContentDateRole>`
`<Date dateformat="00">20110225</Date>`
`</ContentDate>`
`<ContentDate>`
`<ContentDateRole>14</ContentDateRole>`
`<Date dateformat="00">20110307</Date>`
`</ContentDate>`
`</TextContent>`

using Short tags
`<textcontent>`
`<x426>14</x426>`	Excerpt
`<x427>00</x427>`	For any audience
`<d104 textformat="05"><h1>Chapter 1</h1><p>It was a dark and stormy night…</p></d104>`
`<contentdate>`
`<x429>17</x429>`	Last updated date
`<b306 dateformat="00">20110225</b306>`
`</contentdate>`
`<contentdate>`
`<x429>14</x429>`	From date
`<b306 dateformat="00">20110307</b306>`
`</contentdate>`
`</textcontent>`

<ContentDateRole> code 01 from List 155 (Publication date) refers to the nominal publication date of, for example, a newspaper review from which a quotation is taken, and not to the publication date of the product described in the Product record or the publication embargo date for any excerpt. Use code 14 (From date) to express an embargo date for use of the review snippet.

Use of <ContentDateRole> code 17 is preferred to use of the datestamp attribute to indicate the Last updated date for the collateral text.

ONIX recipients must make every effort to comply with embargo dates supplied with collateral material in this way. If a recipient cannot do this because of limitations in their internal systems, then they should ignore any descriptive text associated with a From date (code 14 on List 155) to avoid the risk of using the collateral prior to an embargo. Text provided without a From date and where no Embargo date applies to sales of the product itself should be treated as having no limitation on the earliest date it can be used.

The same effort must be made to comply with Use until dates (code 15 in List 155), and collateral text beyond its Use until date should be removed from retail websites, online catalogues etc. If a recipient’s internal system cannot support removal on the specified date, the text should not be used at all in order to avoid the risk of using the collateral beyond its end date.

The other circumstance where content dates are critical is to control the changeover of collateral materials when a product is reissued. The <Reissue> composite in Group 26 is deprecated – see the detailed notes with <Reissue>. The reissue process replaces one set of collateral material with another set. At some point in the process, where there is no gap between last availability of the old version and first availability of the new version, both old and new collateral material may be carried or referenced in the same ONIX Product record. Old material can be accompanied by an Until date (<ContentDateRole> code 15 from List 155), and new material by a From date (<ContentDateRole> code 14).

P.15 Cited content

The Cited content Group is one of the more rarely used sections of ONIX for Books. However, it has a potentially powerful use: it’s a way of tying product metadata supplied in the Product record into the wider context of the whole web. It allows links to be made between products and third-party reviews of those products, feature articles or published bestseller lists for example.

Cited content is most useful when it is available online. However, P.15 can also specify printed or broadcast content.

Citations are quite different from supporting text included in Group P.14. Firstly, supporting text is embedded in the ONIX message itself, whereas Group P.15 carries only links to other (usually online) content. Second, supporting text is clearly intended for use by the recipient in commercial activities related to the product (the implied license), whereas cited content is the intellectual property of a third party, is subject to that party’s copyright or other rights, and can only be used indirectly (ie by including a link or reference to it on a retailer website, rather than by including the cited content itself on the retailer website).

Cited content composite

If Group P.15 is used, each repeat of the <CitedContent> composite:

must use <CitedContentType> to specify the nature of the linked material;
should include an indication of the intended audience for the description. Where this is omitted, recipients may assume that the cited material is suitable for all audiences. But where it is provided, recipients should take care to limit access to the citation to the specified group;
for references to most printed or broadcast material, <CitedContent> should carry the name of the source of the cited material (eg a newspaper or magazine title, a broadcast program name), and should ideally also include the publication or broadcast date in a <ContentDate> composite;
for a reference to a specific published bestseller list or sales chart, <CitedContent> should carry the name of the list and the position reached, and should ideally also include the publication date in a <ContentDate> composite;
should include the URL for cited content that is accessible online. Note that not all cited content has to be online.

citing a review and bestseller list
using Reference names
`<CitedContent>`
`<CitedContentType>01</CitedContentType>`
`<ContentAudience>00</ContentAudience>`
`<SourceTitle>The Guardian</SourceTitle>`
`<CitationNote>Review of Jonathan Franzen’s ‘Freedom’ by Blake Morrison</CitationNote>`
`<ResourceLink>http://www.guardian.co.uk/books/2010/sep/18/jonathan-franzen-freedom-blake-morrison</ResourceLink>`
`<ContentDate>`
`<ContentDateRole>01</ContentDateRole>`
`<Date dateformat="00">20100918</Date>`
`</ContentDate>`
`</CitedContent>`
`<CitedContent>`
`<CitedContentType>02</CitedContentType>`
`<ContentAudience>00</ContentAudience>`
`<ListName>New York Times Hardcover Fiction</ListName>`
`<PositionOnList>1</PositionOnList>`
`<ContentDate>`
`<ContentDateRole>01</ContentDateRole>`
`<Date dateformat="00">20100926</Date>`
`</ContentDate>`
`</CitedContent>`

using Short tags
`<citedcontent>`
`<x430>01</x430>`	Review
`<x427>00</x427>`	Any audience
`<x428>The Guardian</x428>`
`<x434>Review of Jonathan Franzen’s ‘Freedom’ by Blake Morrison</x434>`
`<x435>http://www.guardian.co.uk/books/2010/sep/18/jonathan-franzen-freedom-blake-morrison</x435>`	URL
`<contentdate>`
`<x429>01</x429>`	Published
`<b306 dateformat="00">20100918</b306>`
`</contentdate>`
`</citedcontent>`
`<citedcontent>`
`<x430>02</x430>`	Bestseller list
`<x427>00</x427>`	Any audience
`<x432>New York Times Hardcover Fiction</x432>`
`<x433>1</x433>`	Position on list
`<contentdate>`
`<x429>01</x429>`	Published
`<b306 dateformat="00">20100926</b306>`
`</contentdate>`
`</citedcontent>`

<ContentAudience> could be omitted, as if an audience is not specified, the audience can be assumed to be unrestricted. The bestseller list cited is in fact available online, but the URL has been omitted from the citation to illustrate that not all resources need be web-accessible.

P.15.1 Cited content type code

Within each repeat of the <CitedContent> composite, a <CitedContentType> data element is mandatory.

Multiple repeats of the <CitedContent> composite can be used to carry references to various material, and the material must be classified using List 156. It is good practice to supply links to selected reviews of the product, and to any published bestseller/sales charts on which the product is prominently featured.

P.15.2 Target audience

The <ContentAudience> element should be used to specify that the cited material in a particular repeat of the <CitedContent> composite is intended for a limited audience – typically this should be used where the material is intended primarily for trade use, or more generally where a link to the material would not be appropriate in a consumer context.

Note that <ContentAudience> is optional within <CitedContent>, whereas it is mandatory within P.14 and P.16. Recipients of ONIX data should take some care that when an audience is specified, they limit visibility of any links or references to that particular audience. If a recipient cannot do this because of limitations in their internal systems, then they should ignore any citation that is not marked as Unrestricted or for general end-customer use (codes 00 or 03 in List 154). Citations provided without any specification of the target audience should be treated as Unrestricted.

P.15.3 Source type

If this data element is included, it refers to the primary medium of any cited content. For example, a review published in a (printed) literary magazine which also makes its full content available online should use code 01 (printed media) from List 157, not code 02 (website). The fact that the cited material is available online is made explicit by inclusion of a URL in the <ResourceLink> element. However, code 02 would be appropriate if the review were a ‘web exclusive’ and appeared solely on the magazine’s website (and not in the printed edition).

P.15.4 Source title

A newspaper or magazine title, or a broadcast program title, should be provided to indicate the source of a review, feature article or other media mention.

Ideally, the publication or first broadcast date of the material should also be provided in a <ContentDate> composite.

P.15.5, P.15.6 Bestseller lists

For references to published bestseller lists or sales charts, both the name of the list and the position reached should be provided.

In most cases, the name of a sponsoring publication is included in the name of the list – for example, ‘The New York Times Paperback Mass-Market Fiction’ list – so a <SourceTitle> element is unnecessary.

Ideally, the publication date of the list should also be provided in a <ContentDate> composite.

P.15.8 Resource link

If the cited material is accessible online, the full URL should be specified, including the protocol (ie the http:, https: or ftp: part).

Content date composite

The <ContentDate> composite is identical to that in Group P.14. But for cited material, the <ContentDate> composite cannot be used to provide date limits or to embargo the cited material, since access to cited content is ultimately beyond the control of either the sender or recipient of ONIX data. However, it can be used to provide an indication of the publication or broadcast date of any cited material – this is especially useful for cited material that is not available online.

P.16 Links to supporting resources

Group P.16 describes various collateral marketing material. Like P.14, it comes with an express invitation to the data recipient to use the material for purposes of marketing or sale of the product. But in contrast to collateral text in P.14, P.16 describes material that is not embedded in the ONIX message itself – it must be either linked to or downloaded. Typically, P.16 is used to deliver links to an image of the cover of a product, sample pages, audio or video extracts and other non-text material.

The Group consists entirely of the <SupportingResource> composite. It’s optional, so the entire group can be omitted if there are no supporting resources available. But for online sales, supporting resources – most especially a cover image – form an important part of the merchandising of a product, so publishers supplying ONIX data will usually wish to include at least one repeat of the composite. Where there are many supporting resources, there can be many repeats of the composite.

Supporting resource composite

The <SupportingResource> composite has a two-level structure. There should be one repeat of <SupportingResource> for each ‘resource’. The resource has a ‘type’, which might specify that it is a front cover, or some sample audiobook content, and a ‘mode’, which might specify audio or a still image. A resource can be associated with a caption or credit via the <ResourceFeature> composite. Then within a particular <SupportingResource> composite, a single resource can be available in different versions, each described within a <ResourceVersion> composite. Resource versions are different ‘renderings’ of the same resource – high and low quality versions of an image, for example, or .wav and .mp3 versions of the same audio clip. Each version may be associated with various features that are unique to that version in <ResourceVersionFeature>, and may also be subject to limitations on when it can be used.

Every Product record should include at least one <SupportingResource> composite, specifying a link to some type of product image. It is best practice to supply at least a cover image (or equivalent).

Each <SupportingResource> composite:

must use <ResourceContentType> to specify the type of resource, and <ResourceMode> to specify whether it’s an audio, video, still image or text resource;
must include an indication of the intended audience for the resource. Recipients should take great care to limit access to the resource material to the specified group;
should specify any captions or required credits associated with the resource material. When specified, recipients must take great care that required credits are displayed alongside the resource;
must describe at least one version of the resource that recipients can either link to or download and use. A URL for the version must be included;
should always use the <ContentDate> composite to indicate when a downloadable resource was last updated.

In some cases, publishers might place a time limitation on when a recipient can link to or display the specified resource material (particularly in a consumer context). Recipients should take great care to comply with any limits supplied in the <ContentDate> composite.

Recipients should not mandate a specific naming scheme for downloadable resource files – if necessary, resources should be renamed according to the recipient’s specific requirements as they are downloaded from the provided URL and stored in the recipient’s system.

If a Product record is prepared and distributed some months before planned publication of the product, it is possible that no resource material of any sort is available. In this case, the entire Group can be omitted. Later updates of the ONIX message should include relevant supporting resources. Providing generic ‘cover not yet available’ images is not recommended practice.

The <ResourceForm> element is most often used to indicate whether the resource version will be hosted by the ONIX supplier (or a third party) – in which case the ONIX recipient should use the URL provided as the src attribute in an HTML <img> or <a> link – or whether the ONIX recipient should download the resource from the URL provided and use that independent copy of the file.

It is best practice to provide at least:

a high-quality cover image (or equivalent) at least 640 pixels (and probably no more than 1000 pixels) in smallest dimension;
- some major e-book vendors request images of much higher quality, up to 1600 pixels in smallest dimension, to provide optimized images for high-resolution tablet devices, but also place file size limits on images (eg no more than 5MB file size);
- images should be flat (not 3D perspective views), cropped so that no background is shown;
- image files should be sRGB colorspace, 24 bits per pixel color depth, JPEG with no clearly visible artefacts;
- it is good practice to attach an ICC color profile to the image, particularly if a colorspace other than sRGB is used (for example, the wider-gamut Adobe RGB). CMYK should be avoided;
- a TIFF version may also be supplied for download by the recipient (other details as above);
- note that no fixed resolution is recommended – it is the number of pixels in the image that is important, as the resolution depends not only on the image itself, but also on the size it is reproduced at by the ONIX recipient;
a ‘thumbnail’ cover image (or equivalent) at a size of 125 pixels in smallest dimension;
- thumbnail files should be JPEG only, but otherwise as for high-quality images;
- it may be useful to ‘simplify’ thumbnail images, as important details of the large images may not be visible when reduced in size;
the high-quality JPEG, a TIFF and the thumbnail JPEG files would usually be versions of the same resource, using <ResourceContentType> code 01 from List 158;
- if a 3D perspective view of the book showing the cover is also provided, use code 03;
for multi-volume products – for example, four paperbacks in a slipcase – multiple images (multiple resources) may be provided;
- the decorative box cover or a ‘3D’ image of the slipcase may be more appropriate;
for products containing audio content, an audio excerpt of around 2–5 minutes length;
- audio files should be MP3 or AAC, mono or stereo, 44.1kHz sample rate, 64kbits per channel per second data rate;
- a ‘CD-quality’ WAV or AIFF version may also be supplied (mono or stereo, 44.1kHz or 48kHz sample rate, 16 bits per channel per sample) for download by the recipient;
low- and high-quality audio files, or two files of equivalent quality but using different codecs, would be different versions of the same audio resource, using code 15 from List 158;
for products that are not flat and rectangular, products where the style of packaging is important, or other products which do not have a conventional cover (eg boxed products, toys or other merchandise, point-of-sale material such as dumpbins etc), an image of the product in 3D perspective – a photograph or digital rendering – should be supplied instead, using <ResourceContentType> code 03 from List 158;
- the background behind product images should be predominantly white.

Images where the width is fixed (eg at 125 pixels) should vary in height according to the aspect ratio of the product (and of course, vice versa). Images should never be distorted to fit a specific shape.

Other types of resource that may commonly be provided are:

portrait images of contributors, as high-quality or thumbnail images – best practice for these images should follow that for covers above;
sample content, eg as text, JPEG images of sample spreads, or PDF, HTML or EPUB-format files that can be read on most e-reading devices;
downloadable reading guides for book groups, as text, PDF, HTML, or as an EPUB-format files;
embeddable applications, or sample content in the form of an embeddable ‘widget’ (a book-preview application). Note that for most resources, the URL is the resource (<ResourceForm> code 01), or the resource itself is downloaded from the URL specified in <ResourceLink> (<ResourceForm> code 02). In contrast, embeddable applications and widgets:
- require an <iframe> or <object> to be embedded into the ONIX recipient’s web page;
- the code to embed should be downloaded from the URL in <ResourceLink>;
- these embeddable resources should carry <ResourceMode> code 01 and <ResourceForm> code 03.
Note that other ‘widgets’ are simple URLs linking to stand-alone websites. The URL in <ResourceLink> is usually the target of a link on the recipient’s web page – nothing need be downloaded by the ONIX recipient;
- these resources should carry <ResourceMode> code 06 and <ResourceForm> code 01.

Filenames for these resources may be arbitrary, in that the filename is carried as part of the URL in in the <ResourceLink> data element and need not comply with any predetermined naming scheme. Since the resources are in most cases intended for downloading by the ONIX recipient, and will in most cases be processed to produce images of sized specifically for the recipient’s website, catalog etc, the recipient may rename the file for their own convenience at that time. However, senders may at least find it convenient to incorporate the ISBN of the product, or the ONIX <RecordReference> from Group P.1, in the filename.

It should be noted that it’s common for suppliers to make the same supporting resources such as cover and audio samples available also to supply chain partners who are not themselves ONIX recipients. In these cases, it is much more important to follow a predetermined naming scheme that also describes the nature of the resource. A simple scheme is used in the examples below, and more comprehensive guidelines are available on the EDItEUR website.

Downloadable resources: front cover resource as thumbnail and high quality images, plus embargoed audio excerpt of author reading content from the product
using Reference names
`<SupportingResource>`
`<ResourceContentType>01</ResourceContentType>`
`<ContentAudience>00</ContentAudience>`
`<ResourceMode>03</ResourceMode>`
`<!-- no <ResourceFeature> composite needed -->`
`<ResourceVersion>`
`<ResourceForm>01</ResourceForm>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>01</ResourceVersionFeatureType>`
`<FeatureValue>D502</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>03</ResourceVersionFeatureType>`
`<FeatureValue>125</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceLink>http://www.publisher.com/b2b/covers/9780001234567-fc125px.jpg</ResourceLink>`
`<ContentDate>`
`<ContentDateRole>17</ContentDateRole>`
`<Date dateformat="00">20101117</Date>`
`</ContentDate>`
`</ResourceVersion>`
`<ResourceVersion>`
`<ResourceForm>02</ResourceForm>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>01</ResourceVersionFeatureType>`
`<FeatureValue>D502</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>03</ResourceVersionFeatureType>`
`<FeatureValue>650</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceLink>http://www.publisher.com/b2b/covers/9780001234567-fc650px.jpg</ResourceLink>`
`<ContentDate>`
`<ContentDateRole>17</ContentDateRole>`
`<Date dateformat="00">20101117</Date>`
`</ContentDate>`
`</ResourceVersion>`
`<ResourceVersion>`
`<ResourceForm>02</ResourceForm>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>01</ResourceVersionFeatureType>`
`<FeatureValue>D504</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>03</ResourceVersionFeatureType>`
`<FeatureValue>1535</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceLink>http://www.publisher.com/b2b/covers/9780001234567-fc300dpi.tif</ResourceLink>`
`<ContentDate>`
`<ContentDateRole>17</ContentDateRole>`
`<Date dateformat="00">20101117</Date>`
`</ContentDate>`
`</ResourceVersion>`
`</SupportingResource>`
`<SupportingResource>`
`<ResourceContentType>13</ResourceContentType>`
`<ContentAudience>00</ContentAudience>`
`<ResourceMode>02</ResourceMode>`
`<ResourceFeature>`
`<ResourceFeatureType>04</ResourceFeatureType>`
`<FeatureValue>3</FeatureValue>`
`</ResourceFeature>`
`<ResourceFeature>`
`<ResourceFeatureType>02</ResourceFeatureType>`
`<FeatureNote textformat="05"><p>Ferenc Júlia reading an excerpt from Petőfi Sándor’s poem <em>A régi, jó Gvadányi</em> (in Hungarian)</p></FeatureNote>`
`</ResourceFeature>`
`<ResourceVersion>`
`<ResourceForm>02</ResourceForm>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>01</ResourceVersionFeatureType>`
`<FeatureValue>A103</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceLink>http://www.publisher.com/b2b/audio/9780001234567-ex300s.mp3</ResourceLink>`
`<ContentDate>`
`<ContentDateRole>17</ContentDateRole>`
`<Date dateformat="00">20110114</Date>`
`</ContentDate>`
`<ContentDate>`
`<ContentDateRole>14</ContentDateRole>`
`<Date dateformat="00">20110117</Date>`
`</ContentDate>`
`</ResourceVersion>`
`</SupportingResource>`

using Short tags
`<supportingresource>`	First resource
`<x436>01</x436>`	Front cover
`<x427>00</x427>`	For any audience
`<x437>03</x437>`	Still image
`<!-- no <ResourceFeature> needed -->`
`<resourceversion>`	First version of resource #1
`<x441>01</x441>`	Linkable file
`<resourceversionfeature>`
`<x442>01</x442>`	File format
`<x439>D502</x439>`	JPEG
`</resourceversionfeature>`
`<resourceversionfeature>`
`<x442>03</x442>`	Width
`<x439>125</x439>`	125 pixels
`</resourceversionfeature>`
`<x435>http://www.publisher.com/b2b/covers/9780001234567-fc125px.jpg</x435>`
`<contentdate>`
`<x429>17</x429>`	Last updated
`<b306 dateformat="00">20101117</b306>`
`</contentdate>`
`</resourceversion>`
`<resourceversion>`	Second version of resource #1
`<x441>02</x441>`	Downloadable file
`<resourceversionfeature>`
`<x442>01</x442>`	File format
`<x439>D502</x439>`	JPEG
`</resourceversionfeature>`
`<resourceversionfeature>`
`<x442>03</x442>`	Width
`<x439>650</x439>`	650 pixels
`</resourceversionfeature>`
`<x435>http://www.publisher.com/b2b/covers/9780001234567-fc650px.jpg</x435>`
`<contentdate>`
`<x429>17</x429>`	Last updated
`<b306 dateformat="00">20101117</b306>`
`</contentdate>`
`</resourceversion>`
`<resourceversion>`	Third version of resource #1
`<x441>02</x441>`	Downloadable file
`<resourceversionfeature>`
`<x442>01</x442>`	File format
`<x439>D504</x439>`	TIFF
`</resourceversionfeature>`
`<resourceversionfeature>`
`<x442>03</x442>`	Width
`<x439>1535</x439>`	1535 pixels
`</resourceversionfeature>`
`<x435>http://www.publisher.com/b2b/covers/9780001234567-fc300dpi.tif</x435>`
`<contentdate>`
`<x429>17</x429>`	Last updated
`<b306 dateformat="00">20101117</b306>`
`</contentdate>`
`</resourceversion>`
`</supportingresource>`
`<supportingresource>`	Second resource
`<x436>13</x436>`	Contributor reading
`<x427>00</x427>`	For any audience
`<x437>02</x437>`	Audio
`<resourcefeature>`
`<x438>04</x438>`	Length
`<x439>3</x439>`	3 minutes
`</resourcefeature>`
`<resourcefeature>`
`<x438>02</x438>`	Caption
`<x440 textformat="05"><p>Ferenc Júlia reading an excerpt from Petőfi Sándor’s poem <em>A régi, jó Gvadányi</em> (in Hungarian)</p></x440>`	With XHTML markup
`</resourcefeature>`
`<resourceversion>`	Sole version of resource #2
`<x441>02</x441>`	Downloadable file
`<resourceversionfeature>`
`<x442>01</x442>`	File format
`<x439>A103</x439>`	MP3
`</resourceversionfeature>`
`<x435>http://www.publisher.com/b2b/audio/9780001234567-ex300s.mp3</x435>`
`<contentdate>`
`<x429>17</x429>`	Last updated
`<b306 dateformat="00">20110114</b306>`
`</contentdate>`
`<contentdate>`
`<x429>14</x429>`	Embargoed until
`<b306 dateformat="00">20110117</b306>`
`</contentdate>`
`</resourceversion>`
`</supportingresource>`

Note the three different versions of the first resource – a thumbnail JPEG, a medium-sized JPEG and a large TIFF, all versions of a single cover image. Why are these differentiated by pixel dimension rather than resolution? Generally a ‘low-res’ or ‘screen res’ image is something around 75–100 pixels per inch (or around 30–40 pixels per cm), and a high-res image is generally at least 300 pixels per inch (120 pixels per cm). So an image that is 225 pixels in width is ‘screen resolution’ if it is printed or displayed at 7.5cm across (because 225 ÷ 7.5 = 30 pixels per cm). Yet exactly the same 225 pixel JPEG is ‘high-res’ if it is displayed it at 1.5cm across (225 ÷ 1.5 = 150 pixels per cm). Digital images don’t have an inherent ‘resolution’ – only a number of pixels – and the eventual resolution depends on the physical size when the image is displayed or printed. (In some circumstances, a resolution or physical size can be described in separate metadata attached to an image, but this is really just a ‘preferred display size’, not an inherent property of the image.)

Different versions of the same resource may have differing resource forms – the thumbnail sized cover image is linkable whereas the larger cover image files are downloadable.The defining feature of a downloadable resource is that the resource must be downloaded by the ONIX recipient, and to display that resource to consumers, a new copy must be hosted on a server independently of the original data supplier. In contrast, for a linkable resource, the ONIX recipient may use the URL eg as the src attribute in an <img> tag, as hosting services for the resource will be provided by the data supplier.

Linkable resources: linking to the publisher’s reading group guide
using Reference names
`<SupportingResource>`
`<ResourceContentType>19</ResourceContentType>`
`<ContentAudience>03</ContentAudience>`
`<ContentAudience>04</ContentAudience>`
`<ResourceMode>04</ResourceMode>`
`<ResourceFeature>`
`<ResourceFeatureType>02</ResourceFeatureType>`
`<FeatureNote textformat="06">Download the Reading Group guide</FeatureNote>`
`</ResourceFeature>`
`<ResourceVersion>`
`<ResourceForm>01</ResourceForm>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>01</ResourceVersionFeatureType>`
`<FeatureValue>D401</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceLink>http://www.publisher.com/b2c/rguides/9780001234567-rgg.pdf</ResourceLink>`
`</ResourceVersion>`
`</SupportingResource>`

using Short tags
`<supportingresource>`
`<x436>19</x436>`	Reading group guide
`<x427>03</x427>`	For end customers
`<x427>04</x427>`	and Librarians
`<x437>04</x437>`	Primarily text
`<resourcefeature>`
`<x438>02</x438>`	Caption
`<x440 textformat="06">Download the Reading Group guide</x440>`
`</resourcefeature>`
`<resourceversion>`
`<x441>01</x441>`	Linkable resource
`<resourceversionfeature>`
`<x442>01</x442>`	File format
`<x439>D401</x439>`	PDF
`</resourceversionfeature>`
`<x435>http://www.publisher.com/b2c/rguides/9780001234567-rgg.pdf</x435>`
`</resourceversion>`
`</supportingresource>`

For linkable resources, the supplied URL can be added to the recipient’s web page in numerous ways. The simplest is as the href attribute of a link:

<p><a href="http:/www.publisher.com/b2c/rguides/9780001234567-rgg.pdf" rel="external">Download the Reading Group Guide</a></p>

If the linked resource is a simple image, it might be used like this. Note the use of the supplied caption as alt text to improve accessibility:

<img src="http:/www.publisher.com/b2c/covers/9780001234567-fc125px.jpg" width="125" alt="Front cover of No Logo by Naomi Klein" />

The defining feature of a linkable resource is that it is the publisher or some third party that will host the resource: the ONIX recipient need not keep their own copy, and is invited to link to the primary version. However, note that some retailers are reluctant to use such linkable resources. They may of course download a copy and host it themselves, subject to any license terms pertaining to the resource.

Embeddable resources: supplying details of an embeddable application (eg a YouTube video player)
using Reference names
`<SupportingResource>`
`<ResourceContentType>13</ResourceContentType>`
`<ContentAudience>00</ContentAudience>`
`<ResourceMode>01</ResourceMode>`
`<ResourceFeature>`
`<ResourceFeatureType>04</ResourceFeatureType>`
`<FeatureValue>5</FeatureValue>`
`</ResourceFeature>`
`<ResourceFeature>`
`<ResourceFeatureType>02</ResourceFeatureType>`
`<FeatureNote textformat="06">The author reads her story to an audience of schoolchildren</FeatureNote>`
`</ResourceFeature>`
`<ResourceVersion>`
`<ResourceForm>03</ResourceForm>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>02</ResourceVersionFeatureType>`
`<FeatureValue>640</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>03</ResourceVersionFeatureType>`
`<FeatureValue>390</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceLink>http://www.publisher.com/b2b/embed/9780001234567-youtube.txt</ResourceLink>`
`</ResourceVersion>`
`</SupportingResource>`

using Short tags
`<supportingresource>`
`<x436>13</x436>`	Contributor reading
`<x427>00</x427>`	For any audience
`<x437>01</x437>`	Application
`<resourcefeature>`
`<x438>04</x438>`	Length
`<x439>5</x439>`	5 minutes
`</resourcefeature>`
`<resourcefeature>`
`<x438>02</x438>`	Caption
`<x440 textformat="06">The author reads her story to an audience of schoolchildren</x440>`
`</resourcefeature>`
`<resourceversion>`
`<x441>03</x441>`	Embeddable application
`<resourceversionfeature>`
`<x442>03</x442>`	Width
`<x439>640</x439>`	640 pixels
`</resourceversionfeature>`
`<resourceversionfeature>`
`<x442>02</x442>`	Height
`<x439>390</x439>`	390 pixels
`</resourceversionfeature>`
`<x435>http://www.publisher.com/b2b/embed/9780001234567-youtube.txt</x435>`	URL
`</resourceversion>`
`</supportingresource>`

Querying the specified URL should return a text file containing HTML or other embeddable application code that may be embedded in the recipient’s web page. For a YouTube video, the URL should return a text snippet something like:

<iframe type="text/html" title="YouTube player" class="youtube-player" src="http://www.youtube.com/embed/9780001234567?rel=0" frameborder="0" width="640" height="390" allowFullScreen</iframe>

Adding this chunk of HTML to a web page within the ONIX recipient’s online store embeds the YouTube video on the page. The height and width of the resource should be provided in the <ResourceVersionFeature> composite so the recipient can control the page layout automatically.

Note that that this is not the only way of specifying a link to a YouTube video (or similar) – it is used here simply an example of a chunk of embeddable code.

P.16.1 Resource content type code

<ResourceContentType> is used to indicate what the resource is, independent of the way that it’s delivered.

P.16.2 Target audience

As with P.14 Descriptions and other supporting text, and as recommended with P.15 Cited content, the <ContentAudience> element must be used to specify when the specified resource is intended for a limited audience – typically this should be used where the material is intended primarily for trade use, or more generally where a link to the material would not be appropriate in a consumer context. The element is mandatory in Group P.16, so if there is no restriction, <ContentAudience> could carry codes 00 or 03.

P.16.3 Resource mode

<ResourceMode> adds detail to the nature of the resource specified in <ResourceContentType>. For example, an interview with a contributor might be delivered primarily as text, as audio or as video – all three would have the same value for <ResourceContentType> (specifically, they would all use code 11 from List 158), but they would have different values for <ResourceMode> (List 159 codes 04, 02 and 05 respectively).

Resources with differing resource modes – back cover image and back cover text
using Reference names
`<SupportingResource>`
`<ResourceContentType>02</ResourceContentType>`
`<ContentAudience>00</ContentAudience>`
`<ResourceMode>03<ResourceMode>`
`<ResourceVersion>`
`<ResourceForm>02</ResourceForm>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>01</ResourceVersionFeatureType>`
`<FeatureValue>D502</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>02</ResourceVersionFeatureType>`
`<FeatureValue>125</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceLink>http://www.publisher.com/b2b/covers/9780001234567-bc125px.jpg</ResourceLink>`
`</ResourceVersion>`
`</SupportingResource>`
`<SupportingResource>`
`<ResourceContentType>02</ResourceContentType>`
`<ContentAudience>00</ContentAudience>`
`<ResourceMode>04<ResourceMode>`
`<ResourceVersion>`
`<ResourceForm>02</ResourceForm>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>01</ResourceVersionFeatureType>`
`<FeatureValue>E112</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceLink>http://www.publisher.com/b2b/covers/9780001234567-text.txt</ResourceLink>`
`</ResourceVersion>`
`<SupportingResource>`

using Short tags
`<supportingresource>`	First resource
`<x436>02</x436>`	Back cover
`<x427>00</x427>`	For any audience
`<x437>03<x437>`	Image
`<resourceversion>`
`<x441>02</x441>`	Downloadable file
`<resourceversionfeature>`
`<x442>01</x442>`	File format
`<x439>D502</x439>`	JPEG
`</resourceversionfeature>`
`<resourceversionfeature>`
`<x442>02</x442>`	Width in pixels
`<x439>125</x439>`
`</resourceversionfeature>`
`<x435>http://www.publisher.com/b2b/covers/9780001234567-bc125px.jpg</x435>`	URL
`</resourceversion>`
`</supportingresource>`
`<supportingresource>`	Second resource
`<x436>02</x436>`	Back cover
`<x427>00</x427>`	For any audience
`<x437>04<x437>`	Text
`<resourceversion>`
`<x441>02</x441>`	Downloadable file
`<resourceversionfeature>`
`<x442>01</x442>`	File format
`<x439>E112</x439>`	Plain text
`</resourceversionfeature>`
`<x435>http://www.publisher.com/b2b/covers/9780001234567-text.txt</x435>`	URL
`</resourceversion>`
`<supportingresource>`

There are two resources here, an image of the back cover and the text from the back cover, distinguished by their <ResourceMode>. (Note text from the jacket flaps should be treated as back cover copy.)

Resource feature composite

The <ResourceFeature> is used to specify features shared by all versions of a particular resource – for example a caption or a required credit, or the running time of a video or audio resource.

It is best practice to use <ResourceFeature> to attach a caption to any image of a contributor, to identify the contributor. Normally the caption should simply be the name of the contributor, but if the image shows several people, it should carry more explanation:

using Reference names
`<ResourceFeature>`
`<ResourceFeatureType>02<ResourceFeatureType>`
`<FeatureNote>Michael Marshall, left, with agent Jonny Geller</FeatureNote>`
`</ResourceFeature>`

using Short tags
`<resourcefeature>`
`<x438>02<x438>`	Caption
`<x440>Michael Marshall, left, with agent Jonny Geller</x440>`
`</resourcefeature>`

If required, captions and credits can carry XHTML markup, but this is rarely necessary.

Note that credits specified with <ResourceFeatureType> code 01 are required, and displaying the credit alongside the resource (eg on a retailer website) should be treated by ONIX recipients as a condition of use of the resource.

Resource version composite

The <ResourceVersion> composite describes a particular version of a resource: there may be other versions in subsequent repeats of the composite – for example high quality and thumbnail versions of an image, highly-compressed and CD-quality versions of audio, or video content compressed using different codecs.

P.16.7 Resource form

This element is used to differentiate between:

‘downloadable resources’ – URLs from which an ONIX recipient may download a resource, for example an image that can then be added to the catalog page. Practically, these might be http:, https: or ftp: protocol URIs from which a resource such as an image or other file may be downloaded;
‘linkable resources’ that are simply URLs that the recipient might add to a web page (for example, a catalog page within an online store might list a variety of URIs leading to further information). For practical purposes, these will be http: or https: protocol URIs, and would most likely be used as the value of a src attribute of an <img> tag or the value of an href attribute of an <a> tag;
- this is sometimes known as ‘deep linking’;
- linkable resources are also – by their nature – often downloadable too, but recipients should use resources in the manner intended by the provider;
‘embeddable resources’, URLs from which the recipient may download embeddable HTML snippets (for example, <iframe> or <object> content that should be embedded into the catalog page).

In all cases, the URL itself is specified in the <ResourceLink> data element, but the manner in which it should be used depends on the Resource form.

Resource version feature composite

The <ResourceVersionFeature> composite is used to specify various features of a particular version of resource – for example the file format and pixel size of an image, or the filesize of any necessary download.

It is best practice to provide at least the following metadata ‘features’ for each resource version:

for image and video resources, the pixel dimensions;
for all types of resources, the file format;
for time-based resources such as audio and video, the running time should be provided (in the <ResourceFeature> composite, not in <ResourceVersionFeature>).

Note the difference between <ResourceFeature> which carries attributes shared by all versions of a resource, and <ResourceVersionFeature> which carries attributes applying to a single specific version of that resource.

P.16.11 Resource link

The Resource link must be a URL: since the link provided might use either http:, https: or ftp:, you should normally include the protocol part of the URI, and not just a web address like ‘www.editeur.org/images/pic1.jpeg’. A complete, or ‘absolute’ URI normally looks something like ‘http://www.editeur.org/images/pic1.jpeg’, including protocol, server name, folder or directory path and the file name.

However, it is possible to specify a ‘relative’ URI instead – this might look like ‘images/pic1.jpeg’ or even just ‘pic1.jpeg’, and in this case, the implied location of the resource depends on the actual location of the ONIX file itself. This option should only be used when ONIX message is delivered to the recipient in such a way that the resource is guaranteed to exist at that relative address. This might be the case if the ONIX message and associated resources are on the same server, or if the ONIX file and the associated resources are delivered to the recipient in a predictable or neatly packaged way (eg in a single ZIP file). Note that moving either the ONIX message file or the resources invalidates all the relative URIs (though moving both without changing their relative location is fine). This relative URI option should not be used to deliver a simple filename, where the relative location of the ONIX message file and the resource is not fixed – a relative URI such as ‘pic1.jpeg’ is not a simple filename, but means that the resource must be in the same folder or directory, on the same server as the ONIX file itself, and that it can be accessed using the same protocol.

using a relative URI
using Reference names
`<ResourceLink>covers/9780007232833-fc500.jpeg</ResourceLink>`

using Short tags
`<x435>covers/9780007232833-fc500.jpeg</x435>`

In this example, if the ONIX message itself is at the address
ftp://www.publisher.com/onix/130719.xml
then the cover image file must be found at
ftp://www.publisher.com/onix/covers/9780007232833-fc500.jpeg.

A relative URI starting with a ‘/’ means ‘relative to the root directory of the server’ rather than relative to the location of the ONIX file. This should never be used in ONIX.

In the special case where an ONIX file and the resources are packaged inside a single ZIP file, ensure when zipping that the ONIX file is in the current directory.

The resource specified should be accessible to all ONIX recipients (for downloadable resources and embeddable resources), or accessible to all internet users (for linkable resources). Downloadable or embeddable resources may require account credentials, for example, a username and password to access, where these credentials are shared with ONIX recipients in advance. Linkable resources may not.

Instead of the URI carrying a link to the image data, it is possible to embed the actual image inside the URI, using the data: URI scheme [this technique is used to embed the EDItEUR logo within this document]. In this case, the URI is the data, and nothing need be downloaded by the recipient. While technically interesting, this is not recommended at present in ONIX. It may be a viable way to carry thumbnail-sized JPEG images or small embeddable resources (such as the YouTube video player example above) in the future.

embedding image data within a URI (not recommended)
using Reference names
`<ResourceLink>data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+IIJElDQ19QUk9GSUxFAAEBAAAIFEFEQkUCQAA . . . /yR/yfz/yx+V/i/vfhoAWx+ce3zj/L2P8AXoA//9k=</ResourceLink>`

using Short tags
`<x435>data:image/jpeg;base64,/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHV . . . /yR/yfz/yx+V/i/vfhoAWx+ce3zj/L2P8AXoA//9k=</x435>`

Content date composite

The most critical function of the <ContentDate> composite is to specify date limits that a publisher may set to control use of any supporting resources – most pointedly, to set an embargo date on the use of any cover image or text extract from the product. The composite should also be used to indicate when the collateral resource was last updated. See the notes in Group P.14 on the use of <ContentDate>.

Note that a date with <ContentDateRole> code 17 (Last updated) is of critical importance when dealing with downloaded or embedded resources, and it should always be used by data providers to indicate a new version of the resource is available. Recipients should check this date and re-download a new version of the resource whenever required. Note that use of <ContentDateRole> code 17 is preferred to use of the datestamp attribute to indicate the Last updated date for the resource.

Timed cover reveal: embargo on use of cover image
using Reference names
`<ResourceVersion>`
`<ResourceForm>02</ResourceForm>`
`<ResourceVersionFeature>`
`<ResourceVersionFeatureType>03</ResourceVersionFeatureType>`
`<FeatureValue>1750</FeatureValue>`
`</ResourceVersionFeature>`
`<ResourceLink>http://www.sagepublications.com/covers/9780001234567.jpeg</ResourceLink>`
`<ContentDate>`
`<ContentDateRole>27</ContentDateRole>`
`<Date dateformat="00">20141021</Date>`
`</ContentDate>`
`<ContentDate>`
`<ContentDateRole>14</ContentDateRole>`
`<Date dateformat="13">20141023T1200Z</Date>`
`</ContentDate>`
`</ResourceVersion>`

using Short tags
`<resourceversion>`
`<x441>02</x441>`	Downloadable resource
`<resourceversionfeature>`
`<x442>03</x442>`	Width in pixels
`<x439>1750</x439>`
`</resourceversionfeature>`
`<x435>http://www.sagepublications.com/covers/9780001234567.jpeg</x435>`
`<contentdate>`
`<x429>27</x429>`	Available from
`<b306 dateformat="00">20141021</b306>`	21st October
`</contentdate>`
`<contentdate>`
`<x429>14</x429>`	Use from (ie embargoed until)
`<b306 dateformat="13">20141023T1200Z</b306>`	noon (UTC) on 23rd October
`</contentdate>`
`</resourceversion>`

In this example, the cover will be available for download from 21st October, but must not be used (displayed) to consumers until the embargo expires at noon on 23rd October.

P.17 Prizes

Best practice is to list key prizes and awards gained by the product itself – or perhaps more often, by the work manifested in the product. So for example a literary prize awarded to a work when the hardcover was the only version available, applies equally to the softcover, and should be listed in the ONIX Product record for both versions. However, an award for exceptional quality printing and binding likely applies to only one version, and should not be listed on the other. If a product has been awarded nothing (so far!) then the entire Group should be omitted.

Generalized awards given to contributors should not be listed here, nor should awards given to other works by the same contributor etc.

Prize or award composite

Winner of the 2010 Prix Renaudot
using Reference names
`<Prize>`
`<PrizeName>Prix Renaudot</PrizeName>`
`<PrizeYear>2010</PrizeYear>`
`<PrizeCode>01</PrizeCode>`
`<PrizeStatement>Lauréat du Prix Renaudot 2010</PrizeStatement>`
`</Prize>`

using Short tags, with alternative language prize statements
`<prize>`
`<g126>Prix Renaudot</g126>`
`<g127>2010</g127>`
`<g129>01</g129>`	Winner
`<x503 language="fre">Lauréat du Prix Renaudot, 2010</x503>`
`<x503 language="eng">Winner of the Prix Renaudot, 2010</x503>`
`</prize>`

<PrizeCode> should always be included, even if the particular prize does not name a runner up or a shortlist. Not all prizes use the long-list / short-list / winner terminology from List 41 to denote degrees of success. A particular prize may use terminology like ‘nominated’, ‘semi-finalist’ or any other term. If the term used indicates that a book is selected by the judging panel for the final category before the winner is announced – as does semi-finalist, for example – then ‘short listed’ (code 04) is a reasonable choice in <PrizeCode>. For a prize like the Newbery Medal, the Medal-winning book may be termed the ‘winner’ (<PrizeCode> 01) and Honor books as ‘commended’ (code 03). In all cases, an additional <PrizeStatement> can make it clear what the proper terminology is for the particular prize.

It may occasionally be useful to list the country in which an award is given within a <Prize> composite – for example, with works in translation, awards given to the original language version may be unfamiliar to potential readers of the translated version.

If a product or work has been awarded multiple prizes, each should be listed in a separate repeat of the <Prize composite. In XML terms, the order they are listed in is not significant: however, it is best practice to list them in descending order of prestige – some ONIX recipients may only retain and use information on the first few repeats of the composite, and providing a very high number of prizes – say more than ten – is unnecessary and undesirable.

There is no option to list prizes and awards in a free-text manner within Group P.17. If a structured description of prizes and awards is not available, then data providers could include a free-text description as part of the normal descriptive text provided in <TextContent> within Group P.14.

Block 3: Content detail

Content detail composite

Block 3 – the <ContentDetail> composite – contains one or more repeats of the <ContentItem> composite. It’s intended to allow the structured description of articles, chapters and other parts of a textual publication, usually in much more detail than a single table of contents. <ContentDetail> is appropriate for describing books in an omnibus, chapters in a book, articles in a scholarly monograph or conference report, poems in an anthology and can provide much more detail about volumes in a collection sold as a multi-item product (commonly called a ‘set’) than could be included in <ProductPart> in Group P.4 (<ProductPart> is concerned only with the physical or digital nature of the individual items, and not their titles, collation order, authorship and so on). The entire composite is unnecessary for simple fiction or narrative non-fiction products where a table of contents is more simply provided in Group P.14, and in many cases might be omitted entirely.

The <ContentItem> composite that forms Block 3 of a Product record should be used to describe a detailed table of contents of a single-item product, or the constituent parts of a multi-item product, particularly where items in that table or list might be available individually, or where there is collateral material that applies to the parts individually.

The entire Block should be omitted:

if such a description is unnecessary or unavailable;
if the Notification type is 04 (a block-level partial update) and no data elements in Block 3 have been updated since a previous message;
the Notification type is 08 (notice of sale of a product from one publisher to another), in which case Blocks 1–3 and 5–6 are unnecessary;
the Notification type is 05 (a record deletion), in which case Blocks 1–6 are wholly unnecessary.

It should be said that extensive use of Block 3 may be beyond the technical capabilities of all but the most sophisticated data providers and recipients.

P.18 Content items

The structure of the <ContentItem> composite that forms the whole of Group P.18 is akin to a complete ONIX record in miniature – and since some parts of a product may in fact be products in their own right (eg parts in a multi-item product, or articles or chapters from a book sold individually), it may be very similar to sections of the ONIX record for those individual products:

<ContentItem> composite – describes a single part, chapter, article etc;
- <LevelSequenceNumber> – describes the position of the item in the hierarchy of content items;
- <TextItem> composite – nature of the content item, including any identifiers for the item, and the extent;
  - <TextItemType>;
  - <TextItemIdentifier> composite;
  - <PageRun> composite;
  - <NumberOfPages>;
- <ComponentTypeName> (eg Chapter, Part, Article);
- <ComponentNumber> (eg a chapter or article number);
- <TitleDetail> composite – see Group P.6;
- <Contributor> composite – see Group P.7;
- <Subject> composite – see Group P.12;
- <NameAsSubject> composite – see Group P.12;
- <TextContent> composite – see Group P.14;
- <CitedContent> composite – see Group P.15;
- <SupportingResource> composite – see Group P.16;
- <RelatedWork> composite – see Group P.22.

The primary intent of the composite is to specify detailed information about each part of the product that is not included in the description of the product as a whole, or in a <ProductPart> composite in Group P.4. Each <ContentItem> composite:

should contain a level sequence number if the order of the items is significant;
must contain a <TextItem> composite that specifies the type of item (complete work, chapter, article…). The composite should also include a product identifier it the item is available as a separate product;
should contain detail of the distinctive title of the content item;
should not contain contributor and subject detail, or collateral material, unless it differs from that provided for the product as a whole.

items within a multi-volume boxed set
using Reference names
`<DescriptiveDetail>`
`<ProductComposition>10</ProductComposition>`
`<ProductForm>SC</ProductForm>`
`. . .`
`<NoCollection/>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>01</TitleElementLevel>`
`<TitleText textcase="02">His Dark Materials</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`. . .`
`</DescriptiveDetail>`
`. . . .`
`<ContentDetail>`
`<ContentItem>`
`<LevelSequenceNumber>1</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>01</TextItemType>`
`<TextItemIdentifier>`
`<TextItemIDType>03</TextItemIDType>`
`<IDValue>9780375823459</IDValue>`
`</TextItemIdentifier>`
`<TextItemIdentifier>`
`<TextItemIDType>15</TextItemIDType>`
`<IDValue>9780375823459</IDValue>`
`</TextItemIdentifier>`
`</TextItem>`
`<ComponentTypeName>Book</ComponentTypeName>`
`<ComponentNumber>One</ComponentNumber>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<TitlePrefix textcase="02">The</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">Golden Compass</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`<TitleDetail>`
`<TitleType>08</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<TitleText textcase="02">Northern Lights</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>2</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>01</TextItemType>`
`<TextItemIdentifier>`
`<TextItemIDType>03</TextItemIDType>`
`<IDValue>9780375823466</IDValue>`
`</TextItemIdentifier>`
`<TextItemIdentifier>`
`<TextItemIDType>15</TextItemIDType>`
`<IDValue>9780375823466</IDValue>`
`</TextItemIdentifier>`
`</TextItem>`
`<ComponentTypeName>Book</ComponentTypeName>`
`<ComponentNumber>Two</ComponentNumber>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<TitlePrefix textcase="02">The</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">Subtle Knife</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>3</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>01</TextItemType>`
`<TextItemIdentifier>`
`<TextItemIDType>03</TextItemIDType>`
`<IDValue>9780375823350</IDValue>`
`</TextItemIdentifier>`
`<TextItemIdentifier>`
`<TextItemIDType>15</TextItemIDType>`
`<IDValue>9780375823350</IDValue>`
`</TextItemIdentifier>`
`</TextItem>`
`<ComponentTypeName>Book</ComponentTypeName>`
`<ComponentNumber>Three</ComponentNumber>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<TitlePrefix textcase="02">The</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">Amber Spyglass</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`</ContentItem>`
`</ContentDetail>`

using Short tags
`<descriptivedetail>`
`<x314>10</x314>`	Multi-item product
`<b012>SC</b012>`	In slipcase
`. . .`	Various elements omitted
`<x411/>`	No collection detail
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>01</x409>`	Product level
`<b203 textcase="02">His Dark Materials</b203>`	Title case
`</titleelement>`
`</titledetail>`
`. . .`
`</descriptivedetail>`
`. . . .`
`<contentdetail>`
`<contentitem>`
`<b284>1</b284>`	First content item
`<textitem>`
`<b290>01</b290>`	Textual work
`<textitemidentifier>`
`<b285>03</b285>`	GTIN-13
`<b244>9780375823459</b244>`	of this content item
`</textitemidentifier>`
`<textitemidentifier>`
`<b285>15</b285>`	ISBN
`<b244>9780375823459</b244>`	of this content item
`</textitemidentifier>`
`</textitem>`
`<b288>Book</b288>`
`<b289>One</b289>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<b030 textcase="02">The</b030>`
`<b031 textcase="02">Golden Compass</b031>`
`</titleelement>`
`</titledetail>`
`<titledetail>`
`<b202>08</b202>`	Former title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<b203 textcase="02">Northern Lights</b203>`
`</titleelement>`
`</titledetail>`
`</contentitem>`
`<contentitem>`
`<b284>2</b284>`	Second content item
`<textitem>`
`<b290>01</b290>`	Textual work
`<textitemidentifier>`
`<b285>03</b285>`	GTIN-13
`<b244>9780375823466</b244>`	of this content item
`</textitemidentifier>`
`<textitemidentifier>`
`<b285>15</b285>`	ISBN
`<b244>9780375823466</b244>`	of this content item
`</textitemidentifier>`
`</textitem>`
`<b288>Book</b288>`
`<b289>Two</b289>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<b030 textcase="02">The</b030>`
`<b031 textcase="02">Subtle Knife</b031>`
`</titleelement>`
`</titledetail>`
`</contentitem>`
`<contentitem>`
`<b284>3</b284>`	Third content item
`<textitem>`
`<b290>01</b290>`	Textual work
`<textitemidentifier>`
`<b285>03</b285>`	GTIN-13
`<b244>9780375823350</b244>`	of this content item
`</textitemidentifier>`
`<textitemidentifier>`
`<b285>15</b285>`	ISBN
`<b244>9780375823350</b244>`	of this content item
`</textitemidentifier>`
`</textitem>`
`<b288>Book</b288>`
`<b289>Three</b289>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<b030 textcase="02">The</b030>`
`<b031 textcase="02">Amber Spyglass</b031>`
`</titleelement>`
`</titledetail>`
`</contentitem>`
`</contentdetail>`

The product as a whole – the three slipcased volumes – is not part of a collection, although if sold separately, the individual volumes are part of a collection entitled ‘His Dark Materials’. This collection title is used as the product title of the slipcased product. Used like this, <ContentDetail> is a natural complement for <ProductPart>. Three <ProductPart> composites would indicate that each volume in the slipcase is a softback – the three product identifiers that apply to the individual parts may be duplicated between Group P.4 and Group P.18.

detailed table of contents, with contributors listed for each chapter
using Reference names
`<ContentDetail>`
`<ContentItem>`
`<LevelSequenceNumber>1</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>02</TextItemType>`
`<PageRun>`
`<FirstPageNumber>ix</FirstPageNumber>`
`</PageRun>`
`</TextItem>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<TitleText textcase="02">Acknowledgements</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>2</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>02</TextItemType>`
`<PageRun>`
`<FirstPageNumber>1</FirstPageNumber>`
`</PageRun>`
`</TextItem>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<TitleText textcase="02">Introduction</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A24</ContributorRole>`
`<PersonNameInverted>Bordo, Michael D.</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>2</SequenceNumber>`
`<ContributorRole>A24</ContributorRole>`
`<PersonNameInverted>Taylor, Alan M.</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>3</SequenceNumber>`
`<ContributorRole>A24</ContributorRole>`
`<PersonNameInverted>Williamson, Jeffrey</PersonNameInverted>`
`</Contributor>`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>3</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>03</TextItemType>`
`</TextItem>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<PartNumber>Part I</PartNumber>`
`<TitlePrefix textcase="02">The</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">Rise and Fall (and Rise) of Market Integration</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>3.1</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>03</TextItemType>`
`<PageRun>`
`<FirstPageNumber>13</FirstPageNumber>`
`</PageRun>`
`</TextItem>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<PartNumber>1</PartNumber>`
`<TitleText textcase="02">Commodity Market Integration, 1500–2000</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A01</ContributorRole>`
`<PersonNameInverted>Findlay, Ronald</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>2</SequenceNumber>`
`<ContributorRole>A01</ContributorRole>`
`<PersonNameInverted>O’Rourke, Kevin H.</PersonNameInverted>`
`</Contributor>`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>3.2</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>03</TextItemType>`
`<PageRun>`
`<FirstPageNumber>65</FirstPageNumber>`
`</PageRun>`
`</TextItem>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<PartNumber>2</PartNumber>`
`<TitleText textcase="02">International Migration and the Integration of Labor Markets</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`<Contributor>`
`<SequenceNumber>1</SequenceNumber>`
`<ContributorRole>A01</ContributorRole>`
`<PersonNameInverted>Chiswick, Barry R.</PersonNameInverted>`
`</Contributor>`
`<Contributor>`
`<SequenceNumber>2</SequenceNumber>`
`<ContributorRole>A01</ContributorRole>`
`<PersonNameInverted>Hatton, Timothy J.</PersonNameInverted>`
`</Contributor>`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>3.3</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>03</TextItemType>`
`<PageRun>`
`<FirstPageNumber>121</FirstPageNumber>`
`</PageRun>`
`</TextItem>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<PartNumber>3</PartNumber>`
`<TitleText textcase="02">Globalization and Capital Markets</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`<!-- contributors omitted for brevity -->`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>4</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>03</TextItemType>`
`</TextItem>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<PartNumber>Part II</PartNumber>`
`<TitlePrefix textcase="02">The</TitlePrefix>`
`<TitleWithoutPrefix textcase="02">Great Divergence, Geography, and Technology</TitleWithoutPrefix>`
`</TitleElement>`
`</TitleDetail>`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>4.1</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>03</TextItemType>`
`<PageRun>`
`<FirstPageNumber>191</FirstPageNumber>`
`</PageRun>`
`</TextItem>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<PartNumber>4</PartNumber>`
`<TitleText textcase="02">Globalization and Convergence</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`<!-- contributors omitted for brevity -->`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>4.2</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>03</TextItemType>`
`<PageRun>`
`<FirstPageNumber>227</FirstPageNumber>`
`</PageRun>`
`</TextItem>`
`<TitleDetail>`
`<TitleType>01</TitleType>`
`<TitleElement>`
`<TitleElementLevel>04</TitleElementLevel>`
`<PartNumber>5</PartNumber>`
`<TitleText textcase="02">Does Globalization Make the World More Unequal?</TitleText>`
`</TitleElement>`
`</TitleDetail>`
`<!-- contributors omitted for brevity -->`
`</ContentItem>`
`. . .`
`</ContentDetail>`

using Short tags
`<contentdetail>`
`<contentitem>`
`<b284>1</b284>`	Item 1
`<textitem>`
`<b290>02</b290>`	Front matter
`<pagerun>`
`<b286>ix</b286>`
`</pagerun>`
`</textitem>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<b203 textcase="02">Acknowledgements</b203>`
`</titleelement>`
`</titledetail>`
`</contentitem>`
`<contentitem>`
`<b284>2</b284>`	Item 2
`<textitem>`
`<b290>02</b290>`	Front matter
`<pagerun>`
`<b286>1</b286>`
`</pagerun>`
`</textitem>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<b203 textcase="02">Introduction</b203>`
`</titleelement>`
`</titledetail>`
`<contributor>`
`<b034>1</b034>`
`<b035>A24</b035>`
`<b037>Bordo, Michael D.</b037>`
`</contributor>`
`<contributor>`
`<b034>2</b034>`
`<b035>A24</b035>`
`<b037>Taylor, Alan M.</b037>`
`</contributor>`
`<contributor>`
`<b034>3</b034>`
`<b035>A24</b035>`
`<b037>Williamson, Jeffrey</b037>`
`</contributor>`
`</contentitem>`
`<contentitem>`
`<b284>3</b284>`	Item 3
`<textitem>`
`<b290>03</b290>`	Body matter
`</textitem>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<x410>Part I</x410>`
`<b030 textcase="02">The</b030>`
`<b031 textcase="02">Rise and Fall (and Rise) of Market Integration</b031>`
`</titleelement>`
`</titledetail>`
`</contentitem>`
`<contentitem>`
`<b284>3.1</b284>`	Item 3 subitem 1
`<textitem>`
`<b290>03</b290>`	Body matter
`<pagerun>`
`<b286>13</b286>`
`</pagerun>`
`</textitem>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<x410>1</x410>`
`<b203 textcase="02">Commodity Market Integration, 1500–2000</b203>`
`</titleelement>`
`</titledetail>`
`<contributor>`
`<b034>1</b034>`
`<b035>A01</b035>`
`<b037>Findlay, Ronald</b037>`
`</contributor>`
`<contributor>`
`<b034>2</b034>`
`<b035>A01</b035>`
`<b037>O’Rourke, Kevin H.</b037>`
`</contributor>`
`</contentitem>`
`<contentitem>`
`<b284>3.2</b284>`	Item 3 subitem 2
`<textitem>`
`<b290>03</b290>`	Body matter
`<pagerun>`
`<b286>65</b286>`
`</pagerun>`
`</textitem>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<x410>2</x410>`
`<b203 textcase="02">International Migration and the Integration of Labor Markets</b203>`
`</titleelement>`
`</titledetail>`
`<contributor>`
`<b034>1</b034>`
`<b035>A01</b035>`
`<b037>Chiswick, Barry R.</b037>`
`</contributor>`
`<contributor>`
`<b034>2</b034>`
`<b035>A01</b035>`
`<b037>Hatton, Timothy J.</b037>`
`</contributor>`
`</contentitem>`
`<contentitem>`
`<b284>3.3</b284>`	Item 3 subitem 3
`<textitem>`
`<b290>03</b290>`	Body matter
`<pagerun>`
`<b286>121</b286>`
`</pagerun>`
`</textitem>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<x410>3</x410>`
`<b203 textcase="02">Globalization and Capital Markets</b203>`
`</titleelement>`
`</titledetail>`
`<!-- contributors omitted for brevity -->`
`</contentitem>`
`<contentitem>`
`<b284>4</b284>`	Item 4
`<textitem>`
`<b290>03</b290>`	Body matter
`</textitem>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<x410>Part II</x410>`
`<b030 textcase="02">The</b030>`
`<b031 textcase="02">Great Divergence, Geography, and Technology</b031>`
`</titleelement>`
`</titledetail>`
`</contentitem>`
`<contentitem>`
`<b284>4.1</b284>`	item 4 subitem 1
`<textitem>`
`<b290>03</b290>`	Body matter
`<pagerun>`
`<b286>191</b286>`
`</pagerun>`
`</textitem>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<x410>4</x410>`
`<b203 textcase="02">Globalization and Convergence</b203>`
`</titleelement>`
`</titledetail>`
`<!-- contributors omitted for brevity -->`
`</contentitem>`
`<contentitem>`
`<b284>4.2</b284>`	Item 4 subitem 2
`<textitem>`
`<b290>03</b290>`	Body matter
`<pagerun>`
`<b286>227</b286>`
`</pagerun>`
`</textitem>`
`<titledetail>`
`<b202>01</b202>`	Distinctive title
`<titleelement>`
`<x409>04</x409>`	Content item level
`<x410>5</x410>`
`<b203 textcase="02">Does Globalization Make the World More Unequal?</b203>`
`</titleelement>`
`</titledetail>`
`<!-- contributors omitted for brevity -->`
`</contentitem>`
`. . .`
`</contentdetail>`

The above table of contents is structured like so:

Acknowledgements
Introduction, by Michael D. Bordo, Alan M. Taylor and Jeffrey G. Williamson
Part I – The Rise and Fall (and Rise) of Market Integration
- 1. Commodity Market Integration, 1500–2000, by Ronald Findlay and Kevin H. O’Rourke
- 2. International Migration and the Integration of Labor Markets, by Barry R. Chiswick and Timothy J. Hatton
- 3. Globalization and Capital Markets, further contributors omitted for brevity
Part II – The Great Divergence, Geography, and Technology
- 4. Globalization and Convergence
- 5. Does Globalization Make the World More Unequal?
- …

The Introduction and each of the arabic numbered ‘chapters’ has individual contributors and page numbers, whereas the roman numbered Parts do not.

It would clearly be possible for the same table of contents to be provided in an XHTML-marked up list in Group P.14:

<Text textformat="05"><ul><li>Acknowledgements</li><li>Introduction, <em>by Michael D. Bordo, Alan M. Taylor and Jeffrey G. Williamson</em></li><li>Part I – The Rise and Fall (and Rise) of Market Integration<ul><li>1. Commodity Market Integration, 1500–2000, <em>by Ronald Findlay and Kevin H. O’Rourke</em></li><li>2. International Migration and the Integration of Labor Markets, <em>by Barry R. Chiswick and Timothy J. Hatton</em></li><li>3. Globalization and Capital Markets, <em>further contributors omitted for brevity</em></li></ul></li><li>Part II – The Great Divergence, Geography, and Technology<ul><li>4. Globalization and Convergence</li><li>5. Does Globalization Make the World More Unequal?</li><li>…</li></ul></li></ul></Text>

However, P.14 cannot be used to attach an abstract for each of the individual papers presented as ‘chapters’, or provide identifiers or subject categories for each of the chapters individually: this is possible using <TextContent>, <TextItemIdentifier> or <Subject> within each of the <ContentItem> composites.

DOIs assigned to each chapter
using Reference names
`<ContentDetail>`
`<ContentItem>`
`<LevelSequenceNumber>1</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>03</TextItemType>`
`<TextItemIdentifier>`
`<TextItemIDType>06</TextItemIDType>`
`<IDValue>10.4400/zuim.rdfg</IDValue>`
`</TextItemIdentifier>`
`</TextItem>`
`<ComponentTypeName>Chapter</ComponentTypeName>`
`<ComponentNumber>1</ComponentNumber>`
`</ContentItem>`
`<ContentItem>`
`<LevelSequenceNumber>2</LevelSequenceNumber>`
`<TextItem>`
`<TextItemType>03</TextItemType>`
`<TextItemIdentifier>`
`<TextItemIDType>06</TextItemIDType>`
`<IDValue>10.4400/zuim.qftk</IDValue>`
`</TextItemIdentifier>`
`</TextItem>`
`<ComponentTypeName>Chapter</ComponentTypeName>`
`<ComponentNumber>2</ComponentNumber>`
`</ContentItem>`
`. . .`
`</ContentDetail>`

using Short tags
`<contentdetail>`
`<contentitem>`
`<b284>1</b284>`	Item 1
`<textitem>`
`<b290>03</b290>`	Body matter
`<textitemidentifier>`
`<b285>06</b285>`	DOI for
`<b244>10.4400/zuim.rdfg</b244>`	Chapter 1
`</textitemidentifier>`
`</textitem>`
`<b288>Chapter</b288>`
`<b289>1</b289>`
`</contentitem>`
`<contentitem>`
`<b284>2</b284>`	Item 2
`<textitem>`
`<b290>03</b290>`	Body matter
`<textitemidentifier>`
`<b285>06</b285>`	DOI for
`<b244>10.4400/zuim.qftk</b244>`	Chapter 2
`</textitemidentifier>`
`</textitem>`
`<b288>Chapter</b288>`
`<b289>2</b289>`
`</contentitem>`
`. . .`
`</contentdetail>`

In the above example, the DOIs have been assigned to each chapter largely for marketing and discoverability purposes, as the chapters are not available as individual products. If each were available separately (eg each as a very small e-book), then it would be appropriate to include each product’s ISBN or GTIN identifier.

Content item composite

This composite is repeated for each content item in the product. A single repeat of <ContentItem> within <ContentDetail> is unlikely, as it provides no more information than can be carried in other, more frequently used, parts of the Product record – in which case, the whole of Block 3 should be omitted.

P.18.1 Level sequence number

<LevelSequenceNumber> is concerned solely with the order and hierarchy of the content items – it does not necessarily match the numbering or naming scheme used within the product itself, so Chapter 1 might be numbered 3 if it is preceded by two front matter content items.

Numbering should proceed like this to indicate the sequential order and nesting of content items:

1
2
- 2.1
  - 2.1.1
  - 2.1.2
- 2.2
3

Subsections can be nested to any necessary depth.

Text item composite

This mandatory composite must contain a <TextItemType> element, and may contain an identifier for the text item – particularly if the item is also available as a solus product (for example where chapters in a book might also be available individually as print-on-demand chapters or e-publications, or where each of the content items is a volume also available for sale independently).

Possible values for <TextItemType> are limited to 01 for full works – where a work in included within a multi-item product – and 02–04 for front, body and back matter.

If <ContentItem> is used to deliver a fully-structured table of contents, then page numbering can also be included within <TextItem>.

P.18.9, P.18.10 Component type name and number

Note the contrast with <LevelSequenceNumber>. The latter is concerned only with ordering of items within <ContentItem>, whereas <ComponentTypeName> and <ComponentNumber> must match the naming and numbering scheme used on the product.

Note also the potential overlap between Component type name and number and <PartNumber> within <TitleDetail>: in general, use <ComponentTypeName> and <ComponentNumber> only when there is no individual title for the content item (eg when chapters are named simply ‘Chapter 2’, ‘Chapter 3’ and so on), or when naming and numbering items within a multi-item product.

Title detail composite

<TitleDetail> should not in general carry any collection-level or product-level titles. For content items such as chapters or articles that feature in a table of contents, or works within an omnibus, <TitleElementLevel> should be code 04, which specifies a content item within a product. This also applies to items within a multi-item product, even if those items are also available as separate products. Of course, the Product records for those individual products would contain the same title element, but with <TitleElementLevel> 01 – because the title is the title of a product, not a content item within a product. Those records might include collection-level title elements too.

Contributor composite to Related work composite

These composites are identical to those in Groups P.7, P.12, P.14, P.15, P.16 and P.22, and similar best practices apply. It is through these composites that <ContentItem> adds value – without them, Block 3 is nothing more than a table of contents.

Note that sequence numbering within a group of <Contributor> composites should be independent of the sequence numbering of the contributors to the product as a whole, and of the numbering of contributors to other content items. Contributors to a content item should be numbered as if the item were itself a product.

Block 4: Publishing detail

Publishing detail composite

Block 4 – the <PublishingDetail> composite – is intended to carry information describing the branding (imprint) of the product, the publisher and the ‘global’ publishing status of the product, plus the publisher’s sales rights associated with the product.

Note that the ‘global’ publishing status information in Group P.20 may not apply to all markets where the product is available. Market-specific publishing status may be carried in Group P.25.

P.19 Publisher

Group P.19 is effectively mandatory within Block 4.

<Publisher> can also include links to websites associated with the publisher or its brands and business units.

There is often significant confusion over the nature of the imprint and publisher. In almost all cases, this can be clarified through understanding that the imprint is merely a brand name, whereas the publisher is a legal entity of some kind (often but not necessarily a commercial organization). The uncertainty arises because the organization may use its own name as its brand – this is almost always the case with small publishers. And naturally, when one publisher acquires another, one organization disappears, but its brand name may live on as a brand of the acquiring publisher. Over time, large publishers acquire a portfolio of brands or imprints.

Further uncertainly can arise where a series or collection of products becomes very large – does it become a brand in its own right? Ultimately, identities can be arranged in a hierarchy, from the narrowest (the title of a single book), through sub-series and series with their collection titles, to the imprint or brand which may encompass many books and collections of books, to a publisher with one or many brands, and eventually to the broadest (a conglomerate that owns several publishing companies). A workable rule of thumb is that the imprint is the broadest entity in that hierarchy that is not a legal entity, and the publisher is the narowest entity that is a legal entity.

simple imprint and publisher
using Reference names
`<Imprint>`
`<ImprintName>Ballantine Books<ImprintName>`
`</Imprint>`
`<Publisher>`
`<PublishingRole>01</PublishingRole>`
`<PublisherName>Random House</PublisherName>`
`<Website>`
`<WebsiteRole>18</WebsiteRole>`
`<WebsiteLink>http://ballantine.atrandom.com</WebsiteLink>`
`</Website>`
`</Publisher>`
`<CityOfPublication>New York</CityOfPublication>`
`<CountryOfPublication>US</CountryOfPublication>`

using Short tags
`<imprint>`
`<b079>Ballantine Books<b079>`	Imprint or ‘brand’
`</imprint>`
`<publisher>`
`<b291>01</b291>`	Publisher
`<b081>Random House</b081>`
`<website>`
`<b367>18</b367>`	Publisher’s consumer website
`<b295>http://ballantine.atrandom.com</b295>`
`</website>`
`</publisher>`
`<b209>New York</b209>`
`<b083>US</b083>`

imprint and publisher with publisher identifier
using Reference names
`<Imprint>`
`<ImprintName>Gabler<ImprintName>`
`</Imprint>`
`<Publisher>`
`<PublishingRole>01</PublishingRole>`
`<PublisherIdentifier>`
`<PublisherIDType>05</PublisherIDType>`
`<IDValue>5106257</IDValue>`
`</PublisherIdentifier>`
`<PublisherName>Gabler Verlag</PublisherName>`
`<Website>`
`<WebsiteRole>18</WebsiteRole>`
`<WebsiteLink>http://www.gabler.de/</WebsiteLink>`
`</Website>`
`</Publisher>`
`<CityOfPublication>Wiesbaden</CityOfPublication>`
`<CountryOfPublication>DE</CountryOfPublication>`

using Short tags
`<imprint>`
`<b079>Gabler<b079>`
`</imprint>`
`<publisher>`
`<b291>01</b291>`
`<publisheridentifier>`
`<x447>05</x447>`	German ISBN Agency publisher ID
`<b244>5106257</b244>`
`</publisheridentifier>`
`<website>`
`<b367>18</b367>`	Publisher’s consumer website
`<b295>http://www.gabler.de/</b295>`
`</website>`
`<b081>Gabler Verlag</b081>`
`</publisher>`
`<b209>Wiesbaden</b209>`
`<b083>DE</b083>`

transfer of ownership of product from one publisher to another – update from divesting publisher
using Reference names
`<RecordReference>f3a85abd-f29e-4e0b-92cc-2fa6a0833022</RecordReference>`
`<NotificationType>08</NotificationType>`
`<RecordSourceType>01</RecordSourceType>`
`<RecordSourceName>XYZ Publishers</RecordSourceName>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`. . .`
`<Publisher>`
`<PublishingRole>09</PublishingRole>`
`<PublisherName>ABCQ Books</PublisherName>`
`</Publisher>`
`<Publisher>`
`<PublishingRole>13</PublishingRole>`
`<PublisherName>XYZ Publishers</PublisherName>`
`</Publisher>`
`. . .`
`<PublishingDate>`
`<PublishingDateRole>28</PublishingDateRole>`
`<Date>20150105</Date>`
`</PublishingDate>`
`. . .`
`<ProductSupply>`
`<SupplyDetail>`
`. . .`
`. . .`
`<ProductAvailability>51</ProductAvailability>`
`. . .`
`</SupplyDetail>`
`</ProductSupply>`

using Short tags
`<a001>f3a85abd-f29e-4e0b-92cc-2fa6a0833022</a001>`	XYZ’s reference
`<a002>08</a002>`	Notice of sale
`<a194>01</a194>`	From publisher
`<a197>XYZ Publishers</a197>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780001234567</b244>`
`</productidentifier>`
`. . .`
`<publisher>`
`<b291>09</b291>`
`<b081>ABCQ Books</b081>`	New publisher
`</publisher>`
`<publisher>`
`<b291>13</b291>`
`<b081>XYZ Publishers</b081>`	Old publisher
`</publisher>`
`. . .`
`<publishingdate>`
`<x448>28</x448>`	Date of transfer
`<b306>20150105</b306>`
`</publishingdate>`
`. . .`
`<productsupply>`
`<supplydetail>`
`. . .`	Old supplier
`. . .`	Returns conditions
`<j396>51</j396>`	Publisher no longer sells product in market
`. . .`	Last date for returns
`</supplydetail>`
`</productsupply>`

transfer of ownership – matching update from acquiring publisher
using Reference names
`<RecordReference>uk.co.abcq.1234567</RecordReference>`
`<NotificationType>09</NotificationType>`
`<RecordSourceType>01</RecordSourceType>`
`<RecordSourceName>ABCQ Books</RecordSourceName>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780001234567</IDValue>`
`</ProductIdentifier>`
`. . .`
`<Publisher>`
`<PublishingRole>09</PublishingRole>`
`<PublisherName>ABCQ Books</PublisherName>`
`</Publisher>`
`<Publisher>`
`<PublishingRole>13</PublishingRole>`
`<PublisherName>XYZ Publishers</PublisherName>`
`</Publisher>`
`. . .`
`<PublishingDate>`
`<PublishingDateRole>28</PublishingDateRole>`
`<Date>20150105</Date>`
`</PublishingDate>`
`. . .`
`<ProductSupply>`
`<SupplyDetail>`
`. . .`
`</SupplyDetail>`
`</ProductSupply>`

using Short tags
`<a001>uk.co.abcq.1234567</a001>`	ABCQ’s reference
`<a002>09</a002>`	Notice of acquisition
`<a194>01</a194>`	From publisher
`<a197>ABCQ Books</a197>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780001234567</b244>`
`</productidentifier>`
`. . .`
`<publisher>`
`<b291>09</b291>`
`<b081>ABCQ Books</b081>`	New publisher
`</publisher>`
`<publisher>`
`<b291>13</b291>`
`<b081>XYZ Publishers</b081>`	Old publisher
`</publisher>`
`. . .`
`<publishingdate>`
`<x448>28</x448>`
`<b306>20150105</b306>`	Date of transfer
`</publishingdate>`
`. . .`
`<productsupply>`
`<supplydetail>`
`. . .`	New supplier, availability and prices
`</supplydetail>`
`</productsupply>`

The product was originally published by XYZ Publishers, but responsibility and existing stock has been transferred to ABCQ Books. Each publisher sends an update, notification type 08 for the divesting publisher, and 09 for the acquiring publisher. If block updates are in use, then assuming no other information is changing, at least ‘block zero’, Block 4 and Block 6 must be sent. Both publishers must name the acquiring publisher, ABCQ Books, as the publisher in Block 4, and should list the divesting publisher as well. Block 6 is optional for the divesting publisher, but may be used to specify returns details, which would often extend after the transition to the new publisher. Each publisher should use their own unique record reference. If necessary, the records can be paired on the basis of the product identifier (for example the ISBN).

Subsequent updates from ABCQ should simply use Publishing role code 01. Some while later, when any transferred stock is exhausted, ABCQ is likely to state the old ISBN is out of print, and to re-publish the product under its own new ISBN. The new Product record should then use <RelatedProduct> to state that the new ISBN replaces the old.

joint-branded flip-book (two books in one, bound back to back)
using Reference names
`<Imprint>`
`<ImprintName>Bloomsbury<ImprintName>`
`</Imprint>`
`<Imprint>`
`<ImprintName>Scholastic Children’s Books<ImprintName>`
`</Imprint>`
`<Publisher>`
`<PublishingRole>02</PublishingRole>`
`<PublisherName>Bloomsbury Publishing</PublisherName>`
`<Website>`
`<WebsiteRole>18</WebsiteRole>`
`<WebsiteLink>http://www.bloomsbury.com/childrens</WebsiteLink>`
`</Website>`
`</Publisher>`
`<Publisher>`
`<PublishingRole>02</PublishingRole>`
`<PublisherName>Scholastic</PublisherName>`
`<Website>`
`<WebsiteRole>18</WebsiteRole>`
`<WebsiteLink>http://http://www.scholastic.co.uk/zone/</WebsiteLink>`
`</Website>`
`</Publisher>`
`<CityOfPublication>London</CityOfPublication>`
`<CountryOfPublication>UK</CountryOfPublication>`

using Short tags
`<imprint>`
`<b079>Bloomsbury<b079>`	Joint branding
`</imprint>`
`<imprint>`
`<b079>Scholastic Children’s Books<b079>`
`</imprint>`
`<publisher>`
`<b291>02</b291>`	Co-publisher
`<b081>Bloomsbury Publishing</b081>`
`<website>`
`<b367>18</b367>`
`<b295>http://www.bloomsbury.com/childrens</b295>`
`</website>`
`</publisher>`
`<publisher>`
`<b291>02</b291>`	Co-publisher
`<b081>Scholastic</b081>`
`<website>`
`<b367>18</b367>`
`<b295>http://http://www.scholastic.co.uk/zone/</b295>`
`</website>`
`</publisher>`
`<b209>London</b209>`
`<b083>UK</b083>`

Co-publishers can be listed as ‘publisher and co-publisher’, or as two co-publishers as shown above. The former approach is preferred when the two publishers have separate ISBNs for the same product (and thus there are two ONIX records), and the latter when a single shared ISBN is used.

Note that co-publisher (PublishingRole = 02) is not related to the idea of a ‘co-edition’. Co-publication means that both publishers are responsible for making a single product available. A co-edition is an arrangement where two publishers share manufacturing arrangements (eg sharing some printing plates), but each make a different product available.

book published in cooperation with another organization
using Reference names
`<Imprint>`
`<ImprintName>Kogan Page<ImprintName>`
`</Imprint>`
`<Publisher>`
`<PublishingRole>01</PublishingRole>`
`<PublisherName>Kogan Page</PublisherName>`
`</Publisher>`
`<Publisher>`
`<PublishingRole>07</PublishingRole>`
`<PublisherName>Chartered Institute of Public Relations</PublisherName>`
`</Publisher>`

using Short tags, with additional contributor
`<contributor>`
`<b034>3</b034>`
`<b035>A24</b035>`	Introduction by
`<b037>Swift, Dr. Antonia</b037>`
`<professionalaffiliation>`
`<b045>Chief Executive</b045>`
`<b046>Chartered Institute of Public Relations</b046>`
`</professionalaffiliation>`
`</contributor>`
`. . .`
`<imprint>`
`<b079>Kogan Page<b079>`
`</imprint>`
`<publisher>`
`<b291>01</b291>`	Publisher
`<b081>Kogan Page</b081>`
`</publisher>`
`<publisher>`
`<b291>07</b291>`	In association with
`<b081>Chartered Institute of Public Relations</b081>`
`</publisher>`

The professional association is not a co-publisher, but lends its brand to the publication. The association or its staff may also be involved editorially.

Imprint or brand composite

Imprint or branding information is typically provided as a simple imprint name – the name that appears on the title page or title verso of a book, or the equivalent in a non-book product. In the case where a product is joint-branded, the <Imprint> composite is repeatable – however, unlike the similar <Publisher> composite, there is no ‘role’ associated with each imprint or brand. It is simply assumed that all imprints are imprints or brands directly associated with the product.

Imprint or brand names should not include any extra text that, for example, indicates their ownership: while ‘Prentice Hall Business, an imprint of Pearson Education’ may be listed on the title page or title verso, the <ImprintName> should simply be ‘Prentice Hall Business’. And where an abbreviated name is used because space is limited, for example on the book spine, the full name should be used: the spine may list ‘HBS Press’, but the full name from the title page or title verso – ‘Harvard Business School Press’ – should be supplied. Consistency is important, and a data supplier should avoid the case where some records list the imprint as ‘Touchstone’ and others as ‘Touchstone Books’.

Note that <Imprint> is a ‘brand name’ or marque, whereas <Publisher> is an organization or company name (and is a legal entity). It is common for a publisher to use its own name as a brand, and in this case, it is still best practice to supply both <Imprint> and <Publisher>, even though they might contain the same text. This can be particularly confusing since many imprint or brand names originated as the names of independent publishing companies, which have since been bought by larger publishers. The name of the small publisher may live on as a brand of the larger publisher. (In the case of a self-publisher, it is possible for publisher, imprint and contributor all to contain the same name.)

It is sometimes useful to deliver an imprint identifier or ‘brand code’ as well as the imprint name. This is particularly so where the code can deliver more granular information about the business unit responsible for a product, where within a large publisher a particular imprint or brand may be shared between several business units. But imprint identifiers – sometimes also termed list codes – can be generally useful to recipients even if they do not provide extra granularity, for example to guard against inconsistent naming of imprints, and at least one major global recipient requires a ‘brand code’ purely for this reason. This can be accomplished using an <ImprintIdentifier> composite and an arbitrary proprietary identifier.

imprint name plus a proprietary ‘list’ code (‘brand code’ or imprint ID)
using Reference names
`<Imprint>`
`<ImprintIdentifier>`
`<ImprintIDType>01</ImprintIDType>`
`<IDTypeName>HCP UK List Codes<IDTypeName>`
`<IDValue>HCUKCNF</IDValue>`
`</ImprintIdentifier>`
`<ImprintName>Collins</ImprintName>`
`</Imprint>`

using Short tags, with both standard and proprietary identifiers
`<imprint>`
`<imprintidentifier>`
`<x445>16</x445>`	ISNI identifying
`<b244>0000000123641546</b244>`	brand name
`</imprintidentifier>`
`<imprintidentifier>`
`<x445>01</x445>`	Proprietary list gives
`<b233>HCP UK List Codes</b233>`	more granular details
`<b244>HCUKCNF</b244>`	where business units
`</imprintidentifier>`	share an imprint/brand
`<b079>Collins</b079>`
`</imprint>`

It is a common error to assume that ‘Proprietary’ here is an indication of the publisher’s trademark or other proprietary rights held over the brand or imprint name itself. It is not. It indicates only that the identifier scheme used (ie the scheme named in <IDTypeName> and from which the value of <IDValue> is drawn) is proprietary.

Note that, although it is possible to provide an <Imprint> composite that contains only an <ImprintIdentifier>, this is bad practice. Provision of a name is vital where a proprietary identifier is used, as otherwise a recipient unaware of the nature of the proprietary code list has no imprint name to work with.

So there are three different ways to provide an imprint name:

<Imprint> composite containing only the imprint name;
<Imprint> composite containing a public or proprietary identifier, plus the imprint name;
<Imprint> composite containing multiple identifiers, plus the imprint name.

Similar practice applies to the use of proprietary and public identifiers inside the <Publisher> composite. Note that List 44 is used to control values for both <ImprintIDType> and <PublisherIDType>: ensure that the <Imprint> composite is used to identify an imprint (which is similar in concept to a ‘brand’ or ‘marque’), and the <Publisher> composite used to identify a publisher (which is a company or organization).

Publisher composite

Publishers associated with the product in various ways should be identified via the <Publisher> composite. This need not be limited to the publisher or co-publishers of the product – it can include a former publisher, a body working in association with the publisher (eg a learned society working with a publisher), or even the publisher of a previous version of the work (eg the original language version).

Publisher names are names of organizations or companies responsible for making the product available, but suffixes indicating the legal nature of the organization – Ltd, SA, LLC, Inc and so on – should be omitted.

In some countries, national libraries or other agencies maintain authoritative publisher identifiers (for example the Deutsche Nationalbibliothek publisher identifier). Where available, these publisher identifiers should be included within the <Publisher> composite. Where there is no accepted national scheme, it is fairly common to use a location identifier such as the GLN (of course, a GLN only identifies the publisher by proxy, as the publisher operating at that location).

Publishing companies are often themselves subsidiaries of larger corporate entities – publishing groups or holding companies. Supply chain partners deal with the publishing company, not its owner, so there is usually little reason to list the publishing group or holding company in the metadata. However, both publisher and group can be included if the need arises.

Publisher and publishing group
using Reference names
`<Publisher>`
`<PublishingRole>01</PublishingRole>`
`<PublisherName>株式会社エンターブレイン</PublisherName>`
`</Publisher>`
`<Publisher>`
`<PublishingRole>10</PublishingRole>`
`<PublisherName>株式会社角川グループホールディングス</PublisherName>`
`</Publisher>`

using Short tags
`<publisher>`
`<b291>01</b291>`	Publisher
`<b081>株式会社エンターブレイン</b081>`	Enterbrain
`</publisher>`
`<publisher>`
`<b291>10</b291>`	Publishing group
`<b081>株式会社角川グループホールディングス</b081>`	Kadokawa Group Holdings
`</publisher>`

Website composite

It can be useful to include links to a publisher’s website. Where possible, the <WebsiteRole> data element should be used to identify whether the website is primarily business-to-business or consumer-focused (codes 17 and 18 respectively on List 73).

More generally, website links can be specified in several different ‘contexts’:

within <Contributor>
within <Conference>
within <Publisher>
within <PublisherRepresentative>
within <Supplier>

Role codes from List 73 cover a variety of types of website, and should be included whenever possible. Suppliers should attempt to provide the most relevant links within each context – for example, a link to a website maintained by an author and promoting a specific work (role code 10) should be provided in a <Contributor> context, not within <Publisher>, and a publisher’s business to business website should be listed in <Publisher> (or possibly within <Supplier>, if the publisher operates its own distribution). A publisher’s website linked to a particular contributor might in principle be listed in either <Contributor> or <Publisher>, but not both – and in practice, the latter location is preferred. The simplest guide on placement of a particular web link is to consider which party (person or organization) is responsible for the website – if it is the author, use <Website> composite within <Contributor>, whereas if it is the publisher, use the website within <Publisher>.

: It is best practice always to include the full URI, including the protocol (ie the http: or https:) within the <Weblink> element, even though in common usage, the http: and even on occasion the www part is often omitted.

P.19.13 City of publication

The city or town of publication is normally listed on the title page of a book, and the <CityOfPublication> element normally carries this name in the form that it is listed. Alternatively, some ONIX implementations may be consistent with the publisher’s ‘house style’, and may be slightly different from the exact listing on the book.

Some publishers list a single location in more than one language, or list more than one location. <CityOfPublication is repeatable in either of these cases – but in the first case, the language attribute is mandatory and in the second it may be omitted.

One location in two languages
using Reference names, Brussels, in both Flemish and French
`<CityOfPublication language="dut">Brussel</CityOfPublication>`
`<CityOfPublication language="fre">Bruxelles</CityOfPublication>`

using Short tags, Moscow, in French and Russian
`<b209 language="fre">Moscou</b209>`
`<b209 language="rus">Москва</b209>`

Two locations, London and Toronto
using Reference names
`<CityOfPublication>London</CityOfPublication>`
`<CityOfPublication>Toronto</CityOfPublication>`

Two locations, London and Paris, in both English and French
using Reference names
`<CityOfPublication language="eng">London</CityOfPublication>`
`<CityOfPublication language="fre">Londres</CityOfPublication>`
`<CityOfPublication">Paris</CityOfPublication>`

Two locations, Rome and Paris, in both Italian and French
using Reference names
`<CityOfPublication language="ita">Roma</CityOfPublication>`
`<CityOfPublication language="ita">Parigi</CityOfPublication>`
`<CityOfPublication language="fre">Rome</CityOfPublication>`
`<CityOfPublication language="fre">Paris</CityOfPublication>`

There is no particular meaning ascribed to the order of the various repeats. However, it’s good practice to assume that recipients may be limited in the number of location names they can store, and might select just the first one or two – so put the ‘most important’ first.

When combining both multiple locations and multiple languages, data senders should ensure that they avoid this, which leaves the English name of one city unknown:

`<CityOfPublication language="eng">London</CityOfPublication>`
`<CityOfPublication language="ita">Londra</CityOfPublication>`
`<CityOfPublication language="ita">Roma</CityOfPublication>`

Each individual location should be listed either in the full set of specified languages, or without any language attribute (ie suitable for all specified languages). Both the London / Paris and the Rome / Paris examples are correct, whereas the London / Rome combination is not.

Recipients can then easily select all locations for which there is no language attribute, plus all locations which carry their preferred option from the languages available.

P.19.14 Country of publication

<CountryOfPublication> is the country where the publisher is based, and may be different from the country in which publication takes place – for example, a UK-based publisher may publish a book in Australia, and in this case, <CountryOfPublication> should be the United Kingdom.

The country of publication is useful in library cataloging (and is vital for ISBN registration purposes), so should always be provided. While less critical, the city or cities wherein the publisher is based can also be useful, so should be supplied where possible. Cities and countries of publication are usually listed on a book’s title page or the title verso.

For multi-national publishers, the country of publication is the country in which the particular business unit that produced the product is based, and usually the country from whose ISBN agency the ISBN is drawn.

Product contact composite

The product contact composite is intended to carry the name and other details of a contact person (usually at the publisher) who is responsible for some aspect of this particular product. A direct contact like this might help facilitate particular retail promotions, author tours, or access to the publisher’s production files (to meet the needs of print-impaired readers). Such contact details are clearly business-to-business contacts, and data recipients must not use them in consumer-facing contexts.

providing promotional contact details
using Reference names
`<ProductContact>`
`<ProductContactRole>02</ProductContactRole>`
`<ProductContactName>Effectiv Promos LLC</ProductContactName>`
`<ContactName>Georgia Fremont, +1 212 555 0123</ContactName>`
`<EmailAddress>gfremont@effectiv.com</EmailAddress>`
`</ProductContact>`

using Short tags
`<productcontact>`
`<x482>02</x482>`	Promotional contact
`<x484>Effectiv Promos LLC</x484>`
`<x299>Georgia Fremont, +1 212 555 0123</x299>`
`<j272>gfremont@effectiv.com</j272>`
`</productcontact>`

The <ProductContactIdentifier> and <ProductContactName> refer to an organization, not to a specific person. The contact name and e-mail address refer to a person within that organization.

There is a strong contrast with the contact details provided in the <Sender> composite in the message header – the header contact is responsible for the message as a whole, and is often a technical contact. The <ProductContact> composite is specific to each product in a message.

P.20 Global publishing status and dates / copyright

Group P.20 conveys the essential information about the lifecycle of a product, as it is defined by the publisher. This includes status information about whether the product is not yet published, active and available for sale, or is unavailable, and it includes dates (both past and future) for events such as initial publication or when a product is declared out of print. The status and dates are expressly the global status and dates. That is, a publication date quoted in P.20 must be the original (earliest) publication date of the product in any territory or market, and an out of print date should be the latest of any territory or market. ONIX providers can specify local, market-specific status and dates – for example a publication date that applies within a specific market – in Group P.25.

In the simple case, when a product is only available in a single market, provision of the publishing status and dates in either P.20 or P.25 is all that is required. Note that ‘single market’ does not mean ‘single country’, but any size of territory defined by rights and distribution arrangements (for a fuller definition, see Block 6).

In the more complex case when a product is available in a variety of different markets, market-specific details must be provided in P.24 and P.25 within separate repeats of the Block 6 <ProductSupply> composite – one repeat for each market.

In either case, it is valuable to include both ‘global’ information in Group P.20 and market-specific information in Group P.25, and doing so is considered best practice even when it’s not essential. But data providers must ensure that the status and dates provided in Group P.20 reflect the true global position. It is common for a publisher operating in multiple markets to consider one the primary or ‘home’ market, but it is a mistake to assume that a ‘global’ status or date is necessarily the same as the ‘status or date in the primary market’. Early publication in a secondary market, for example, means that the secondary market publication date is the basis for the global publication date. Early publication in the secondary market should in this case be viewed as ‘delayed availability in the primary market’.

Note that a publisher representative in a specific market – see Group P.25 – may not always be aware of the full ‘global’ publishing information, in which case details from Group P.20 might need to be omitted if the representative supplies ONIX Product records. Market-specific details should not be specified in P.20 in place of missing global details.

The <PublishingDetail> composite should include a ‘global’ status in the <PublishingStatus> data element.

At least one <PublishingDate> composite should be included, to carry the global publication date of the product (unless this is specifically precluded by the <PublishingStatus>). Additional relevant dates should also be specified, including:

any embargo on retail sales;
any embargo on release of product metadata;
an out of print date (as this can affect the acceptance of returns).

This best practice applies even when the markets in which a product is available each have a market-specific status and market-specific dates in Group P.25. Data providers must ensure that the global status and dates in P.20 are consistent with any market–specific status and dates provided in Block 6 – for example, a global publication date must be the earliest of any market-specific publication dates, and a product cannot be out of print globally if it is still active in any market.

ONIX recipients must ensure they comply with any stated embargo and/or announcement dates.

forthcoming product with an embargo on sales
using Reference names
`<PublishingStatus>02</PublishingStatus>`
`<PublishingDate>`
`<PublishingDateRole>01</PublishingDateRole>`
`<Date dateformat="00">20110428</Date>`
`</PublishingDate>`
`<PublishingDate>`
`<PublishingDateRole>02</PublishingDateRole>`
`<Date dateformat="00">20110428</Date>`
`</PublishingDate>`

using Short tags
`<b394>02</b394>`	Forthcoming
`<publishingdate>`
`<x448>01</x448>`	Nominal pub date
`<b306 dateformat="00">20110428</b306>`	YYYYMMDD format
`</publishingdate>`
`<publishingdate>`
`<x448>02</x448>`	Sales embargo date
`<b306 dateformat="00">20110428</b306>`
`</publishingdate>`

out of print product
using Reference names
`<PublishingStatus>07</PublishingStatus>`
`<PublishingDate>`
`<PublishingDateRole>01</PublishingDateRole>`
`<Date dateformat="00">20080925</Date>`
`</PublishingDate>`
`<PublishingDate>`
`<PublishingDateRole>13</PublishingDateRole>`
`<Date dateformat="00">20100311</Date>`
`</PublishingDate>`
`<PublishingDate>`
`<PublishingDateRole>11</PublishingDateRole>`
`<Date dateformat="00">20070920</Date>`
`</PublishingDate>`

using Short tags
`<b394>07</b394>`	Out of print
`<publishingdate>`
`<x448>01</x448>`	Nominal pub date (of this product)
`<b306 dateformat="00">20080925</b306>`	YYYYMMDD format
`</publishingdate>`
`<publishingdate>`
`<x448>13</x448>`	Out-of-print date (of this product)
`<b306 dateformat="00">20100311</b306>`
`</publishingdate>`
`<publishingdate>`
`<x448>11</x448>`	First publication (of work)
`<b306 dateformat="00">20070920</b306>`
`</publishingdate>`

provision of multiple dates for an e-book
using Reference names
`<PublishingStatus>04</PublishingStatus>`
`<PublishingDate>`
`<PublishingDateRole>11</PublishingDateRole>`
`<Date dateformat="05">1811</Date>`
`</PublishingDate>`
`<PublishingDate>`
`<PublishingDateRole>19</PublishingDateRole>`
`<Date dateformat="01">198510</Date>`
`</PublishingDate>`
`<PublishingDate>`
`<PublishingDateRole>01</PublishingDateRole>`
`<Date dateformat="00">20110428</Date>`
`</PublishingDate>`

using Short tags
`<b394>04</b394>`	Active (‘in print’)
`<publishingdate>`
`<x448>11</x448>`	Date of first publication of work
`<b306 dateformat="05">1811</b306>`	Only the year is available
`</publishingdate>`
`<publishingdate>`
`<x448>19</x448>`	Publication date of print equivalent
`<b306 dateformat="01">198510</b306>`	Year and month available
`</publishingdate>`
`<publishingdate>`
`<x448>01</x448>`	Publication date
`<b306 dateformat="00">20110428</b306>`	Exact date in YYYYMMDD format
`</publishingdate>`

The contemporary e-book is based on conversion of a backlist product from 1985, though the work was first published 200 years ago. The dateformat attribute is used to control the differing precision of each of the dates.

P.20.1 Publishing status

This is the product’s global status as defined by the publisher.

Several status codes in List 64 preclude the sending of a publication date. For other statuses, at least the publication date should be included in a repeat of the <PublishingDate> composite, as well as any other relevant dates.

Meaning of the main publishing status codes in List 64:

A similar diagram in the Specification illustrates how the status may change over time, through the lifecycle of the product.

Some publishers use the term ‘reprint under consideration’ (RUC) to describe a product which is out of stock, and for which there is no current plan to reprint and bring it back into stock. In many cases, this is a transitional status while decisions are taken: orders will be accepted, and there is a reasonable expectation that a reprint decision will be made and the product will become available again. But in some cases, this RUC status persists so long that it’s clear the product is effectively out of print and will never become available: orders may be accepted, but will never be fulfilled. Publishers are encouraged to use <PublishingStatus> code 06 only where a reprint decision is realistically being considered. Code 07 should be applied when the product is formally out of print, and code 08 is available to indicate ‘effectively out of print’.

Subject to any Consumer announcement date, retailers may wish to present ‘Forthcoming’ or ‘not yet published’ titles to consumers more positively as ‘Available for advance order’ or ‘Pre-order now’. Orders placed by retailers with the publisher or distributor while a product is forthcoming are sometimes termed ‘subscription orders.

Publishing date composite

Several dates can be provided for a single product – not just the date of publication, but also announcement dates to control when metadata becomes available (eg in an online store) or an embargo date to control when sales may begin.

There is some variation in terminology regarding dates. ONIX uses the following key terms throughout, and these are listed for use with <PublishingDate> composite in List 163:

Publication date – the date on which the product is nominally ‘published’. This date is used for advance planning, and is associated with various business processes: it may be linked to the invoice date for product copies delivered prior to publication, to delivery guarantees offered to retailers, to the timing of promotional activity, or to bibliographic cataloging. However, it is not necessarily the date on which copies of the product will be delivered to retailers, nor the earliest date a retailer may begin retail sales to consumers, nor is it the earliest date on which a consumer may place an advance order (‘pre-order’) a copy of the product. Actual availability of stock to the retailer may be no more than a few days prior to the nominal publication date (see Expected availability date);
- retailers receiving stock prior to the publication date are not expected to wait until the publication date to begin retail sales or pre-order fulfillment, unless an embargo has been set. In the absence of an embargo, fulfillment to consumers may begin as soon as stock is available;
- since most products do not have an embargo date, it is very common for retail sales or advance order fulfillment to begin a few days before the publication date;
- advertising and promotional activity is often timed to coincide with (or refer to) the publication date, but if exact synchronization is required, an embargo or strict on-sale date should be set;
- some publishers choose to term the earliest date on which a consumer may take possession of a product as a ‘publication date’. In ONIX, this is an ‘embargo date’, and in an ONIX message, an embargo date must always be set in addition to the publication date;
Market publication date – For internationally-traded books, the ‘publication date’ often varies between markets. For any one market, there is a single date, and strictly, only the earliest of these dates across several markets is the publication date. Later dates, in other markets, are often termed market publication dates, local publication dates and so on. In ONIX, where there are several market publication dates, the earliest of these should be listed in the <PublishingDate> composite in Group P.20 to reflect the ‘global’ status of the book. The individual market publication dates should be listed in the <MarketDate> composite in P.25;
- in most cases, the earliest date will be the date of publication in the publisher’s home or primary market, but this is not always the case. Where a publisher arranges early availability in an foreign market, the arrangement should be treated as delayed availability in the home market. It is that early date that is the publication date quoted in the <PublishingDate> composite. To avoid any doubt, both markets should include an explicit market publication date in the <MarketDate> composite;
Embargo date – the earliest date on which a customer can take posession of a product (ie the date the embargo expires). In general, it is assumed that retailers may begin retail sales of the product (or begin to fulfil orders placed in advance) as soon as stock is available. This is commonly several days prior to the nominal publication date. If for any reason a publisher wishes to control the earliest date of retail sale or pre-order fulfillment, a sales embargo date should be supplied (in addition to the publication date). If retailers receive stock prior to the stated embargo date, it must be sequestered by the retailer until the embargo has expired;
- embargoes are set by the publisher, so they are carried in <PublishingDate>. They may also be carried for confirmation purposes in <SupplyDate> (see Group P.26). It is good practice to provide the embargo date in both places, and they would typically be the same. Occasionally, the embargo in a particular market may be later than the ‘global’ embargo, so the <SupplyDate> embargo may be later than the global embargo in <PublishingDate>;
- fulfillment by mail order may usually begin one day prior to expiry of an embargo, since delivery to the consumer will occur the following day (at the earliest);
- in North America, embargo dates are often known as ‘strict on-sale dates’, ‘on-sale dates’, or ‘national-’ or ‘one-day laydown dates’, and embargoes are often backed by legal affidavit. In other territories, industry-wide agreements and codes of practice govern retail activity when an embargo has been set. ONIX recipients must respect embargo dates whether or not an affidavit has been signed;
  - some North American publishers distinguish between ‘strict’ and non-strict on-sale dates – the latter are, in effect, embargo dates for which an affidavit has not been signed. In ONIX, they are treated the same as strict on-sale dates, as retailers are expected to treat strict and non-strict on-sale dates identically (ie whether an affidavit exists or not). In ONIX, both strict and non-strict on-sale dates are Embargo dates;
- in other media (eg music or electronic games), an embargo date is known as a ‘street date’;
- embargoes are often set where book content is serialized in newspapers, or when a release needs to be synchronized (‘day and date’) with other media releases (eg film or TV tie-ins);
- embargoes are also used to control the retail release of e-publications, where retailers may be supplied with master files some time in advance of publication, perhaps several weeks in advance. The time taken for conversion of the master files to the specific file format used by the retailer may be unpredictable. Setting an embargo date ensures that the release can be synchronized across several retailers, giving retailers a ‘level playing field’ and ensuring that the start of retail activity coincides with any planned promotional effort;
- the embargo date need not coincide with the nominal publication date, although most commonly it does;
- such an embargo does not apply to the product metadata. A retailer may display a product catalog entry (eg in an online store) and may accept advance orders from consumers (pre-orders) prior to expiry of the embargo, but must not fulfill those orders until expiry;
- the embargo does apply to display of sample or preview content – even sample content that is supplied alongside other product metadata that may itself be displayed – except when a ‘Valid from’ date that allows earlier display is supplied alongside the sample content in Block 2;
- if the publisher wishes to set different embargo dates for sales and for samples/previews, then the date applying to the sample or preview should be associated directly with it in Block 2. An explicit ‘Valid from’ date supplied with sample content in Block 2 takes precedence over any embargo date in P.20 or P.26. The embargo date in <PublishingDate> of course remains in place for actual product sales or fulfillment of advance orders;
- in ONIX 2.1, the embargo date was carried in the <OnSaleDate> element;
Expected availability date – the date on which physical stock is expected to be released from the distributor or wholesaler to the retailer, sometimes also called the ‘expected ship date’. For electronic products, this is the date on which master files are expected to be released to the retail platform or retailer;
- this is never carried in <PublishingDate>. It is specified in <SupplyDate>, as it is a feature of the distribution arrangements for the product, but is discussed here for convenience;
- the Expected availability date is typically a week or so before the nominal publication date. Physical stock may take a few days after the Expected availability date to reach the retailer, so should be delivered to the retailer prior to publication. In the absence of an Embargo date, it may be placed on sale to end-customers immediately;
- in ONIX 2.1, the expected availability date was carried in the <ExpectedShipDate> element;
Consumer (or Public) announcement date – in general, it is assumed that retailers may publicize a forthcoming product as soon as they receive the necessary metadata for that product. And this implies also that retailers may begin to gather pre-orders as soon as they receive the necessary metadata. If a data supplier such as a publisher wishes to control the public availability of metadata and the earliest date that retailers may accept pre-orders, a Consumer announcement date should be supplied. If retailers receive a Product record prior to the stated announcement date, it may be used for internal purposes, but must not be exposed in a consumer-facing context (eg a public-accessible website) and pre-orders must not be accepted until the stated date;
- if the data supplier wishes to control the public announcement of the product separately from the acceptance of advance orders (pre-orders), then a Pre-order embargo date may also be supplied;
- data suppliers should take special care in managing Consumer announcement dates. It is common to link Consumer announcement dates to planned Publication dates, for example automatically setting Consumer announcement dates to six months prior to the publication date. If the planned publication date is modified, the announcement date might be adjusted automatically so that it remains six months prior to the new publication date. But of course, such automatic adjustments should not be made after the product is announced – once a product has been announced, it cannot be ‘unannounced’;
- data recipients should also take care to ensure that metadata does not appear in a consumer-facing context prior to any Consumer announcement date;
Trade announcement date – in cases where ONIX records are supplied to data aggregators, who subsequently supply the data to retailers, it is generally assumed that the aggregators may pass on metadata as soon as they receive it (and after it has passed through any internal editorial processes the aggregator uses). If a data supplier wishes to provide an aggregator with data, but delay its onward supply for any reason, a trade announcement date should be supplied. If data aggregators receive a Product record prior to the stated trade announcement date, it may be used for internal purposes, but should not be exposed to supply chain partners who receive the aggregator’s data (or of course, to consumers);
- management of Trade announcement dates is similar to that for Consumer announcement dates;
Date of first publication – this is the nominal publication date of the first manifestation of the work of which this product is a manifestation. So for a typical mass-market paperback, this is the publication date of the equivalent hardback or trade paperback. The ‘work’ here should be understood in ISTC terms, and the work in question may be identified in Group P.22;
- for a second or subsequent edition, the date of first publication refers to earliest publication of this edition, not the earliest publication of the first edition, since each new edition is a new work (albeit derived from the previous edition);
- for an e-book, this may be the same as the Publication date of print counterpart, or it may be different. For a 2011 e-book version of a book first published in 1995 then republished in paperback form in 2001, the Date of first publication is 1995, the Publication date of the print counterpart could be 2001, and the Publication date is 2011;
- for works in translation only, the Date of first publication in original language is the Date of first publication, as above, for the ISTC ‘parent work’ from which the current work has been derived. For example, the date of first publication of The Girl with the Dragon Tattoo is 2008, but the date of first publication in original language (ie the date of first publication of Män som hattar kvinnor in Swedish) is 2005;
- in ONIX 2.1, the date of first publication was carried in the <YearFirstPublished> element (which obviously only included the year part of the date).

Some of these dates should be provided whether they are in the future or the past – a publication date or any out of print/deletion date, for example. Others such as a passed embargo or announcement date have no relevance, and should not be included if they are in the past.

: ‘Deletion’ here refers to deletion of the product or removal from a catalog of available products (cf <NotificationType> in Group P.1).

These dates apply equally to digital products. In the absence of any embargo, a digital retailer or company providing digital fulfillment services may commence delivery of files to consumers immediately upon receipt of the ‘master files’. If a publisher aims to deliver master files to retailers (or their service companies), allow ample time for testing and quality assurance, and yet still control the timing of earliest fulfillment of sales to consumers in any way, an Embargo date should be provided.

Dates quoted in a <Date> element – whether within <PublishingDate> or elsewhere in the Product record – should use the Gregorian calendar, the de facto global civil and commercial calendar. The exception to this is where dates might have a special significance and must be quoted using another calendar for cultural reasons – for example the use of the Hijri lunar calendar for dates linked to Islamic religious texts. Use of alternative calendars should be strictly minimized, as there is no guarantee that data recipients will be able to correctly interpret them.

When supplying dates in ONIX, the dateformat attribute can be supplied to specify the format of the date (YYYY, YYYYMM or YYYYMMDD, for example). If the attribute is omitted – and without the similar but deprecated <DateFormat> element – most dates require a default format of YYYYMMDD. Do not use a dummy date such as 1st January of a particular year if only the year is known – use dateformat to limit the precision of the date, for example dateformat="05", and supply only YYYY.

Most dates are simply that – dates. But increasingly, particularly for e-publications, embargo dates are set to specific times. Some date formats available in List 55 allow a time to be included. Embargoes (and other dates) can specify either a ‘rolling’ local time, or a specific instant in time. As an illustration of the difference, consider the meaning of these three embargo dates:

<Date dateformat="13">20120815T1500</Date>

<Date dateformat="13">20120815T1500-0400</Date>

<Date dateformat="13">20120815T1900Z</Date>

The first has no timezone information, and is therefore a ‘rolling time’, meaning that retail sales are embargoed until 3pm local time – thus the product goes on sale in New York at 3pm – but sales can begin some five hours earlier in London (ie at 3pm in London), and cannot begin for a further three hours in Seattle (ie at 3pm in Seattle). The second and third examples specify a particular instant in time – 3pm in a time zone four hours behind UTC, or 7pm UTC. This means that the product can be sold beginning at 3pm in New York (because New York is four hours behind UTC), and sales can begin in London and Seattle at exactly the same instant (ie at 8pm in London, because London is one hour ahead of UTC, and at noon in Seattle because Seattle is seven hours behind UTC).

It is critical that publishers setting embargoes with exact time parameters decide whether the embargo time is rolling or instantaneous, and that they use the correct format to specify the time. Note that it may not be possible for e-book retailers selling to customers in many countries (or even within a single country that stretches across several time zones) to apply rolling time embargoes properly.

Times that include timezone information (ie instants in time) should wherever possible express that time in UTC.

Midnight embargoes can be specified with a time of either 2400 or 0000 – the former indicates an embargo that expires at the end of a day, and the latter indicates expiry at the beginning of the day. So these two examples indicate an identical rolling embargo time – but of the two, the latter is strongly preferred:

`<Date dateformat="13">20120815T2400</Date>`	(end of 15th August)
`<Date dateformat="13">20120816T0000</Date>`	(beginning of 16th August)

Copyright statement composite

This composite can be used to record details of any copyrights or neighboring rights (for example the phonogram or database rights) held in the content of the product. The whole composite is repeatable for products incorporating multiple rights – for example, the author and the reader of an audiobook could hold separate copyright and phonogram rights. And any single right may be held jointly by multiple owners.

However, it should never be interpreted as being comprehensive – there may be other rights in the product that are not listed, for example various image rights, over and above any specified text copyright.

When listing a particular copyright owner, note that it is possible to provide only an identifier, but this is strongly discouraged. Wherever possible include the name (either corporate or personal) as well.

joint copyright shared between author and publisher
using Reference names
`<CopyrightStatement>`
`<CopyrightType>C</CopyrightType>`
`<CopyrightYear dateformat="11">20042013</CopyrightYear>`
`<CopyrightOwner>`
`<PersonName>Amelia Winstanley</PersonName>`
`</CopyRightOwner>`
`<CopyrightOwner>`
`<CorporateName>General Text Inc.</CorporateName>`
`</CopyrightOwner>`
`</CopyrightStatement>`

using Short tags
`<copyrightstatement>`
`<x512>C</x512>`	© Copyright
`<b087 dateformat="05">2004</b087>`
`<b087 dateformat="05">2013</b087>`
`<copyrightowner>`
`<b036>Amelia Winstanley</b036>`
`</copyrightowner>`
`<copyrightowner>`
`<b047>General Text Inc.</b047>`
`</copyrightowner>`
`</copyrightstatement>`

Note the different date formats and the repeat of <b087>. The short tag version might be rendered as ‘© 2004, 2013 Amelia Winstanley and General Text Inc.’, whereas the reference names version might be rendered as ‘© 2004–2013 Amelia Winstanley and General Text Inc.’

P.21 Territorial rights and other sales restrictions

ONIX is product-focused: it is not primarily concerned with the publishing rights held by a publisher in a work – only in those rights that the publisher is exploiting in the particular product. Group P.21 lists the territorial extent of those rights (‘sales rights’).

These sales rights should clearly be a subset of – or the same as – the publishing rights held by the publisher. They should also be the same as – or a superset of – the distribution rights held by a particular supplier and specified in the <Market> composite in Group P.24.

With increasing globalization in the book supply chain – seen most particularly in the growth of e-book retail platforms with global scope, and with online retailers increasingly able to fulfill orders globally – it is no longer adequate to supply sales rights details for only those countries where ONIX recipients are based, or which a publisher considers its core market. ONIX suppliers should aim to provide a complete statement of the sales rights in all territories, although if necessary it is still possible to list certain territories where the rights position is unknown or unstated. The intent is to provide a precise, reliable statement of the rights information that can be used by an automated system to determine whether a product can or cannot be sold.

However, ONIX can communicate something about the publishing rights held, insofar as it can state whether the publisher’s rights are exclusive or non-exclusive. These types of publishing right generally pertain at work rather than product level. By claiming exclusive sales rights (<SalesRightsType> 01), the publisher is stating that no other publisher has the right to exploit the work in that territory – and this implies that other publisher’s manifestations of the work on sale in the same territory may be ‘infringing’.

Additional guidance on the description of sales rights in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Specify Markets and Suppliers in ONIX 3.

The <PublishingDetail> composite should include a full statement of the territorial sales rights associated with the product in one or more <SalesRights> composites. This includes specifying:

geographical areas where the product can be sold;
- it is good practice to specify whether the rights are exclusive, or whether another publisher might legitimately exploit parallel rights in the same work via other products with the same content;
geographical areas where the product cannot be sold;
- it is good practice to specify whether this is because the publisher holds no rights, or whether the publisher simply chooses not to exploit the rights;
any remaining geographical area where the rights position is unknown (or where the publisher wishes not to state a position, perhaps because of an in-progress negotiation).

Some territorial sales rights are accompanied by sales restrictions, for example where a product is exclusive to a particular retailer within a territory. Any such restrictions should be included.

This best practice applies even if each individual market a product is available in is described in Block 6. ONIX providers should ensure that individual market territories in Block 6 are consistent with the ‘global’ sales rights listed in Group P.21 (ie the markets are a subset of or identical to the P.21 territories with sales rights.)

Specifying geographical areas – territories – can be accomplished in a flexible manner. Territories can be built by defining an aggregation of countries or sub-national regions, or by excluding countries or regions from a ‘WORLD’ region. Finally, there is a data element that must be used to describe the sales rights for any geographical area not already covered (which may be those areas where the rights position is unclear, unknown, or which must remain unstated).

The <SalesRestriction> composite allows particular <SalesRights> composites to be further constrained, so that the product is saleable only through particular channels or outlets within the territory.

Only WORLD, national and sub-national entities are used to define territories. Supra-national regions other than WORLD are not used. Although supra-national terms like ‘Europe’ or ‘Commonwealth’ are in common use in discussing territorial rights, these groupings often have a dynamic nature and are difficult to interpret. For example, a publisher has exclusive rights throughout the European Economic Area (which consists of the EU and three EFTA countries), and either non-exclusive or no rights elsewhere. What happens when a new country joins the EU? Does the publisher automatically gain exclusive rights in the new country? Or has it lost EEA exclusivity because some other publisher had and still retains rights in that new country? This can only be answered through study of the relevant contract – is the area of exclusivity contractually defined as ‘the EEA’, or as a fixed list of countries? Within ONIX, territories are always defined by a list of countries, which avoids ambiguity and allows publishers to express rights in a granular manner. It is for the publisher to expand terms such as EEA into the correct list of countries, as that can only be done with access to contractual detail.

Code ROW (Rest of world) from List 49 – the list of regions used in <RegionsIncluded> and <RegionsExcluded> – is not valid in ONIX 3.0. Use <ROWSalesRightsType> instead. Code ECZ (Eurozone) is also not used in <SalesRights>, and its use is strongly discouraged elsewhere – use an explicit list of countries instead.

exclusive world rights excluding India
using Reference names
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`<CountriesExcluded>BD BT IN LK MV NP PK</CountriesExcluded>`
`</Territory>`
`</SalesRights>`
`<SalesRights>`
`<SalesRightsType>06</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>BD BT IN LK MV NP PK</CountriesIncluded>`
`</Territory>`
`</SalesRights>`

using Short tags
`<salesrights>`
`<b089>01</b089>`	For sale (exclusive)
`<territory>`
`<x450>WORLD</x450>`
`<x451>BD BT IN LK MV NP PK</x451>`
`</territory>`
`</salesrights>`
`<salesrights>`
`<b089>06</b089>`	Not for sale (no rights)
`<territory>`
`<x449>BD BT IN LK MV NP PK</x449>`
`</territory>`
`</salesrights>`

The exclusions from the first rights composite are dealt with in the second, so no <ROWSalesRightsType> element is required – although <ROWSalesRightsType> could be used in place of either of the composites to convey the same meaning.

exclusive sales rights in EEA plus Switzerland, no rights in North America, non-exclusive rights in the rest of the world
using Reference names
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GB GR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</CountriesIncluded>`
`</Territory>`
`</SalesRights>`
`<SalesRights>`
`<SalesRightsType>06</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>CA MX US</CountriesIncluded>`
`</Territory>`
`</SalesRights>`
`<ROWSalesRightsType>02</ROWSalesRightsType>`

using Short tags
`<salesrights>`
`<b089>01</b089>`	For sale (exclusive)
`<territory>`
`<x449>AT BE BG CY CZ DE DK EE ES FI FR GB GR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</x449>`	EU, EFTA
`</territory>`
`</salesrights>`
`<salesrights>`
`<b089>06</b089>`	Not for sale (no rights)
`<territory>`
`<x449>CA MX US</x449>`
`</territory>`
`</salesrights>`
`<x456>02</x456>`	For sale (non-exclusive)

exclusive world rights except in North America, but product is not sold in Spain and an alternative is offered
using Reference names
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`<CountriesExcluded>CA ES MX US</CountriesExcluded>`
`</Territory>`
`</SalesRights>`
`<SalesRights>`
`<SalesRightsType>06</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>CA MX US</CountriesIncluded>`
`</Territory>`
`</SalesRights>`
`<SalesRights>`
`<SalesRightsType>04</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>ES</CountriesIncluded>`
`</Territory>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9788401234569</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9788401234569</IDValue>`
`</ProductIdentifier>`
`</SalesRights>`

using Short tags
`<salesrights>`
`<b089>01</b089>`	For sale (exclusive)
`<territory>`
`<x450>WORLD</x450>`
`<x451>CA ES MX US</x451>`
`</territory>`
`</salesrights>`
`<salesrights>`
`<b089>06</b089>`	Not for sale (no rights)
`<territory>`
`<x449>CA MX US</x449>`
`</territory>`
`</salesrights>`
`<salesrights>`
`<b089>04</b089>`	Not for sale (but exclusive rights)
`<territory>`
`<x449>ES</x449>`
`</territory>`
`<productidentifier>`	Alternative product
`<b221>03</b221>`	GTIN-13
`<b244>9788401234569</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9788401234569</b244>`
`</productidentifier>`
`</salesrights>`

exclusive sales rights in North America, no rights in Europe, rights elsewhere unknown
using Reference names
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>CA MX US</CountriesIncluded>`
`</Territory>`
`</SalesRights>`
`<SalesRights>`
`<SalesRightsType>06</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GB GR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</CountriesIncluded>`
`</Territory>`
`</SalesRights>`
`<ROWSalesRightsType>00</ROWSalesRightsType>`

using Short tags
`<salesrights>`
`<b089>01</b089>`	For sale (exclusive)
`<territory>`
`<x449>CA MX US</x449>`	North America
`</territory>`
`</salesrights>`
`<salesrights>`
`<b089>06</b089>`	Not for sale (no rights)
`<territory>`
`<x449>AT BE BG CY CZ DE DK EE ES FI FR GB GR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</x449>`	EU, EFTA
`</territory>`
`</salesrights>`
`<x456>00</x456>`	ROW rights unknown or unstated

exclusive world rights, but this product is an own-brand exclusive to Fnac. An alternative product is identified for other retailers
using Reference names
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`</Territory>`
`<SalesRestriction>`
`<SalesRestrictionType>05</SalesRestrictionType>`
`<SalesOutlet>`
`<SalesOutletIdentifier>`
`<SalesOutletIDType>03</SalesOutletIDType>`
`<IDValue>FNC</IDValue>`
`</SalesOutletIdentifier>`
`<SalesOutletName>Fnac</SalesOutletName>`
`</SalesOutlet>`
`</SalesRestriction>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9782001234561</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9782001234561</IDValue>`
`</ProductIdentifier>`
`</SalesRights>`

using Short tags
`<salesrights>`
`<b089>01</b089>`	For sale with restrictions
`<territory>`
`<x450>WORLD</x450>`
`</territory>`
`<salesrestriction>`
`<b381>05</b381>`	Retailer-exclusive (own brand)
`<salesoutlet>`
`<salesoutletidentifier>`
`<b393>03</b393>`	ONIX outlet ID
`<b244>FNC</b244>`	FNAC
`</salesoutletidentifier>`
`<b382>Fnac</b382>`
`</salesoutlet>`
`</salesrestriction>`
`<productidentifier>`	Alternative product
`<b221>03</b221>`	GTIN-13
`<b244>9782001234561</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9782001234561</b244>`
`</productidentifier>`
`</salesrights>`

Sales rights composite

A typical <PublishingDetail> composite would include one or more <SalesRights> composites, each of which must specify a geographical territory and the type of sales rights that pertain there. In the very simplest case where exclusive worldwide publishing rights are held, just a single <SalesRights> composite is required. In a more complex case there may be two or three (occasionally more), plus a <ROWSalesRightsType> element. However, there should not normally be more than one <SalesRights> composite for each <SalesRightsType> (and any <ROWSalesRightsType> should carry a different value too).

<SalesRights> composites within which <SalesRightsType> codes 03, 04, 05 or 06 indicate that the product is not for sale (and possibly also the deprecated codes 07 and 08, which indicate it is for sale, but only in certain outlets or channels) may include an identifier for equivalent alternative products that may be available (or are not restricted to particular outlets or channels). This uses the <ProductIdentifier> composite, and best practices outlined in Group P.2 apply. Alternative products are intended to be used where one publisher provides two geographically distinguished products, as well as when a publisher without rights provides details of another publisher’s products (in real-world use, the latter will likely be rare). Data providers should attempt to match alternative products to the territories in which they are available – there is little benefit in listing alternatives that are themselves unavailable. However, data recipients should not assume anything about the availability of such alternatives, and should rely only on the full Product records for those products.

In typical circumstances, there would be a maximum of one repeat of the <SalesRights> composite for each value of <SalesRightsType>. However, it is possible that two repeats of the <SalesRights> composite carrying the same <SalesRightsType> might be necessary, either when a specified alternative product is known to be available in only some of the countries where the primary product is unavailable, or when a particular non-territorial sales restriction applies in only some of the countries where a product is for sale.

Territory composite

Each <SalesRights> composite must include a <Territory> composite to specify a geographical area, within which the particular sales rights apply. Every <Territory> must include either a <CountriesIncluded> or a <RegionsIncluded>, or both.

Geographical territories can be built up by including multiple countries or sub-national regions, and fine-tuned by excluding smaller regions from individual countries, or by excluding countries and smaller regions from the WORLD region. Areas that are not included should not be excluded (they would typically be included in a different <SalesRights> composite). For example, if the territory to be specified for one <SalesRights> composite is ‘North America’, then simply include the North American countries – the rest of the world should not be explicitly excluded (but the rights applicable to the rest of the world should be described in a separate <SalesRights> composite). Exclusions should be used to refine the included territory. For example, if the territory to be specified is ‘the 48 contiguous States of the USA’, then include USA using <CountriesIncluded> and exclude Hawaii and Alaska using <RegionsExcluded>. (You could alternatively include each of the 48 States individually, using <RegionsIncluded>, and the meaning of the <Territory> composite would be identical. Choosing which method to use may depend on the way in which territorial rights information is held in another IT system, but clearly the first method is simpler and preferable.)

In <Territory>, sub-national regions can be excluded from countries and from supra-national regions, and countries can be excluded from supra-national regions. But only certain combinations of inclusion and exclusion make sense. If CI means that <Territory> includes a <CountriesIncluded> element, RI means <RegionsIncluded>, CX and RX are exclusions, and — indicates an element is missing, only the following combinations can be used:

CI —— —— ——
CI —— —— RX ¹
—— RI —— ——
—— RI —— RX (only where RI = WORLD)
—— RI CX —— (only where RI = WORLD)
—— RI CX RX (only where RI = WORLD) ²
CI RI —— —— (only where RI does not contain WORLD) ³
CI RI —— RX (only where RI does not contain WORLD) ¹ ³

Other combinations do not make sense ⁴, and most will not validate.

¹ the regions excluded obviously have to be regions within the included countries
² the regions excluded must be outside the countries excluded (that is, countries and regions are separately excluded from WORLD)
³ the regions included must be outside the countries included
⁴ an exception to this applies in Group P.26, where a few other combinations are valid.

ONIX uses the ISO 3166-1 country codes in List 91. Since this list also includes autonomous and semi-autonomous parts of some countries, and overseas territories or dependencies of others, care should be taken to include these separately where appropriate, independent of the ‘parent’ country, as they are not automatically included in the larger country when interpreting ONIX List 91. So US overseas territories such as Guam or Samoa are not included as part of code US, since they have their own codes (GU and SA), and the Åland Islands are not included in code FI (Finland), since the islands have their own code (AX). Similar principles apply to French départements et territoires d’outre-mer (eg Réunion, Guadeloupe), the British Channel Islands (GG and JE) and overseas territories (BM etc) and so on. In addition, independent principalities and microstates such as San Marino (SM), Lichtenstein (LI) and Andorra (AD) are often overlooked.

When interpreting List 91, the subdivisions are not considered part of the larger country for sales rights, market or pricing purposes. In ONIX, the country code FR is considered to apply only to metropolitan France (including Corsica), and not to include the overseas departments and territories (codes BL, GF, GP etc). So if rights are held throughout the larger country, include both the main country code and the country code for the smaller subdivision.

Country ¹		Subdivision with independent code in List 91
Australia	AU	CC	Cocos Islands
		CX	Christmas Island
		NF	Norfolk Island
		HM	Heard Island and McDonald Islands
China	CN	HK	Hong Kong
		MO	Macao
		TW	Taiwan
Denmark	DK	FO	Faroe Islands
Denmark	DK	GL	Greenland
Finland	FI	AX	Åland Islands
France	FR	BL	Saint Barthélemy
		GF	French Guiana
		GP	Guadeloupe
		MF	Saint Martin
		MQ	Martinique
		NC	New Caledonia
		PF	French Polynesia
		PM	Saint Pierre and Miquelon
		RE	Réunion
		TF	French Southern Territories
		WF	Wallis and Futuna
		YT	Mayotte
Netherlands	NL	AW	Aruba
		BQ	Bonaire, Saba and Sint Eustatius
		CW	Curaçao
		SX	Sint Maarten
New Zealand	NZ	TK	Tokelau
Norway	NO	BV	Bouvet Island
Norway	NO	SJ	Svalbard and Jan Mayen
United Kingdom	GB	BM	Bermuda
		GS	South Georgia
		GG	Guernsey
		JE	Jersey
		IM	Isle of Man
		KY	Cayman Islands
		MS	Montserrat
		PN	Pitcairn Islands
		SH	Saint Helena, Ascension and Tristan da Cunha
United States	US	AS	American Samoa
		GU	Guam
		MP	Northern Mariana Islands
		PR	Puerto Rico
		UM	US Minor Outlying Islands
		VI	US Virgin Islands

¹ this list is not necessarily exhaustive

Note that some of these subdivisions may also have codes in List 49 for use within <RegionsIncluded> and <RegionsExcluded> – for example region code GB-IOM is synonymous with country code IM. The country codes from List 91 should be used in preference, and equivalent codes in List 49 should not be used.

Sales restriction composite

This composite should be used only within <SalesRightsType> codes 01 and 02, and it specifies an additional restriction that applies within a particular territory – for example a product may be a retailer exclusive, or sales may be restricted to a specific channel such as to libraries or schools.

: Prior to ONIX 3.0.2, <SalesRestriction> was used outside <SalesRights>, using <SalesRightsType> 07 or 08. This method is deprecated. The <SalesRestriction> composite should be included within the <SalesRights> composite to which it applies.

It is also possible to describe restrictions with the opposite effects – a product that is available to all except a specific retailer, or a product that is not available to the library sales channel.

It is possible to describe a product that is generally available to the trade in one territory, yet restricted to a specific channel or retailer in another. The general availability is described in one repeat of the <SalesRights> composite with <SalesRightsType> 01 (assuming exclusive rights are held), and the restricted availability is described in a second repeat of <SalesRights> with <SalesRightsType> 01 and a <SalesRestriction> composite. The restriction details supplied then only apply to the territory with which it is grouped.

exclusive rights in Commonwealth and EEA plus Switzerland, no rights in North America, non-exclusive rights elsewhere – but within the EEA, the product is only sold as a retailer-exclusive in Waterstones
using Reference names
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>AG AU BB BD BN BS BW BZ CA CM DM GD GH GM GY IN FJ JM KE KI KN LC LK LS MU MV MW MY MZ NG NR NZ PG PK RW SB SC SG SL SZ TO TT TV TZ UG VC VU WS ZA ZM</CountriesIncluded>`
`</Territory>`
`</SalesRights>`
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GB GR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</CountriesIncluded>`
`</Territory>`
`<SalesRestriction>`
`<SalesRestrictionType>04</SalesRestrictionType>`
`<SalesOutlet>`
`<SalesOutletIdentifier>`
`<SalesOutletIDType>03</SalesOutletIDType>`
`<IDValue>WST</IDValue>`
`</SalesOutletIdentifier>`
`<SalesOutletName>Waterstones</SalesOutletName>`
`</SalesOutlet>`
`</SalesRestriction>`
`</SalesRights>`
`<SalesRights>`
`<SalesRightsType>06</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>CA MX US</CountriesIncluded>`
`</Territory>`
`</SalesRights>`
`<ROWSalesRightsType>02</ROWSalesRightsType>`

using Short tags
`<salesrights>`
`<b089>01</b089>`	For unrestricted sale (exclusive)
`<territory>`
`<x449>AG AU BB BD BN BS BW BZ CA CM DM GD GH GM GY IN FJ JM KE KI KN LC LK LS MU MV MW MY MZ NG NR NZ PG PK RW SB SC SG SL SZ TO TT TV TZ UG VC VU WS ZA ZM</x449>`	Commonwealth
`</territory>`
`</salesrights>`
`<salesrights>`
`<b089>01</b089>`	For restricted sale (exclusive)
`<territory>`
`<x449>AT BE BG CY CZ DE DK EE ES FI FR GB GR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</x449>`	EU and EFTA
`</territory>`
`<salesrestriction>`	(in EU and EFTA)
`<b381>04</b381>`	Only via
`<salesoutlet>`
`<salesoutletidentifier>`
`<b393>03</b393>`	ONIX outlet list
`<b244>WST</b244>`	Waterstones
`</salesoutletidentifier>`
`<b382>Waterstones</b382>`
`</salesoutlet>`
`</salesrestriction>`
`</salesrights>`
`<salesrights>`
`<b089>06</b089>`	Not for sale (no rights)
`<territory>`
`<x449>CA MX US</x449>`
`</territory>`
`</salesrights>`
`<x456>02</x456>`	For sale (non-exclusive) elsewhere

‘Commonwealth’ is a large but dynamic list of countries, and the particular countries included may vary from product to product and from time to time.

The second <SalesRights> composite does not mean that the product can be sold throughout the European countries listed – it means it can be sold in those counties subject to the sales restriction. Prior to 3.0.2, the same information could be conveyed with <SalesRightsType> 08, but this code is now deprecated.

exclusive world rights but temporarily excluded for sale via a particular retailer
using Reference names
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`<Territory>`
`<SalesRestriction>`
`<SalesRestrictionType>11</SalesRestrictionType>`
`<SalesOutlet>`
`<SalesOutletIdentifier>`
`<SalesOutletIDType>03</SalesOutletIDType>`
`<IDValue>ZZZ</IDValue>`
`</SalesOutletIdentifier>`
`<SalesOutletName>LoCostReadz</SalesOutletName>`
`</SalesOutlet>`
`<StartDate dateformat="00">20130621</StartDate>`
`<EndDate dateformat="00">20140102</EndDate>`
`</SalesRestriction>`
`</SalesRights>`
`<!-- no ROWSalesRightsType -->`

using short tags
`<salesrights>`
`<b089>01</b089>`	For restricted sale (exclusive)
`<territory>`
`<x450>WORLD</x450>`
`<territory>`
`<salesrestriction>`
`<b381>11</b381>`	Except via
`<salesoutlet>`
`<salesoutletidentifier>`
`<b393>03</b393>`	ONIX outlet list
`<b244>ZZZ</b244>`	Other
`</salesoutletidentifier>`
`<b382>LoCostReadz</b382>`	Fictitious retailer
`</salesoutlet>`
`<b324 dateformat="00">20130621</b324>`
`<b325 dateformat="00">20140102</b325>`	Until January 2014
`</salesrestriction>`
`</salesrights>`
`<!-- no x456 -->`

exclusive world rights, but sold only through two specific retailers for a short time after publication
using Reference names
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`</Territory>`
`<SalesRestriction>`
`<SalesRestrictionType>04</SalesRestrictionType>`
`<SalesOutlet>`
`<SalesOutletIdentifier>`
`<SalesOutletIDType>03</SalesOutletIDType>`
`<IDValue>KBO</IDValue>`
`</SalesOutletIdentifier>`
`</SalesOutlet>`
`<SalesOutlet>`
`<SalesOutletIdentifier>`
`<SalesOutletIDType>03</SalesOutletIDType>`
`<IDValue>APC</IDValue>`
`</SalesOutletIdentifier>`
`</SalesOutlet>`
`<EndDate dateformat="00">20140621</EndDate>`
`</SalesRestriction>`
`</SalesRights>`

using Short tags
`<salesrights>`
`<b089>01</b089>`	For sale (exclusive)
`<territory>`
`<x450>WORLD</x450>`
`</territory>`
`<salesrestriction>`
`<b381>04</b381>`	Retailer exclusive
`<salesoutlet>`
`<salesoutletidentifier>`
`<b393>03</b393>`	ONIX outlet ID
`<b244>KBO</b244>`	Kobo and…
`</salesoutletidentifier>`
`</salesoutlet>`
`<salesoutlet>`
`<salesoutletidentifier>`
`<b393>03</b393>`
`<b244>APC</b244>`	Apple
`</salesoutletidentifier>`
`</salesoutlet>`
`<b325 dateformat="00">20140621</b325>`	Restriction ends (and product is generally available after this date)
`</salesrestriction>`
`</salesrights>`

Note that restrictions can be time-limited if necessary, by including <EndDate> (and possibly a <StartDate>). After a restriction expires, the <SalesRights> composite should be interpreted as if the restriction does not exist. The deprecated <SalesRightsType> code 07 should be treated as code 01 after expiry of any restrictions, and code 08 should be treated as code 02.

The expected expiry of a sales restriction provides an example where provision of ONIX metadata to retailers that are not able to sell the product is valuable – they may be able to sell the product in the future. And retailers who are affected by a restriction may still make use of the metadata, even prior to expiry, for customer service purposes (‘You cannot buy it from us yet’, ‘You cannot buy it from us, but we can offer you this alternative’, or even ‘You cannot buy it from us, but it may be available from this other retailer.’), and perhaps to facilitate the sales of used books. Best practice must therefore be to provide metadata, even when a retailer cannot sell the product.

But it is recognized that in some circumstances, there are commercial imperatives that weigh heavily against the provision of such metadata. Publishers may not wish to include retailer-exclusive products in an ONIX data feed that is sent to all retailers – especially prior to publication of that exclusive product – and retailers with exclusive arrangements may similarly not want their retail competitors informed in advance of the product appearing in-store. However, there is no reason to prevent dissemination of the metadata once the product is published, as competitor retailers may (legitimately) wish to facilitate used-book trading. The availability of metadata on products with sales restrictions (at least post-publication) is also important for the collection of aggregated sales data and market statistics.

P.21.10 Rest of World sales rights type code

In a technical sense, the <ROWSalesRightsType> element is optional. But the Specification defines it as ‘required in all cases where no sales rights type is associated with the region ‘WORLD’, and in all cases where a sales rights type is associated with ‘WORLD’ but with exclusions that are not themselves associated with a sales rights type’. It is defined that way to ensure that a sales rights type is associated unequivocally with every part of the world. And it is still required even if you believe you have listed all possible countries individually.

The <ROWSalesRightsType> element has two common uses. First, with codes 01–06, it is used to express rights statements such as ‘non-exclusive rights in the rest of the world’ – this can often be more convenient than using a <SalesRights> composite that includes WORLD and excludes a wide range of countries. Second, with code 00, it is used to make a positive statement about remaining areas of the world where rights are unknown or where the publisher does not wish to make a statement. In such cases, ONIX recipients should of course assume nothing about the rights that are applicable, and as a precaution should treat such territories as if the product were not for sale.

Since this data element relies on preceding <SalesRights> composites to define the extent of ‘the rest of the world’, it should never appear unless it is accompanied by one or more <SalesRights> composites. And if the <SalesRights> composites unequivocally cover the whole world, then the <ROWSalesRightsType> element should be omitted.

Whether Group P.21 requires a <ROWSalesRightsType> element must be checked on a case-by-case basis:

Is the WORLD region associated with a sales rights type code?
- if no, <ROWSalesRightsType> is required, even if you believe you have exhaustively listed all ISO country codes separately. It will act as a fallback if you have inadvertently omitted a country, or if a new country is created (eg South Sudan was created in 2011);
- if yes, see question 2;
Within the <SalesRights> composite that includes WORLD, are there any <CountriesExcluded> or <RegionsExcluded> elements?
- if no, <ROWSalesRightsType> should be omitted;
- if yes, see Question 3;
Are all those excluded countries and regions included in other <SalesRights> composites?
- if no, <ROWSalesRightsType> is required. It may be used to specify the rights that apply in the remaining countries or regions, or specify that those rights are unknown or unstated;
- if yes, <ROWSalesRightsType> should be omitted.

: Code 00 from List 46, indicating that sales rights are unknown or unstated, may be used only with <ROWSalesRightsType>. It is not valid within the <SalesRights> composite. As a precaution, recipients should generally interpret code 00 as ‘not for sale’.

Block 5: Related material

Related material composite

The <RelatedMaterial> composite, with its enclosed <RelatedWork> and <RelatedProduct composites, is used to deliver information about related works and other products, and their relationship to the product being described. <RelatedWork> is used to describe a relationship between the product being described – the subject of the entire ONIX Product record – and an abstract ‘work’. <RelatedProduct> is used to describe a relationship between the product being described and another product (which may be another manifestation of the same work, or a manifestation of another work).

P.22 Related works

The <RelatedWork> composite is primarily intended to be used to specify the ISTC of the (work manifested in the) product – a ‘work identifier’ that is shared by all products that contain the same significant text content, where each product will have a different ISBN, and where products may even be published by different publishers.

Importantly, it can also be used to specify the work’s relationship to other works (it may be a derivation of another work, or other works may be derived from it): a large measure of the value of ISTC is that it creates ‘family trees’ of works, and allows publishers and retailers to create groupings of products based on the relationships between their ISTCs – collocating products manifesting a work alongside the manifestations of a parent work and child works. For example, a novel in translation can be linked to its parent work in the original language, and to an abridged, adapted or enhanced child work.

Work identifiers are immensely useful to retailers, who may – with certainty – link multiple versions of the same work, and delink other, seemingly-similar products. This ensures the retailer is able to offer all versions of the work – hardcover, softcover, various e-publications, the luxury leatherbound version – giving the customer greater choice of formats and prices, and enhancing the visibility of niche products. To some extent, retailers can accomplish this without ISTCs, but the accuracy of such efforts is variable (for example when the same work is re-published under a different title). Libraries can use ISTCs for collocation, or to prevent acquisition of duplicate versions of works. The ISTC can also be used to improve compliance with territorial rights.

this product is a manifestation of a particular work identified by an ISTC. The ‘parent’ ISTC is also specified
using Reference names
`<RelatedWork>`
`<WorkRelationCode>01</WorkRelationCode>`
`<WorkIdentifier>`
`<WorkIDType>11</WorkIDType>`
`<IDValue>A02200900000A654</IDValue>`
`</WorkIdentifier>`
`</RelatedWork>`
`<RelatedWork>`
`<WorkRelationCode>02</WorkRelationCode>`
`<WorkIdentifier>`
`<WorkIDType>11</WorkIDType>`
`<IDValue>A02200900000ECDE</IDValue>`
`</WorkIdentifier>`
`</RelatedWork>`

using Short tags
`<relatedwork>`
`<x454>01</x454>`	Is manifestation of
`<workidentifier>`
`<b201>11</b201>`	ISTC
`<b244>A02200900000A654</b244>`	Of this work
`</workidentifier>`
`</relatedwork>`
`<relatedwork>`
`<x454>02</x454>`	Is manifestation of work derived from
`<workidentifier>`
`<b201>11</b201>`	ISTC
`<b244>A02200900000ECDE</b244>`	Of parent work
`</workidentifier>`
`</relatedwork>`

In this example, the parent ISTC (A02-2009-00000ECD-E) is an original work, and the product is a manifestation of a derived work (A02-2009-00000A65-4), in this case an abridged edition. Equally, the parent work could be the Sixth edition, and the product a manifestation of the Seventh edition, a derived work.

supplying multiple parent ISTCs for an omnibus edition
using Reference names
`<RelatedWork>`
`<WorkRelationCode>02</WorkRelationCode>`
`<WorkIdentifier>`
`<WorkIDType>11</WorkIDType>`
`<IDValue>A022009000000951</IDValue>`
`</WorkIdentifier>`
`</RelatedWork>`
`<RelatedWork>`
`<WorkRelationCode>02</WorkRelationCode>`
`<WorkIdentifier>`
`<WorkIDType>11</WorkIDType>`
`<IDValue>A022009000000964</IDValue>`
`</WorkIdentifier>`
`</RelatedWork>`
`<RelatedWork>`
`<WorkRelationCode>02</WorkRelationCode>`
`<WorkIdentifier>`
`<WorkIDType>11</WorkIDType>`
`<IDValue>A0220090000009B3</IDValue>`
`</WorkIdentifier>`
`</RelatedWork>`

using Short tags
`<relatedwork>`
`<x454>02</x454>`	Is manifestation of work derived from
`<workidentifier>`
`<b201>11</b201>`	ISTC
`<b244>A022009000000951</b244>`	Of Sense and Sensibility
`</workidentifier>`
`</relatedwork>`
`<relatedwork>`
`<x454>02</x454>`	Is manifestation of work derived from
`<workidentifier>`
`<b201>11</b201>`	ISTC
`<b244>A022009000000964</b244>`	Of Pride and Prejudice
`</workidentifier>`
`</relatedwork>`
`<relatedwork>`
`<x454>02</x454>`	Is manifestation of work derived from
`<workidentifier>`
`<b201>11</b201>`	ISTC
`<b244>A0220090000009B3</b244>`	Of Northanger Abbey
`</workidentifier>`
`</relatedwork>`

The omnibus edition does not (yet) have an ISTC of its own (it could be registered as a work derived by compilation of the three parent works).

supplying an internal work identifier
using Reference names
`<RelatedWork>`
`<WorkRelationCode>01</WorkRelationCode>`
`<WorkIdentifier>`
`<WorkIDType>01</WorkIDType>`
`<IDTypeName>KP-biblio-work-ID</IDTypeName>`
`<IDValue>2283</IDValue>`
`</WorkIdentifier>`
`</RelatedWork>`

using Short tags
`<relatedwork>`
`<x454>01</x454>`	Manifestation of
`<workidentifier>`
`<b201>01</b201>`	Proprietary
`<b233>KP-biblio-work-ID</b233>`
`<b244>2283</b244>`
`</workidentifier>`
`</relatedwork>`

Proprietary internal identifiers such as this always require a ‘namespace’ – a likely-to-be-unique name for the identifier. Without such a namespace, many companies are likely to have works with the internal number 2283.

using the ISBN of the first-published version as a proprietary work identifier of last resort
using Reference names
`<RelatedWork>`
`<WorkRelationCode>01</WorkRelationCode>`
`<WorkIdentifier>`
`<WorkIDType>01</WorkIDType>`
`<IDTypeName>CE-titoloID</IDTypeName>`
`<IDValue>CET9780001234567</IDValue>`
`</WorkIdentifier>`
`</RelatedWork>`

using Short tags
`<relatedwork>`
`<x454>01</x454>`	Manifestation of
`<workidentifier>`
`<b201>01</b201>`	Proprietary
`<b233>CE-titoloID</b233>`
`<b244>CET9780001234567</b244>`
`</workidentifier>`
`</relatedwork>`

It is common for publishers with legacy IT systems to use an ISBN to identify ‘works’. Typically this is the ISBN of the first product that manifests the work – sometimes termed the ‘title ISBN’ or ‘head ISBN’ – and is often the hardback ISBN. There is an obvious potential for confusion.

When using an ISBN as a proprietary work ID, the publisher has prefixed the ISBN with ‘CET’. This is in addition to the provision of the ‘CE-titoloID’ name for the proprietary identifier, and greatly reduces the level of doubt when an ISBN is used to identify a work: the prefix makes it obvious that the identifier is not being used as an ISBN in this context and reduces the likelihood that a recipient will confuse the internal work ID with a product ID.

Related work composite

The strongly-preferred work identifier is the ISTC, and it is best practice to supply an ISTC that has been registered for the work manifested in the product, with a <WorkRelationCode> of 01 from List 164. Any parent or source works, or known child or derived works should also be specified, with <WorkRelationCode> codes 02 and 03 respectively – the supply of parent and child ISTCs greatly enhances the value of the data for collocation of multiple products.

The diagram illustrates the relationship between the product (which is the subject of the Product record) and various works, with the <WorkRelationCode> codes used with the ISTCs of those works:

Note that List 164 says nothing about the nature or method of derivation of derived works – whether by revision, abridgement, translation, adaptation, addition of ancillary non-textual content etc.

However, it is recognized that only a small number of publishers have so far started registering ISTCs. Where an ISTC has not been registered, reliable internal identifiers still have some utility. Internal identifiers will not have the valuable cross-publisher quality of ISTC, but may still help retailers create clusters of a single publisher’s products which contain the same textual content. Internal identifiers should normally use <WorkIDType> 01 (Proprietary), and should always have an <IDTypeName> to distinguish them from similar internal identifiers used by other publishers.

It’s worth noting that when proprietary work IDs are provided, the ‘rules’ governing what constitutes a single work are inevitably unknown to the ONIX data recipient. Are abridged editions or second editions the same work as the original, or different works? A publisher’s internal view of what constitutes a single work is sometimes much wider than the model inherent in the ISTC. Since the scope of the proprietary identifier is unknown, it is difficult to interpret relationships between works expressed with proprietary identifiers, whereas with ISTC these relationships are closely defined and are an important part of the value provided by an ISTC.

Ideally, the scope of a proprietary work identifier should be the same or similar to that of the ISTC. That is, it should identify the content of the product. Changes to the content – such as through significant addition or revision, abridgement, adaptation, translation etc – should necessitate a new work identifier. ‘Work’ identifiers with a broader scope (eg where the second edition has the same work identifier as the first, or where the abridged and unabridged versions have the same work identifier) are not recommended.

In the absence of a reliable internal work identifier, some companies use the ISBN of the first-published version of a work (sometimes called a ‘title ISBN’ or ‘head ISBN’) to collocate all versions of the same work. A similar practice arises when a publisher allocates an ISBN to an e-book ‘master file’, from which several different products are derived: this is often (erroneously) termed an ‘e-ISBN’. However the individual products are identified – and best practice would be to allocate each of them a unique ISBN – the master file’s ISBN can be used to signify that they are all manifestations of the same content. It should be noted that the master file should generally not have its own ISBN and ONIX record, as it is usually not a product in its own right. But it is frequently given a ‘for internal purposes only’ ISBN that is used in ONIX records communicated between the publisher and a technical intermediary who may use the master file to create several products. In these cases, an ISBN is being used in place of a work identifier. As a last resort, this ISBN may be supplied as a proxy work identifier in ONIX records – but should never be included if there is any other work identifier available. It is best practice to identify this proxy as a proprietary work identifier (ie <WorkIDType> code 01), although it could theoretically be supplied with <WorkIDType> code 15. When used as an internal work identifier, the ISBN is being used ‘out of context’ and not as an ISBN (which by definition and when used correctly identifies a product). Given the ubiquity of ISBN as a product identifier and the ease of recognition of the ‘978’ and ‘979’ prefixes, it is strongly recommended that when an ISBN is used in a different context – as a proprietary identifier of something other than a product – then it should be modified in some way to ensure it cannot be interpreted as an ISBN. It could be modified by adding a prefix or suffix, or in any other way that ensures it looks unlike an ISBN.

: Some companies use an e-book ISBN to identify a master file that is also a product in its own right, perhaps an EPUB format file from which other e-book file formats can be derived. This is like using a ‘title ISBN’ or ‘head ISBN’, and the same advice applies. Take great care, as it is easy to confuse ISBN as product identifier with the same ISBN being used as a work identifier.

P.23 Related products

The <RelatedProduct> composite is primarily intended to be used to specify the ISBNs of any similar or related products, though other identifiers may be used. Information about related products is invaluable to retailers, who can ensure the customer is aware of the full range of product options, and may be able to offer a customer alternatives if the desired product is unavailable for any reason.

The <RelatedProduct> composite should be used:

when a ‘work’ is available in multiple versions (for example, in hardback, paperback, and as one or more e-books);
- this might include other products which are (in ISTC terms) not the same work – abridgements, illustrated versions and so on;
when one product is superseded by another (eg a second edition supersedes the first, and a media-tie in version may replace an original);
to list other products in the same collection;
when a product is also available as part of an omnibus, set, bundle or other multi-part product;
to link to parts of an omnibus, bundle or set that are available separately.

If <ProductComposition> indicates the product is a multi-item product (ie using codes 10, 11, 30 from List 2), <RelatedProduct> should not repeat relationships to component products that are included as product parts in Group P.4.

Each repeat of the <RelatedProduct> composite must contain an identifier for the related product, and must specify the relationship between the product and the related product. In general, further information about the related product should not be provided.

There are a large number of ways two products may be related, and two individual products may have multiple relationships. For example, one ISBN may be an e-book version of another (print) product, and <ProductRelationCode> codes 06 and 13 from List 51 may both apply. Or a product tied to release of a movie may include codes 03, 06 and 18 relating it to the earlier non-tie in version. The <ProductRelationCode> element is repeatable to accommodate these multiple relationships.

Where the product is related to many other products, then each related product is identified in a separate repeat of the <RelatedProduct> composite. Although <ProductIdentifier> is repeatable within <RelatedProduct>, each <RelatedProduct> composite lists just one related product – thought that one product may have multiple identifiers. The repeatability of <ProductIdentifier> is not used to list multiple products within a single <RelatedProduct> composite – instead, repeat the whole <RelatedProduct> composite for each related product.

new product replaces a previous version (2011 edition replaces 2010 edition)
using Reference names
`<RelatedProduct>`
`<ProductRelationCode>03</ProductRelationCode>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9782849026335</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9782849026335</IDValue>`
`</ProductIdentifier>`
`</RelatedProduct>`

using Short tags
`<relatedproduct>`
`<x455>03</x455>`	Replaces
`<productidentifier>`
`<b221>03</b221>`	GTIN-13
`<b244>9782849026335</b244>`	(of 2010 edition)
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9782849026335</b244>`	(of 2010 edition)
`</productidentifier>`
`</relatedproduct>`

The sample is from the Product record for the 2011 edition. In the Product record for the 2011 edition, the ISBN of the 2010 edition is listed as a related product with the relationship ‘replaces’. In an updated Product record for the 2010 edition – which may show the 2010 edition as going out of print – the ISBN of the 2011 edition should be listed with the relationship ‘replaced by’ (code 05 from List 51).

linking an e-publication to other alternative formats of the same work
using Reference names
`<RelatedProduct>`
`<ProductRelationCode>13</ProductRelationCode>`
`<ProductRelationCode>06</ProductRelationCode>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780007120765</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780007120765</IDValue>`
`</ProductIdentifier>`
`</RelatedProduct>`
`<RelatedProduct>`
`<ProductRelationCode>06</ProductRelationCode>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780007234387</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780007234387</IDValue>`
`</ProductIdentifier>`
`</RelatedProduct>`

using Short tags
`<relatedproduct>`
`<x455>13</x455>`	Epublication based on
`<x455>06</x455>`	Alternative format
`<productidentifier>`
`<b221>03</b221>`	GTIN-13
`<b244>9780007120765</b244>`	(of paperback)
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780007120765</b244>`	(of paperback)
`</productidentifier>`
`</relatedproduct>`
`<relatedproduct>`
`<x455>06</x455>`	Alternative format
`<productidentifier>`
`<b221>03</b221>`	GTIN-13
`<b244>9780007234387</b244>`	(of hardcover)
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780007234387</b244>`	(of hardcover)
`</productidentifier>`
`</relatedproduct>`

linking a print-on-demand facsimile product to its original
using Reference names
`<RelatedProduct>`
`<ProductRelationCode>24</ProductRelationCode>`
`<ProductRelationCode>16</ProductRelationCode>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780002130325</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780002130325</IDValue>`
`</ProductIdentifier>`
`</RelatedProduct>`

using Short tags
`<relatedproduct>`
`<x455>24</x455>`	Is facsimile of
`<x455>16</x455>`	POD replacement for
`<productidentifier>`
`<b221>03</b221>`	GTIN-13
`<b244>9780002130325</b244>`	(of original)
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780002130325</b244>`	(of original)
`</productidentifier>`
`</relatedproduct>`

linking a t-shirt to the book it promotes
using Reference names
`<RelatedProduct>`
`<ProductRelationCode>08</ProductRelationCode>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780684833392</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780684833392</IDValue>`
`</ProductIdentifier>`
`</RelatedProduct>`

using Short tags
`<relatedproduct>`
`<x455>08</x455>`	The t-shirt is ancillary to the book
`<productidentifier>`
`<b221>03</b221>`	GTIN-13
`<b244>9780684833392</b244>`	(of the book)
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	ISBN
`<b244>9780684833392</b244>`	(of the book)
`</productidentifier>`
`</relatedproduct>`

The t-shirt is the product here – the separate record for the book could include the t-shirt as a related product, but with a different <ProductRelationCode> (code 07 instead of code 08).

Related product composite

The <RelatedProduct> includes the <ProductIdentifier> composite described in Group P.2, and similar best practice applies.

It’s true to say that <RelatedProduct> and <RelatedWork> can sometimes provide the same information: a product may be linked to several others via <ProductRelationCode> 06 (Alternative format), and all those products would be manifestations of the same ISTC, which could be specified in <RelatedWork>. However, it is good practice to include both <RelatedWork> and <RelatedProduct> composites whenever possible: not all ONIX recipients are able to make use of <RelatedWork>, and each composite adds different detail to the relationship between two products.

<RelatedProduct> might in principle also duplicate information provided in <ProductPart> in Group P.4, particularly when using the <ProductRelationCode> 02 (Product includes related product). It is good practice to include identifiers for multi-item products in <ProductPart> and not to repeat them in <RelatedProduct>. ONIX recipients should make use of identifiers listed in <ProductPart> in addition to those in <RelatedProduct.

The most important relationships from List 51 include:

code	relation
06	<Product> is available in an alternative format as <RelatedProduct>
06	use to link hardback, paperback, e-book versions, where the content is essentially identical. Linking two products implies they are the same work, and they may also be linked through sharing a single work identifier (that is, in <RelatedWork>, each product would specify that they are manifestations of the same work using <WorkRelationCode> 01)
01	<Product> includes <RelatedProduct>
02	<Product> is included within <RelatedProduct>
02	use for multi-item products which include items that are themselves available individually. Also use where the content from one product is included in another product – for example with an omnibus edition, or where a chapter of a book is also made available as an independent product. This latter relationship also implies that the two products may be linked through <RelatedWork> using codes 02 and 03 too (they are not manifestations of the same work, but one work may be derived from the other)
03	<Product> replaces <RelatedProduct>
05	<Product> is replaced by <RelatedProduct>
05	use to link new and previous editions, or whenever one product completely supersedes another. The two products would generally be manifestations of different works, but one work would often be derived from the other, and this implies they may also be linked using codes 02 and 03 in <RelatedProduct>. Do not use for ‘paperback replaces hardback’ – for that, use code 06 instead. Note that a particular Product record might well have related products with both codes 03 and 05 – a sixth edition replaces the fifth, and towards the end of its life is itself replaced by the seventh edition (and the sixth edition work would be derived from the fifth, and would in turn have the seventh derived from it)
18	<Product> is a special edition based on the basic version <RelatedProduct>
19	<Product> is also available as a special edition, as <RelatedProduct>
19	use to link normal with tie-in, gift, illustrated or similar types of ‘special’ editions (generally of the same work – though if extra content is included in the special edition, it may represent a derived work). Do not use for ordinal numbered editions (use codes 03 and 05 instead), or for facsimile editions (use codes 24 and 25 instead), or for enhanced e-books (use 28 and 29);
30	<Product> is a member of a collection, which also includes <RelatedProduct>
30	use to link together all products in a collection, particularly useful if there is no collection identifier supplied in Group P.5. The members of the collection would generally not have particular work relationships to each other
13	<Product> is an e-book based on the print version <RelatedProduct>
27	<Product> is the print version on which <RelatedProduct> is based
27	use to link an e-book and its previously-published paper equivalent (when paper and e-book version are published contemporaneously, then the e-book is just another format and should be related with code 06). This implies the paper and digital products are the same work, and may also be linked via a sharing a code 01 work identifier in <RelatedWork>
28	<Product> is an enhanced version of <RelatedProduct>
29	<Product> is a basic version of <RelatedProduct> (29)
29	use to link basic and enhanced e-books. The enhanced e-book is a manifestation of a new work derived from the basic work (or possibly the other way around, if the basic version were created by removal of material from the enhanced version)
26	<Product> is a separate license that covers usage of <RelatedProduct>
26	use when <RelatedProduct> is digital, and available separately
22	<Product> is by the same author as <RelatedProduct>
23	if you liked <RelatedProduct>, you’ll love <Product>
23	these relationships normally apply at work level. When relating products, ensure <Product> and <RelatedProduct> appeal to the same market – for example, both <Product> and <RelatedProduct> are mass market paperbacks, or both are audiobooks
07	<Product> has ancillary or supplementary <RelatedProduct>
08	<Product> is ancillary or supplementary to <RelatedProduct>
08	use for example to link a promotional poster to the product it is promoting, or where general merchandise (t-shirt, mug, tote-bag) is linked to a particular product

Note the direction of these relationships. Many come in pairs: if one is used in a particular Product record, then the ‘opposite’ or inverse relationship is used in the ‘other’ Product record (the record for the related product). Others, including codes 06, 22 and 30, are their own opposites.

It is a common error to get the direction of the relationship wrong. For example, an ONIX Product record that describes a hardback or paperback book may list an e-book as a related product. That relationship must use code 27, not code 13. Conversely, the Product record describing the e-book should list the print book as a related product, using the inverse relationship code (ie must use code 13, not 27).

In all cases, there is no requirement that <RelatedProduct> identifies a product published by the same publisher, nor does it imply anything about the status or availability of the related product. Further metadata for the related product should be obtained from the full Product record for that product.

P.23.5, P.23.6 Related product form and form detail

The <RelatedProduct> composite may include limited information about the product form of a related product. This is strongly discouraged, except in circumstances where the ONIX recipient specifically requests this information.

Normal ONIX practice is that all metadata for related products should be derived from the full Product record of the related product – only identifiers should be included within a <RelatedProduct> composite. The <ProductForm> and <ProductFormDetail> data elements are provided in <RelatedProduct> specifically for use in cases where the data recipient does not receive (and does not want to receive) full Product records for the related products – as for example might be the case where ONIX metadata is provided to a specialist e-book retailer and that retailer does not wish to receive full records about related print products.

Block 6: Product supply

Product supply composite

The <ProductSupply> composite is intended to carry supply chain information – where a product may be ordered from, how much it will cost, when it will be available and so on. But this information is market-specific, and separate repeats of the <ProductSupply> composite should be used to specify different information that applies to different markets.

Note that <ProductSupply> is the only block-level composite in a Product record that is repeatable, once for each market the product is available in. Block 6 of a Product record in principle consists of all the <ProductSupply> composites in the record.

ONIX 3.0 uses a four-level structure to describe the geographical supply arrangements for a product:

First, there are the territorial sales rights in Group P.21, which lists all the territories where a publisher wishes to sell the product (including territories where the publisher has exclusive or non-exclusive rights);
these territories may be a single market, or may be divided into two or more independent markets, each of which is represented by a <ProductSupply> composite. If there are multiple markets, there are – at least in principle – multiple <ProductSupply> composites;
within a market, there may be one or multiple suppliers (distributors, wholesalers and so on), each represented by a <SupplyDetail> composite;
each supplier may set multiple prices, and each price might only be valid in a single country, or may be valid in multiple countries.

: Of course, not every market need be listed in a particular ONIX record. It may be that the sender of the ONIX message specifies details of only the market within which the message is distributed, omitting irrelevant information about other markets. So the market territories listed may be a subset of the sales rights territories, and other market(s) exist by implication only.; Where a specific list of countries or regions is not included, the assumption must be that the list is inherited from the next ‘higher’ level – so a price without an attached list of countries must be valid throughout the market, and a <ProductSupply> composite that does not include a list of countries or regions must be assumed to mean that the market is the totality of the <SalesRights> area.; This structure in ONIX 3.0 is significantly different from ONIX 2.1. In 3.0, suppliers operate within markets, whereas in 2.1, suppliers have supply-to countries – the order of the hierarchy is modified. And in 3.0, geographical information about sales rights, market extent and price validity consistently use the same XML composite – <Territory>. In 2.1, sales rights, supply-to countries and prices all use quite different XML structures.

So what is a ‘market’? In general, where a product is distributed from a single source – say from one exclusive distributor – then there is a single market. Multiple markets are characterized by there being:

more than one exclusive distributor, each having an exclusive geographical territory or an exclusive sales channel;
- in this case, the sales rights that the publisher is exploiting (see Group P.21) are divided up into narrower and disjunct sets of distribution rights that are granted by the publisher to different distributors. It’s clear that the distribution territories must ‘fit within’ the overall sales rights territories;
- it is of course possible that distribution territories or channels overlap, but at least part of a market must be exclusive, otherwise it is not a distinct market;
significant differences in publication date (or more specifically, in initial market availability date) or other dates and statuses.

Varying prices across different countries or regions, or having multiple non-exclusive distributors or wholesalers do not in themselves indicate that there are multiple markets.

So <ProductSupply> describes the product supply chain in a particular market. The <ProductSupply> composite itself has a three part structure:

the <Market> composite, Group P.24 describes the geographical (or channel-based) extent of the market;
- <Market> may be omitted when the product is available in only a single market, since the market would be identical to the <SalesRights> included in Group P.21;
the <MarketPublishingDetail> composite, Group P.25 specifies the status and availability of the product in the market;
- <MarketPublishingDetail> may also be omitted in some circumstances, when the product is available in only a single market;
the mandatory <SupplyDetail> composite, Group P.26 carries supplier and pricing details for the product in the market. There can be multiple suppliers, each represented by a repeat of the <SupplyDetail> composite, and a supplier may maintain multiple prices each applicable in a variety of territories.

Note that there is no particular requirement that a Product record contains information on all markets that a product is available in. It is possible for a publisher to provide information on just a single market, even when the product is available more widely, if for example an ONIX data feed is tailored to a specific retailer recipient and that retailer’s operations are clearly within the confines of that market. Or a wholesaler may provide an ONIX feed containing only the details of the market within which it operates, while the data recipient may be a global retailer operating across many markets. (Of course in these cases, <Market> and perhaps <MarketPublishingDetail> should not be omitted). Because of this, great care needs to be taken by recipients who receive ONIX records describing a specific product from multiple sources (a retailer might receive an ONIX record for a particular product from the publisher, from a data aggregator, and from one or more wholesalers). A newly-supplied Block 6 should not replace all data in the recipient’s internal system, but should in most cases only replace data previously received from that particular data supplier.

Additional guidance on the description of markets in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Specify Markets and Suppliers in ONIX 3.

P.24 Market

Group P.24 describes the extent of a market – usually in geographical terms, but it may also be limited by sales channel (eg to schools only) and may even be limited to a single customer. It defines the extent of the market within which the following <MarketPublishingDetail> and <SupplyDetail> data applies.

It is obviously important that any specification of the extent of a market does not extend beyond the bounds of the geographical area where the product is for sale as specified in Group P.21, or beyond any sales restriction that applies – any market which includes countries or regions where the product that is not for sale, or which fails to specify sales restrictions that match those in P.21, sets up an internal inconsistency that cannot be resolved by the data recipient. The sum of all markets must be a subset of, or identical to, the publisher’s sales rights. If P.24 is omitted, then the market is understood to be identical to the extent of the publisher’s sales rights.

<Market> should never be omitted when a product is available in multiple markets, even if the particular Product record contains details of only one of those markets.

market where publisher holds and exploits world rights via one supply chain, but where a separate exclusive distributor has been appointed for Africa (excepting the Maghreb countries, Egypt and some island states)
using Reference names
`<Market>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`<CountriesExcluded>AO BJ BW BF BI CM CF TD KM CD CG CI DJ GQ ER ET GA GM GH GN GW KE LS LR LY MG MW ML MZ NA NE NG RW SN SL SO ZA SD SZ TZ TG UG ZM ZW</CountriesExcluded>`
`</Territory>`
`</Market>`

using Short tags
`<market>`
`<territory>`
`<x450>WORLD</x450>`	World
`<x451>AO BJ BW BF BI CM CF TD KM CD CG CI DJ GQ ER ET GA GM GH GN GW KE LS LR LY MG MW ML MZ NA NE NG RW SN SL SO ZA SD SZ TZ TG UG ZM ZW</x451>`	Excluding most of Africa
`</territory>`
`</market>`

The market for the African distributor in a second repeat of the <ProductSupply> composite would simply include all the countries excluded here.

markets where the publisher holds and exploits rights throughout world except the ‘US market’ (which in this case includes Canada, Mexico and the Philippines). The product will be published with a strict sales embargo date in the UK, but with a later pub date and no embargo in the remainder of the world
using Reference names
`<ProductSupply>`
`<Market>`
`<Territory>`
`<CountriesIncluded>GB</CountriesIncluded>`
`</Territory>`
`</Market>`
`<!-- <MarketPublishingDetail>, <SupplyDetail> omitted for brevity -->`
`</ProductSupply>`
`<ProductSupply>`
`<Market>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`<CountriesExcluded>AS CA GB GU MP MX PH PR UM US VI</CountriesExcluded>`
`</Territory>`
`</Market>`
`<!-- <MarketPublishingDetail>, <SupplyDetail> omitted for brevity -->`
`</ProductSupply>`

using Short tags
`<productsupply>`	First market – UK
`<market>`
`<territory>`
`<x449>GB</x449>`
`</territory>`
`</market>`
`<!-- <marketpublishingdetail>, <supplydetail> omitted for brevity -->`	<MarketPublishingDetail> carries details of UK pub date, embargo etc (which are identical to the ‘global’ details in Group P.20). <SupplyDetail> carries details of supplier(s) in UK market
`</productsupply>`
`<productsupply>`	Second market – rest of world
`<market>`
`<territory>`
`<x450>WORLD</x450>`
`<x451>AS CA GB GU MP MX PH PR UM US VI</x451>`	(excluding GB and the US market)
`</territory>`
`</market>`
`<!-- <marketpublishingdetail>, <supplydetail> omitted for brevity -->`	<MarketPublishingDetail> carries detail of the ROW availability date (which is later than the pub date in P.20)
`</productsupply>`

market where publisher holds rights only in the schools market in Europe (in this case ‘Europe’ is the EU and EFTA)
using Reference names
`<Market>`
`<Territory>`
`<CountriesIncluded>AT BE BG CY CZ DE DK EE ES FI FR GB GR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</CountriesIncluded>`
`</Territory>`
`<SalesRestriction>`
`<SalesRestrictionType>07</SalesRestrictionType>`
`</SalesRestriction>`
`</Market>`

using Short tags
`<market>`
`<territory>`
`<x449>AT BE BG CY CZ DE DK EE ES FI FR GB GR HU IE IT LT LU LV MT NL PL PT RO SE SI SK CH IS LI NO</x449>`	31 countries in the EU and EFTA
`</territory>`
`<salesrestriction>`
`<b381>07</b381>`	Schools only
`</salesrestriction>`
`</market>`

In this case, the sales restriction applies to all countries in the market, since it is nested within the only <Market> composite. If it applied only to some of the market, then two repeats of the <Market> composite could be used as in the example below (remember – the market is the sum of the various repeats of <Market>). cf the use of different <SalesRightsType> codes in Group P.21 to indicate whether any sales restrictions apply.

market where a publisher exploits world rights, but has agreed a temporary retailer exclusive in Spain. The product is for general trade sale outside Spain
using Reference names
`<Market>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`<CountriesExcluded>ES</CountriesExcluded>`
`</Territory>`
`</Market>`
`<Market>`
`<Territory>`
`<CountriesIncluded>ES</CountriesIncluded>`
`</Territory>`
`<SalesRestriction>`
`<SalesRestrictionType>04</SalesRestrictionType>`
`<SalesOutlet>`
`<SalesOutletName>Casa del Libro</SalesOutletName>`
`</SalesOutlet>`
`<EndDate dateformat="00">20110828</EndDate>`
`</SalesRestriction>`
`</Market>`

using Short tags
`<market>`	First part of market
`<territory>`
`<x450>WORLD</x450>`	Everywhere…
`<x451>ES</x451>`	Except Spain
`</territory>`
`</market>`
`<market>`	Second part of market
`<territory>`
`<x449>ES</x449>`
`</territory>`
`<salesrestriction>`
`<b381>04</b381>`	Retailer exclusive in Spain
`<salesoutlet>`
`<b382>Casa del Libro</b382>`
`</salesoutlet>`
`<b325 dateformat="00">20110828</b325>`	Until 28 Aug 2011
`</salesrestriction>`
`</market>`

In a slight variation of this case, Casa del Libro’s exclusivity might extend throughout Europe – and if so, it would be better to exclude all EU and EFTA countries from the first part of the market and include them in the second part of the market, to make it clear the product is not for sale through Spanish language bookshops in south-west France or elsewhere in Europe.

‘windowed’ sales restrictions in the North American market
using Reference names
`<Market>`
`<Territory>`
`<CountriesIncluded>CA MX US</CountriesIncluded>`
`</Territory>`
`<SalesRestriction>`
`<SalesRestrictionType>09</SalesRestrictionType>`
`<EndDate>20150423</EndDate>`
`</SalesRestriction>`
`<SalesRestriction>`
`<SalesRestrictionType>12</SalesRestrictionType>`
`<EndDate>20150625</EndDate>`
`</SalesRestriction>`
`</Market>`

using short tags
`<market>`
`<territory>`
`<x449>CA MX US</x449>`
`</territory>`
`<salesrestriction>`
`<b381>09</b381>`	not for sale to libraries
`<b325>20150423</b325>`	…until 24 April
`</salesrestriction>`
`<salesrestriction>`
`<b381>12</b381>`	not for sale to subscription services
`<b325>20150625</b325>`	…until 26 June
`</salesrestriction>`
`</market>`

The product is for sale throughout North America, but cannot be sold to libraries until late April, and cannot be sold to ‘subscription’ services until late June. Note that the end date attached to each restriction is ‘inclusive’, so the restriction still holds on that date.

‘Subscription’ services in this case are those that provide readers with ‘all you can eat’ access to a library of e-books for a fixed monthly fee, but where those e-books that are read by consumers are purchased by the service from the publisher or distributor. They are usually purhased ‘on demand’, with the purchase triggered by a consumer beginning to read, or when a consumer reads beyond a preset ‘free preview’ limit that may be set using <EpubUsageConstraint>.

Market composite

The <Market> composite is repeatable, and in some cases – particularly where a market restriction applies in only part of a market – multiple repeats may be necessary. The extent of the ‘market’ is the sum of all the repeats of <Market>. It is obvious good practice to minimize the number of repeats, consistent with correct description of the extent of the market itself.

Territory and Sales restriction composites

The <Territory> and <SalesRestriction> composites are identical to those in Group P.21, and similar best practices apply.

However, there is no ‘rest of world’ option within <Market> analogous to <ROWSalesRightsType> within <SalesRights>, and ROW is not a valid option for a region (ROW on List 49 is not used in ONIX 3).

P.25 Market publishing detail

Group P.25 – the <MarketPublishingDetail> composite – comprises three largely separate types of information, all of which are specific to a particular market:

in <PublisherRepresentative>, details of any local publisher or agent acting on behalf of the publisher that makes the product available in the market;
a market-specific publishing status and relevant dates, analogous to those provided globally by the publisher in Group P.20;
selected details of any promotional campaign, copies printed or sold, and other miscellaneous information.

Market publishing detail composite

Each <ProductSupply> composite should include a <MarketPublishingDetail> composite, unless the following three conditions are all true:

the publisher deals directly with distributors, wholesalers, retailers, and possibly with consumers, in which case the <PublisherRepresentative> composite should be omitted;
the product is available in only a single market, in which case the publishing status and dates provided at ‘global’ level in P.20 apply, and need not be repeated in P.25;
- note that if there is a <PublisherRepresentative> composite, market publishing status and dates must not be omitted, even if there is only a single market. Group P.20 should reflect the publisher’s status, and Group P.25 should reflect the publisher’s representative’s status;
there is no relevant data to include in the remainder of the <MarketPublishingStatus> composite (elements from P.25.17 to P.25.22).

If the original publisher works through a local publisher or a sales agent (in this particular market), <PublisherRepresentative> should include the agent’s or publisher’s role and organizational details. Some countries and agencies maintain formal identifier schemes for publishers and agents. Where such identifiers are used, they should be included in the <AgentIdentifier> composite.

<MarketPublishingDetail> must include a <MarketPublishingStatus> element giving the publisher’s representative’s status for the product. At least one <MarketDate> composite should be included, to carry the market-specific ‘publication date’ of the product (unless this is specifically precluded by the <MarketPublishingStatus>). Additional relevant market-specific dates should also be specified, including any metadata or sales embargoes and any ‘out of print in this market’ date.

Data providers must ensure that the market status and dates are consistent with any global status and dates provided in Block 4. Market-specific dates cannot be earlier than the global dates (though they can be identical).

If <MarketPublishingDetail> is omitted, then the ‘global’ information in Block 4 should be used by ONIX recipients to determine the extent of the market plus relevant dates and statuses.

<MarketPublishingDetail> should never be omitted when a product is available in multiple markets, even if the particular Product record contains details of only one of those markets. And note that when market-specific details are provided in P.25, it is still best practice to include ‘global’ details in P.20 (even though it is not essential). Doing so makes clear the difference between a product that is available in only one market, and a Product record that contains details of only one market, and expresses nuanced differences between ‘publication date’ and ‘publication date in this market’.

product from UK publisher available through Australian local publisher
using Reference names
`<MarketPublishingDetail>`
`<PublisherRepresentative>`
`<AgentRole>07</AgentRole>`
`<AgentName>HarperCollins Publishers</AgentName>`
`<Website>`
`<WebsiteRole>18</WebsiteRole>`
`<WebsiteLink>http://www.harpercollins.com.au</WebsiteLink>`
`</Website>`
`</PublisherRepresentative>`
`<MarketPublishingStatus>02</MarketPublishingStatus>`
`<MarketDate>`
`<MarketDateRole>01</MarketDateRole>`
`<Date dateformat="00">20110707</Date>`
`</MarketDate>`
`</MarketPublishingDetail>`

using Short tags
`<marketpublishingdetail>`
`<publisherrepresentative>`
`<j402>07</j402>`	Local publisher
`<j401>HarperCollins Publishers</j401>`
`<website>`
`<b367>18</b367>`	Publisher’s consumer website
`<b295>http://www.harpercollins.com.au</b295>`
`</website>`
`</publisherrepresentative>`
`<j407>02</j407>`	Forthcoming
`<marketdate>`
`<j408>01</j408>`	Local publication date
`<b306 dateformat="00">20110707</b306>`
`</marketdate>`
`</marketpublishingdetail>`

Any publication date provided in P.20 may be the same as or earlier than the local publication date in P.25 – but for obvious reasons should never be later than the P.25 date. ONIX recipients should use the dates and status provided in P.25, unless specifically concerned with the global position.

Publisher representative composite

A publisher’s representative may be a ‘local publisher’ or a sales agent responsible for a market, but is always an organization, not a person. A local publisher undertakes responsibility for the product in the market – certainly including promotion and distribution, possibly including manufacturing copies of the product, and potentially including legal liabilities that normally lie with the publisher. A local publisher may or may not be named on the product itself: they may be in effect a co-publisher, or simply acting as a distribution agent. In contrast, a sales agent takes on fewer responsibilities – likely limited to promotion and distribution.

What distinguishes a publisher’s representative from a normal importer, distributor, wholesaler or retailer? A representative would be associated with a distinct market, and takes on at least part of the publisher’s role, for example controlling the publication or availability date, within that market. The original publisher would have no direct role in that market, except via the representative.

This composite is – in most respects – the local market equivalent of the <Publisher> composite in Group P.19, and similar best practices apply. Although almost every part of the <PublisherRepresentative> composite is optional, it is best practice to include – at minimum – the mandatory <AgentRole> element and the optional <AgentName>, with any identifiers and the organization’s website if available.

: ‘Agent’ here does not imply the use of the ‘Agency model’.

Product contact

This composite is analogous to the <ProductContact> composite in Group P.19, although in this case it may carry contact details provided by the publisher’s representative in the market.

: This composite replaces the use of the <PromotionContact> date element, plus <TelephoneNumber>, <FaxNumber> and <EmailAddress> within <PublisherRepresentative>, which have been deprecated.

P.25.12 Market publishing status

This data element is directly analogous to <PublishingStatus> in Group P.20, and similar best practices apply. Note however that it uses a different codelist (List 68). When it is provided, a market-specific publishing status or date supersedes any ‘global’ status or date provided in P.20 for the specific market only.

Similarly, some statuses require associated dates in <MarketDate>.

specifying the product is ‘out of print in this market’
using Reference names
`<MarketPublishingStatus>07</MarketPublishingStatus>`
`<MarketDate>`
`<MarketDateRole>13</MarketDateRole`
`<Date dateformat="00">20091022</Date>`
`</MarketDate>`

using Short tags
`<j407>07</j407>`
`<marketdate>`
`<j408>13</j408`
`<b306 dateformat="00">20091022</b306>`
`</marketdate>`

The implication here – because it is not ‘globally’ out of print – is that the product is still in print in another market. Only the local publisher or publisher’s representative has declared it out of print.

P.25.17 to P.25.22 Promotion details

These data elements relate to promotional activity in a particular market.

The most likely to be used is the <PromotionalCampaign> data element: this should be used to specify market-specific advertising and promotion plans prior to publication or reissue – the planned use of print or broadcast advertising, for example, any author tour or other media tie-ins. There is some overlap here with information that can be provided in Group P.16, which can include links to press releases or an author tour itinerary. However, details in P.25 are market-specific, and are clearly intended for trade use only.

If <PromotionalCampaign> details are provided, it is good practice to also supply a contact name in <PromotionContact> for queries about the promotional activity. This would normally be the person responsible for advertising and promotion of the product in this particular market – a person in the publisher’s or publisher’s representative’s publicity department for example.

The <InitialPrintRun> data element might be used to provide details of limited and numbered editions (see <EditionType> codes NUM, SPE in Group P.9), but best practice would be to provide this information in an <EditionStatement> element. Use <InitialPrintRun> only when the size of the print run is to be treated as ‘promotional’ – for example, to express the confidence the publisher has in the product.

P.26 Supply detail

Group P.26 is the <SupplyDetail> composite, and it is the most complex of the Groups in the ONIX for Books Specification. However, large parts of the Group are optional and used only rarely: the commonly-used parts of the <SupplyDetail> composite are limited to two composites – <Supplier> and <Price>, plus a handful of data elements specifying the availability of the product from the supplier.

In the case of physical products, a ‘supplier’ is normally a distributor or wholesaler from whom a retailer can obtain the product for resale. For digital products, the ‘supplier’ is normally a ‘retail platform’, which may be operated for or by a single retail entity, or by a platform owner offering technical fulfillment services to a range of retailers.

Supply detail composite

There must be at least one <SupplyDetail> composite within the <ProductSupply> composite. And each repeat of <SupplyDetail> describes one supplier, and must contain details of:

the supplier’s identity and contact details, in the <Supplier> composite;
the availability of the product from that supplier, in the <ProductAvailability> element;
- <ProductAvailability> should carry a datestamp attribute to indicate how current the data is;
- certain availabilities should be accompanied by dates in the <SupplyDate> composite and possibly an order lead time in <OrderTime>;
- for physical products, the <ReturnsConditions> composite should indicate whether the product can be returned to the supplier, and the number of items in each carton or binder’s pack should be quoted in <PackQuantity>;
either a <Price> composite, or <UnpricedItemType> to indicate that the product is not priced:
- free of charge products must use <UnpricedItemType>, not a <PriceAmount> of zero.

The <Supplier> composite:

must include the supplier’s role in the supply chain;
should include the business name of the supplier organization in the <SupplierName> element;
should include any applicable formal identifiers for the supplier organization or location. The preferred identifier for international use is the GLN (Global Location Number), but some countries and agencies maintain other identifier schemes for suppliers or supplier locations, and identifiers used in the territories where the product is sold should be included;
should include contact details for the supplier such as telephone number and e-mail address.

For any one supplier, there may be multiple prices – because the supplier may plan to change the price in the future, or because the supplier may offer the product at different prices in different territories or to different types of customer. Each supplier should list all the prices valid in all territories they deal with (within the confines of the market), including prices that apply only to specific classes of customer (for example, corporate/institutional prices, or prices only applicable to library customers).

Each <Price> composite:

should include the type of price and terms of trade (recommended retail price, fixed retail price, net wholesale price, agency price etc);
must include the price itself;
should specify the price either tax-inclusive or tax-exclusive (never both);
- prices should be quoted exc-tax in North America, and in other territories where prices are advertised exc-tax;
tax-inclusive prices should include a breakdown of the taxes included within the quoted price;
- inclusion of tax details almost inevitably means the price is only valid in one specific country;
- there should be no tax details for a price quoted exc-tax;
where the price is supplied on trade discount (wholesale pricing, or more generally, a reseller model) or agency terms (ie not a net wholesale price but one on which the retailer is paid commission), the <Price> composite should specify the discount or commission, as a percentage or as a discount code, using the <Discount> or <DiscountCoded> composites;
should include the applicable currency, and the territory within which the price is valid;
- where the territory is omitted, the recipient should assume the price is valid throughout the market;
- the territory should never extend beyond the confines of the market;
if a future price change is planned, the current and future prices should both be included, with dates to indicate the validity of each;
for physical products, should indicate whether the price is printed on the product itself.

For reissues, the <Reissue> composite should not be used.

Within any specific market – as represented by the whole <ProductSupply> composite – there must be at least one, and may be many suppliers: each supplier is represented by a <SupplyDetail> composite.

Each supplier would normally, but need not be willing (or even able to) supply the product to every part of the market. Setting prices that are valid for specific territories indicates an offer to supply to those territories. The price need not be set in the currency of the country involved. So a Spanish publisher could set export prices in Euro valid for various countries which do not themselves use the Euro internally.

But note that price territories must be a subset of or identical to the market territories, which are either specified in Group P.24 or are understood to be identical to the publisher’s sales rights specified in Group P.21 if P.24 is omitted.

Additional guidance on the description of suppliers and price territories in ONIX 3.0 will be found in a separate document ONIX for Books Product Information Message: How to Specify Markets and Suppliers in ONIX 3.

supplier of forthcoming product is publisher/distributor of physical book
using Reference names
`<SupplyDetail>`
`<Supplier>`
`<SupplierRole>01</SupplierRole>`
`<SupplierIdentifier>`
`<SupplierIDType>06</SupplierIDType>`
`<IDValue>8001234567897</IDValue>`
`</SupplierIdentifier>`
`<SupplierName>Campione Editore</SupplierName>`
`<TelephoneNumber>+39 0123 45678901</TelephoneNumber>`
`<EmailAddress>vendite@campioneeditore.com</EmailAddress>`
`</Supplier>`
`<ReturnsConditions>`
`<ReturnsCodeType>04</ReturnsCodeType>`
`<ReturnsCode>03</ReturnsCode>`
`</ReturnsConditions>`
`<ProductAvailability datestamp="20110517">10</ProductAvailability>`
`<SupplyDate>`
`<SupplyDateRole>08</SupplyDateRole>`
`<Date dateformat="00">20110621</Date>`
`</SupplyDate>`
`<PackQuantity>8</PackQuantity>`
`<Price>`
`<PriceType>02</PriceType>`
`<Discount>`
`<DiscountPercent>37.5</DiscountPercent>`
`</Discount>`
`<PriceStatus>02</PriceStatus>`
`<PriceAmount>7.95</PriceAmount>`
`<Tax>`
`<TaxType>01</TaxType>`
`<TaxRateCode>P</TaxRateCode>`
`<TaxRatePercent>4<TaxRatePercent>`
`<TaxableAmount>7.64</TaxableAmount>`
`<TaxAmount>0.31</TaxAmount>`
`</Tax>`
`<CurrencyCode>EUR</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>IT</CountriesIncluded>`
`</Territory>`
`<PrintedOnProduct>02</PrintedOnProduct>`
`<PositionOnProduct>00</PositionOnProduct>`
`</Price>`
`<!-- Price composites for other countries omitted -->`
`</SupplyDetail>`

using Short tags
`<supplydetail>`
`<supplier>`
`<j292>01</j292>`	Publisher supplies retailers
`<supplieridentifier>`
`<j345>06</j345>`	GLN
`<b244>8001234567897</b244>`
`</supplieridentifier>`
`<j137>Campione Editore</j137>`
`<j270>+39 0123 45678901</j270>`
`<j272>vendite@campioneeditore.com</j272>`
`</supplier>`
`<returnsconditions>`
`<j268>04</j268>`	ONIX returns code
`<j269>03</j269>`	Sale or return
`</returnsconditions>`
`<j396 datestamp="20110517">10</j396>`	Not yet published
`<supplydate>`
`<x461>08</x461>`	Expected availability
`<b306 dateformat="00">20110621</b306>`	YYYYMMDD format
`</supplydate>`
`<j145>8</j145>`	Packed 8 per carton
`<price>`
`<x462>02</x462>`	RRP including tax
`<discount>`
`<j267>37.5</j267>`
`</discount>`
`<j266>02</j266>`	Firm
`<j151>7.95</j151>`
`<tax>`
`<x470>01</x470>`	VAT
`<x471>P</x471>`	Tax paid at source
`<x472>4<x472>`	%
`<x473>7.64</x473>`
`<x474>0.31</x474>`
`</tax>`
`<j152>EUR</j152>`	€
`<territory>`
`<x449>IT</x449>`	Price valid only in Italy
`</territory>`
`<x301>02</x301>`	Price is printed on product
`<x313>00</x313>`	Position is unspecified
`</price>`
`<!-- prices for other countries omitted -->`
`</supplydetail>`

Special tax rules in Italy allow VAT to be prepaid by the publisher. Books are subject to VAT at the 4% rate.

supplier is distributor of POD product
using Reference names
`<SalesRights>`
`<SalesRightsType>01</SalesRightsType>`
`<Territory>`
`<RegionsIncluded>WORLD<RegionsIncluded>`
`<CountriesExcluded>CA US VI GU AS PR PH UM MX</CountriesExcluded>`
`</Territory>`
`</SalesRights>`
`<SalesRights>`
`<SalesRightsType>06</SalesRightsType>`
`<Territory>`
`<CountriesIncluded>CA US VI GU AS PR PH UM MX<CountriesIncluded>`
`</Territory>`
`</SalesRights>`
`<!-- no ROW sales rights type needed -->`
`. . .`
`<SupplyDetail>`
`<Supplier>`
`<SupplierRole>0</SupplierRole>`
`<SupplierIdentifier>`
`<SupplierIDType>06</SupplierIDType>`
`<IDValue>5030670160471</IDValue>`
`</SupplierIdentifier>`
`<SupplierName>Lightning Source</SupplierName>`
`<EmailAddress>info@lightningsource.com</EmailAddress>`
`</Supplier>`
`<ReturnsConditions>`
`<ReturnsCodeType>04</ReturnsCodeType>`
`<ReturnsCode>02</ReturnsCode>`
`</ReturnsConditions>`
`<ProductAvailability datestamp="20120324">23</ProductAvailability>`
`<OrderTime>1</OrderTime>`
`<Price>`
`<PriceType>02</PriceType>`
`<DiscountCoded>`
`<DiscountCodeType>01</DiscountCodeType>`
`<DiscountCode>AKOGA095</DiscountCode>`
`</DiscountCoded>`
`<PriceStatus>02</PriceStatus>`
`<PriceAmount>29.95</PriceAmount>`
`<Tax>`
`<TaxType>01</TaxType>`
`<TaxRateCode>Z</TaxRateCode>`
`<TaxRatePercent>0</TaxRatePercent>`
`<TaxableAmount>29.95</TaxableAmount>`
`<TaxAmount>0.00</TaxAmount>`
`</Tax>`
`<CurrencyCode>GBP</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>GB</CountriesIncluded>`
`</Territory>`
`<PrintedOnProduct>02</PrintedOnProduct>`
`<PositionOnProduct>01</PositionOnProduct>`
`</Price>`
`<Price>`
`<PriceType>01</PriceType>`
`<DiscountCoded>`
`<DiscountCodeType>01</DiscountCodeType>`
`<DiscountCode>AKOGA096</DiscountCode>`
`</DiscountCoded>`
`<PriceStatus>02</PriceStatus>`
`<PriceAmount>29.95</PriceAmount>`
`<!-- no tax composite -->`
`<CurrencyCode>GBP</CurrencyCode>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`<CountriesExcluded>GB CA US VI GU AS PR PH UM MX</CountriesExcluded>`
`</Territory>`
`<PrintedOnProduct>01</PrintedOnProduct>`
`</Price>`
`</SupplyDetail>`

using Short tags
`<salesrights>`
`<b089>01</b089>`
`<territory>`
`<x450>WORLD<x450>`	For sale everywhere
`<x451>CA US VI GU AS PR PH UM MX</x451>`	…except US, CA, MX market
`</territory>`
`</salesrights>`
`<salesrights>`
`<b089>06</b089>`	Not for sale, as publisher
`<territory>`	…has no rights in
`<x449>CA US VI GU AS PR PH UM MX<x449>`	…US, CA, MX market
`</territory>`
`</salesrights>`
`<!-- no ROW sales rights type needed -->`	Because all exceptions to world rights are explicitly associated with type 06
`. . .`
`<supplydetail>`
`<supplier>`
`<j292>0</j292>`
`<supplieridentifier>`
`<j345>06</j345>`	GLN
`<b244>5030670160471</b244>`
`</supplieridentifier>`
`<j137>Lightning Source</j137>`
`<j272>info@lightningsource.com</j272>`
`</supplier>`
`<returnsconditions>`
`<j268>04</j268>`	ONIX returns codes
`<j269>02</j269>`	Firm sale
`</returnsconditions>`
`<j396 datestamp="20120324">23</j396>`	Available POD
`<j144>1</j144>`	One day turnaround
`<price>`
`<x462>02</x462>`	Price inc tax
`<discountcoded>`
`<j363>01</j363>`	BIC discount code scheme
`<j364>AKOGA095</j364>`
`</discountcoded>`
`<j266>02</j266>`	Firm price
`<j151>29.95</j151>`
`<tax>`
`<x470>01</x470>`	VAT
`<x471>Z</x471>`	…is zero-rated
`<x472>0</x472>`
`<x473>29.95</x473>`
`<x474>0.00</x474>`
`</tax>`
`<j152>GBP</j152>`	Pounds Sterling
`<territory>`
`<x449>GB</x449>`	Price applicable in GB only
`</territory>`
`<x301>02</x301>`	Price printed
`<x313>01</x313>`	…on back cover
`</price>`
`<price>`
`<x462>01</x462>`	Price ex tax
`<discountcoded>`
`<j363>01</j363>`	BIC discount code scheme
`<j364>AKOGA096</j364>`
`</discountcoded>`
`<j266>02</j266>`	Firm price
`<j151>29.95</j151>`
`<!-- no tax composite -->`	…as price is ex-tax
`<j152>GBP</j152>`	Pounds Sterling
`<territory>`
`<x450>WORLD</x450>`	Price applicable everywhere
`<x451>GB CA US VI GU AS PR PH UM MX</x451>`	…except GB (where other price is applicable) and US, CA, MX market (where the product is not for sale)
`</territory>`
`<x301>01</x301>`	This price not printed on product
`</price>`
`</supplydetail>`

Recommended retail price in UK is £29.95 including tax. Recommended retail price elsewhere is £29.95 plus any local taxes.

supplier is exclusive retail platform for e-book, on agency terms, for US and Canadian market
using Reference names
`<ProductSupply>`
`<!-- Group P.24 -->`
`<Market>`
`<Territory>`
`<CountriesIncluded>CA US VI GU AS PR PH UM</CountriesIncluded>`
`</Territory>`
`</Market>`
`<!-- Group P.25 -->`
`<MarketPublishingDetail>`
`<MarketPublishingStatus>02</MarketPublishingStatus>`
`<MarketDate>`
`<!-- nominal publication date -->`
`<MarketDateRole>01</MarketDateRole>`
`<Date dateformat="00">20110816</Date>`
`</MarketDate>`
`<MarketDate>`
`<MarketDateRole>02</MarketDateRole>`
`<Date dateformat="00">20110809</Date>`
`</MarketDate>`
`</MarketPublishingDetail>`
`<!-- Group P.26 -->`
`<SupplyDetail>`
`<Supplier>`
`<SupplierRole>10</SupplierRole>`
`<SupplierName>e-books4U</SupplierName>`
`<TelephoneNumber>+1 212 555 0123</TelephoneNumber>`
`<EmailAddress>info@ebooks4u.com</EmailAddress>`
`</Supplier>`
`<ProductAvailability datestamp="20110621">10</ProductAvailability>`
`<SupplyDate>`
`<SupplyDateRole>02</SupplyDateRole>`
`<Date dateformat="00">20110809</Date>`
`</SupplyDate>`
`<Price>`
`<PriceType>41</PriceType>`
`<DiscountCoded>`
`<DiscountCodeType>05</DiscountCodeType>`
`<DiscountCodeTypeName>MyBooks Agency Type</DiscountCodeTypeName>`
`<DiscountCode>B</DiscountCode>`
`</DiscountCoded>`
`<PriceStatus>02</PriceStatus>`
`<PriceAmount>7.99</PriceAmount>`
`<CurrencyCode>USD</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>US VI GU AS PR PH UM</CountriesIncluded>`
`</Territory>`
`</Price>`
`<Price>`
`<PriceType>41</PriceType>`
`<DiscountCoded>`
`<DiscountCodeType>05</DiscountCodeType>`
`<DiscountCodeTypeName>MyBooks Agency Type</DiscountCodeTypeName>`
`<DiscountCode>B</DiscountCode>`
`</DiscountCoded>`
`<PriceStatus>02</PriceStatus>`
`<PriceAmount>7.49</PriceAmount>`
`<CurrencyCode>CAD</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>CA</CountriesIncluded>`
`</Territory>`
`</Price>`
`</SupplyDetail>`
`</ProductSupply>`

using Short tags
`<productsupply>`
`<!-- Group P.24 -->`
`<market>`
`<territory>`
`<x449>CA US VI GU AS PR PH UM</x449>`
`</territory>`
`</market>`
`<!-- Group P.25 -->`
`<marketpublishingdetail>`
`<j407>02</j407>`
`<marketdate>`
`<MarketDateRole>01</MarketDateRole>`	Nominal publication date
`<Date dateformat="00">20110816</Date>`
`</marketdate>`
`<marketdate>`
`<j408>02</j408>`	Embargo (strict on-sale) date
`<b306 dateformat="00">20110809</b306>`
`</marketdate>`
`</marketpublishingdetail>`
`<!-- Group P.26 -->`
`<supplydetail>`
`<supplier>`
`<j292>10</j292>`	Exclusive distributor to end customers
`<j137>e-books4U</j137>`
`<j270>+1 212 555 0123</j270>`
`<j272>info@ebooks4u.com</j272>`
`</supplier>`
`<j396 datestamp="20110621">10</j396>`	Not yet available
`<supplydate>`
`<x461>02</x461>`	Embargo date
`<b306 dateformat="00">20110809</b306>`
`</supplydate>`
`<price>`
`<x462>41</x462>`	‘Agency’ price, exc-tax
`<discountcoded>`
`<j363>05</j363>`	Proprietary commission terms code
`<j378>MyBooks Agency Type</j378>`
`<j364>B</j364>`
`</discountcoded>`
`<j266>02</j266>`	Firm price
`<j151>7.99</j151>`
`<j152>USD</j152>`	US$ price
`<territory>`
`<x449>US VI GU AS PR PH UM</x449>`	for US market
`</territory>`
`</price>`
`<price>`
`<x462>41</x462>`	‘Agency’ price, exc-tax
`<discountcoded>`
`<j363>05</j363>`	Proprietary commission terms code
`<j378>MyBooks Agency Type</j378>`
`<j364>A</j364>`
`</discountcoded>`
`<j266>02</j266>`
`<j151>7.49</j151>`
`<j152>CAD</j152>`	CA$ price
`<territory>`
`<x449>CA</x449>`	for Canada only
`</territory>`
`</price>`
`</supplydetail>`
`</productsupply>`

The retail platform (the supplier) can sell exclusively to the US market and Canada, in either US$ or CA$, but retail price is fixed by the publisher (the ‘agency’ model). The publisher maintains a code indicating to the reseller what commission % it will receive on each sale. If the publisher has rights beyond the US market and Canada, a second <ProductSupply> composite could carry the wider market and supply details.

future increase in recommended retail price
using Reference names
`<Price>`
`<PriceType>01</PriceType>`
`<DiscountCoded>`
`<DiscountCodeType>01</DiscountCodeType>`
`<DiscountCode>ATAFR005</DiscountCode>`
`</DiscountCoded>`
`<PriceStatus>02</PriceStatus>`
`<PriceAmount>7.99</PriceAmount>`
`<CurrencyCode>EUR</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>AT BE CY FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC ME SM VA</CountriesIncluded>`
`</Territory>`
`<PriceDate>`
`<PriceDateRole>15</PriceDateRole>`
`<Date>20120429</Date>`
`</PriceDate>`
`</Price>`
`<Price>`
`<PriceType>01</PriceType>`
`<DiscountCoded>`
`<DiscountCodeType>01</DiscountCodeType>`
`<DiscountCode>ATAFR005</DiscountCode>`
`</DiscountCoded>`
`<PriceStatus>02</PriceStatus>`
`<PriceAmount>8.99</PriceAmount>`
`<CurrencyCode>EUR</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>AT BE CY FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC ME SM VA</CountriesIncluded>`
`</Territory>`
`<PriceDate>`
`<PriceDateRole>14</PriceDateRole>`
`<Date>20120430</Date>`
`</PriceDate>`
`</Price>`

using Short tags
`<price>`
`<x462>01</x462>`	RRP exc-tax
`<discountcoded>`
`<j363>01</j363>`	BIC discount code
`<j364>ATAFR005</j364>`
`</discountcoded>`
`<j266>02</j266>`	Price is firm
`<j151>7.99</j151>`
`<j152>EUR</j152>`
`<territory>`
`<x449>AT BE CY FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC ME SM VA</x449>`
`</territory>`
`<pricedate>`
`<x476>15</x476>`	Price valid until
`<b306>20120429</b306>`	29th April
`</pricedate>`
`</price>`
`<price>`
`<x462>01</x462>`	RRP exc-VAT
`<discountcoded>`
`<j363>01</j363>`
`<j364>ATAFR005</j364>`
`</discountcoded>`
`<j266>02</j266>`
`<j151>8.99</j151>`	Increased price
`<j152>EUR</j152>`
`<territory>`
`<x449>AT BE CY FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC ME SM VA</x449>`
`</territory>`
`<pricedate>`
`<x476>14</x476>`	New price valid from
`<b306>20120430</b306>`	30th April
`</pricedate>`
`</price>`

Dates are inclusive. That is, the end date for one price should be the day before the start date of the next price. Prices are assumed to switch outside business hours between the two trading days, or at midnight, unless specific time and timezone details are included.

temporary special offer pricing (two price method)
using Reference names
`<Price>`
`<PriceType>07</PriceType>`	Wholesale price inc-tax
`<PriceTypeQualifier>00</PriceTypeQualifier>`	‘Normal’ unqualified price
`<Discount>`
`<Quantity>10</Quantity>`
`<DiscountPercent>6.5</DiscountPercent>`
`</Discount>`
`<PriceAmount>49.00</PriceAmount>`
`<Tax>`
`<TaxType>01</TaxType>`	VAT
`<TaxRateCode>R</TaxRateCode>`	at Reduced rate
`<TaxRatePercent>6</TaxRatePercent>`	of 6%
`<TaxableAmount>46.25</TaxableAmount>`	Ex-VAT price
`<TaxAmount>2.75</TaxAmount>`	Tax payable
`</Tax>`
`<CurrencyCode>SEK</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>SE</CountriesIncluded>`
`</Territory>`
`</Price>`
`<Price>`
`<PriceType>07</PriceType>`	Wholesale price inc-tax
`<PriceTypeQualifier>08</PriceTypeQualifier>`	‘Special offer’
`<PriceAmount>39.00</PriceAmount>`	Reduced by SEK10.00
`<Tax>`
`<TaxType>01</TaxType>`	VAT
`<TaxRateCode>R</TaxRateCode>`	at Reduced rate
`<TaxRatePercent>6</TaxRatePercent>`	of 6%
`<TaxableAmount>36.75</TaxableAmount>`	Ex-VAT price
`<TaxAmount>2.25</TaxAmount>`	Tax payable
`</Tax>`
`<CurrencyCode>SEK</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>SE</CountriesIncluded>`
`</Territory>`
`<PriceDate>`
`<PriceDateRole>24</PriceDateRole>`
`<Date dateformat="12">Swedish Book Promotion Week</Date>`	This lower price only valid for a short period (normally, exact start and end dates are provided. In this case, exact dates unknown – should be supplied in later update message)
`</PriceDate>`
`</Price>`

using Short tags, prices provided ex-VAT (and therefore without the <Tax> composite)
`<price>`
`<x462>05</x462>`	Wholesale price exc-tax
`<j261>00</j261>`	‘Normal’ unqualified price
`<discount>`
`<x320>10</x320>`	Additional volume discount
`<j267>6.5</j267>`	below wholesale price
`</discount>`
`<j151>46.25</j151>`
`<j152>SEK</j152>`	Swedish Krona
`<territory>`
`<x449>SE</x449>`	Price valid in Sweden only
`</territory>`
`</price>`
`<price>`
`<x462>07</x462>`	Wholesale price
`<j261>08</j261>`	‘Special offer’
`<j151>36.75</j151>`
`<j152>SEK</j152>`	Swedish Krona
`<territory>`
`<x449>SE</x449>`	Price valid in Sweden only
`</territory>`
`<pricedate>`
`<x476>24</x476>`	Price valid during
`<b306 dateformat="12">Swedish Book Promotion Week</b306>`	Exact dates of period unknown
`</pricedate>`
`</price>`

The product is available on wholesale terms to the Swedish book trade, at SEK49 including 6% Swedish VAT (or SEK46.25 ex VAT in the short tags example). A discount of 6.5% below the normal wholesale price applies for orders of 10 copies or more. The product is planned to be available on ‘special offer’ for a reduced wholesale price of SEK39 (or SEK36.75 ex VAT in the short tags example) for a short promotional period, though no volume discount will apply to orders at the promotional price. The dates of the promotional period are as yet uncertain: this is a rare use of dateformat code 12 from List 55 for a complex, approximate or uncertain date, and the details should be updated as soon as the exact dates of Book Promotion Week are known, with something like <b306 dateformat="06">2012013120120213</b306> (ie 31st Jan to 13th Feb 2012). See the closed-end price promotion example in discussion of the Price date composite

Supplier composite

The <Supplier> composite is mandatory, and should contain enough information to clearly identify a supplier for the product. This might be as little as the name of the supplier organization, but ideally would include multiple contact options too – telephone, e-mail, fax and an identifier that might be used in any electronic ordering system. Ideally, phone and fax numbers should be full international numbers – +1 212 555 0123 rather than (212) 555-0123.

Within the <Supplier> composite, a ‘role’ is mandatory. This data element describes the position of the supplier in the supply chain, in relation to the original publisher and the end purchaser or consumer, and lets recipients of the data (other than the supplier) know where an order can be directed. In most physical supply chains, the key parties are publishers, distributors (also sometimes called ‘vendors of record’), wholesalers and retailers or library suppliers. Some publishers act also as distributors, whereas others appoint distributors to act on their behalf, and ‘publishers’ may in some cases be market-specific representatives of the originating publisher. The supply chain for digitally-delivered products is more varied, with intermediaries offering a variety of services that ultimately connect publisher to consumer.

For physically-delivered products, the ‘supplier’ is an organization to which an order for a product might be directed by a downstream customer. So a distributor is a supplier (for wholesalers and usually also for retailers). A retailer is a supplier too, though it is perhaps less clear at whom a message containing a <Supplier> composite that describes a retail offering might be aimed (the retailer’s website is one possibility).

For digitally-delivered products, the supplier is also the organization to which orders should be directed. So for example, a publisher offering direct fulfillment of e-publications to consumers might name itself as the supplier. In contrast, a publisher of products that are unique to a specific ‘retail platforms’ should name that platform as the supplier. And ONIX data sent from a publisher that contracts with a digital services intermediary might name the intermediary as the ‘supplier’, since it is to the intermediary that a retailer might apply prior to retailing that publisher’s catalog. Individual consumer orders handled by the retailer would be forwarded to the digital services intermediary, from whom the consumer would download the file.

For all these various scenarios, the supplier’s position within the supply chain must be specified using the <SupplierRole> data element and a code from List 93.

Certain countries operate identification schemes for companies and/or locations. These are often vital enablers for e-commerce systems that allow ONIX recipients to place orders with particular suppliers. In territories where a particular identification system is used, the identifiers should be included in a <SupplierIdentifier> composite – and in particular, suppliers should ensure that all identifiers used within any e-commerce system in which the supplier participates are included. The preferred identifier for international usage is the GLN.

Supplier own coding composite

Publisher’s sales guidance
using Reference names
`<SupplierOwnCoding>`
`<SupplierCodeType>03</SupplierCodeType>`
`<SupplierCodeTypeName>Collins Sales Guide</SupplierCodeTypeName>`
`<SupplierCodeValue>B+</SupplierCodeValue>`
`</SupplierOwnCoding>`

using Short tags
`<supplierowncoding>`
`<x458>03</x458>`
`<x513>Collins Sales Guide</x513>`
`<x459>B+</x459>`	indicates level of expected sales
`</supplierowncoding>`

Indication of backlist / frontlist status
using Reference names
`<SupplierOwnCoding>`
`<SupplierCodeType>04</SupplierCodeType>`
`<SupplierCodeTypeName>Apple Price Agreement</SupplierCodeTypeName>`
`<SupplierCodeValue>F</SupplierCodeValue>`
`</SupplierOwnCoding>`

using Short tags
`<supplierowncoding>`
`<x458>04</x458>`
`<x513>Apple Price Agreement</x513>`
`<x459>F</x459>`	indicates Frontlist (so price agreement applies)
`</supplierowncoding>`

Supplier own coding should only be used when the information is supplier-specific. All codes are necessarily proprietary, and although <SupplierCodeTypeName> is not mandatory (for compatibility with versions earlier than 3.0.2), it is best practice for suppliers to agree – and use – consistent naming for each type of code.

The <SupplierOwnCoding> composite is used to carry supplier-specific information from publisher to supplier, or from supplier to retailer. The examples above show publisher-to-supplier information – a guide to expected sales, which the supplier might use to gauge how many copies to order prior to publication, a code indicating the backlist / frontlist status of the product, which may be used to control contractual limits on pricing (eg in this case via Apple), and a yes/no indication of whether the product can be included in a ‘subscription’ collection.

Returns conditions composite

Since in many countries, most but not all products in the physical book supply chain are offered on a sale-or-return basis, it is vital that all such products should specify their returnability.

The simplest way to specify returnability is to make use of the ONIX Returns Conditions codes in List 204, which can indicate whether the goods are on consignment, firm sale, or ‘sale or return’. An alternative for North American use is the BISAC Returns codes in List 66, which specifies a basic set of four codes – returnable, not returnable, conditional (ie contact the supplier) and strippable (ie returnable, but only the cover need be sent back). However, some countries maintain other code lists, and it is best practice to include the relevant codes from lists in widespread use across the territories where the supplier operates. Where a standard returns code is not appropriate, a proprietary returns coding scheme can be used.

Returns conditions can be a key data element when products switch from normal stock availability to print-on-demand, or to out of print. POD products are often not returnable, and the change of Returns conditions plus the Product availability and Order time may be the only three data elements that changed when this switch happens. Ideally, a supplier would provide some notice of the latest date on which returns will be accepted, using the <SupplyDate> composite.

In principle, electronically-delivered products such as e-books are subject to returns too – a consumer might return a product for technical reasons, for example – but such returns are normally dealt with by the retailer as a customer service issue and an adjustment made to the sales reports: there is nothing physical to return. The <ReturnsConditions> composite should not usually be included for electronically-delivered products.

P.26.17 Product availability

The <ProductAvailability> data element is mandatory within the <SupplyDetail> composite.

It is good practice to add a datestamp attribute to the <ProductAvaialbility> data element, particularly where the ‘age’ of the availability data is different from the overall age of the message derived from <SentDateTime> in the message header.

Some values of <ProductAvailability>, from List 65, should also be accompanied by a <SupplyDate> composite, for example giving an expected availability date (from the supplier in question) or latest date that returns will be accepted (by the supplier in question). Sales embargo dates should not be included here (or at least, not only here): it is best practice to supply these in either Group P.20 (for globally-administered embargoes) or Group P.25 (for embargoes applied 2in a specific market).

Note that different suppliers may report different availabilities at the same time – a product may be out of stock at one wholesaler for example, while being available from stock at another. <ProductAvailability> is unique to a supplier, and need not even reflect the publisher’s <PublishingStatus> supplied in Group P.20: the publisher may declare a product out of print, while a supplier retains stock. At that point, and depending on the original terms of trade, a supplier may have the opportunity to return unsold stock, or retain the stock for continued retail fulfillment.

For products that are not normally available from stock – particularly those that are available print-on-demand or only-to-order (ie <ProductAvailability> codes 22 and 23), it is best practice to include the <OrderTime> data element, so an ONIX recipient may judge the expected delay in fulfilling an order. An <OrderTime> of zero means a same-day service, but typical values are more likely to be 1–3 days for print-on-demand and longer for only-to-order.

For digital products, availability is usually much simpler than for physical items: only a subset of the codes in List 65 are likely to be appropriate.

Availability codes from List 65 (for digital products)
product availability from supplier	code
Cancelled	01
Not yet available ³	02
Available	20
Temporarily unavailable ³	30
Temporarily withdrawn ³	34
Not available	40
Not available, replaced by new product	41
Not available, other format available	42
No longer supplied by us	43
Withdrawn from sale	46
Not available, publisher indicates OP ¹	51
Not available, publisher no longer sells product in this market ²	52

¹ ie publisher no longer sells product in any market
² eg for rights reasons
³ a <SupplyDate> composite should also be provided. Note that this status implies the product can be ‘pre-ordered’ (subject to any pre-order embargo listed in <PublishingDate>)

Stock quantity composite

ONIX data suppliers may or may not wish to provide details of stock quantities held at their distribution locations. Such information can be commercially sensitive – but can also be valuable to retailers as it helps avoid large orders being placed when only small numbers of copies are in stock. Stock quantities can be either accurate numbers of copies, or can be deliberately obfuscated to reduce their sensitivity – the optional <Proximity> element is used to indicate the likely accuracy of the stock figure.

It can also be useful for distributors and wholesalers to provide an estimate of the rate of sale of existing stock, known as stock velocity, as an indicator of likely future exhaution of stock (and this can also be subject to an optional proximity value). When combined with stock figures, velocity infomation reduces the likelihood of orders that can only be part fulfilled, or of a backorder

The entire <Stock> composite is repeatable if the supplier has multiple locations from which stock might be fulfilled, and in this case, a <LocationName> (or perhaps a location identifier) should be included. If the supplier has only a single location, then neither the location name nor an identifier is necessary.

<Stock> is not relevant with POD, OTO or digital products.

providing an approximate stock quantity
using Reference names
`<Stock>`
`<LocationName>Carlisle</LocationName>`
`<OnHand datestamp="20100921">1400</OnHand>`
`<Proxmimity>06</Proximity>`
`<Velocity>`
`<VelocityMetric>01</VelocityMetric>`
`<Rate>125</Rate>`
`<Proximity>05</Proximity>`
`</Velocity>`
`</Stock>`

using Short tags
`<stock>`
`<j349>Carlisle</j349>`	Warehouse location
`<j350 datestamp="20100921">1400</j350>`	Copies (on 21st Sept)
`<x502>06</x502>`	Not less than
`<velocity>`
`<x504>01</x504>`	Mean daily sale (measured over last month)
`<x505>125</x505>`	Copies
`<x502>05</x502>`	About (within factor of two)
`</velocity>`
`</stock>`

In this case, a retailer could be confident of rapid delivery of an sizeable order if placed with the supplier immediately, since there are at least 1400 copies in stock, and stock is unlikely to be exhausted within a week or so. However, more than a few days delay in placing an order could result in part-fulfillment or a backorder (mean stock depletion lies between 63 and 250 copies per day).

For time-sensitive data elements or composites such as <Stock> the datestamp attribute can be valuable, particularly if there is any significant difference between the ‘age’ of the stock report and the overall age of the message derived from <SentDateTime> in the message header.

Note that <OnHand> is defined as the number of copies available to fulfill orders – it does not include in-stock copies that have already been committed to fulfilling an order. Some distributors and wholesalers term this their ‘free stock’. It is possible for free stock – and thus <OnHand> – to go negative if order commitments exceed the number of copies in stock and no further copies are on order. Committed orders could be fulfilled using returned copies. But if further new copies are on order to cover those order commitments, then any particular committment should be counted either as negative free stock or as a (positive) <CBO> quantity. Ensure outstanding orders are not counted twice. Given <OnHand> of -100, <OnOrder> of 1000 and <CBO> of 250, the supplier will have 650 copies free stock after delivery of the on order copies.

Within the <Velocity> composite, <Rate> can also be negative in some rare circumstances, where returns more than offset orders.

The stock reporting functionality provided in ONIX 3.0 is essentially identical to that provided by the EDItX Stock Report message format, and is similar to that in earlier, equivalent X.12, EDIFACT or Tradacoms EDI messages.

P.26.41 Pack or carton quantity

It is good practice to include a <PackQuantity> data element where possible, though it is recognized that this information is not always available.

This information is provided for the convenience of recipients who wish to order in carton quantities. A pack or carton quantity does not imply that orders must be for an exact multiple of the carton quantity: a pack quantity of (for example) 8 does not mean that a orders for 1, 5 or 15 copies will not be accepted. It means only that orders for 8, 16 or 24 copies are likely to be fulfilled using whole cartons rather than ‘loose’ copies. If arbitrary numbers of copies are not available from the supplier – if only multiples of the pack quantity may be ordered – then the carton should be treated as a multi-item trade pack (<ProductComposition> code 30).

P.26.42 Unpriced item type

Unpriced item type should be used to describe products that are free of charge, products where a price has not yet been announced, or products where no price is applicable – for example, where a product is not retailed separately or where the product is available on revenue-share terms. In particular, for free of charge products, <UnpricedItemType> 01 (see List 57) should always be used in place of a <Price> composite where the Price amount is zero. Similarly, an <UnpricedItemType> should be used as a placeholder in a Product record sent prior to setting a price, using code 02 – though it is good practice to announce a price as soon as possible, even if it is unconfirmed and uses <PriceStatus> code 01.

free of charge POS item
using Reference names
`<SupplyDetail>`
`<Supplier>`
`. . .`
`</Supplier>`
`<ProductAvailability>21<ProductAvailability>`
`<UnpricedItemType>01</UnpricedItemType>`
`</SupplyDetail>`

using Short tags
`<supplydetail>`
`<Supplier>`
`. . .`
`</Supplier>`
`<j396>21</j396>`	In stock
`<j192>01</j192>`	FOC
`</supplydetail>`

unpriced in one market, priced in another
using Reference names
`<ProductSupply>`
`<Market>`
`<Territory>`
`<CountriesIncluded>US CA</CountriesIncluded>`
`</Territory>`
`<SalesRestriction>`
`<SalesRestrictionType>13<SalesRestrictionType>`
`</SalesRestriction>`
`</Market>`
`<SupplyDetail>`
`<Supplier>`
`. . .`
`</Supplier>`
`<ProductAvailability>10</ProductAvailability>`
`<UnpricedItemType>06</UnpricedItemType>`
`</SupplyDetail>`
`</ProductSupply>`
`<ProductSupply>`
`<Market>`
`<Territory>`
`<CountriesIncluded>US CA</CountriesIncluded>`
`</Territory>`
`<SalesRestriction>`
`<SalesRestrictionType>12</SalesRestrictionType>`
`</SalesRestriction>`
`</Market>`
`<Market>`
`<Territory>`
`<RegionsIncluded>WORLD</RegionsIncluded>`
`<CountriesExcluded>US CA</CountriesExcluded>`
`</Territory>`
`</Market>`
`<SupplyDetail>`
`<Supplier>`
`. . .`
`</Supplier>`
`<ProductAvailability>10</ProductAvailability>`
`<Price>`
`. . .`
`</Price>`
`</SupplyDetail>`
`</ProductSupply>`

using Short tags
`<productsupply>`	Market 1
`<market>`
`<territory>`
`<x449>US CA</x449>`	Market is US and Canada
`</territory>`
`<salesrestriction>`	But restricted to
`<b381>13<b381>`	…subscription services only
`</salesrestriction>`
`</market>`
`<supplydetail>`
`<supplier>`
`. . .`
`</supplier>`
`<j396>10</j396>`	Awaiting
`<j192>06</j192>`	Available on revenue share terms
`</supplydetail>`
`</productsupply>`
`<productsupply>`	Market 2
`<market>`
`<territory>`
`<x450>WORLD</x450>`	Everywhere
`<x451>US CA</x451>`	…except US and Canada
`</territory>`
`</market>`
`<market>`	Plus…
`<territory>`
`<x449>US CA</x449>`	US and Canada
`</territory>`
`<salesrestriction>`
`<b381>12</b381>`	…except subscription services
`</salesrestriction>`
`</market>`
`<supplydetail>`
`<supplier>`
`. . .`
`</supplier>`
`<j396>10</j396>`	Awaiting
`<price>`
`. . .`	Price details
`</price>`
`</supplydetail>`
`</productsupply>`

Market 2 is a rare example where the <Market> composite has to be repeated, because the restriction (to everyone except subscription services) applies in one part of the geographical range of the market but not actoss the whole geographical range.

Price composite

The <Price> composite is optional within the <SupplyDetail> composite, but in practice, there must always be either an <UnpricedItemType> element or at least one <Price> composite for each supplier – often there’s more than one price. And obviously, <UnpricedItemType> and <Price> should never occur in the same <SupplyDetail> composite.

The <Price> composite is repeatable within an instance of the <SupplyDetail> composite – a single supplier may maintain several prices at the same time. However, each individual repeat of the <Price> composite should contain a unique combination of <PriceType>, <PriceQualifier>, <PricePer>, <Currency>, <Territory> and validity dates in the <PriceDate> composite – it should always be possible for a customer to select the single price that applies unequivocally. And although <PriceType> is optional where a default price type is supplied in the message header, it should be considered effectively mandatory since it is not good practice to supply a default price type.


: A <PriceAmount> of zero should never be used to indicate a product is free of charge – use <UnpricedItemType> instead.; If a supplier specifies that a product is unpriced in one territory, and carries a price in another, then these two territories must be in separate markets – described within separate repeats of the <ProductSupply> composite. However, it is possible for one supplier to mark the product as unpriced (throughout the whole market), where another supplier provides a price.

Price identifier composite

Where a product is available at a number of different price points – to different customer groups (via <PriceType> and <PriceQualifier>), or with different price conditions, or in different combinations of currency and territory – it may make accurate and granular revenue reporting impossible. Simple aggregated revenue or an average selling price may not be enough to meet the needs of the publisher or an intermediary supplier for royalty or tax purposes. In this case, each price point may be given an arbitrary identifier using <PriceIdentifier>.

The <PriceIdentifier> composite can carry an identifier that is:

unique for each price amount and currency (ie two unrelated products both priced at €4.95 would carry the same identifier);
unique for each price type (ie two unrelated products sold with the same combination of price type and qualifier, conditions, territory etc – but not necessarily at the same actual amount – would carry the same identifier);
unique for each combination of price amount and type (but two unrelated products may still carry the same price identifier if all details of their prices are identical);
unique across products, price points and types.

Whether the ID identifies the price amount, the price type or some combination of both will depend on the choice made by the publisher or supplier. But the price identifier can be included in revenue reporting to ensure that the publisher or intermediary supplier receiving the report can associate revenue with a particular product sold under particular terms and conditions.

There is no standardized scheme for price identifiers, and the only value on List 217 for <PriceIDType> is ‘Proprietary’ (which in turn means that <IDTypeName> is effectively mandatory). A UUID (Universally Unique Identifier) constructed in accordance with RFC 4122 (types 1 or 4) would make a good price identifier, since they can be ‘minted’ automatically on demand, each time a price is created or modified.

P.26.43, P.26.44 Price type code and Price type qualifier

Since prices may be quoted excluding or including tax, may be recommended or fixed retail prices, may be quoted based on different business models (eg wholesale or agency terms), and may have other limitations or conditions (eg only valid pre-publication, or only valid for particular classes of customer, or relate to a three-day rental rather than a purchase), the <PriceType> code should always be included – and if necessary it should be accompanied by the <PriceQualifier> data element and the <PriceCondition> composite.

In general, the Price type code identifies the business model or terms of sale on offer, and Price qualifier limits the applicability of the price to specific customers or circumstances. Price conditions enable expression of rental rather than purchase prices. Prices without a <PriceQualifier> should be assumed to apply to all classes of customer, or – if there are other prices with qualifiers – to all customers to whom another, qualified price does not apply. However, mixing qualified and unqualified prices opens up some ambiguity, so is not recommended – it is best practice to ensure that wherever possible, if any price has a qualification, then all prices within that <SupplyDetail> composite should be qualified. So for example, an institutional price with <PriceQualifier> 06 should not be listed alongside an unqualified ‘consumer’ price: use <PriceQualifier> 05 on the consumer price to make it clear this does not apply to institutional customers. Where necessary, <PriceQualifier> 00 from List 59 can be used to provide a price for all customers to whom other qualifiers do not apply.

Further limitations on the applicability of a price are specified by currency, territory and date. In addition to this, many Price type codes occur in pairs, allowing prices to be quoted excluding tax and including tax. However, the same price should never be quoted using both Price type codes from a single pair: that is, a supplier should never include two <Price> composites that vary only in Price type code, where the two price types are the exc-tax and inc-tax variants of the same pair. So for example, a recommended retail price for sales to consumers in a particular country should be specified with either code 01 or code 02 from List 58, but not both.

Choosing whether to specify prices including or excluding tax depends on the territory:

In North America and other markets where tax rates vary from state to state and province to province, it is normal practice to quote prices excluding sales tax;
- Prices are ‘advertised’ exc-tax, and sales taxes added only at the checkout, so a particular price point chosen for marketing reasons – for example, $10.95 – must be an exc-tax price. If an inc-tax price of $10.95 were provided, that would mean an undesirable advertised price of $10.07 in a particular jurisdiction with 8.75% sales tax. Furthermore, the advertised price would have to be different in each tax jurisdiction (and there are several hundred different sales tax jurisdictions within the USA);
- It is almost impossible for retailers – particularly online retailers – to make use of tax-inclusive prices supplied for territories where sales tax varies according to local jurisdiction;
- Where exc-tax prices are provided, it can be useful to provide a <ProductClassification> composite (see Group P.3) using the Harmonized System or a national product classification, so that recipients can estimate the applicable tax in their particular jurisdiction, prior to receipt of the goods (eg for advance orders);
In Europe, where VAT is applied on a largely national basis, it is normal to quote consumer prices including tax – at least for countries in which the supplier is based or where a tax-inclusive recommended retail price is printed on the product. However, export prices and educational, institutional or corporate (business-to-business) prices are often quoted excluding tax, even within the EU, as some EU countries maintain special regional tax regimes (for example, the Canary Islands have a special local sales tax), and schools or other organizations often prefer exc-VAT pricing;
Where prices are quoted inc-tax, a breakdown of the tax details should be provided in the <Tax> composite. Since tax rates are country-specific, this means that all inc-tax prices apply to a single country only;
- There is an exception, but it is rare. Occasionally a publisher may set a single inc-tax RRP for multiple countries, understanding that this inevitably implies that the underlying exc-tax price varies from country to country. In this case, no <Tax> composite should be included, since even though the inc-tax price is the same, the percentage rate and absolute amount of tax varies across the various countries;
Conversely, where prices are quoted exc-tax, no <Tax> composite should be provided.

including two different qualified prices, with price identifiers
using Reference names
`<Price>`
`<PriceIdentifier>`
`<PriceIDType>01</PriceIDType>`
`<IDTypeName>PRH PTUID</IDTypeName>`
`<IDValue>ff8a5521-fcad-4a3b-89b0-34f2ed131016</IDValue>`
`</PriceIdentifier>`
`<PriceType>02</PriceType>`
`<PriceQualifier>05</PriceQualifier>`
`<!-- details of consumer price inc-tax -->`
`</Price>`
`<Price>`
`<PriceIdentifier>`
`<PriceIDType>01</PriceIDType>`
`<IDTypeName>PRH PTUID</IDTypeName>`
`<IDValue>3e304b73-50f6-432d-8e82-2865198dad73</IDValue>`
`</PriceIdentifier>`
`<PriceType>01</PriceType>`
`<PriceQualifier>06</PriceQualifier>`
`<!-- details of institutional price exc-tax -->`
`</Price>`

using Short tags
`<price>`
`<priceidentifier>`
`<x506>01</x506>`	Proprietary ID
`<b233>PRH PTUID</b233>`	for revenue reporting
`<b244>ff8a5521-fcad-4a3b-89b0-34f2ed131016</b244>`	UUID
`</priceidentifier>`
`<x462>02</x462>`	Including tax
`<j261>05</j261>`	Price to consumers
`<!-- details of consumer price inc-tax -->`
`</price>`
`<price>`
`<priceidentifier>`
`<x506>01</x506>`
`<b233>PRH PTUID</b233>`
`<b244>3e304b73-50f6-432d-8e82-2865198dad73</b244>`
`</priceidentifier>`
`<x462>01</x462>`	Excluding tax
`<j261>06</j261>`	Institutional price
`<!-- details of institutional price exc-tax -->`
`</price>`

In addition to the different Price qualifiers on the two prices above, one is quoted inc-tax, the other exc-tax. This is quite usual, for example in European VAT jurisdictions, where consumer sales are priced including tax, and business-to-business sales are typically priced exclusive of tax.

In general, the Price type code identifies the business model or terms of sale on offer, and Price type qualifier limits the applicability of the price to specific customers:

Price type values from List 58
Trade sales (normal reseller terms)	exc-tax ⁵	inc-tax ⁵
Recommended retail price (RRP)	01	02
Fixed retail price	03	04
Wholesale price ⁴	05	07
Alternative wholesale price ¹ ⁴	08	09
Freight-pass-through RRP ²	31	–
Freight-pass-through billing price ²	32	–

Pre-publication trade sales (reseller terms), where post-publication prices will differ	exc-tax	inc-tax
Pre-publication recommended retail price ³	21	22
Pre-publication fixed retail price ³	23	24
Pre-publication wholesale price ³ ⁴	25	27

Trade sales (agency terms)	exc-tax	inc-tax
Publisher’s retail price	41	42

Special sales (generally non-returnable, often retailer-specific) ⁶	exc-tax	inc-tax
Recommended retail price	11	12
Fixed retail price	13	14
Wholesale price ⁴	15	17

Price type qualifiers from List 59
Unqualified price (applies when no other qualified price applies) ⁷	00
Member/subscriber price	01
Export price (not recommended – use <Territory> instead)	02
Reduced price when purchased as part of a collection	03
Voucher/coupon promotion price	04
Consumer price	05
Library/corporate/institutional price	06
Reservation order	07
Promotional offer (temporary ‘special offer’ price reduction) ⁶	08
Library only price	10
Education only price	11
Corporate only price	12

¹ used where two wholesale prices are required for different customer categories
² US-only
³ use where reduced prices are applicable for orders placed pre-publication (‘subscription orders’)
⁴ if accompanied by discount information, eg based on ordering a minimum number of copies, this is treated as a discount below the wholesale price
⁵ choice between inc- and exc-tax prices is market- and sometimes sector-specific. Supply one or other, not both
⁶ it is a common error to confuse ‘special sales’ where the terms and conditions vary from the norm, and ‘special offers’ where the price is lowered for a temporary promotional period
⁷ use as necessary as the complement of any price qualifiers that have no obvious complement (for example, to qualify a non-member price, or a price without a coupon). But omit if there is no price other than the ‘normal’ unqualified price

P.26.46 Unit of pricing

The <PricePer> element is normally omitted, as it has a default value that indicates the price refers to a single copy of the product.

This means that where the product is a quantity pack, filled dumpbin or other product that contains multiple items intended to be separated and retailed individually, the price is the price of the multi-pack, not the price of each of the individual retail products. The price of each individual retail item is usually detailed in a separate product record. The product record of the multi-pack should describe only the multi-pack, and should use <ProductPart> to list the identifiers (for example, the ISBN) of the individual retail items.

Price condition composite

The <PriceCondition> composite is primarily used to indicate rental prices – time-limited licenses – for e-publications. Prices without Price conditions are purchase prices (or perpetual licenses). It is also used to indicate ‘linked prices’, where the price is dependent on ownership or purchase of another product.

With purchases and rentals of e-publications, the ‘product’ sold is in fact a license. Purchases are ‘perpetual licenses’, where the term (duration) of the license is unlimited. Rentals are ‘time-limited licenses’. Some publishers take the view that different rental durations are different licenses, and thus require different product identifiers. In this case, a complete Product record is required for each license variation, and the duration of the rental may be specified in <EpubUsageConstraints> (see Group P.3). No <PriceCondition> is necessary.

Alternatively, a single product – one single product identifier, and thus one single Product record – may be available both as a purchase (a perpetual license) and for one or more rental durations (a range of time-limited license options), and so there may be a lengthy list of prices for the same product, where the only difference is the length of time that the product is licensed for. There are two common models:

the price for each rental period is a simple percentage of the retail price, so for example 30% of retail for a 3-day rental, 50% for a one week rental, 70% for one month and so on. The exact percentages may be set by the retailer, or may be subject to a broad agreement between publisher and retailer – but they are set ‘globally’, not on a product by product basis. This needs no particular treatment in ONIX, though the final prices can be confirmed or communicated to a third party as below);
the price for each rental period is managed individually by the publisher, and needs to be communicated to the retailer on a product-by-product basis. In this case, the price for each possible rental duration may be carried in a single repeat of the <Price> composite within an overall Product record.

However, these methods do not provide a unique product identifier or SKU against which to report rental revenues in a granular fashion – if a unique product identifier is required, for example to ensure that revenues can be reported separately for each rental duration (without any changes to existing reporting and applications), then a complete ONIX Product record per rental duration is required. The alternative – which does require changes in reporting – it to make use of a proprietary <PriceIdentifier> within the <Price> composite.

The intention of <PriceCondition> is to support a product catalog like this, where each price can be managed individually by the data supplier. Note that the ‘3-day rental’ option is not a fixed proportion of the ‘buy’ price:

Product 1	ISBN 1	buy as PDF	£17.95
		rent for 3 days	£5.95
		rent for one week	£8.95
		rent for one month	£11.95
		extend rental from 3 days to one week	£4.95
		extend rental from one week to one month	£3.95
		convert one month rental to purchase	£6.95
Product 2	ISBN 2	buy as EPUB	£19.95
		rent for 3 days	£9.95
		rent for one week	£12.95
		rent for one month	£15.95
		extend rental from 3 days to one week	£3.95
		extend rental from one week to one month	£4.95
		convert one month rental to purchase	£7.95

This two-product catalog with various purchase and rental options would require two Product records, each with (at least) seven repeats of <Price>. Further repeats of <Price> could be used to specify other rental periods, further extension and conversion options, rental prices in other currencies for other territories etc. Within a single <Price>, the <PriceCondition> composite specifies the rental duration the price applies to, and for rental extension and conversion options, <PriceCondition> specifies the prior rental requirements.

<PriceCondition> also supports linked prices. For linked prices, the ‘other’ product – on which validity of this price depends – can be identified with <ProductIdentifier>. This composite should follow the best practices set out in Group P.2.

If there are multiple conditions placed on a price (eg for this linked price, you must own or purchase two other products), each condition should be listed in a separate repeat of <PriceCondition>. If one of multiple conditions must be met (eg for this linked price, you must own or purchase either one of two other products), these should be treated as two separate prices, each with a single simple condition, in two repeats of <Price>.

specifying perpetual license (purchase) and time-limited license (rental) prices
using Reference names
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>00</PriceConditionType>`
`</PriceCondition>`
`<PriceAmount>27.95</PriceAmount>`
`<CurrencyCode>EUR</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>AT BE CY EE FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC SM VA ME</CountriesIncluded>`
`</Territory>`
`</Price>`
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>10</PriceConditionType>`
`<PriceConditionQuantity>`
`<PriceConditionQuantityType>01</PriceConditionQuantityType>`
`<Quantity>3</Quantity>`
`<QuantityUnit>07</QuantityUnit>`
`</PriceConditionQuantity>`
`</PriceCondition>`
`<PriceAmount>9.95</PriceAmount>`
`<CurrencyCode>EUR</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>BE DE LU NL</CountriesIncluded>`
`</Territory>`
`</Price>`
`<!-- further repeats of <Price> can specify other rental periods -->`

using Short tags
`<price>`	Price with no conditions – a purchase or ‘perpetual license’
`<x462>01</x462>`	Exc-tax price
`<pricecondition>`
`<x463>00</x463>`	No conditions
`</pricecondition>`
`<j151>27.95</j151>`
`<j152>EUR</j152>`
`<territory>`
`<x449>AT BE CY EE FI FR DE ES GR IE IT LU MT NL PT SI SK AD MC SM VA ME</x449>`	Valid in 17 Euro-using EU countries and five other European countries which use the Euro
`</territory>`
`</price>`
`<price>`	Price With time-limitation – a rental
`<x462>01</x462>`
`<pricecondition>`
`<x463>10</x463>`	Rental time limit
`<priceconditionquantity>`
`<x464>01</x464>`	3 days
`<x320>3</x320>`
`<x466>07</x466>`
`</priceconditionquantity>`
`</pricecondition>`
`<j151>9.95</j151>`
`<j152>EUR</j152>`
`<territory>`
`<x449>BE DE LU NL</x449>`	Note the rental price is valid in Benelux and Germany only (the supplier may not rent out the product in the other countries)
`</territory>`
`</price>`
`<!-- further repeats of <price> can specify other rental periods -->`

specifying rental, rental extension, rental to purchase upgrade and purchase prices
using Reference names
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>10</PriceConditionType>`
`<PriceConditionQuantity>`
`<PriceConditionQuantityType>01</PriceConditionQuantityType>`
`<Quantity>3</Quantity>`
`<QuantityUnit>09</QuantityUnit>`
`</PriceConditionQuantity>`
`</PriceCondition>`
`<PriceAmount>19.95</PriceAmount>`
`<CurrencyCode>USD</CurrencyCode>`
`<!-- Territory omitted for brevity -->`
`</Price>`
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>10</PriceConditionType>`
`<PriceConditionQuantity>`
`<PriceConditionQuantityType>01</PriceConditionQuantityType>`
`<Quantity>12</Quantity>`
`<QuantityUnit>09</QuantityUnit>`
`</PriceConditionQuantity>`
`</PriceCondition>`
`<PriceAmount>34.95</PriceAmount>`
`<CurrencyCode>USD</CurrencyCode>`
`</Price>`
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>10</PriceConditionType>`
`<PriceConditionQuantity>`
`<PriceConditionQuantityType>01</PriceConditionQuantityType>`
`<Quantity>12</Quantity>`
`<QuantityUnit>09</QuantityUnit>`
`</PriceConditionQuantity>`
`</PriceCondition>`
`<PriceCondition>`
`<PriceConditionType>12</PriceConditionType>`
`<PriceConditionQuantity>`
`<PriceConditionQuantityType>01</PriceConditionQuantityType>`
`<Quantity>3</Quantity>`
`<QuantityUnit>09</QuantityUnit>`
`</PriceConditionQuantity>`
`</PriceCondition>`
`<PriceAmount>19.95</PriceAmount>`
`<CurrencyCode>USD</CurrencyCode>`
`</Price>`
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>11</PriceConditionType>`
`<PriceConditionQuantity>`
`<PriceConditionQuantityType>01</PriceConditionQuantityType>`
`<Quantity>3</Quantity>`
`<QuantityUnit>09</QuantityUnit>`
`</PriceConditionQuantity>`
`</PriceCondition>`
`<PriceAmount>34.95</PriceAmount>`
`<CurrencyCode>USD</CurrencyCode>`
`</Price>`
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>11</PriceConditionType>`
`<PriceConditionQuantity>`
`<PriceConditionQuantityType>01</PriceConditionQuantityType>`
`<Quantity>12</Quantity>`
`<QuantityUnit>09</QuantityUnit>`
`</PriceConditionQuantity>`
`</PriceCondition>`
`<PriceAmount>19.95</PriceAmount>`
`<CurrencyCode>USD</CurrencyCode>`
`</Price>`
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>00</PriceConditionType>`
`</PriceCondition>`
`<PriceAmount>49.95</PriceAmount>`
`<CurrencyCode>USD</CurrencyCode>`
`</Price>`

using Short tags
`<price>`	Rental
`<x462>01</x462>`	Exc-tax price
`<pricecondition>`
`<x463>10</x463>`	Rental time limit
`<priceconditionquantity>`
`<x464>01</x464>`
`<x320>3</x320>`	Three months
`<x466>09</x466>`
`</priceconditionquantity>`
`</pricecondition>`
`<j151>19.95</j151>`
`<j152>USD</j152>`
`<!-- territory omitted for brevity -->`
`</price>`
`<price>`	Rental
`<x462>01</x462>`	Exc-tax price
`<pricecondition>`
`<x463>10</x463>`	Rental time limit
`<priceconditionquantity>`
`<x464>01</x464>`
`<x320>12</x320>`	Twelve months
`<x466>09</x466>`
`</priceconditionquantity>`
`</pricecondition>`
`<j151>34.95</j151>`
`<j152>USD</j152>`
`</price>`
`<price>`	Rental extension, upgrade from three to twelve months
`<x462>01</x462>`
`<pricecondition>`
`<x463>10</x463>`	Rental time limit
`<priceconditionquantity>`
`<x464>01</x464>`
`<x320>12</x320>`	Twelve months
`<x466>09</x466>`
`</priceconditionquantity>`
`</pricecondition>`
`<pricecondition>`
`<x463>12</x463>`	As upgrade from
`<priceconditionquantity>`
`<x464>01</x464>`
`<x320>3</x320>`	Three months
`<x466>09</x466>`
`</priceconditionquantity>`
`</pricecondition>`
`<j151>19.95</j151>`
`<j152>USD</j152>`
`</price>`
`<price>`	Rental to purchase conversion, upgrade from three months rental to perpetual license
`<x462>01</x462>`
`<pricecondition>`
`<x463>11</x463>`	Rental to purchase, as upgrade from
`<priceconditionquantity>`
`<x464>01</x464>`
`<x320>3</x320>`	Three months
`<x466>09</x466>`
`</priceconditionquantity>`
`</pricecondition>`
`<j151>34.95</j151>`
`<j152>USD</j152>`
`</price>`
`<price>`	Rental to purchase conversion, upgrade from twelve months rental to perpetual license
`<x462>01</x462>`
`<pricecondition>`
`<x463>11</x463>`	Rental to purchase, as upgrade from
`<priceconditionquantity>`
`<x464>01</x464>`
`<x320>12</x320>`	Twelve months
`<x466>09</x466>`
`</priceconditionquantity>`
`</pricecondition>`
`<j151>19.95</j151>`
`<j152>USD</j152>`
`</price>`
`<price>`	No conditions – purchase
`<x462>01</x462>`	Exc-tax price
`<pricecondition>`
`<x463>00</x463>`	No conditions
`</pricecondition>`
`<j151>49.95</j151>`
`<j152>USD</j152>`
`</price>`

The above lists six prices arranged so that an outright purchase is $50, renting for one period of three or twelve months then converting to a purchase totals $55, and renting, extending the rental, then converting to a purchase totals $60.

For rental extensions, <PriceConditionType> code 10 is used to specify the new total duration of the rental, not the duration of the extension (ie extension from 3 to 12 months means the extended rental expires 12 months after the original 3 month rental began, not 15 months).

specifying a linked price (price of an e-book is dependent on purchase or ownership of the equivalent print book)
using Reference names
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>00</PriceConditionType>`
`</PriceCondition>`
`<PriceAmount>7.95</PriceAmount>`
`<CurrencyCode>CAD</CurrencyCode>`
`<!-- Territory omitted for brevity -->`
`</Price>`
`<Price>`
`<PriceType>01</PriceType>`
`<PriceCondition>`
`<PriceConditionType>05</PriceConditionType>`
`<ProductIdentifier>`
`<ProductIDType>03</ProductIDType>`
`<IDValue>9780007120765</IDValue>`
`</ProductIdentifier>`
`<ProductIdentifier>`
`<ProductIDType>15</ProductIDType>`
`<IDValue>9780007120765</IDValue>`
`</ProductIdentifier>`
`</PriceCondition>`
`<PriceAmount>2.95</PriceAmount>`
`<CurrencyCode>CAD</CurrencyCode>`
`<!-- Territory omitted for brevity -->`
`</Price>`

using Short tags
`<price>`	normal price
`<x462>01</x462>`	Ex-tax
`<pricecondition>`
`<x463>00</x463>`	No conditions
`</pricecondition>`
`<j151>7.95</j151>`
`<j152>CAD</j152>`
`<!-- territory omitted for brevity -->`
`</price>`
`<price>`	linked price
`<x462>01</x462>`	Ex-tax
`<pricecondition>`
`<x463>05</x463>`	Price conditional on prior purchase or ownership of…
`<productidentifier>`
`<b221>03</b221>`	GTIN-13
`<b244>9780007120765</b244>`
`</productidentifier>`
`<productidentifier>`
`<b221>15</b221>`	And ISBN
`<b244>9780007120765</b244>`	of linked product
`</productidentifier>`
`</pricecondition>`
`<j151>2.95</j151>`
`<j152>CAD</j152>`
`<!-- territory omitted for brevity -->`
`</price>`

Where some prices within a <SupplyDetail> composite include price conditions, it is good practice to include <PriceCondition> on every price, using <PriceConditionType> 00 from List 167 where necessary to provide positive indication that there are no conditions.

Discount code and Discount composites

The physical book supply chain in some countries is unusual in that products are supplied from distributors and wholesalers to retailers based on a discount from a fixed or recommended retail price, rather than the more common explicit wholesale price to which retailers add their markup. <PriceType> allows prices of either type to be quoted.

In cases where business-to-business prices are based on retail price minus a discount, it is common for publishers, distributors and wholesalers to specify discounts given against the retail price in a coded manner rather than as explicit percentages. This is either because discount terms vary from customer to customer (ie from retailer to retailer), as well as from product to product, or because they are commercially sensitive for some other reason. So if on Product A, retailer X gets a 37.5% discount and retailer Y gets 41%, this can be communicated in a single ONIX message without tailoring each message to a specific retailer, and without revealing commercially-sensitive discounts to other retailers. The publisher, distributor or wholesaler establishes a set of ‘discount groups’ and allocates each product to a group. Each retailer then uses a private, retailer-specific lookup table to relate the discount group for the product to the actual discount percentage they would receive. So Product A might be in Discount Group 3, and according to their individual lookup tables, retailer X receives 37% discount on all products in Group 3 and retailer Y receives 41%. Rather than changing the Discount Group relating to each product, it is the lookup table that is the subject of negotiation between the supplier and retailer.

Where such a scheme is operated, the Discount Code (termed a ‘Discount Group number’ in the example above) should be included for all products supplied on normal business-to-business terms, within a <DiscountCoded> composite. Typically, the <DiscountCodeType> within the composite is 02 from List 100 (a proprietary code), and the actual Discount Code (‘3’ in the example described above) is specified in <DiscountCode>. In common with all proprietary codes and code lists, a distinctive name for the code scheme should be included in <DiscountCodeTypeName>.

In some countries, a consistent naming scheme for Discount Codes is maintained by a central agency – for example by BIC in the UK: these schemes have their own entries in List 100 and do not need a <DiscountCodeTypeName>.

supplying a proprietary discount code
using Reference names
`<DiscountCoded>`
`<DiscountCodeType>02</DiscountCodeType>`
`<DiscountCodeTypeName>Acorn Press DG</DiscountCodeTypeName>`
`<DiscountCode>DG31</DiscountCode>`
`</DiscountCoded>`

using Short tags
`<discountcoded>`
`<j363>02</j363>`	Proprietary discount code scheme
`<j378>Acorn Press DG</j378>`	Distinctive name for code scheme
`<j364>DG31</j364>`	Individual retailers can work out what ‘DC31’ means in percentage terms
`</discountcoded>`

Where discounts are not commercially sensitive, and do not vary from retailer to retailer – or where an ONIX message is exchanged solely in the context of a specific trading relationship – they can be expressed as plain percentages, and should be carried in a <Discount> composite instead, within the simple <DiscountPercent> data element. Repeated <Discount> composites can also be used to specify rising discounts based on order quantities.

rising discount based on order quantity
using Reference names
`<Discount>`
`<DiscountPercent>36.5</DiscountPercent>`
`</Discount>`
`<Discount>`
`<Quantity>10</Quantity>`
`<DiscountPercent>41</DiscountPercent>`
`</Discount>`

using Short tags
`<discount>`
`<j267>36.5</j267>`	No minimum order for 36.5% discount
`</discount>`
`<discount>`
`<x320>10</x320>`
`<j267>41</j267>`	Additional 4.5% for orders of 10 copies or more
`</discount>`

For products – particularly in the e-book supply chain – that are traded under the Agency model (ie where the <PriceType> is 41 or 42), the <Discount> composite should be interpreted as the ‘commission composite’. A percentage specified in <DiscountPercent> indicates the commission that the agent earns for the sale. This percentage is usually fixed, but might vary from product to product. If the commission (on a particular product) varies between agents or is commercially sensitive for any other reason, the <DiscountCoded> composite may be used to specify the commission indirectly (using Discount code type 05 or 06).

Of course, if the price quoted in the enclosing <Price> composite is a wholesale price (a business-to-business price, <PriceType> codes 05, 07, etc) rather than one based on a retail price less a discount, then neither <DiscountCoded> nor <Discount> would normally be included at all. However, wholesale prices may sometimes be accompanied by additional discounts for volume purchases (ie by a <Discount> composite containing a <Quantity> data element as well as the percentage).

P.26.61 Price status

A product announced in an ONIX record several months before publication might go through the following stages prior to publication:

product announced, <UnpricedItemType> code 02 (price to be announced), no <Price> composite
price announced, <PriceStatus> code 01 (provisional)
price announced, <PriceStatus> code 02 (firm)

: Firm here does not imply ‘firm-sale’ (as contrasted with ‘sale or return’), but suggests that orders placed at that price will be honored, even if the price is revised prior to fulfillment of the order. Orders placed against a provisional price may be subject to price changes. Firm sales (in the sense of ‘not sale or return’) should be indicated using a Special Sales Price type.

P.26.62 Price amount

A price should be included for all products except those that are explicitly unpriced or free of charge (so a zero price should never be used). The price can be supplied either as an amount in a specified currency using <PriceAmount> or, in exceptional circumstances, as a price tier or code using <PriceCoded> (and again, a currency should be specified, unless the coding scheme makes it explicit that a tier relates to multiple prices in different currencies). The tier/code option should only be used when the product is retailer or at least retail platform-specific, and is only relevant when that retailer or platform sets a fixed set of price tiers for the products in its store. Each <Price> composite should contain only one price.

It is best practice to always provide the Price amount as a real number with the conventional number of explicit decimal digits, even when the digits are trailing zeros – so a price should typically be given as 3.00, not 3 or 3.0. Prices and other real numbers in ONIX must always use the period character ‘.’ as the decimal separator, not a comma or mid-dot, though recipients may display prices using the conventional decimal separator for the locale (for example, a price of 7.95 in the ONIX data, with a period, would be displayed as ‘€7,95’ in France, with a comma). And for very large numbers, there should be no ‘thousands separator’ in the ONIX data, even though the price might be displayed with a group separator (ie a price of 1275.00 with currency code MXN in the ONIX would be displayed as ‘$1,275.00’ in Mexico, with Peso symbol, a comma as the group separator and a period as the decimal separator).

: List 96 indicates the conventional number of decimal places for each currency, taken from ISO 4217 and the Unicode Common Locale Data Repository. For most currencies, convention suggests two decimal places (eg 100 cents = 1 US Dollar). A handful of currencies use three decimal places (eg 1000 fils = 1 Jordanian Dinar), and List 96 indicates this using ‘(3)’. About 50 currencies are conventionally quoted as integers without any decimal places (eg Japanese Yen, Korean Won). For these currencies, either there are no subunits, or the previous subunits (eg the sen and jeon for the Yen and Won) are no longer in practical use, and this is indicated using ‘(0)’. However, while it is best practice to quote prices with the conventional number of decimal places, it is not an error – merely poor practice – to omit trailing zeros.

Price coded composite

This composite is used only for supplying prices which are specified as tiers in a price list, rather than as absolute amounts. Some tiering systems use a single tier that translates into multiple prices in various currencies (so Tier 7 could mean $6.95, €4.95 and £4.45), and others use independent tiers for each currency or work in only a single currency. In either case, the currency is implicit within the tier definition, so <PriceCoded> should be used without <Tax>, <CurrencyCode> and usually without <Territory>. In contrast, <PriceCoded> does not prelude the use of <PriceDate> (eg to notify future changes in tier), <Discount> or <DiscountCoded> (for business-to-business discounts or agency commission rates), or other type- and status-related elements (eg <PriceType>, <PriceCondition> and <PriceStatus>).

Normal use would include a <PriceCodeTypeName> as the tier structure and the relationship of each tier to an actual price amount would most likely be unique to a particular retailer (for example, the Apple iBooks store).

Tax composite

For Price types that include tax (ie <PriceType> codes 02, 04, 07, 42 etc from List 58), a <Tax> composite should be included, to detail the tax included in the price. Note that where tax details are supplied, they are specific to a single country or tax jurisdiction, so the <Territory> composite should also be included to specify the geographical validity of the specific price and tax combination. Separate repeats of the <Price> composite should be used for areas of the market that have different taxes.

See the notes on inc-tax and exc-tax Price types in P.26.43.

The <Tax> composite should not be used with exc-tax Price types (ie <PriceType> codes 01, 03, 05, 41…), though of course additional business-to-business taxes may apply, and sales taxes may be applied by the retailer ‘at the cash register’ – the exc-tax Price type simply indicates that these taxes are not included in the specified price.

Although every element is optional, it is best practice to supply all elements of the <Tax> composite, so the recipient can choose which elements to use or display.

The composite is limited to specifying a single tax rate. Where a multi-item product is subject to tax at more than one rate, then multiple repeats of the composite should be used.

part of multi-item product taxed at zero rate, part at standard rate
using Reference names
`<Price>`
`<PriceType>02</PriceType>`
`. . .`
`<PriceAmount>9.95</PriceAmount>`
`<Tax>`
`<TaxType>01</TaxType>`
`<TaxRateCode>S</TaxRateCode>`
`<TaxRatePercent>20</TaxRatePercent>`
`<TaxableAmount>5.85</TaxableAmount>`
`<TaxAmount>1.17</TaxAmount>`
`</Tax>`
`<Tax>`
`<TaxType>01</TaxType>`
`<TaxRateCode>Z</TaxRateCode>`
`<TaxRatePercent>0</TaxRatePercent>`
`<TaxableAmount>2.93</TaxableAmount>`
`<TaxAmount>0.00</TaxAmount>`
`</Tax>`
`<CurrencyCode>GBP</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>GB</CountriesIncluded>`
`</Territory>`
`<PrintedOnProduct>01</PrintedOnProduct>`
`</Price>`

using Short tags
`<price>`
`<x462>02</x462>`	Inc-tax price
`. . .`
`<j151>9.95</j151>`	RRP 9.95
`<tax>`
`<x470>01</x470>`	VAT
`<x471>S</x471>`	Standard rate
`<x472>20</x472>`	Percent (note not 0.20)
`<x473>5.85</x473>`	Ex-VAT price (of this portion)
`<x474>1.17</x474>`	VAT (on this portion)
`</tax>`
`<tax>`
`<x470>01</x470>`	VAT
`<x471>Z</x471>`	Zero rate
`<x472>0</x472>`	Percent
`<x473>2.93</x473>`	Ex-VAT price (of this portion)
`<x474>0.00</x474>`	VAT (on this portion)
`</tax>`
`<j152>GBP</j152>`	UK £
`<territory>`
`<x449>GB</x449>`	Price valid in UK only
`</territory>`
`<x301>01</x301>`	Not printed on product
`</price>`

Ex-VAT price is £8.78 (ie 5.85 + 2.93). Two-thirds of the value of the product (ie £5.85) is taxable at standard 20% UK VAT rate, resulting in tax of £1.17. One third (ie £2.93) is zero-rated (taxable, but with a rate of zero percent), resulting in tax of £0.00. Total inc-VAT price is £9.95 (ie £5.85 + £1.17 + £2.93 + £0.00)

Note that when a product is wholly zero-rated for VAT, an inc-tax Price type should still be used, the <TaxableAmount> is equal to the <PriceAmount> and the <TaxAmount> is zero).

part of multi-item product taxed at reduced rate, part at standard rate
using Reference names
`<Price>`
`<PriceType>02</PriceType>`
`. . .`
`<PriceAmount>9.95</PriceAmount>`
`<Tax>`
`<TaxType>01</TaxType>`
`<TaxRateCode>S</TaxRateCode>`
`<TaxRatePercent>19</TaxRatePercent>`
`<TaxableAmount>6.20</TaxableAmount>`
`<TaxAmount>1.18</TaxAmount>`
`</Tax>`
`<Tax>`
`<TaxType>01</TaxType>`
`<TaxRateCode>R</TaxRateCode>`
`<TaxRatePercent>7</TaxRatePercent>`
`<TaxableAmount>2.40</TaxableAmount>`
`<TaxAmount>0.17</TaxAmount>`
`</Tax>`
`<CurrencyCode>EUR</CurrencyCode>`
`<Territory>`
`<CountriesIncluded>DE</CountriesIncluded>`
`</Territory>`
`<PrintedOnProduct>02</PrintedOnProduct>`
`<PositionOnProduct>11</PositionOnProduct>`
`</Price>`

using Short tags
`<price>`
`<x462>02</x462>`	Inc-tax price
`. . .`
`<j151>9.95</j151>`	RRP 9.95
`<tax>`
`<x470>01</x470>`	VAT
`<x471>S</x471>`	Standard rated
`<x472>19</x472>`	Percent
`<x473>6.20</x473>`	Ex-VAT price (of this portion)
`<x474>1.18</x474>`	VAT (on this portion)
`</tax>`
`<tax>`
`<x470>01</x470>`	VAT
`<x471>R</x471>`	Reduced rate
`<x472>7</x472>`	Percent
`<x473>2.40</x473>`	Ex-VAT price (of this portion)
`<x474>0.17</x474>`	VAT (on this portion)
`</tax>`
`<j152>EUR</j152>`	Euro
`<territory>`
`<x449>DE</x449>`	Price valid in Germany only
`</territory>`
`<x301>02</x301>`	Printed on product
`<x313>11</x313>`	On removable outer wrap
`</price>`

The recommended retail price is €9.95, made up of two portions. The first portion is €6.20 plus 19% VAT and the second portion is €2.40 plus 7% VAT. Total tax is €1.35 (€1.18 plus €0.17)

In principle, where only an exc-tax price is supplied, the tax that should be applied in a particular tax regime could be indicated by the <ProductClassification> (see Group P.3). Partly-taxable products can be dealt with using different commodity codes and using the <Percent> data element within <ProductClassification> to indicate what proportion of the overall exc-tax price is represented by each commodity code.

It is good practice to ensure that money amounts are rounded to an appropriate precision, and not presented as a real number with more than 2 (or perhaps 3) decimal places.

P.26.71 Currency code

All prices should include a specific <CurrencyCode> data element. It is best practice to avoid providing a default for currency in the message header.

: One special case – prices quoted using <PriceCoded> which specify a price tier should omit <CurrencyCode>, and any default currency provided in the message header should also be ignored.

Territory composite

The <Territory> composite is essentially identical to that in Group P.24, and similar best practices apply. <Territory> in P.24 describes the geographical extent of the market, whereas in P.26, it describes the geographical validity of a particular price within that market. Where a tax-inclusive price (<PriceType>, 02, 04, 07, 42 etc) is specified, <Territory> also specifies the geographical applicability of the tax.

Note that there is no requirement that currency and territory be aligned: prices for export territories are often set in the currency of the country where the supplier is based, or in some widely traded currency, rather than in the currency of the country into which the product is being sold, and a price in a particular currency need not apply in all countries using that currency.

: Because the supra-national region ECZ (the Eurozone) may be used in <RegionsIncluded> and <RegionsExcluded> within Group P.26, the allowed combinations of <CountriesIncluded>, <RegionsIncluded>, <CountriesExcluded> and <RegionsExcluded> are more complex than those in Block 4 or Group P.24. However, use of the ECZ region is strongly discouraged – use <CountriesIncluded> with ‘AT BE CY EE FI FR DE ES GR IE IT LU LV MT NL PT SI SK’ (the 18 Eurozone countries), plus possibly ‘AD MC SM VA ME’ (other non-EU countries in continental Europe using the Euro as their official currency) in preference.

Typically, the market that the supplier operates within spans multiple countries. A supplier may choose a single price, in a single currency, for supplies to all those countries. Or they may set different prices, in multiple currencies, specifically for each country in the market. Clearly, no price should appear to be valid outside the market – that is, the <Territory> for a price should always be a subset of (or the same as) the <Territory> for the market, just as the market <Territory> should be a subset of (or the same as) the territory covered by Sales rights types 01 and 02. However, not all suppliers are necessarily willing supply to all countries within the market, and thus, the various prices listed for that supplier may not cover all the countries in the market. A price without a <Territory> composite must be interpreted as applying throughout the market, but if the territories attached to various prices do not add up to cover the whole market, it simply means that the supplier does not supply to the remaining countries within the market. Other suppliers operating within the same market may list prices for those remaining countries.

Price date composite

The function of the price date composite is to provide limits on the validity of a price. For example, it enables planned future prices to be notified to data aggregators, wholesalers and retailers in advance.

Dates should specified as the last date on which a current price will be effective, or the first date on which a future price will be effective. Current prices do not need a start date, and planned future prices do not need an end date. The end date for the current price should be the day immediately prior to the start date of the future price, and neither need necessarily be a business day. An end date should not be provided without an indication of the subsequent price (ie a start date for another price), except as an indication that orders for the product will not be accepted after that date.

Closed-end price promotions (temporary reductions in price) should be specified through provision of either two or three prices – the current price (with an end date, if three prices are specified), the temporary price (with both start and end dates), and optionally the price the product will revert to at the end of the promotion (with a start date). An example of the three price method is shown below, and the two price method is shown at the beginning of Group P.26. So why use one rather than the other?

the two price method is more concise, and is generally preferred. The <PriceQualifier> code 08 specifies the special price is temporary, and that it will revert to the ‘normal’ price at the end of the promotion;
the three price method (which does not need to use price qualifiers) allows the post-offer price to be different from the pre-offer price.

closed-end price promotion, 8th–22nd May (three price method)
using Reference names
`<Price>`
`<PriceType>05</PriceType>`
`. . .`
`<PriceAmount>7.99</PriceAmount>`
`. . .`
`<PriceDate>`
`<PriceDateRole>15</PriceDateRole>`
`<Date dateformat="00">20110507</Date>`
`</PriceDate>`
`. . .`
`</Price>`
`<Price>`
`<PriceType>05</PriceType>`
`. . .`
`<PriceAmount>5.99</PriceAmount>`
`. . .`
`<PriceDate>`
`<PriceDateRole>14</PriceDateRole>`
`<Date dateformat="00">20110508</Date>`
`</PriceDate>`
`<PriceDate>`
`<PriceDateRole>15</PriceDateRole>`
`<Date dateformat="00">20110522</Date>`
`</PriceDate>`
`. . .`
`</Price>`
`<Price>`
`<PriceType>05</PriceType>`
`. . .`
`<PriceAmount>7.99</PriceAmount>`
`. . .`
`<PriceDate>`
`<PriceDateRole>14</PriceDateRole>`
`<Date dateformat="00">20110523</Date>`
`</PriceDate>`
`. . .`
`</Price>`

using Short tags, using shortened From … until date format
`<price>`
`<x462>05</x462>`	Wholesale price type
`. . .`
`<j151>7.99</j151>`	Normal price
`. . .`
`<pricedate>`
`<x476>15</x476>`	Until
`<b306 dateformat="00">20110507</b306>`	7th May
`</pricedate>`
`. . .`
`</price>`
`<price>`
`<x462>05</x462>`
`. . .`
`<j151>5.99</j151>`	Promotional price
`. . .`
`<pricedate>`
`<x476>24</x476>`	From … until
`<b306 dateformat="06">2011050820110522</b306>`	8th–22nd May
`</pricedate>`
`. . .`
`</price>`
`<price>`
`<x462>05</x462>`
`. . .`
`<j151>7.99</j151>`	Normal price
`. . .`
`<pricedate>`
`<x476>14</x476>`	From
`<b306 dateformat="00">20110523</b306>`	23rd May
`</pricedate>`
`. . .`
`</price>`

For a single-day promotion, the start and end dates for the promotional price are the same date.

Dates are inclusive. That is, the end date for one price should be the day before the start date of the next price. In the absence of time and timezone information, it should be assumed that price changes happen outside business hours between the two dates specified, or at midnight, at the location of the supplier. However, if the exact timing of the price change is critical, precise time and timezone information can be supplied using dateformat code 13.

P.26.86, P.26.87 Price on product

It is helpful for retailers to know in advance whether a price is printed on the product itself, particularly since trade practice on this varies greatly, and the retailer may need to plan in advance for stickering physical stock. It is good practice to supply this information where it is available, via <PrintedOnProduct> (and possibly also the <PositionOnProduct> data element).

Note that for multi-item trade-packs, <PrintedOnProduct> indicates whether the multi-item product is priced – it implies nothing about the inner product that is sold at retail.

Reissue composite

A ‘reissue’ occurs when a publisher makes an existing product available (again) with revised collateral material, a redesigned cover etc, but without significant changes to the content of the product and without any change in the product identifiers. This might occur regularly with perennial backlist products where the product receives a regular ‘refresh’ or ‘relaunch’. The old and new versions are not available concurrently (since that would require them to be treated as two separate products, with separate identifiers), and there may or may not be an intervening period during which neither version of the product is available.

The issue that faces metadata suppliers and recipients is to achieve an orderly switchover from using the old collateral material to using the new, revised material – and timing this switchover so that a consumer ordering the product on the basis of seeing, say, a cover image on a retailer’s website, gets the product bound with the cover they expect.

The intent of the <Reissue> composite is – or was – to provide a way for suppliers to deliver information about a planned reissue of an existing product. However, all information that might be carried in the composite can also be carried in other, more appropriate parts of the message, and use of the <Reissue> composite is deprecated. For convenience, best practices associated with reissues are described here, and these recommended practices avoid the <Reissue> composite altogether.

Reissues can be actioned at either a ‘global’ or market level. However, since reissues mostly involve updating of descriptive text and supporting resources specified in Block 2 of an ONIX Product record – and all Block 2 metadata applies to the product globally – there is no support within these best practices for reissues that happen in only one market (where another market may continue to be supplied with older versions of the same product). In this regard, the use of the <Reissue> composite may have been advantageous, but the significant simplification gained by avoiding it is felt to be worthwhile.

There are two distinct reissue scenarios. The first is when there is a period preceding the reissue when the product is unavailable. The second is when availability of the older version continues right up to the reissue, and availability is essentially uninterrupted.

If there is a distinct gap between last availability of the ‘old’ version and introduction of the reissued version of the product, then the treatment in ONIX is relatively simple: replacement of the metadata and resources describing the old version of the product with revised metadata and resources while the product is out of stock:

the Publishing status in Group P.20 or Market publishing status in Group P.25 remains Active throughout (ie <PublishingStatus> or <MarketPublishingStatus> code 04 from List 64 or List 68), because there is no time during the reissue process when orders for the product cannot be placed;
at the point of announcement of the planned reissue, add the date of the next reissue in <PublishingDate> in Group P.20, with <PublishingDateRole> code 21 from List 163 (or the equivalent in <MarketDate> in Group P.25);
- after the reissue, that date becomes the Last reissue date, code 16;
in Group P.26, <ProductAvailability> should change from In stock (code 21 from List 65) to Out of stock (code 31) when the old version runs out, to Awaiting reissue (code 33) when the reissue is announced, to In stock again when the new stock becomes available;
- there may not be an intervening period when Out of stock is used, if the reissue is announced immediately the old version going out of stock;
- Awaiting reissue should be accompanied by an Expected ship date indicating when reissued copies will ship from the supplier (use <SupplyDateRole> with code 08 from List 166). Just as the Expected ship date for a new product is likely to be a few days prior to a nominal publication date, the expected ship date for a reissue is likely to be a few days prior to the nominal reissue date;
collateral material such as a revised cover image or updated descriptive text for new version can be included as normal in Block 2 as soon as the reissue is announced (or when stock of the old version is exhausted), since the old collateral no longer has any value;
- where the collateral material must be downloaded by the retailer (eg when it is a supporting resource such as a cover image), include a <ContentDate> composite with <ContentDateRole> code 17 from List 155 to indicate the resource has been updated. This indicates the data recipient should re-download the resource and replace the old version with the updated version, even if the file name or URI for the resource is unchanged;
for the avoidance of any doubt, put a note indicating ‘pending reissue’ in <PublishingStatusNote> or <MarketPublishingStatusNote>, and remove it when the reissue is complete.

If there is no significant gap between availability of the ‘old’ version and introduction of the reissued version of the product, then in all probability the publisher and retailer will not wish to publicize the upcoming reissue in advance (since to do so might inhibit final sales of the old version and leave excess stock). So the aim is to announce the reissue to the supply chain a little in advance and supply revised metadata and supporting resources (eg a new cover image) in the ONIX data feed, allowing the recipient ample time for any necessary processing. At the same time, the aim is to inhibit the use of revised metadata and resources in consumer-facing contexts until the planned date of reissue. The sequence of metadata changes is slightly different:

the Publishing status in Group P.20 or Market publishing status in Group P.25 remains Active throughout (ie <PublishingStatus> or <MarketPublishingStatus> code 04 from List 64 or List 68);
at the point of announcement of the planned reissue, add the date of the next reissue in <PublishingDate> in Group P.20, with <PublishingDateRole> code 21 from List 163 (or the equivalent in <MarketDate> in Group P.25);
- after the reissue, that date becomes the Last reissue date, code 16;
in Group P.26, <ProductAvailability> remains as In stock (code 21 from List 65) throughout (though the nature of that stock is changed at some point);
collateral material such as any revised descriptive text or supporting resources for the new version should be included in Block 2 along with a date controlling the introduction of the new collateral material (and replacement of the old);
- temporarily, the new collateral should be included in parallel with the old;
- use the <ContentDate> composite with <ContentDateRole> code 14 from List 155 to specify the first date on which the reissue can be publicized with the new collateral material;
- use <ContentDate> composite with <ContentDateRole> code 15 to specify the last date on which the previous material may be used. Do not simply remove the old material from the data feed as its status would remain unclear – remove it only after the last date on which it is valid;
- these dates might indicate ‘immediately’, but are more likely to indicate ‘continue using the old material until the date of the reissue, then switch to the replacement material’.

Appendix

Glossary

A0, A4 etc: See A series paper sizes.
AA: Author’s alterations, corrections made on proofs by the author or publisher. cf printer’s errors or literals, which are errors made by the typesetter.
AAC: Advanced Audio Coding. Improved codec for audio files to reduce file size or download time. Used to compress audio files in the iTunes store, but not unique to Apple. AAC compression generally sacrifices a little less quality than MP3 compression.
AACR2: Anglo-American Cataloging Rules, second edition, widely used English language library cataloging rules. cf RDA. See also MARC21, the primary format in which library catalog metadata is transmitted (and often stored).
Abstract: Short summary of the contents of (for example) an academic paper, article or chapter. Journal publishers often provide free online access to abstracts, while access to the full text remains dependent upon subscription.
Abstract model: Generalized conceptual model of a real-world system, developed as a guide or aid to understanding the principles of that system. Often expressed as a series of generic entities (‘things’ – books, people, places, dates and so on), the potential relationships between them, and perhaps the events that may change those entities and relationships. See <indecs>, FRBR.
Accessibility: A book can be accessible by print-impaired people (eg blind, partially sighted or dyslexic readers, or readers with a physical disability). For e-books, accessibility is not a special edition or feature, but a best practice for mainstream editions. For print books, special accessible editions are often required. Accessibility is also a consideration for the remainder of the supply chain, including retailer websites and e-reading devices.
Accessible edition: Large print, Braille or specially-formatted audiobook that can be used by print-impaired people who cannot use a conventional physical book.
Accession number: A unique identifier added to each item acquired by a library or archive. The accession number is a proprietary item identifier, and two items with the same ISBN (ie two instances of the same manifestation) would have distinct accession numbers.
Adhesive binding: Typical paperback (‘limp’) book binding using hot-melt adhesive applied to the roughened or notched spine of the book block to hold the pages or signatures and cover together. Also termed ‘Perfect binding’.
Adobe RGB: Extended RGB colorspace, allowing a much wider range of colors on screen than standard sRGB.
Adoption: Decision by a school or college, or by a consortium or educational authority, that a specific textbook will be included on a reading list or used to teach a course of study.
Advance: Sum paid by a publisher to an author (or other contributor) prior to publication. Often paid in parts, upon acquisition (agreement of the publishing contract), upon delivery of manuscript, and upon publication. The advance is paid against future royalty earnings, so the author does not receive any further royalty payments from the publisher until the advance has been ‘earned out’ (or ‘recouped’).; See ARC.
A format: UK term for a paperback around 178 × 111mm in size, roughly equivalent to a US mass-market paperback. See also B format.
Agency model: Business model based on the idea that a publisher sells to the consumer and is wholly responsible for setting the price. The retailer acts as an intermediary or agent to facilitate the sale and takes a fixed commission from the publisher; cf the more common wholesale or reseller model. Under the agency model, the publisher can directly control the ‘street price’ or Actual selling price of a book, whereas under the reseller model, street prices are usually at the discretion of the retailer – the retailer can even choose to sell the book at a loss to attract footfall – unless the legal framework provides for Fixed rather than Recommended retail prices. Reseller models where retail prices are not fixed thus encourage retailers to compete on price (possibly to the exclusion of other areas such as customer service) and put great pressure on margins. However, agency models are more complex for the publisher, and may be viewed as anti-competitive.
A&I: Abstracting and indexing. cf AI.
Airside edition: Book only for sale in bookshops in the duty-free (or ‘airside’) area of an airport (cf ‘groundside’). Occasionally, special editions are produced specifically for airside retail outlets (though they are not editions in the proper sense used for P.9 Edition).
AIS, AI: Advance Information Sheet, also called a Title sheet, a printed page of metadata about a book produced in advance of publication for sales and marketing purposes, including details of the title, author, ISBN, pub date, format, price, a description of the contents and marketing information. In effect, an ONIX Product record can be the equivalent of an AIS or title sheet.
Answer code: Distributor or wholesaler’s response to an order or stock enquiry. In ONIX, codes in List 65 (used in the <ProductAvailability> date element) are equivalent to answer codes.
A&P: Advertising and promotion, often the major concern of the marketing department. Not to be confused with P&A, price and availability.
API: Application programming interface, set of protocols, functions or services that one piece of software offers to another, used to share data between applications on a computer or between computer systems on a network.
ARC: Advance Reading Copy (pl often just Advances), sometimes also known as a Review copy: early finished copies of a book, usually arriving before publication and used for publicity purposes, reviews, and occasionally for evaluation (eg for potential adoption) and approvals etc. Book proofs (which are bound but usually editorially unfinished) are also sometimes used in the same way.
ASCII: American Standard Code for Information Interchange. Simple character set comprising 0–9, A–Z and a–z, plus a few basic symbols and punctuation characters. An ‘Ascii’ text file is one that contains plain text (‘words and spaces’) using only characters from this set. There’s no control over fonts, no formatting or styling (eg different point sizes, justification, bold or italic), and no accented characters, specialized symbols or fancy punctuation – ASCII does not even allow for proper curly quotation marks “ and ” or currency symbols like £ and €. cf Latin‑1, Windows‑1252, Unicode.
A series: ISO standard cut sheet paper sizes, used almost everywhere except North America. A0 is 841 × 1189 mm – 1 square metre in area, with sides in the ratio of 1:√2. A1 is half that area (but the same shape), A2 is half again, and so on. 2A0 is twice the area of A0. RA and SRA raw paper sizes are roughly 5% or 15% larger in area than A series sizes, to allow for bleed and final trimming, so SRA4 is 225 × 320 mm, where A4 is 210 × 297 mm. B series sheets are intermediate between the A series sizes (B1 is between A0 and A1).
ASIN: Amazon Standard Identification Number, a proprietary identifier for products used internally within Amazon.
ASP: See RRP.
Aspect ratio: Ratio of height to width of an image, screen etc. See portrait, landscape.
Assistive technology: Software and devices such as text-to-speech (TTS) screen readers or Braille displays that make books more accessible to print-impaired readers.
Asterisk: Typographical mark, a small star (‘ * ’), used in text to indicate the presence of an annotation, as a list item marker (instead of a • symbol), to indicate multiplication (instead of the proper × symbol), etc.
Asterism: Typographical mark, usually of three stars or asterisks (‘ ⁂ ’) but often approximated by a row of three spaced asterisks, indicating a break in the flow of text.
Attribute: In XML documents such as an ONIX message, text, numeric or other data contained within an opening markup tag (eg the dateformat attribute within <Date>). XML attributes usually carry information about how to interpret a data element. More generally, can be synonymous with ‘property’, ‘characteristic’ or ‘data element’.
Authentication: Verification of the identity of a person, product or process. cf Authorization.
Authority file: In library cataloging and bibliographic data, a central list of, for example, contributor names. Used to ensure that contributors can be identified unambiguously and to highlight the single preferred form of a name that might have various forms or spellings. Any particular name may appear in different forms on different books, eg with or without Dr., with ü, ue or u, yet the shared contributor number from the authority file would make it clear that the two names identify the same contributor. Authority files also help differentiate different contributors who share a name, and optionally can be used to resolve the real people behind pseudonyms. See also ISNI. More generally, an authority file forms a type of controlled vocabulary.
Authorization: Verification of the permissions associated with a person or process, for example to access or change some information. cf Authentication, on which authorization depends.
AVC: Advanced Video Coding, a format for compressed video data, also termed H.264. Has superseded earlier and less technically sophisticated video compression schemes such as H.261, H.263, and is likely to be replaced by H.265.
B2B: Business-to-business – commercial transactions between businesses, such as between a wholesaler and a retailer, or between a publisher and a wholesaler. cf B2C.
B2C: Business-to-consumer – commercial transactions between a business and an end user (usually but not always an individual consumer). cf B2B.
Backlist: Backlist products are those that have been on sale for (typically) a year or more and are still available. In contrast, Frontlist titles are conventionally those less than a year old (and usually including forthcoming publications).
Back matter: Pages following the main content of a book, including appendices, endnotes, bibliography, index, other notes and possibly any advertising and blank pages. Back matter is also termed End matter and occasionally ‘postlims’. cf front matter.
Backorders: See dues.
Back-to-back: Two books in one, bound back-to-back, with the text of one upside down so that it reads from the ‘back’ of the book. The two share a single spine. Sometimes termed a ‘turn-around book’, ‘tête-bêche’ or a ‘flip book’ (but cf Flick book). cf Dos-à-dos binding, where two books are bound back to back without turning one upside down, so the foredge of one meets the spine of the other.
Bandwidth: In data communications, the amount of data that can be carried over a particular channel, usually measured in bits per second (or megabits per second – Mbit/s or Mbps). Transmitting a 10 megabyte file over a 1Mbit/s link should take around 80–100 seconds.
Barcode: Machine-readable data printed as a series of black and white stripes on a product or on packaging. A conventional ‘Bookland’ barcode on a book uses the EAN-13 barcode symbology and has the ISBN printed above the stripes, with the equivalent GTIN-13 at the bottom. The stripes represent the GTIN-13, not the ISBN (though for modern books, the two are the same number). Other types of barcode (different ‘symbologies’, with differing sizes and arrangements of bars) can appear on products, on cartons containing multiple products, on pallets, shipping labels etc, for example GTIN-12 (formerly known as UPC-A barcodes, but obsolete in the book trade since 2005), GTIN-14 and GS1-128 (SSCC barcodes). Barcode readers mostly use red light, so printing barcodes in color requires care to preserve adequate contrast.
Basis weight: See paper weight.
Berne Convention: International copyright agreement concluded between various European countries in 1886, since revised and extended to most countries.
B format: UK term for a paperback around 197 × 130mm in size, roughly equivalent to a US trade paperback. See also A format.
BIC: Book Industry Communication, a UK-based trade organization.; In the ONIX and metadata context, the subject categorisation scheme developed by BIC and used mostly in the UK, though close variants of the BIC scheme are used in some other European countries, for example CCE (Classificazione commerciale editoriale) in Italy. cf BISAC, CLIL, WGS, see also Thema. Schemes like BIC, BISAC, CLIL, WGS and Thema are intended for use in the book trade, and have little in common with library-focused subject classification or categorisation schemes like Dewey Decimal, UDC or LCSH (Library of Congress Subject Headings).
BISAC: A subject categorisation scheme developed originally by BISAC (Book Industry Systems Advisory Committee), now administered by BISG and used mostly in North America. In the past, BISAC has also been known as BASIC. cf BIC, see also Thema.
BISG: US-based trade organization Book Industry Study Group.
Bit: In computing, a binary digit – a single unit of information, either 0 or 1. Eight bits are usually combined into a byte. A byte of data might represent a single decimal number between 0 and 255, or a single text character (eg in the Latin‑1 character set), or a particular brightness for a pixel in an image (eg brightness of red in an RGB image). This document comprises around 2.5 megabytes (million bytes) of data.
Blad: Sample pages of a book, produced in the form of a booklet for promotional purposes.
Block update: See Organization of data delivery.
Blurb: Short descriptive text usually written by the publisher and used to promote the book. The blurb may be used in a catalogue or on the back cover or jacket flaps of the book, and may include short quotations from favourable reviews or endorsements.
Board: Stiff card used for the rigid covers of a hardback, or for the leaves of a ‘board book’. Generally more than 200gsm and 250µm (or 10 mils) in bulk.
Book block: Part-bound book, with all the signatures gathered, bound and trimmed, but before the cover is added.
Book proof: Paginated and bound proof copy, usually without the final cover and with text that still requires final corrections. Used for marketing and (sometimes) review purposes, as well as final proofreading and correction. See also advance reading copy, page proof.
Bound proof: See book proof, advance reading copy.
Brackets, braces, parentheses: Paired typographic symbols – brackets ‘[ … ]’, braces ‘{ … }’, parentheses ‘( … )’. In text, brackets are often used to surround sections of quotations that are not verbatim. and parentheses for subsidiary phrases or clarification. Parentheses are often called ‘round brackets’ in UK.
Bulk: Thickness of a sheet of paper, usually measured in microns (µm, thousandths of a millimetre). Typical book paper is around 90–120µm. In the US, often termed Caliper, and measured in mils (thousandths of an inch). See also paper weight. Strictly, the relationship between a paper‘s weight and bulk is the density (mass per unit volume), and higher quality papers generally have higher density, but confusingly, a paper’s ‘density’ is often used as a synonym of the paper’s weight or grammage (ie mass per unit area) without regard to bulk or caliper.
Byte: See bit.
Byte order mark: In the UTF‑16 encoding of Unicode characters, each character is represented by two or more bytes of information. But these bytes might be in either order – something like saying either ‘seventy three’ or ‘three and seventy’. A special character, a byte order mark, may be included as the first character in a Unicode file to make it clear which way around the rest of the file is. However, the strong recommendation in ONIX is to omit byte order marks, and to declare either UTF‑16BE (‘big endian’, like seventy three) or UTF‑16LE (‘little endian’, like three and seventy) explicitly in the first line of the XML file. A byte order mark is valid in UTF‑8 too, but it has no real meaning, and again should be omitted.
Caliper: See bulk.
Cancel: Removal and replacement of a page from a book, or the reprinted sheets for replacing cancelled pages.
Cardinality: In XML, data modelling and database design, whether a data element or composite is optional or mandatory, and whether nor not it is repeatable, within a particular DTD or schema. In the ONIX documentation, a cardinality of 0…1 means the element is optional, 1 means mandatory, 0…n means optional and repeatable, and 1…n means mandatory and repeatable. Cardinality is often a simplification of the full requirements of a schema or data model, since the requirements can be contextual – they depend on other data values. In ONIX, <ROWSalesRightsType> is 0…1 (ie optional), but in many circumstances is actually mandatory (it is dependent on the data provided in various <SalesRights> composites). Such contextual requirements cannot be expressed in the XML DTD or schema.
Case-bound: Book bound with rigid board covers – a hardback. Not to be confused with a slip-case, a separate board ‘sleeve’ the book slides into. cf limp-bound, a paperback.
Cast off: Calculation of the likely number of typeset pages from the number of characters or words in text and the page and type size.
CC: See Creative Commons.
CCE: See BIC.
CDF: Consumer direct fulfillment, see Drop shipment.
CE: In dates, Common Era of the Gregorian calendar, secular equivalent to AD (anno domini). cf BCE, Before Common Era.; In product certification, the CE logo on a product is a declaration by the manufacturer that indicates it conforms to European Union legislation and directives, for example on product and materials safety. In font names, CE usually indicates the font includes a repertoire of characters suitable for Central European languages such as Polish or Czech.
C format: Less common UK term for a paperback in a size more typically used for trade hardbacks – sometimes around 216 × 135mm in size (Demy), but equally often 234 × 153mm (Royal) or another size. More typically just termed a trade paperback.
Chapbook: Originally a small book or pamphlet of popular, sensational, juvenile, moral or educational content once sold by street merchants or peddlers known as ‘chapmen’. In modern use, may be almost any short booklet, often a children’s book. Occasionally (and probably wrongly) termed a ‘chapter book’.
Character encoding: See character set.
Character entity: Method of encoding non-ASCII characters in HTML, for example ‘…’ for an ellipsis, now largely unnecessary with widespread use of Unicode characters. While character entities were used with earlier versions of ONIX, they are not valid in ONIX 3.0.
Character set: A defined list or repertoire of characters. A Character encoding then defines how this repertoire is represented by a computer. For example, ASCII lists a repertoire of 95 printable characters including space – plus a selection of non-printable ‘control characters’ including tab, newline and so on – and encodes them using the numbers 0–127 (or 00000000 to 01111111 in binary). Latin‑1 lists 191 characters, and encodes them using the numbers 0–255. Windows‑1252 is a different encoding of around 215 characters also using the numbers 0–255 – and obviously this means that if some text is encoded using Windows‑1252 and then displayed as if it were Latin‑1, some characters will be displayed wrongly or not at all. See also Unicode, a character set of more than 100,000 characters.
Check digit: Many identifiers include a numerical check digit, calculated arithmetically from the other digits. For an ISBN, for example, calculating what the check digit should be based on the first twelve digits, then comparing it with the actual check digit indicates whether the ISBN is likely to be correct, or whether an error has been introduced. Different identifiers use different mathematical procedures (or ‘algorithms’) for calculating the check digit.
Chigago Manual of Style: Widely used guide for spelling, punctuation, grammar and typographic style in American English, derived orginally from guidelines set by Chicago University Press. cf Hart’s Rules.
CIE: Commission Internationale de l’Eclairage, the body responsible for colorimetry standards, against which colorspaces such as Adobe RGB or sRGB are characterised.
CIP: Cataloguing in Publication, limited bibliographic information produced by national libraries prior to publication of a book, based on information supplied in advance by publishers. The CIP information is often printed within the book itself on the title verso page.
CIP4: International Cooperation for the Integration of Processes in Prepress, Press, and Postpress Organization, a standards organization focusing on process automation and improved workflow in the print industry. CIP4’s key technical standard is JDF (Job Definition Format), an XML messaging system used in print production.
CLIL: Commission de Liaison Interprofessionnelle du Livre, a French book trade organization.; In the context of ONIX and metadata, Classification CLIL is the subject classification developed by the Commission and used widely in the French book trade. See also Thema.
Cloth book: See rag book.
CMYK: Cyan, magenta, yellow, key (or black), basic subtractive color model used to simulate (at least in theory) the full range (or gamut) of visible colors in color printing with four colored inks (and halftoning). In practice the range of printable colors is more limited than the full visible range. See also RGB, halftone.
Codec: Coder–decoder. Loosely, the compressed file format used to store a files containing image, audio or video data. Since such files can often be very large, the data is compressed mathematically. JPEG is a lossy format for image data, whereas TIFF is lossless. AAC and MP3 are two different lossy formats for audio data. These are referred to as ‘different codecs’. More strictly, the codec is the software used to compress or decompress the data in a particular format.
Codelist: Term used in ONIX documentation for a controlled vocabulary or authority file. In addition, codelists define a language-independent notation – the code – for each term or concept in the vocabulary. Only the code appears in ONIX data. Some codelists have an implied hierarchy (for example list 150, where BA is clearly a broader term than BB or BC), making some lists taxonomies rather than simple vocabularies. See also SKOS, keyword.
Co-edition: See co-publication.
Collation: Process of sorting, the sort order or proedure used, or the process of checking items have been sorted correctly.
Collection: Fixed or indefinite number of products that share some collective identify such as a collective title. Members of the collection also have other attributes in common, such as product form or a branding or design style. A set or a series is a collection, but a collection could also comprise a less formal selection of products.
Colophon: Logo of publisher or imprint on the spine or title page of a book.; A statement about production details such as typeface, paper grade and binding printed on the title verso or at the end of the book.
Color gamut: The range of colors available within a particular colorspace (for example, within sRGB) or on a particular display or printed page (see CMYK), often measured against the full range of visible colors (or ‘chromaticities’) as defined by the CIE.
Composite: Informal term used in ONIX documentation to refer to an XML markup structure that contains (only) other data elements, eg the <ProductIdentifier> composite contains three data elements, <ProductIDType>, <IDTypeName>, and <IDValue>.
Compression: Data compression is the mathematical process of reducing the size of a file, for example by eliminating repetition and redundancy. Different compression methods are either lossy or lossless. Lossless compressed files can be expanded back to reconstitute the exact original data, but lossy compression – often used with image, video or audio files – discards less important sounds or image detail to make the compressed file even smaller, so the re-expanded file is only approximately the same as the original. In practice, the difference may be invisble or inaudible, but lossy compression is obviously unsuitable for use with text or numerical data. AAC and MP3 are lossy audio codecs, JPEG is a lossy image codec and AVC is a lossy video codec. TIFF is a lossless image file format, WAV is lossless audio, and Zip losslessly compresses any file. See also codec.
Consignment: See sale or return.
Contributor: Person or organization responsible for creating the intellectual or artistic content of the product. Generally, ONIX is concerned only with contributors named on the product itself. The publisher acquires rights to exploit the intellectual or artistic content created by the contributor, in return for fees or a royalty.
Controlled vocabulary: An exhausive list of terms that can be used in a particular context or data element. Each term in the vocabulary should have an unambiguous definition or explanation, and may include both preferred terms and less-preferred synonyms. Controlled vocabularies may be a ‘flat’ list of terms, or the terms may be arranged hierarchically – in which case the vocabulary is sometimes called a taxonomy. See also codelist, authority file.
Co-op: Co-operative marketing, arrangement whereby the publisher subsidises or pays for advertising and promotional activities (A&P) carried out by a retailer.
Co-publication: When two publishers co-operate to publish a book, they may create and sell a single product (a co-publication), or may create a shared ‘base’ from which two different products are derived and sold (these are Co-editions). A co-publication may carry the branding for both publishers, and may even carry two separate ISBNs (one from each publisher), but it is a single product. In contrast, co-editions have separate identities (including separate ISBNs for each publisher’s version), even though they might differ by no more that the branding and the publisher details. Often, the shared base for a co-edition may consist only of the color images, to which each publisher adds entirely separate text – this type of co-edition is very common in multi-language illustrated books, as it offers significant savings in shared production costs.
Copyleft: A play on conventional copyright: a licensing arrangement whereby a work (most often computer software) may be copied, used, re-distributed, adapted or modified, free of any restrictions, on condition that anything derived from it is bound by the same conditions. Some Creative Commons licenses are copyleft licenses.
Copyright: The exclusive rights to perform, display, reproduce, sell, modify, adapt or otherwise use original work or other intellectual property that is expressed in text, images, sound – a right enshrined in the Universal Copyright Convention (the ‘Berne Convention’, originally agreed in 1886 but revised several times since). The copyright in a work is held by the author or creator, and can subsequently be passed on (eg to the author’s estate), or licensed or assigned to publishers (and others) in a contract. In most jurisdictions, copyright (which is essentially a commercial right) is accompanied by inalienable Moral rights such as the right to be identified as the author, and protection for the integrity of the work. Unlike a patent or a trademark, copyright is automatic – you don’t need to register it to gain legal protection, though in some countries, registration can be beneficial. Copyright in a textual work persists for up to 70 years after the death of the original creator, and limits exploitation of the work by those other than the copyright holder, licensees or assignees (collectively, rightsholders). After expiry of the rights, the work passes into the public domain. Certain groups, eg print-impaired readers, may hold a legal copyright exception and can make copies for personal use without obtaining permission from the rightsholders. Other uses of copyright material may also be allowed without explicit permission (eg for purposes of education, research, parody, for review and criticism, for digital backups etc) under ‘fair use’ or ‘fair dealing’ provisions of national law, but the scope and detail of these exceptions vary from country to country.
Copyright exception: See copyright.
Copyright page: Also termed the Imprint page. In a printed book, the title verso on which the copyright notice, publisher and imprint details, the ISBN and impression number, CIP and other details about the publication of the book usually appear. In a e-publication, this is often added at the end of the book.
Creative Commons: Organisation that develops copyright licenses that permit and encourage free sharing of creative works. Some CC licenses are copyleft (in particular the SA ‘Sharealike’ variants), others reserve some rights to the creator or, like the CC0 (‘CC Zero’) waiver, waive all possible rights (including the right to place sublicensing restrictions on derived works). See also Open Access.
CSS: Cascading Style Sheets, W3C standard for markup used alongside HTML to control the appearance of web pages (where the HTML markup largely defines the structure).
DAD: Digital Asset Distributor, organisation that facilitates distribution of digital assets such as e-books to online retailers and libraries on behalf of the publisher. The service may encompass a managed asset repository, file format conversion services, metadata and e-book distribution, and aggregation of sales statistics.
Dagger: Typographic symbol ‘ † ’ sometimes used to indicate footnotes in text. Also comes in double dagger (‘ ‡ ’) flavor.
DAISY Consortium: Digital Accessible Information System, a consortium of organisations working to promote ‘inclusive publishing’ and the availability of accessible editions of books to all, including print-disabled readers. See also DTB, EPUB.
Dashes: Common typographic dashes come in different lenghs, -, – and —. Hyphens (the shortest) are used to connect compound words or split words at the end of a line in justified text. En dashes (the middle size) can be used for parenthetical phrases – usually like this, with spacing – or unspaced to indicate a range such as A–Z or 1–9. Em-dashes are used for parenthetical phrases—usually like this, without spacing—or to indicate an abrupt halt or discontinuity in a sentence. In some languages and typographic styles, em dashes or a slightly longer ‘quotation dash’ are commonly used for dialogue, in place of opening quotation marks. And in maths, the subtraction sign ‘−’ is about the size of an en dash, but is often matched to the widths of the digits.
Data element: In XML documents such as an ONIX message, text, numeric or other data contained between a pair of markup tags. Sometimes loosely termed a ‘data field’. cf attribute, composite.
‘Day and date’: Movie industry term for simultaneous release of linked media properties, as when releasing a tie-in book carefully timed to publish on the same day as the film opens in cinemas. Such released are usually embargoed to prevent early sales from bookshops. cf windowing.
DC: Distribution centre, a distributor or wholesaler’s warehouse.; In metadata contexts, see Dublin core.
DDC: Dewey Decimal Classification, common subject classification system used in libraries, named for its creator Melville Dewey. See also UDC, LCC.
Deckle edge: Page edges of a book block left rough and untrimmed, or more likely, carefully trimmed to make them look rough and untrimmed. Also termed a Rough front.
Delimiter: Character or character sequence used in data files to separate one discrete data element from the next. CSV files use commas as delimiters. XML uses angle brackets (< and >) as separators between data and markup. Within a few ONIX data elements such as <CountriesIncluded>, a space is used as a delimiter in a list of country codes. There is a clear problem whenever a delimiter character occurs within the data itself – this is why XML data must use < to represent the < symbol within the data.
Delta update: See Organization of data delivery.
Demy, Demi: Common hardback book size in the UK, typically around 216 × 135mm. Pronounced as in ‘deny’. See also Royal, trade paperback.
Deprecate: Deprecated data elements or codes are not recommended for use, and in general are strongly discouraged. In most cases, another element or code is recommended instead. Deprecation implies obsolescence, but the element or code does remain technically valid.
Derived work: See work.
Dewey: See DDC.
Dieresis: Diacritic mark indicating (in English pronunciation) a vowel that is pronounced separately – for example in ‘naïve’. The same ‘two dots’ symbol is more commonly used in Germanic languages for an umlaut, which has a different effect on pronunciation, for example ,schon / schön‘. The effect an umlaut has on alphabetic sorting varies by country.
Discount (retailer discount, trade discount): In some countries, books have established wholesale or business-to-business prices. In others, business-to-business transactions are based on a discount from the fixed or recommended retail price. The discount given by a distributor or wholesaler varies from retailer to retailer (bigger retailers sometimes get more discount) and from book to book (discounts are often greater on mass market fiction than on specialist non-fiction). Assuming the books are sold at their normal retail price, the trade discount represents the retailer’s gross margin (revenue minus cost of goods sold). See also reseller model.; Discount can also refer to books sold at retail for less than their recommended retail price (which reduces the retailer’s margin).
Distributor: Organization that holds the primary stock of books and is responsible for fulfillment (of trade orders) in a particular territory or market on behalf of the publisher. Wholesalers and retailers may act as intermediaries between the distributor and the end customer. Many large publishers own or operate their own distributor, and hold stocks themselves. Other publishers appoint a single, exclusive distributor per market or territory (and this exclusive distributor is sometimes termed the Vendor of record). Some publishers prefer to appoint multiple non-exclusive distributors.
DNS: See IP address.
DocBook: XML markup for structured book texts and documentation. The text of the book contains markup that divides it up into parts, chapters, paragraphs, tables, lists, footnotes and so on. The markup is structural and semantic, rather than defining the typographic presentation or page layout, and the DocBook data can be processed automatically to create e-books, large print, conventional print, synthetic audio versions of the book.
DOI: Digital Object Identifier – a digital identifier for a document or other object, generally one accessible via the Internet. Objects with DOIs can be the target of clickable links in other documents (eg a scholarly article may cite another article via its DOI), or the link may provide information about the object. In contrast to the superficially similar URL link, DOIs are managed (by the owner of the target object) so that third-party links to the object do not break when the target document is moved. In contrast with many other identifiers, DOIs are always associated with some kind of domain-specific service, and are actionable (clickable) to gain access to that service. The most common application of DOIs in publishing is CrossRef’s registration and resolution service for online scholarly material, which provides citation services, but DOIs are also used within the DataCite service for citation of and access to research datasets, and the Entertainment Identifier Registry (EIDR) identifier scheme for movie and TV assets.
DPI: Dots per inch, the number of data points or pixels per inch of resolution in an image. Note that the DPI of an image is variable – if the image is displayed at twice the size, the DPI halves. To print an image as a halftone, the DPI of the image should ideally be twice the halftone LPI (so 350dpi at the size the image will be printed for a 175lpi halftone screen. More pixels are unnecessry, fewer means a lower-quality halftone).
DRM: ‘Digital Rights Management’ usually refers to technical protection measures (eg content encryption systems and other access control technologies, and also watermarking) that are used to enforce or monitor compliance with constraints on usage of digital content within e-publications. DRM can for example limit copying and redistribution of the digital content, printing, cutting and pasting of text, sharing and lending, and can also place a time limit on the use of the content to enable rentals. DRM seeks to protect intellectual property from copyright infringement, but can also (often inadvertently) prevent usages that are specifically allowed by copyright exceptions.
Drop shipment: Also termed Consumer direct fulfillment (CDF). In order to avoid retailers holding stock, while at the same time minimising fulfillment time, distributors and wholesalers sometimes ‘drop ship’ goods direct to the retail customer. The retailer placing the order must pass the customer delivery address to the wholesaler or distributor. This is most common with POD copies of books.
DST: See DTO.
DTB: Digital Talking Book, standard specification for an e-book format accessible to blind or otherwise print-impaired readers (and also for the associated reading systems). Developed by the DAISY Consortium, and therefore also known as the DAISY standard (versions 2 and 3). Content of a DTB can range from text with XML markup (to be read using text-to-speech software), through combined text plus pre-recorded audio, to audio-only files with additional navigation functionality. DTB has been largely superseded by the EPUB 3 standard, which incorporates many features to make EPUB content more accessible.
DTD: Document Type Definition. Specifies the set of markup tags and the structure – in terms of mandatory and optional markup tags, their order and nesting – that may be used in a particular type of XML or SGML. document. So the ONIX for Books DTD defines how tags like <Contributor> or <x448> may be used. See also schema.
DTO: Download To Own, also termed DST, EST, Digital or Electronic Sell-Through. Business model whereby e-book files or other digital goods are downloaded with a perpetual license. cf DTR, rental.
DTR: Download To Rent. Business model whereby e-book files are downloaded with a time-limited license. See also rental. cf DTO.
Dublin Core: Set of key metadata elements (including Title, Creator, Publisher, Date and so on) intended to standardize bibliographic description and facilitate access to documents and resources on the internet. There were originally (in 1998) just 15 elements in the Dublin Core Metadata Element Set (DCMES), with a further 40 terms (DCTerms) added later, but the imprecision of the term definitions and lack of a common data exchange format mean DC is used either very loosely, or with application-specific ‘profiles’ that prevent broad interoperability.
Dues, Backorders: Business-to-business orders taken by a publisher, distributor or wholesaler prior to publication or during a temporary period of unavailability (when they are more frequently termed backorders), for delivery when the book becomes available. Subscription orders are recorded as dues. cf pre-orders, which are consumer orders placed with a retailer.
Dummy: Usually handmade mock-up of a book, folded together or bound from unprinted pages to demonstrate the physical nature of a planned product.
Dumpbin: Temporary, free-standing decorative box, usually of cardboard, produced by the publisher to display copies of books in a retail environment. See POS.
EAN: See GTIN.
EDI: Electronic Document Interchange: system for highly-automated exchange of strictly-formatted business documents such as invoices, orders or P&A updates. Common document formatting standards include X.12 (used in North America), Tradacoms (in UK) and EDIFACT (the underlying ISO 9735 standard, common across much of the rest of the world). These are not XML-based standards, but XML equivalents do exist under the EDItX banner.
EDItEUR: Not-for-profit membership-supported organization that develops and maintains, inter alia, the ONIX and EDItX families of message standards and the Thema subject categorisation scheme. EDItEUR also manages the International ISBN Agency, and provides a limited secretariat service to the International ISTC and ISNI agencies.
Edition: See P.9 Edition. Historically and in book collecting, ‘edition’ carries the same meaning as impression (eg a limited edition, or a ‘first edition’ of Charles Darwin’s On the origin of species by means of natural selection), but in other contexts, does not imply that all copies are manufactured together, only that they are identical or very nearly so in content (ie there can be several impressions of a Third Edition in paperback, and a separate hardback of the same Third Edition). Significant revisions or changes to the content imply a new edition, and in <indecs> and ISTC terms, a new (derived) work. Other ONIX edition types specified in P.9 – facsimile, large print or Braille, for example – and loose terms such as airside edition used elsewhere are not classed as new works (though they are new manifestations).
Edge decoration: Colored, marbled or gilded edges of the book block.
EDItX: Family of XML-based ‘transactional’ e-commerce messages developed by EDItEUR, intended as replacements for common EDIFACT, X.12 and Tradacoms EDI trading messages. The family also includes sales/revenue report messages intended to simplify retail platform-to-publisher sales reporting of e-books.
EDUPUB: Standardized e-book file format aimed particularly at education material. EDUPUB is a specialized profile of EPUB 3.
EEA: European Economic Area, a free-trade area made up of the European Union countries plus three of the four EFTA countries, Iceland, Lichtenstein and Norway. The EEA agreement provides a ‘uniform internal market’ with freedom of movement for people, goods, services and capital, and great uniformity in regulations relating to trade, social policy, consumer protection, the environment and company law across 31 countries. In territorial rights contexts, ‘Europe’ often means the EEA – but at other times Europe implies the continent, which would additionally include Switzerland, the Balkans, Russia, Ukraine, Belarus and (possibly) Turkey and the trans-Caucasus (Georgia etc).
EFTA: European Free Trade Association, comprising Iceland, Lichtenstein, Norway and Switzerland (though several other countries were previously members and are now members of the European Union). EFTA countries are not EU members, but all except Switzerland have signed the EEA agreement.
Ellipsis: Typographic mark consisting of three dots ( ‘…’ ) indicating an omission, elision or continuation.
ELT: English language teaching.
Embargo date: See Publishing date composite in Group P.20.
Endband: Headband or tailband at top and bottom of a book spine – originally protective reinforcement of the binding of the book block, and thus implying a high-quality binding, but these days purely decorative.
End matter: See back matter.
End paper: Strong paper sheet used to affix the case of a hardback to the book block.
EPICS: EDItEUR Product Information Communication Standard – a data dictionary that inspired many of the data element definitions of ONIX.
EPOS: Electronic Point Of Sale, a retailer till or checkout system often also used for sales data and stock control.
EPUB: Standard e-book file format developed and maintained by the IDPF. The latest EPUB 3 version of the format builds on HTML5 and CSS, incorporates both reflowable and fixed-format variants, and includes features to help publishers optimize the accessibility of the content (obviating the need for specialized accessible editions). Note that ONIX has a number of data elements named <Epub… (for example <EpubTechnicalProtection>) which are intended for use with all types of e-publication. They are not exclusively for publications in the EPUB file format.
EST: See DTO.
Expression: See FRBR.
Extent: Page count, the number of pages in a book (or occasionally, the number of words or the running time). See Group P.11 for different methods of measuring the extent.
Faceted search: Technique for searching a collection of information based on applying multiple filters, successively refining the search results until the item is found. Faceted seaching is often used after an initial direct text search.
Fair use, fair dealing: Limited exceptions to copyright, for example allowing usage of short excerpts or quotations from a copyrighted work for particular purposes such as review, citicisism or private study without formal permission or payment. In some jurisdictions, the limits on fair use are clearly and legally defined. In others, it is defined in a more flexible and pragmatic way.
Field: See data element. May also refer to a column in a database table, or a pre-defined data entry area in a form.
Fingerprint: Procedure to capture the underlying characteristics of, for example, a chunk of audio or video, irrespective of how it is encoded as data: in contrast to a mathematical hash function, a song would have the same fingerprint when encoded as MP3 or AAC. Digital fingerprints are used to recognise similarity, where hashes are used to detect differences.
Firm sale: See sale or return.
First sale principle: Under US copyright law, retail book purchasers are allowed to sell, trade, rent, loan, or dispose of the item without the prior consent of the copyright holder. In other jurisdictions, some of the copyright holder’s rights are ‘exhausted’ at the time of first (retail) sale, to similar effect. However, first sale and exhaustion do not apply to e-books because they are licensed rather than sold, so libraries and consumers do not usually have the right to loan, rent or re-sell e-books without the publisher’s permission.
Fixed pricing: In certain countries, for example France or Germany, there are legal restrictions that prevent retailers selling books significantly below the recommended retail price.
Flash card: Small card bearing a letter, word, phrase, number or symbol, displayed quickly to learners to improve recognition skills and recall. Often used in teaching very basic literacy and numeracy.
Flick book: Book containing a sequence of illustrations on the pages, designed to give an animated effect when the pages are flicked through. Occasionally termed ‘flip book’, but not be confused with two-in-one volumes, two books bound together back-to-back.
Folio: Historical term for a page number, or for a single sheet of paper.
Folly: Cartographer’s folly, a fictitious feature inserted into a published map to help detect copyright violation and plagiarism. Fictitious entries in dictionaries, encyclopedias etc are occasionally called ‘mountweasels’. See also watermark.
Font: Set of characters of the same typeface and size, for example 18pt Helvetica or 10pt Garamond.
Foredge: Outer edge of a book page, opposite the bound edge or spine. Occasionally ‘fore-edge’.
Four-colour: See CMYK process color.
FRBR: IFLA’s Functional Requirements for Bibliographic Records is a conceptual model, the approximate library-centric equivalent of the <indecs> framework. The most significant contrast in terminology for ONIX implementors is that, while <indecs> and FRBR describe effectively identical manifestation and item or instance concepts, a work in <indecs>, ONIX and ISTC terms is roughly equivalent to an expression within the FRBR model.
Frontlist: See backlist.
Front matter: Pages preceding to the main content of a book, including title and imprint pages, tables of contents and of illustrations, and any foreword, preface and introduction text. Also termed Prelims (preliminary pages), and usually numbered with Roman numerals. cf Back matter.
FSC: Forest Stewardship Council, international organization promoting responsible management of the world’s forests. It provides accreditation and certification standards for forest management and forest products such as pulp and paper. See also PEFC, the somewhat similar Programme for the Endorsement of Forest Certification.
FTP: File Transfer Protocol, a standard method of transferring files across the internet. cf HTTP.
Full-bound: Binding in which the spine and covers are fully bound in cloth, leather or other material. cf Half-bound, Quarter-bound.
Full update: See Organization of data delivery.
Galley, galley proof: Unpaginated proof copy for checking and correction of the text. The text is in a single long column, without specific page breaks). cf page proof.
Genre: Books of a particular style, form or subject matter – for example romance, crime, science fiction.
GLN: Global Location Number, an international standard identifier for a physical trading location or (loosely) for an organization at that location. Well established within e-commerce and physical logistics, and not in any way specific to the publishing industry. cf SAN. Although the GLN system is administered by GS1, there is no central registry of GLNs, and a single location may have more than one GLN. Note that GLNs are 13-digit numbers, and must be distinguished from GTIN-13s by context.
Gloss: Short explanation, interpretation or annotation of an unfamiliar word or phrase, added between the lines of text (an ‘interlinear’ gloss), in the margin or in a separate glossary. See also ruby.
Glossary: Alphabetically arranged list of terms and their definitions or explanations, essentially a topic-specific dictionary. See also controlled vocabulary, taxonomy.
Governance: Policy, decision-making and oversight arrangements for a standard such as ONIX, or for an identifier registry like that operated by national ISBN agencies. Well-founded, inclusive and consistent governance engenders trust and builds credibility in the standard, allowing confident adoption and use of the standard by stakeholders.
Granularity: The extent to which metadata is divided into appropriate data fields – for example the way that a contributor name can be divided into <NamesBeforeKey>, <PrefixToKey>, <KeyNames> etc. Highly-granular metadata makes it easier to re-use the same metadata in different and possibly even unforseen ways.
GSM, grammage: Grams per square metre, see paper weight.
GS1: International standards organization responsible for a wide range of supply-chain standards, including the SSCC, GLN and GTIN identifier schemes.
GTIN: Global Trade Item Number, a numbering scheme for tradeable items in the supply chain administered by GS1. Common GTINs have 12, 13 and 14 digits. GTIN-12s were formerly known as UPCs (Uniform Product Codes), and are used almost exclusively used in North America. Their use on books has been deprecated since 2005. Thirteen digit ISBNs are a small subset of the GTIN-13 number scheme used to identify a wide range of retail items. GTIN-13s were formerly known as EANs (European Article Numbers). GTIN-14s are used to identify trade packs of items (from cartons to pallets).
GTIN-13: See GTIN.
GUID: Globally Unique Identifier. See UUID.
Guillemets: Arrow-shaped quotation marks ( « and » ) used in French.
Gutter: The portion of a bound page closest to the spine, the ‘back’ or ‘inside’ margin (cf the ‘outside’ margin nearest the foredge).
Gzip: See zip.
Half-bound: High-quality binding in which the spine and corners of the covers (only) are bound in leather (or other fine and durable material). cf Quarter-bound, Full-bound.
Halftone: Printing technique or the resulting printed image in which shades of grey (or for color images, shades or tints of the CMYK process colors) are simulated by small and regularly spaced ink dots of varying sizes – this is termed AM or ‘amplitude modulation’ screening. The regular spacing of the halftone dots is measured in lines per inch (LPI), or per centimetre. Occasionally, halftoning uses very small dots but varies their spacing rather than their size – so-called ‘stochastic’ or FM (‘frequency modulation’) screening. cf line art, which uses only ‘solid’ ink and does not use halftoning to simulate shading.
Handle system: The name resolution system that underlies the DOI. The Handle system turns an identifier or ‘handle’ for a resource – something like 10.4400/zuim — either directly into an IP address, or into a DNS name which can itself be resolved to an IP address. The resulting IP address can then be used to locate the identified resource, or its metadata, on the Internet.
H.264: See AVC.
Hart’s Rules: Reference book listing rules of (British) English spelling, punctuation, grammar, usage and typographic style. Derived originally from guidelines for Oxford University Press, but is now the basis of ‘house style’ at many UK publishers. cf Chicago Manual of Style.
Hash: Typographic symbol ‘ # ’ indicating ‘number’ or (in North America) ‘pound avoirdupois’. Not to be confused with the Pound Sterling sign ( ‘£’ ) or the musical sharp sign ( ‘♯’ ).; Short, unique numerical pattern based on the digital content of a large block of data. If the underlying data changes in any way, the hash (sometimes loosely termed a ‘fingerprint’) inevitably changes, so comparison of the expected and actual hash values is a way of detecting changes to the data. There are many different procedures (‘functions’ or ‘algorithms’) for generating hashes, for example MD5 or SHA-256. cf fingerprint. See also identifier, the key difference is that the hash is generated from the data via a particular hash function, whereas identifiers are assigned to the data.
Hexadecimal: Numbers in base 16. Hexadecimal notation is convenient for numbers that are actually stored by a computer as binary (base 2) numbers. 49 in ‘hex’ is 01001001 in binary (and 73 in ordinary base 10). Hexadecimal uses the digits 0–9 and a–f, so after 49, you get 4a (01001010), 4b–4f (01001011–01001111), then 50 (01010000).
H&J: See hyphenation and justification.
HTML: Hypertext Markup Language, the markup system used for simple web pages. Usually refers to HTML version 4, standardized by the W3C in 1997. It uses simple XML-like tags to add structure to plain text, for example by surrounding third-level headings with <H3> tags and by marking paragraphs with <P> tags. See also XHTML, CSS.
HTML5: The latest version of HTML. Some old HTML tags have been removed or redefined, some new tags have been added, the specification itself (technically a W3C ‘Recommendation’) is more rigorous, but it retains much of the familiarity of HTML version 4. Less formally, ‘HTML5’ may also encompass related standards used in modern web browsers. See also CSS.
HTTP: HyperText Transfer Protocol, a standard method used for transferring files across the internet. HTTP is used to transfer normal web pages (at their most basic, these are just files that use HTML markup) from web server to browser – but HTTP can be used to transfer other types of information too. cf FTP
Hyphenation and justitifcation: Usually just H&J, typesetting procedures to align line endings so that both left and right margins are straight rather than ragged. Both the spacing of letters and between words can be varied so that each line of justified text is the same length. In some scripts (eg Arabic), joining strokes between individual letters can also be elongated. Words can be hyphenated to reduce the need for excessive variations, and to improve the look and readability of the text. Justified text may still need further adjustment to eliminate widows and orphans.
Identifier: Effectively, a persistent ‘name’ or ‘label’ for some entity like a product, a work, a location – or indeed a name – where the label is unique within a given context. Identifiers are often (but not always) in a tightly-controlled alphanumeric format, and sometimes contain a check digit to help error detection. Standardized identifiers (for example the ISBN or ISNI) generally provide global uniqueness, there is often a minimum set of metadata associated with the identifier, and the identifier and metadata are sometimes managed in a centralized registry. Other identifiers use decentralized registries. A well-managed registry engenders trust in the identifier and its likely future persistence. Although many identifiers are constucted using a ‘recipe’ (something like ‘four digits for the year, three for the publisher, then five more digits and a check digit’), it is best to treat them as dumb labels without internal meaning, intelligence or affordance. For standardized identifiers, the nature or scope of the identified entity is well defined and understood, so they enable unambiguous communication between organizations within the supply chain. Proprietary identifiers such as the ASIN may only be unique within a particular organization, and the exact nature of the entity identified is often not understood beyond the organization.
IDPF: International Digital Publishing Forum, the body that devised and maintains the EPUB file format for e-books.
IFC, IBC: Inside front cover (cover 2), Inside back cover (cover 3).
ILS: See LMS.
Imposition: The arrangement of a set of pages printed on a single sheet, so that the pages appear in the correct order when the sheet is folded and trimmed to form a signature. Page 2 will be printed on the reverse of the sheet where page 1 is printed. Page 3 will not be imposed side-by-side with page 2 (except in a 4-page imposition with a single fold), but will appear adjacent after folding. Pages 2 and 3 are a ‘reader’s pair’ or spread in the finished book, but pages 2 and 15 could be a ‘printer’s pair’ (they will be adjacent in a 16-page, three fold imposition).
Impression: A single print run or batch of copies of a book. All copies in an impression are manufactured at the same time and are identical. Subsequent impressions of the same product (reprints) may incorporate minor corrections to the content but may not include significant changes (significant changes to the content would imply it is a new edition). The impression number is usually noted on the copyright page.
Imprint: A brand name or marque used on the product by the publisher. On a book, the imprint is usually named on the title page with further details on the title verso. The imprint name is often (but not always) different from the name of the publisher, and larger publishers often make use of multiple imprints across a variety of products. cf list.
Imprint page: See copyright page.
In print: Active, available. Status implying the product has been published and is orderable from the publisher or publisher’s distributor. Note that this does not imply the product is immediately available – it may be temporarily unavailable (cf in stock/out of stock). Conversely, out of print does not mean the product is necessarily unavailable – there may be stock within the supply chain. Out of print means only that the publisher will no longer accept orders for the product. Out of commerce is sometimes used to indicate ‘out of print and unavailable’.
Indecs: The <indecs> project and resulting <indecs> metadata framework provide the conceptual model and many of the principles that underpin the ONIX metadata framework. For example, the concepts of work and manifestation used in the ONIX framework (and the item concept which is largely unused in ONIX) are drawn directly from <indecs>. cf FRBR. <indecs> also underlies DDEX and EIDR for the recorded music and filmed entertainment sectors
Insert: See plate section.
Inspection copy: Copy provided to a potential customer – often an educational institution – on SOR terms, for evaluation and potential purchase or adoption.
Instance, item: A single copy of a book. In both the FRBR and <indecs> frameworks, a single ‘instance’ of a particular manifestation.
Integrated book: Book with text and illustrations combined on the same pages, rather than with any illustrations isolated in a plate section.
Internet: ‘The much-feared best advertisement for books, and their perfect complement: one being a high-tech place where you can go to be connected and somehow feel alone, the other a low-tech thing where you can go to be alone and somehow feel connected.’ Steve Macone, New York Times blog, 25 Nov 2013.
IP, IPR: Intellectual Property Rights are legally-recognized property rights over tangible expressions of creations of the mind such as literary, musical and other artistic works, designs, inventions and discoveries. IP is (or can be) protected by copyright, patent, design and trademark registration. See Rights.
IPA: International Publishers Association, organisation representing publishers worldwide.
IP address: Internet Protocol address, unique numerical address of a computer attached to the Internet. Some IP addresses are also associated with DNS (Domain Name System) names, which are easier to remember – 70.32.68.89 is (currently) www.editeur.org. Computers use the IP address to communicate with other computers, but whenever necessary, they use the DNS system to convert (or resolve) any names entered by a human into the matching IP address.
ISBN: International Standard Book Number, unique and internationally-recognized identifier for a ‘monographic publication’ – a book, e-book, audiobook or book-like product – which according to ISBN rules must be available to the public. See also barcode. ISBNs are a subset of GTIN-13s beginning with 978 or 9791–9799 (9790 numbers are ISMNs). ISBNs consist of 13 digits (eg 9780001234567), though they are often displayed with extra spaces or hyphens (eg 978-0-00-123456-7 or 978 0 00 123456 7). But the hyphens or spaces are really just a convenience – they are not a significant part of the identifier. [The positions of the hyphens or spaces within the ISBN highlight the different ‘parts’ of the ISBN – for example separating the ‘registrant element’, sometimes called the ‘publisher prefix’ (00 in the example), from the ‘publication element’ (123456) and the final check digit (7). Note that the middle two of the four spaces or hyphens do not always appear in the same positions – their correct positioning depends on the length of the ‘registration group element’ (0 in the example, but can be up to five digits) and the registrant element (00, but can be up to seven digits). A longer registration group or registrant element implies a shorter publication element.] Also termed ISBN-13 when it is important to differentiate from legacy ISBN-10s.
ISBN-10: Prior to 2007, ISBNs contained only 10 digits (occasionally including the digit X, used to represent 10 in the last digit, the check digit, which was calculated using base 11 arithmetic). Any former 10-digit ISBN can be converted into the equivalent 13-digit ISBN by prefixing it with ‘978’ and recalculating the check digit. (There are several online converters which will do this. The algorithm for 13-digit ISBNs is different from that used for ISBN-10.) Any 978… ISBN-13 can be converted back into an ISBN-10, but 979… ISBN-13s do not have an ISBN-10 equivalent. Continued use of ISBN-10s is strongly deprecated.
ISBN-13: See ISBN.
ISBN-A: Actionable ISBN, a special type of DOI that incorporates an ISBN as part of its syntax. The equivalent ISBN-A for the ISBN 978-0-00-123456-7 would be 10.978.000/1234567. Note that registration of an ISBN-A is separate from the registration of the ISBN – it is not an automatic part of the ISBN registration process.
ISLI: International Standard Link Identifier. An embryonic international standard identifier that can be attached to a relationship between two entities, when it is important to identify and manage the link itself, not just assert the fact that it exists. The ISLI could find potential application in rights management, where in a relationship such as ‘A licenses B’, it would be important to attach an identifier and other metadata to the ‘licenses’ relationship.
ISMN: International Standard Music Number, an identifier similar to the ISBN, but used for manuscript (notated) music and digital equivalents. Prior to 2008, ISMNs were ten characters (the letter M plus nine digits), but are now 13 digits, with 9790 replacing the ‘M’. A mathematical quirk – or admirable foresight – means the check digit does not need to be recalculated.
ISNI: International Standard Name Identifier, a standard identifier for public identities or personas of parties (people, organizations) involved in creative activities. It can provide an unambiguous way of identifying contributors and publishing companies. An ISNI consists of 15 decimal digits plus a final check digit which may be 0–9 or X.
ISO: International Organization for Standardization, the non-governmental global standards setting body of which mamy national standards bodies are members. ISO Technical Committee 46 Subcommittee 9 (ISO/TC46/SC9) is ultimately responsible for many standardized publishing identifiers including the ISBN, ISTC and ISNI, but ISO sets standards for many other aspects of the publishing industry too.
ISRC: International Standard Recording Code, standard twelve character identifier for audio recordings (often music). The twelve characters comprise a two-letter country code, a three-character code identifying the registrant, two digits for the year the code was assigned, and five digits to specify the particular recording.
ISSN: International Standard Serial Number, a standard eight-digit identifier for serial publications such as academic journals, magazines and ongoing series of books. As with the ISBN-10, the last digit may be ‘X’. Note that the ISSN identifies the journal (eg ISSN 0028-0836 is the print version of Nature), magazine or series, not a particular issue of the journal or magazine, nor a particular book within the series. The ISSN-L (Linking ISSN) is an ISSN shared between versions of a journal available in different formats (eg online and printed). ISSNs can be expanded to GTIN-13 form and expressed in a barcode using the prefix 977 and a recalculated check digit.
ISTC: International Standard Text Code, unique identifier for textual works. An ISTC consists of 16 hexadecimal digits, comprising a three-digit code for the registration agency, a year of registration, eight digits to specify the individual work and a final hexadecimal check digit. A work identified by an ISTC may be exploited in several products, which would be identified by ISBNs. ISTCs are cross-publisher, and may also be related to each other where one work is derived from another (via translation, abridgement, compilation and so on). Like ONIX, ISTC draws upon the theoretical model provided by <indecs>.
ISWC: International Standard Musical Work Code, unique identifier for musical works, independent of any particular performance or recording (for which an ISRC would be used). An ISWC consists of 11 characters – a T followed by nine digits and a check digit.
Jacket, dust jacket: Loose paper cover wrapped around the boards of a cased book, also known as a dust cover, dust wrapper etc. The imagery printed on the jacket (the ‘cover image’), and any blurb on the folded-in flaps, are key marketing tools.
JPEG: Joint Photographic Experts Group. More commonly, an efficiently compressed image file format standardized by that group. JPEG image files are much smaller and nearly as high in quality as the original image (as little as 10% of the size with little peceptible decrease in quality). Greater compression reduces the image quality (JPEG is ‘lossy’), and highly-compressed JPEG images often show characteristic ‘quilted’ patterns. cf TIFF.
Jusitification: See hyphenation and justification.
Kerning: Adjustment of the spacing between particular pairs of letters to improve their fit and look. For example, in the word ‘WAVE’, the A fits nicely between the W and the V, so the three letters can be closed up a little. cf ‘tracking’ or letterspacing, which adjusts the spacing between all letters equally to adjust the length of a line (see justification).
Key title: See lead title.
Keyword: Word or phrase chosen to describe the content or theme of a book. Keywords do not conform to a controlled vocabulary, but may be any natural language word, such as names of characters in a novel, locations, narrative themes etc – any relevant word that is likely to be the target of a search.
Lamination: Thin plastic film applied to a printed sheet, for protection or to improve the appearance. The film can be glossy or matte.
Landscape: A page or image in landscape format is wider than it is tall. cf portrait, where the height is greater than the width. See also aspect ratio.
Latin‑1: Also known as ISO 8859-1. One of a range of standard 8-bit encoded character sets intended for use with various European languages – Latin‑1 is designed for a wide range of west European languages, and includes the common characters A–Z, a–z, 0–9 and basic punctuation, plus some fancy symbols (eg §, ¶, ¿, × and ÷ symbols) and extra and ‘accented’ characters like æ, ð, ø, ß, and á, ç, ê, ñ, ü. It omits curly quotes, en- and em-dashes and some other fancy punctuation (see Windows‑1252), and many Latin characters used only by central and east European languages. It is a superset of ASCII, and a subset of Unicode. Related character sets Latin‑2 to Latin‑10 are optimized for other Latin-script languages: Latin‑2 contains the necessary characters for most central European languages, Latin‑5 is for Turkish, Latin‑9 (also termed ISO 8859-15) is an improved version of Latin‑1 that additionally includes the Euro sign (€). Further ISO 8859 character sets combine basic Latin characters and symbols with Cyrillic, with monotonic Greek, with Hebrew and with basic Arabic characters.
Latin‑9: See Latin‑1.
Laydown: See Embargo date. In printing, is occasionally used to mean Imposition.
LCC: Library of Congress Classification, book subject classification used in some libraries. cf DDC, UDC.; Linked Content Coalition, a consortium of standards bodies and identifier registries that aims to – over time – increase interoperability between metadata, rights information and identifier standards across multiple media sectors.
Levelling: Measurement or assessment of the complexity of text, or the reading ability required for comprehension.
Lead time: Expected time taken from order to delivery, for example of a POD product.
Lead title, Key title: Publisher’s frontlist titles for any particular month or season that are expected to sell the most copies or become bestsellers, which are given significant advertising and promotion support (A&P). cf midlist.
Legal deposit: Legal requirement and administrative process whereby publishers lodge a copy – sometimes multiple copies – of every publication with a national library or with other repositories. Exact requirements vary from country to country, and increasingly apply to digital as well as physical publications.
License: A limited set of rights granted by a rightsholder to a licensee, together with any accompanying duties. An e-book ‘purchase’ is in fact the purchase of a license (a bundle of rights) to use the e-book in various ways (which for example does not usually include the right to lend or resell the e-book). The license is normally perpetual – a DTO model (cf rental, DTR). Traditional book sales involve both a limited bundle of rights and the physical object. The rights governed by the license terms for e-books are narrower, and are not exhausted in the same way as they are with physical goods (or in other jurisdictions, the principle of first sale does not apply).
Line art: See halftone.
List: Informally, the books a publisher or imprint has available in print, or are soon to be published. Within a large publisher, there are usually separate lists for different types of book. See also backlist and frontlist. cf imprint.
LMS: Library Management System, integrated software appliations to support the functioning of a library, including acquisition, cataloguing and access. Also ILS, Integrated Library System.
Locale: The set of location or culturally-specific patterns and conventions used for display of numbers, prices, time and date formats, etc, sometimes also encompassing language and script preferences, and sort order. ONIX generally aims to ensure data (other than textual descriptions) is communicated in a locale-independent way, leaving the details of locale-specific use or display of the data to the eventual recipient. The Common Local Data Repository (CLDR) is a useful central source of information about specific locales.
Loose leaf: Publication which is supplied unbound, as individual sheets. These are usually punched to fit in a binder (often the type with openable metal rings) which makes replacing updates pages simple.
Lossy, lossless: See compression.
Manifestation: The physical or digital embodiment of a particular work. The related hardback, paperback and e-book products are different manifestations of the same work. All contain essentially identical content. Note that a manifestation encompasses multiple individual copies (or instances) of a book, which are identical (or very nearly so). Manifestations may be identified with ISBNs. See <indecs> and FRBR.
MARC: Machine Readable Cataloging, a family of metadata formats used in library cataloguing. MARC21, the latest version in use in North America and the UK, is closely tied to the AACR2 cataloging rules. UNIMARC and many minor national variations are common elsewhere. MARC has been in use for nearly 50 years, and has been updated many times to cope with developments in cataloguing practices (see AACR2 and RDA), but it is likely to be replaced by more modern data formats over the next decade.
Market: A geographical area within which commercial arrangements for distributing and selling a product are consistent – usually with a single exclusive distributor and single availability date across the market.
Markup: Labels, delimiters or tags within a document that define its structure or meaning. In XML and HTML, markup tags are placed between < and > symbols. Tags are often paired to indicate the beginning and end of a particular data element within the document, so top-level heading text in HTML is contained between <H1> and </H1> tags. Markup can be described as semantic or presentational, but in practice is usually a mixture of both.
Mass market: General non-specialist (adult) consumer market. Also, a paperback product aimed at this broad-based market.
Message: See ONIX message.
Metadata: Strictly, data about other data. More usefully, in the context of the book and e-book supply chain, metadata can be thought of as all the data used to describe and trade products through the supply chain. This encompasses both simple, structured and factual information like titles, author names, distribution arrangements and prices, and richer, more complex descriptive data, classifications of various types and even parts of the book itself (a table of contents can be seen also as valuable descriptive metadata). ONIX messages are simply a method of communicating highly structured and standardized metadata from one party to another within the supply chain.
Midlist: Frontlist titles not expected to become bestsellers, and thus not attracting the marketing and promotional effort that publishers afford to lead titles.
Mono, monochrome: Printed using a single ink (usually black). Note this can include halftone images, not just text and line illustrations.
Monograph: Publication that’s complete in one part or volume (or occasionally, in a small number of separate volumes). Individual stand-alone books – or occasionally, sets of books – are monographs. Sometimes also implies a detailed and scholarly work. cf a serial publication such as an academic journal or magazine.
Moral rights: See copyright.
MP3: MPEG Audio Layer-III, standard for compressed audio files. cf AAC. See also codec.
NBN: National Bibliography Number, an identifier assigned to a book or other document by a national library. Unlike the ISBN, there is no international standard – every library uses its own proprietary format, and NBNs are rarely used outside the library context.
Normalization: In a relational database, the strategy of designing data tables and relationships between tables to ensure each chunk of data is stored only once, so that it can be managed efficiently and consistently. However, database designs can sometimes be judiciously denormalized to improve performance, if data management is not such a priority.
OA: See open access.
OCLC: Online Computer Library Center, US-based global library cooperative offering services such as cooperative cataloguing, technology services and research.
OFC, OBC: Outside front cover (cover 1), Outside back cover (cover 4).
ONIX_implement: E-mail mailing list and support forum for general questions about ONIX.
ONIX message: A complete ONIX data file, generally one in a series of messages passed between a data provider and a data recipient. A single message may contain one or many Product records.
On-sale date: See strict on-sale date.
OP: See out of print.
OPAC: Online Public Access Catalogue, bibliographic database of a library’s holdings, accessible either online or via terminals within the library.
Open access: Licensed on ‘open’ terms, for example under a Creative Commons license, which typically mean that a work or product can be read, used and re-distributed freely (or at least, free of charge). The particular license chosen may require attribution, prevent the distribution of derivative works, or impose other restrictions. More often associated with serials such as academic journals, but some academic publishers produce open access monographs (ie books). Open access material is usually made available via a digital archive maintained by the publisher or an independent ‘open access repository’.
Open standard: Broadly, standards that are publicly available and generally implementable without charge, and which are developed and maintained through a transparent decision-making process open to a broad range of stakeholders.
OPS: Out of print, Substitute. OP, but the publisher suggests another equivalent or updated product (eg a second edition may be marked as OPS when the third edition becomes available).
Orphan: In typesetting, a single word or excessively short line that appears at the end of a paragraph. Alternatively, a section heading or the first line of a paragraph, or a partial or short line of text (eg the last line of a paragraph), which occurs at the bottom of a column or page. Typesetters and designers try to avoid all three types of orphan. See also widow.
Orphan work: A work protected by copyright or other rights, but where the presumed rightsholders are unknown or cannot be contacted. Such orphans are problematic, because uncertainty about the rightsholders and the expiry of their rights means they cannot be exploited.
Out of commerce: Out of print and no new stock is available in the supply chain (though used copies may be available). May apply to a particular product (which implies that other manifestations of the same work may still be in commerce), or may be applied to a work (which implies no manifestations of the work are in commerce).
Out of copyright: Work on which copyright (and other IP rights) have expired. After expiry, the work passes into the public domain.
Out of print: A publisher may declare a product out of print (or OP) to indicate it will no longer accept orders. This usually also means copies sold to retailers on a sale or return basis are no longer returnable (or may be returnable only for a short period after the product is declared OP). However, out of print does not mean ‘unavailable’, as there may still be many copies in the supply chain. See also in print, out of commerce. Out of print can also be applied to a work rather than an individual product, which implies all manifestations of a work are out of print.
Packager: Agency contracted by the publisher to produce a book, usually including text creation, editing, design and illustration but not manufacturing of the final product.
P&A: Price and availability. Not to be confused with A&P, advertising and promotion.
Page count: See extent.
Page proof: Paginated but unbound proof copy for final checking, indexing etc prior to printing and publication. cf galley proof, bound proof.
Pallet: Wooden packing base on which books (or other goods) are stacked, stored and transported in bulk. A pallet or skid is typically around 1 × 1.2m and can carry up to about 1000 typical hardback novels or 2000 paperbacks (depending on their extent), or a tonne of paper sheets.
Pamphlet: Small booklet with few pages, often self-covered (no separate cover), and usually bound with a simple wire stitch.
Paper weight: The weight of a particular grade of paper, usually measured in gsm (grams per square metre of a single sheet). Handily, an A0 sheet is 1 square metre, and so are 16 sheets of A4. Typical book paper lies in the range of 60–100gsm. In North America, paper weight may instead be expressed in terms of the Basis weight, the weight in pounds of a Ream (500 sheets) sized 25 × 38 inches. Typical book paper lies in the range of 40–70lb basis weight (approximately equivalent to 60–100gsm). For some types of paper and board, a different basis size is used – eg 20 × 26inches for cover board, so 230gsm cover board is 85lb basis weight (and this is sometimes written 85#). See http://www.papersizes.org/us-international-weights.htm for basis weight to gsm conversion tables. See also bulk.
Partwork: Publication released in several weekly or monthly installments, which may be bound together to form a complete book.
Party: Generalized term for a person or organization involved in a creative activity. See also persona.
PDF: Portable Document Format, standard file format for electronic documents (including e-books), originally devised by Adobe but now an ISO standard. A PDF file can encapsulate almost every aspect of the document – the text, fonts, all vector and raster graphics and even limited interactivity. In general, a PDF fixes the design of the document exactly and PDF is often used to transfer publisher files to the printer for manufuacturing, but reflowing PDFs are possible. Unfortunately, PDF does not retain structural or semantic markup, which reduces its accessibility.
PEFC: See FSC.
Permissions: Authorization from the copyright or other rightsholder to incorporate one work, or a part of a work, within another – for example the permission to include a copyright image or quote a passage of text from one book in another. See also rights.
Persona: The public-facing outward identity of a party – usually of a person. See also ISNI.
Pilcrow: Typographic symbol ‘ ¶ ’ usually indicating ‘paragraph’ (or sometimes in technical contexts, the Return character at the end of a paragraph).
Pixel: See raster image.
Plate section: Pages bound into a book containing primarily halftoned illustrations (often photographs), usually printed on higher quality paper than the remainder of the book block. Plate sections – sometimes also termed Inserts – usually lack page numbers. cf integrated book.
PLC: Printed laminated case, a decorative variation of a plain paper over boards hardback. The printed design on the cover boards is usually varnished or laminated, as PLCs often lack a separate jacket.
POD: Print on demand, the manufacture of a single copy – often using xerographic (toner-based) printing – in response to a customer order. POD copies may be drop-shipped to the retail customer, or fulfilled via a retailer. cf Short-run printing, which often uses similar technology to manufacture small numbers of copies (a print run of perhaps 10 up to 200 copies). These copies are then warehoused and distributed in a conventional manner (though warehousing for such small numbers of copies may be at the printer, rather than at a dedicated distributor’s or wholesaler’s warehouse).
Point: Traditional primarily American and British typographic unit of size, abbreviated as pt. Historically, slightly less than 1⁄72nd of an inch (or about 0.3515mm). The use of points in Postscript has made exactly 1⁄72 (0.3527mm) the de facto standard, and spread the use of points to other typographic traditions. The main text in a printed document is usually around 9–12pt. cf Didot, measurement unit widespread in European typography at least until the 1980s, around 0.375mm (ie about 7% larger than a traditional point).
Portrait: See landscape.
POS: Point of Sale, or Point of Service – ultimately, the retailer’s till or checkout. In the US, Point of Purchase.; Promotional material such as posters, dumpbins, bookmarks placed at or for sale at the retailer’s till or checkout.
Post-coordination: See pre-coordination.
Pre-coordination: Method of classification where multiple concepts are combined to form single subject headings or codes carrying multiple meanings. The opposite is Post-coordination, where the multiple subject headings are used, and the combined meaning emerges from the combination of subject headings or codes. As an example, BISAC is pre-coordinated – a children’s sports story featuring baseball would be classified as JUV032010 – whereas Thema is at least in part post-coordinated, and the same book would be classified as YFR (Children’s sporting stories) plus YNWD3 (baseball).
Prelims: See front matter.
Pre-order: Consumer order placed with a retailer in advance of actual availability of the product, for delivery on (or at least close to) the publication date.
Presentational markup: See semantic markup.
Print-impaired readers: Readers with visual, physical or cognitive impairments who cannot use conventional printed or on-screen books, for example blind, partially-sighted or dyslexic readers, or readers with a physical disability. Print-impairment is a range of issues rather than a single problem, but print-impaired readers can often make use of various types of assistive technology and accessible editions. In many countries, print-impaired readers have a copyright exception that allows copying and modification of copyright material to make it accessible for personal use.
Print run: Number of copies printed in a single impression. Historically, this was an edition, and this sense is still used in book collecting (‘a valuable first edition’).
Process color: Color printing in which CMYK inks and halftoning are used to simulate the full range of color. Note that cyan, magenta, yellow and black is not the only possible combination of process colors – though rare, a six-color process with additional orange and green inks can widen the range of colors that can be simulated faithfully (the color gamut). cf mono, spot color.
Product: A particular manifestation of a work that is available for sale to the public (or to an organization, on a business-to-business basis). Although ONIX is often characterized as describing products, it can be used to describe parts of a product that are not individually available, or components that are used during creation of products. However, such parts and components should not be identified using an ISBN, unless they are also products in their own right.
Product record: The complete collection of metadata relating to a single product, provided within an ONIX message. A Product record is contained between <Product> and </Product> tags.
Provenance: In metadata, the origin of an assertion or metadata property – for example, who says that the book is about motorcycle maintenance? The provenance is important when metadata sources conflict.
Publication date: See Publishing date composite in Group P.20.
Public domain: Works in which all copyright, neighboring and related rights have expired, or those where such rights never pertained. Note that works covered by Creative Commons and similar open access licenses are not public domain, though for particular ‘licenses’ such as the CC0 (‘CC Zero’) waiver, the net effect may be somewhat similar.
Publisher: The organization responsible for making the product available, and generally the one taking the financial risk. cf distributor, contributor and imprint. The publisher is a legal entity, whereas the imprint is merely a brand name.
Publishing rights: The right to publish or commercially exploit a work, obtained by the publisher from the author, creator or other rightsholder. The publishing rights obtained by a publisher may be global and perpetual, or limited geographically or for a limited period. In the English-language publishing market, it is common for a British-based publisher to obtain world rights from an author, but then sub-license North American rights to a US-based publisher (or vice versa). Alternatively, the author may license the North American and remaining rights separately to two different publishers, or a single publisher may obtain the rights to publish globally. cf sales rights.
QR code: Quick Response code, a type of 2D barcode comprising a grid of black and white squares. When scanned (eg with a smartphone), QR codes can trigger actions (go to a URL, send an SMS text message, add contact details to an address book, display text), and some actions have attendant security risks. There is no standard use within the book trade, but they are often used in consumer advertising to avoid the need to type long URIs.
Qualifier: Subject code used within schemes such as BIC and Thema that can only be used to refine the meaning of another code.
Quarter-bound: High-quality binding in which the spine (only) is bound in leather (or other fine and durable material). cf half-bound, full-bound.
Quotation marks: Typographic symbols (eg ‘ ’ or “ ”) used in pairs around quotations, reported speech or to highlight a word or phrase. Different languages use different quotation marks, even within the same writing system, and conventions for single or double quotes vary too (eg English uses ‘…’, German uses „…‟, French uses « … », Japanese uses 「…」).
Rag book: Children’s book in which every leaf is fabric rather than paper. Also termed a ‘Cloth book’.
RAM: Random Access Memory, the working memory of a computer, usually in the range of 1 gigabyte (roughly a billion bytes, in a smartphone) to 64 gigabytes (in a server). The contents of RAM are usually lost when the computer is switched off. Contrast with the more or less permanent storage attached to a computer, which is also measured in gigabytes.
Raster image: A digital image represented as rows and columns of colored dots (Pixels – picture elements). TIFFs and JPEGs are raster image formats. Raster images cannot be scaled without losing visual clarity – if displayed too large, curves become jagged and the image pixels become individually visible. cf vector image.
RDA: Resource Description and Access. Modern set of library cataloging rules – not yet widely used but likely to supplant AACR2 in most English language library applications.
RDBMS: See Relational database.
Reading age: Measure of a child’s reading proficiency or the proficiency required to read a text, expressed as the age of a child of average reading ability.
Recto: The side of a single leaf in a book that is read first – the right hand page in a book, which is usually given an odd page number. (Conceptually, a recto page is a left page in Arabic, Hebrew, or in traditional Chinese and Japanese, where page progression is right-to-left.) The opposite is a Verso page, the second side of a leaf, or left hand page (in most languages), with an even page number.
Reissue: As for reprint, but with refreshed marketing collateral, a new cover etc. Reissue sometimes implies renewed availability after a period where the product has been unavailable. Reissues continue to carry the same ISBN as earlier impressions (using a new ISBN is simply a new product, not a reissue of the original, even if it carries identical content and has an identical product form etc).
Relational database: Metadata is often managed using a relational database, in which the data is stored in one or more tables. Each table has rows representing entities such as products or contributors, and the table columns are the properties of each entity. The tables are normalized (designed to minimize redundancy), so each bit of data is stored only once – so an author who has written a dozen books has their name stored once, forming a row in a Contributor table, and data in that row can be linked to the many rows in the Books table as required. Most relational database management applications have library software for importing and exporting XML.
Remainders: Unsold books disposed of by the publisher or distributor at a low price to a specialist bookseller (who cannot return them). An alternative to destruction of unsold copies.
Rental: In e-books, a limited-term (temporary) license, where a ‘purchase’ is a perpetual license.
Repertoire: In text encoding, the range of characters used in a document, or present in a particular character set.; In rights, may refer to the works of a particular creator or rightsholder, or those offered by a righsholder for licensing under particular terms.
Reprint: [Print] a new impression, usually manufactured to replenish stock. Copies are essentially identical to the previous batch or impression, though may incorporate minor changes to correct errors, and they carry the same ISBN as previous impressions. Note that if the changes represent significant alterations to the content, then the new copies are a distinct edition – in ONIX terms a new product (and indeed a new work) which would also have a new ISBN (and a new ISTC).
Reseller model: Business model based on the idea that the publisher sells to an intermediary (typically a distributor, wholesaler or retailer) based on an established retail price minus a discount (the discount may vary from intermediary to intermediary), or via an established business-to-business or wholesale price. The intermediary can subsequently sell on the book to the consumer at whatever price they choose. Alternatively, in some legal frameworks, the retailer must sell to the consumer at the fixed retail price. In either case, it is the wholesaler or retailer that is the publisher’s direct customer, and not the consumer. This is the most common business model in the book trade; cf the alternative agency model.
Resolution: The process of resolving an identifier to retrieve its underlying metadata, or to find the entity itself. For some ‘actionable’ identifiers such as the ISBN-A, this resolution process can be via the internet, in the same way a DNS name may be resolved to an IP address.; The degree of detail captured in an image (or more generally, degree of precision in a measurement). Image resolution is usually expressed in dots per inch (DPI) or per centimetre. Note that resolution applies to an image in the physical world, not to the underlying pixel data which can be reproduced at any size (see notes on image resolution in Group P.16).
Returns: Books sold to retailers on ‘sale or return’ terms, that fail to sell at retail and are subsequently returned to the wholesaler or distributor for credit. Some publishers allow low-value books to be destroyed by the retailer rather than physically returned (eg by stripping off the cover, which is then returned as proof of destruction).
Reversion: Return to the creator of rights previously licensed by the creator to a publisher, for example at the end of a contractually-set term or under other agreed circumstances. Reversions are often requested if a publisher fails to keep a work in print.
Review copy: Copy sent (free of charge) to the press or other media for the purposes of review. See ARC.
RGB: Red, Green, Blue – basic additive color model used (eg) on a computer screen to generate (or at least simulate) the full range (or gamut) of visible colors. See sRGB, Adobe RGB, CMYK.
Rights: General term covering copyright, moral rights and other intellectual property rights, plus contractual rights such as the right to distribute or sell products. Volume rights give the publisher the right to publish and sell products based on (manifestations of) a copyright work, and are sometimes divided by language and geographical territory (eg ‘the publisher holds Commonwealth English language rights’). Subsidiary rights (usually attached to the volume rights, but often sublicensed by the volume rights holder) include the right to create and publish serializations, abridgements, adaptations and (assuming the underlying volume rights are not limited by language) translations. Distribution rights are rights conferred by the publisher on a distributor, enabling the distributor to trade a product in a particular market. See also permissions, publishing rights, sales rights.
Rightsholder: Party which holds copyright or some related rights in a work.
RNG: RELAX NG schema language. See schema.
Rough front: See deckle edge.
Royal: Common UK hardback book size typically around 234 × 153mm. See also demy, trade paperback.
Royalties: Payments made by the publisher to authors or other contributors, in return for the right to publish and sell the book. Royalties are usually calculated as a percentage of the price of the book – though sums are often paid in advance, and minor contributors may only receive a fixed fee.
RRP: Recommended Retail Price, a price chosen and recommended by the publisher for sales to the consumer (occasionally termed a Suggested retail price, or SRP). The retailer does not have to use this price, and may choose to sell the product for a lower (or higher) price – the Actual selling price or ASP. But royalties paid to the contributors of the book are often based on a percentage of the RRP, even though the Actual selling price is different. In some countries, retail prices set by publishers are fixed: by law, retailers may not reduce (or increase) the Fixed pricing. In countries where RRPs are the norm, the Agency model may also allow publishers to exert direct control over consumer prices.
Ruby: Small gloss or annotation added to characters in non-alphabetic scripts such as Japanese or Chinese, used to guide pronunciation of unfamiliar characters or provide phonetic information for sorting purposes. See Person name in Group P.7.9, though ruby glosses can be incorporated into any textual data element.
Sale or return: Transaction terms where goods are sold (eg from a distributor or wholesaler to a retailer) and the purchaser retains the right to return them for full credit if not sold at retail. Resellers rights to return unsold copies may expire when or a fixed period after a book is declared out of print. In some cases, goods need not be physically returned – commonly, the cover can be torn off and returned instead (such books are ‘strippable’). In contrast, ‘Firm sale’ terms mean the product is sold and is not returnable for credit at all, and ‘Consignment’ terms (sometimes called ‘see-safe’ terms) mean the product is still owned by the upstream distributor or wholesaler even though it is physically stocked by the retailer (the retailer ‘buys’ it only after selling it on to a consumer).; Occasionally, sale or return terms (more strictly, consignment terms) are applied to products supplied to end-purchasers, and the purchaser pays only after deciding to keep the goods. See inspection copy.
Sales rights: The contractual rights that a publisher confers on its distributors, wholesalers and retailers, allowing them to trade and make the product available. Note the contrast with publishing rights. Publishing rights concern where a publisher has the right to sell a product. The sales rights are where the publisher chooses to make the product available. Clearly the sales rights must be a subset (or the same as) the publishing rights. In ONIX, only the sales rights are described in detail.
SAN: Standard Address Number, American national standard identifier for a trading location within the supply chain. The SAN registry is administered by Bowker. In contrast to the GLN, it is unique to the publishing industry, but is well established in book-related e-commerce in North America and parts of Europe to identify distribution locations, customer delivery addresses etc.
Schema: Like a DTD, an XML schema formally defines the set of markup tags that may be used in a particular type of XML document, their order and nesting. But unlike a DTD, a schema also constrains the data types and values that may be used within the data elements in the document. Two primary ‘flavors’ of ONIX for Books schemas are available, using the XSD and RNG schema languages, both of which are themselves XML documents. (Technically, the DTD is a very simple kind of schema too, though DTDs are not themselves XML documents.) A further type of schema, a Schematron, is also available for trial use, and would normally be used in conjunction with an XSD schema. Not to be confused with a database schema, which is a formal definition of the structure of a database and defines the nature of the columns, tables, relationships and so on in the database.
Schematron: An alternative type of XML schema language. Schematron is rule-based, and is able to test conformance with a wider range of document constraints and business rules than XSD or RNG schemas. The ONIX Schematron also checks identifier check digits, and can provide warnings when recommended maximum text string lengths are exceeded.
Section mark: Typographic symbol ‘ § ’ usually indicating a section or clause in a document.
Self-publisher: Person combining the roles of contributor and publisher.
Sell-in: Sales to retailers – the number of copies entering the sales channel. In the book trade, most of these copies are typically sold on sale or return terms, so sell-in is not a final sales total. cf sell through.
Sell-through: Sales to consumers. In principle, sell-through = sell-in minus returns. Sell-through is sometimes expressed as a percentage of sell-in (eg a sell-through of 85% implies a 15% return rate). See also EST.
Semantic markup: Markup tags that define or at least highlight the meaning or nature of the tagged text, rather than simply specifying how it should be presented. In contrast, presentational markup defines only how the text should be displayed on page or screen. As a simple example, HTML includes <i>, a purely presentational tag that indicates text should be displayed in italics. In contrast, the <em> and <cite> tags have the same typograhic effect on the appearance, but have extra semantic value – they indicate why the text should be italicised (for emphasis, or because it is a title citation).
Serial: Ongoing publication issued under the same title in a succession of discrete parts, often at regular intervals, such as a magazine, academic journal, newspaper or regularly-issued directory or annual report. Issues are usually dated or numbered sequentially, and are usually purchased via a subscription rather than by purchase of individual issues. Just as monographic publications are identified with an ISBN, serial publications are identified with an ISSN.
Series: Continuing and indefinite sequence of monographic products published separately over a period of time, with a shared identity such as a ‘series title’. The products are usually of similar product form, and share a distinctive branding or design style. A series is not available for purchase as a single product. In ONIX, a series is a type of collection. cf set.
Set: Finite number of products published simultaneously or over a definite period of time, with a shared identity such as a ‘set title’. The products are usually of similar product form, and share a distinctive branding or design style. The products in the set may be available individually, or the set may be a single product, or both. In ONIX, a set is a type of collection. cf series.
SGML: Standard Generalized Markup Language. Highly complex technical standard for markup. Effectively the predecessor of XML, but rarely used because of its complexity.
Short run: See POD.
Signature: A number of pages (usually a multiple of eight) printed on a single sheet and then folded and trimmed to form a section of a book. Signatures are gathered in the correct order and bound to form the book block. See also imposition.
Shrinkwrap: Thin plastic film used for packaging, which contracts tight around the packed goods when exposed to heat.
Skid: See pallet.
SKOS: Simple Knowledge Organization System, a way of structuring and representing controlled vocabularies such as ONIX codelists, subject classification and categorisation schemes, taxonomies, etc.
SKU: Stock Keeping Unit. In logistics, a unique (and often proprietary) identifier for each product available. In the book trade, the ISBN is sometimes used as an SKU. But often – for example where a single ISBN is reprinted or reissued – an internal stock control process needs to use more granular identification than is provided by the external product identifier (the ISBN). A book distributor might supplement the ISBN with an impression, lot or batch number to ensure older stock is sold before newer.
SLA: Service Level Agreement, the agreed quality of service (often quoted in terms of time to react, time to complete a task, acceptable technical standards etc) to be provided by a service department or an external partner.
Slip-case: Sleeve constructed of rigid board into which the book slides, leaving the spine exposed.
Solus: Alone, apart from others of its type. So a ‘solus review’ which concentrates on a single book, or a solus advertisement, placed away from other adverts (or at least away from others offering similar products, cf classified advertising).
SOR: See sale or return.
Special sale: Business-to-business sale where the terms and conditions of sale differ from the norm – for example, for a product where sale-or-return terms are normal, a firm sale (non-returnable) is a special sale. The buyer usually pays a lower price, of course.
Sort: Arrange into alphabetical or numerical order.; In typesetting, a special symbol (as opposed to a normal alphabetic or numeric character), a ‘dingbat’.
Spine: Bound edge or back of a bound book, squared off or slightly rounded.
Spot color: Specific colored ink used for printing, in contrast to simulating that color using process color inks and halftoning.
Spread: Pair of facing pages in a book.
sRGB: Standard RGB, the colorspace that Windows uses by default for RGB images. See also Adobe RGB.
SRP: See RRP.
SSCC: Serial Shipping Container Code, an 18-digit number used to identify logistics units such as containers, pallets and shipping cartons (parcels) in the supply chain. The SSCC is often printed as a GS1-128 barcode.
STEM: Science, Technology, Engineering and Maths curriculum topics and publishing sectors.
Stemming: Reducing inflected or derived words to their word stem, base or root form. Search engines use stemming to improve the search results, ensuring that searches for ‘fishes’, ‘fishing’, ‘fished’, ‘fisher’ all match ‘fish’. Occasionally termed ‘lemmatisation’.
STM, STML: Scientific, Technical, Medical (and Legal) publishing sectors.
Strict on-sale date: Also known as an embargo date (this is the preferred term within ONIX), ‘on-sale date’ or ‘laydown date’ – see the <PublishingDate> composite in Group P.20, and note that ONIX does not distinguish between a strict on-sale date backed by legal force (eg an affidavit) and one that is not (eg backed only by an industry code of conduct). Where the publisher wishes to exercise close control over the earliest retail availability of a product, this is the earliest date that a consumer may obtain a copy of a product – though advance orders (pre-orders) may be placed prior to the embargo date, and advance orders fulfilled by mail-order may be dispatched one day prior to expiry of the embargo.
Stream, streaming: Download and play or display audio, video or e-book data in real time, without storing the data permanently as a file.
Strippable: See sale or return.
Subrights: Subsidiary rights, or a sublicensed fraction of the volume rights.
Subscription: Prepayment against future delivery of multiple issues of a serial publication such as an academic journal over a fixed period of time (eg an annual subscription for twelve monthly issues). Journal issues already received are retained by the subscriber even if the subscription is cancelled.; Prepayment of a regular (eg monthly or annual) fee for access to an online resource such as a journal or an online library of e-books for a specific period. Access to the journal or e-book library ends if the subscription is cancelled (in principle at least – some e-journal subscriptions can include limited ‘post-cancellation access’). Note that some so-called B2C ‘subscription’ models are structured more like ordinary B2B sales between publisher or distributor and the subscription library operator, but operate as subscriptions between the subscription library operator and the consumer.
Subscription orders: Retailer orders placed with a wholesaler or distributor several weeks prior to publication date – see also dues.
Subsidiary rights: See rights.
SVG: Scalable Vector Graphics, a vector image format incorporated within HTML5. The diagrams in this document use SVG.
Tag, Tagging: Can refer to either the markup elements of HTML, XML or ONIX (eg ‘the <ProductForm> tag’, or ‘using <ruby> tags in XHTML’), or to keywords associated with some content that are used to classify the content (eg ‘blog posts tagged with “ONIX”’, or ‘a tag cloud’). It is common to confuse these two very distinct meanings, particularly as classification tags can sometimes be embedded within markup tags….
Taxonomy: A classification scheme, where controlled vocabulary terms or concepts are arranged in a hierarchy of classes and sub-classes. Strictly, a particular entity can only be attached to an single class or term within the taxonomy, though this is not always rigorously applied (for example with many ‘subject classification’ schemes). Where the vocabulary terms are related not just hierarchically (ie broader and narrower terms) by also by non-hierarchical links of association (‘related to’) and equivalence (‘same as’), the scheme is often called a thesaurus. A formal representation of the concepts and the relationships is an ontology. See also SKOS.
Technical protection: See Digital rights management.
TEI: Text Encoding Initiative, organisation that develops the TEI standard and guidelines for XML semantic markup of structured text. TEI markup is used most often in academic work in the humanities, social sciences and linguistics, and particularly for text preservation.
Teleordering: E-commerce system handling electronic orders for books, routing EDI messages between booksellers and their suppliers.
Thema: A new subject categorisation scheme that has been developed in part from the BIC scheme, but internationalized and significantly extended to create a multi-lingual scheme with global applicability. It differs from BIC in that it makes greater use of post-coordination, and has a mechanism for national extensions to qualifiers within the scheme. Like ONIX, Thema is managed by EDItEUR. Thema was introduced in late 2013, and is currently in the early stages of implementation in many countries. It is intended to be used in parallel with existing nationally-focused schemes, and has the potential to eventually supplant them as a single global scheme.
TIFF: Tagged Image File Format, a high-quality (lossless) file format for raster images. TIFF files can be compressed, but are still usually much larger than the same image stored as a JPEG.
Tip-in: Extra leaf glued into a book after binding, often used for separately-printed illustrations or plates, errata sheets, gatefolds and other pages that are not the same size, or sometimes for pages intended to be removed.
Title page: Recto page at the beginning of a book that bears the title of the book, and usually also the names of contributors and the publisher and city of publication. The Title verso (the reverse of the title page, often also called the Imprint page) usually contains copyright details and any CIP information and colophon.
Title sheet: See AIS.
Title verso: See title page.
TLS: Trimmed Leaf Size, occasionally TPS (trimmed page size) or just trim size. Dimensions of a book page after binding and trimming. For a typical paperback where the cover is cut flush to the pages, the TLS is also the size of the cover. For hardbacks where the cover boards extend beyond the trimmed pages, the cover is usually around 6mm larger in each dimension.
TOC: Table of Contents.
TPB: See Trade Paperback.
TPS: See TLS.
Trade paperback: In the UK, a paperback produced in a size more typical of hardbacks (see demy, royal); in the US, a paperback that’s usually larger than rack-size mass-market paperbacks (but not as large as a typical hardcover book).
Trade publishing: Publishing of fiction and general interest non-fiction books primarily for adults, which are sold primarily through ordinary retail bookshops. cf specialist sectors, including children’s publishing, academic and educational publishing, STM and legal publishing.
Trim size: See TLS.
TRIPS: Agreement on Trade-Related Aspects of Intellectual Property Rights, international agreement administered by the World Trade Organization that defines minimum standards for legal protection and enforcement of intellectual property rights (IPR).
TTS: Text to Speech. Synthesized speech sounds generated from text by specialized software, usually to improve text accessibility for print-impaired readers.
Typeface: A set of characters of a particular consistent design, for example Helvetica or Garamond. cf font.
UDC: Universal Decimal Classification, common and highly detailed subject classification system used within many libraries and information services. See also DDC, on which UDC was originally based, and LCC.
Ultraviolet: Digital rights management system which implements an internet-accessible key locker, so DRM-protected content can be unlocked by any of the Utraviolet account owner’s devices.
Umlaut: See dieresis.
Unicode: Comprehensive set of characters, hugely improved over ASCII and Latin‑1 to Latin‑10, which are focused on basic English text and European scripts respectively, because it includes the characters required for all common written languages, including non-European scripts like Arabic, Devanagari or Chinese, and a vast range of mathematical and other symbols. However, displaying these characters is font-dependent too – the data may be in Unicode, but if your font does not contain the right characters, you still can’t see it! This page is composed in Unicode, which allows it to include special characters like √ (square root symbol), д (Cyrillic letter de), ش (Arabic character sheen) or 房 (Chinese word fáng) – but you might not see them correctly if your web browser and operating system don’t support Unicode or the font does not include the relevant glyphs. Each character in Unicode has a 32-bit number (cf ASCII, which uses 7 bits (binary digits), or Latin‑1, 8 bits per character, which both contain a much smaller range of characters), so in principle Unicode files are four times the size of Ascii files for the same text content. However, UTF‑8 is a special encoded form of Unicode that reduces the file size to something more manageable.
UPC: See GTIN.
URI: Uniform Resource Identifier – an identifier for a resource (usually, but not necessarily, a resource on the internet).
URL: Uniform Resource Locator – a variety of URI that identifies a resource based on where it can be found or ‘actioned’. For example, the familiar http://www.editeur.org URL is the identifier for a resource – the EDItEUR website.
URN: Uniform Resource Name – a variety of URI that identifies a resource based solely on a name, without any indication of where that resource can be found. For example, urn:isbn:9780007232833 identifies a book, but cannot (in general) be used to find a copy of that book on the internet – some libraries do operate ‘URN resolvers’ to link that URN to metadata about that book or to an electronic copy of the book, but such systems tend to be internal to the library.
UTC: Coordinated Universal Time, or ‘Zulu’ time, which is (for practical purposes) the same as Greenwich Mean Time (GMT). It does not change with timezones or daylight saving. Local timezones use a specific offset from UTC, so EST is five hours behind UTC, and EDT is four hours behind.
UTF‑8: Practical encoding of the Unicode character set. Files containing English text are approximately the same size as if they were represented in ASCII. Files containing equivalent text in other languages are larger, but usually comparable with encodings designed specifically for that language (eg Shift_JIS for Japanese text). UTF‑16 is another practical encoding of Unicode, but it comes in two flavors, UTF‑16LE and UTF‑16BE (little-endian and big-endian).
UUID: Universally Unique Identifier, label or identifier that can be minted in accordance with RFC 4122. UUIDs are essentially random numbers, sufficiently large to practically ensure uniqueness without the need for centralized management (they contain 128 bits, or 32 hexadecimal digits). Some types of UUID include information about the time of creation of the ID, or the machine that created the ID, instead of being wholly random. GUID Globally Unique Identifiers are UUIDs, but the GUID name is more common in some particular contexts (eg within Microsoft software).
Validation: The process of checking an XML document meets the requirements of a particular DTD or schema – for example the ONIX for Books DTD and XSD. Special XML software tools are required to validate an XML document.
Vector image: A digital image represented as lines and shapes, such as a map, diagram or graph. SVG is a vector image format. Vector images can be scaled without losing quality – curves remain smooth at any size. cf raster image.
Vendor of record: See distributor.
Verso: See recto.
Volume rights: Loose term indicating the main rights to publish a book (or more generally, ‘exploit a work’), for example in hardback and paperback and possibly other formats. The rights may be limited to a particular language, a particular geographical territory, and might also be time-limited. See also rights.
W3C: World Wide Web Consortium, the body that controls many of the standards that underlie the technical workings of the internet, including HTML and XML.
Watermark: In digital rights management (DRM), a hidden or hard-to-remove pattern of unique data added to each individual copy of a product, so that the purchaser or licensee of each copy can be identified. Watermarking – sometimes called ‘social DRM’ – does not enforce constraints on usage of digital content, but discourages breaking those constraints by making the responsible party identifiable.
WAV: Audio file format most commonly used with Windows PCs, usually uncompressed. cf AAC, MP3 audio files.
WGS: Warengruppen Systematik, product category system used widely in the German book trade, combines subject coding with information about the product form. See also Thema, which is in use alongside WGS within the German book trade.
Wholesale model: See reseller model.
Wholesaler: Supply chain organization that holds a secondary stock of books. A wholesaler obtains stocks from a primary distributor and supplies stocks to retailers or other business-to-business customers. Wholesalers are typically non-exclusive – there may be several wholesalers competing to supply the retailer. Some wholesalers (or ‘Jobbers’) specialize in supplying the libraries or schools markets rather than the retailer market.
Widow: In typesetting, a partial or short line of text (eg the last line of a paragraph) which occurs at the top of a column or page. Typesetters and designers try to avoid widows. See also orphan.
Windowing: Movie industry release strategy where a movie is published on different media at different times (eg first a theatrical release in cinemas, then on Bluray and DVD, then subscription TV and finally free-to-air TV). Trade book publishers often follow a similar strategy with hardback, trade paperback, mass-market releases. cf day and date releases.
Windows‑1252: An 8-bit character encoding of around 215 characters, a superset of ASCII and Latin‑1 character sets, with a few additions such as curly quotes, en- and em-dashes, †, ƒ, ž. Used with the Windows operating system. The near equivalent character set on the Mac is called MacRoman, though the actual encoding of many characters is different.
WIPO: World Intellectual Property Organization, specialized agency of the United Nations concerned with international copyright, patents and trademarks. It originated in an organization charged with administration of the Berne Convention.
Wire stitch: Staple. A wire stitch through the middle of a set of folded sheets forms a simple booklet.
Work: Distinct intellectual or artistic creation, from which several products (or manifestations in <indecs> terms) may be derived; roughly synonymous with ‘title’, where hardback, paperback and e-book manifestations of that title are all versions of the same work. Textual works may be identified with an ISTC. Modifications to a work, such as translation, abridgement or significant revision (eg to create a new edition) or addition of further material create a new ‘Derived’ work. ONIX uses the <indecs> view of a work; cf FRBR, within which a work has a broader definition. A FRBR expression is the equivalent of an indecs work.
Work for hire: Normally, the creator of a creative work becomes the initial copyright holder. Work for hire is an arrangement whereby the employer of the creator, or the party that commissions a work, becomes the copyright holder.
X.12: See EDI.
XHTML: A slightly reformulated and stricter version of familiar HTML markup, differing in that it conforms to XML syntax. All tags must be properly closed and nested, and tags must be lower case.
XML: eXtensible Markup Language. Underlying technical standard for ONIX for Books syntax (see http://www.w3.org/TR/xml/), allows highly structured, granular documents, and makes data easily reusable. Often used to communicate data between databases. See also DTD and schema.
XML database: An alternative to a relational database, in which data is stored as a collection of XML documents, rather than being decomposed into individual tables, rows and columns. In some circumstances, can perform better than a relational model when there are very large numbers of dependent tables.
XSD: W3C XML Schema Language. See schema.
XSLT: eXtensible Stylesheet Language Transformations – language for defining how to process an XML document, for example to convert it from one DTD or schema to another, or into an XHTML format.
Yapp binding: Soft cover that extends a few millimetres beyong the edge of the book block (like hardbacks boards do). Binding style sometimes used for Bibles, soft-cover dictionaries, personal diaries. The edge of the cover is sometimes fitted with a zip fastener to keep the book closed.
YA: Young Adult book – intended to be read and enjoyed by adolescents (approximately 12–18 years old). Also refers to a book primarily intended for adults but considered suitable for mature 12–18 year olds.
Zip: Zipped and Gzipped data files are compressed to be smaller than the original data files, making them easier or quicker to send to a recipient. They can be decompressed (unzipped, gunzipped) by the recipient to recover the exact original data. The compression algorithm is the same, but Gzip is used for single files, whereas zip may be used on entire folders of files. Note that zipping or gzipping doesn’t greatly reduce the size of files that are already compressed, such as JPEGs or MP3s.

Checklist of ‘practical minimum set’ of data elements

It is common, with a standard as large and comprehensive as ONIX for Books, for implementors to ask what is the minimum set of metadata elements that it is necessary to support. This might seem to be a purely technical question – what is the minimum ONIX message you can construct that consists only of mandatory data elements. However, this technical minimum is useless – it contains no information about the product other than a single ISBN (or some other identifier). On the other hand, no ONIX data sender or recipient uses every ONIX data element. To a large degree, the question of the minimum set of metadata elements has to be answered by considering the business requirements of both sender and recipient of the data. And the minimum set suitable for a typical trade publisher or retail bookstore will differ from the minimum set designed to meet the needs of an academic publisher or educational bookseller.

Another approach to the idea of a ‘minimum set’ is to limit which codes from each codelist are supported. Recipients who can only use a subset of codes from a particular codelist should ensure there are sensible fallbacks in place for unsupported codes – they should not restrict which codes can be used by senders, but should map unsupported codes used in the data they receive to the nearest supported equivalent (or in some cases, unsupported codes could be treated as exceptions that require manual intervention).

The table below summarizes a practical minimum set of data elements that a data sender should be able to support, at least to cover the typical data recipient’s requirements for the most common types of product. For the most part this duplicates the summaries in rounded boxes throughout this Implementation and Best Practice Guide, though a few of the more specialist data elements have been dropped.

Omission from this list does not imply that a particular data supplier or recipient should simply ignore the element in question – it means only that the element is unlikely to be required by typical recipients or for common types of product. For example, the list below does not cater for collections nested within other collections (it omits <PartNumber> within <Collection>). Neither does it cater for religious texts, for e-book rentals, for the publication of conference proceedings, nor for the use of Block 3 to carry structured tables of contents, since these are not required in most implementations. Conversely, inclusion in this list does not imply a data supplier must implement a particular data element or composite – though data recipients should be wary where omitting support for one seemingly unimportant data element may change the interpretation of another important data element. For example, <ProductPart> and the whole of Group P.4 is unnecessary where multi-component products are not a consideration, and <SalesRestriction> is only required where products are retailer-exclusive. Ignoring <ProductPart> is largely benign, but ignoring <SalesRestriction> may change the interpretation of <SalesRights>. (Again, some unsupported data elements that do potentially change the interpretation of other data could be treated as exceptions requiring manual intervention.) The important point is that the minimum set of data elements for a particular implementation is highly dependent on the nature of the products the data supplier is describing, and on the purpose the description is intended for.

Some ONIX national groups have also defined expectations for the minimum set to be used within a particular country. Importantly, such sets are minimums, and do not prevent a data supplier delivering richer information – nor do they prevent recipients making use of this richer data when it is supplied.

For an alternative ‘minimum’ set of data elements focused on a specific business requirement, see ONIX for ISBN Registration, a subset or ‘profile’ of ONIX for Books intended solely for communication between publishers and national ISBN Agencies, that carries only that metadata required for registration of ISBNs – omitting all details of collateral material, content details and product supply details since they are irrelevant to the process of ISBN registration, but making mandatory a few elements that are optional in ONIX for Books.

data element checklist
#	Reference name	Short tag	Notes
Message
	`<?xml version="1.0"?>`	`<?xml version="1.0"?>`	also include encoding
	`<ONIXMessage release="3.0">`	`<ONIXmessage>`
Message header
	`. <Header>`	`<header>`
	`. . <Sender>`	`<sender>`
	`. . . <SenderIdentifier>`	`<senderidentifier>`	if available
	`. . . <SenderName>`	`<x298>`
	`. . . <ContactName>`	`<x299>`
	`. . . <EmailAddress>`	`<j272>`
	`. . <Addressee>`	`<addressee>`	if message is tailored
	`. . . <AddresseeName>`	`<x300>`
	`. . <MessageNumber>`	`<m180>`	if delta update
	`. . <SentDateTime>`	`<x307>`
Product record
	`. <Product>`	`<product>`
Group P.1
	`. . <RecordReference>`	`<a001>`
	`. . <NotificationType>`	`<a002>`
	`. . <RecordSourceType>`	`<a194>`	if aggregated data
	`. . <RecordSourceName>`	`<a197>`	if aggregated data
Group P.2
	`. . <ProductIdentifier>`	`<productidentifier>`
Block 1
	`. . <DescriptiveDetail>`	`<descriptivedetail>`
Group P.3
	`. . . <ProductComposition>`	`<x314>`
	`. . . <ProductForm>`	`<b012>`
	`. . . <ProductFormDetail>`	`<b333>`	if relevant
	`. . . <ProductFormFeature>`	`<productformfeature>`	especially for digital products, safety warnings, paper certifications etc
	`. . . <ProductPackaging>`	`<b225>`	if product is packaged
	`. . . <PrimaryContentType>`	`<x416>`	if not simply textual
	`. . . <ProductContentType>`	`<b385>`	if not simply textual
	`. . . <Measure>`	`<measure>`	if product is physical
	`. . . <CountryOfManufacture>`	`<x316>`	if product is physical
	`. . . <EpubTechnicalProtection>`	`<x317>`	if product is not physical
	`. . . <EpubUsageConstraint>`	`<epubusageconstraint>`	if product is not physical
	`. . . <MapScale>`	`<b063>`	if cartographic
Group P.4
	`. . . <ProductPart>`	`<productpart>`	if a multi-item product
	`. . . . <PrimaryPart/>`	`<x457/>`
	`. . . . <ProductIdentifier>`	`<productidentifier>`
	`. . . . <ProductForm>`	`<b012>`
	`. . . . <ProductFormDetail>`	`<b333>`	if relevant
	`. . . . <NumberOfItemsOfThisForm>`	`<x322>`	or…
	`. . . . <NumberOfCopies>`	`<x323>`
	`. . . . <CountryOfManufacture>`	`<x316>`	if product part is physical
Group P.5
	`. . . <Collection>`	`<collection>`
	`. . . . <CollectionType>`	`<x329>`
	`. . . . <CollectionIdentifier>`	`<collectionidentifier>`	even if only proprietary
	`. . . . <TitleDetail>`	`<titledetail>`
	`. . . . . <TitleType>`	`<x330>`
	`. . . . . <TitleElement>`	`<titleelement>`
	`. . . . . . <SequenceNumber>`	`<b034>`	if title has many elements
	`. . . . . . <TitleElementLevel>`	`<x409>`
	`. . . . . . <TitleText>`	`<b203>`	if legacy data cannot differentiate titles with prefixes, but…
	`. . . . . . <NoPrefix/>`	`<x501>`	or…
	`. . . . . . <TitlePrefix>`	`<b030>`	plus…
	`. . . . . . <TitleWithoutPrefix>`	`<b031>`	is better
	`. . . . . . <Subtitle>`	`<b029>`
	`. . . . . <TitleStatement>`	`<x478>`	if simple concatenation is insufficient
	`. . . <NoCollection/>`	`<x411/>`
Group P.6
	`. . . <TitleDetail>`	`<titledetail>`
	`. . . . <TitleType>`	`<x330>`
	`. . . . <TitleElement>`	`<titleelement>`
	`. . . . . <SequenceNumber>`	`<b034>`	if title has many elements
	`. . . . . <TitleElementLevel>`	`<x409>`
	`. . . . . <PartNumber>`	`<x410>`
	`. . . . . <YearOfAnnual>`	`<b020>`
	`. . . . . <TitleText>`	`<b203>`	if legacy data cannot differentiate titles with prefixes, but…
	`. . . . . <NoPrefix/>`	`<x501>`	or…
	`. . . . . <TitlePrefix>`	`<b030>`	plus…
	`. . . . . <TitleWithoutPrefix>`	`<b031>`	is better
	`. . . . . <Subtitle>`	`<b029>`
	`. . . . <TitleStatement>`	`<x478>`	if simple concatenation is insufficient
Group P.7
	`. . . <Contributor>`	`<contributor>`
	`. . . . <SequenceNumber>`	`<b034>`
	`. . . . <ContributorRole>`	`<b035>`
	`. . . . <NameIdentifier>`	`<nameidentifier>`	even if only proprietary
	`. . . . <PersonNameInverted>`	`<b037>`	or…
	`. . . . <TitlesBeforeNames>`	`<b038>`	and…
	`. . . . <NamesBeforeKey>`	`<b039>`	and…
	`. . . . <PrefixToKey>`	`<b247>`	and…
	`. . . . <KeyNames>`	`<b040>`	and…
	`. . . . <NamesAfterKey>`	`<b041>`	(if any eastern-style names)
	`. . . . <CorporateNameInverted>`	`<x443>`
	`. . . . <BiographicalNote>`	`<b044>`
	`. . . . <UnnamedPerson>`	`<b249>`
	`. . . <ContributorStatement>`	`<b049>`
	`. . . <NoContributor/>`	`<n339/>`
Group P.9
	`. . . <EditionType>`	`<x419>`
	`. . . <EditionNumber>`	`<b057>`
	`. . . <EditionStatement>`	`<b058>`
	`. . . <NoEdition/>`	`<n386/>`
Group P.10
	`. . . <Language>`	`<language>`	of text, and of original if product is translated
Group P.11
	`. . . <Extent>`	`<extent>`
	`. . . <AncillaryContent>`	`<ancillarycontent>`
Group P.12
	`. . . <Subject>`	`<subject>`	subject schemes and keywords
	`. . . <NameAsSubject>`	`<nameassubject>`
Group P.13
	`. . . <Audience>`	`<audience>`
	`. . . <AudienceRange>`	`<audiencerange>`	if children’s or education product
Block 2
	`. . <CollateralDetail>`	`<collateraldetail>`
Group P.14
	`. . . <TextContent>`	`<textcontent>`
	`. . . . <TextType>`	`<x426>`
	`. . . . <ContentAudience>`	`<x427>`
	`. . . . <Text>`	`<d104>`	ideally with XHTML markup
	`. . . . <TextAuthor>`	`<d107>`	if text is review or endorsement
	`. . . . <ContentDate>`	`<contentdate>`
Group P.15
	`. . . <CitedContent>`	`<citedcontent>`
	`. . . . <CitedContentType>`	`<x430>`
	`. . . . <ContentAudience>`	`<x427>`
	`. . . . <SourceTitle>`	`<x428>`
	`. . . . <ResourceLink>`	`<x435>`
	`. . . . <ContentDate>`	`<contentdate>`
Group P.16
	`. . . <SupportingResource>`	`<supportingresource>`
	`. . . . <ResourceContentType>`	`<x436>`
	`. . . . <ContentAudience>`	`<x427>`
	`. . . . <ResourceMode>`	`<x437>`
	`. . . . <ResourceFeature>`	`<resourcefeature>`	for captions, credits etc
	`. . . . <ResourceVersion>`	`<resourceversion>`
	`. . . . . <ResourceForm>`	`<x441>`
	`. . . . . <ResourceVersionFeature>`	`<resourceversionfeature>`	for file types, pixel sizes, running times etc
	`. . . . . <ResourceLink>`	`<x435>`
	`. . . . . <ContentDate>`	`<contentdate>`
Group P.17
	`. . . <Prize>`	`<prize>`
	`. . . . <PrizeName>`	`<g126>`
	`. . . . <PrizeYear>`	`<g127>`
	`. . . . <PrizeCode>`	`<g129>`
Block 4
	`. . <PublishingDetail>`	`<publishingdetail>`
Group P.19
	`. . . <Imprint>`	`<imprint>`
	`. . . . <ImprintIdentifier>`	`<imprintidentifier>`	if available
	`. . . . <ImprintName>`	`<b079>`
	`. . . <Publisher>`	`<publisher>`
	`. . . . <PublishingRole>`	`<b291>`
	`. . . . <PublisherIdentifier>`	`<publisheridentifier>`	if available
	`. . . . <PublisherName>`	`<b081>`
	`. . . <CityOfPublication>`	`<b209>`
	`. . . <CountryOfPublication>`	`<b083>`
Group P.20
	`. . . <PublishingStatus>`	`<b394>`
	`. . . <PublishingDate>`	`<publishingdate>`
Group P.21
	`. . . <SalesRights>`	`<salesrights>`
	`. . . . <SalesRightsType>`	`<b089>`
	`. . . . <Territory>`	`<territory>`
	`. . . . <SalesRestriction>`	`<salesrestriction>`	if product is not for general distribution
	`. . . <ROWSalesRightsType>`	`<x456>`
Block 5
	`. . <RelatedMaterial>`	`<relatedmaterial>`
Group P.22
	`. . . <RelatedWork>`	`<relatedwork>`
	`. . . . <WorkRelationCode>`	`<x454>`
	`. . . . <WorkIdentifier>`	`<workidentifier>`	even if only proprietary
Group P.23
	`. . . <RelatedProduct>`	`<relatedproduct>`
	`. . . . <ProductRelationCode>`	`<x455>`
	`. . . . <ProductIdentifier>`	`<productidentifier>`
Block 6
	`. . <ProductSupply>`	`<productsupply>`
Group P.24
	`. . . <Market>`	`<market>`	unless only a single market
	`. . . . <Territory>`	`<territory>`
	`. . . . <SalesRestriction>`	`<salesrestriction>`
Group P.25
	`. . . <MarketPublishingDetail>`	`<marketpublishingdetail>`	unless only a single market
	`. . . . <PublisherRepresentative>`	`<publisherrepresentative>`
	`. . . . . <AgentRole>`	`<j402>`
	`. . . . . <AgentIdentifier>`	`<agentidentifier>`
	`. . . . . <AgentName>`	`<j401>`
	`. . . . <MarketPublishingStatus>`	`<j407>`
	`. . . . <MarketDate>`	`<marketdate>`
Group P.26
	`. . . <SupplyDetail>`	`<supplydetail>`
	`. . . . <Supplier>`	`<supplier>`
	`. . . . . <SupplierRole>`	`<j292>`
	`. . . . . <SupplierIdentifier>`	`<supplieridentifier>`
	`. . . . . <SupplierName>`	`<j137>`
	`. . . . . <TelephoneNumber>`	`<j270>`
	`. . . . . <EmailAddress>`	`<j272>`
	`. . . . <ReturnsConditions>`	`<returnsconditions>`	for physical products
	`. . . . <ProductAvailability>`	`<j396>`	also include datestamp
	`. . . . <SupplyDate>`	`<supplydate>`
	`. . . . <PackQuantity>`	`<j145>`
	`. . . . <UnpricedItemType>`	`<j192>`	or…
	`. . . . <Price>`	`<price>`
	`. . . . . <PriceType>`	`<x463>`
	`. . . . . <PriceQualifier>`	`<j261>`	if relevant
	`. . . . . <DiscountCoded>`	`<discountcoded>`	or…
	`. . . . . <Discount>`	`<discount>`	if discounts are relevant
	`. . . . . <PriceAmount>`	`<j151>`
	`. . . . . <Tax>`	`<tax>`	if price includes tax
	`. . . . . <CurrencyCode>`	`<j151>`
	`. . . . . <Territory>`	`<territory>`
	`. . . . . <PriceDate>`	`<pricedate>`
	`. . . . . <PrintedOnProduct>`	`<x301>`	for physical products

ONIX codelists and internationalization

Why does ONIX use codelists, where the codes embedded in data files are ‘BB’, ‘BC’, ‘01’, ‘02’ and the like, instead of apparently more understandable controlled vocabulary terms like ‘Hardback’, ‘Paperback’ and so on? ONIX is specifically intended to support a truly global book trade, and uses codes to provide a measure of explicit language-independence. Codelists consist of tables with three main columns:

Sample codelist
code	label	notes
BA	Book
BB	Hardback	Hardback or cased book.
BC	Paperback	Paperback, softback or limp-bound book.
BD	Loose-leaf	Loose-leaf book, individual sheets, optionally with updateable binder.

each row of the codelist is a concept;
the first column is the code or notation for each concept – and it’s this notation that is embedded in the ONIX message data;
the second column is a shortish preferred label for each concept – the label is often suitable for display, eg in an application menu or on a web page;
the third column is a longer definition or explanatory editorial note or scope note for each concept, in the event that the label is not enough to ensure the concept is defined adequately.

The concept and its notation are language-independent. Conventionally, the label and notes columns are in English, simply because EDItEUR’s documentation is created in English – but occasionally, a few concepts are labelled in some other language in which they were first expressed (eg Dwarsligger, Sonderausgabe), usually with an English equivalent given in the notes (though sometimes just treated as a loanword). Conceptually at least, there could be many pairs of label and note columns, each pair for a different language. So ‘BB’ is linked to the label ‘Hardback’ in English, but could equally well be linked to ‚Gebundene ausgabe‘ in German or to ‘精装书’ in Chinese – so long as the concept is unchanged, the labelling and notes can be translated into any language. There might also be alternative labels and synonyms within the same language – ‘Hardcover’ is more common than ‘Hardback’ in North American usage, for example, although the words are largely interchangeable. In this way, a message sent from an American publisher to a German or Chinese retailer will contain the code ‘BB’, which specifies the concept expressed as ‘Hardcover’ to the publisher and the identical concept expressed as ‚Gebundene ausgabe‘ or ‘精装书’ to the retailer.

The codelists are published in English, but could be translated into any language, provided the concept expressed by each row is unchanged. Some ONIX National Groups may produce translations for languages other than English.

A particular IT system may use any labels that are familiar to the users of that system – in English, ‘hardback’, ‘hardcover’, and (in some contexts) ‘cased’ are synonyms, and any synonym could be used in place of the preferred label given in the codelists, providing once again that the concept expressed is unchanged.

As an aside, it’s also worth noting that the codes (the notations) in ONIX are all limited to the basic ASCII character set – as indeed are all other elements of the ONIX syntax such as tag and attribute names – because most other character sets and encodings contain ASCII as a subset and no special care is needed to include ASCII in XML files. This limitation doesn’t apply to the labels or the notes, as they never appear in a message.

The terms in some lists have an implicit underlying hierarchy – that is, some terms are more general and others are more refined concepts. List 150 is a good example, where the code BA (Book) is broader and codes BB, BC, BE (Hardback, Paperback, Spiral bound) are narrower, more specialized terms. While List 150 makes the underlying taxonomy more or less visible in the codes, other lists do not. These semantic relationships may be made explicit in future.

The internationalization approach for ONIX codelists – and some of the terminology above – is equivalent to that in SKOS (Simple Knowledge Organization System, see http://www.w3.org/2004/02/skos/). The ONIX codelists may be published as a SKOS concept scheme in the future.

Development and support lifecycle

The status of a particular release of ONIX for Books – say of Release 3.0.2 – follows an orderly development and support lifecycle.

Active development:
- the schema is under active development, and will be extended or enhanced to deliver new functionality as new business requirements are identified, providing they can be met without introducing incompatibilities with existing implementations of the release;
- new codes and new codelists will be introduced as necessary. Revisions of the codelists are generally published quarterly, and this is the primary means of adding new functionality to the release;
- changes to schema and codelists will be discussed with ONIX National Groups, must be approved by the ONIX International Steering Committee – the primary governance body for the standard – and will be fully documented;
- changes to the schema imply a new minor version or sub-version (also known as a revision), depending on the scope of the additional functionality. Release 3.1 would be a minor version increment after 3.0, whereas 3.0 revision 1 (also known as 3.0.1) is a sub-version increment from 3.0 (more specifically, from 3.0.0). A new minor version would aim to retain a very high degree of forwards and backwards compatibility, but might include limited incompatible changes – new mandatory elements or removal of deprecated elements – into the schema where necessary to support new functionality. A new sub-version would always retain full backwards and forwards compatibility, and thus cannot introduce new mandatory elements into the schema or remove elements entirely (though they may be deprecated);
  - for a new sub-version, full backwards and forwards compatibility means that no additional development work is required of either data suppliers or recipients, unless they wish to support any new optional data elements added to the schema (this forwards compatibility assumes recipients can correctly ignore unknown elements in messages from data suppliers who have implemented the new optional elements in a later sub-version). Note that complete forwards compatibility is not always possible, and this would trigger a minor version change;
  - full backwards and forwards compatibility also implies that new sub-versions should not change the interpretation of existing data conforming to the older version, for example by ascribing meaning to the absence of new data elements);
  - for a new minor version, any breaking changes should be extremely limited in scope;
  - another difference between a minor version and a sub-version is that sub-versions completely replace the equivalent earlier sub-version in all respects, whereas minor versions retain separate identities (ie a minor version is a separate development branch and thus has a separate development and support status). That is, for practical purposes, version 3.0.1 no longer exists after release of 3.0.2, whereas 3.1 (or the latest sub-version such as 3.1.1) would still be maintained after release of 3.2;
  - a new minor version would usually imply the old minor version is moved from ‘active development’ to ‘feature complete’;
- major new functionality requirements that cannot be met without introducing significant incompatible changes imply a new release and an incremented major version number (ie some future release 4.0 would be a major version increment after 3.x);
Feature complete:
- the schema will not be extended, whether new requirements can be accommodated or not;
- however, corrections, bugfixes and minor workarounds will still be developed as necessary;
- new codes (but generally not new codelists) will be added as necessary. New codelists may be added where they are effectively ‘shared’ with later releases, and the effect of such changes will be taken into account during the development process;
- the documentation is essentially frozen, but will remain easily available and will be updated to correct errors where necessary;
- all users are encouraged to migrate to a more recent release;
Legacy (extended use):
- the schema is frozen, and corrections, bugfixes and minor workarounds will not be developed;
- new codes and codelists will not be added – except possibly as result of developing later versions that use the same codelists (the effect of such developments on the extended use version will not be taken into particular account during the development process);
- documentation and any online schemas will be archived, though they may remain available upon request;
- all users are very strongly advised to migrate to a more recent release;
Obsolete;
- no support available.

Note that none of these stages are defined by reference to a ‘current’ version of ONIX. At the time of writing, both Release 2.1 and Release 3.0 are ‘current’ in that they are in widespread use, but 2.1 is in the ‘legacy’ phase of the lifecycle. Only ONIX 3.0 is recommended for new developments. No version of ONIX ‘stops working’ at any stage in this process, but the model guides the orderly reduction in EDItEUR support effort for superseded versions and allows implementors to plan and budget for future development.

The status of various ONIX releases (as at the beginning of 2015) is as follows:

ONIX 3.0: active development, latest revision 2 (version 3.0.2);
ONIX 2.1: legacy (extended use), latest revision 03 (or revision 04 in Japan only);
ONIX 2.0: obsolete;
ONIX 1.x: obsolete.

Outside Japan, ONIX 2.1 was ‘feature complete’ from 2008, when the decision to develop ONIX 3 was made – and in most countries, it was effectively feature complete since the release of ONIX 2.1 revision 02 in June 2004 (since revisions 03 and 04 were intended principally for Spain, Australia and Japan). With the agreement of the ONIX International Steering Committee, it was announced in 2012 that all revisions of ONIX 2.1 would be considered ‘legacy’ from the end of 2014. At the same time, the status of ONIX 2.0 was revised to obsolete. ONIX 2.1 users (and any remaining ONIX 2.0 users) are strongly encouraged to ensure they have a plan in place to migrate to ONIX 3.0.

The ONIX development and support lifecycle is based on the versioned staged maintenance model presented in Software maintenance and evolution: a roadmap, Bennett and Rajlich, Proceedings of the Conference on The Future of Software Engineering, ICSE ’00, (ACM, ISBN 1-58113-253-0, DOI: 10.1145/336512.336534).

Checklist for establishing a new data feed

Prior to the widespread use of ONIX messages, data suppliers often had to create unique data files – in different formats – for their various supply chain partners. Spreadsheet files, comma- or tab-separated files, with different columns, with the meaning of the data in those columns often ill-defined, and with unstated limitations on what each recipient might be able to use inevitably led to imperfect and costly-to-maintain data exchanges.

ONIX is intended to eliminate this variation (and thus reduce costs), by providing semantic consistency (standardising the nature and meaning of the data to be included in each ‘column’ – each data element) and a standardized syntax (the underlying XML structure). Data suppliers should in principle be able to create a single data output process to feed all their supply chain partners. The Product record for a particular product should not depend on whom that Product record is sent to.

But in real-world use, setting up a data feed with a new partner is not quite a matter of agreeing to use ONIX 3.0 and adding a new delivery address to a list of FTP sites. Partners need to:

agree the selection criteria for records to be included in feed;
- how far ahead should the scope extend for forthcoming products?
  - around six months is likely to be typical. It is best practice to ensure that all key data is available at least four months prior to publication;
- should products that the recipient cannot sell be included?
  - trade-only products such as multi-copy packs or point-of-sale material – a data recipient retailer might be able to purchase but not sell these items;
  - products that are exclusive to other retailers, other sales channels or other territories – the data recipient might not be able to purchase or sell these items. In many cases, the need for commercial confidentiality would preclude their inclusion prior to publication, but their inclusion post-publication enables better customer service (or used copy trading). Conversely, are products that are exclusive to the recipient included?
- should already-obsolete (ie out of print) products be included?
  - for example, to facilitate used book trading or to improve customer service;
agree the overall character set and encoding;
check the method used to embed any markup within certain data elements (XHTML markup, or HTML with either CDATA or escaping);
confirm whether Reference names or Short tags will be used;
- an XSLT-based Tagname Converter is available from http://www.editeur.org/93/Release-3.0-Downloads/#Tag%203.0 if it proves necessary to translate messages between Reference names and Short tags (or vice versa);
agree the file collection/delivery method, for example;
- ‘push’ or ‘pull’ model (ie use of a server controlled by the recipient, or by the sender);
- file transfer method (eg FTP, SFTP, FTPS, HTTP, HTTPS…);
- server address details and account credentials;
- whether the file will be compressed (‘zipped’) or not;
- the file naming convention;
agree the supply mode – full feed always, or initial full feed followed by delta files or block-level updates;
agree the frequency of new messages – as needed, or on a regular intra-day, daily or weekly schedule – and the procedures to be followed when a message is missed or cannot be delivered;
agree whether the ONIX Acknowledgement Message will be used, and whether it would be used simply to confirm message receipt or as part of a more comprehensive query and error reporting message choreography;
agree whether supporting resources such as cover images and sample files will be downloaded by the recipient from a URL delivered in the ONIX message, or whether a parallel feed of collateral files is required (with only filenames supplied in the ONIX message);
agree whether ongoing post-publication updates of price and availability will be provided as part of the ONIX data feed, or whether separate price and availability updates will be delivered using another method (eg via an X.12 or EDIFACT PRICAT message);
discuss which data elements will be used by the recipient, and how they will be presented in both internal and consumer-facing contexts (note that this does not imply that the content of the Product record needs to be configured for each recipient, as recipients should simply ignore elements they do not use);
confirm the Codelist issue in use, and the expectations of both sender and recipient when future Codelist updates are issued by EDItEUR. Codelist updates occur typically three or four times per year;
confirm the recipient can comply with Announcement, Embargo, Valid From/To dates, Content audience limitations, display of required credits and other similar limitations or requirements embedded in the ONIX;
confirm whether the recipient imposes any non-standard requirements of their own. Recipients should strenuously avoid imposing any such non-standard limitations, since non-standard messages impose extra costs on the supply chain. But where they are unavoidable – for example because of legacy IT systems – they should be clearly documented, and ideally, a development roadmap or timetable established to eliminate them);
agree whether the implied license to use supplied data is enough, or whether a formal license covering use of the data by the recipient is needed;
- a formal license is recommended for modification and/or redistribution of the data by the recipient, or where third-party API access to the data is provided by the recipient;
agree whether industry norms regarding timeliness of data delivery from sender, and speed of processing by recipient are enough, or whether a formal service level agreement is required;
- organizations including BISG and BIC have produced guidelines for service levels within their specific markets which set out expectations for both senders and recipients;
agree procedures for occasional emergency notification of required changes (eg in response to legal or product safety issues).

Beyond this checklist, using ONIX does not remove the need for end-to-end testing. However, the scope of that testing and the likelihood of serious errors is much reduced because – in most cases – the generation of the ONIX message data will not be new as it will have been in use by the sender with other recipients, and the parsing, insertion and update process will be established within the recipient organization because it too will have been in use with other senders.

Character sets and character encodings

The ONIX Specification lists the basic range of characters that can be incorporated into an ONIX message without any special care. This list comprises the printable ASCII characters – with the exception of the ‘&’ and ‘<’ characters, which must be encoded as ‘&’ and ‘<’ when included in data. (Of course, they are used un-encoded, as ‘&’ and ‘<’, as part of the XML markup.)

Any characters beyond this basic set can be incorporated in ONIX data one of two ways, using either Unicode numerical character references or a message-wide character encoding. Either method enables any character in the full Unicode character set (a repertoire of more than 100,000 characters from all the major writing systems of the world) to be included in ONIX data. (Having said this, the ability to display any of these characters on screen is dependent on the fonts installed on a particular device. Modern operating systems provide broad but not entirely complete font support by default.)

It may be useful to think of a numerical character reference as a way of encoding any one of the Unicode characters beyond the basic set as plain text. The character can be included in ONIX data by encoding it as ‘&#xn;’ where n is the Unicode character number in hexadecimal (in base 16). Effectively, the single Unicode character is encoded into a series of plain text characters – ampersand, hash, the letter x, a series of digits and a semi-colon. Alternatively, use ‘&#n;’ where n is the character number in ordinary decimal (base 10).

If numerical character references are a text encoding of Unicode character numbers, a message-wide character encoding is a binary encoding of the same character numbers. Fundamentally, all text is stored as a series of numbers. Each Unicode character has a 32-digit binary number, and the most basic encoding is simply to use that number. But this means that plain text files become very large, each character using four bytes rather than just one or two. UTF‑16 and UTF‑8 are mathematical ways of encoding the same numbers so that most characters take only two or even just a single byte. Some more rarely used characters require more than two bytes – the -8 and -16 refer to the minimum number of bits used).

encodings of the characters ‘é’, ‘ž’ and ‘д’
desired character in metadata	é	ž	д

numerical character reference	text in file
decimal	`é`	`ž`	`д`
hexadecimal	`é`	`ž`	`д`

binary encoding	binary data in file (in hexadecimal)
UTF-8	`c3 a9`	`c5 be`	`d0 b4`
UTF-16LE	`e9 00`	`7e 01`	`34 04`
UTF-16BE	`00 e9`	`01 7e`	`04 34`
Latin-1 (ISO 8859-1)	`e9`	— ¹	—
Latin-9 (ISO 8859-15)	`e9`	`b8`	—
Windows-1251	—	—	`e4`
Windows-1252	`e9`	`9e`	—
MacRoman	`8e`	—	—

named character entity	text in file
(not valid in ONIX 3.0, used in 2.1)	`é`	`&zcaron;`	`&dcy;`

¹ dash indicates the character cannot be represented in this encoding

UTF‑8 and UTF‑16 are encodings that allow any Unicode character number to be encoded. Most modern operating systems and programming frameworks use one or the other by default, and UTF‑8 is the preferred encoding for ONIX, particularly for messages exchanged internationally. In contrast, Latin‑1, Windows‑1252 and MacRoman are common legacy encodings that can only encode a small, Latin-focused subset of the Unicode character repertoire. So while each of the three can encode the ‘é’ character, the character ‘ž’ cannot be encoded using Latin‑1 – it is not included in the Latin‑1 repertoire – and none can encode the (Cyrillic) letter ‘д’. Latin‑9, an update of Latin‑1, can encode ‘ž’. In contrast, Windows‑1251 – a Cyrillic-focused subset – can encode ‘д’, but not ‘é’ or ‘ž’.

: This illustrates the difference between a character set and a character encoding. The difference is clear-cut with Unicode (a character set, or repertoire) and UTF‑8 (a way of encoding the characters in that set as sequences of numbers), and more blurred with Latin‑1 or Windows‑1252, which define both a limited character set and a way of encoding that set of characters as numbers.

The relatively small repertoire of around 200 Latin script characters available in Windows‑1252 or Latin‑1 makes them more or less suitable for text in most Western European languages. But they are unsuitable for many other languages which use the Latin script as they require characters outside the limited repertoire, and cannot be used for languages that use other scripts (Cyrillic, Arabic etc). There are many other encodings tailored for other languages and scripts, each in effect enabling the use of a different subset of the full Unicode repertoire.

The fact that a single character like ‘é’ can be encoded in different ways means that unless the encoding is known, a character can be misinterpreted. A ‘ž’ character stored as the hexadecimal number e9 using the Windows‑1252 encoding, then read as if it were using the MacRoman encoding would be misinterpreted as ‘û’. And the same e9 would cause an error if read as if it were Latin‑1 or UTF‑8, because e9 doesn’t represent any character in those encodings. Naturally, text can be read (with the correct encoding) then converted to a different encoding, but only if the repertoire of characters in the text is limited and includes only characters that are within the repertoire of the new encoding – a single ‘ž’ in the text would prevent conversion to Latin‑1 (though some software might silently substitute ‘z’ and allow conversion to go ahead). So software developers need to be aware how their applications encode textual data, and applications should control both the repertoire of characters used and the encoding used to store the data. This control needs to be maintained end-to-end, from the application used to create, store and manage the data, through the ONIX message itself, to the application or website used by the eventual data recipient.

An XML message can contain an encoding declaration to ensure the recipient of the data can interpret the content correctly, so an application that uses the Windows‑1252 encoding must include the following declaration in any ONIX message:

: <?xml version="1.0" encoding="Windows-1252"?>

The recipient can then ensure text characters in the data are interpreted correctly, or perform a controlled conversion to another encoding if necessary.

: If no encoding is declared, the default is UTF‑8 or UTF‑16 (XML software should make an automatic choice). However, it is best practice to declare the encoding, even if it is UTF‑8 or UTF‑16. And because UTF‑16 comes in two distinct flavors – UTF‑16BE and UTF‑16LE – you should declare which one it is (and you should omit any ‘byte order mark’).

Reference list of allowed HTML / XHTML tags

Recommended

It is strongly recommended that HTML and XHTML tags are limited to this small set
paragraphs and line breaks	`<p>`	`<br />`
emphasis	`<strong>`	`<em>`	`<b>`	`<i>`
bulleted and numbered lists	`<ul>`	`<ol>`	`<li>`
sub- and superscript	`<sub>`	`<sup>`
definition lists	`<dl>`	`<dt>`	`<dt>`
simple glosses	`<ruby>`	`<rb>`	`<rp>`	`<rt>`

Note that ONIX ruby support is based on the structure of XHTML 1.1;

ruby tags are not valid in XHTML 1.0, but modern browsers will cope with them;
ONIX does not support the full HTML5 <ruby> syntax. The <rb> tag is not part of HTML5 or XHTML5, but is required in ONIX and in practice, modern browsers will cope with it. HTML5 also allows multiple <rt> elements within a single <ruby> element, but this is invalid in ONIX.

The ‘outermost’ HTML / XHTML tags within an ONIX element that accepts HTML / XHTML should be ‘block-level‘ tags. Of the recommended tags, only <p> and the three list tags <ul>, <ol> and <dl> are block level. So, of these four:

<Text textformat="05">This is <strong>incorrect</strong>, as there are no outermost tags.</Text>

<Text textformat="05"><li>This is <strong>incorrect</strong>, as the outermost tags are not block level.</li></Text>

<Text textformat="05"><p>This is <strong>correct</strong>.</p></Text>

<Text textformat="05"><p>This is <strong>correct</strong>.</p><ul><li>And so is this.</li></ul></Text>

only the third and fourth examples are correct. The first has no ‘outermost’ XHTML tags, and the outermost tags in the second example are not block-level tags. As shown in the last example, the marked-up text does not have to be enclosed within in a single block-level XHTML or HTML element. A mix of block-level tags meets the requirements.

Allowed

These tags are allowed in ONIX 3.0, but not recommended
`<h1>`	`<h2>`	`<h3>`	`<h4>`	`<h5>`	`<h6>`
`<table>`	`<caption>`	`<thead>`	`<tbody>`	`<tfoot>`
`<tr>`	`<th>`	`<td>`	`<colgroup>`	`<col>`
`<div>`	`<span>`	`<blockquote>`	`<pre>`
`<address>`	`<cite>`	`<dfn>`	`<abbr>`	`<q>`	`<small>`
`<samp>`	`<code>`	`<kbd>`	`<var>`
`<a>`	`<img>`	`<map>`	`<area>`	`<bdo>`	`<hr />`

HTML attributes such as style should be avoided.

Only <h1> to <h6>, <div>, <table>, <address>, <blockquote>, <pre> and <hr> are block-level elements.

These tags are also allowed, but not recommended
`<acronym>`	`<big>`	`<tt>`
`<rbc>`	`<rtc>`

They cannot be used by recipients using HTML5 / XHTML5. None are block-level.

Not allowed

These tags are not allowed
`<menu>`	`<dir>`	`<isindex>`
`<basefont>`	`<rfont>`
`<strike>`	`<u>`	`<s>`	`<center>`
`<iframe>`	`<noframes>`

Although they are part of HTML 4.01 and XHTML 1.0 and 1.1 Transitional, they are excluded from XHTML 1.0 and 1.1 Strict on which the ONIX subset is based.

These tags are not allowed
`<html>`	`<head>`	`<body>`
`<title>`	`<base>`	`<meta>`	`<link>`	`<style>`
`<script>`	`<noscript>`	`<object>`	`<param>`	`<applet>`
`<form>`	`<label>`	`<input>`	`<select>`	`<optgroup>`	`<option>`
`<textarea>`	`<fieldset>`	`<legend>`	`<button>`
`<ins>`	`<del>`

They are excluded by the ONIX prohibitions on tags that may not appear within <body>, tags for embedded objects, forms, scripting and document revision.

These tags are not allowed, as they are not part of HTML 4.01 or XHTML 1.1
`<header>`	`<footer>`	`<nav>`	`<section>`	`<article>`	`<aside>`
`<details>`	`<summary>`
`<figure>`	`<figcaption>`	`<meter>`	`<progress>`
`<time>`	`<wbr>`	`<mark>`	`<bdi>`
`<canvas>`	`<audio>`	`<video>`	`<source>`	`<embed>`	`<track>`
`<datalist>`	`<keygen>`	`<output>`	`<command>`	`<dialog>`

These tags are valid only in HTML5 / XHTML5.

Reference list of integer and real data elements

The Specification does not explicitly define numeric data elements as real or integer values. However, there are common-sense limitations – you cannot have a negative number of illustrations or a map scale of zero – and the XML schema implements stricter checks on numeric values as listed.

Integers

Positive integer (1, 2, 3…)
`<BatchQuantity>`	`<MinimumOrderQuantity>`
`<ConferenceNumber>`	`<NumberOfCopies>`
`<EditionNumber>`	`<NumberOfItemsOfThisForm>`
`<FreeQuantity>`	`<NumberOfPages>`
`<LatestReprintNumber>`	`<PackQuantity>`
`<MapScale>`	`<PositionOnList>`
`<MessageNumber>`	`<SequenceNumber>`
`<MessageRepeat>`

Positive integer or zero (0, 1, 2, 3…)
`<CBO>`	`<OnOrder>`
`<Number>`	`<OrderTime>`
`<NumberOfIllustrations>`

Integer (…−3, −2, −1, 0, 1, 2, 3…)
`<OnHand>`	`<Rate>`

Real numbers

Positive decimal (> 0)
`<ExtentValue>`	`<PriceAmount>`
`<Measurement>`	`<TaxableAmount>`

Positive decimal or zero (≥ 0)
`<DiscountAmount>`	`<TaxAmount>`
`<Quantity>`	`<ToQuantity>`

Percent decimal (≥ 0 and ≤ 100)
`<DiscountPercent>`	`<TaxRatePercent>`
`<Percent>`

ONIX Acknowledgement message

The ONIX for Books Acknowledgement Format Specification, released January 2015, is a separate and optional message intended to be sent by the recipient of an ONIX message to the data supplier in response to receipt of a standard ONIX for Books message. It allows an ONIX for Books recipient to:

confirm receipt of the original ONIX message;
report to the original sender a summary of Product records processed and updated into the recipient’s database;
report details of any errors encountered, or any queries about the product data supplied; or
return to the sender details of proprietary identifiers asigned by the recipient.

The Acknowledgement message can form part of a ‘choreography’ of messages between sender and recipient (say between publisher and data aggregator, or between distributor and retailer). For example, by agreement, the absence of an Acknowledgement after 24 hours could be used to trigger retransmission of the original ONIX message, with suitable modification of <MessageRepeat>, or Acknowledgements could be used to monitor and assess agreed service levels. However, it is not expected that it will be used in every ONIX 3.0 data feed, and where it is adopted, implementations might at first use only the simplest functionality (confirmation of receipt).

Simple Acknowledgement noting receipt of an ONIX message
using Reference names
`<?xml version="1.0" encoding="UTF-8"?>`
`<ONIXMessageAcknowledgement release="3.0" xmlns="http://ns.editeur.org/onix/3.0/acknowledgement/reference">`
`<Header>`
`<Sender>`
`<SenderName>Waterstones</SenderName>`
`</Sender>`
`<Addressee>`
`<AddresseeName>Publisher GmbH</AddresseeName>`
`</Addressee>`
`<MessageNumber>571</MessageNumber>`
`<SentDateTime>20130327T1510Z</SentDateTime>`
`<AcknowledgementNumber>1</AcknowledgementNumber>`
`<AcknowledgementSentDateTime>20130327T1805Z</AcknowledgementSentDateTime>`
`<MessageStatus>00</MessageStatus>`
`<MessageStatusDate>`
`<MessageStatusDateRole>01</MessageStatusDateRole>`
`<Date dateformat="00">20130328</Date>`
`</MessageStatusDate>`
`</Header>`
`<NoProduct/>`
`</ONIXMessageAcknowledgement>`

using Short tags
`<?xml version="1.0" encoding="UTF-8"?>`	File may contain extended characters without need for special coding
`<ONIXmessageacknowledgement release="3.0" xmlns="http://ns.editeur.org/onix/3.0/acknowledgement/short">`	Includes optional namespace
`<header>`
`<sender>`
`<x298>Waterstones</x298>`	The recipient of the original ONIX message
`</sender>`
`<addressee>`
`<x300>Publisher GmbH</x300>`	The sender of the original ONIX message
`</addressee>`
`<m180>571</m180>`	Message number and sent date
`<x307>20130327T1510Z</x307>`	…of the original ONIX message
`<m485>1</m485>`	First acknowledgement (to 571)
`<m487>20130327T1805Z</m487>`	…and its sent date
`<m489>00</m489>`	Message received
`<messagestatusdate>`
`<m490>01</m490>`	Expected to be processed
`<b306 dateformat="00">20130328</b306>`	…tomorrow
`</messagestatusdate>`
`</header>`
`<x507/>`	No product record-level info (yet)
`</ONIXmessageacknowledgement>`

Although labelled ‘Release 3.0’, the January 2015 version is the first full release of the Acknowledgement message. It is numbered for consistency with ONIX 3.0 (although it could in principle be used with legacy ONIX 2.1 messages too).

Key changes between ONIX 2.1 and ONIX 3.0

The table below summarizes the major changes in ONIX 3.0, for implementors planning a transition from ONIX for Books 2.1 to 3.0. For each numbered data element group in the Release 2.1 Product record, the table below shows the equivalent in 3.0, and notes where there have been significant changes. It does not list every minor change, but indicates where the majority of work will be required.

The impact of these changes – and the amount of development work required to support ONIX 3.0 messages in an existing IT system that already supports ONIX 2.1 – will vary, depending on the database schema and on the complexity of the business models that the message is required to support.

The difficulty of supporting 3.0 in an application that already supports 2.1 will also depend on whether the 2.1 implementation has been kept ‘current’. ONIX 2.1 includes a large number of specialized data elements inherited from 1.x and 2.0, but these are complemented by more flexible composite data elements that are new in 2.0, 2.1 or in its subsequent minor revisions (2.1.1 to 2.1.4). In 2.1, the composite elements are strongly preferred, but for reasons of compatibility, the old elements are retained and deprecated. So for example, ONIX 2.1 contains the (deprecated) specialized elements <EAN13> and <UPC>, but the use of the <ProductIdentifier> composite is strongly preferred. Many of the changes in 3.0 amount to removal of these deprecated elements. Thus if the implementation of 2.1 has already eliminated use of the deprecated elements and maximized the use of generalized composites (as recommended), a significant portion of the work needed to support 3.0 has already been done. If the 2.1 implementation amounts to a minimally-updated 2.0, and still uses many deprecated elements, then the migration to 3.0 will likely be more onerous. Note that ONIX 2.1 superseded 2.0 in 2003.

If migrating from ‘up-to-date’ ONIX 2.1 to 3.0, radical changes in the underlying IT system or database are unlikely to be required (circumstances vary, of course). Most of the necessary changes are likely to be in adding or improving support for multi-item and digital products, in handling sets and series, sales rights, and – optionally – in adding support for block updates. After that, further changes are related to taking advantage of the added flexibility of ONIX 3.0, in the areas of collateral material, parallel multilingual text and international market supply details for example.

Having said this, limited development work on an existing IT system or database, simply to migrate to ONIX 3.0 may not in itself result in a system suitable for the modern publishing supply chain. Development to enable metadata to be managed in a more normalized way (where most metadata is managed once at a ‘work’ level rather than many times at a product level), and to integrate the management of e-publications with print products in a single, hybrid business process may be necessary.

‘So here is my ONIX 2.1 data. Where do I put it in ONIX 3.0?’ This is not usually a good strategy with which to approach an ONIX 2.1 to 3.0 transition. Not all data elements have direct equivalents, and the way certain types of data are included in the record has changed significantly. Nor should it be assumed that data practices that were good or acceptable in ONIX 2.1 remain good practice in ONIX 3.0. ‘Translation’ of ONIX 2.1 into ONIX 3.0 – producing an ONIX 3.0 record based solely on the data in an ONIX 2.1 record – is not always possible and is rarely desirable.

Key changes between ONIX 2.1 and ONIX 3.0
2.1	3.0	Notes
<ONIXMessage>		Root element: the <ONIXMessage> tag now has a mandatory release attribute and may include a namespace declaration (release was optional in 2.1). The message should not contain a DOCTYPE declaration.
<Header>		Header: some restructuring with elements renamed, and redundant elements have been removed.
<Product>		Product record: a new six-part block structure within the Product record, intended to support more granular, block by block updating, is new to ONIX 3.0. The ONIX Price and Availability Update message is no longer a separate message format – it is simply a block update containing only an identification preamble (‘block zero’) and Block 6. For regularly-timetabled updates, it is possible to send a message containing no Product records (from 3.0 revision 2).
PR.1	P.1	Record reference number, type and source: no significant changes.
PR.2	P.2	Product numbers: the Barcode element has been replaced by a new <Barcode> composite allowing barcode type and position to be specified separately, and redundant elements have been removed. No other changes.
PR.3	P.3 P.4	Product form: significant changes in the elements and coding used for multiple-item products and for digital products, including DRM, usage constraints and (from 3.0 revision 2) licensing details. There is little change in the handling of most single-item physical products. Provision has been added to allow a country of manufacture to be specified when this is required for cross-border supply.
PR.4		Epublication detail: this data element group has been deleted, since product form description for digital products is now integrated into Group P.3.
PR.5	P.5	Series: the <Series> composite in Release 2.1 has been replaced with a new <Collection> composite. This carries collective attributes (of series or sets), where they are not carried in P.6 (ie where they are not required as part of the distinctive title of the product). A new <CollectionSequence> composite can carry details of ordered collections (from 3.0 revision 1).
PR.6		Set: this data element group has been deleted. Sets are now handled in the same way as series, in P.5.
PR.7	P.6	Title: the <Title> composite in Release 2.1 has been replaced by an expanded <TitleDetail> composite. This can also include collective title elements (of series or sets) when these are required as part of the distinctive title of the product.
PR.8	P.7	Authorship: little or no significant change in the elements used for a personal or corporate contributor name. However the <Contributor> composite has been restructured to make it more logical, and the name identifier elements have been redefined. Associations between contributors and places can be defined in a more flexible way (from 3.0 revision 2).
PR.9	P.8	Conference: redundant elements have been deleted, otherwise no change.
PR.10	P.9	Edition: no significant change.
PR.11	P.10	Language: a new element allows script as well as language to be specified, and redundant elements have been deleted. No other changes.
PR.12	P.11	Extents and other content: all extent types are now handled in a slightly extended <Extent> composite, and redundant elements have been removed. Minor adjustments in the treatment of illustrations and ancillary content.
PR.13	P.12	Subject: both main and subsidiary subjects are now handled as repeats of a single <Subject> composite, and redundant elements have been deleted. The <PersonAsSubject> composite in Release 2.1 has been slightly restructured, as <NameAsSubject>, consistent with changes to the <Contributor> composite in P.7.
PR.14	P.13	Audience: redundant elements have been deleted, otherwise unchanged.
PR.15 PR.16	P.14 P.15 P.16	Descriptions and other supporting text / Links to image/audio/video files: two ONIX 2.1 data element groups have been replaced by three new groups, significantly extending the capability for handling supporting materials, particularly resources made available on the web
PR.17	P.17	Prizes: one redundant element has been deleted, otherwise unchanged.
PR.18	P.18	Content items: changes are limited to those which follow from the revision of some of the composites from other data element groups which are re-used here.
PR.19	P.19	Publisher: redundant elements have been deleted. The <Imprint> and <Publisher> composites have been revised so that handling of identifiers is consistent with general ONIX practice. Provision for providing promotional and other contact details on a per-product basis has been added (from 3.0 revision 1).
PR.20	P.20	Publishing status and dates, and copyright: individual date elements have been deleted and replaced by a repeatable date composite. For books published in international markets, it is no longer mandatory that there will be a single publishing status and pub date in P.20, if that ‘global’ status is unknown (a publisher would be aware of the global status, but other ONIX senders may not be). Instead, status and date can be specified for individual markets in P.25. A new element for Latest Reprint Number has been added, for use only in certain countries where this information is understood to have legal significance. From 3.0 revision 2, copyright details are more flexible.
PR.21	P.21	Territorial rights and other sales restrictions: the <NotForSale> composite has been deleted, with adjustments to the <SalesRights> composite so that all cases can now be handled within this single composite. A new <ROWSalesRights> data element has been added to define the rights associated with countries not specifically listed. The country and region elements have been grouped inside a new <Territory> composite which is also used in P.24 and P.26, so that wherever a geographical area is specified it is handled in the same way. The underlying logic, however, remains the same. Provision has also been added to allow a non-geographical restriction to be stated with date limits, and (from 3.0 revision 2), the <SalesRestriction> composite is moved inside the <SalesRights> composite.
PR.22		Dimensions: the <Measure> composite has been moved to P.3, and redundant elements have been deleted. Consequently this data element group is no longer required.
PR.23	P.22 P.23	Related products: a new <RelatedWork> composite has been added as P.22. The <RelatedProduct> composite has been radically cut back, by general agreement, so that it usually carries only a relation type and an identifier. Provision is retained for carrying a product form, but this is not recommended for general use.
PR.24 PR.25 PR.26	P.24 P.25 P.26	Supplier, availability and prices / Market representation / Sales promotion information: these three groups have been significantly restructured within a new <ProductSupply> block. P.24 now specifies a territorially-defined market together with any non-territorial sales restrictions which are specific to that market. P.25 details the publishing status of a product within a particular market. P.26 details the distribution source, availability, and price of the product within a particular market. Within the new structure, many of the most frequently used elements remain the same, though there are some detailed changes and additions, notably a new and more flexible <Tax> composite, price conditions for rentals and linked product offers, tiered pricing, and a facility for provision of prices of other, comparable products and (from 3.0 revision 2) for price identifiers. The recommended treatment of reissues has been changed and the <Reissue> composite deprecated.
Attributes		The meaning of the datestamp attribute has been modified.
Multilingual text		Most textual data elements are repeatable if the text is supplied in multiple parallel languages (from 3.0 revision 1). Note that named entities for non-ASCII characters – for example – or ü – are not supported in 3.0. Use native characters in your chosen encoding, or numerical character references (eg – or ü) instead. The five built-in XML entities including & and < are exceptions.
Use of XHTML 1.1		Allows the use of the <ruby> tag in XHTML marked up textual data (from 3.0 revision 1). For textual data elements that do not support XHTML markup, Unicode interlinear annotation delimiters (characters ￹, ￺ and ￻) may be used to delimit text glosses.
XML schemas		XML developers can choose between DTD, XSD or RNG expressions of the ONIX data structure and of the codelists for validation. An extended validation tool based on Schematron is in development.
UML diagrams		A data model, documented as a set of UML class diagrams, is available for application developers. Contact info@editeur.org for details.
Application notes		A selection of notes on specific aspects of ONIX 3.0 practice are available on the EDItEUR website, for example How to describe sets, series and multiple-item products in ONIX 3.
Acknowledgement message		Can be used to confirm receipt or pass status and error information from recipient of an ONIX message back to its sender.
This Guide		Publication of a global implementation and best practice guide to accompany the Specification is intended to reduce country-to-country variation in the implementation of ONIX 3.0 and ensure that metadata can flow freely in an increasingly global metadata supply chain.