Book Metadata, ONIX, and Digital Asset Management (DAM) systems

Book Metadata, ONIX, and Digital Asset Management (DAM) systems

Book Metadata

Maintaining the metadata for your books can be quite a chore. Joel Friedlander's overview covers some of the basics.

It takes me two pages of my multi-page management spreadsheet to hold the simple columnar data (ISBNs, Library of Congress (LoC) numbers, publication dates, page counts, etc.) and textual data (blurbs in various lengths, keywords, BISAC codes, etc.). Some of that data is static, but parts of it are changeable based on marketing experiments, temporary sales, and so forth.

When we go to a distributor site that caters to indies, we are usually presented with a form to fill out for each book. Since I strive for consistency, I always have to open up the form for a book I've already posted to that distributor, to make sure I fill out all the questions the same way across all my titles.

How do the big boys handle this?

Well, that's a question, isn't it? It's hard to get the details. The big traditional publishers have complex internal needs (moving a title from acquisition through edit, formatting, marketing, publication) involving different departments and requirements, and their management systems are crafted with that in mind to give them a shareable single complex record for the title that holds both in-house private data and public data intended for use with their trading partners (distributors, retailers, etc.)

The output of their systems these days tends to be in the form of ONIX records (see below) — this much I know. But exactly how they share those records with their partners is obscure to me. (Alas, trad-published authors who've added indie-publishing share insights with us, but we don't meet a lot of back-office technical types from the traditional publishing firms.) You can see how vague the specific details are for an overview on metadata maintenance that's meant to be helpful, or for a discussion about refreshing metadata as things change.

The big traditional publishers have much more complicated problems. As indies or micro-publishers, we get to choose what we want to deal with, and some of the industry tools are available for us to use, if we think it's important enough.

There are some industry consultants, in particular Laura Dawson of Numerical Gurus, who make a specialty of covering these sorts of topics for their clients at a level that's useful for indies to understand, and if you have an interest in digging deeply, I recommend The Book on Metadata and The Metadata Handbook.

Why do we care?

Pretty obvious, isn't it? My book got to this site (Blio) via Smashwords, and whatever you may think of them, they can't supply what they don't carry. My “long description” (in the Smashwords form) appears as the “short description”, without formatting, and no long description is supplied for the Overview tab. Smashwords has no form field for Editorial Reviews.

The constant confusion between brief descriptions (synopses) which are usually plain text fields (no markup or linefeeds) and long descriptions, which should be rich text fields with HTML markup, is made much worse by the intermediate distributors who rarely make the distinction clear (i.e., “Only a single paragraph without markup for the brief description”, or “only these HTML tags are permitted for the long description”) and markup is often lost between trading partners. And that's if the form even offers separate fields for short and long descriptions.

While I don't know exactly how Stephen King's publisher gets the clean metadata to Blio, through what distribution channels, I know I want to look as much like that as possible.

ONIX

Quoting from a presentation:

• ONIX stands for ONline Information eXchange
• There are over 200 data elements
• ONIX is a metadata standard that publishers use to distribute electronic information about their books
• The information is distributed to wholesalers, brick & mortar stores, online retailers, and anyone else involved in the sale and distribution of books
• ONIX is not a database, but uses XML to organize data storage

ONIX is a relatively recent standard. Here's a brief overview of its history and uses — read this before continuing.

Since ONIX is an XML standard, the output is semi-human-readable XML records. But don't worry — nobody deals with the ONIX XML records directly. Everyone uses some sort of interface, an ONIX editor.

These examples are for a product called (inventively enough) ONIXEDIT.

Products like this may have simple forms for basic fields, advanced forms for all the rest of the fields, or cloud-based forms to accommodate shared data and different computer platforms.

The prices for the basic version at ONIXEDIT are well within reach of indies, but what would we use this for, other than as a substitute for our tired spreadsheets of metadata? After all, who can we send ONIX data to?

Recently, distributor PublishDrive announced that it would begin accepting ONIX records from its publisher customers, many of whom are indies. Distributor Streetlib already does this. Of course, the devil's in the details — what sorts of records, what fields will they handle, what they can send to their downstream partners.

DAMs – Digital Asset Management systems

There are a class of service providers that supply not just general title management systems but also specialist variants that handle ONIX services. One example is Firebrand, with its Eloquence on Demand set of offerings. In principle, what a system like that offers is to not only give you a platform for managing your title metadata, but also a way to distribute it to all your trading partners.

That sounds like just the thing I want — a single place to manage all my title metadata, and a simple way to get it to all my downstream retailers. But it doesn't work like that.

Let me explain…

Today I distribute via a variety of methods. In the past, I've also used IngramSpark and eBookPartnership.

Ebook

• Amazon (direct)
• Barnes & Noble (direct)
• Kobo (direct), and 11 downstream partners
• Smashwords (direct), and 6 downstream partners
• PublishDrive's 39 downstream partners
• (soon) Streetlib's several dozen downstream partners

Print

• Createspace (not-expanded), and all the participating Amazon regions
• Ingram LSI, and thousands of potential downstream partners

Audiobook

• AuthorsRepublic, and a dozen or more downstream partners

This is not all the partners available for my distributors — there's a certain amount of overlap — just the partners I'm using. And some of these downstream partners are themselves distributors (Tolino, Nielsen, etc.)

Now, of those 100+ retail partners (and thousands for print), wouldn't it be great if I could send them ONIX datafeeds with updated information? Remember, that can include the actual files (ebook, audio, print).

I spoke with Ingram CoreSource and Firebrand Technologies at some length about this possibility. The former is priced out of the reach of indies, but the latter is not, if we have enough titles to make it worthwhile. But it won't work for us, as indies — not at the moment.

You see, not all of our retail partners are capable of accepting an ONIX feed. Some need a spreadsheet, some need a special variant, and so forth. A distributor like PublishDrive or Streetlib has to take that into account. A system like Firebrand is a sort of wholesale distributor of ONIX data, and it can provide specialized services to take advantage of that. For example, it can consolidate sales reports for a subclass of the most popular wholesale partners.

In this sketch, I tried to lay out my naive understanding of what I wanted to be possible. The blue is for the Publisher's responsibilities. Firebrand sends the ONIX data to every one of the trading partners we identify who can accept it (DAM-enabled), with different variants based on the version of the product.

The reps at Firebrand were very friendly and spent time exploring this, because I really wanted it to work, but this sketch is wrong, in one obvious way. I'm not, for instance a trading partner with Blio (from the above example) — I'm a trading partner of Smashwords, who is a trading partner of Blio. I have no relationship with those “Ebook Partners” boxes above.

Each of my distributors has made whatever adjustments necessary to reach their outlets with some variant of an Excel or ONIX datafeed. Firebrand can't do that — it's not in the distribution business per se — it's in the ONIX feed business (for this particular product).

So what I have to hope for is for each of my partners from the list above to accept ONIX feeds (and for them to evolve to being able to keep that metadata clean all the way through to their retail partners.

Streetlib and PublishDrive may be the first, but hopefully others will follow.

If it's any consolation, many traditional publishers are grappling with the same issues. Read the article, and see just how messy getting the right data to the retailers still is.

Original article and pictures take hollowlands.com site