Looking for an easy way to speak to your colleagues and higher-ups and make the case to transition to ONIX 3.0 from 2.1? Trying to make the case for a return on investment? The BookNet staff team contributed their favourite business case reasons to transition, collected below!

3.0 supports regional information about contributors that media, retailers, and libraries crave

It’s no secret that retailers and libraries, not to mention schools and media, want to support local authors and illustrators and tell the stories of their communities.

We’re already leveraging that data in BNC CataList, where the <ContributorPlace> composite helps us display both the residence and the hometown for contributors. This data allows site users to search and filter results to bubble up contributors with regional affiliations. <LocationName> is particularly appreciated to support local authors and is unique to ONIX 3.0.

How the elements of the <ContributorPlace> composite work together, according to EDItEUR’s ONIX for Books: Implementation and Best Practice Guide:

Although the ONIX schema allows use of both Country and Region codes together, it is strongly recommended that only one or the other is used in a particular <ContributorPlace> composite. Region codes already include the relevant country designation. A location name cannot be used without also including either a country or region code.

Open

Example: designating a contributor as Canadian & indicating residency

This contributor is a Canadian citizen who currently lives in Newfoundland & Labrador, specifically in Stephenville.

Where it gets exciting is that <ContributorPlace> is repeatable, which means you can identify multiple geographical locations, and that <LocationName> is added in 3.0, which is a text field that allows data suppliers to indicate specific cities, neighbourhoods, etc. While <ContributorPlace> in 2.1 supported country and region codes, <LocationName> offers the ability to narrow down and provide even more detailed information. Moreover, <ContributorPlaceRelator>'s codelist is expanded for 3.0:

You will note that codes 09, 10, and 00 are exclusive to 3.0 as 2.1’s code list for Contributor place relator is frozen at issue 36, while the current codelist for 3.0 is issue 50.

Wondering why we’re especially interested in promoting Canadian authorship? Read BookNet Canada’s President & CEO Noah Genner’s blog post “Canadian authors: The whys and hows of identifying them in your data.”

3.0 presents information about series & sets better than ever before

ONIX 3.0 completely re-works Product title and Collection unlocking the ability to communicate information about your sets and series better than you ever have! The transition from 2.1 overhauls the concepts of “series” and “sets,” replacing both with the superior term “collection.” The best place to start? Review EDItEUR’s comprehensive reference document available here, but we’ll summarize some of the key points.

As defined in EDItEUR’s ONIX Glossary of Terms:

When followed, ONIX 3.0 allows for greater clarity without duplication of materials in a way that allows for improved use by retailers and data recipients. BookNet Canada’s metadata guru Tom Richardson documented major changes to how sets and series are handled in ONIX 3.0 in his 2018 blog post: we recommend reading it to better inform your transition as it flags the relatively small changes from ONIX 2.1 that 3.0, including enhancements to the <ProductPart> composite that is widely supported by retailers.

Finally, something big that will satisfy purveyors of branded products: support for brand names is now covered off in the handling of series and sets through the <Collection> composite. This means you can clean up all those subtitles and put those brand names where they belong: in the <Collection> composite, as a “master brand” represented as code 05 in <TitleElementLevel>.

What’s a “master brand?” Glad you asked!

The title element names a master brand where the use of the brand spans multiple collections and product forms, and possibly multiple imprints and publishers. Used only for branded media properties carrying, for example, a children’s character brand.

Example: indicating a brand name distinct from a series name

This book is an early reader title branded as Mattel’s Barbie toy collection.

There’s much more to say about collections and the opportunities offered by ONIX 3.0: watch this space for a post by Tom Richardson on this very topic! Sign up to BookNet Canada’s eNews or add the Blog’s RSS to be notified.

Supplying information about markets and suppliers has never been simpler

One of the most significant changes between ONIX 2.1 and 3.0 is the revision of the product supply chain information, which is communicated in Block 6 in 3.0. We won’t summarize all the changes as EDItEUR has a comprehensive reference document available here that is essential reading. There are some key takeaways that can help you exploit this block.

The concept of “market”

ONIX 3.0 introduces the concept of a ‘market’ and the particular supplier operating in it. Because a product can be sold in more than one market and the distinct supply chains in each, it’s necessary to specify availability and suppliers for each unique supply chain.

Block 6 publication dates' supremacy

ONIX 2.1 users will be familiar with the many publication dates that must be included in a product record. Block 6 allows sophisticated date management across multiple markets and, accordingly, suppliers. What’s important to note: Block 6 publication dates have supremacy over any publication dates provided in P.20 and P.21.

