[UPDATE: The ONIX converters will be retired on Dec. 31, 2016. You can find out more here.]
Converting ONIX 2.1 to ONIX 3.0 is a very useful way to learn where “stuff” goes in ONIX 3.0, but publishers are often confused about why, once they’ve done the conversion, the resulting ONIX is just not good enough. I’ve been participating in arguments about this—and, as always, I’ve come up with a succinct explanation after the fact. Be happy you weren’t involved in my long ones!
A typical scenario in North America is a publisher supporting a “local” file: a file distributed only within that area. Such a file often says nothing about the world outside of its distribution—it just ignores it.
ONIX 3.0 strives to support including full information… by making it difficult to leave information out. The idea is simple: full information will enable end users to properly select the data and merge it with information from other markets. That’s a common need now. Any data recipient getting data internationally—and Indigo, Kobo, Bowker and BiblioShare all get international metadata—have the problem illustrated here.
Here’s a “local” Publisher and Sales Rights statement in ONIX 2.1:
<Publisher>
<PublishingRole>01</PublishingRole>
<PublisherName>North American Book Publisher</PublisherName>
</Publisher>
<PublishingStatus>04</PublishingStatus>
<PublicationDate>19890601</PublicationDate>
<SalesRights>
<SalesRightsType>01</SalesRightsType>
<RightsCountry>US CA</RightsCountry>
</SalesRights>
All that says is this is an active book from 1989 published by North American Book Publisherwith stated publisher rights for the US and Canada. Run it through a conversion process and it would appear in ONIX 3.0 as:
<Publisher>
<PublishingRole>01</PublishingRole>
<PublisherName>North American Book Publisher</PublisherName>
</Publisher>
<PublishingStatus>04</PublishingStatus>
<PublishingDate>
<PublishingDateRole>01</PublishingDateRole>
<Date>19890601</Date>
</PublishingDate>
<SalesRights>
<SalesRightsType>01</SalesRightsType>
<Territory>
<CountriesIncluded>US CA</CountriesIncluded>
</Territory>
</SalesRights>
So this is a one-to-one transfer of the information, with minor changes in format. ONIX 3.0 isn’t that different from ONIX 2.1, really.
What’s missing here is the ability for an end user to load the data reliably. Data aggregators can’t answer a simple question like: Is this the full rights statement for “North American Book Publisher”?
In ONIX 3.0 there is an expectation to provide “full” information—which, in an ideal world, would be an accurate world-wide sales rights statement but does NOT have to be. Here would be the preferred answer in ONIX 3.0 for a publisher or distributor who didn’t want to supply any more information. It contains one simple addition (bolded):
<Publisher>
<PublishingRole>01</PublishingRole>
<PublisherName>North American Book Publisher</PublisherName>
</Publisher>
<PublishingStatus>04</PublishingStatus>
<PublishingDate>
<PublishingDateRole>01</PublishingDateRole>
<Date>19890601</Date>
</PublishingDate>
<SalesRights>
<SalesRightsType>01</SalesRightsType>
<Territory>
<CountriesIncluded>US CA</CountriesIncluded>
</Territory>
</SalesRights>
<ROWSalesRightsType>00</ROWSalesRightsType>
That final line explicitly states that the sender of the ONIX is NOT supplying more detail—outside of the US and Canada the sales rights are “unknown or unstated for any reason.” With that addition, the end user can now reliably use the data because they know the limits of it. They can merge this data with other files speaking to other rights and markets.
In short: The data recipient doesn’t have to assume things based on the file source but knows them based on the metadata.
The reason why conversion does not work is because ONIX 3.0 without that addition is a bit pointless. It’s just ONIX 2.1 data without any additional clarity.
Why can’t a conversion just add that, then? It could, if you knew all the files you were converting needed it. That means the converter would need to be written to suit each company using it, though, and that’s a lot of work—no different from mapping their database into ONIX 3.0. That one line has to mean something to be useful in data exchange, and the only one who can supply it is the company that sends it.
So clarity doesn’t require new information, it just requires the sender to be explicit—and being explicit is a requirement for “good” ONIX in 3.0. The above is just one example, though, and ONIX 3.0 has many similar tweaks to achieve the same ends in all areas.
What’s needed is for publishers to actually improve their metadata by supporting new detail and accuracy, so bite the bullet and say yes to supporting new data that can help retailers sell your books. Even when you just shoehorn your 2.1 into 3.0 as your starting place, that process will have already begun, even if nothing has been added.
What’s a really good use for conversion tools?
Use conversion tools to help you create a map from your database to ONIX 3.0, so you can see where stuff goes. And then use that as a guide to the manual and documentation to make sure you’re using your ONIX 3.0 clearly—adding values to “select” by.
Another thing everyone wants to know is when to start converting. Well, the process has begun! BiblioShare is receiving ONIX 3.0 “production” files now. We’re only getting them from two publishers to date—a third can start anytime! We do want to see more ONIX 3.0 files, but only if you can submit ONIX 2.1 and ONIX 3.0 simultaneously. Why? Well, we need to figure it out, too, in order to help you.
Help us help you by giving data today and regularly. Print, digital, 2.1, 3.0… BookNet Canada believes you can never know too much.
Go play:
http://booknet.gogpg.com/ONIX2toONIX3.aspx
And when you’ve made your ONIX 3.0 better and have systems that can supply it regularly, then send it to us!
