A couple of questions were sent to the BookNet offices recently, both about the simplest cases for using a set in ONIX, so I thought I'd expand the answers into a blog post. EDItEUR has guidelines as both a 2009 document as well in its ONIX for Books: Implementation and Best Practice Guide, but as admirable as these resources are, they centre on ONIX 3.0 and the pragmatic questions relate as much to 2.1. Overview documentation also tends to move rapidly towards complicated cases, and that can disguise just how simple the basics really are.
One of the perennial ONIX questions also happens to be: What is the transition between 2.1 and 3.0 all about, anyway? So in order to kill two birds with one blog post, I'm also going to provide a focused look at the difference between ONIX 2.1 and 3.0 in this one small case.
One change made by ONIX 3.0 was to give up trying to define the difference between 'set' and 'series,' and instead, it grouped everything under a new term: 'collection.' The terms can be confusing, so let's start with a definition: A 'set' refers to a book product made up of more than one book and sold under a single ISBN. A example, a boxed set of seven paperbacks sold as a single unit. Let's keep it super simple and not assign ISBNs to the individual volumes, it's only sold under the one ISBN. Let's take a look at how this works in ONIX.
ONIX 2.1
While Product Form describes what the product is as a book, it doesn't assign a quantity to that what-ness. Most book products contain a single book, but what makes a set special is that it contains multiple books.
This is how this is communicated in ONIX 2.1:
- PR.3.1 Product Form: 'BC' paperback (plus PR.3.2 Product Form Detail is B102 to clarify the type of paperback)
- PR.3.7 Product Packaging: ONIX Code List 80 value '11' or 'slip cased set.' (According to the code list notes, a slip case is “commonly referred to as ‘boxed set’.”)
- PR.3.9 Number of Pieces: 7. (This section asks you to provide the quantity of items in the set. In other words, indicate the number of homogeneous Product Forms.)
In 2.1, Product Form plus Number of Pieces are intended to describe a set, with the option of adding a code value to define the packaging, if necessary. It's that simple.
One source of confusion is that Number of Pieces should only be used to count a single type of Product Form – paperbacks in this example. When a set is made up of different things, such as Book and Toy, Book and two DVDs, or DVD and Download, you should use 'WW' as Product Form and it indicates a mixed-media product. A product made of more than one thing is different than a product made of multiples of the same thing; in the former you don't use Number of Pieces and in the latter you do use Number of Pieces. Think of it this way: It doesn't make sense to supply a count of "more than one" because saying "book and two DVDs" is "three" or "book and download" is... well, what? It means nothing to a retailer. When using 'WW,' you can provide details about each individual Product Form in the Contained Item composite.
Don't forget that you have all sorts of free text options to describe the product: Title and Subtitle, Product Form Description, and the marketing copy can all be invoked to describe any aspects of the set. A set is special – it's bigger than a book.
The other complication I'd like to highlight is that it was only by reading the code list notes that I could be sure that what ONIX called 'slip cased set' was what we in North America call a boxed set. Always read the notes!
ONIX 3.0
- P.3.1 Product Composition – ONIX Code List 2 requires you to state before all else if the product contains 00' – a single component or '10' – multiple components. In this example we'd select '10'.
- P.3.2 Product Form is 'SC' – Multiple-component retail product, slip-cased*
The primary difference between 2.1 and 3.0 when it comes to sets is that 3.0 does not support an equivalent to 'Number of Pieces' at the single Product Form level. Instead it's much simpler.
2.1's method requires that you differentiate between multiples with the same Product Form and those with different ones. It was confusing and prone to misuse. In 3.0, simply choosing 'multiple component' at the Product Composition level means you go to the S_ section of Code List 150 to find multiple-component codes, which requires supporting Product Parts.
Here's how it would work for our example:
- P.4.5 Product Form Code (Product Part) is 'BC' (and probably should include the P.4.6 Product Form Detail 'B102' to clarify the type of paperback)
- P.4.12 Number of Items of a Specified Form (Product Part) is '7' for the quantity.
In this simple case of seven paperbacks in a set, ONIX 3.0 follows the exact same logic as 2.1 in Product Parts of Product Form and the much more explicitly named Number of Items of a Specified Form. Many publishers would have assigned an ISBN to each volume and, if they had, they would support a Product Part entry for each ISBN.
A note on using Product Parts
Does that mean every ONIX 3.0 user should support use of Product Parts? I have to say “Yes” for two reasons:
- Reviewing data in BiblioShare shows that support of ONIX 2.1’s Contained Item is common among many publishers, including several major ones, and that means retailer support is also high. Most children's publishers support Contained Item because they sell multiple-item products that can only be described this way. Companies that supply dump bins usually support it as well. If support of an ONIX structure is high with retailers, its use should be common in data senders even if the number of products in your data that it affects is small. Retailers need that overall consistency to use the data fully.
- The transition from ONIX 2.1 to 3.0 requires you to support small changes in your data to improve clarity and accuracy. Since we know that 2.1 was prone to misuse with regards to Number of Pieces, EDItEUR made changes to improve accuracy in this area. Product Packaging remains a code list that you really should support, but EDItEUR took a common need – slip cased set (aka boxed set) – and made it a Product Form option. Note that there's still a minor inconsistency in that a single book sold in a slip case would require use of a Product Packaging code as the 'SC' option applies only to multiples.
In short, supporting Product Parts is the simplest option.
Sets in 2.1 vs. 3.0
While much of ONIX 3.0 is virtually identical to ONIX 2.1, small tweaks and changes – like the ones outlined here – are spread throughout the new version. ONIX 3.0 is a different MAPPING of your data; it is NOT a matter of simply converting the tags in existing 2.1 data and rearranging their placement. In the case of sets, the structure is handled differently. And if you had previously been keeping up to speed on improvements to the standard by updating your 2.1 to support Contained Item, the transition to 3.0 would now be easier than trying to develop your 3.0 based on an incomplete implementation of the previous standard.
"J'accuse, Tom!" you say. "You're bitter and unrealistic, aren't you?"
Not entirely, so let's talk about kludge solutions, since both 2.1 and 3.0 offer some room for firms with occasional need to work with their system limitations. (I add this because when I provide one-to-one ONIX advice, I usually have to discuss this and my motto is: Implicit in any best practice is the existence of other practices.)
First, as noted above, it's a normal 2.1 convention to supply the single book Product Form and Number of Pieces without Contained Item. This covers the simple case well. For multiple product types, say a Book + Toy multiple, the kludge solution used to involve using the primary product code for the book and hoping the retailer notices it has the second product attached. More recently, you've likely used WX without Contained Item because it at least warns the retailer that it's not a "simple" book. In either case, ISBN lists can be provided using Related Product.
By streamlining multiples and tying two primary values (i.e., multiples in Product Composition supported by the S_ Product Forms) to identify them, EDItEUR is clearly directing you to use Product Parts. As a kludge solution for firms who support a small number of simple sets and are trying desperately NOT to fully implement Product Parts, I recommend that you at least consider using a single Product Part composite that's set up to support the simple case above and support it as you do now with Related Products. I'm not going to recommend handling multiples with different Product Forms any other way than using Product Parts. Talk to your trading partners to find out what they need, and I suspect you'll implement Product Parts.
And, finally, 2.1’s logic requires implementing Product Packaging and Contained Item for sets. Since ONIX 3.0 logic assumes you’ve already done this, the changes described above are minor tweaks.
What to do if the volumes in the set have individual ISBNs
Let's close by looking at a simple set where the individual volumes each have their own ISBNs. This leads to the conundrum: Do I use Contained Item (2.1) / Product Parts (3.0) AND the Related Product composite to list the bits that make up the product I'm describing as a set?
Some things to consider when approaching this scenario:
- For 3.0, the best answer is clearly provided by Product Parts.
- Similarly, use of 2.1’s W_ Product Forms means you really should use Contained Item.
- It’s also clear that if you cannot supply it the right way, you should use Related Products.
- Arguably, when describing a set in 2.1 where all books are the same Product Form, Related Product might even be preferred.
While the answer is clear in 3.0 that Product Parts should be supplied, there's still a case to provide both this and Related Product. Product Parts can be seen as supporting retailers' systems, while Related Product supports their marketing. As well, some end users may only support one system and Related Product is very heavily used and requested.
I recommend that you supply both in most cases. And if you use Related Product, represent the set contents using the following ONIX Code List 51 Relation Type values:
- The set's ISBNs are each listed as Relation type '01' Includes.
- Correspondingly support each individual volume with references to the set using Relation type '02' Is part of.
- Finally, support the set by providing '30' Product in the Same Collection (but if the set has a large ISBN count you might consider asking trading partners if they find this helpful. A 16-volume set would have 272 separate ISBN entries to fully cross reference itself.)
It never hurts to contact major trading partners and say what you support or plan to change to help them use your data better.
* What’s the difference between ONIX 3.0 Product Forms 'SB' (boxed) and 'SC' (slip-cased)? Well, the former is a box and the latter is open on one side. As noted above, a North American 'boxed set' usually means a slip case in ONIX, but in the ONIX code list the notes make clear a box would be a six-sided safe shipping device around your expensively produced set and a slip case implies looking good with spines visible as a unit in your book case.