The uniqueness of the <Territory> composite

You will note that <Territory> is peppered throughout an ONIX record, popping up in <Market>, <SalesRights>, and <Price>. It defines a distinct geographic area and contains the elements <CountriesIncluded>, <RegionsIncluded>, <CountriesExcluded>, and <RegionsExcluded>. When handled correctly (that is, to say, with consideration and accuracy), there is infinite potential to specify the broad international handling of a book in a single record.

Bringing it all together

The organization of Block 6 can be summarized by the following table of elements from EDItEUR’s documentation:

This block is so great, it’s House of Anansi Press' favourite ONIX block:

The efficiency of the <ProductSupply> block is great. It allows for more detailed metadata regarding suppliers, markets, prices, etc., while giving the receiver of the ONIX a clearer view of the information with clearer language.

Want to scope out some of House of Anansi’s best-in-class metadata? Install the BookNet Canada Chrome extension Biblio-o-matic, hover over one of their ISBNs on any website, click “View ONIX record,” and check out some sweet bibliographic excellence.

3.0 offers full support for digital & open access products

ONIX 2.1 started development before the turn of this century, before it was clear that there was consumer demand for digital products. ONIX 3.0 enables implementers grappling with a modern sales environment, one dominated by online sales and discovery, and one that isn’t restricted by geography.

One such enhancement 3.0 provides is detailed pricing options such that one record can support different channels; essential for supporting sales of digital products. You’re reading that correctly: one record can provide detailed price level options for all pricing models and types, including country by country pricing.

There is support for:

• Promotional pricing, including start/stop dates

• Options for release timing

• Multiple tax rates

• Multiple discounts

• Subscriptions

• Licensing

• Rentals

• Free and promotional products

Simply put, if you’re selling internationally, digital or print products, ONIX 3.0 covers it all.

Moreover, ONIX 3.0 allows for the inclusion of information that could not be expressed through 2.1, including:

• DRM and other constraints (including not having it)

• Enhanced digital products

• Accessibility

• Bundles

Interested in learning more about the difference between digital products and how they’re handled in ONIX 3.0 vs. 2.1? Read the FAQ here.

Target your marketing content for specific audiences

Marketing is worthless if not targeted to a specific audience. You or your marketing colleagues may agonize over the precise timing and placement of ads, the distribution of promotional materials, and identifying who will engage with what, when. Metadata is marketing. Just as marketing personnel wants to target specific audiences to promote your books, so should you want to support them in your metadata fields.

ONIX 3.0 offers data providers an opportunity to target marketing messaging and materials through the introduction of the <ContentAudience> element in the <TextContent> composite, a repeatable element that allows a data sender to communicate specific messages to specific audiences, for example, retailers, librarians, teachers, students, etc. Each of these and more can be specified through the selection of a code from list 154.

Let’s take a look at that list:

Additionally, it’s important to note the suggested use for <ContentAudience>:

The <ContentAudience> element must be used to specify that the text in a particular repeat of the <TextContent> composite is intended for a specific audience – typically, most text supplied is unrestricted and suitable for all audiences, but the <ContentAudience> code is particularly important where the text is intended exclusively for trade or press use, or where the text has been tailored for a specific set of potential customers.

The savvy reader’s mind is blown – we know. Imagine the possibilities! When matched with the potential <TextType>s in list 153, the potential for precise, differentiated content to reach the desired audience is almost endless. Let’s take a look at that list:

Mix & match <ContentAudience> with <TextType> and you’re going to have some very happy marketing colleagues. After all, happy colleagues, happy life!

If you’re interested in how metadata collaboration between departments can be optimized, check out Harlequin’s holistic approach to metadata management on the BookNet Canada blog or on YouTube.

3.0 encourages you to flex your promotional events hustle

For marketing personnel and the people who love them, Block 7 Promotion detail will make your dreams come true. All that work your colleagues put into planning attention-grabbing events for your books and authors? ONIX 3.0 allows you to spotlight these efforts in your product metadata. If the event is designed to promote the book, it should be included! And why wouldn’t you want to?

The <PromotionDetail> composite is comprised of the <PromotionalEvent> composite, and its repeats. Each repeat is designed to be a unique event, where multiple stops on a traditional author tour would be represented in a single <PromotionalEvent> composite, with significantly different events (for example, featuring a different agenda, additional contributors or personalities appearing, etc.) represented by unique composites for each in their own <EventOccurrence> composites.

The structure of these two composites allows a data provider to share detailed information about specific events:

