There is an excellent presentation on this as Section 8. COLLECTIONS: SERIES, SETS, AND BUNDLES in Best Practices for Product Metadata: Guide for North American Data Senders and Receivers and anyone interested in this topic should review it.
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.
|ONIX 2.1||Comments||ONIX 3.0|
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)
BLOCK 1: Product Description
PR.3 Product form
ONIX for Books Implementation and Best Practice Guide
available on EDItEUR's website provides an excellent
overview with examples for how to handle the
P.3 Product form
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
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