Goals, mine and yours

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.”

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.

Open

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> <!-- List 15 “Distinctive Title” -->
<TitleElement>
<SequenceNumber>1</SequenceNumber>
<TitleElementLevel>01</TitleElementLevel> <!-- List 149 “Product Level” -->
<TitlePrefix>The</TitlePrefix>
<TitleWithoutPrefix>Niece’s Bishop’s Friend</TitleWithoutPrefix>
<Subtitle>A Novel</Subtitle>
</TitleElement>
</TitleDetail>

<TitleDetail>
<TitleType>01</TitleType> <!-- List 15 “Distinctive Title” -->
<TitleElement>
<SequenceNumber>1</SequenceNumber>
<TitleElementLevel>01</TitleElementLevel> <!-- List 149 “Product Level” -->
<NoPrefix/>
<TitleWithoutPrefix>Desert Desserts</TitleWithoutPrefix>
<Subtitle>Sweet Meals' End</Subtitle>
</TitleElement>
</TitleDetail>

xpath Short tag:

product//descriptivedetail//titledetail//titleelement

<titledetail>
<b202>01</b202> <!-- List 15 “Distinctive Title” -->
<titleelement>
<b034>1</b034>
<x409>01</x409> <!-- List 149 “Product Level” -->
<b030>The</b030>
<b031>Niece’s Bishop’s Friend</b031>
<Subtitle>A Novel</Subtitle>
</titleelement>
</titledetail>

<titledetail>
<b202>01</b202> <!-- List 15 “Distinctive Title” -->
<titleelement>
<b034>1</b034>
<x409>01</x409> <!-- List 149 “Product Level” -->
<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> <!-- List 15 “Distinctive Title” -->
<TitleElement>
<TitleElementLevel>01</TitleElementLevel> <!-- List 149 “Product Level” -->
<TitleText>The Niece’s Bishop’s Friend</<TitleText>>
<Subtitle>A Novel</Subtitle>
</TitleElement>
</TitleDetail>

<TitleDetail>
<TitleType>01</TitleType> <!-- List 15 “Distinctive Title” -->
<TitleElement>
<TitleElementLevel>01</TitleElementLevel> <!-- List 149 “Product Level” -->
<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> <!-- List 15 “Distinctive Title” -->
<titleelement>
<x409>01</x409> <!-- List 149 “Product Level” -->
<b203>The Niece’s Bishop’s Friend</b203>
<b029>A Novel</b029>
</titleelement>
</titledetail>

<titledetail>
<b202>01</b202> <!-- List 15 “Distinctive Title” -->
<titleelement>
<x409>01</x409> <!-- List 149 “Product Level” -->
<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.

Title Detail and Title Element composites

Title Detail is a container composite with one defining code list, ONIX Code List 15 for <TitleType> | <b203>, which defines it and all the Title Element composites it may take to create the title. As mentioned above, every ONIX record must have a Product Title entry, but Title Detail can be used to provide things like a translated title or a distributor’s title. There are 12 additional options to the expected distinct title entry (not including the best-to-leave-unused “undefined” code), but here I’m only concerned about the use of “Title Type” “01” in both P.6 Product Title and P.5 Collection.

Products and collections both use titles and Title Detail identically, the only difference is their place in the XML:

P.5 Collection xpath
(Reference tag): Product//DescriptiveDetail//Collection//TitleDetail//TitleElement | (Short tag): product//descriptivedetail//collection//titledetail//titleelement
or
P.6 Product Title xpath
(Reference tag): Product//DescriptiveDetail//TitleDetail//TitleElement | (Short tag): product//descriptivedetail//titledetail//titleelement

Every Title Detail has to contain at least one Title Element composite. You’ve seen its most common presentation used in the example included above. The most common use can support a book’s main title and subtitle, but here’s the full list of options:

Although the order is odd and it looks a bit different, it’s also largely familiar. It’s safe to say that the Part Number or Year of Annual almost never precedes a book’s main title, and what’s new in ONIX 3.0 is that a title is assembled as an ordered series of component parts created by repeating one or more Title Element composites within a uniquely and purposefully coded Title Detail composite.

If you publish an annual and the Year of Annual appears in the P.5 Collection name following the series name you must use a second composite coded appropriately in order to get the same display supported in ONIX 2.1. But there’s no restriction: it can appear before the title, or after the subtitle. In ONIX 3.0 it can appear in the P.6 Product’s main title just as easily as in the Collection. Title Element is identical in both P.6 Product Title and P.5 Collection Title, and its components, like Year of the Annual, can be indexed as necessary from either P.5 or P.6. ONIX 3.0 strives to avoid duplication and the metadata is actually clearer for that.

An example

The annual Guinness World Records book has always used a Product Title entry in ONIX 2.1 (at least in Canada) with the year embedded in the main title. ONIX 3.0 allows the exact same presentation but you can treat it as a book title and include the current year as a fielded Year of Annual entry.

xpath Reference tag: Product//DescriptiveDetail//

