Our top reasons to transition to ONIX 3.0

A list of business case reasons to transition to ONIX 3.0 put together by the @BookNet_Canada staff team. Be the change in the metadata world!
CLICK TO TWEET

We know, dear readers, that sometimes on this blog it’s like preaching to the choir. You’re the true believers, our acolytes, our disciples sharing the good word of metadata standards, best practices, and are forces for change in your companies and in the wider trade. You believe. You were dreaming of Thema subject categories when it was but a mere glimmer in your colleagues' eyes. You held your ground when your sales team wanted to list comparable authors in a product’s keywords. Be the change in the metadata world.

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.

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

<ContributorPlace>
<ContributorPlaceRelator>08</ContributorPlaceRelator>
    <CountryCode>CA</CountryCode>
</ContributorPlace>
<ContributorPlace>
    <ContributorPlaceRelator>04</ContributorPlaceRelator>
    <RegionCode>CA-NL</RegionCode>
    <LocationName>Stephenville</LocationName>
</ContributorPlace>

Using short tags

<contributorplace>
<x418>08</x418>
    <b251>CA</b251>
</contributorplace>
<contributorplace>
    <x418>04</x418>
    <b398>CA-NL</b398>
    <j349>Stephenville</j349>
</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	("Flourit")
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

<Collection>
<CollectionType>10</CollectionType>      
    <TitleDetail>          
        <TitleType>01</TitleType>        
        <TitleElement>   
            <TitleElementLevel>05</TitleElementLevel>
            <NoPrefix/>     
            <TitleWithoutPrefix textcase="02">Barbie™​</TitleWithoutPrefix> 
        </TitleElement> 
        <TitleElement>   
            <TitleElementLevel>02</TitleElementLevel>
            <NoPrefix/>     
            <TitleWithoutPrefix textcase="02">Easy Reader with Large Print​</TitleWithoutPrefix>     
        </TitleElement> 
    </TitleDetail>         
</Collection> 

…

<TitleDetail>  
    <TitleType>01</TitleType>
    <TitleElement>      
        <TitleElementLevel>01</TitleElementLevel>   
        <NoPrefix/>        
        <TitleWithoutPrefix textcase="02">Barbie as a Pilot​</TitleWithoutPrefix>     
    </TitleElement>     
<TitleDetail>

Using short tags

<collection> 
<x329>10</x329>  
    <titledetail>
        <b202>01</b202>
        <titleelement>   
            <x409>05</x409>
            <x501/>           
            <b031 textcase="02">Barbie™</b031>         
        </titleelement>  
        <titleelement>   
            <x409>02</x409> 
            <x501/>           
            <b031 textcase="02">Easy Reader with Large Print​</b031>
        </titleelement>  
    </titledetail>          
</collection>

…

<titledetail>   
    <b202>01</b202>  
    <titleelement>
        <x409>01</x409>
        <x501/>  
        <b031 textcase="02">Barbie as a Pilot​</b031>
    </titleelement>     
<titledetail>

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 >
< 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 < UnpricedItemType >
< 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	Any audience
01	Restricted	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 dream, 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

<Prize>
    <PrizeName>Scotiabank Giller Prize</PrizeName>
    <PrizeYear>2019</PrizeYear>
    <PrizeCountry>CA</PrizeCountry>
    <PrizeCode>05</PrizeCode>
</Prize>
<Prize>
    <PrizeName>A CBC Book of the Year</PrizeName>
    <PrizeCountry>CA</PrizeCountry>
</Prize>
<Prize>
    <PrizeName>Rakuten Kobo Emerging Writer Prize for Literary Fiction</PrizeName>
    <PrizeYear>2020</PrizeYear>
    <PrizeCountry>CA</PrizeCountry>
    <PrizeCode>01</PrizeCode>
</Prize>
<Prize>
    <PrizeName>Forest of Reading Evergreen Award</PrizeName>
    <PrizeCountry>CA</PrizeCountry>
</Prize>
<Prize>
    <PrizeName>Trillium Book Award</PrizeName>
    <PrizeCountry>CA</PrizeCountry>
</Prize>
<Prize>
    <PrizeName>Danuta Gleed Literary Award</PrizeName>
    <PrizeCountry>CA</PrizeCountry>
    <PrizeCode>01</PrizeCode>
</Prize>

Using short tags

<prize>

    <g126>Scotiabank Giller Prize</g126>
    <g127>2019</g127>
    <g128>CA</g128>
    <g129>05</g129>
</prize>
<prize>
    <g126>A CBC Book of the Year</g126>
    <g128>CA</g128>
</prize>
<prize>
    <g126>Rakuten Kobo Emerging Writer Prize for Literary Fiction</g126>
    <g127>2020</g127>
    <g128>CA</g128>
    <g129>01</g129>
</prize>
<prize>
    <g126>Forest of Reading Evergreen Award</g126>
    <g128>CA</g128>
</prize>
<prize>
    <g126>Trillium Book Award</g126>
    <g128>CA</g128>
</prize>
<prize>
    <g126>Danuta Gleed Literary Award</g126>
    <g128>CA</g128>
    <g129>01</g129>
</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.

---

What have we missed?

Have you already transitioned to ONIX 3.0 at your firm? Would you like to spread the good word of 3.0? Email us at biblio@booknetcanada.ca with your best tips and tricks.

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.