ONIX 3.0 and 2.1 -- What it means for BiblioShare data aggregation service users

Owned by Tom Richardson
Last updated: Apr 05, 2020 by Tim Middleton
3 min read

BNC BiblioShare requests that its clients 

  • Continue to supply ONIX 2.1
  • If you can supply ONIX 3.0 to supply it and ONIX 2.1
  • Contact us before supplying ONIX 3.0 (this would apply to anyone you submit data to).  In our case, we will need to set up a new account for that feed.

BNC BiblioShare schema validation is based on

  • The ONIX 2.1 schema will be based permanently on Issue 36 Code List.  Any use of codes implemented in Issue 37 or after will cause files to fail schema validation

  • The ONIX 3.0 schema will be updated with every new Code List Issue and new codes will be accepted concurrent with the issue release.


Expanded explanation:

Schema validation: As of Code Issue 36 January 2017 EDItEUR no longer update future ONIX 2.1 schema to include new "shared" code lists.  Code lists unique to ONIX 2.1 have not been updated for a couple of years but up to January 2017 any code list shared by ONIX 2.1 and 3.0 was updated in the ONIX 2.1 schema published on the EDItEUR website.  As of Issue 36 that published schema will no longer change

ONIX 2.1 use:  There are very few companies in North America currently sending ONIX 3.0 files for physical products.  This makes it difficult even for companies who can process ONIX 3.0 for other markets to be able to use ONIX 3.0 in this market.

BNC BiblioShare is unique in that we preserve publisher data as it is given to us -- we certify ONIX data so that makes sense on one level -- but that makes us a depository of actual ONIX data.  ONIX 2.1 and 3.0 are distinct datasets and there isn't a one-to-one compatibility even if they (largely) track the same information.   What that means for BiblioShare is we share the overall market issue in that while we can process ONIX 3.0 files we don't have enough of it to set up effective client services for it.  For example, neither The 49th Shelf nor BNC CataList are able to process ONIX 3.0, and we have not had the data to create unique feeds for any of our wholesaler clients.  We can accept and need ONIX 3.0 data – but have no distribution of it (yet!).

Small publishers, often lured by their ONIX software offering a "quick" conversion to ONIX 3.0, are switching and discovering that the file isn't wanted.  Here's two rules of thumb on that and where to get more information:

No one should unilaterally switch from ONIX 2.1 to ONIX 3.0 without notifying their data recipients FIRST. 

Before you convert you should do some homework – see the "pitch" below and blog post, nexts, for more info on the sunset of ONIX 2.1

October 2014 BookNet Blog Post

Spring 2015 on – multi-part posts on Making the Transition from ONIX 2.1 to 3.0

EDItEUR site information, see in particular the PDF on local file instalation.

The pitch for change

The transition from ONIX 2.1 to 3.0 isn't actually that difficult, but if you haven't changed anything in your metadata when you make it, then there's two possible reasons:  You support a superb and very complete set of ONIX 2.1 metadata elements – and you should work to understand how much better and more precise that data can be in ONIX 3.0; OR you've taken a not very full ONIX 2.1 and made it into a very incomplete ONIX 3.0 file.  ONIX 3.0 is intended to fix supply chain problems that have come up since ONIX 2.1 was created. It supports a higher level of accuracy and ONIX 3.0 users expect to be able to find it.

A really quick way to understand it is:  Look at what you support in your digital file.  Excluding digital product specific data points: Are you supplying information in it about markets, rights, work identifiers – possibly pricing – that doesn't appear in your print file?   That's the definition of accuracy and ALL your metadata – print included – should be at that level. Data aggregators should be able to "select" the information they need from your records – all your records – the same way they will exclude some other company's data where you've got rights.  If your ONIX file supports those data points, it's easily done.  If it doesn't then it will make it hard for your data to travel to other markets.  

If one of your ebooks is selling well in Germany, why wouldn't a German bookstore want to order some print copies?  Why not put the standard bits into your ONIX feed that allow that bookstore to know if that option exists – or to clarify that it's not an option in that market?