Goals, mine and yours

The first instalment of a mini-series about the use of ONIX’s Collection composite written by @BookNet_Canada's Bibliographic Manager Tom Richardson.
CLICK TO TWEET

ONIX’s primary concern is simply to carry publisher-created book metadata to retailers, cleanly and preferably without duplication. While there are specific elements in the standard intended for use in display (easily identified by their support of XHTML formatting), the vast majority of ONIX metadata is NOT intended to allow the sender to specify how the end user can display their product. Instead, the data is sent appropriately defined to support the data’s use by the end user, meaning that the display is largely a choice based on their clients' needs.

I start here because the Collection composite in ONIX 3.0 has a reputation for being complicated and I hope to show you otherwise. I also ask you to consider that ONIX 2.1 Series metadata has been poorly supported by North American retailers. This situation was created, in part, by the variety of solutions used by data senders to suit their perception of the display needs of one very large retailer. Expecting ONIX 3.0’s Collection to match what publishers did for ONIX 2.1’s Series will make it seem confusing, not least because series data provided by senders in ONIX 2.1 wasn’t generally supported as EDItEUR intended. As always, the transition to ONIX 3.0 gives us a chance to do better metadata and solve problems. My goal is to promote the use of ONIX as EDItEUR intends it because that’s how we avoid “flavours of ONIX.”

Animated gif of Yoda saying "You must unlearn what you have learned."

As you probably know, a collection is a grouping of products that in the simplest case are created and marketed by a publisher. Publishers need retailers to display that group of products to their customers, but one ONIX record can only show a single product’s place in that grouping. Meaning that retailers must create their client facing display by assembling it from the publisher’s metadata. For example, book “A” is a member of a Collection that includes multiple subcollections, subcollection one, two, and three. In order for a retailer to create a full Collection listing with all its subcollections they must assemble their information one record at a time.

That’s why publishers focusing on controlling the display of the retailer’s page for a single book record aren’t going to deliver what retailers need to support a collection as a whole. But rest assured Series name isn’t the only tool EDItEUR makes provision for.

Product Title

Both composites P.6 Product Title Detail and P.5 Collection Title Detail contain identical support for a repeating Title Element composite. One difference is all ONIX records must support a Product Title entry while Collection entry is only provided when it’s needed. So we’ll start at one of the big but largely ignored changes in the transition from ONIX 2.1 to 3.0 — how titles are recorded.

The books:

The Niece’s Bishop’s Friend: A Novel
Desert Desserts: Sweet Meals' End

Preferred method in ONIX 3.0

xpath Reference tag:

Product//DescriptiveDetail//TitleDetail//TitleElement

<TitleDetail>
<TitleType>01</TitleType> 
<TitleElement>
<SequenceNumber>1</SequenceNumber>
<TitleElementLevel>01</TitleElementLevel> 
<TitlePrefix>The</TitlePrefix>
<TitleWithoutPrefix>Niece’s Bishop’s Friend</TitleWithoutPrefix>
<Subtitle>A Novel</Subtitle>
</TitleElement>
</TitleDetail>

<TitleDetail>
<TitleType>01</TitleType> 
<TitleElement>
<SequenceNumber>1</SequenceNumber>
<TitleElementLevel>01</TitleElementLevel> 
<NoPrefix/>
<TitleWithoutPrefix>Desert Desserts</TitleWithoutPrefix>
<Subtitle>Sweet Meals' End</Subtitle>
</TitleElement>
</TitleDetail>

xpath Short tag:

product//descriptivedetail//titledetail//titleelement

<titledetail>
<b202>01</b202> 
<titleelement>
<b034>1</b034>
<x409>01</x409> 
<b030>The</b030>
<b031>Niece’s Bishop’s Friend</b031>
<Subtitle>A Novel</Subtitle>
</titleelement>
</titledetail>

<titledetail>
<b202>01</b202> 
<titleelement>
<b034>1</b034>
<x409>01</x409> 
<x501/>
<b031>Desert Desserts</b031>
<b029>Sweet Meals' End</b029>
</titleelement>
</titledetail>

