Return to IBPA’s Ask the Experts
Topics Discussed Below Include
Book Conversion to ONIX / XML vs. HTML
I have two questions: How do I go about getting my book converted into ONIX? In Canada we have a program called the 49th Shelf, but my file has to be in ONIX to be accepted. What is the difference between xml vs. html?
ONIX (Online Information eXchange) is the standard markup language adopted by the book industry, worldwide, for metadata (basic information in electronic format) about books. In the old days, publishers printed catalogs, as did distributors, wholesalers, etc., and these were filed in various places so that a book could be looked up by anybody interested in it. Now, hardly anybody in the book trade keeps printed records–it’s all electronic. Electronic records can follow any number of formats, but it’s most convenient for everybody if the same format is used for all trade books. The industry settled, years ago, on ONIX as the format. ONIX is a very specific XML database. In theory, if everybody who publishes books creates metadata in ONIX format, then every book database can find it and can know everything that you–the publisher–would want people to know about the book. With millions of new titles published every year, positioning your book so that people can find it is important.
Book publishers tend to be slow in adopting changes, so not every publisher–and certainly not every small publisher–has yet come around to this, even though it is clearly in publishers’ best interests to do so. But Canada is far ahead of the US in this. My understanding is that in Canada, if you want to be carried by Indigo or even most independent stores, you need ONIX data.
XML is similar to and related to HTML. Without getting into the technical issues, XML language is very exacting–any error causes it to mess up. As I’m sure you are aware, HTML has a huge amount of tolerance for errors–most Web sites have errors that most Web browsers ignore. You don’t have that luxury with XML data.
ONIX is an XML database specifically for books. It has a standard set of fields that need to be filled out. These are things like number of pages, copyright date, ISBN, authors, illustrators, price, etc. There are far more fields than most people will ever use, but an effort is made to accommodate everything anybody might want to know about a book. You can include information about your promotions, for example, and reviews, Table of Contents, excerpts, trim size, paper quality, etc. If you have a specialty book with edible covers and pages that fold out to become a teddy bear, there are probably fields to fully describe that, although they may not be fields that are looked for by every wholesaler.
Typically, a publisher prepares ONIX data and submits it, on a regular basis, to to their business partners. In the US, that typically means Ingram, Baker & Taylor, Barnes & Noble, and other store chains, wholesalers, etc. For new books, the submission is normally several months ahead of the pub date, but these can be update regularly.
Many small publishers who work with trade distributors have the ONIX submissions done by their distributors, as they handle all trade sales anyway. (In my case, my books are distributed to the trade by Midpoint, which handles my ONIX submissions, but I also produce my own data, which I add to databases not on Midpoint’s list, such as the Library of Congress and various Web sites.)
Many bigger publishers hire services, such as Media Entities or Firebrand, to manage their metadata. These can do a very good job, but may be out of the price range of little publishers. The advantage of a service is not just producing the data, but knowing which fields need to be filled out for each of the major recipients, who to send it to, how often they want it updated, etc. Their submissions are automatically accepted by all the big trading partners, so they don’t get a call back from, say Ingram asking “who are you anyway and why would we want your data?” The services can save a lot of hassle, but, again, it’s not cheap.
I should add, though, that metadata are more than just the ONIX information files. They are often tied in with EDI, the automatic ordering systems used by the major wholesalers and chains. (That’s another story, of course.) But once you have everything you want people to know about your book in data form, you’d be crazy not to use that data for other things as well.
In my case, I create metadata with a cheap, simple-to-use program called Couplet. Couplet can be run independently, but it can also be used in concert with Publishers’ Assistant, which handles my order-taking, billing, taxes, royalties, etc. That way I don’t have to have my title information entered into two separate software programs. The same database automatically handles all of the book information and shopping cart on my Web site. I don’t do full print catalogs any more, but if I did, I could export it for that too. There’s no longer any reason to keep entering the same information over and over into separate listings and databases.
Publishers Assistant is free if you don’t need paid user help. Couplet, purchased independently, costs $99, or comes at no charge for those with a maintenance agreement of $35 a month for all user help, upgrades, etc. for PubAssist. I mention this only to communicate that there are ways to handle this yourself, affordably. I also need to add a disclosure–I am the the publisher of the software. It is a very small part of my business–I am primarily a book publisher–and the software is handled primarily in partnership with the chief programmer. There are undoubtedly other great software solutions out there, but I mention Couplet because I use it and I have not researched any others.
I also know a few publishers–who have only one or two books–who program their own ONIX submissions. For those with the skill and patience, that is a viable option. But the codes are lengthy, and, as I mentioned, there is no tolerance for error. The coding information, though, is readily available–nothing is secret or proprietary.
You can get much more detailed information online, of course. While the ONIX standards are agreed upon worldwide, each major nation is represented. In the US, it’s the Book Industry Study Group (bisg.org). This is a very helpful group, which will even test your data to see if it meets the standards.
Canada, as I said, is further advanced in this. I think the best source there is BookNet, which even supplies templates you can fill out for the various versions of ONIX. Check it at <http://booknet.gogpg.com/>.
The version issue can be a bit complex. Some of the folks you will submit to are not set up for the latest version, and it is not backward compatible. Therefore, most of us don’t use the latest version until it becomes more universally used. If you have an older version, it can be read by a wholesaler or other recipient who uses a newer version. That said, the newer versions may have features you want and need. For example, the newer versions are much better for handling data on e-books.
This is just an overview, of course, but I hope it’s helpful. For most of us who don’t do our own programming (and I don’t, even though I publish some software) a general understanding is all that’s needed in order to make informed choices.
~ Steve Carlson is co-founder and publisher of Upper Access, a small conventional (royalty-paying) book publishing company in operation since 1986. He also publishes business software for fellow book publishers. He has served on the board of IBPA and is currently active with its New England affiliate, IPNE.
We hope you will find this program useful, but as with any advice, we recommend that you make sure it fits your specific business needs. IBPA does not specifically endorse or support any particular group or service.