Email list hosting service & mailing list manager

(Previous discussion continued)
Re: Coverage loads - quality of data McCracken, Peter (15 Oct 2008 17:32 UTC)

Re: Coverage loads - quality of data McCracken, Peter 15 Oct 2008 17:32 UTC

I'd like to chime in on this topic on two levels: first, as co-chair of the KBART group mentioned below, and second, as a co-founder of Serials Solutions.

First, I feel strongly that KBART will be able to create a positive impact on the transfer of data among and between members of the e-resource supply chain. We have a great group of individuals from all parts of the supply chain who have been putting a lot of work into the project so far. The working group first met in March, and given that we only meet monthly, much has been done so far. We anticipate releasing our report in early 2009.

Anyone can follow our progress at NISO's KBART page (http://www.niso.org/workrooms/kbart) or by joining the monitoring group at http://www.niso.org/lists/kbart_interest/.

We *are* focusing on the issue of inaccurate data being delivered by content providers, and I think it is obviously a very important one. Charlie Rapple and I, the two KBART co-chairs, have given presentations about KBART everywhere we can, including through a number of conferences and meetings aimed directly at publishers. Several members of the KBART team, chaired by Adam Chandler (Cornell Univ), will be presenting about KBART at the Charleston Conference next week.

We see an important role in educating publishers about the metadata they deliver. In a nutshell, inaccurate metadata leads to incomplete searches, which leads to undiscovered content, which leads to unrenewed subscriptions, which leads to lost revenue. Hopefully, that argument will carry some weight.

In addition, if content providers are able to significantly enhance the quality of the data they deliver, then it may be that libraries will be able to feel confident in using files directly from the content providers, rather than passing them through ERAMS vendors like Serials Solutions.

So to go to my second point, I'd like to thank Judith Stokes for her comments about Serials Solutions -- they were welcomed heartily in the office, by the way -- but make one point that I've made in other places before.

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.

We are willing to take the blame, even if we didn't introduce the error, because we see our role as improving the way libraries connect their patrons with their content. We can best do that through improving the data we manage. So when aggregators report incorrect data, please do tell us, because we *can* fix it, we *can* tell you what you can actually access in those databases, and we can help you get patrons to resources that it seems aggregators don't even know they're offering.

Thanks,

Peter McCracken

-----Original Message-----
From: SERIALST: Serials in Libraries Discussion Forum [mailto:SERIALST@list.uvm.edu] On Behalf Of Ercelawn, Ann
Sent: Tuesday, October 14, 2008 4:22 PM
To: SERIALST@LIST.UVM.EDU
Subject: Re: [SERIALST] Coverage loads - quality of data

