Bundles present a great opportunity for publishers and consumers alike. With print books there's an object with scale – the consumer can see how many inches of thickness over three books are in that artfully presented slipcase sitting in a bookstore. The big sticker says what a great value they get. Half the problem for print book publishers is getting that bundle visible in the stores – so it's getting buy in by the retailers and paying any necessary co-op costs – but once it's visible then it should sell itself to consumers looking for it. Of course getting them looking is the other half, but it's all within the traditional skills of book publishers and sellers.
Even on-line sales are easier for print books because that 3-D product shot still carries scale information – you know what it is at a glance – but once you're solely dependent on the metadata problems start and they get acute for digital products. A digital book can be broken up into "shorts" (de-bundled?) – short stories or chapters – as quick content. Or the digital book can be one downloadable file with 5 full length novels inside. From the consumer's perspective it's a file, one file and outside of the metadata – the fine print – shorts and bundles can look the same. Seriously: for a short you may need to say where it's from – and what else they might buy (inform them about the complete book they don't get). And for a bundle you need to say what's included (reference the books they do). There may not even be much of a price difference if the publisher is holding a temporary promotional sale. Do they know which they are looking at a glance? How can the consumer know what "value" is from a digital on-line record?
That's the digital bundle problem: A digital bundle file is like a print publisher's omnibus edition – there are no "parts" to it, just one big file. But like print books getting retailer buy-in on the bundle is an important part in selling it. It won't be easy on its own.
I don't have an answer, but while I usually try to "go simple" and avoid raw ONIX in these explanations, I think that in this case the opposite is needed. All the parts you can put into play (in ONIX – your system might not support them all) and show 2.1 vs 3.0. The point would be a document that you can use with a trading partner – where they can say: We don't support that, but we can use that.
3.0 blocks are noted but don't exist for 2.0.
Identification Section (used with all blocks)
PR.1 Record reference numbers, type and source
No relevant comment for bundles.
P.1 Record reference, type and source
PR.2 Product numbers
The bundle's ISBN. There's little difference between 2.1 and 3.0 here except 2.1's repeatable Barcode element (List 6)
Typically a bundle of books are books that are also available under other ISBNs – that's further down. This is the section where you put the unique ISBN that represents the BUNDLE – the order number for product you're describing.
P.2 Product numbers
The bundle's ISBN. 3.0 supports a repeatable Barcode composite that is more flexible using Type (List 141) and Position (List 142)
There are differences between 2.1 and 3.0 for Bundles and they begin with ONIX 3.0's Product Composition tag which has no counterpart in 2.1. ONIX .3.0's Product Composition isolates some of the problems of using Product Form that create problems for ONIX 2.1 users.
There is no comparable ONIX 2.1 section but in 3.0 Product composition allows at the highest level allows identification of a multiple-item product – and that includes a physical book bundle.
Multiple physical items should be supported using Product Parts in ONIX 3.0. While Contained Item in ONIX 2.1 is often not supported, ONIX 3.0 use "expects" Product Parts to be used.
All digital products, bundles included, are almost certainly code 00 Single Item retail product. WHY? There's only 1 digital file – the number of files amalgamated to create it doesn't play a part here.
A typical print bundle would be code 10 Multiple-item product retailed as a whole but that assumes that the print book has distinct volumes. An omnibus edition would be a type of bundle that would be a single product – in the same way a digital file is one thing. Also note that packaging doesn't count: A slipcase isn't a "part" in this context (any more than shrinkwrap would be) so a single volume in a slipcase is a single product.
P.3.1 Product composition (List 2)
At a high level Product composition lets retailers know how they can sell the product.
PR.3.1 Product form code (List 7)
If it's one or three paperback books the Product Form is still "BC" – you're just describing the for of the product.
The logic of digital products remains the same – and because most digital products are comprised of a single file standard digital practice applies to bundle products here.
Most bundle products do not require use of Contained Items / Product Parts – but see more below as they offer options for communication.
P.3.2 Product form code (List 150)
PR.3.2 Product form detail Product Form Feature composite
No special options for Bundles here.
P.3.3 Product form detail Product Form Feature composite
PR.3.7 Product packaging type code
Physical product bundles should supply this value: It would be normal for a bundle of several "objects" to be supplied in some form of packaging – even if only shrinkwrap.
P.3.7 Product packaging type code
PR.3.8 Product form description
No special instruction here but note as a "very useful way" to explain the product to the retailer if there's anything not well covered in the codes.
P.3.8 Product form description
PR.3.9 Number of pieces
Here is a major difference between
PR.3.10 Trade category code
No special options for Bundles here.
P.3.9 Trade category code
But if it's a book and a DVD – two different Product Forms then it's: ONIX 2.1: "WW" (or another W_ code – use Contained Item to describe the individual products) ONIX 3.0: "SA" (or another S_ code – use Product Parts to describe the individual products)
*FOR KLUDGE OPTIONS: See note 1 below.
Data exchange, like life, involves compromise. Where it's "fairly common" for a subset of the market to not support the "right" way in ONIX to supply data here are some alternatives
Do you need to support Contained Item / Product Parts? Well, most children's publishers who have a substantial number of book and toy products do support it. And major retailers like Amazon take it. But some publishers have a very small number of