We were overjoyed to welcome lots of eager publishing professionals to our new board room for two days of ONIX training with EDItEUR's Graham Bell this week. With one day down (ONIX: Essentials) and one to go (ONIX: Advanced Topics), we can truthfully report that Graham really knows his stuff. A few highlights, if you will:
ONIX is an 'internal data bus' for transferring information through the data supply chain
Who doesn't love a succinct metaphor? Graham started things off with a quick introduction to book metadata — "all the information about your book that might be used to help describe, create, trade, promote, and sell it" — and moved on to describing how ONIX facilitates the transfer of that information amongst trading partners (and readers). If you're not sold on using ONIX as a shared language to efficiently and accurately communicate book metadata, consider this scenario: You're a publisher sending metadata for your titles via Excel, but some retailers need your files in XLSX format and others in XLS. As a result, you employ an Excel jockey to stay abreast of these various caprices and after a few months they lose the will to live. Enough said.
Honourable mention goes to data aggregators (like BookNet!) who help to shepherd the exchange of data and add value through validation so you know your ONIX files are getting the job done.
Data needs to be kept up to date, for everyone's sake
Graham made a point of demonstrating how one cog in the data supply chain can cause confusion (and lost sales) for everyone. Even in a data ecosystem where all trading partners are using ONIX to share book metadata, one retailer choosing not to update their metadata feeds on a regular basis (daily, for instance) can result in consumers getting confused on basic points like list price and publication date, which can quickly go from accurate to inaccurate with just one day's worth of new data being lost. The consequence? Potential book buyers see discrepancies between retailers or other displayers of metadata, get frustrated or want to know why they're getting conflicting information, and sales are lost. So for everyone's sake, keep those ONIX feeds up to date.
Who owns metadata?
One of the attendees asked an interesting question right off the bat: "Who owns metadata?" You may be quick to assume that the publisher who created the ONIX file owns that data. But the answer is actually a bit more complex than that. To start, it's not possible to copyright basic mechanical facts (like the author's name or the list price), though things like a short description can feature content that is copyrighted. However, by sending out that data in an ONIX feed, the publisher gives implied permission to all end users of that data to publish and modify it as they like. Also, contractual terms and conditions between trading partners can often stipulate the right for the end user to modify the metadata. So, while creators do have some authority over the data they send out, the information supplied through book metadata is really intended to be used and modified in whatever way best benefits the marketing and sale of those books — after all, that's what it's for.
A compelling argument for transitioning from ONIX 2.1 to 3.0
Are you supplying book metadata and still using ONIX 2.1 because you feel it's still working for your business? Well, Graham would like to point out to you that the 2.1 standard was developed way back in 2003. So, you should ask yourself this: Is your business still the same as it was in 2003? *mic drop* (Learn more about moving from 2.1 to 3.0.)
Who says ONIX is complicated?
A quick sojourn through the wild world of contributor names (from sorting family names like "O'Connor" and "d'Aberville" to dealing with special titles) led Graham to remind the class that, if you think the structure for ONIX for Books is complicated, just remember that it's not nearly as complicated as actual real-world complexity.