...
- 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 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 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.
...