Email list hosting service & mailing list manager


Re: Coverage loads - quality of data Steven C Shadle 15 Oct 2008 00:36 UTC

Agreed.  I make it clear to Thompson that my faculty (Thompson's immediate audience) is not finding the content they want and that faculty understand it is a problem with the data Thompson is using.  In one case, I had a faculty member who wanted to contact them directly and I provided the email address.  If you take the time to educate faculty, they can be great advocates.

Steve Shadle/Serials Access Librarian  *****  shadle@u.washington.edu
University of Washington Libraries      ***     Phone: (206) 685-3983
Seattle, WA 98195-2900                   *        Fax: (206) 543-0854

On Tue, 14 Oct 2008, Laura Smart wrote:

> Publishers hear from us.  We complain mightily when we encounter it.  Web of Knowledge is particularly messy in its treatment of title/ISSN changes (see how they treat the Physical Review titles for example).  Thompson's response so far has been to tell us, in effect, "we can't do that" when we're requested that they get more accurate information.  That is horse-pucky. It IS technically possible, they just refuse to do it. Libraries don't have enough market leverage with Thompson that they will make it a priority, I presume.   We will continue pressuring publishers/vendors though.  I dream of a day when publishers will create consistent metadata for their offerings, in a standards-based and open format, and really look forward to seeing how much publisher buy-in happens with the KBART initiative.
>
> Laura
>
>
>
>
> Laura Smart, Metadata Services Manager
> Caltech Library Services
> 1200 E. California Blvd. MC 1-32
> Pasadena, CA     91125-3200
> (626)395-6149 / FAX (626)792-7540
> http://library.caltech.edu/laura
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: SERIALST: Serials in Libraries Discussion Forum
>> [mailto:SERIALST@list.uvm.edu] On Behalf Of Ercelawn, Ann
>> Sent: Tuesday, October 14, 2008 1: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.
>