<NoCollection/> <!-- this notes that no collection entry is used -->
<TitleDetail>
<TitleType>01</TitleType>
<TitleElement>
<SequenceNumber>1</SequenceNumber>
<TitleElementLevel>01</TitleElementLevel> <!-- List 149 Product Level -->
<NoPrefix/>
<TitleWithoutPrefix>Guinness World Records</TitleWithoutPrefix>
</TitleElement>
<TitleElement>
<SequenceNumber>2</SequenceNumber>
<TitleElementLevel>01</TitleElementLevel> <!-- List 149 Product Level -->
<YearOfAnnual>2021</YearOfAnnual>
</TitleElement>
<TitleStatement><b>Guinness World Records</b> <i>2021</i></TitleStatement>
</TitleDetail>

xpath Short tag: product//descriptivedetail//

<x411/> <!-- this notes that no collection entry is used -->
<titledetail>
<b202>01</b202>
<titleelement>
<b034>1</b034>
<x409>01</x409> <!-- List 149 Product Level -->
<x501/>
<b031>Guinness World Records</b031>
</titleelement>
<titleelement>
<b034>2</b034>
<x409>01</x409> <!-- List 149 Product Level -->
<b020>2021</b020>
</titleelement>
<x478><b>Guinness World Records</b> <i>2021</i></x478>
</titledetail>

In the next instalment, I’ll use the example of the Guinness World Records book again but treating it like a collection as there are reasons to do it that way. All you need to know now is that either way you do it, a consumer would be none the wiser. For the moment I’d like to point out that, like Year of Annual, Part Number can be used in Product Title as well as Collections for either’s display.

The above isn’t a big change, so let’s look at the codes that define each possible instance of the Title Element composite in either P.6 Product Title or P.5 Collection:

ONIX Code List (Issue 50) List 149: Title element level

This is a big change. A book title or a Collection title can now contain components that are a little like the Key Name parts used in a Contributor composite. The big difference is Key Name parts are in a single composite while you repeat Title Element composites within a Title Detail to present each component in their correct order. This is why the “preferred method” includes a Sequence Number in Title Element. The order of authors is important and so is the book’s title presentation. Each component needs its place.

It’s easy to see the value of code 04 Content item: You can support an omnibus or bundled product with fielded entries for each embedded book’s title. That’s really useful — and noted here because it’s hard to think of a way it can be used to support Collection so it’s a “product only use” mostly outside of this explanation.

It’s also easy to see that a Title must support the product but it’s less clear why we need a “01” Product code for it. After all, it’s a given that within an ONIX record the information applies to the specific product identified by this one ISBN. This code exists because title components can point at something “not-the-product.” The definition of Collection given in our first instalment was a grouping or listing of individual products held by the retailer or other end user. And there you go: the balance of the codes are there to support the grouping of multiple products as represented by Collections and Master Brand.

In addition to ignoring code 04 Content item, I’m going to largely ignore code 05 Master brand. It may represent a very distinct thing, but in ONIX use the difference between a “Collection” and a “Master Brand” is negligible because both designate that this product is a member of a group you want a retailer to support as a listing and the tools to support it are the same. In a simple case, a collection would be all one publisher’s products while a master brand would be a publisher’s products grouped with other companies' products and would typically include non-book products. In this case, I’m looking at the simple case of a publisher collection, but it’s easy to see any list outside of the product can be supported by an ONIX Collection. There’s no limit, really, to groupings that can help retailers sell books and EDItEUR has a number of suggestions for very useful things you can do with Collections that we won’t cover outside of a general comment at the end.

That’s the big change ONIX 3.0 supports: Titles are important carriers of meaning and concepts. A title describes a book. If a subject provides a standardized way to group books about a topic, the title’s job is to summarize how this book can fit with that topic. Titles can be used to group things together and we can have an interesting debate if they or the author are the most important part of book metadata. Titles carry a lot of weight and EDItEUR is providing tools to use them more fully.

It took a while but we’re ready to look at Collections in our third and last instalment. Until then, may the (ONIX) force be with you. Bye!

Transition Notes:

• The Title Detail composite contains one other tag that hasn’t been put into context: <TitleStatement> | <x478>, it’s an optional XHTML enabled entry that provides the overall title (Product Title if in P.6 and Collection Title if in P.5) and while it does NOT replace the use of Title Elements components, if supplied, it should be used for display.

  • Title Statement doesn’t replace indexing and Collections is all about providing retailers their indexing about groups so it doesn’t figure much into this explanation, but there’s a difference between a Collection Title Statement and a Product Title Statement. The mandatory distinct Product Title would fully match the product in both its Title Element presentation and in its Title Statement. The optional Collections Title that is created by its Title Elements sequence can be supplemented by its Title Statement. Supplying information in Collection’s Title Elements list will always be appropriate for indexing, but the sum of its parts may be insufficient for its display. This isn’t an issue if the retailer uses its indexed entries for product display but the Collection Title Statement provides a way for the sender to provide a full Collection name.

• This title structure was agreed to by multiple companies, including publishers and retailers in Canada and the United States, and has been available for more than a decade (largely: sequence number was added in version 3.0.1 and the NoPrefix empty set in version 3.0.2). It’s also true that not many companies have worked this logic into their datasets and there’s no appreciable use of these title components available yet. BookNet Canada strongly recommends that end users demonstrate their commitment to getting the better data — that they have asked for — by programming to accept it based on the ONIX standard. This structure benefits them most. Letting publishers know you accept it will drive use.

Collections

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.

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!