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.
