Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 50 Next »

Table of Contents: 

Introduction

ONIX (ONline Information eXchange) is a universal, international format enabling all publishers to exchange information about books.

The ONIX specification is developed and maintained by EDItEUR with direction from an International Steering Committee that includes representatives from many of the countries that have adopted ONIX (including Canada).

What is ONIX?

ONIX is a standard format or "language" that publishers need to use when distributing electronic information about books to wholesale, e-tail and retail booksellers, other publishers, and any other supply chain partner involved in the production, review or sale of books.

ONIX is not a database and you don't have to change your database in order to use it. Don't be worried by the acronym: it isn't a programming language and it can't "do" anything. It just describes. It provides two things: Code Lists with their standard international definitions that support clear communication, and a file format for the delivery of book information.

ONIX Codes can be used to clarify information sent via Excel spreadsheet, delimited ASCII (tab or comma, with our without headings), fixed width, HTML, Word, QuarkXpress, email message or hard copy, but the ONIX file format is the preferred method because XML and it's comprehensive book record ONIX offers have distinct advantages over other formats.

ONIX Makes It Easier To Sell Books

Take a browse through any of the major online bookstores and you'll notice that some books have cover art, descriptions, review and other information (known as metadata), and others list nothing but the title, author and price. Metadata plays a large role in online book sales (titles with metadata outsell those without, eight to one) so it is in the best interest of both bookstores and publishers to include metadata for as many titles as possible.

Online retail's emergence as a popular new channel for buying books, albeit one that lacks the opportunity to physically pick up and browse a jacket cover, has been a key driver in the creation of ONIX. Books are promoted through written text on a web page. Getting this data about each book from publishers to booksellers proved complicated, especially as major industry retail databases used different format preferences for receiving bibliographic data. A standard format was, therefore, agreed upon as the optimum way for publishers to format and exchange their book information.

The major booksellers and distributors have moved towards this standardized format for bibliographic data, so that wholesalers, retailers and other suppliers can accept information that is transferred electronically in the ONIX format. The fact that publishers can create one file to push to all aspects of the supply chain means their bibliographic data is going to be represented.

The ONIX Message

The ONIX standard defines both a list of data fields about a publication and how to send that data in an ONIX message. ONIX specifies and defines the data elements so that everyone can be sure they're referring to the same thing. Publishers can use as many or as few of the data elements they wish to record and transmit. These are not just limited to facts and figures and textual description: multimedia files, such as images and audio files are becoming increasingly important as ways of encouraging sales and enriching the record.

The ONIX message is a set of data elements defined by tags written in XML (eXtensible Markup Language).  The XML definitions provided its schema defines, among other things, how to order the data elements and how the elements are interrelated.

How Does ONIX Actually Work?

ONIX is a common language of terms and definitions, which describe the data fields needed to express the rich information publishers and retailers require. The standard has new structures added irregularly but done typically between every one to two years.  Supporting code lists are updated around 4 times a year.

