On December 31, ONIX 2.1 is making like a cowboy and riding off into the sunset after 11 great years on the metadata ranch.
If you were to choose a classic western as a metaphor here, you’ll want to avoid those circling-of-the-wagon epics—this is no time for publishers to be defensive in their outlook. Personally, I would say the transition from ONIX 2.1 to ONIX 3.0 is much like the film Unforgiven. You have your aging, steely-eyed protagonist, who must confront his violent past. He can’t transcend what’s made him what he is today, but in answer to a plaintive “I don’t deserve this,” he growls “Deserve’s got nothing to do with it.”
Metadata is a perennial phoenix, always improving and growing—maybe here the embodiment of “the code of the west”—played out against the starker reality of Who has time for this anyway? Feeling a little disgruntled or grizzled is OK, but calling yourself a metadataist is, well, a bit weird. And confronting your trading partners whilst they are in an outhouse? As our hero would say, “That’s right out of line.”
But still, a ranch hand at the metadata corral can’t help but be optimistic: The gleaming, new railway of ONIX 3.0 is coming to town. It’s modern, flexible, and better able to meet all your data-sharing needs.
So what does the ONIX 2.1 sunset mean for industry players? Let’s take a look.
1. The sunset date is December 31, 2014. That’s less than three months away. Should I panic?
Anyone who worked near computers around the year 2000 can remember how effective panic was with Y2K. Huge efforts were made to ensure that nothing would happen and, well, nothing did. That’s what everyone should expect here, only with about tenfold less drama.
There is one real change, and that’s that the source documents for ONIX 2.1—the DTD and Schema—will no longer be available to a DOCTYPE request. That means any processing done that references those documents through XML may fail.
Here’s a quick triage: Do you do any XML processing of ONIX files? That would include validation of any sort that does or might rely on a connection to the DTD or Schema documents at EDItEUR.
If your answer to the above is “No,” then you should simply be aware that if something very weird and unexpected happens to some aspect of your ONIX creation in January 2015, it might relate to EDItEUR’s dropping its support.
Here’s a simple test if you’re not using a web-based solution: Disconnect the internet. Does your ONIX creation still work? If so, you’re gold.
If you said “Yes” to the original question, then you should be sure to install both the DTD and Schema locally. If you have installed both locally, you should make sure there isn’t still some routine that relies on the online documents.
Either way, that’s about the worst that can happen—something might stop working. And the solution is simple enough: install local files. There are exhaustive instructions here: https://booknetcanada.atlassian.net/wiki/display/UserDocs/DIY+Schema+Validation+for+Workmanlike+ONIX.
[Updated Jan. 13, 2015] EDItEUR has also published a note on the very simplest way to avoid any failures in processing ONIX 2.1 files after sunset. The workaround is straightforward, but will require some technical skill and administrator access to the relevent computers to implement. You can find instructions on using local DTD and XSD files after ONIX 2.1 sunset here.
2. Can I still send out my existing ONIX 2.1 file after December?
Yes. Anyone who is set up to receive ONIX 2.1 will continue to process files exactly as they are doing now. You should be much much more worried about making the transition to ONIX 3.0. Then you really must let your trading partners know and make sure that they can accept the file and use the data.
In BNC BiblioShare’s case: We want your ONIX 3.0 but only if you continue to supply ONIX 2.1. In our case, we can accept the 3.0 file, but because we store and serve out your ONIX as you deliver it to us, we can’t actually use the data. We don’t have uptake enough yet to set up services. So please, start supplying us both types of file as soon as possible so we can make the transition.
If you can only support one, then make it ONIX 2.1 for the moment.
3. I can do both, but how long should I expect to support ONIX 2.1 and ONIX 3.0 files simultaneously?
At some point, one of the large publishers is going to make the jump because they have a need of some the ONIX 3.0 features. When that happens, change will probably start happening a lot faster. Until then, it’s hard to say.
But the transition from ONIX 2.1 to ONIX 3.0 is largely one of supporting a higher level of accuracy to better support international sales. So if you’re a publisher, do you know (in an exportable way) what sales rights you hold on your products? Can you express (in an exportable way) the areas you’ve assigned to your “suppliers” (AKA distributors)?
One way to go about getting ready for ONIX 3.0 is simply to improve your ONIX 2.1 feed. Imagine you’re in another country, a long way away, with your ONIX feed. Does it really contain the information they need to know? If they had a feed from another source with the same ISBNs in it, would they have the information to differentiate between a conflict and a rights sale?
4. I’m a small publisher without an IT department. I’m concerned that I don’t have the resources (time, money, tech know-how) to upgrade my ONIX. What do you think?
“Deserve’s got nothing to do with it.” Sorry, I had to say that. You do what you can, but in a lot of ways you actually have it easier. You have a small number of books, so use your ONIX as an organizing tool if you can. Save time and money by using services like BNC CataList to make more use of your ONIX.
But really: ONIX is a B2B communications tool. If you’ve got trading partners who accept your ONIX then they are the reason you support it. And if you don’t, then you try to provide the primary data points commonly needed. Use BiblioShare’s Quality Reports to follow generally what those are.
5. I’m a retailer or library who accepts ONIX feeds. Is there anything I need to do to prepare for the sunset date?
Not really. If you can accept one type of file or the other, nothing will change except that you can’t get new codes added to ONIX 2.1. Please note that there is a slightly extended twilight to ONIX 2.1, with limited support for codelists through 2015.
If you’re looking to start setting up to accept ONIX feeds, and you’re confronted by the need to set up to support an outdated, no-longer-supported standard, then you may be part of the vanguard of change: The other driver for all this will be companies who refuse to accept metadata from an unsupported standard.
6. Honestly, I’m leaning towards just continuing to create ONIX 2.1 files and hoping for the best. Will something bad happen to me?
Nope. Well, avoid outhouses maybe, but probably nothing that bad. At some point, it may happen that a large retailer will say they don’t want your trashy ONIX 2.1 file. Or you’ll have a business need that makes you money that you need better metadata support for.
I can’t conceive of a scenario where you wouldn’t have at least a year’s warning. But I’m not in charge either.
7. I think ONIX 3.0 sounds like the greatest metadata advance since pointy brackets! But I haven’t actually made the transition yet. Can you point me towards the resources I need to get started?
Have a look at the North American Metadata Best Practices which likely covers off much of what you need.
Talk to your system provider and see what their plans are for ONIX 3.0 implementation.
Graham Bell of EDItEUR has a particularly good webinar on making the transition from ONIX 2.1 to 3.0.
EDItEUR’s Best Practices Guide for ONIX 3.0 (available here) is also superb. One of the central messages from Graham’s webinar is that the transition is not that difficult—at least if you have done the work suggested above in #3.
BookNet will continue to develop resources, but I’d say just get started and you’ll find the manual and best practices documentation actually explain most of it beautifully.
And of course, you can ask me directly if you have problems: biblio@booknetcanada.ca
