This is part of an ongoing series of posts on things that regularly appear in BookNet Canada’s standards department in-basket. This post provides answers to variations on: “Do I need to care about Product Parts?” which sometimes arrives as: “Where’s Number of Pieces?”
ONIX 3.0 requires the use of Product Parts
Product Parts is part of the solution to one of the problems that plagued ONIX 2.1 which was neatly solved in ONIX 3.0 by requiring all multiple component products to follow a simplified and consistent presentation that always ends in Product Parts. In ONIX 3.0 Number of Pieces is no longer an option available to describe a product at a high level, and is replaced with a triage that starts with clear divisions and choices:
The product is either a single component product (typically “a book”) and there’s nothing to count OR it’s a multiple component product where by definition there is something to count.
The product is either sold to consumers OR the ONIX record describes something supplied to or sold to retailers and is usually related to multiple components.
In ONIX 3.0 all counting of components happens within Product Part and EDItEUR, whose prowess at defining just-granular-enough datapoints is well known, created it because you need to clearly define what’s being counted.
The problem in ONIX 2.1 that they solved was it allowed some types of series or sets to be counted at a high level where, if they shared the same product form, you could provide a count of them in Number of Pieces without defining anything about the individual books in the set. The retailer “knew” how many books were in it but not their ISBNs — which could be optionally supplied in Related Product. More complicated things were intended to be supplied in Contained Item (which is very similar to Product Parts) but because the precedent had been established, data senders would stretch the use of Number of Pieces to cover things that didn’t share the same product form or have ISBNs in Related Product. That led to records that were ambiguous in their use of Number of Pieces — the data wasn’t easily understood because it wasn’t properly defined.
Most companies with multiple component products did, eventually, develop support for ONIX 2.1’s Contained Item, though it often came as part of their transition to ONIX 3.0 after ONIX 2.1’s development had been formally locked. Supporting this functionality was an improvement but even companies that implemented it continued to support records using the convoluted and confused use of Number of Pieces.
In day-to-day practice, tradition often trumps improvement, but it’s that residue of confusion left behind by ONIX 2.1 that manifests as questions about ONIX 3.0’s Product Parts: Companies still look for a type of workaround no longer offered in the standard.
An expanded explanation
This is all about counting something and that’s a Product Form, or more typically a Product Form and the ISBN it’s associated with. The ONIX definition of Product Form is:
“An ONIX code which indicates the primary form of a product. Mandatory in an occurrence of <DescriptiveDetail>, and non-repeating.”
EDItEUR is wonderfully literal. You need to consider that the “form of a product” being described by this ISBN and in this ONIX record is “non-repeating” — appears only once in relationship with its defining composite — and “mandatory.” By being defined within the <DescriptiveDetail>, also known as Block 1 which is also “non-repeating” and “mandatory,” that means within an ONIX record there is a Product Form provided as a single code that describes the whole Product. Note that Product Forms can be used elsewhere in ONIX — within Related Materials for example or within Product Parts. They are there to either define another product, where the same definition holds for that product, or to provide the form (and the count) of the component that makes up the Product being described. In all cases, you’re referencing a similar primary defining code of something.
If the first step of the triage above is to determine if the product has one or more than one component, then you should expect that Product Form code list will reflect that.
Most Product Form codes apply to what’s defined as a singular product without components.
There are two Product Form groupings, defined by their leading letter, that can apply to multiple component products.
Product Forms starting with “S” apply to all products sold to consumers as multiple component products.
In addition to generic codes, there are code options for common packaging that contain multiples. Here are some examples, other options are available:
SB Multiple-component retail product, boxed (a six-sided, closed box)
SC Multiple-component retail product, slip-cased (a five-sided box with one side open often called a “boxed set” in Canada)
All S codes carry the instruction “Format of product components must be given in <ProductPart>” in Code List 150 Product Form’s Notes
Product Forms starting with “X” apply to all products supplied or sold to retailers, usually product bundles or support material for them.
Note that while multiples will likely dominate what you need to communicate, not all X codes involve them and require the support of Product Parts. Here are some examples, other options are available:
XB Dumpbin-empty typically would not require the use of Product Parts.
XC Dumpbin-filled would always require Product Parts because you would need to use it to identify and count what fills the dumpbin — that’s what the retailer gets to sell after all. Here are some examples of what the entry would include, other options are available:
Its ISBN. Note that if the dumpbin included multiples of different books, each with its own ISBN, then each would have its own Product Part entry.
The Product Form associated with this ISBN and likely its Product Form Detail.
The number of copies of this ISBN included in the retailer’s bundle.
Circling back to the first point: Most Product Form codes apply to what’s defined as a singular product.
A Product Part entry always uses one of those “singular Product Form codes” and that’s never one whose leading character is S but can include one whose leading character is X because some of them can be a “singulars Product Form code.”
The point of Product Part is that it repeats to provide a series of entries that provide counts by:
Product Form plus an ISBN OR a product form that represents all the same thing
Product Form without a specific identifier and that DOES NOT represent all the same thing
This will be more clear in the examples because there are two ways to provide a count.
Before we get to the examples, there are a couple of pieces that need to be used correctly.
Product Composition
Product Composition provides a level of definition above Product Form — the code we’ve seen defines the product. Its purpose is to provide additional information about what the ONIX record supports at the highest possible level. One part of that is exactly the triage that I led this post with:
The product is either a single component product (typically “a book”) and there’s nothing to count OR it’s a multiple component product where by definition there is something to count.
The product is either sold to consumers OR the ONIX record describes something supplied to or sold to retailers and is usually related to multiple components.
And that means when you declare something as:
A single component product AND sold to consumers you need to use what I’ve called the “singular Product Form codes”
A multiple component product AND sold to consumers you MUST use one of the leading S Product Forms AND use Product Parts
If you are providing something supplied or sold to retailers you MUST use one of the leading X Product Forms AND if you also need to provide defining counts of components then you MUST use Product Parts, and will likely need to identify the components by their ISBN and individual Product Form
Product Composition also allows you to specify information about what you are providing to retailers so it provides extra support to define the purpose of the X Product Forms
And it is used to identify records that provide information rather than products for sale
If you wanted to create an ONIX record for a component only sold in another product there’s a code in Product Composition to identify it. That might allow you to assign an ISBN (or another identifier) that would help both you and retailers keep track of the bits that are sold as part of a multiple-component product even though you never sell the component outside of it.
If you wanted to create a listing for all the products in a collection so a unified listing was available but there’s no need to sell it as a unit, there’s a code for that.
Product Composition may seem redundant but consider what’s “special” about those information-related codes: There wouldn’t be a Product Supply statement or a price, and what do all retailers need? Those two, in every record. It’s not practical to expect retailers to process these sorts of data points without being warned about their atypical purpose. That would mean you probably should ask if they can take them before you send them, but I fully expect that over time other special cases with develop.
Product Composition must be used correctly and as defined by the code list’s notes. Neither you nor your trading partners should be ignoring it just because over 90% of all book records will share the same List 2 code. It provides support to retailers’ processing by defining how they should expect to use the record: if it’s for sale bundles or support materials used by them, if it’s used as information to keep their records straight, or if it’s for sale to consumers. This code set tells them how they should process the record to use it. It’s an important part of getting it right.
Examples of the two ways to provide a count of Product Forms
It’s mandatory for every Product Part entry to have one (what I’ve called “singular”) Product Form AND a count — even if the count is “1.” There are two different tags to provide a count but only one can appear in an entry — if you use one, you don’t use the other.
<NumberOfCopies> / <x323> is how you count Product Forms with ISBNs, or any Product Form where the product is identical.
<NumberOfItemsOfThisForm> / <x322> is how you count Product Forms that are NOT identical products.
Example 1:
A shrink-wrapped boxed set of Lord of the Rings would have three Product Part entries, one for each volume in the trilogy. So the ONIX record would contain:
The Product Form for the record would use the code for the boxed set, which in ONIX is the code for slip case “SC” for “Multiple-component retail product, slip-cased.”
In ONIX “boxed” means a box — a six-sided closed box. “SC” slip case is what this market calls a “boxed set” – an open-sided container that the consumer will normally keep.
Each of the three Product Part entries would include:
Its individual ISBN
The count as “NumberOfCopies” equal to “1”
The Product Form in each is “BC” with PF Detail “B102”
The boxed set is shrink-wrapped but you would NOT choose “SD” (shrinkwrapped) as the main Product Form because it's in a slip case, but you can use the main product entry’s P.3.7 Product Packaging type code to say that the product being sold to the consumer is in protective film:
<ProductPackaging> / <b255> Code “21”
Example 2:
Imagine it’s a classroom pack of 10 copies of the same book — Huck Finn — with one fully published Teacher's Guide and 10 blank stationary notebooks without an ISBN. Let’s not worry about the environment and say the 10 copies of Huck Finn are boxed, the notebooks are shrink-wrapped together, and the entire shipment arrives as a shrink-wrapped unit.
The tag used for counting remains Number of Copies because what’s being counted is identical within its product form.
Disclaimer: It's possible to think through shipment options and product multiples that exceed Product Parts capacity. This example is already silly in terms of how you’d actually create a product for sale, but it’s made extreme to help show how it can work. Product Parts works well for things you expect a retailer to sell and handle and an ONIX record isn’t designed to support pallet shipments. It can handle stuff in a box with multiple ISBNs. Some good pieces of ONIX advice are: “Don’t be silly, be practical” and don’t ask for book metadata for extreme edge cases because you won’t want to do the programming it will require.
The main Product Form for the record would use the code for the shrink-wrapped, “SD” for “Multiple-component retail product, shrink-wrapped.” You could alternatively use the generic “SA”, “Multiple-component retail product, unspecified”, code plus P.3.7 Product Packaging as in the previous example — but in this case, the components are a bundle sold to schools and shipped in shrink-wrapped to make a unit. In the first example, the use of Product Packaging allowed identification of a boxed set — something sold to the consumer and needed for online display. That’s more important than it being shrink-wrapped — which is still important for a retailer, and maybe the consumer, to know.
It would still be three Product Parts entries:
Huck Finn would be one entry
With ISBN and “NumberOfCopies” equal to “10”
Product Form / Detail “BC” / “B102”
P.4.9a within Product Part <ProductPackaging> / <b225> Code “09” In Box
Teachers Guide would be one entry
With ISBN and “NumberOfCopies” equal to “1”
Product Form / Detail “BC” / “B102”
Notebooks would be one entry
“NumberOfCopies” equal to “10”
Product Form “PR” (notebooks from the Stationary section with leading “P” codes)
P.4.9a within Product Part <ProductPackaging> / <b225> Code “21” Shrink-wrapped
Note that I did NOT list a P.4.9a within Product Part as a Product Packaging entry for the Teacher’s Guide. It’s shrink-wrapped within the shipped unit with the box of Huck Finn and the second unit of shrink-wrapped notebooks but I would NOT suggest considering showing it as “00” for no outer packaging because that would be confusing and not helpful. It could even be taken as it arrives separately from the other package — after all, it is “in outer packaging” given it’s in the packaging for the whole product being sold.
I know this seems pedantic but I’ve noted the use of default values of “00” in Product Packaging and in general, I think that the use of “defaults” in ONIX is a bad idea. It’s better to say nothing (provide no data tag) than to make retailers load data that doesn’t tell them anything useful. I think some companies may think that using a default provides consistency, but defaults have a way of creating ambiguity and misinterpretation. As another example, I cannot count the number of records I’ve seen with a <NoEdition/> tag paired with a Title entry that included “Second Edition.” Title shouldn’t include Edition to begin with, but the second wrong simply reinforces that retailers cannot rely on the <NoEdition/> tag to contain useful information. That’s how default values spoil coherent metadata and maybe it’s too late to save Edition but let’s keep Product Packaging meaningful.
Follow the ONIX convention of saying nothing when you’ve nothing to say.
Example 3 using Number Of Items Of This Form:
<NumberOfItemsOfThisForm> / <x322> is used when the multiple in the product part entry is not the same thing. So that eliminates anything with an ISBN because it has to be the same thing — and as a generalization, you should include any ISBN available for a product in a Product Part entry, so we are talking about products that share the same Product Form but are not identical.
If in the first example for the boxed set of Lord of the Rings, let’s say that the individual books did NOT carry an ISBN and are only sold as a component in this slip cased product (boxed set) that arrives shrink-wrapped so you can count on the books not being separated.
That would make one Product Part entry:
Product Form / Detail of “BC” / “B102”
Number Of Items Of This Form / x322 equals to “3”
The decorative slip case remains using the main Product Form as “SC” for “Multiple-component retail product, slip-cased”.
P.3.7 <ProductPackaging> / <b255> Code “21” remains to say the product being sold to the consumer is shrink-wrapped.
And there would be no change in how the book’s title is handled — more on this below.
Other examples might be:
Mini-book packs where the retailer gets an assortment of different books for a counter dump bin. This really should be by ISBN — but then the assortment would need to have a set number for each ISBN. Practically speaking leaving such counter premium mini books as a random assortment rather than tracking them individually might support a price point that enhances their point-of-sale appeal.
Assorted t-shirts — different designs, different colours.
Assorted journals — say a bundle of various stationary diaries.
It’s actually hard to think of good examples because the lack of definition is inherently problematic — but that would be why it’s important to use this tag properly. “Number of items of this form” with its clumsy name gives a clear indication to the recipient that the contents are NOT identical. The alternate, “Number of copies”, is a clear indication that what they get is the same. If you don’t like using “Number of items of this form” solve your problem by assigning ISBNs and identifying identical things with knowable counts.
No one will complain about accuracy!
Of course, you might wonder if, say, stationary notebooks that are identical in size, design, format, and page count with variations in cover colour are “different or not.” I’d say it would depend on the accompanying title and description. When in doubt ask your sales rep to be sure — and maybe they should ask their retail buyer, who will likely say “Don’t send me green ones. They don’t sell.”
Frequently Asked Questions
Titles
You’ll note that there’s something missing that you might expect Product Parts to support given that it’s describing a component: You cannot supply a component’s book title in your entry. You can supply its identifiers, Product Form and Detail (same as you might in Related Product — and like Related Product you would expect the retailer to use the ISBN to link back to that record), things you might need for shipping like the Country of Manufacture (used only if it’s meaningful and different from the whole product), or things that might need to be displayed to the consumer if the individual components need explanation such as the size and weight, forestry certification, and so on. But Product Part does not provide for the book title.
That’s because the component’s book titles should be supported in the Product Title entry — where as you know the now 12-year-old “new standard” allows for various parts of a book title to be parsed as labelled entries and recorded in display order within the Title entry's repeating Title Element composite.
One of the parsing options in Title Elements is ONIX Code list 149 Title Element Code: “04” Content Item which is defined in its notes as “The title element refers to a content item within a product, e.g., a work included in a combined or ‘omnibus’ edition, or a chapter in a book. Generally used only for titles within <ContentItem> (Block 3)”.
As suggested in this code, you can also support a structured and detailed table of contents (or index entry) for each book in Block 3 Content item. Its use is recommended as it can add a layer of reliable structured tagging that would be hard to replicate in a Block 2 Text Description for a Table of Contents entry. The simplicity that you need to use in Block 2 works against you but Block 3 Content can provide a clear framework for more complicated entries.
A single book in a slip case
Case one — the individual book and the book in a slip case share the same ISBN.
Just follow the normal triage:
Use the normal “singular” product form and its detail — probably BC with B102
Use P.3.7 Product Packaging and use “10” to show it’s in a slip case
You’ve already counted it by using the code for single component product “00” in Product Composition
Case two — the book has its own ISBN different from the slip case product’s ISBN.
You could follow the triage above — it wouldn’t be wrong but maybe it’s less than ideal because there are multiple ISBNs in play. I’d recognize that metadata can require compromises — and edge cases grow in length. You can use Product Parts if it’s needed and that’s a business decision you can make.
The fact that the book doesn’t share the ISBN with the book with slip case is a problem.
Another is that Product Packaging does not repeat so: What if it was also shrink-wrapped and it was important to provide that information?
P.3.7 Product Packaging is always the most outer layer of product packaging so of necessity it would have to be coded as “21” for shrink-wrapped
You’ll need to treat the book and slip case as an “SC” product to show it as “in a slip case”. That will require you to:
Use Product Composition as “10” for multiple components — that will warn the retailer to expect to find the product defined in Product Parts
In Product Parts use the normal “singular” product form and its detail — probably BC with B102
Number of Copies (the count of the Product Form) is “1”
Assuming the book carries its own ISBN, it's provided as part of the Product Part entry
There are two tricky bits that might be handled in a couple of ways
I would not provide a P.4.9a within Product Part Product Packaging code because you’ve already used the SC to provide it.
If the scenario weren’t as simple as having a specific code that covered it, then I would use the generic “SA” for multiple parts unspecified and that would allow me to use individual Product Forms with counts as needed — and in that scenario, you could use P.4.9a Product Packaging within Product Parts to say “in a slip case” with the entry.
If there’s only one ISBN (the book is only sold in the slip case) AND you need to list it in Product Parts
In this case, I would NOT repeat the ISBN in Product Part because it has already been provided as the identifier for the Product. A good rule of thumb in metadata is never to repeat a metadata value — or if you do there should be a reason for it. Here’s an example of good vs. bad repetition:You provide a GTIN-13 as well as an ISBN-13 because they are two different identifiers and both are used by retailers. The fact that they are (typically) the same number isn’t relevant (and sometimes they might not be the same). This is also specified by a recommendation in the North American Metadata Best Practices. When we clarify something for our market in this document it’s done because it’s worth doing.
You DO NOT duplicate the ISBN-13 in Product Part because that would have the retailer looking for a match outside of the product record and the record is its own match. (If I remember my original Star Trek that would be the way to defeat an evil robot and retailers are never that. In reality, the retailer is to the publisher like Frankenstein is to the blind musician — “Friend!”)
That’s too long, but as a final comment: I think it’s important to see that the Product Composition is an active part of ensuring this is readable metadata. You are allowed — and in many cases must — use Product Part to count “1” and by using Product Composition to “make-this-record” a multiple you clarify that your use of an “S-code” with Product Part is intentional. Product Composition can seem like overkill but an ONIX record is weaker without it.
Sign up for our weekly newsletter to stay on top of all the future instalments of this series. And if you have questions for us, please drop us a line. We’re always happy to talk Standards!
Want to make data-informed decisions? We can help.