This is the second installment in a series of blog posts (introduced here) offering solutions to help you update your ONIX 2.1 data to make it compatible with the needs and intent of ONIX 3.0. This post has been updated as of July 25, 2016 to reflect updates to ONIX 3.0.
If you haven’t already, I would encourage you to read the introduction to this series, which looks at why it’s important to modify your data, as well as the first installment on Collections. They do most of the heavy lifting in terms of overview and considerations for conversion.
This post looks at improved Sales Rights, as part one of Markets and Supply, to introduce some changes in the handling of territory statements as well as a new element that helps reduce ambiguity. So while my focus here is demonstrating Sales Rights, much of this extends to cover Markets and Supply.
What needs to change?
As I previously explained in the introduction, there are problems being solved wherever metadata has changed between 2.1 and 3.0. With regards to Sales Rights, as well as Markets and Supply, 2.1 and 3.0 have fairly similar capabilities but changes have been made to improve clarity and accuracy in international metadata, thereby solving two sub-issues:
- ONIX 2.1 is clumsy in how it handles territory statements and 3.0 streamlines things by using the same building blocks consistently.
- The second problem is outside the ONIX but relates to normalized bad data practices, where data senders have implemented rights statements incoherently and/or haven’t implemented market statements at all. It’s normal to see Currency Codes used as a proxy for market information (even though data senders may expect one currency to be used in multiple markets)—aggregators and retailers have learned to live with this. ONIX that supports digital records tends to be “better” but we’re still seeing poor data practices with the ones we get in BiblioShare.
The biggest change in the transition to 3.0—certainly for the North American supply chain, but I think elsewhere, too—has to do with this second problem. A good metadata file has within it all the information needed by retailers to load and select the right information. I speak as a data aggregator when I say how important this is: getting all the information in the file right means that you can automate processing of multiple sources accurately. That’s the goal of this, as far as I’m concerned.
How to do this is already well documented on pages 178 to 186 of Best Practices for Product Metadata (and much of that is sample script in 3.0 and easily digested), as well as in the EDItEUR documentation below. You should read those. What I find when looking at BiblioShare data is that data senders don’t get how easy Sales Rights can be, and instead make it unnecessarily complex. That complexity in turn makes it hard to absorb the data, which is why retailers generally ignore it. So, two basic points to start with:
- An ONIX record represents a specific product sold to consumers–it contains the Sales Rights for that one ISBN and not the work.
- Sales Rights are held by the company named as publisher.
There are functional limits here:
- A metadata file created by a rights holder, distributor, or a third-party data source can only provide what they’ve been told by their client (and that client may not be the originating publisher).
- The originating publisher who would know their product rights information can only submit data to the extent that: a) these secondary data sources have systems set up to absorb that information; and b) their rights records are exportable.
That’s the source of bad data practices: the “I don’t have” chain can extend all the way back to the originating publisher and the “I can’t support” chain grows from that. Retailers end up interpreting much of the data however they like, not because they’re evil but because they can and no one seems to care much. It’s easier to fix a small number of complaints than to enforce loadable data, especially when much of the data isn’t well done anyway.
A book’s rights, including who can sell it and where (i.e., its market), are important. It’s outside of the scope of this blog post to explain why, but it’s a fundamental expression of your ability to do business and needs to be supported in the metadata for the book to be sold internationally. The likely alternative is someone stealing the content to sell in other markets and retailers lacking the necessary information to prevent it. (A much longer review of metadata in this context can be found in Brian O’Leary’s 2012 BISG report, The Development, Use and Modification of Book Product Metadata—a timeless classic.)
The ONIX 3.0 solution (that’s equally doable in ONIX 2.1 (almost)):
A publisher’s rights to their product are best protected by a worldwide rights statement. While market statements can simply define the area they apply to, it’s different for rights statements: it’s only clear if it’s complete—if it’s partial, it’s ambiguous. That’s fundamental to how you create a rights statement. In either 2.1 or 3.0, you can say the publisher holds world rights on that ISBN, if that’s accurate, even if the metadata you prepare only serves a market subset of that. That’s why territory statements in Product Supply’s Market and Supply Detail are as important as Sales Rights: they define where the book is supplied or marketed to, and clarity there supports a worldwide rights statement.
ONIX 3.0 has one change to Sales Rights: you can also say “I’m not supplying more than I’ve said” and that’s a great improvement over 2.1, where that has to be assumed in the absence of information. The difference? A retailer can act on your statement: another metadata file from another market representing the same ISBN can be taken to be accurate if they know its market representation is outside the scope of your file.
Making the prevention of ambiguous metadata a normal business practice is the ONIX 3.0 solution.
ONIX codelists issue 46 for Sales Rights
You may not have looked recently at ONIX codelists issue 46 for Sales Rights (and it’s possible that your software hasn’t been updated), so this is what the ONIX standard considers to be the types of rights a publisher can hold:
| Value | Description | Notes |
| 00 | Sales rights unknown or unstated for any reason | May only be used with the ONIX 3 <ROWSalesRightsType> element. |
| 01 | For sale with exclusive rights in the specified countries or territories | |
| 02 | For sale with non-exclusive rights in the specified countries or territories | |
| 03 | Not for sale in the specified countries or territories (reason unspecified) |
|
| 04 | Not for sale in the specified countries (but publisher holds exclusive rights in those countries or territories) |
|
| 05 | Not for sale in the specified countries (publisher holds non-exclusive rights in those countries or territories) | |
| 06 | Not for sale in the specified countries (because publisher does not hold rights in those countries or territories) |
(I’ve left off 07 and 08 because they are deprecated.)
With these, you can clearly say that the publisher sells the product exclusively here, and though it may not support sales elsewhere, it still holds rights in the rest of the world. Or you can say that this ISBN cannot be sold here, that it’s an exclusive option there, or as to the rest, that the ISBN may have a competing product from another publisher (non-exclusive).
Really, you can say what you need to say in a couple of Sales Rights statements, maybe three. One difference between 2.1 and 3.0: Sales Rights composites are limited to three instances in 2.1, but you are not limited in 3.0. It’s still hard to use more than three, but it’s possible if you need to.
World rights and the basic rights statement
In an ONIX feed, the XML structures information as “composites,” which are statements or units with a clear start and stop. Since composites can be repeated, you can have more than one unit of information. Just like an ONIX record describes one ISBN, one composite associates a defining code (from codelists issue 46 in this case) with a value (taken from two other codelists in this case, more on them below). The most common unit within a Sales Rights composite is “Publisher holds exclusive (“01”) World rights on the product,” which is presented here in both 2.1 and 3.0:
The composite opens, unit begins:
b089 / SaleRightsType code “01” from List 46 is “Exclusive Rights”
and the area is defined by the territory statement “WORLD”
The composite closes, unit ends.
It’s a unit with two interlocking parts. However it appears on your data entry screen it's as if you’re transmitting to your trading partner little discrete units of information. In practice, multiple statements should make a coherent whole. And if you need that parsed out:
- A specific b089 / SalesRightsType code should only appear ONCE for each product. You can repeat Sales Rights composites (units) to support other SalesRightsType codes, but each code is mutually exclusive within a given product/ISBN. You shouldn’t expect the retailer to combine two or three “exclusive” statements to make a whole—you provide them with a single territory statement that defines where you have exclusive rights.
- The country/territory statement within each Sales Rights composite (unit) is also mutually exclusive against the territory statements in other Sales Rights composites (units) for that ISBN. You can’t say the Sales Rights in Canada are somehow both “01” Exclusive and “02” Non-exclusive, for example. You can read the statements and if they contradict each other they must be wrong.
- The ideal in ONIX would have the sum of all the territory statements in their uniquely defined units be the world. That makes the clearest statement because we expect retailers to respect the rights statement and anything less is ambiguous.
ONIX 3.0 Territory statement
In 2.1 you have two unique elements:
- b090 / RightCountry (supported by ONIX codelist 91); and,
- b388 / RightsTerritory (supported by ONIX codelist 49).
You use them in a very similar way in 3.0, BUT many companies are not doing so optimally. Plus, you may not always be able to convert the information directly to 3.0 even if that were the case. In 3.0, you use a new composite called Territory that supports four elements and one important rule (and one codelist change):
- x449 / CountriesIncluded (supported by ONIX codelist 91)
- x450 / RegionsIncluded (supported by ONIX codelist 49)
- x451 / CountriesExcluded (supported by ONIX codelist 91)
- x452 / RegionsExcluded (supported by ONIX codelist 49)
To use a Territory Statement in either Sales Rights or Markets, remember these points:
Statements should be as simple as possible and positive statements are easier to interpret.
The “Included” unit is always bigger. Whatever area is “Excluded” is always a subset of “Included.”
List 49 Region Code does NOT include ROW as a valid statement. ROW is NOT USED in 3.0.
Here are two typical examples of what’s expected in Territory composites:
The first territory statement expresses “Canada and the US excluding Hawaii and Alaska.” The second covers the world excluding the United Kingdom.
ROWSalesRightsType
Let’s look at the two territory examples as I’d expect them to be used in 2.1 and compare them to how they might appear in 3.0.
Example 1:
For the first one I’m assuming the publisher holds full US rights but chooses NOT to exercise their right to sell in Hawaii and Alaska (as well as a few other countries), and holds no rights for ROW. So three distinct statements are needed:
Okay, this example is hardly a typical rights statement, but in any case, you can see that the new tags in 3.0 allow for a complicated statement with high clarity and not many parts.
Note the corresponding “Exclude” and “Include” tags. You can’t just leave two states out of your rights statements—or if you did they would be grouped in the ROWSalesRightsType as part of it’s No Rights area—normally if you exclude something you must also include it under another rights type. The reason you’d use “excluded” in a territory statement would be, like here, to avoid a silly, hard-to-read, and long listing of many values (more on that below).
Finally, note the ROWSalesRightsType that simplifies the presentation of ROW statements in Sales Rights.
Example 2:
Readers of the first version of this blog post may recall I had this part different. I presented the metadata in a less than optimal way by imitating ONIX 2.1 conventions and used the ROWSalesRightsType to create a positive statement of where exclusive rights were held. The problem with doing it that is it’s hard to program for.
It’s always best to use a clear positive statement defining an area and following a model the same as you’d typically say it: the publisher holds exclusive world rights except in the United Kingdom. One of the improvements in ONIX 3.0 is that you can do this more easily.
In 2.1, that’s pretty straightforward and it’s not ambiguous. The only thing to note here is you’d use the ONIX 2.1 only territory code “ROW” instead of “WORLD” because in ONIX 2.1 “ROW” invites end users to look for a second statement—“Rest Of World” means less than the world. In 2.1 use the WORLD code for a single Sales Rights Composite statement that defines the WORLD. If there’s more than one statement, use ROW to show that.
In ONIX 3.0 you don’t use the territory code ROW, It doesn’t belong. Replace by ROWSalesRightsType. The difference is that in 2.1 ROW can be used as a positive statement, replacing WORLD, because you can’t mimic the normal shorthand of excluding an area from a larger one, so ROW does double duty in 2.1.
In ONIX 3.0 create your positive statement of where you can sell the book and then, clean up, dealing with the rest using a ROWSalesRights Type.
See the elegance of the positive statement; It appears pretty much the way we say it: “it has World rights except for the United Kindom”. What’s going on in the rest of the world? The publisher does not hold any rights there. Unlike Example 1, there’s no need to include the “excluded” GB in a second statement because the “excluded” area is covered by the ROWSalesRightsType. It wouldn’t have been wrong to provide a second Sales Rights composite for “06” and explicitly name GB in it as a country code – but should the rights change, say you sell rights for Australia, you’d only have to fix the Countries Exlcuded list if you used ROWSalesRightType. It’s simpler this way.
Believe it or not, “good” ONIX is the simplest and clearest choice—if looks wonky or seems clumsy there’s probably a better way.
Problems for conversion and data reality
The last example above for “the world excluding the United Kingdom” is dead simple and completely unambiguous, but it’s NOT a one-to- one conversion between 2.1 to 3.0. ROW appears in the 2.1 statement but it’s not used in the same way in the 3.0 statement where it has been flipped and covers only the exclusion. So, there’s a good question to ask your conversion provider: what would it do with this simple case? If you can’t use ROW in 3.0 statements, then what happens to them? You may need to clarify the data. The data I see in BiblioShare suggests to me that it’s not a question many need to ask, likely because there is a much more common way to present the data in 2.1 or 3.0:
What are the problems here?
- First off, there’s the the use of “03,” which is the Not for Sale (unspecified) code. Why not use one of the more accurate codes, like “06”? (See further note below–the ambiguous choice may be intentional.)
- Trivia: There are 252 codes in the current ONIX country code list (List 91). Since three of them are deprecated, “the world” in terms of the country code list can be represented by 249 unique codes. So the 248 codes here are probably the equivalent of saying ROW. That whole mess could be replaced with <x456>03</x456>.
We want retailers to use this information and pay attention to it. A ROW statement would be simple, durable, and clear. This list, meanwhile, is complex and potentially dated. What would it mean if there are 250 active countries in List 91 and this accounts for 249 of them? What do we want a retailer to do with that missing country? What do they do if a deprecated country appears on this list? They would have a responsibility (in theory if not in practice) to track it. Doing it this way invites poor data practices further down the line as discussed in the “What needs to change?” section above.
Anyway, it’s all a moot point: I checked the ISBN this references and got hits on both Amazon.com (US) and Amazon.uk, as well as other websites outside Canada. The information is actually wrong: the ISBN is for sale in some of the countries listed in the “03” Not For Sale statement. I expect the sender either doesn’t know or is manipulating the data to match the Product Supply statement for “Canada.” The sender is ensuring that the data in BiblioShare has no meaning outside of Canada, which is a shame because our data sometimes goes beyond our borders. It’s not impossible for Kobo, our local international marketeer, to look at our data, or for us to use BiblioShare data while discussing metadata with Bowker or BISG (and others). So this statement could cause confusion in other supply chains.
So let’s leave the blog now and head down the road to get a tat for our forearms: “Doing it right is simpler than doing it wrong.”
Resources
- ONIX for Books: How to specify markets and suppliers in ONIX 3.0
- Graham Bell’s webinar on transitioning from ONIX 2.1 to 3.0
- Best Practices for Product Metadata—the new version published in June 2015 is fully updated to support ONIX 3.0
- The full ONIX Manual and EDItEUR’s International Best Practices—go here to find the ONIX Manual; these are documents you should be updating regularly
