- What is ONIX?
- What is ONIX for Books? Where can I buy it?
- Who is responsible for ONIX for Books international standards?
- Are ONIX for Books standards only used for ‘books’?
- What are the benefits of adopting ONIX for Books standards?
- What is ONIX for Books 3.0?
- Why did EDItEUR decided that the time is right for a new release?
- What is the status of previous releases of ONIX for Books?
- When do you anticipate that ONIX for Books 3.0 will be widely implemented?
- What are the advantages of ONIX for Books 3.0?
- What are the significant differences between Release 2.1 and Release 3.0?
- What is the ‘schema’?
- What are the ‘DTD’, ‘XSD’ and ‘RELAX NG’ schemas?
- How should I validate an ONIX for Books message?
- As a publisher, how can I implement ONIX for Books?
- Will ONIX for Books affect the way I manage my product information?
- Where can I get more information on implementing ONIX for Books?
- Do I need to include all elements listed in ONIX for Books?
- Does the order of elements matter in ONIX for Books?
- What are ‘reference names’ and ‘short tags’?
- What should I do if I have no information to go in an ONIX data element?
- Can ONIX cope with books and metadata in any language?
- Is ONIX training available?
ONIX stands for ONline Information eXchange; it is an XML-based family of international standards intended to support computer-to-computer communication between parties involved in creating, distributing, licensing or otherwise making available intellectual property in published form, whether physical or digital.
ONIX for Books was the first, and is the most widely-adopted, member of EDItEUR’s ONIX family of standards. The first release of ONIX for Books was published in 2000. The most recent release (Release 3.0) was published in April 2009. ONIX for Books is now firmly established around the world as the book trade standard for the communication of ‘rich product metadata’ – the type of metadata that is needed to support the sale of books in the supply chain, not least for online retailing.
It’s important to understand that ONIX is simply a standard method for communication. It is not in itself a database, a software application, or a product you can purchase (although many software applications and products may well implement the standard). And the standard is available without charge: EDItEUR makes all ONIX documentation available for download on it’s website, and there are no charges if you make use of the standard.
Note however, although EDItEUR is committed to ensure that ONIX is free to use, it is not ‘free’ in the sense that the standard itself and all associated documentation remains © EDItEUR.
ONIX for Books was originally developed jointly by the Association of American Publishers and EDItEUR, and subsequently by EDItEUR in collaboration with the Book Industry Study Group (BISG) in the US, and Book Industry Communication (BIC) in the UK.
It is now managed by an International Steering Committee with representatives of user groups in 15 or more countries including Australia, Belgium, China, Canada, Finland, France, Germany, Italy, Japan, the Netherlands, Norway, Russia, Spain, Sweden and the Republic of Korea, as well as US and UK representatives from BISG and BIC. The Steering Committee meets twice a year, at the London and Frankfurt Book Fairs, and is responsible for ensuring the standard develops in line with the needs of ONIX users.
Although the format is invariably referred to as ONIX for Books, it has always covered other media and other products produced by book publishers and distributed through the book supply chain. In particular, Release 3.0 has improved the capabilities of ONIX with respect to the management of information about e-books and other digital products.
For publishers, experience has shown that ONIX for Books brings two important business benefits. As a communications format, it makes it possible to deliver rich product information into the supply chain in a standard form, to wholesalers and distributors, to larger retailers, to data aggregators, and to affiliate companies. And by providing a template for the content and structure of a product record, ONIX has helped to stimulate the introduction of better internal information systems, capable of bringing together all the ‘metadata’ needed for the description and promotion of new and backlist titles. The same core data can also be used to produce advance information sheets, catalogues and other promotional material.
For ‘downstream’ supply chain partners, ONIX for Books means that they can speed up the loading of up-to-date product information into customer-facing systems, with less need for manual intervention and much lower risk of error. It reduces the need to deal with multiple proprietary data formats, and hence reduces support costs. And by enabling third parties such as trade associations of data aggregators to develop metrics for data quality and timeliness, it encourages the overall improvement of the data available throughout the supply chain.
It is a major new release of the ONIX for Books product information format for book publishers and other organizations in the book supply chain. It is the first major release since 2001 (when ONIX for Books 2.0 was released), and is the first release in which digital products have been treated as a ‘core’ elements in ONIX coverage. It is the first release for eight years which is not backwards-compatible with previous releases.
The International Steering Committee took the decision that the time had come to move to a new release for two main reasons. The first was the need to improve the handling of digital products; the second was the recognition that the price of maintaining backwards-compatibility was the increasing number of ‘deprecated’ elements which have had to be retained – and supported by ONIX receivers – even though they are no longer recommended for use. ONIX for Books 3.0 deletes all ‘deprecated’ elements, as well as others that are now redundant as a result of other changes in the new release. It also enables digital products to be handled more comprehensively and more consistently than before. At the same time, the opportunity has been taken to introduce important improvements in other areas, although there are many data element groups where little or no change has been considered necessary.
- With the release of ONIX 3.0, all ONIX for Books 1.n releases have been formally withdrawn, and EDItEUR will no longer support them.
- ONIX for Books 2.0 is also no longer actively supported, though there are still a few users, documentation is still available, and many updates to the ONIX Codelists apply equally to 2.0 and 2.1.
- ONIX 2.1 will continue to be fully supported until the end of 2014. This includes essential updates to code lists used in 2.n. The International Steering Committee agreed that the timetable for planned reduction in the level of support should be announced three years in advance, to ensure that organizations can plan (and budget for) their migration to ONIX 3.0 effectively. It is expected that by that time, the implementation of ONIX 3.0 will have reached a point where it is appropriate to cease further support.
- All development is now focused on Release 3.0 and ONIX for Books users are encouraged to adopt this version as early as is practicable. The latest minor update of ONIX 3.0 is 3.0.1, which was released in January 2012.
Implementation is at different stages in different markets. In the US and UK, ONIX 3.0 implementation is at an early stage, but some major metadata aggregators can already receive ONIX 3.0, and others plan implementations in 2013 and 2014. The major suppliers of publishers’ systems can already supply 3.0-capable systems, or are close to doing so.
In other markets – particularly those where 2.1 was less widely implemented – ONIX 3.0 implementation is much more advanced.
Some of the advantages of Release 3.0 over previous ONIX for Books releases are:
- Redundant elements have been eliminated, and the design of the standard has been updated to reflect several years of experience.
- There is a global Implementation and Best Practice Guide, which aims to ensure that ONIX 3.0 data is highly interoperable on a global basis (rather than being bound to a particular set of national best practices).
- Digital products can be more fully and consistently described, and the groundwork has been laid for further development in this area, as new product formats and content packages evolve.
- The handling of series, sets and multiple-item products – an acknowledged problem in earlier releases – has been greatly improved. As part of this improvement, there is a new extended title composite, which enables title detail to be more accurately expressed.
- Publishers and others are able to specify a much greater variety of ‘marketing collateral’ – typically web resources – to support the promotion and sale of physical and digital products.
- For ONIX users working in complex international markets, for example the international English-language market, supply-related elements in ONIX 3.0 have been regrouped to allow the status of a product in different markets to be more clearly and accurately described.
- The Specification allows the provision of multi-lingual metadata, for those supply chains where more than one language is in use.
- With the introduction of the ISTC (International Standard Text Code), products can be related to a parent ‘work’, to identify groups of different manifestations of the same text, or of texts derived from a common source.
- ONIX 3.0 Product records are ‘blocked’ in a new way which will permit updates to be sent without complete record replacement, and without the need for a separate ‘Supply Update’ message type (which was necessary for this purpose in ONIX 2.1). This message structure potentially greatly reduces the parsing and ingestion effort required to keep records up to date throughout the lifecycle of the product.
- The ONIX 3.0 schema definition is available in the ISO RELAX NG schema language, as well as in DTD and W3C XSD schema languages.
As a quick guide to those considering upgrading from Release 2.1 to 3.0, we have prepared a summary table which you will find in the Appendix to the Introduction to ONIX for Books 3.0.
The schema is the formal definition of the structure, content and, to some extent the semantics (or meaning) of data in an XML file, ie in this case an ONIX XML message.
However, there are some 'business rules' within the documentation for the ONIX specification that cannot be defined and enforced within the schema, and these too are part of the definition of ONIX for Books.
These are three widely-recognised ‘languages’ in which XML schemas can be expressed. EDItEUR provides DTDs and XSD schemas for all current ONIX for Books releases, and for Release 3.0 there is also a RELAX NG schema. Developers can use a variety of widely-available XML tools to validate an ONIX message against the DTD, XSD or RNG schema. With the DTD, only the structure is validated. With the XSD or RNG schema, both the structure and the code values are validated. An ONIX message which fails at either of these levels is invalid, and it is reasonable to expect it to be rejected by a receiver.
In the first place, whether you are sending or receiving ONIX messages, we strongly recommend that you should use a suitable XML validation tool to check the message structure and, preferably, the code values against one of the schema definitions. Over and above this, there are also ONIX business rules which (for example) specify conditional requirements. These cannot at present be validated by off-the-shelf XML tools. Some national groups and independent developers offer validation tools which check some of these added criteria. And several national groups operate accreditation schemes which involve a more rigorous test process, typically taking into account not just the basic validity of ONIX messages but also their timeliness and the level of content.
The options for publishers who want to start sending ONIX for Books are of three kinds:
- develop or commission bespoke software for managing your product metadata, and build in support for ONIX for Books;
- acquire a third-party system for product data management which supports ONIX for Books; or
- contract to use a web-based service which supports online data entry and delivery of ONIX for Books output to designated receivers.
The availability and practicality of each of these options will vary from country to country: some ONIX national groups may be able to provide contacts with system or service suppliers, and a selection are also listed on the ONIX Users and Services Directory. Wherever possible, EDItEUR provides links to national groups and to system vendors from the ONIX for Books pages on this website.
ONIX for Books is a format specifically developed to support the communication of information from one computer system to another. It is not designed as an internal database format. However, it is obvious that communication can only work if the systems at each end are substantially ‘ONIX compliant’ – for example, supporting data element structures and data encoding which are no less exact or granular than those used in ONIX. It is important to verify at the earliest possible stage that any product data management system you plan to use is ‘ONIX compliant’ in this sense.
Much of the content of a product record is free text which cannot be automatically validated. It is all too easy to deliver something which is correct in format terms but wrong in data content. For example, title fields in some book trade systems are traditionally used to carry added data, such as an edition number, which differentiates one product from another. But in ONIX for Books, title elements should carry only the component parts of the title, and there are separate elements for edition numbers and types. So not only your internal database structures, but also the disciplines followed by your data entry staff, need to be ‘ONIX compliant’.
Implementation questions are routinely discussed on the ONIX_Implement listserv, and notices of ONIX for Books developments are sent out to the listserv as well as to national groups. If you have not signed up to the list, you can do so here.
ONIX for Books aims to cover the widest possible range of needs, and it therefore includes many elements which are specialised to particular forms of publishing or particular markets. Nobody uses all the elements of the format, and only a small number are mandatory. EDItEUR provides a comprehensive Implementation and Best Practice Guide that offers advice on the most commonly useful ONIX 3.0 data elements. In many countries where ONIX for Books has been adopted, national groups publish their own guidelines for implementation and ‘good practice’. If you are buying a third-party system or service, you need to check that it complies with the guidelines that are in use in your particular market(s). Some receivers may choose not to use certain elements, or may ask for one option rather than another. However, no receiver should reject a valid message because it includes optional content which they have chosen not to use.
Yes. Elements in an ONIX for Books message must be delivered in the sequence defined by the schema. A message in which elements occur out of sequence will not validate.
On the other hand, where an element is repeated several times (say because there are several contributors, or several subject codes) the order of the repeats is generally not meaningful.
Each element in ONIX for Books has a ‘plain language’ reference name (for example, <NotificationType>) and a short tag (for example, <a002>). The schema definitions allow either reference names or short tags to be used to label the elements in an ONIX XML message. They cannot, however, be mixed in the same message. Users can make the choice between readability and conciseness. For ONIX 2.1 and for ONIX 3.0, there are tagname converters which translate reference names to short tags, and vice versa.
In the very earliest ONIX for Books releases, the initial letters of the short tags indicated an attempted logical grouping of elements. As the format developed, this grouping quickly became impractical, so that there is now no significance to be drawn from the initial letters. (The numeric part of the tag has always been unique by itself.) In ONIX 3.0, all new elements have been assigned short tags of the form <xnnn>, so that they can be immediately recognised as new.
If for a particular product there is no information available for an optional data element, the data element should be omitted. If the element is mandatory, however, you must not send an ONIX record without providing valid data for the element. In neither case is it permissible to send an ‘empty element’.
Note that if the element for which there is no information available is a mandatory part of a larger composite element within the message, the whole composite element must be omitted.
[In XML it is possible to deliver an empty element in either of two forms: <Tag></Tag> or <Tag/>. Neither of these two forms should ever occur in an ONIX for Books message, except in a few instances where an element (eg the <MainSubject/> flag in Group P.12 in Release 3.0) is specifically defined as always empty, in which case we strongly recommend that the second form <Tag/> should be used. If there is no data for an element that is not defined as empty, the element should be omitted completely. Most ‘illegal’ empty elements are detected by validation against the XSD or RNG schemas, but not by validation against the DTD. Consequently there is a risk with the DTD that a message could pass validation even though it includes mandatory elements for which there is no data. This is another reason for using the XSD or RNG schema for validation wherever possible.]
Yes. ONIX is not built around the needs of any one country, or any one supply chain. Although the reference tag names are in English, this is just a convenience, and the data carried within most data elements is language-independent. Whether a book is known as a hardback (English), or a hardcover (American English), or a gebundene ausgabe (German), the ONIX data is the same (<ProductForm>BB</ProductForm>). Where the data is text in a particular language – for example, a contributor’s biography – the text can be provided in one language or in several languages in parallel.
And to facilitate this text in multiple languages, ONIX data can use Unicode: whether your metadata is in Latin script (for English and most European languages), Cyrillic (for Russian), Hanzi or Kanji (for Chinese and Japanese) or Hangul (for Korean), Unicode covers what you need.
Some national user groups and other organizations provide implementation help, workshops and formal training. EDItEUR also runs in-house training for its members. If you are interested in receiving – or providing – formal training, please contact EDItEUR.