Ready? Ok, let’s get right to it.
To increase sales, both publishers and retailers want consumers to buy groups of products. What’s a group? Well, EDItEUR doesn’t have specific criteria, but they’ve designed ONIX 3.0 to give you the tools you need to create a record entry in a listing for a group of products.
Let’s consider two examples. First, take the simple example of a trilogy: An author publishes three novels, typically over several years, culminating in a slipcased (AKA “boxed”) set and digital bundle. Now let’s consider an educational publisher whose instructional books form a network of disciplines subdivided into job functions containing book lists. And one book might be a member of more than one job function and so appears on more than one list. It’s debatable if the former needs to be handled as a formal collection, after all the three books and the set can easily share a name displayed in the Product Title but there’s no debate that the latter would be a complex undertaking.
Computers and ONIX handle complexity by using identifiers. So there’s a simple way to differentiate collections: All collection identifiers must be supplied in the Collection composite.
If you don’t need to use a system of identifiers to help retailers structure your collection (e.g. it’s a simple trilogy) then whether or not your trilogy gets a distinct “Series Name” and a distinct “Book Title” is purely a marketing choice. Retailers can index the Title Element component “collection” from a Product Title entry and then display the full entry as a product title. That also means that if they’re given both a distinct and unique Product Title and a Collection Title, the retailer can have more flexibility in their design choices by displaying them differently.
Publishers giving the data once, without duplication, of where they want the information displayed can gain control of the retailer display that they want without interfering with the retailer’s ability to create the indexing that they need to group the product. On the other hand, if there’s duplication, it can prevent retailers from displaying series names with any nuance.
We’ve said this before and we’ll say it again: ONIX 3.0’s structure is a win-win for the publisher, retailer, and buyer.
Here’s the mind blowing part: If you DO need to use a system of identifiers to help retailers structure your collection (e.g. it’s more complex than a trilogy) you have the same choice. You can still control the display the same way. It’s just more likely that you’ll use distinct Collection Title entries separated from the Product Title. By the time you move into collections with sub-collections, I’d think you’d want retailers to be handling Product Title and Series Name distinctly — BUT — although unlikely, you still have the choice of using Product Title.
And when it comes to supporting complexity by using a set of easily understood identifiers to help retailers structure their data, well, I don't think you have a choice. Retailers need to create their listings from individual product records and if you’re asking them to track “Barbie™” as a brand name and one book’s title needs “Barbie’s” you better have the back up association in identifiers. Titles have a limitation: What you put physically on the book may not create the ideal index entry. Identifiers can support the perfect consistency computers need.
Clarity when not using collections
Like ONIX 2.1’s <NoSeries/> | <n338/>, ONIX 3.0 also supports an empty set: <NoCollection/> | <x411/> marker. The only difference in its use is that it’s more important in ONIX 3.0. The marker’s purpose is to confirm for retailers that there’s no collection information to be indexed, and the potential for collection components to be used in P.6 Product Title means collection use isn’t confined to its dedicated composite. Be accurate! Let your trading partners know that NoCollection’s absence means they’re indexing collection data and its presence reliably means there are no collection entries in this record.
Note that Title Element Level 04 Content Item and 05 Master Brand aren’t collection components and their presence or absence isn’t relevant to using the NoCollection marker.
Another reason to use the Collection composite
We’ve seen that Title Element’s sequence number controls the display order for the title components and Part Number should also match the display. In the simple case of a trilogy that might be enough information, but if you need to actually order the collection and provide a number that a computer could use to put this ISBN in its right position within it, then you’ll need to use a Collection composite and include it as a <CollectionSequence> | <collectionsequence> composite containing the <CollectionSequenceNumber> | <x481> entry. It supports some options to make collections and sub-collections easier if it’s not as simple as using an integer.
Multiple collections vs sub-collection
A collection can be divided into sub-collections. As noted in part one, a book would have a unique tree and its ONIX record cannot show sub-collections it's not part of. It does show the tree that defines it with the Top Collection to sub-collection to sub-sub-collection — going however far down as necessary to get to the product, all done by nesting codes in repeating Title Element composites in a single Collection composite.
If the same book was also a member of another sub-collection (same Top Collection but different tree), it would have to have a second Collection composite, just as it would need one for being a member of a second collection. A collection is an index entry so more shouldn’t be a problem for end users, but before you invest heavily in this sort of complexity, ask if your trading partners are prepared to display two Series entries on a single Title page. Creating a listing is easy but there are always limits to real estate devoted to display.
What’s a product in a collection in an ONIX record anyway?
If a collection represents a group of products held as a listing or a concept outside of the ONIX record, then within that record, the top root of the Collection tree (however simple or complex) represents something not-the-product. And the Title Element’s Part Number or Collection’s Sequence Number is of-the-product. That sounds a bit strange but when you start fiddling with sub-collections you’ll quickly see this is needed because sub-collections must be lower than their collection and why the Title Element composite is defined by a code list tag named Title Element Level. Don’t worry — it’s less complicated to do than to write.
It should be obvious that the Part Number associated with the ISBN is not labeled as a “Collection” component in Title Element composite because it applies to the specific product. Similarly, a Collection composite is describing a place in a collection so its Collection Sequence Number applies to this product’s ISBN.
Sample scripts
Here’s the example I promised, re-working a Guinness World Records book entry to use collections. Product Titles have a problem — they change. Some years it might add “book” for Guinness Book of World Records, and other years may or may not include “The.” Names will change in a long running series so there’s good reason to include an identifier to make sure that group can be handled consistently. Trade sales are important but libraries buy a lot of these books too, and there may be a need for more than one identifier.
In this example, we present the annual’s name as part of a collection supported by collection identifiers while still embedded in the Product Title entry. For consumers, nothing will have changed but the there’s extra information to help end users index the books over time.
xpath Reference tag: Product//DescriptiveDetail//
<!-- Group P.5 Collection -->
<Collection>
<CollectionType>10</CollectionType>
<CollectionIdentifier>
<CollectionIDType>01</CollectionIDType> <!-- List 13 Proprietary -->
<IDTypeName>Guinness_Identifier</IDTypeName> <!-- Type name shows the source of a proprietary code -->
<IDValue>GWR</IDValue>
</CollectionIdentifier>
<CollectionIdentifier>
<CollectionIDType>02</CollectionIDType> <!-- List 13 ISSN -->
<IDTypeName>United States</IDTypeName> <!-- Type name needed as the ISSN can be for different countries -->
<IDValue>0072-9000</IDValue>
</CollectionIdentifier>
</Collection>
<!-- Group P.6 Product Title -->
<TitleDetail>
<TitleType>01</TitleType>
<TitleElement>
<SequenceNumber>1</SequenceNumber>
<TitleElementLevel>02</TitleElementLevel> <!- List 149 Collection -->
<NoPrefix/>
<TitleWithoutPrefix>Guinness World Records</TitleWithoutPrefix>
</TitleElement>
<TitleElement>
<SequenceNumber>2</SequenceNumber>
<TitleElementLevel>01</TitleElementLevel> <!- List 149 Product -->
<YearOfAnnual>2021</YearOfAnnual>
</TitleElement>
<TitleStatement><b>Guinness World Records</b> <i>2021</i></TitleStatement>
</TitleDetail>
xpath Short tag: product//descriptivedetail//
<!-- Group P.5 Collection -->
<collection>
<x329>10</x329>
<collectionidentifier>
<x344>01</x344> <!-- List 13 Proprietary -->
<b233>Guinness_Identifier</b233> <!-- Type name shows the source of a proprietary code -->
<b244>GWR</b244>
</collectionidentifier>
<collectionidentifier>
<x344>02</x344> <!-- List 13 ISSN -->
<b233>United States</b233> <!-- Type name needed as the ISSN can be for different countries -->
<b244>0072-9000</b244>
</collectionidentifier>
</collection>
<!-- Group P.6 Product Title -->
<titledetail>
<b202>01</b202>
<titleelement>
<b034>1</b034>
<x409>02</x409> <!-- List 149 Collection -->
<x501/>
<b031>Guinness World Records</b031>
</titleelement>
<titleelement>
<b034>2</b034>
<x409>01</x409> <!- List 149 Product -->
<b020>2021</b020>
</titleelement>
<x478><b>Guinness World Records</b> <i>2021</i></x478>
</titledetail>
And here’s a general example script from EDItEUR’s Best Practices showing what might be called a “typical” series entry. The ISBN represents a book with a main product title of “Le jour du soleil?” that is “Tome 1” in a collection with the title of “XIII” — a very typical arrangement in France or Quebec. The Collection Sequence Type “02,” Title order, confirms the correct place in the collection is “1” or this product is first in that collection — which can be read as it’s displayed “Tome 1” but it’s also made easily ordered in a collection listing by a number entry.
xpath Reference tag: Product//DescriptiveDetail// | xpath Short tag: product//descriptivedetail// |
---|---|
<!-- Group P.5 Collection -->
<Collection> <CollectionType>10</CollectionType> <CollectionSequence> <CollectionSequenceType>02 </CollectionSequenceType> <CollectionSequenceNumber>1 </CollectionSequenceNumber> </CollectionSequence> <TitleDetail> <TitleType>01</TitleType> <TitleElement> <TitleElementLevel>02 </TitleElementLevel> <NoPrefix/> <TitleWithoutPrefix textcase="01">XIII </TitleWithoutPrefix> </TitleElement> <TitleElement> <TitleElementLevel>01 </TitleElementLevel> <PartNumber>Tome 1</PartNumber> </TitleElement> </TitleDetail> </Collection> <!-- Group P.6 Product Title --> <TitleDetail> <TitleType>01</TitleType> <TitleElement> <TitleElementLevel>0 </TitleElementLevel> <TitlePrefix textcase="01" >Le</TitlePrefix> <TitleWithoutPrefix textcase="01">jour du soleil?</TitleWithoutPrefix> </TitleElement> </TitleDetail> |
<!-- Group P.5 Collection --> <collection> <x329>10</x329> <collectionsequence> <x479>02</x479> <!--Title order (confirmation) --> <x481>1</x481> <!--Product is first item in collection --> </collectionsequence> <titledetail> <b202>01</b202> <!--Distinctive title (of the Collection)--> <titleelement> <x409>02</x409> <!--Collection level --> <x501/> <b031 textcase="01">XIII</b031> </titleelement> <titleelement> <x409>01</x409><!--Product level --> <x410>Tome 1</x410> <!-- displayed part number --> </titleelement> </titledetail> </collection> <!-- Group P.6 Product Title --> <titledetail> <b202>01</b202> <!--Distinctive title (of the Product) --> <titleelement> <x409>01</x409> <!--Product level --> <b030 textcase="01">Le</b030> <b031 textcase="01">jour du soleil?</b031> </titleelement> </titledetail> |
Transition Notes:
If you’re a publisher who feels their series entries were abused by retailers (that’s the entire North American supply chain) please consider implementing Title Detail and Title Element fully. Avoid duplication to support better use.
If you’re a retailer who’s never been able to properly index what publishers provided as (so-called) series entries, please consider implementing Title Detail and Title Element fully. Support indexing title components from both P.6 Product Title and P.5 Collections. Set up a product display page appropriately to maximize collection options and let publishers know you support it!
Think about what sort of identifiers would help you the most: Proprietary ones where there’s a one-to-one correspondence between a name and an identifier, with each level of a sub-collection handled after a delimiter? Or maybe publishers should use ISNI where appropriate. Let’s talk as an industry!
Advanced topics in Collection
I just gave you most of what you need to know to support collections by talking about Title entries. What’s missing in this explanation is all the other stuff the Collections composite can do in the supply chain. If a publisher collection’s is confined to a single publisher, and master brand entries represent licensed products held by that publisher — what if we expand just a little more?
What if: We traded lists as Collections … different kinds of sequences that presented publisher products in different ways — ways that might make more sense to consumers. What if we compiled lists of books on a topic — not restricted to one publisher or product type. Collections is waiting to help you. Understand and support the simple case then look again at EDItEUR’s documentation with new eyes to see its potential. Let’s talk as an industry!
Visit the links below to read the first and second instalments of this mini-series.
How to use the various filters and reports available in LibraryData to help kick start your diversity auditing process.