The KBART Group is working on this problem
(http://www.niso.org/workrooms/kbart).
But publishers need to hear from librarians that the quality of data at
publisher web sites matters.

Ann

-----Original Message-----
From: SERIALST: Serials in Libraries Discussion Forum
[mailto:SERIALST@LIST.UVM.EDU] On Behalf Of Chad Hutchens
Sent: Tuesday, October 14, 2008 2:20 PM
To: SERIALST@LIST.UVM.EDU
Subject: Re: [SERIALST] Coverage loads - quality of data

I agree...this is a big problem in a lot of ways.  There's a report out
that
was done in the UK in 2007 I believe.  It's a very interesting read that
describes what is going on with this entire problem.

A very good read for those interested:

http://www.uksg.org/resolvers

--
Chad Hutchens
Electronic Resources Librarian
University of Wyoming Libraries
Dept 3334, 1000 E University Ave.
Laramie, WY 82071-20000
Ph: (307) 766-5560

> From: Lucy Wrightington <lxw08@HEALTH.STATE.NY.US>
> Reply-To: "SERIALST: Serials in Libraries Discussion Forum"
> <SERIALST@LIST.UVM.EDU>
> Date: Tue, 14 Oct 2008 09:51:09 -0400
> To: "SERIALST: Serials in Libraries Discussion Forum"
<SERIALST@LIST.UVM.EDU>
> Subject: Re: [SERIALST] Coverage loads - quality of data
>
> A huge and growing problem that no one so far seems able/willing to
tackle.
> I report these to Ebsco A-to-Z all the time, but they are dependent on
the
> publisher loads.
> Former titles are getting lost as they don't show up in the databases
at
> all.
> Many publishers are guilty of this.
> Who's doing it right? Science Direct and PubMed Central to name a
couple.
> They should be the accepted model.
> Any ideas would be welcome on how the library community can bring
pressure
> to fix this.
>
> Lucy Wrightington, Senior Librarian
> Dickerman Library
> Wadsworth Center, N.Y. State Dept. of Health
> Empire State Plaza, Albany, NY 12201
>
>
>
>
>
>              "Stokes, Judith"
>              <JStokes@RIC.EDU>
>              Sent by:
To
>              "SERIALST:                SERIALST@LIST.UVM.EDU
>              Serials in
cc
>              Libraries
>              Discussion Forum"
Subject
>              <SERIALST@LIST.UV         Re: [SERIALST] Coverage loads -
>              M.EDU>                    quality of data
>
>
>              10/14/2008 09:39
>              AM
>
>
>              Please respond to
>                 "SERIALST:
>                 Serials in
>                  Libraries
>              Discussion Forum"
>              <SERIALST@LIST.UV
>                   M.EDU>
>
>
>
>
>
>
> When we find errors and report them to Serials Solutions they are
> cooperative -- enthusiastic, even, about getting it right. On the
other
> hand, if the data comes from an aggregator like Proquest which does
just
> what you reported -- lump all holdings under the current title and not
even
> cross ref from the old title -- it will just keep coming in wrong over
and
> over again. Getting the aggregators to change is a different story
> altogether. I've had no luck with that.
>
> Good luck,
> Judith Stokes
>
> Judith E. Stokes
> Serials/E-resources Librarian
> Rhode Island College
> 600 Mount Pleasant Avenue
> Providence, RI 02908-1991
> 401.456.8165
>
>
> -----Original Message-----
> From: SERIALST: Serials in Libraries Discussion Forum
> [mailto:SERIALST@list.uvm.edu] On Behalf Of Cahill, Helen
> Sent: Monday, October 13, 2008 8:08 PM
> To: SERIALST@LIST.UVM.EDU
> Subject: [SERIALST] Coverage loads - quality of data
>
> Hello all,
>
> I wonder if there is anybody out there who has assessed the quality of
data
> being offered by the coverage load vendors? I'm principally interested
in
> Serials Solutions, Ebsco A-Z, and III's CASE product, but would also
> welcome comments on any others.
>
> Here is an example from the coverage loads for ACM: "SIGART bulletin"
was
> published 1990-1998 with previous and later titles. There is (to my
> cataloguing mind) a problem over the coverage that is available from
SS,
> EAZ and CASE: they list the coverage for SIGART bulletin to be
1970-1998,
> and don't have any listing for the previous title. I've looked in a
few
> catalogues (randomly) and it seems to me that libraries are simply
> accepting that (wrong) coverage data. How do your patrons find the
online
> version of "SIGART newsletter"?
>
> Has that bothered anybody out there enough to have attempted to get
these
> vendors to properly match the coverage to the title runs? Or, are we
so
> seriously understaffed world-wide that we can't either do the checking
&
> correcting or pressure the vendors to produce accurate information?
Has
> anybody ever offered to clean up the data offered by these vendors to
> benefit all others?
>
> I'm feeling like this is going to develop into one of those Publisher
vs
> Vendor, IT vs Cataloguer debates, but I'm always mindful of what our
> library patrons want to see when they look on our OPACs.
>
> Thanks!
>
> Helen Cahill
> Cataloguer, Collection Services
> Massey University Library
> Private Bag 11054
> Palmerston North 4442
> NEW ZEALAND
>
> Ph: + 64 6 350 5799 ext 7876
> Fax: + 64 6 350 5692
> emai: H.Cahill@massey.ac.nz<mailto:H.Cahill@massey.ac.nz>
> http://library.massey.ac.nz
>
>
>
> IMPORTANT NOTICE:  This e-mail and any attachments may contain
confidential or
> sensitive information which is, or may be, legally privileged or
otherwise
> protected by law from further disclosure.  It is intended only for the
> addressee.  If you received this in error or from someone who was not
> authorized to send it to you, please do not distribute, copy or use it
or any
> attachments.  Please notify the sender immediately by reply e-mail and
delete
> this from your system. Thank you for your cooperation.