EDItEUR Series 8: Amazon adopts ONIX 3.1 for Kindle

Recap:

Metadata management is an important aspect of publishing. It’s the key information about a publisher’s products that needs to be shared with the remainder of the supply chain – from the basic title, author, ISBN, cover image, publication date and price, to richer information like abstracts or summaries, author bios, open access licenses and details of distribution arrangements. Metadata is often communicated via ONIX, a standard data file format that publishers, retailers, libraries and various intermediaries use, across many countries. It encompasses bibliographic information about the book itself, but also the vital marketing collateral and commercial arrangements. If you’re unfamiliar with ONIX, there’s a 15-minute briefing video available at https://tinyurl.com/3eyy3a9f.

EDItEUR is a member-supported independent trade association and standards body that’s best known for developing, supporting and promoting the ONIX and Thema standards, ensuring our ‘metadata supply chain’ remains based on free-to-use, open standards. The latest versions of its standards specifications can be found on the EDItEUR website https://www.editeur.org/.

The ONIX ecosystem took an important step forward in March.

In this series, Graham Bell, Executive Director of EDItEUR, shares occasional updates on EDItEUR’s work and the standards it manages.

In the previous article, I focussed on the newest revisions of ONIX – versions 3.1.1 and 3.1.2 – each of which introduced a range of richer options for metadata communication between publishers, various intermediaries, and booksellers in the ‘metadata supply chain’. But an equally important measure of progression is how the oldest versions of ONIX are still being used. Are publishers and retailers adopting the newer versions and gaining the benefits, or are they clinging to legacy or even obsolete versions that lack the sophistication of later developments.

Here the picture is mixed. While many publishers have pushed ahead, ONIX version 2.1 is still in use. This version was released in mid-2003 and was an almost trivial update of version 2.0 from two years earlier – in effect, it’s a standard that dates from 2001. At best, ONIX 2.1 addresses the industry issues of 2006, since when it has remained unchanged, and EDItEUR has provided no support for this version since the end of 2016. Yet a significant number of metadata senders and recipients continue to rely solely on this version. Many use IT systems that cannot export or ingest ONIX 3.0 or 3.1.

Why?

Aside from a straightforward reluctance to invest in new technology infrastructure that’s common across the industry, EDItEUR believes there are a couple of other key reasons why remarkably old versions of ONIX are still in use.

First, ONIX standards don’t have any kind of built-in expiration date. Despite release 2.1 being declared ‘obsolete’, it hasn’t stopped working. This is deliberate. In creating its standards, EDItEUR does not introduce any dependency on EDItEUR itself: EDItEUR doesn’t possess an ‘off-switch’. Everything necessary for ONIX 2.1 – documentation, XML schemas, controlled vocabularies – was made available for download (free of charge), and in fact it all remains available from an archive page on the EDItEUR website. So if version 2.1 still works, why invest in something new?

And of course, ONIX 2.1 does the basics, as it always did. Later developments add new functionality, but if your business requirements remain fairly basic too, it might seem that nothing in the new version provides any real benefit for your business or any incentive to update.

Some of the above arises because of poor appreciation of ONIX developments by decision makers – or even of standards in general. And this is wholly understandable: metadata is to some degree a specialism within publishing and bookselling, and those specialists are not often the decision makers. NB if you’re a decision maker who’s unfamiliar with ONIX, there’s a 15-minute briefing video about ONIX available at https://tinyurl.com/3eyy3a9f.

ONIX version 3.0 was created more than a decade ago, not just to add new functionality but also to simplify the standard. ONIX 2.1 had become too complex, and 3.0 is more consistent, simpler, clearer to interpret, and – most likely – less expensive to develop software for. Similarly, release 3.1 removed a handful of old and largely unused parts of the standard, as well as introducing new elements. In addition to simplification, new versions also clarify. A good example would be sales restrictions in ONIX 3.0. A sales restriction might say ‘this book may be sold in USA and Canada, but only to educational institutions – not through the general book trade’. As introduced, these restrictions were workable, but difficult for recipients to interpret. Revision 3.0.2 of ONIX modified the structure of the ONIX to clarify how these restrictions should be interpreted and applied – but because of the commitment to back-compatibility, the ‘old’ option was not removed. Release 3.1 finally removes the old option, so everyone’s approach to sales restrictions can now be simplified. Simplification and clarification of the standard reduces software development and maintenance effort, removes ambiguity from the metadata used across the industry, and reduces customer service issues (how much does it cost to answer the retailer’s query ‘can I sell this book to educational institutions in Mexico?’)

Second, there’s what might be termed ‘industry coordination’. In some countries, there has been a concerted cross-industry effort to use the most up-to-date versions of ONIX, more or less as they are released. Sweden is perhaps the best example, where a very large proportion of the entire metadata supply chain has voluntarily adopted each new ONIX release, together (over a single weekend!), in a highly coordinated fashion, but metadata supply chains in other countries have also taken this coordinated approach. This ensures publishers have partners to send new data to – immediately – and retailers have partners from whom to receive new data. The benefits of introducing a new version of ONIX (and of not using an older version) begin to accrue straight away.

Contrast this with the alternative, where organisations update one at a time, in an uncoordinated way. It’s a familiar chicken and egg problem: a publisher invests in an update of its metadata systems, but might be forced to wait months before a retailer can accept that new version of ONIX – or a retailer invests yet still has to maintain its old data receipt processes as well. The benefits of any update don’t arise until much later. It only takes one significant ‘hold-out’ organisation to reduce the benefits and increase the costs for the entire metadata supply chain for several years. Coordination is where trade associations can help their members, though of course without creating anti-trust issues or encouraging anti-competitive behaviour, but these coordination efforts are not always successful. EDItEUR strives to make each update as compatible as possible with its predecessor, in order to reduce the costs that arise from this uncoordinated approach, but without industry coordination, there are inevitably fewer clear incentives for a publisher, intermediary or retailer to keep up to date.

Having laid out the reasoning behind some organisations’ reluctance to use modern versions of ONIX, how did the ONIX ecosystem take a big step forward in the week of the London Book Fair? While Amazon has insisted on ONIX 3.0 for physical products for a few years now, its Kindle business has continued to insist on ONIX 2.1. This has affected many system vendors, publishers and intermediaries, who might otherwise have simplified their software suite and reduced some software maintenance costs by removing ONIX 2.1 functionality. Now, Amazon has announced that from April 2025, it will accept ONIX 3.0 and 3.1 for Kindle products too. And in turn, this enables the rest of the industry to move forward.

One of the benefits of this is that ONIX 3.0 and 3.1 enable publishers to provide the full range of metadata describing e-book accessibility required by the European Accessibility Act, which comes into force in three months’ time.

For the moment, Kindle will continue to accept 2.1 as well, just as Amazon accepted both 2.1 and 3.0 for physical books for a short transitional period. Now, the transition has begun for Kindle metadata too.