This is the preferred way to present a title in ONIX 3.0 which is different than how it’s done in ONIX 2.1. Here all titles would appear with the same main title field being used: <TitleWithoutPrefix> | <b031> and either carry a <TitlePrefix> | <b030> or the <NoPrefix/> | <x501/> empty set as needed. It’s preferred because it simplifies data and presents the main title for indexing consistently in the same tag: <TitleWithoutPrefix> | <b031>. I’ve also intentionally included <SequenceNumber> | <b034> for reasons I’ll discuss below.

The common but more complicated method in ONIX 3.0

xpath Reference tag:

Product//DescriptiveDetail//TitleDetail//TitleElement

The common method uses the following and <TitlePrefix> example above without supporting the <NoPrefix/> empty set or <SequenceNumber>.

<TitleDetail>
<TitleType>01</TitleType> 
<TitleElement>
<TitleElementLevel>01</TitleElementLevel> 
<TitleText>The Niece’s Bishop’s Friend</<TitleText>>
<Subtitle>A Novel</Subtitle>
</TitleElement>
</TitleDetail>

<TitleDetail>
<TitleType>01</TitleType> 
<TitleElement>
<TitleElementLevel>01</TitleElementLevel> 
<TitleText>Desert Desserts</TitleText>
<Subtitle>Sweet Meals' End</Subtitle>
</TitleElement>
</TitleDetail>

xpath Short tag:

product//descriptivedetail//titledetail//titleelement

The common method uses the following and <b030> example above without supporting the <x501/> empty set or <b034>.

<titledetail>
<b202>01</b202> 
<titleelement>
<x409>01</x409> 
<b203>The Niece’s Bishop’s Friend</b203>
<b029>A Novel</b029>
</titleelement>
</titledetail>

<titledetail>
<b202>01</b202> 
<titleelement>
<x409>01</x409> 
<b203>Desert Desserts</b203>
<b029>Sweet Meals' End</b029>
</titleelement>
</titledetail>

This is almost identical to ONIX 2.1 and preserves its weird choice between <TitleText> | <b203> OR <TitlePrefix> | <b030> with <TitleWithoutPrefix> | <b031>. And it looks shorter without that seemingly useless sequence number. But note that I needed to add an example to cover off not supporting title indexing, which is not a “preferred way” even in ONIX 2.1. Optimistic 3.0 assumes you want to support better metadata. You really should be able supply index-ready titles and gain the advantage of not needing to support <TitleText> | <b203> in any record.

Think about it. Having a book's main title always appearing in one consistent place is actually very very useful and a genuine improvement. We should be implementing to use index-ready titles supported by <TitleWithoutPrefix> | <b029> with <TitlePrefix> | <b030> or the <NoPrefix/> | <x501/> empty set.

The next step is to consider what options exist for Title, which will be covered in our next two instalments of this blog mini-series.

Transition Notes

ONIX 3.0’s rules prohibit Title Text AND With Prefix/Without Prefix being used together in the same composite. That’s a common choice in ONIX 2.1 that isn’t available in 3.0. In ONIX 2.1, supplying TitleText (b203) with the Prefix entries allowed it to function as the consistent place to find the book title, but it did it without indexing support.
Title With Prefix/Without Prefix must only be used if you support indexing. If you don’t support indexing the correct way to send a title is in the <TItleText> | <b203> element. Please don’t default to sending records with prefixes in TitleWithoutPrefix (b031) because end users should be able to process records knowing what they get.
All of the examples above are allowed by ONIX 3.0’s validation rules. Data receivers will need to plan for them and to be aware that ONIX 3.0 does not eliminate every opportunity for poor choices by data senders.
- Data processors should also note that there are multiple TitleTypes (titles have more purposes than the mandatory “01” distinct product title entry). For some use cases presenting title data without indexing may make more sense. The preferred method should be used for Title Type 01 “distinct title,” but end users shouldn’t program to only support the preferred way to fully support other Title Type entries.