We all know images are worth thousands of words, so what happens when there is silence? Often it means that you have to do some asking.

We frequently receive emails at BookNet wondering about missing cover images. The email goes something like this: "Can you investigate why there’s no cover image for book X?" These emails are what I consider a kind of situational irony. Why? Well, it’s often the publisher of the book, the creator of the CataList catalogue, or the owner of the copyright who is asking about their missing cover image.

Admittedly, our method of ingesting and serving up cover images, interior images, back covers, and author photos can be confusing. That’s why in this new instalment of the Easier with BookNet series, we’ll share "troubleshooting" tips that will make distributing your images easier and more effective.

How BookNet gets images

Let’s start with how we get images. It’s very simple.

Everyone who is providing data to BiblioShare, BookNet’s quality-controlled data aggregation and distribution system, is assigned a directory on our FTP server. Since there are two versions of ONIX at play in the supply chain, and they’re not backwards compatible, we provide most users with two BiblioShare accounts on the FTP server — one for the 2.1 data and one for the 3.0 data.

This is one area where we often run into some confusion. Providers need to give us the 2.1 data if, for instance, they want to see it in any of our other products like CataList, or our Shopify plugin, as these products are still mostly populated by ONIX 2.1 data.

That said, the ONIX 3.0 data needs to be delivered to the 3.0 directory on the FTP server. This directory requires a different login from the 2.1 directory — for now.

The 2.1 directories and the 3.0 directories contain the same file structure. An ONIX folder for the ONIX data, an image folder for — you guessed it, images, a position folder for what we lovingly refer to as PANDA (price and availability data), and a sample directory with more nested directories for everything from samples, reader guides, and teacher guides to table of contents and excerpts.

What we want clients to know

The trick is that we don't need clients to duplicate the delivery of that rich content that exists outside of ONIX.

All of our file naming protocols for this extra content are based off the unique 13 digit ISBN for a title and a little flag to indicate what type of resource it is. I.e., is it a cover, an interior, an author photo, a back cover? Let us know in the file name according to our naming protocol. Or (yes with BiblioShare there’s always a very flexible "or"), you can just drop the file named simply with the ISBN into the correctly named folder. This basically does the same thing as naming the asset with the correct flag.

It isn't actually that hard to figure out and yet we often see mistakes in the naming of a file, or a file gets placed in the wrong directory and suddenly your cover image is showing the third page of an interior image or something like that.

And to further complicate things on the rich content front, ONIX enables users to add codes and links for media that they’re supposed to be hosting on a webserver somewhere to the Media composite. Some companies loading data to BiblioShare will rely on these links to provide things like cover images, etc. (see code list 38 for all the available types), to their trading partners. They never load images to the FTP on BiblioShare, instead we have a bot that that goes out to all those links and if the links are valid the bot will pull down cover images, etc., and presto — now they are in BiblioShare.

Where things can get confusing

As you can see, these various methods and variations can become confusing. Some users are confused by the fact that we have their content when they haven't uploaded any covers. Some are confused by the fact that we only have some of their content. These are the MediaFile code providers. They don't really know what the frequency of the bot crawl is and they don't necessarily know how to get their content to us faster when there’s an issue. They could just upload it to their BiblioShare FTP directory and the issue will be resolved almost immediately.

Then, of course, they may fall victim to the confusion around the two different BiblioShare accounts that we have to implement for ONIX. However, I should make it clear that even if you do put your images in both of your different directories — BiblioShare doesn't get confused.

We process and make available only one image based on the ISBN. Last one in is the one that gets delivered. The reason not to put them into both the 2.1 and the 3.0 directories is that it makes your workflow less manageable.

How to know if BookNet has the correct files

BiblioShare being both stubborn but also very flexible provides a couple of ways to check your content.

Bibli-O-Matic — This shows you almost everything you need to know about what we have for your book — we show you the covers, the interiors, when the ONIX data was last loaded to BiblioShare, links to CataList, to SalesData, and more. I really recommend Bibli-O-Matic for use all over the place — it’s my go-to plugin for troubleshooting.
BISH Asset service — This service opens the window into all of the content we have for the title in question. It can be accessed via a browser with the correct parameters in your http request — essentially the ISBN and service type flags that are required.
When you call the BISH Asset service the response will show you if we have a 2.1 record, a 3.0 record, a position record, and any of the content I've been writing about above — covers, interiors, samples, and more.
The payload also shows you when each of those assets was processed into BiblioShare and the dimensions and file sizes for any images — always a handy way to compare image files! So use this service for your investigation into your holdings in the ever growing and widely used BiblioShare platform.

Of course there are other services available to check your images as well. As I mentioned BiblioShare can be extremely flexible and generous. There’s the ImageInfo service, the ImageList service, and a kind of reverse BishAssets service we call ISBNforAsset service. This allows you to get a list of the ISBNs for any given asset stored in BiblioShare. More information about these services is available here.

I know there are other questions around images — like how do you apply your alt text for your images so that it's delivered along with your images. That is a blog post for another day. In the meanwhile, have a question about not seeing something? Arm yourself with our APIs and never be in the dark again about any of your ISBNs in BiblioShare. Don't see the data for the asset that you're expecting? Then just upload it to the correct folder in your FTP directory and watch the magic work.