Serials Coverage: Z39.71 vs. ONIX Coverage

Serials Coverage

I have an issue I’d like to put on the radar of ILS developers generally, especially open source ILS developers, especially apropos since the Evergreen Serials module is in the process of being developed.

When trying to integrate my Link Resolver with my ILS recently, I wanted to accomplish a task that seems like you’d often want to accomplish: When given a particular journal citation (say, issn, volume, and issue), identify if we have it in print, and identify the particular ILS record(s) that correspond to that serial holding in print.

In our environment, this turned out not to be possible to do in a reasonably confident way. Part of the problem is the Z39.71 standard, which is used to express serials coverage/holdings in a human readable format. While z39.71 holdings statements are theoretically intended to be consistent and maybe even machine-processable—anyone who has tried to machine process them will have discovered they aren’t really suitable for recovering the sort of information needed to perform my task, for example.

On top of that, in many actual ILS environments, catalogers end up entering z39.71 purely by hand. I don’t know if there is even a way to validate z39.71 holdings statements automatically (I suspect there is not, an obvious problem in itself), but I’d guess that in a typical environment around half of z39.71 statements in a corpus are probably not strictly legal z39.71. Whether through typo, cataloger misunderstanding of the standard, or simply lack of concern with following the standard I don’t know, probably a different mix in different institutions.

So it’s just not working. We need another way to format these things, that is actually machine actionable, where software can actually answer questions about holdings, as well as present holdings/coverage to users in reasonable ways (ideally including set arithmetic on several holdings statements, to be able intersect, union, difference, etc. in presenting to the user.)

Enter the ONIX For Serials Coverage Statement standard. Turns out a draft of this standard already exists, and is just perfecty suitable for what we need. It is intended to be sort of a ‘plug-in’ for coverage information in *both* the ONIX Serials Online Holdings (SOH) format and Serial Products and Subscriptions (SPS) format. But to my reading, it’s really quite suitable for use as an independent thing apart from any other ONIX format too, for instance as a component of an OPAC that otherwise uses MARC. It’s XML. According to the draft standard

It provides for enough detail to support the following basic functionalities:
• To allow a system to produce an eye-readable display that will give an end-user an understanding of what content is included.
• To allow a system to determine whether or not a particular issue or citation is included in the holdings represented by a coverage statement

And to my reading, it succeeds with a very sensible XML format.

It is only a draft right now. It does not appear to have been published at all. I happen to have a copy of the draft, which I’m happy to share with anyone interested directly, but I’m not certain I can really ‘publish’ it online.

I’d like to suggest that this at least get on the radar of the development team for Evergreen Serials module (or any other interested ILS developers). It would be great if an ILS actually stored it’s serials coverage information according to a standard like this, so we could actually write software to act upon this information, instead of just dislaying it as-written to the user.


4 thoughts on “Serials Coverage: Z39.71 vs. ONIX Coverage”

  1. It gets even more complex (or maybe muddier). There’s a new holdings data standard being created by ISO TC46 SC4 WG10. Here’s a link to the documents and the notice about a meeting.
    I was actually on this committee for a while but never could figure out what it was about and why this particular standard was needed. It is stated that the schema is “primarily designed to be included in responses to queries,” which seems to be what you want. Why not ONIX? Why not MARC holdings? (OK, maybe I know the answer to that one.)

  2. Well, I could tell you why what’s currently being done doesn’t work, I’ve tried to give the overview in this post. I’d have to look into MARC Holdings more than I have to explain exactly why it as a standard doesn’t work–but if that’s what we’re currently using, then the _way_ we’re using it _definitely_ doesn’t work.

    When I looked around for something that would, ONIX Coverage is what I came up with–and it looks like it will fit the bill quite nicely, it’s designed very well. And it’s not too complicated, shouldn’t be hard to implement at all. It seems very good to me. (I imagine the chair of the committee, Nathan Robertson, is in large part to thank). (It needs a validating schema, which it doesn’t look like it has, but it’s close).

    So if one standard is good, two are even better, right? Ha, no. So if ONIX Coverage works fine–and is pretty much done–I don’t see any reason why anyone’s got to spend some time on another standard. Of course, that argument would hold more weight if the ONIX people would actually approve and/or publish the draft ONIX Coverage standard.

    The interest thing about this sort of thing, is that if an ILS starts implementing _something_ that actually does the trick (which needs to effect serials workflow too, to some extent–hopefully in a beneficial way), code4lib types will immediately start writing code against it. You don’t need to weight for the heavy machinery of ‘vendor buy-in’ or whatever. And in fact two standards that both did the trick WOULD be better than the current situation, although not as good as one standard.

    So I still say ONIX Coverage. I’ll email you a copy, Karen.

  3. I’m grappling with this at the moment, but I can’t see any short-term alternative to MFHD in terms of something which our ILS is able to handle right now. We could afford to wait a few more months before taking the plunge if I could see ONIX in action somewhere. Our holdings lie more or less dead in our bib 850 fields; I have to move them out of there in short order so that they will link up with ERM. Any ideas that don’t involve hiring programmers?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s