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.
On occasion, EDItEUR comes across ONIX product records which inadvertently misuse various Notification type codes in the <NotificationType> element. This is important to get right, because it can affect the way a metadata recipient processes incoming data. By far the most common Notification types are:
- Code 01 (Early notification) is for a product record sent more than about six months prior to planned publication.
- Code 02 (Advance notification confirmed — perhaps not the best heading) is for a product record sent less than about six months prior to planned publication, but even advance copies of the book itself are not yet to hand. When those advance copies do arrive at the data sender, then the metadata details can be checked and the Notification type updated to…
- Code 03 (Notification confirmed upon publication). This indicates that the product has switched from forthcoming to active — it has been, or is on the brink of being, published. As a consequence, there should always be an updated Product record sent in the week of publication, using code 03 and an “active” publishing status. (A scrupulous publisher might separate these two events, switching to Notification type code 03 a little earlier than switching to Publishing status 04.)
There are some common questions that are asked about these codes:
- Can a product have more than one Product record update with Notification type code 01? Yes, it’s used for all Product records that are more than six months from publication. Code 01 does not mean it’s the first time a particular Product record has been sent.
- If I send out a Product record for the first time, but it is only four months prior to publication, do I use code 01 or 02? You should use code 02.
- If I’ve sent out a Product record using code 01, then a couple of updates using code 02, then publication is postponed by six months, or postponed indefinitely, should I continue to send out updates using code 02, or switch back to code 01? Strictly, you should switch back to code 01.
- What about post-publication updates? Well, certain fields clearly should not change post-publication — the title, the publication date itself… but it’s perfectly normal to have post-publication updates to the metadata, to add reviews, change the price or the rights, to update keywords or whatever. These should all use code 03.
- If I’m establishing a brand new data feed with a new reseller, what Notification type do I use? Well, stick to the guidance above. If you’re sending an already published product, use 03. You don’t need to send an 01 or 02 first. That’s the “normal” way a new product enters the ongoing feed, being announced with an 01 maybe six to eight months before publication, then subsequently being updated with 02 and 03 updates — but a brand new ONIX feed doesn’t have to follow that path.
All of the above means that Notification type is — at least for codes 01, 02, and 03 — merely a proxy for the publication date. It’s a simple and up-front way of suggesting how reliable the data is likely to be — the longer before publication it is, the more “provisional” the data is. But this is not true for the various other Notification types.
Code 04 (Partial update), aka a Block update. Block updates are perhaps the best ‘unused’ feature of ONIX, and can be considerably more efficient than full Product records. A Block 6 Block update makes a great Price and Availability update message. For data recipients who have not implemented Block updates, this Notification type code needs to be treated as an error and the data sender informed.
- Are there equivalents of codes 01, 02, and 03 for Block updates? No — it’s just 04. Of course, a sender has to start with a normal “full product record,” so will use codes 01, 02, or maybe 03 when they first send ONIX product details. Subsequent updates can be full or partial.
- Can you mix ordinary “full record” updates (01, 02, 03) in the same ONIX message as 04 Block updates? Yes.
Code 05 (Delete) is a request for a ‘recall’ of a Product record sent entirely in error. This must NOT be used for products that go out of print, or out of stock, or are recalled for any reason — those are changes of Publishing status and Product availability. A code 05 Deletion is only for that moment when you’ve sent out an initial product record, then immediately realize the product should have been kept secret for a couple more weeks. Note that it’s a request to delete all information about a product, not just to ignore the previous update. Code 05 should be very, very rare, and it seldom has any effect at all if more than a few hours have elapsed — once data is sent out, and processed by the recipient, it’s unlikely recipients will be able to remove it.
- What if I send a code 05 Deletion two or three days after I make a mistake? “You can’t put toothpaste back in the tube.” It’s unlikely that data recipients will be able to delete your data. Your best recourse is to send a full update that changes the title, indefinitely postpones the pub date, sets the price to TBA with <UnpricedItemType> code 02, and so on. Then remember to change it all back again when the metadata is okay to release.
There are a couple of other special case Notification types, and the one I’m going to highlight is code 89. This is for a test record. If a recipient has a test environment, then this record can be ingested — but if a recipient has no suitable test environment, it should probably be ignored.
- Can I mix test Product records and real Product records in the same ONIX message? Technically yes, but I personally would be reluctant to do so unless assured by the test recipient that their system can deal with this scenario.
EDItEUR hopes this clears up any misunderstandings of <NotificationType>, particularly around the meaning of codes 01 and 05.
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.
