In late March, EDItEUR — the organization that manages the ONIX for Books standard, among others — announced the rollout of ONIX 3.1:
ONIX release 3.0 has developed over the last decade through several minor revisions, 3.0.1 to 3.0.8. Each has added new but optional functionality to the ONIX message, and each has retained full backwards compatibility with earlier revisions — ONIX files matching the 3.0 release from 2010 remain fully valid under the latest 3.0.8 revision of the standard.
Now, in 2023, EDItEUR has published ONIX release 3.1. This is the first version since 2010 without full backwards compatibility. However, the degree of incompatibility is very small.
- Graham Bell, Executive Director, EDItEUR
Bell goes on to explain the key changes in this new version, and what data senders need to do.
Release 3.1 takes all the key features of 3.0.8 and adds new data elements to provide the most frequently-requested new functionality — but crucially, it drops support for a handful of ‘deprecated’ data elements and the outmoded <Gender> data element.
For most data senders, upgrading to Release 3.1 should be straightforward: any ONIX 3.0 message that does not use any of the deprecated elements or <Gender> is already 3.1-ready. It needs only a trivial change to make it valid ONIX 3.1. For data recipients, the difficulty of accepting 3.1 (probably alongside 3.0 for some time) will depend on the data ingestion architecture, but should not be greater than any other past revision of 3.0 (e.g., upgrading from 3.0.2 to 3.0.3).
Use of these dropped data elements has been heavily discouraged for up to a decade, and of the seven elements removed, evidence from large-scale data recipients shows that only two show any significant contemporary usage. Any metadata carried in these deprecated elements has a preferred location elsewhere in the message, and those two elements that are in some limited use are straightforward to replace — the deprecated <DateFormat> must be replaced by the dateformat attribute, and the deprecated <AudienceCode> tag with the <Audience> composite).
Dropping these deprecated data elements from the ONIX 3.1 release removes unnecessary additional complexity for data recipients, ensures there is just one clear way to express any particular metadata, and by simplifying the XML schema, should also slightly improve the performance of message validation and processing.
Newly deprecated element: <Gender>
Bell’s use of outmoded as an adjective to describe the <Gender> data element couldn’t be more appropriate. While many data consumers are interested in discovering books about a certain topic by contributors of specific genders, ONIX was not the appropriate container for such sensitive information about someone’s identity. If you recall, ONIX List 229 supported the <Gender> data element, used ISO 5218 (ISO 5218 offers “codes for the representation of human sexes” and is similarly outmoded), and offered only three codes:
u; unknown or unspecified (provides positive indication that the gender is not known or is not specified by the sender for any reason)
f; female
m; male
Bell puts it succinctly:
The codelist previously used in ONIX (ISO 5218 – because that’s the list used by ISNI) is outmoded, and in no way suitable for the more contemporary, inclusive and nuanced conception of gender that authors, publishers, librarians and retailers want to use — hence [EDItEUR’s] recommendation that this be captured in the author biography rather than in a single codelist value. And finally, reports from large-scale ONIX recipients showed little use of the <Gender> field — so immediate removal rather than long-term deprecation was deemed the best option.
Without offering granular meaning nor an opportunity for a free-text method for contributors to offer self-identification, the element was not as useful as popular hopes would suggest, and can rightly be replaced by a robust and precise biography, provided by the contributor. Combined with a lack of data supplier support and discontinuation of the intended use of the element when originally conceived (<Gender> was added to ONIX primarily for use in ISNI registration workflows, and ISNI has now confirmed that it no longer uses the <Gender> field for deduplication purposes), ONIX 3.1 rightly deprecates the <Gender> element.
Further reading
Read the full release announcement from EDItEUR here.
See the full list of changes here.
For full background, an overview of the message structure, and a summary of key differences between Release 2.1 and Release 3.0/3.1, read the Introduction to ONIX for Books 3.1 here.
If you are interested in keeping up-to-date with bibliographic standards, visit BookNet’s User Documentation here.
What did BookNet read in 2024? We’re sharing some tidbits of data about our team’s reading habits this year.