The top reasons to transition to ONIX 3.0
- Lauren Stewart
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!
- 1 3.0 supports regional information about contributors that media, retailers, and libraries crave
- 2 3.0 presents information about series & sets better than ever before
- 3 Supplying information about markets and suppliers has never been simpler
- 4 3.0 offers full support for digital & open access products
- 5 Target your marketing content for specific audiences
- 6 3.0 encourages you to flex your promotional events hustle
- 7 Showcase your contributors' accomplishments independently from the book’s
- 7.1 P.17 Prizes
- 7.2 P.7 Authorship
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.
Example: designating a contributor as Canadian & indicating residency
This contributor is a Canadian citizen who currently lives in Newfoundland & Labrador, specifically in Stephenville.
Using Reference names | Using Short tags |
|---|---|
<ContributorPlace> | <contributorplace> |
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:
Value | Description | Notes |
|---|---|---|
01 | Born in |
|
02 | Died in |
|
03 | Formerly resided in |
|
04 | Currently resides in |
|
05 | Educated in |
|
06 | Worked in |
|
07 | Flourished in | (‘Floruit’) |
08 | Citizen of | Or nationality. For use with country codes only |
09 | Registered in | The place of legal registration of an organisation |
10 | Operating from | The place an organisation or part of an organisation is based or operates from |
00 | Associated with | To express unknown relationship types (for use when expressing legacy ONIX 2.1 data in ONIX 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:
ONIX 2.1 | ONIX 3.0 |
|---|---|
Series: Continuing and indefinite sequence of monographic products published separately over a period of time, with a shared identity such as a ‘series title’. The products are usually of similar product form, and share a distinctive branding or design style. A series is not available for purchase as a single product. In ONIX, a series is a type of collection. | Collection: Fixed or indefinite number of products that share some collective identity such as a collective title. Members of the collection usually also have other attributes in common, such as product form or a branding or design style. A set or a series is a collection, but a collection could also comprise a less formal selection of products. |
Set: Finite number of products published simultaneously or over a definite period of time, with a shared identity such as a ‘set title’. The products are usually of similar product form, and share a distinctive branding or design style. The products in the set may be available individually, or the set may be a single product, or both. In ONIX, a set is a type of collection. |
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.
Using Reference names | Using Short tags |
|---|---|
<Collection> | <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:
Element / Composite | Optional or mandatory? | Repeatability | Notes |
|---|---|---|---|
<ProductSupply> | Optional | Repeatable | All ONIX records should contain at least one Product Supply composite. |
<Market> | Optional | Repeatable | Each Product Supply composite should include the extent of its market |
<Territory> | Mandatory | Non-repeatable | Every Market composite must specify a geographical area |
<SalesRestriction> | Optional | Repeatable | Any sales restrictions that apply within that territory should be included |
</Market> |
|
|
|
<MarketPublishingDetail> | Optional | Non-repeatable | Strongly recommended for all Product Supply composites |
<PublisherRepresentative> | Optional | Repeatable | Sales representation support is recommended |
<ProductContact> | Optional | Repeatable | Product contact support is recommended |
<MarketPublishingStatus> | Mandatory | Non-repeatable | Every Market Publishing Detail must contain a Publishing Status |
<MarketDate> | Optional | Repeatable | Market Publication Date is strongly recommended |
</MarketPublishingDetail> |
|
|
|
<SupplyDetail> | Mandatory | Repeatable | There must be at least one Supply Detail composite within every Product Supply composite |
<Supplier> | Mandatory | Non-repeatable | Every Supply Detail composite must include a Supplier composite that must include a Supplier Role, business name and should include any applicable identifiers. Contact information and website are recommended |
<ProductAvailability> | Mandatory | Non-repeatable | Every Supply Detail composite must include Product Availability |
<SupplyDate> | Optional | Repeatable | Every Supply Detail should include appropriate dates, in particular by supporting forthcoming books with an embargo date as well as anytime an expected ship date is needed |
<Price> | Optional | Repeatable | Every Supply Detail should contain a price. It can be omitted only if replaced by <UnpricedItemType> |
<PriceType> | Mandatory (don't use default Price Type) | Non-repeatable | All price composites must contain Price Type (and Price Qualifier if needed) to uniquely identify the price amount’s purpose. Additional Price composites can cover each unique statement |
<DiscountCoded> | Optional | Repeatable | All prices should be supported by discount codes |
<PriceAmount> | Optional | Non-repeatable | All price composites should contain a price amount, which cannot be zero. It can be omitted only if replaced by <UnpricedItemType> |
<Tax> | Optional | Repeatable | Tax information should not be sent if the Price Type is coded for “without tax”. Usually needed for European & UK prices |
<CurrencyCode> | Mandatory (don’t use default Currency Code) | Non-repeatable | All price amounts must be assigned a currency code |
<Territory> | Optional | Non-repeatable | All price composites should supply a territory statement to cover where the Price Amount applies to |
<CurrencyZone> | Deprecated | Non-repeatable | Deprecated Do not use. |
</Price> |
|
|
|
</SupplyDetail> |
|
|
|
</ProductSupply> |
|
|
|
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:
Value | Description | Notes |
00 | Unrestricted | Any audience |
01 | Restricted | Distribution by agreement between the parties to the ONIX exchange (this value is provided to cover applications where ONIX content includes material which is not for general distribution) |
02 | Booktrade | Distributors, bookstores, publisher’s own staff etc |
03 | End-customers |
|
04 | Librarians |
|
05 | Teachers |
|
06 | Students |
|
07 | Press | Press or other media |
08 | Shopping comparison service | Where a specially formatted description is required for this audience |
09 | Search engine index | Text not intended for display, but may be used (in addition to any less restricted text) for indexing and search |
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:
Value | Description | Notes |
|---|---|---|
01 | Sender-defined text | To be used only in circumstances where the parties to an exchange have agreed to include text which (a) is not for general distribution, and (b) cannot be coded elsewhere. If more than one type of text is sent, it must be identified by tagging within the text itself |
02 | Short description/annotation | Limited to a maximum of 350 characters |
03 | Description | Length unrestricted |
04 | Table of contents | Used for a table of contents sent as a single text field, which may or may not carry structure expressed using XHTML |
05 | Flap / cover copy | Primary descriptive blurb taken from the back cover and/or flaps. See also code 27 |
06 | Review quote | A quote taken from a review of the product or of the work in question where there is no need to take account of different editions |
07 | Review quote: previous edition | A quote taken from a review of a previous edition of the work |
08 | Review quote: previous work | A quote taken from a review of a previous work by the same author(s) or in the same series |
09 | Endorsement | A quote usually provided by a celebrity or another author to promote a new book, not from a review |
10 | Promotional headline | A promotional phrase which is intended to headline a description of the product |
11 | Feature | Text describing a feature of a product to which the publisher wishes to draw attention for promotional purposes. Each separate feature should be described by a separate repeat, so that formatting can be applied at the discretion of the receiver of the ONIX record, or multiple features can be described using appropriate XHTML markup |
12 | Biographical note | A note referring to all contributors to a product – NOT linked to a single contributor |
13 | Publisher’s notice | A statement included by a publisher in fulfillment of contractual obligations, such as a disclaimer, sponsor statement, or legal notice of any sort. Note that the inclusion of such a notice cannot and does not imply that a user of the ONIX record is obliged to reproduce it |
14 | Excerpt | A short excerpt from the main text of the work |
15 | Index | Used for an index sent as a single text field, which may be structured using XHTML |
16 | Short description/annotation for collection | (of which the product is a part.) Limited to a maximum of 350 characters |
17 | Description for collection | (of which the product is a part.) Length unrestricted |
18 | New feature | As code 11 but used for a new feature of this edition or version |
19 | Version history |
|
20 | Open access statement | Short summary statement of open access status and any related conditions (eg ‘Open access – no commercial use’), primarily for marketing purposes. Should always be accompanied by a link to the complete license (see <EpubLicense> or code 99 in List 158) |
21 | Digital exclusivity statement | Short summary statement that the product is available only in digital formats (eg ‘Digital exclusive’). If a non-digital version is planned, <ContentDate> should be used to specify the date when exclusivity will end (use content date role code 15). If a non-digital version is available, the statement should not be included |
22 | Official recommendation | For example, a recommendation or approval provided by a ministry of education or other official body. Use <Text> to provide details and ideally use <TextSourceCorporate> to name the approver |
23 | JBPA description | Short description in format specified by Japanese Book Publishers Association |
24 | schema.org snippet | JSON-LD snippet suitable for use within an HTML <script type="application/ld+json"> tag, containing structured metadata suitable for use with schema.org |
25 | Errata |
|
26 | Introduction | Introduction, preface or the text of other preliminary material, sent as a single text field, which may be structured using XHTML |
27 | Secondary flap / cover copy | Secondary descriptive blurb taken from the back cover and/or flaps, used only when there are two separate texts and the primary text is included using code 05 |
28 | Full cast and credit list | For use with dramatized audiobooks, filmed entertainment etc, for a cast list sent as a single text field, which may or may not carry structure expressed using XHTML |
29 | Bibliography | Complete list of books by the author(s), supplied as a single text field, which may be structured using (X)HTML |
30 | Abstract | Formal summary of content (normally used with academic and scholarly content only) |
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 |
|---|---|
 |
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:
Using Reference names | Using Short tags |
|---|---|
<Prize> | <prize> |
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.