How to send ONIX 3.0 files to BiblioShare along with your ONIX 2.1 feed

ICYMI: BookNet Canada set a target deadline of August 28, 2020 for all Canadian data providers to be able to send a full ONIX 3.0 feed. To help the industry accomplish this goal and to support a well-rounded ONIX education, BookNet Canada is highlighting essential resources and publishing on the BNC blog.

Yes, @BookNet_Canada's quality-controlled data aggregation and distribution system, #BiblioShare still wants your ONIX 2.1 files along with your ONIX 3.0 data feeds.
CLICK TO TWEET

Here’s a sentence you won't read every day: There are a lot of exciting things happening in the supply chain world these days! One of them is that finally, after a mere six years since the sunset of the ONIX standard version 2.1, the industry is getting incentivized to transition to ONIX 3.0.

With this transition, and inspired by some major players indicating they'll only be accepting ONIX 3.0 in the not too distant future, we thought this would be a good opportunity to remind our BiblioShare participants (and those not yet participating) how this will all play out for you in terms of getting us your data.

Currently, within our BiblioShare platform, we have the same issue as everyone else out there in the book metadata world: There’s not a clean, easy way to simply cut over to the 3.0 version of ONIX. The two versions of ONIX, the ‘sunset' 2.1 version and the 'new' 3.0 version aren’t compatible. This means that we need discrete feeds for either version and we need to receive both feeds!

Why both feeds?

We need both feeds because there are a lot of companies out there — possibly your trading partners — who will not now, nor anytime soon, be able to accept ONIX 3.0 data. Sure, the number of those types of trading partners will slowly diminish over time, but until you’re comfortable with no longer needing to support those partners your company will need to continue to produce both versions of your ONIX metadata feed.

While over the years (and especially lately) we'e provided reasons to start using ONIX 3.0, and while we've created a lot of material to support your decision-making process with regards to this transition, it’s important that we make clear how BiblioShare will work and currently works, to make this a reality.

How does BiblioShare work?

When we create an account in BiblioShare what we enable is a way for your company to provide ONIX and receive a somewhat detailed quality report on your data. We also create a directory on an FTP server for your company. This directory holds all of the subdirectories that are used for providing us with supporting material as well as the ONIX data for your company’s catalogue of titles. We've built our processing engine to automatically process files based on both their file name as well as according to which directory the files are placed in.

This is what you get when you have a BiblioShare account:

BiblioShare uses these directories to control our processing engine. If you put your ONIX XML or zip file into the ONIX directory this tells us to process this file accordingly, using the ONIX schema to guarantee files are valid. If your files aren’t valid then you’ll get a nicely worded email from BiblioShare letting you know your file did not pass validation and asking you to try again.

In this blog post, we go over some of the most common errors that lead to file invalidation. In addition to bad links, blanks, and using the wrong codelist version, we’ve noticed that the following are also reasons why files might not pass validation:

• putting collateral into the wrong directories

• using the wrong file format for things like covers, interiors, or samples

• problems that stem from internal firewall policies or default settings for the FTP client software that is used to upload files

Naturally, as is often the case with technical support, these issues are very much subjective — determined by each business’ IT departments, internal procedures, etc. If you need more details about what issue might be leading to invalidation then you should either try validating the file yourself with your XML software or shoot us an email. We do all that we can within our power to facilitate solutions for even these unique problems.

So, to be as clear as possible, our FTP server can support either secure FTP or open FTP. Generally, we find that client software (particularly Filezilla) will have a default setting for using a simple or an encrypted connection, and 9 times out of 10 any issues with connecting to our FTP server may be resolved by tweaking this setting. We have documentation on the use of Filezilla to logon to BiblioShare’s FTP available here.

Right file wrong place

So what happens if you put the right file in the wrong place? Good question, glad you asked. Let's say you put your version 3.0 ONIX file into your 2.1 file directory. Well, BiblioShare uses the ONIX schema to ensure your ONIX is valid so you'll very likely have a failed file on your hands. This happens because the ONIX schemas point to code lists that are specific to each version of ONIX (learn more about ONIX Code lists Issue 50). This isn't exactly the same as using a wrong code from say a 3.0 codelist in your 2.1 record — although that will cause your file to fail as well. The ONIX versions are structurally different and so not backward compatible.

That, in a nutshell, is how we’re currently straddling the transition from ONIX 2.1 to ONIX 3.0. If you’re ready to provide ONIX 3.0 data to the supply chain then, by all means, get in touch — we’ll get you set up!

To stay up-to-date on all ONIX 3.0 transition news and information, subscribe to our weekly eNews or nab the RSS feed.