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

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). We will need to set up a new account for that feed.

Expanded explanation:

There are very few companies in North America currently sending ONIX 3.0 files. 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 change 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 to some print copies? Why not put in 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?