[OPEN-ILS-GENERAL] Serials Coverage: Problem/solution for the radar

[Jonathan Rochkind]

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
(http://www.niso.org/standards/resources/Z39-71.pdf), 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.