I’m very pleased to announce that a new, fully updated version of the joint BookNet Canada /
Best Practices for Product Metadata
guide, including guidance for digital products and ONIX 3.0, has been released:
Best Practices for Product Metadata: Guide for North American Data Senders and Receivers.
Download it for free from
or
.
A Little History
It’s no mean feat to update such a venerable standards document. The last edition of the guide was released in 2005, and it has been the basis for BookNet’s and BISG’s data certification programs ever since. This update is the result of almost two years’ work from a wide range of publishers, wholesalers, and data aggregators—including detailed input from
itself. For a full list of what’s new, please
check out BISG’s press release
.
We’ve done all of this because we, the royal We of the industry, want you to take this guide seriously. The new edition will underlie our ongoing data certification programs, and BookNet will celebrate by updating our BiblioShare File Quality Reports—look for more announcements on
that
over the next few months.
What Next?
Since this 194-page tome is the bible for North American metadata exchange, I thought an obvious blog topic was: What does the publishing industry expect you do with this thing? OK, yes, you should obviously read it and live by it. But
how
do you live by these updated standards? Please get a paper bag before reading on. (Trust me.)
Step One: Preparation
The first trick is to remember that this isn’t the only bible out there. The first of its general guidelines (p. 7) says: “This document is not a substitute for EDItEUR’s
ONIX 3.0 Implementation and Best Practice Guide
.” So be sure to download EDItEUR’s guide. While it focuses on ONIX 3.0, nearly all of it (outside of the actual example scripts) can be applied to ONIX 2.1. In short, this is your working guide to ONIX theory. A quick pointer: the blue boxes summarize each section’s major points.
I can hear hyperventilation. Breathe into your paper bag. This is the point of this blog post: How do you absorb all of this? Simple: In chunks and stages. These are reference documents, not literature.
Step Two: Start with the Table of Contents
Take a look at the table of contents in the
Best Practices for Product Metadata
guide. It’s a list of 32 core topics that the North American supply chain experts have identified as the most important elements in our “local” metadata.
Note:
If you haven’t yet got an ONIX program going, you will probably be using software or some industry guidance to create a starter ONIX file. Use that as your guide to these guides. If you already have an ONIX program in place, you can start with your own ONIX file.
Step Three: Decide What Product Metadata You Support
This step is subtler than just looking at the database that feeds your ONIX file. Think of it this way: You already track multiple data points for your business, some because they’re legally required, others because they provide critical information about how you make profit. Product metadata is a specific subset of your overall business. It’s the low-hanging fruit of metadata, but it’s still your business knowledge overlaid on the products you sell.
When you’re deciding whether to support a given field in your product metadata, the real question is: Does this communicate what I—
and my trading partners
—need to support my business? That’s what’s in the
Best Practices
guide: what industry experts say your trading partners need (and reasonably expect to find) in your data. So think about that as you read the two or three paragraphs in each section of the
Best Practices
guide that define the business case and tell you if the data is mandatory.
Now: the moment of truth. Ask yourself: Do my systems support this business case? Can my trading partners use this data for the purpose described here? Think carefully: “maybe” is not the same as “yes.”
Step Four: Compare Your ONIX to the Standard
Now look at your own systems and the ONIX file you produce. If the ONIX standard allows you to break core data points into smaller components than you support, ask yourself whether these granular data points are relevant to your company and your business partners.
This is where the
EDItEUR Best Practices document
can be extremely useful: It explains what the ONIX standard is tracking, and why. Its “international perspective” demonstrates why tracking publisher information and rights is different from tracking market-specific information. Maybe you need to do both.
Finally, look at what data points your records don’t support. The question is the same: Are any of these points applicable to your products, and do you need to be supporting them?
If you make it through this exercise, and search your soul, you will probably have to face the difficult truth that some part of your metadata program doesn’t live up to the ideal. There will be parts of the “core” you don’t support, or support but not well. It’s OK—best practice documents implicitly encompass that there are other than best practices… and we all appear as sinners in a bright enough light.
Conclusion
The point here is that publishing metadata is exchanged between businesses and used to enlighten consumers about what you sell. Not every business needs to track the same things. No business has the internal structures to track every data point to the same extent.
And that’s the point of the
Best Practices
guide: It provides a summary of what other companies are looking for and why. If it’s important to your business and its ability to make money and you’re doing it badly—well, you don’t need the confessional booth offered by BiblioShare’s File Quality Report, do you? Just follow the guides to do metadata better. And look for updates, because best practices change.
