Using the Related Products composite is not complicated but it's very easy to get mixed up.
To understand how to use the Related Product composite you need to know that everything else in an ONIX file is describing the very specific product as it is sold to a consumer. An ONIX file is like filling out another company's on-line product description for one ISBN. You want to know what to put in the Measure Composite? You pick up the book with that ISBN and use a ruler and scale and fill out the information. Can you measure a digital file? Then you don't use the Measure composite because you don't use metadata elements that can't apply to this product. And so it for goes for every other composite: The Sales Rights composite describes the rights that the Publisher has on this product and not the rights they may have on the overall author's "work." The Supply Detail describes who retailers can order this product from and on what terms.
Once you think in those terms Related Products become a lot easier. This is the composite where you can stick a different ISBN representing another product and provide a code to explain how the two products relate. In Related Product you're still describing how the other ISBN relates to this specific product so, for example, code "03" (Replaces) means that the <Product> (the current record ISBN) "Replaces" the ISBN given in Related Product Composite.
In the Related Product composite you're giving instructions to end users of your ONIX data so they can figure out which book they should be selling or offering to consumers or clients. Or you're telling them about other products they might sell or can be considered equivalent to this product for evaluation of the current book.
Example: If you want to make sure a retailer can keep all the books by one author together so their buyer can keep the backlist orders up and a consumer trying to find them on their website can buy them all easily you, then you list the ISBNs in Related Product as "by the same author". Is that all you can do? Spell the author's name consistently in all records. If the author produces his/her books in a Series be sure that's in the metadata both as a series entry and in Related Product as "In the same series." And spell the Series Name consistently. Then you ramp up by using name identifiers for any name (author or series) to provide an extra hinge for the end user to use to get it right. Then you ramp higher still by using outside standards like ISNI as the identifier so you've created the "persistent" identifier that helps discoverability. But to create direct, clear relationships Related Product is the most used way, right now with retailers today, to achieve the goal of keeping that author's books together.
The trick to using Related Products? You don't know which book the on-line site is going to start with. If they choose their selects based on information they pulled from the hardcover it should match what they would get from the most recently listed ebook. Similarly all the names should be presented identically in case that's how the end user is matching. The same is true if you use any identifiers. Make it as easy as possible for the end user because it's not their job to build a picture of this book by doing extensive cross referencing all the information in each book. Consistency is key.
Edition is one of those terms that can mean a lot within publishing – that book on the table can be called an edition – but in metadata the meaning of Edition should be specific and the Related Product composite plays a big part in it's use.
When a publisher creates an "edition" that deserves mention in metadata as an Edition they've changed the content of something in one of their published books in some substantive way and issued it under a new ISBN. There's an old product and a new and likely improved product. In a few special cases Edition is used to show some special market or limit in the supply chain: "Large Type" or "Ultra Large Type" are considered "Edition Codes" in metadata (a special market) and so are books that are published initially as "digital editions" without any print counterpart (atypical supply).
Let's start with the typical case in publishing: All formats – hardcover, paperback, digital, etc. -- that share the same text or text-and-illustration combination are "identical content" and are considered to be of the same "Edition." Or to state that another way: By far the vast majority of books published come out in a single original edition and are only available in multiple formats. In good ONIX metadata these are identified by the <NoEdition /> tag which very accurately says what it means: Don't go looking for "edition" related information about this book because it doesn't exist. You can improve the metadata entry by providing a "Work Identifier" that shows all these entries are, indeed, the same content – and the "persistent" identifier to improve discoverability would be an ISTC. All publishers should use at least a proprietary Work Identifier and if you must use an ISBN (usually of the first released product) then be sure to use that ISBN in ALL of the products including the book you take it from. End users should be able to simply "select" using the Work Identifier and get all the books.
Let's pause for a moment and think just how useful <NoEdition /> is to end users: A marker for "All the formats I sell share the same content!!" Genius -- thank you EDItEUR! That means there's no extra implication here for Related Products beyond those listed above.
That takes us to the most typical metadata use for edition information which is using an "Edition Number" to mark a later edition. The general convention is that a sequential Edition Number is used when you published an updated book where 20% or more of the content is changed or new. It's a marker to show libraries and previous buyers that they should consider replacing their book copy, and for retailers so that they know that this is the book they should be offering for sale. Lesser changes than typical for an Edition Number but that still warrant a new ISBN can be marked using a "Edition Type Code" that describes the change. It really does NOT make sense to do both at the same time. An edition number "2" combined with "Revised" implies that there may be an edition number "2" prior to this "Revised" version so it's very much an either or choice (unless you really are revising the second edition and issuing it as a new ISBN – and then I have to wonder why it's not "3" if consistency is key).
What you're really doing while Edition information is telling end users that there are other options for CONTENT – not just format. That's really the meaning of Edition in metadata: Options are available for content and those books will have different ISBNs.
Clearly an Edition is a meaningful thing in a supply chain but retailers need to get information about many copies they sold previously and librarians need to confirm that their clients really did use the previous editions a lot. Related Product is how they track that old edition (listed in the new product as "Replaces) or know from their records that that there's a new edition of a high sales title (listed in the old product as "Replaced by"). It's a daisy chain! It's not only pretty but in enables records to be linked.
It that all you can do? Of course not. You should give a clear statement about what changes have been made to the new edition to explain why it's worth buying. That's usually part of the Main description that buyers and librarians will be using for their initial assessment. You might use Edition Statement for that as well but check the manual for recommendations on it's use. I if you've supplied Edition Number or Code you don't usually need Edition Statement as well. Consistency in your records is always recommended so in addition to adding the "Replaced by" ISBN to Related Product you should remove the <NoEdition /> tag from ALL the book records that carry it for that work (not just the same format – that there is new content is true for all the books even if there isn't a corresponding new format. Use the Work Identifier and it's easy). Note that replacing it with Edition Number "1" is optional and recommended only if adds clarity. For example, if the new edition is numbered "2" then making all the formats of the original edition "1" is clear, but if the new edition is "REV" then it's maybe less clear and up to you. The main thing is to remove the tag that says "no other edition exists" as it's now false and let the simple fact that it's an OP record listing another book as "Replaced by" identify it for the supply chain. If that other book is simply marked by a "REV" Edition Type Code everything is clear enough.
Books are books, content is content and format is format. An ebook with the same content as a print book is just another format of that book. Why is that so unsatisfying and clearly not entirely true? It is true in terms of the metadata though digital books – like any other format – have unique coding. It feels wrong because digital products are often sold in a different supply chain, and because digital products have their own lingo and history – one part of which is product version numbers and file version control.
In general we (who? BookNet, the standards community) recommend that the concept of "edition" be protected as useful (restated:books of the same content are part of the same edition, and that substantial changes of content should be highlighted in the supply chain(s) as edition changes). It's been developed over 400 years and it's a simple and effective tool – and it works in the digital world as well as the print. Let's make a parallel between software version numbers which loosely go up by whole numbers for major revisions and keep the regular definition of Edition.
But digital files are corrected and files will be periodically re-issued – so there is a need to communicate with your trading partners what the current "file version" is. ONIX provides for this in Edition Version Number – which is a number that must be used with an Edition Number, leading to a conundrum: If you must provide an Edition Number to provide an Edition Version Number, and we don't recommend using an Edition Number until there are multiple editions, how do you supply a digital version number? Simple: Sometimes the design of metadata standard isn't ideal and you live within that. If it's necessary to use Edition Version Number, then supply an Edition Number 1 if necessary. Think of it this way: you're forcing the end user to track the version number and at that point the "1" becomes meaningful too. Everyone else should try to respect the usefulness of using the <NoEdition /> tag.
Please note that there are no established guidelines within the digital product supply chain on file version number. This is an area you should expect change.
You might note that I avoided the phrase First Edition and avoided writing out First, Second... as editions. There are two reasons for that: First, in metadata Edition Number should be given as a number -- 1, 2, 3, 4... and not as First, Second, Third, Fourth, or as 1st, 2nd, 3rd, 4th... Metadata always use integers (numbers) if the manual asks for them, and it usually will because databases can "action" numbers and use them to add, subtract and order sequentially. Words look nice and read well but they do not sequence without extra programming, Make life easy for your trading partners and always choose to make your file "machine readable" whenever possible.
Second there's confusion about First Edition in that people collect First Editions and the phrase can mean a first printing of the original edition. Metadata is not trying track this – that a subset of a book's print run may or may not be collectible is not really a supply chain problem. If you are selling a proper collectible First Edition at a higher price and want it in the metadata, then you'll need to issue a unique ISBN and it's metadata would provide an excellent use for the Edition Statement to add "Signed and numbered First Edition." It would likely only be available through direct order or at most a limited number of stores. All that can be accommodated in ONIX if necessary but generally we're talking about the books that retailers can buy and or sell for you – the regular run of the book – and the recommendations here are for representing regular book transactions.
Don't leave mad though, here's a thought game you can play: Can a collectible First Edition have a meaningful Related Product entry in the sense described here for other editions? 500 word essays will neither be accepted nor read, but BookNet Canada will collectively be amused and appreciate the effort.
Read more about Edition and Related Product on the BNC Blog at https://www.booknetcanada.ca/blog/2020/2/26/dont-do-what-donny-dont-does-editionrelated-product. Subscribe to the Blog's RSS at https://www.booknetcanada.ca/blog?format=rss.