It is also a standardized means of electronic delivery that uses recognizable XML tags for each data element. You can choose to use readable descriptive tags called "reference" or "short" code-like tags (EDItEUR and BookNet both recommend using reference tags – there's really no functional difference but <PublisherName>Your Press Name</PublisherName> is self-explanatory and <b081>Your Press Name</b081> is not).

How ONIX works is simple:  An ONIX record represents a single salable product with a unique ISBN.   An ONIX file contains multiple records and it allows a retailer or other company to load book metadata in bulk direct to their database.  An ONIX record can contain everything a business needs to know to sell the book as well as all the material they need to display to consumers so they can make a buying decision.  The publisher provides the retailer with everything they need and can maintain control of many or all aspects of their product's presentation to the public, as well as set up special pricing, licensing arrangements and so on in a file format designed to be both comprehensive and updated regularly.  As marketing needs change an ONIX record can, and should be, updated.  Problems are minimized because all trading partners should get the same data.  All this assumes a publisher stores their information in a database of some sort, though ONIX specific software does exist.

ONIX 2.1 vs ONIX 3.0

One point that's confusing is ONIX comes in two incompatible versions, and both remain in use:  2.1 developed between 1999 and 2009 (see the next section), and 3.0 developed from 2009 ongoing. It's best to think of 3.0 as both a different mapping (explained below) and a tweaked version of 2.1.  Design choices made in 2.1 couldn't accommodate digital products and that forced changes that "broke" the structure or logic of 2.1.  EDItEUR developed new and better logic, then made small changes for clarity and functionality throughout ONIX 3.0. They "tweaked" 2.1 making 3.0 overall simpler, more accurate and smarter.  And then development continued providing new metadata support and improvements for another decade. Business needs are not static and metadata changes.

Anything you can say in ONIX 2.1 can be said in ONIX 3.0. In many if not most cases, it can be said the same way, but if you think of a publisher having a database of metadata "mapping" it to ONIX 2.1 is different than mapping to ONIX 3.0.  Mapping is not only placement (the order and many tag name used in 2.1 and 3.0 are different) but would include conversion of values in the publisher's dataset.  As here's an example: 

A publisher would know and record however they like that this ISBN is the EPUB digital version, then map that knowledge appropriately to the ONIX standard. 

  • In ONIX 2.1 a digital books primary format code, called Product Form, comes from ONIX Code List 7 and is "DG". The fact it's the EPUB is conveyed by a List 10 EpubType code of "029". 
  • ONIX 3.0 also uses Product Form as well but it's source Code List is number 150 (not the same list as 2.1) and and the basic digital book's code is "EA".  It is supported by a List 175 Product Form Detail (not EpubTye) code of "E101". 

If your head is spinning don't worry as all of that is likely handled by your software. This just illustrates that it's the same information but to give some meaning to being a different "mapping". 

The above example seems to be one-to-one but in other sections, say describing Territories and Rights, the actual logic ONIX 3.0 use is different to allow for greater clarity.  Again, the publisher should know what they mean and the map used to ONIX 2.1 or 3.0 is different  A goal of ONIX 2.1 was to support international sales and it comes close to doing that, but use discovered problems.  ONIX 3.0 "tweaks" the information to fix the problems resulting in subtle differences and greater clarity. Like format, it's the same publisher information but mapped to different structures and 3.0 is supported by fewer and clearer logic rules. If you care about accuracy you'll appreciate ONIX 3.0. 

The most important problem to be solved by any publisher is to know what rights they have and the territories they service and the same for companies they contract with to provide that service. That's hard to track but once you have that electronically (however you record it) the ONIX standard makes trading the information easy.

The digital supply chain is in many ways distinct and is largely compatible with ONIX 3.0 (if ONIX is accepted).  Most retailers will accept either 2.1 or 3.0 but prefer 3.0 because it supports digital products better.  The print supply chain use of ONIX predates ONIX 3.0 and North American publishers and the print supply chain invested heavily in ONIX 2.1 development.  While ONIX 3.0 is not hugely different for print products the fact it's not a one-to-one conversion with 2.1 means development work is required to use 3.0 and companies are reluctant to make the change. 

The experience of companies who have done the development to make a transition from 2.1 to 3.0 report that it's easier to do than they expected but it's sad and undeniable fact that many print publishers and retailers in North America have not made the transition yet.   This means that anyone starting out has to at least consider supporting both ONIX 2.1 and 3.0.


ONIX 2.1 is No Longer a Supported Standard

As of early 2017 the ONIX 2.1 will not be updated further. Codelist Issue 36 (released January 2017) is the final code list for this version and the only one required going forward. Not being supported does not mean it is not used. ONIX 2.1 can remain in use for however long two companies choose to continue to trade data using that version. In North America ONIX 2.1 continues to be used for many physical book metadata transfers, though this is an ever-changing landscape.

BookNet Canada continues to recommend:

  • All data suppliers continue to support ONIX 2.1 for North American data transfer
  • If you can support ONIX 3.0 in addition to ONIX 2.1 please do so and ensure trading partners are aware of the option. This will facilitate retailers and other aggregators developing ONIX 3.0 support
  • No one should switch from ONIX 2.1 to ONIX 3.0 without first notifying their trading partners.  We think you'll find that you will still need to support ONIX 2.1
  • New implementations of ONIX have a hard decision:  ONIX 2.1 will not be supported for much longer but it remains the practical choice in our market.

Amazon's 3.0 Request

Amazon has requested that all physical book ONIX feeds be submitted in ONIX 3.0 by December 31, 2020. No deadline has been specified for digital ONIX but it is already dominated by ONIX 3.0 and the expectation is that it will follow shortly thereafter. This request applies globally to all Amazon divisions. Watch for more announcements from other retailers and companies supplying data.

BookNet Canada has compiled supporting documentation at https://booknetcanada.atlassian.net/wiki/spaces/UserDocs/pages/1149894942/Transition+to+ONIX+3.0%3A+Essential+Resources+for+Data+Providers as well as a benchmarking / progress calendar for data providers at https://booknetcanada.atlassian.net/wiki/spaces/UserDocs/pages/1144129720/Transition%2Bto%2BONIX%2B3.0%2BCanadian%2BMarket%2BCountdown%2BCalendar.


ONIX is Currently Defined as ONIX 3.0.7

Changes for ONIX 3.0.7.pdf October 31, 2019 adds a new 

  • This is an addition of a new Block 7 Promotional details and it has new tags assigned as P.27
  • It's placement in the ONIX tree is between Block 2 (Marketing & collateral) and before Block 3 (Content)
  • The placement is logical as it's about book promotion and comes after marketing & collateral but there's no easy way to avoid it be out of numerical order as a block or P number.
  • As expected the Block PromotionDetail cannot repeat (only Block 6 Product supply can repeat to allow for multiple market support) but it contains the PromotionalEvent composite that can repeat.
  • This "Events" section is specifically about promotional events – book signings, author tours, media appearance – and transmitting information in advance of the event (The Block 1 P.8 Event section is for books about Events or Conferences)
  • The Promotional Event composite can repeat for different events and each event has to have at least one composite but can contain multiple dates in an Event Occurrence section.  The above documentation and the ONIX manual provide a full explanation.

There are a few other tweaks – a new addition to Prize to support Regional prizes as well as new HTML support in Prize Statement.  Text Content now supports "Text Source Description" to allow for context to be added to a reviewer so their name and credentials can be communicated separately.  Several other tweaks are listed in the document above.

Changes for ONIX 3.0.6  April 24, 2019  This is an exceptionally small revision that added the following two

  • a Measure composite to Product Part (needed because knowing the size of each component in a multiple part product can be important)
  • URL links in Website composites can now repeat to provide language support. (Use of the Language attribute in ONIX 3.0 allows for, say, the main description to be provided in more than one language – so separate composites where the only difference is the language used in the description.  URLs can also appear in different languages and so are now allowed to repeat in the composite)

Changes for ONIX 3.0.5 October 26, 2018 is another recent revision change. 

  • Adding a new element to Block 3 (Content) to support chapter-level audio time codes
  • Two Block 6 (Product Supply) additions:
    • to support pallet quantity and
    • designate tax exempt. 
  • Several other minor updates and changes are detailed in the specification (look under "Introduction" for a summary of revision changes and details under "Document History."  Appendix A1 is a complete list of all ONIX composite and elements in ONIX file or schema order.)

The time for making the transition to ONIX 3.0 has now come and all publishers and data recipients should at a minimum familiarize themselves with the new constructs and data elements ONIX 3.0 can support. The value in the transition to ONIX 3.0 comes from the ability to better sell books and identification of any new data points that would help your business work better will increase the likelihood of their adoption by the industry.   Already identified

Editeur.org has a number of papers describing the changes as well as an overview document Best Practice Guidelines that explain both what needs to be recorded and why.

ONIX 3.0 users should update their codelists using the list at https://ns.editeur.org/onix/en. ONIX 2.1 users should use code list Issue 36 (the final code list for this version and the only one required going forward).

Current North American Metadata is Defined by:

Version 3.0.7 -- Revision 7
ONIX Code List 49  ONIX_BookProduct_Codelists_Issue_49_Changes.pdf

Version 2.1.3  – Revision 3 (Revision 4 is largely about changes for Japan)
ONIX Code List Issue 36 is the last code list that should be used for ONIX 2.1

BISAC Subject Code list 2018 edition and Regional Themes 

Thema Version 1.3.2 (last updated April 2019)

The overview of ONIX for Books at the Editeur website.

Implementation LISTSERV

Join Yahoo Groups ONIX_IMPLEMENT email list

Their archive of messages goes back beyond 2000 and covers a wide range of topics. Correct ONIX usage may be a matter of correctly matching code list definitions but it often depends on a consensus between suppliers and end users. This can vary between markets (each country has its own flavour of ONIX) and this forum is where the consensus begins.

Canadian-specific questions can be sent to biblio@booknetcanada.ca and if necessary will be brought to the attention of the Bibliographic Committee (where Indigo is an active member).

Questions?

If you need help, contact biblio@booknetcanada.ca.

  • No labels