At some point, somebody in your company is actually going to have to look at the ONIX 3.0. Yes, I know that we all have to talk about it—endlessly—before we implement it, but how can you plan for ONIX 3.0 when you don’t even know what’s in it? Like most things in standards, cracking the binding on the manual is the hardest step.
What? You haven’t downloaded the manual yet? OK—opening the file is the second hardest step. First, figure out whether you’d prefer a PDF or HTML 5 version of the manual: links to both versions are available here. You should use the version that makes you happy, but personally, I find the HTML 5 edition easier to use.
Got the manual? Good. Now take a look at the table of contents, and you’ll see P. numbers, not the familiar PR numbers from ONIX 2.1. And you’ll see that the P. numbers are divided under 6 headings called “blocks.” No, no: It’s not all too much. Your head is not going to explode! Just settle down in your big comfy chair and let Biblio the metagnome tell you a quick story about using code lists for digital products. Go ahead and follow along in the manual and code lists if you’d like, but better check your pockets before we start—Biblio has some unsavory habits, and light fingers to match his hairy toes.
The digital metadata meat in the manual is mostly under section P.3. So click the link, or scroll down to that section. You’ll see a big difference here between ONIX 2.1 and 3.0: A digital product is just another product in ONIX 3.0, and its values are just as important as “physical product” values. So the basic “product” information section (section P.3) is where digital products are described.
P.3.2 Product form using List 150: Codes starting with E_ and L_ values for the difference between a digital download and a digital product license. This list, like several others, is unique to ONIX 3.0.
P3.3 Product form detail – List 175: Expanded E_ values for fixed, reflowed, ratios and other genuinely useful descriptions (as well as some of the old crap I guess they felt they couldn’t just drop).
P.3.4-.6 Product form feature – List 79: Very important topics related to education and accessibility which you might want to review. List 79 also supports information on operating systems and format version information if needed. Also see Code 09 for the subsidiary code list for digital accessibility detail (List 196).
P.3.10 Primary content type code – List 81: Be clear what’s in the digital file. If it’s mostly text, you can let the world know that here.
P.3.11 Product content type code – List 81 (again): Provide supplementary content to P.3.10.
P.3.16 Digital product technical protection – List 144 – defines the DRM on the product.
Constraints on the product are carried in:
P.3.17-.20 Usage constraints: (a repeatable section)
P.3.17 Usage type (digital products) – List 145: basic definition of the constraint.
P.3.18 Usage status (digital products) – List 146: defines the unit of use for the constraint.
P.3.19-20 Usage limit composite (digital products): Here’s where you pair a “quantity” with a code from List 147 that defines the quantity. This is an optional and repeatable section.
Biblio wants to know if you can see how you might use all these to describe a single-user versus multi-user library book. It’s not even a trick question!
List 145 defines that it allows “lending” between devices or Library Lending.
List 146 says whether lending is permitted or not—or if there is a limit on the permission.
And the Usage Limit composite defines it.
You tell Biblio that you’re confused about why these constraints and stuff are even appearing at this primary level. And you want to know “How in name of all that’s simple and reasonable do we even know that it’s a book for sale to libraries?”
Biblio sighs heavily—this wasn’t part of his storytelling contract. “Well, remember that Best Practices for Digital Identifiers document? It would tell you that you need to use a distinct ISBN if you define usage constraints. A library would need to be able to order, using an ISBN, the digital product with the right constraints. So once you start applying constraints you’re getting pretty specific about who’s buying the product. List 71—Sales Restriction type code—would allow you to limit the ISBN to libraries. That’s market information, not product information.”
“Dear God,” you say, “Why can’t I just use Price Qualifier to say it’s for sale to libraries with its price?”
Biblio has to scratch himself here, and offers you his finger to smell before answering. “Well, you can… but you can’t define constraints limited to libraries in a multi-price record where the constraints don’t apply to all. You can define as many prices as you want for various groups that can buy a product with these constraints, but you can NOT sell what amounts to two distinct products with the same ISBN. Remember,” says Biblio, licking his finger, “an ISBN is an order number for the benefit of the client. If they can’t order a product using it and get what they ordered, what’s the point?”
Following the code lists isn’t hard. “You start at the table of contents…” and think about Maria in The Sound of Music to keep going. Here’s a trick: If you get the full code list as a single document you can search it for terms.
