Email list hosting service & mailing list manager

Re: Coverage loads - quality of data (Peter Hosking) Bob Persing 17 Oct 2008 01:56 UTC

Subject: RE: SERIALST Digest - 14 Oct 2008 to 15 Oct 2008 (#2008-210)
From: Peter Hosking <>
Date: Fri, 17 Oct 2008 10:17:49 +1300
To: "SERIALST: Serials in Libraries Discussion Forum"

Hello Peter

I read your reply with interest and I'd like to add that our experience
has been similar to Judith's. Whenever we have reported any data
problems they have been quickly resolved by Serials Solutions.

However I do wonder if you run any crosschecks comparing information in
the MARC record with the coverage dates? For example if you have a
coverage note saying "12/01/1994 to present" but the MARC record has an
008 Dt St set to 'd' it probably needs investigating. Or if the date 1
in the 008 is 1995, and the coverage date starts with 1980 then it is
likely there is a mismatch.

An example is ssj0030585 which has an 008 beginning date 1991, but the
coverage date for AGU Digital Library starts with 1978.

Peter Hosking
Serials Cataloguing Librarian
Collection Services
University of Canterbury Library
Christchurch, N.Z.

On Wed, 15 Oct 2008, Peter McCracken wrote:

 > ... I feel that you should, in fact, blame Serials Solutions when you
 > find inaccurate data, even if we didn't introduce it. We're never going
 > to have perfect data, but you can bet we're going to try! Libraries pay
 > us to manage this data, and we see it as a critical part of what we do.
 > We realized long ago that if we didn't have a way of correcting the data
 > we get from content providers, we'd never be able to deliver correct
 > data to our customers. So we built a "rules management module," in which
 > our catalogers and knowledgebase editors research and then write rules
 > to correct inaccurate data that comes into our system. (All of these
 > editors are in our Seattle office, and , thanks to the nearby UW
 > iSchool, all have MLSs, are earning them, or have significant experience
 > working in libraries before joining Serials Solutions.) We currently
 > have many thousands of rules written to correct errors coming in from
 > hundreds of databases.
 > We very much welcome corrections from clients, as Judith says. We can't
 > check everything (in fact, there's a lot we can't check at all, since we
 > don't have access to the database), and we rely on clients to help us
 > discover these errors. And what I love most is that when a librarian
 > reports an error to us, we correct it not just for that person's
 > institution and users, but for *everyone* who has access to that
 > database ...