Updating from ONIX 3.0 to 3.1?

The following post was featured in the international ONIX implementation group — a mailing list that you should follow for ONIX announcements and discussion. Want to stay on top of ONIX implementation issues in a global discussion led by EDItEUR? Join the group here.

It is now three years since the advent of ONIX 3.1, and the Specification is freely available here. Many key data senders and recipients have updated their systems. But a question posed during a recent ONIX training session asked whether the update from 3.0 to 3.1 was as onerous as the move from 2.1 to 3.0. This was answered during the training session, of course, but also posted to the onix@groups.io mailing list:

Well, no. In summary, updating from 3.0 to 3.1 involves only a handful of steps:

There are a small number of deprecated data elements in ONIX 3.0 that have been removed from ONIX 3.1. Check whether you are using any of them. Only two or three (<AudienceCode> and <DateFormat> and possibly <Conference>) were ever in any widespread use, and they are easy to replace with modern equivalents — use the <Audience> composite and the dateformat attribute attached to the <Date> tag instead, and all <Conference>-related tags have equivalents named <Event…> instead.

The <Gender> tag in 3.0 was not deprecated, but nonetheless has been removed from 3.1. It was never widely used — in fact it was only added to ONIX to ease ISNI registration, and ISNI no longer uses that tag either.

If you use <SalesRestriction>, ensure it is inside the <SalesRights> composite, not outside (the old position outside was deprecated in 3.0).

If you use <UnnamedPersons>, ensure it precedes any <AlternativeName> or other contributor date, affiliation, biography or website elements. (The old position that followed contributor date, affiliation, biography, etc. was deprecated in 3.0.)

Most commercial title management systems already avoid the deprecated elements, the gender tag and the two deprecated positions, even if they are limited to ONIX 3.0. If you’re using off-the-shelf software or a cloud service, your vendor has most likely taken care of these things. If you use a customised system or in-house development, the above steps are not at all difficult — and since the deprecations have been in place for a decade or more, there’s a decent chance they have already been fixed. So...

Once you have dealt with the deprecations (and with the Gender element), you will still have valid ONIX 3.0, and you can continue to supply it as normal to your supply chain partners. But you’re also ready to take the final step. Talk to your supply chain partners to ensure they can accept 3.1, then just change the attributes in the <ONIXMessage> tag at the beginning of the file:

<ONIXMessage release="3.1" xmlns="http://ns.editeur.org/onix/3.1/reference">

(NB if you use short tags, this might say ONIXmessage with a lower case m, and /short at the end.)

That’s it. Deal with the deprecations (and the gender tag), then update the release and xmlns attributes. Of course, once you’re using ONIX 3.1, there are new additions to the standard that you can begin to take advantage of, but none of these additions are mandatory and you can at least begin with 3.1 that merely replicates what you previously had in 3.0.

The latest revision of 3.1 is ONIX 3.1.3, and over and above the functionality available in 3.0, it includes new organisation identifiers for professional affiliations, codes used to indicate the frequency of publishing new books in a collection, the ability to express license limitations on the use of collateral material (e.g., long descriptions, cover images) for training AIs, prioritisation of repeated collateral items such as reviews or internal images, prize identifiers, physical addresses required for compliance with EU safety regulations, a rationalisation of the source of collateral text such as reviews, options for both translated and transliterated text, and other additions.

Other key discussions on the ONIX mailing list in the last three months or so have covered questions about the best treatment of Spanish editions within the US metadata supply chain, how to express ‘World English language rights’ in ONIX, and the removal of the last remaining ONIX 2.1 documentation from the EDItEUR website.

If you’re not on the ONIX mailing list, send a blank e-mail to onix+subscribe@groups.io. It’s a great place for any ONIX stakeholder to stay up to date, and to pose questions and receive answers — often very quickly — from EDItEUR or the wider ONIX community.

Graham Bell is Executive Director of EDItEUR, responsible for the overall development of EDItEUR’s standards and the management services it provides on behalf of other standards agencies (including the International ISNI agency and the International DOI Foundation).

He joined EDItEUR as its Chief Data Architect in 2010, focused on the continuing development and application of ONIX for Books, and on other EDItEUR standards for both the book and serials sectors.