In my last post, I looked at what it means to implement ONIX 3.0, and came to the conclusion that it meant carrying enough “granularity” to improve metadata accuracy to support international sales. And I suggested that even ONIX files shared only within Canada will still need to implement new support in order to co-exist in a supply chain that supports international metadata. I hope that I also showed that ONIX 2.1 supports most of the same ability (even if ONIX 3.0 does it better), and that international support means everyone pulling up their meta-bootstraps.
Why do I harp on and on about all this? Well, bleating loudly is my standard way of communicating about standards, but more on point: ebooks are sold internationally. Editeur’s Graham Bell, at his recent ONIX presentation associated with BNC’s Technology Forum, pointed out how liberally in their own favour e-tailers interpret ambiguous metadata. My summary: If you don’t tell them otherwise, they will sell, and the results may not be happy contractually. You might feel lucky and think “I’m fine because I have all the rights, so I don’t need to waste time saying so in my files,” but if these liberal interpretations become a problem for sellers, then that ambiguity might flip-flop and confine you to your local market.
Understanding the rights you have to the author’s work, as well as any ancillary material you’ve added to make it a “book,” and then relating that business information to the products you sell, is the cornerstone of useful metadata. The simple reality is that accurate communication is the only way of making arrangements with companies where your handshake is not an option.
In this post, I want to look at what an orderly transition from ONIX 2.1 to ONIX 3.0 might look like. My apologies in advance: It’s not that pretty, and it seems as if no one wants it to be orderly.
The Current Status of ONIX 3.0
To understand how far your company should be in the transition between 2.1 and 3.0, it’s helpful to look at what is happening in the industry worldwide. ONIX 3.0 is used by the new players—China, the Middle East, India, Russia—the markets that came to ONIX around the beginning of this decade. (BTW: ONIX 3.0 has improved the ability to carry multiple languages and translations—and these markets are using them.) ONIX 3.0 is accepted by e-tailers, in particular those e-tailers that need metadata from the huge markets that the new players represent.
ONIX 2.1 is still the dominant version being used by the early ONIX adopters—the English-language market, and particularly the old guard print-book-focused companies. In North America, ONIX 2.1 is used almost exclusively. The theoretical capacity to accept ONIX 3.0 that exists in most large data aggregators in North America is limited by the absence of North American 3.0 files to load.
Considering Early Adoption
But you’re sold on ONIX 3.0—you know your stuff and want to start now. Can you just make the change? I think you can—but even now, you’re going to be an early adopter.
The first question is: Can you support both ONIX 2.1 and ONIX 3.0 simultaneously? If you can support both, are you adding depth to your information in ONIX 3.0? If not, is that because you’re using all the bells and whistles of ONIX 2.1, so your files are already pretty close to supporting the granularity available in ONIX 3.0? And are you planning to improve your ONIX 3.0 file as retailers identify new elements that will help them sell?
If all of that sounds good, you’re in a great position to painlessly make the transition. You should simply offer your ONIX 3.0 to all trading partners, and I expect that within a year or two you will be able to look at dropping your 2.1 file.
Get Your Data in Order
To the best of my knowledge, though, there are few publishers in North America who can make the above claims. If you think you can, I seriously invite you to get in touch, for no other reason than that I need your 3.0 file for testing! What I’m hoping to avoid (based on test files that I have seen), is this: A distributor takes an early 2000s–style ONIX 2.1 file—poor support, deprecated elements and all—and shoehorns the same data into the 3.0 format. A 3.0 file that, say, contains only Person name, inverted, or can’t differentiate between people and corporations as authors, or doesn’t say where the Supplier supplies to. It can be done. The flexibility of the ONIX standard allows for no end of nonsense.
If this describes the development plan behind your ONIX 3.0 file, then I can only suggest you should step back and look to develop a system that can take the real business knowledge within your company and apply it to your product metadata so that other companies can work with you. That’s the point here, and the business case for doing this right is support for international sales. Your ONIX 3.0 file should be more than bad data playing dress-up.
When to Take the Leap
I suspect that most publishers understand all of this, but are concerned about the need to support two data standards simultaneously. In this case, you probably just want to know when to make the shift to ONIX 3.0.
If you’re doing your own programming, there’s no way to avoid supporting two ONIX versions during the 3.0 file’s development. You’ll have to start sometime, though, and my recommendation is that you shouldn’t let the dual-support issue stop you.
There is a different group of ONIX producers, though: small players using ONIX-based software. ONIX 2.1 is not backward-compatible from ONIX 3.0. If you store data in ONIX 2.1 and want to make the transition to ONIX 3.0, you’ll have to make changes and add values. There are fields that are mandatory in 3.0 that aren’t mandatory in 2.1. There will be mandatory slots in an ONIX 3.0 template that weren’t present in 2.1.
To make matters even trickier, most ONIX-based software doesn’t allow for one dataset that supports two distinct ONIX feeds. It gives you a template to fill out to support whichever version of ONIX you want to use. To support both ONIX 2.1 and 3.0 you’ll need to support two templates, each with their own dataset. Two copies of each product record, one for each version, and update them both to support your end users. That’s a pain!
At the moment, then, I see two workable options for small players: If you want to make the transition to ONIX 3.0 now, you should maintain and update two separate datasets in both versions of ONIX to support end users. Alternatively, you could wait a little longer before making the transition. In my opinion, there’s little percentage in small players being early adopters, and waiting a little longer may be your best bet.
End Users and ONIX 3.0
The same problem can exist in end users. Most end users map the incoming data onto their data set—they’ve identified specific business needs and have systems that support them. They should be able to map ONIX 3.0 to their databases as well as ONIX 2.1, and most have done that work already. You might ask your end users about what they support and whether they maintain the granularity and detail that ONIX 3.0 supports. Ultimately, though, you can trust that end users will program to meet retailer needs. It is publishers’ willingness to support retailer needs that drives the market. Once end users have data in ONIX 3.0 that tells them something new, they will use it.
Some end users, and BookNet’s own BiblioShare is one of them, use the ONIX standard as their data model. These users will have the same problem as the small players do. What does it mean if you store ONIX as ONIX and there is no compatibility between versions?
Well, in theory, if we receive a data feed in ONIX 3.0 and have an end user who needs it served to them as ONIX 2.1, we will need to map the data from one version to another. Mapping ONIX 3.0 down to 2.1 is at least plausible, but what do you do if you need to map ONIX 2.1 to ONIX 3.0? Most ONIX 2.1 files don’t contain the international data points that ONIX 3.0 is designed to provide better support for, and there are mandatory data points in ONIX 3.0 that are not required in 2.1. In these cases, BiblioShare would be forced to play data dress-up, but the value of the resulting data to any supply chain players expecting real ONIX 3.0 would be negligible.
The transition from ONIX 2.1 to 3.0 needs to be made. The real point is accuracy and international support for a larger supply chain.
