Sending ONIX 3.0: Update, don't recreate

Owned by Lauren Stewart
Jul 15, 2020
7 min read

A misconception about transitioning from ONIX 2.1 to 3.0 is that you completely have to reinvent your feeds, as if it’s a wholly new literary form turning everything on its head. When really, it’s more like modernizing a classic; the setting may have been tweaked, but the story is basically the same.

When it comes to ONIX 3.0, your workflow shouldn't be devastatingly different — but it can be more efficient. And that means you may need to take a moment and reacquaint yourself with the basics in order to re-evaluate your current process and make the transition easier.

So, with that in mind, we’re going to take a look at a few ONIX tales that share the common theme of how to properly send your metadata out in to the world — where it can be read, and beloved, by all machines that come in contact with it.

The Tale of Little Red Receiving Server

When you send your files off, alone through the woods, to bring Granny some goodies (and by Granny we mean consumers) think about how much you’re weighing poor Little Red down. A basket overladen with the same pieces will slow her down (and honestly, how many scones can one old woman eat?). But, if you supply her with only fresh baked goods, she’ll have nothing to blame for delays but poor judgement.

If you’ve been sending ONIX to BiblioShare, or other data distributors, you’re probably familiar with the concept we’re alluding to: full vs. delta files. A quick reminder:

Full file: A complete record of everything you’re currently publishing or will publish (ex. forthcoming titles), this also includes any changes/updates made to previously submitted records.

Delta file: Contains only changes/updates to previously submitted records. These work best if they’re sent on a weekly basis.

But we’re seeing a worrying trend when it comes to ONIX 3.0: no delta files.

File types remain the same for both ONIX 2.1 and 3.0 so the best practice is universal: When you first send data, send the full file. This is your baseline. A record of your entire inventory. After which you need only to create/send delta files which contain new records and updated ones. Your entire inventory should be represented in the totality of your delta files and it should be part of your regular production feed by summer 2020. That being said, are full files a one-off? No. Full files should be sent annually at least, so you have a new baseline which your partners can work from each fiscal.

But as we said, ONIX 3.0 makes things more efficient. In this case the introduction of Block updates. Unlike ONIX 2.1, ONIX 3.0 consists of seven blocks (Did you hear about Block 7 Promotional Details?) that collectively represent a key portion of your metadata. Block updates are essentially delta files, but much more compact as they’re only sending portions of records, namely the part that contains the updates. It’s a fantastic way to decrease loading time, but the adoption for some reason has been slow. EDItEUR has a wonderful explanation of what block updates are here and while BiblioShare does support them, they're not being widely used in the industry. But, as they're essentially the text messages of ONIX, we expect to see this change as 3.0 adoption becomes more widespread.

Moral of the story: The larger the file, the longer the load time. ONIX 3.0 isn’t a big bad wolf, and can be dissected and sent more regularly in smaller files, just like ONIX 2.1!

The Emperor’s New Publishing Status

The digital market is a land all it’s own, and in this land the worst thing you can do is treat your digital books as just an add-on for their print counterparts. Digital is a format not bonus content. ONIX 3.0 is digital’s main ally as it describes your digital titles far more fully and (again) more efficiently than ONIX 2.1.

So what are we getting? Sloppy data. What can you do? Use the transition to improve.

Take for instance the use of Code 11 (Withdrawn from sale) in List 64 (Publishing Status). This should translate as “No longer available for legal reasons.” But often we see Code 11 used for temporary withdrawals and then not properly coded when the book is available again. There are temporary codes, such as List 65 (Product availability), code 34 (Temporarily withdrawn from sale) or Code 16 (Temporary Withdrawal) in List 64 that should be used much more regularly. While digital books will never run out of copies, that doesn’t mean they won’t simply stop being produced. If, say, another edition comes along and you wish to direct traffic to this new shiny version, then you should be using code 17 (Permanently withdrawn from sale) which translates to “Digital version of Out-of-Print.”

We bring this up because ONIX 3.0 is better suited to this digital landscape. It has subtle, but essential changes. For instance, if temporarily withdrawn, ONIX 3.0 requires a date for when the book will be available again. This is how you create better, more useful metadata, you share actionable, relevant information. And the little changes found in ONIX 3.0 are an easy way to accomplish that.

Most importantly, you must keep your data updated and present, or else it’s all just fanfare leading to confusion. Like a certain emperor who took a drafty stroll one day.

Moral of the story: If the book remains available and actionable it should be updated regularly. Send us your digital files!

The Three Little Supply Pigs

There are ways to further condense the size of your ONIX file and that’s by taking advantage of ONIX 3.0’s Block 6: Product Supply. Supply Detail, Market Representation, and Sales Promotion from ONIX 2.1 have been relocated to Block 6. What does this mean exactly?

EDItEUR says it best:

ONIX 3.0 uses a four-level structure to describe the geographical supply arrangements for a product:

  • First, there are the territorial sales rights in Group P.21, which lists all the territories where a publisher wishes to sell the product (including territories where the publisher has exclusive or non-exclusive rights);

  • these territories may be a single market, or may be divided into two or more independent markets, each of which is represented by a <ProductSupply> composite. If there are multiple markets, there are – at least in principle – multiple <ProductSupply> composites;

  • within a market, there may be one or multiple suppliers (distributors, wholesalers and so on), each represented by a <SupplyDetail> composite;

  • each supplier may set multiple prices, and each price might only be valid in a single country, or may be valid in multiple countries.

Let’s break this down a little.

A market in ONIX terms means a territory that shares:

  • Sales representation

  • Supplier

  • Dates

A market can be as small as a province and as large as the world. And here’s where ONIX 3.0 shines. It's simpler AND It represents Canada as its own market. This is important since previously the common (though incorrect) practice of ONIX 2.1 was to use sales rights as a kind of proxy for supply details. But they are often not one and the same. Market is not synonymous with sales rights, but you must have the sales rights in order to sell to a market. In ONIX 3.0 each market gets its own Block 6, the only ONIX block that can repeat, and each instance includes details about who is supplying the book associated with the ISBN of record, who is promoting it, and when it's on sale.

How does this condense your ONIX file size? Because you’re no longer repeating information. It’s far more efficiently organized and allows users to use it as EDItEUR intended. In this regard, cementing your information is a more reliable way to relay details, as opposed to haphazardly stringing information together from different sections in your ONIX (which could result in errors and angry end users). If the three little pigs had just diversified and utilized their materials, they could have had three solid structures as opposed to one functional locale.

Moral of the Story: ONIX 3.0 is a more solid conveyor of information for the supply chain.

Here are other resources and information we've made available to help Canadian data providers with the transition to ONIX 3.0:

Feel free to get in touch should you have any questions or need support. We’re here to help.

This originally appeared on the BNC Blog at https://www.booknetcanada.ca/blog/2020/4/17/sending-onix-30-update-dont-recreate. Subscribe the the blog RSS at https://www.booknetcanada.ca/blog?format=rss.