KeyNames: Supporting diversity with fully implemented ONIX

Recently, a major retailer brought forward a problem that they were having with the metadata coming in: East Asian names were being poorly presented.

It’s a matter of respect to present authors' names properly and any publisher or retailer that has identified diversity, equity, and inclusion as a corporate goal should ensure they can meet this very basic level of support.

Our advice: don’t think of it as a problem, it really isn’t, instead think of it as an easy win, a simple attainable metric that visibly shows your corporate ethos, and as a way to do the right thing while producing better metadata that in the long run will also help support higher sales.

While this is an important topic for the transition to ONIX 3.0, I’ve identified it as a problem with the full implementation of ONIX since you can support full contributor naming in both ONIX 2.1 and ONIX 3.0. It’s also something EDItEUR got right early on and is proud of: ONIX’s ability to support naming and its indexing from any culture — something that ONIX users have been able to do for more than 15 years, whether they know it (and do it) or not.

ONIX contributors, when fully implemented, are organized around "KeyNames" which are understood as the primary names and the one used for indexing. It's supported by other four primary parts, so the full set of naming options are:

• Names before key name

• Prefix to key name (von is the most familiar)

• KeyNames (the full index name as defined for the language — can be a phrase)

• Names after key name

• Suffix to key name (Jr or III are our typical need)

So, really it's the primary name — the name that gets indexed — and what comes before and after. Those prefixes and suffixes can be needed because there are things in other cultures that can come between name parts. Not shown is the support for titles the author might hold (and you Royalists might need for marketing) before and after the name as well as author-specific honourifics that follow the name (most often seen for medical credential acronyms). Basically, all publishers need to do is ask their author the correct way to present their name and put the parts in the right spot.

And there’s a way to handle it. Well, two ways because another thing EDItEUR has always supported is Alternate Names as a separate composite defined by its own code list. So the main product composite can support the author as their main display preference, and you can back it up with an author-approved alternative that can also be available for indexing and display. (Need a kludge solution to supporting Alternate Name? Use keywords. Just don’t expect to see it displayed — it’s very much a poor second choice.)

That’s it. It’s been there in ONIX metadata waiting for your company to implement it, so take the transition to ONIX 3.0 as an opportunity to do that work if you haven’t. It may be a good time to ask if there are any other basic metadata areas relevant to your business where the capacity of ONIX exceeds your database’s abilities.

How does BookNet Canada know this is an industry-wide problem?

• We know it because it’s a common question from IT departments who are mystified by ONIX’s lack of support of “Middle Names.” They’re looking to support standard North American naming of First and Last Name – with mail merge support by leaving the Christian name available on its own. That’s a bit of intentional old speak to emphasize that this is a cultural choice that EDItEUR quite rightly is not making any attempt to support. You might want it in your dataset for other purposes, but it’s not needed in book based metadata.

• We know it because most feeds that support KeyNames also support the PersonName entries and its logic depends on the expectation of First and Last Name entries.

• We know it because ONIX also allows senders to use PersonName or PersonNameInverted instead of supporting KeyNames, and around 10% of the ONIX 2.1 data incoming to BiblioShare still arrives using PersonNameInverted without KeyNames support. ONIX 3.0 continues to allow that because pragmatic EDItEUR understands that there’s a need that’s dictated by actual use.

• And finally, we know the problem exists at retailers. We know this because publishers continue to support PersonName entries, which by the way, should have been dropped a decade ago. Here is an example: A publisher had a weird data sourced error based on a fully set up contributor block in ONIX that included both of the PersonName entries and the appropriate KeyName group for the book's single author. The error was that another person's name was used for PersonNameInverted. I would optimistically think that every retailer or data user would pull their information from the KeyName group when it’s supplied and the mistake should have never come to light. But it did because many companies use and display PersonNameInverted in North America. 

In conclusion, it really is just simply courtesy to do this better, the benefits are endless, and if you think about it, it’s a small improvement to your metadata that can not only appropriately present contributors' names but also have a positive effect on your sales. Just be safe and do the right thing.