The <PromotionalEvent> composite	The <EventOccurrence> composite

The <PromotionalEvent> composite	The <EventOccurrence> composite
Open

All of that to say that anything and everything about your events can be communicated to data recipients in the <PromotionalEvent> composite:

• the name of the event

• the type of event

• its target audience

• the participants (including any/all <Contributor>s, <NameAsSubject>s, and participants specific to the event and not the product itself)

  • participants specific to the event will require their own <Contributor> composite associated with the <PromotionalEvent>, not in the P.7 Authorship composite

• logistical details of the event in the <EventOccurrence> composite:

  • the status of the event

  • the date and time of the event

  • information about the venue (if a physical event, information such as the venue name, address, accessibility information, rules, etc.) or the access information (if a virtual event, information such as the URL)

  • sponsorship information (if applicable)

This Block and its <PromotionalEvent> composite are the stuff of dreams, truly. Media, bookstores, and libraries have long requested data about book events to anticipate and respond to local demand. Providing this in a standardized form through product metadata saves time across the publicity, sales, and marketing departments of many publishing houses!

The use of Block 7 comes with a caveat: as this block is newly introduced (2019), not all data recipients who accept ONIX 3.0 have the capacity to ingest Block 7 information. Anytime you modify your feed to an existing data recipient, make sure you discuss this with your trading partners before sending it.

If Block 7 is your next homework assignment (and it should be!), bookmark BookNet Canada’s metadata guru Tom Richardson’s post on the BookNet Canada blog about promotional events.

Showcase your contributors' accomplishments independently from the book’s

The last one on our list is a small addition but one that will make metadata nerds very, very happy. If you’ve ever cringed when adding author prize and nomination information under P.17 Prizes, you’re in good company. 3.0 will settle your ONIX compulsions like nothing else! We’ve mentioned this in a previous blog post, but we’ll go into detail here.

What you need to know is that ONIX 3.0 recognizes that prizes for a contributor may be awarded distinct from the product expressed in the ONIX record. In 3.0, there are two places to include prize information: Block 1 (Product description; in P.7 Authorship) and Block 2 (Marketing collateral detail; in P.17 Prizes).

P.17 Prizes

First up is the section you know well from 2.1: prize information for the product in question. As you’ll know well from EDItEUR’s Best Practices:

For literary prizes and other awards, best practice is to list key prizes and awards gained by the product itself – or perhaps more often, by the work manifested in the product. So for example a literary prize awarded to a work when the hardcover was the only version available, applies equally to the softcover, and should be listed in the ONIX Product record for both versions. However, an award for exceptional quality printing and binding likely applies to only one version, and should not be listed on the other. If a product has been awarded nothing (so far!) then the entire <Prize> composite should be omitted.

As a reminder, the <Prize> composite is repeatable and has the following components:

• the name of the prize (mandatory)

• the year (if applicable)

• the level of achievement (if applicable) in <PrizeCode> using list 41

• the country associated with the prize (if applicable) in <PrizeCountry> using list 91

• the precise wording in <PrizeStatement> about the prize

And here’s how it works together:

As you can see, the composite is quite structured and also doesn’t allow for free text. If a structured description of the prize isn’t available, you’re able to include this in P.14 Descriptions and other supporting text, in <TextContent>.

Let’s see how it looks, using the ONIX record for Zalika Reid-Benata’s Frying Plantain:

P.7 Authorship

This is where ONIX 3.0 will satisfy the most Type A personalities among us: the long-awaited opportunity to specify prizing information that’s specific to the contributor, independent from the product! Just as <Contributor> is a repeatable composite, <Prize> may be repeated per contributor. <Prize> is an “associated attribute” of the <Contributor> and includes all the same components as you’re familiar with from p.17 Prizes. In the <Contributor> composite, you may list general awards given to a contributor as well as awards given to a contributor for other works and products. Just imagine the opportunities! We know, it’s pretty sweet.

We’d be remiss if we didn’t recommend good metadata management regarding prizes and awards. Read our call to action here.

We would be remiss to note that many of the definitions, examples, and sources for this piece come from EDItEUR’s fantastic documentation for ONIX. If you haven’t dug deep into their documentation, start with BookNet’s love letter to their Best Practices on the blog, and be sure to download the ONIX for Books specification & most recent codelists release & Best Practice Guide.

This originally appeared on the BNC Blog at https://www.booknetcanada.ca/blog/2020/8/20/our-top-reasons-to-transition-to-onix-30. Subscribe the the blog RSS at https://www.booknetcanada.ca/blog?format=rss.