Months before a finished book enters a warehouse, a retailer may already display its title, cover, contributors, publication date, format, price, subject, description, and preorder status. The visible page feels premature only if a book is understood as an object. In the supply chain, the publication already exists as a structured claim about a future product.

ONIX for Books is one of the principal ways that claim travels. Maintained by EDItEUR, ONIX is an XML-based standard for exchanging book-product information among publishers, distributors, wholesalers, retailers, libraries, and data services. Readers rarely see an ONIX message. They see interfaces assembled from parts of one.

The invisible record is not a copy of the book. It is a commercial representation whose revisions may begin earlier and continue later than the publication it describes.

Product before object

An ONIX record centers on a Product. A hardcover, paperback, EPUB, downloadable audiobook, and large-print edition are not several files attached to one interchangeable title. They can have different identifiers, forms, prices, publication dates, rights, supply states, and accessibility features.

ONIX can relate those products to one another and to a larger work, collection, or prior edition. The distinction parallels the ISBN's function: the supply chain must know which publication product can be ordered, not simply which intellectual work someone means.

A product record carries identity and description, contributor roles, subjects and audience, product form and extent, publication timing, market rights, supply, price, and supporting assets such as cover images. The standard is extensive because book commerce contains facts that are both conditional and time-dependent.

Some facts should remain stable. An ISBN cannot become a convenient ID for another format, and a contributor's identity should not drift from one receiver to another. Other facts are expected to change. A temporary cover becomes final; a market date arrives; a territorial price changes; stock is replenished; rights expire. Metadata quality includes saying the right thing at the right time.

A correct message can produce a wrong page

A publisher sends an ONIX message to a trading partner or data intermediary. The receiver validates, maps, selects, and stores its contents under local business rules. It may shorten a description, map a subject into a proprietary category, combine another data source, cache an old image, or ignore a field it does not support.

The sender is responsible for the accuracy and timeliness of what it supplies. It cannot determine every screen assembled downstream. This is why correcting a portal field may fail to change a retailer page immediately: another feed may have precedence, processing may be delayed, the retailer may be using a different product identifier, or its mapping may have introduced the error.

Troubleshooting starts with a short provenance chain. Identify the product and sender, obtain the actual message and transmission time, confirm validation or acknowledgment, then compare the source value with what the receiver stored and displayed. Version and codelist issue matter when a code is accepted by one system and unknown to another.

These are operational failures with visible consequences. A wrong availability state can prevent an order. A misspelled contributor can split an author's catalog. Bad territorial data can advertise an offer where the supplier lacks rights. A date error can disturb preorder handling and reporting.

The metadata inside the ebook is another record

An EPUB contains package metadata. A PDF can include document information and XMP. Those fields travel with the file and help reading systems, libraries, and archives identify the publication. ONIX travels separately through the trade and can describe changing offers and supply conditions that do not belong inside a static reading file.

The records should agree on identity while serving different purposes. An EPUB needs the metadata required for its publication and reading behavior. ONIX can describe suppliers, territorial prices, market dates, availability, returns conditions, collateral, and relationships among products. Updating a retail price does not require rebuilding the ebook.

The distinction prevents several common mistakes. Embedding an ISBN in a PDF does not register or distribute it. Sending an ONIX accessibility code does not make the underlying ebook accessible. Descriptive metadata cannot repair missing navigation. A feature claim is accurate only if production has actually supplied the feature.

Four events in one record

Consider one paperback through four events. At announcement, its product record has an identifier, contributor, provisional publication date, initial price, descriptive copy, and a temporary cover clearly identified as such. The publication can be found and preordered without pretending that every property is final.

Before release, the final cover and extent replace provisional values, rights and supply details are confirmed, and an on-sale date is supplied with the appropriate meaning. The message is an update to the same product identity, not a second paperback accidentally competing with the first.

On publication, availability changes from forthcoming to the applicable supplied state. Years later, a new edition receives its own identity and is related to the older paperback; the older record is updated to say whether it remains available, is replaced, or is no longer supplied in a particular market. “Temporarily unavailable,” “out of print,” and “replaced by a new edition” lead buyers and systems to different actions.

The lifecycle needs an owner. Someone should know which system is authoritative, who approves descriptive and supply fields, how updates are issued, and how receiver errors are investigated. A small publisher using a distributor may never write XML, but it can still audit the data transmitted on its behalf.

Codes and their dates

ONIX uses codelists for values such as contributor role, product form, availability, price type, language, and subject scheme. Codes let systems with different interfaces and working languages exchange defined concepts without depending on free-text guesses.

The lists evolve through additions, clarifications, and deprecations. Sender and receiver need to know which issue they support. A new code may be accurate in the publisher's message and unknown to an older receiver; a deprecated value may persist in backlist data for years.

Standards maintenance is therefore part of metadata maintenance. EDItEUR has archived ONIX 2.1 and labels it obsolete. At the time this article was reviewed, Release 3.0 is the maintained release family documented by EDItEUR. That is a dated statement about the standard's current governance, not a reason to assume that every trading partner has completed migration. Legacy exchanges require mapping, testing, and agreement.

Validation establishes only part of quality. A message can conform to a schema while carrying an inaccurate biography, a poorly chosen subject, or an accessibility feature the file does not possess. Structural validity and editorial truth require separate checks.

The record after the launch

Publication day does not complete the metadata. Reviews, awards, corrected contributor data, new descriptions, price changes, supplier transitions, rights changes, and related formats may all arrive later. Leaving an old product record untouched can make a book commercially illegible while the reading copy remains perfectly sound.

The ONIX record resembles a book only in a limited way: structure determines what others can find and do. Unlike the published text, the record is designed to describe a product moving through markets and time. Its usefulness lies in revision with continuity. Readers need the result to be uneventful: the correct edition under the correct name, available in the correct place at the correct price, described well enough to choose knowingly.

SOURCES

- EDItEUR. “ONIX for Books Overview.” https://www.editeur.org/83/Overview/ - EDItEUR. “ONIX for Books Release 3.0 Downloads.” https://www.editeur.org/93/Release-3.0-Downloads/ - EDItEUR. “ONIX for Books Codelists.” https://ns.editeur.org/onix/en - EDItEUR. “Archived Previous Releases.” https://www.editeur.org/15/Archived-Previous-Releases/ - Book Industry Study Group. “Metadata Committee.” https://www.bisg.org/metadata-committee - Book Industry Study Group. “Metadata Best Practices.” https://www.bisg.org/metadata-best-practices - BookNet Canada. “What Is ONIX?” https://www.booknetcanada.ca/blog/2025/10/17/what-is-onix