What Happens When My Metadata Leaves The House, Part II

In a previous post, I talked about the issues surrounding getting your data ingested by third parties. This week, let’s think: What are some of the issues around sending OUT metadata?

Relationships

We have systems, which can be outdated, chaotic, and incompatible. We have a functional process – who does what when – which is riddled with exceptions. And we have a single source of truth that holds all the most updated information, but has to export that information in a lot of different ways.

Relationships are what get us through the gaps in tech, staffing, and standards.

This industry was built on relationships: Agents knowing the tastes of editors. Marketers knowing the tastes of bookstore buyers. Editors knowing what works for library acquisitions. Human relationships – our work friends – keep this industry in business in the face of imperfect systems. And that’s not appealing to some folks – which is also why we have a thriving indie scene with relationships of its own – some see these relationships as forming a gate-keeping system, a sense of exclusivity.

But for the most part, the relationships are there to smooth the bumps in the workflow. Sudden price change? Call up your vendor partner at B&N. Want to test out an idea for a project? Reach out to the collections development librarian to see if she thinks it’s viable. Need to recall a book or cancel a publication, and the ONIX feed may or may not get ingested? Call up your trading partners and they’ll do a manual update to their records.

Our relationships are the hack that makes it all work. The relationship between publisher and bookseller existed before there were systems to facilitate information exchange.

So, as with any relationship, communication is the highest priority. Much of that communication is automated with metadata transmissions – but as with anything automated, there are going to be exceptions that have to be dealt with manually. Which means an email or a phone call, or an in-person chat at a conference to gain or give clarification about what’s expected. Maybe the answers aren’t what we want to hear, but at least we know how to solve the problem.

I’d like to say that the one thing we can all count on is that everybody in the business wants it to work. And in most cases that’s true.

You do have the “digital disruptors” – Apple, selling devices; Google, selling ads; Amazon, selling everything – who don’t necessarily have the book industry’s best interests at heart. And that’s where we’re experiencing the greatest friction. It’s not necessarily with computer systems. It’s with market systems – when our world is disrupted not by ebooks, but by (for example) a vendor using our product as a loss leader; another vendor who is uncommunicative and not at any conferences/standards meetings; another vendor whose founder didn’t even want to sell books in the first place because “nobody reads anymore”.

We can’t NOT do business with these folks. But we are the little guys here, and that’s a reality. This is WHY we have to deal with competing vendor requirements – books might be a small fraction of Amazon’s business, but Amazon is a LARGE fraction of OUR business.

So how can we improve our relationships with these partners?

Well, on some level they do want things to work as well, or they wouldn’t be selling our books. And maybe, in addition to trying to school Google in the wacky ways of book publishing, we need to learn from Google about the also wacky ways of tech.

The other thing to note is that these companies DO hire book people. The folks at Google Books are longtime publishing operatives – from HarperCollins, B&N, Scholastic and Harvard University Press. Amazon regularly hires out of the NYC book publishing pool. And the iBookstore is staffed by people from Simon & Schuster, B&N, Oxford University Press, and other traditional publishing companies. So the encouraging thing is…we are infiltrating. There really ARE like-minded people at these companies. They seem (and feel) like faceless organizations, but they are not. That’s a myth that we’ve been telling ourselves for over 10 years.

Best Practices

What we’d consider best practices can vary depending on who’s consuming the metadata.

BISG has published a document on best practices for product metadata in the book supply chain. That’s a good foundation for bookselling – obviously the vendor requirements will differ as they compete with one another. Of course, Amazon doesn’t participate in hammering out these best practices, so they’re not perfect. But it’s a good guideline to begin with.

For non-bookselling purposes – libraries and other institutions – the idea of “best practice” gets a little murky. Resource Description and Access (RDA) was created by an international association of library organizations as a set of guidelines for cataloguing resources (books and other things). RDA can serve as a good foundation upon which to build library metadata.

Some systems vendors also do educational sessions where best practices are reviewed: Firebrand, Klopotek, Iptor and Ingenta all have user conferences or webinars for their clients that go over market needs for metadata and standards. And of course there are trade shows like ALA and BEA which also have conference tracks.

Basically, if you get out there and start talking – and you might not have to go places physically, if budget is an issue – you can get a conversation going. Maybe others are having similar problems to you. Maybe there’s a solution someone knows about. To some degree, we compete, but as an industry we’re also really good at helping each other.

Leave a Reply

Your email address will not be published. Required fields are marked *