Email list hosting service & mailing list manager


Serials Holdings Access Survey Results (Sam A. Khosh-khui) Marcia Tuttle 04 Feb 1994 06:58 UTC

---------- Forwarded message ----------
Date: Fri, 4 Feb 1994 09:58:27 -0500
From: "Sam A. Khosh-khui" <SK03@ADMIN.SWT.EDU>
Subject: Serials Holdings Access Survey Results

                     SERIALS HOLDINGS ACCESS SURVEY RESULTS

        Many thanks to those who responded to our "Serials Holdings
        Access Survey".  The following is a summary of the results.

        Fifty-five percent (55%) of the respondents indicated that they
        either maintain a separate serial database or they are in the
        process of creating one.  Forty-five percent (45%) indicated that
        they do not have a separate serials database or have no plans to
        have a separate serials database.

        Forty percent (40%) of those who have separate serials databases
        indicated that the changes in the main database automatically
        reflected in the serials database.  Another method being
        mentioned to update the serials database is that every record
        created or changed in the main database is added to a queue, then
        a tape is produced from the records in the queue and loaded
        off-line into the separate serials database.  Other libraries
        indicated that they update the serial database once a week, every
        other week, and once a month.

        COMMENTS FOR HAVING A SEPARATE SERIALS DATABASE:

        Some of those who have separate serials databases commented that
        they do not have their periodicals listed in OPACs since they are
        not cataloged but are housed in a separate section of the Library
        and filed alphabetically by title.

        Having a separate database would allow linking to "our
        Abstracting and Indexing databases without worrying about
        different record types, ISBN's vs. ISSN's for linking, etc.; that
        we avoid 'contaminating' the title index in our monographs file
        with the numerous high-frequency words that appear in journal
        titles; that we provide serials-specific access points and have
        different combinations of indexes".

        For some it was too early to say whether or not their users are
        better served with having a separate serials database, partly
        because most of their users haven't used the alternative approach
        to accessing their serials list.  The feeling is that there are
        some real challenges to extracting serials holdings information
        from the DRA system via Report Writer. Some others libraries have
        already done so and have extracted serial records through DRA
        Report Writer and made them available through the Gopher Server.
        Using such methods, the users are better served because once the
        information is available through gopher, people can use a
        WAIS-like search of the serials list and see a summary of the
        holdings.

        Those libraries who have created a separate serials database for
        their serials indicated that they have no regret over their
        decisions.  In response to the question "Would you do it
        differently if you had to do it all over again?" These comments
        were mentioned:

        -Absolutely!  It has given us excellent control of the
         collection ... and provides up-to-date information to the
         patron.

        -Our users are better served by the separate system only because
         it has more functionality.  We have separate monographs and
         serials databases ... and this causes problem to our users who
         have to search 2 databases to verify our holdings, especially
         for conferences records which could be in either of them.

        -Users are mostly interested in the continuance of the Serials
         List and some improvement in its sophistication.  They are also
         very pleased with one place to look (OPAC) for both serials and
         monographs!

        One problem being mentioned is the difficulty many students have
        with the display of retrieved serials titles information in the
        OPAC.  The library, however commented that they do not have a
        fully automated Serials Module.  Therefore, holdings are not
        displayed in the OPAC, only displayed in the Serials List and
        this may be part of the reason.

        Even among those who do not have separate serials database for
        serials some of the above advantages were mentioned but it was
        indicated that they need the ability to add some intelligence to
        the OPAC to guide users to the serials file at appropriate points
        in their search".

        COMMENTS FOR NOT HAVING A SEPARATE SERIALS DATABASE:

        Those who did not have a separate database indicated that double
        databases are a disaster.  It takes a lot of time energy to make
        sure things keep both database up-to-date the way you want them
        to.  Not many patrons differentiate between serials and non
        serials when they search. When having two separate databases,
        "you have to assume that your patrons know in advance that
        something is a serial in order to know where to look.  That is
        not always true".

        "Users are not likely to look for encyclopedias, yearbooks or
        things like Physician's Desk Reference in the serials file, but
        these items are coded as serials in the MARC record.  As a matter
        of fact, since we are a union catalog, some of our libraries
        don't agree on the definition of "serial", so there are some
        titles that are represented in both files. "

        "Another difficulty is the issue of non-book serials (and this
        can only get worse with Format Integration).  If most users think
        of serials as "magazines", you can be sure that they will not
        search for sound recordings in the serials database, though some
        sound recording series may be treated as serials by the library."

        Most patrons prefer a single place to look and enjoy the benefits
        of an integrated system.  "It seems to me that what you are
        wanting is a different *view* of the same database ... not
        separate views.  If so, you should be lobbying/working-for a
        different presentation appropriate to serials and/or a different
        search mechanism." Most of the time, having everything in one
        single database has worked well for most people and is too early
        to tell if this method will be a major inconvenience or not.

        Two libraries pointed out that previously they had separate
        databases for serials.  However, after realizing that "it was too
        much work to be updating holdings in two separate files and it
        appeared that their students were _not_ willing to search for
        serials in a separate lookup", they decided to combine the
        serials database with the main one.  Doing so has eliminated
        patrons frustration.  It was also easier for people in the ILL
        Dept.

        The additional cost of keeping two parallel systems and system
        support for local database was mentioned as another reason for
        not having separate serials database. "The amount of duplicate
        effort required is enormous".

        Finally, some libraries indicated that they have plans for
        enhancing their automated systems and once it is a reality, they
        will re-evaluate the need for separate serials databases.

    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    *                                                                 *
    * Sam A. Khosh-khui, Ph. D.         BITNET: SK03@SWTEXAS          *
    * Serials Cataloging Librarian    INTERNET: SK03@ACADEMIA.SWT.EDU *
    * Albert B. Alkek Library            PHONE: 512/245-2288          *
    * Southwest Texas State University     FAX: 512/245-3002          *
    * San Marcos, Texas 78666-4604                                    *
    *                                                                 *
    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *