This is the third part of a series. The first part can be found at https://booknetcanada.atlassian.net/wiki/spaces/UserDocs/pages/1259733139/How+do+you+best+represent+the+names+of+your+publisher+and+imprint+in+your+metadata. The second part can be found at https://booknetcanada.atlassian.net/wiki/spaces/UserDocs/pages/1259962551/Imprint+and+publisher+name+some+case+studies.
...
A Canadian distributor did most of that when they took on an account representing almost 30,000 ISBNs with hundreds of individual publishers. They provided accurate Publisher and Imprint Names (avoiding the "distributor choices" complication referenced in part two of this series) and backed it up with a proprietary code in the Imprint composite, providing a unifying code grouping their source account. Retailers who care about these books know that this account can continue to group these books. This is an incredibly useful backend value. Success!!
...
BookNet may not have eyes looking into your soul to know for sure (only Facebook and Google have those), but BiblioShare data allows us to know how many data senders provide proprietary codes without a description. The following counts are out of 3 million ONIX 2.1 records and show that use of the imprint proprietary code use is very high (two-thirds of all those records – after all, it's a standard Amazon request) and the publisher proprietary code use is also high (approaching half of all records – after all, it's an alternate Amazon request), but only a couple of distributors use a proprietary code within Supplier Identifier. We've broken out the percentages for each to show if there was a single composite per record, and the percentage where the composite is supplied without a description.
| Composites with proprietary code | Total count, January 2019 (out of 3 million ONIX 2.1 records) | % single composite | % missing description |
|---|---|---|---|
| Imprint | 2,207,625 | 100% | 61% |
| Publisher | 1,358,548 | 96% | 63% |
| Supplier Identifier | 10,713 | 100% | 0% |
Over 60% without a description! (We'll get back to 4% multiple publisher composites in a minute.) So while it's impossible to know an end user's programming choices, this implies that no one's asking data senders to supply a description because it would be trivial to supply it. It also implies that senders aren't telling anyone why they supply this value. That's okay because the standard Amazon request is well known and it's for a code to identify imprint (or publisher) name, so it's arguably not needed.
...
And let me put it this way: If you wanted to use proprietary codes to carry new information, then you'd need to expect to use the description field. And you need to believe that recipients are prepared. Part two of this series looked at a number of use cases where there's background detail that might be useful to know about Publisher or Imprint Names. Further, if publishers start using ISNI for their own names, you should expect to see multiple identifier composites. The 60% of entries that supply proprietary data without full support says very loudly that no one is prepared.
...
The circle of life
You can see the pattern: Part one of this series started from need and use causing the re-purposing of a commonly supplied value. Your database only supports one slot, so if someone wants an alternate you stick the data there even if it doesn't represent the same thing. And at the other end of the supply chain, recipients of your metadata base their programming on the data as it was, hoping it'll never change. Part two was a list of reasonable complexity — some of which might need to be communicated, some not.
...