|
Endeavor Implementation Project |
Some Endeavor Voyager Catalogs to Visit
Some Opinions About Sharing (Combining) Databases
Making Decisions in a Shared Database
Web Catalog/OPAC
Acquisitions and Serials
Cataloging
Circulation
Reports
Security
System-wide Considerations
UH Systems Department Workload Considerations
Pros and Cons of Merged (Shared) vs. Separate Databases
How will we make the final decision?
Here are combined notes from various meetings and email messages.
Please send comments and corrections to Wil Frost.
Deadline for library decisions on shared or separate databases due to Wil Frost: Tuesday, March 21, 2000. University's deadline for decision to Endeavor: Friday, March 24, 2000.
You will find it useful to visit Endeavor libraries on the web and look at their catalogs. There is a customer list at the Endeavor corporate site, http://www.endinfosys.com. Here are a few you might want to try:
According to Endeavor, this is a shared database with multiple institutions where they deduped records in the loading process.
Northwestern University and Washington Research Library Consortium
According to Endeavor, these are both cases of shared databases where they did not attempt to dedupe.
According to Endeavor, Georgia has separate databases and they have grouped selected databases for simultaneous searching.
Informs users of the need to pre-limit a search, tells what kinds of searches cannot be limited and provides step by step instructions.
01. Distance Education Librarians
02. Paula Mochida, UH Administration
03. Paul Wermager, UH Manoa Library
04. Roberta Winjum, UH Manoa Library
05. Gregg Geary, UH Manoa Library
06. Tokiko Bazzell, UH Manoa Library
07. Lenore Maruyama, Leeward Community College
08. Ramona Kincaid, Kauai Community College
09. Thelma Diercks, UH Manoa Library
10. Dave Coleman, UH Manoa Library
Arguments against a Shared Database
11. Helen Rogers, UH Hilo
12. Kevin Roddy, UH Hilo
13. Larry Goldstein, Leeward Community College
14. Lisa Sepa, Maui Community College
(Listed in order received.)
1. The UH Distance Learning Librarians would like to go on
record in support of a common patron file and catalog in the Endeavor system.
Ultimately common databases will provide easier access to library services
for all students and in particular Distance Learning students who enroll at
different campuses simultaneously.
A shared patron file would mean that privileges (i.e. online access, book borrowing, magazine subscriptions, etc.) could be added or deleted with greater ease. As it stands now students have to register at several different libraries for different privileges and some students may not even be allowed to borrow at their local site library if they are not registered there as students. We have recently solved the multiple library card problem by issuing barcodes to attach to local site cards but every site has a different system and students have to know the "rules" of each system.
There are issues in circulation where distance students are not registered as students at the local site campus and incur delinquent fees or fines. There is no easy way to put a hold on that student, whereas a shared patron file would simplify this process and in addition, allow us to track patrons who borrow from multiple libraries. Although a few people on the outer islands fly to Manoa and borrow books, this problem is especially significant to Oahu libraries where access is much easier and where more libraries are involved. In Fall 2000, the UHCCs will be delivering an AA Distance Learning degree and UH Manoa and UH Hilo are offering co-delivered certificates and BA/MA degrees. The amount of students taking courses from various campuses can only increase as evidenced by the upward trend in Distance Learning enrollments across the system.
Although our primary focus has always been on the patron registration file, we would also support a common catalog. Reference librarians can relate a litany of student errors in their approach to our catalogs, logging on to the wrong catalog, switching to the wrong one, overlooking catalogs, etc., etc. One stop shopping is a way to overcome these problems. No doubt there will be much confusion if we adopt a common catalog but the good bibliographic instruction and reference service that we have always provided can overcome this.
Distance Learning has been moving us toward a universal approach to many of our services, registration (Buzzeo), counseling, financial aid, and libraries. Obviously, it is the student that drives these changes and this case is no different. We urge you to seriously consider a universal system.
Sincerely yours,
Ramona Kincaid, Convener, UH Distance Learning Librarians
Anne Mckenna
David E. Coleman
Diane Sakai
Elaine Shultz
Laurel A Gregory
Linda Soma
Nancy Heu
Randy Hensley
Susan Murata
Tiffany Severn
2. Paula Mochida, UH Distance Education special assistant, has requested that
we have a shared database for all University campuses in order to support
distance education students who take classes on different campuses. She states:
From my distance learning perspective, I think a universal database is needed in order to provide the best possible service to all of our patrons. The boundaries between campuses are physical limitations that no longer have to nor should impede library research, borrowing, document delivery, business transactions, etc.
It is essential to the success of distance learning that academic and student support services and infrastructures are streamlined to facilitate what students and faculty require. In addition to Manoa on-campus students, there are around 800 students taking Manoa courses throughout the state, primarily on the neighbor islands. In total, there are around 3000 students taking UH distance learning classes throughout the system, in-state and out-of-state. Many are taking classes from more than one campus.
I know there is concern about security, quality, etc. but we'll wait until hell freezes over before we get the perfect system. In other words, we can't wait! I have a great deal of confidence that most of our students can figure out how to navigate library holdings and online information and I have a great deal of trust in the integrity and capabilities of our staff.
I hope that you will endorse my recommendation to the decision-makers to invest in whatever it takes to implement a common database from the start. I frequently "brag" about how successful the library has been in working as a system (albeit not without pain), and this would be another MAJOR example.
3. Paul Wermager, chair of the UH Manoa Library's Departments Heads Group believes:
A. We must think Globally and not continue to think so territorily. We are moving (finally) to a web environment and so, therefore, should maximize the advantages a web product like Endeavor can offer us, instead of reverting to our narrow, library-centered thinking which in the long run will create roadblocks for our patrons in the coming years. We MUST use a shared database! It would be fiscally irresponsible of us not to.
B. A Shared Database will not be an easy entity to build or maintain. But it is NOT an impossibility either. Other sites have done it; why can't we? It requires two major components from us: -a VISION of a shared database for the UH System -a WILL to make the shared database work
C. Haste makes waste. If we are going to do a shared database correctly and be able to address all the complexities adequately, we need MORE Time to accomplish that task. July is a VERY unrealistic goal, given the major questions still left unresolved. Can we not simply stop our maintenance contract with CARL and continue to use the present CARL software while working out the bugs/decisions on Endeavor? (Our tandems are the most reliable equipment we have so i doubt very much we would have any downtime with CARL in the interium.) If that is not feasible, then we should bite the bullet and continue to run CARL with Endeavor in the background in a test mode.
In summary, i strongly support a shared database, but i would like to see it created slowly, deliberately, and with as much testing as possible to attain a QUALITY database we can all take pride in.
4. Roberta Winjum, head of the UH Manoa Library's Collection Services
Division provides this review done by the Collection Services department
heads.
The table of Pros and Cons of Merged (Shared) vs. Separate Databases (at bottom of this page) shows pros and cons identified by the Collection Services Division Heads regarding the idea of a shared database versus multiple separate databases for UH System Libraries in the Endeavor Voyager system.
The columns are divided into pros and cons of either merged or separate databases. Each row attempts to describe the pros and cons of one concept as it relates to either merged or separate databases. The asterisks preceding an item show that it was considered a critical or deciding factor. Thirteen items with asterisks can be construed as supportive of separate databases; twelve are supportive of a merged database.
In light of this, the decision is not clear-cut. The Collection Services Heads could make a case for either a merged database or shared databases. We are willing to support a shared database, however, please note that some of the negatives of a shared database pertain to problems with "dirty data", duplicate records, and authority control. We are concerned that no formal body exists to determine how the workload will be shared, who may touch which bibliographic records, or other details of shared data. We would like to suggest that one or more decision making bodies be created to make these decisions, and we feel that the decisions should be made by a representative group that would know the data and the ramifications well. For example, a Community Colleges Cataloging Committee already exists, and its membership and duties could be expanded to consider cataloging and authority control issues of a system-wide shared database.
We also recognize, and hope that you appreciate, that a shared database will create some workload issues, perhaps more for Manoa than the other system libraries. We would like some reassurance that flexibility exists to expand our staffing if needed to cover the added responsibilities of database maintenance of a new, merged database.
Many of the biggest obstacles to a shared database turn out, in our estimation, to be problems that can be solved with effort and resources. We hope that the UH System is willing to make these efforts and devote these resources to what we feel, through this analysis, has shown itself to us to be a good idea overall for the long term benefit of UH System patrons.
5. Gregg Geary, head of UH Manoa Library's Sinclair Library offers
these thoughts:
After reviewing a number of the issue related to shared vs. separarte databases for Endeavor I give my "qualified" support for the shared database. Here are some of my thoughts and concerns:
Positive Thoughts
A. I agree with those in the Community Colleges, Paula Mochida, and others in Distance Ed. that we need to move to the shared database. We must put actions behind the long ongoing rhetoric regarding a Unified University System. We must use the new technology available to us to make it easier for patrons to access information. Wherever possible, we should have less geographic discrimination.
B have read Helen Rogers passionate appeal against the shared database. I understand her concerns. Yet, when I read at the end of her message that she did not find a student who was not able to conceptualize use of sparated databases I have to ask why the converse would not be equally true. It is just something we are not familar with. I am especially concerned that since her major complaints will be address by the new Endavor system coming at the start of 2001 we will make a short sighted decision. If we go with separate databases it may be an expensive and limiting system that we will live with for years to come and was done primairly to prevent a problem that would be with us for only six months.
C We have had problems with getting media material to the community colleges due to a cumbersome system that does not provide convenient access of media material to community college students. If we ever which to consider off-site loans of media material to CC patrons the shared system will facilitate these considerations.
D. As a selector, I think it will be very informative to know what is in other collections across the system with just one search. I will be able to make better quality decisions about what to buy. This is especially true if borrowing among the colleges is streamlined. I am concened that students have ready access to information. If the state University System owns it and they can borrow it, fine. I do not demand that if be housed at Manao. Getting it to the patron is a concern expressed below.
D. While there is definately going to be a good deal of teaching patrons and staff on how to use the system, we should remember that since this is a Web-based system there is a good sized segment of our population who will take to this new system with some ease. They may understand its capabilities better than we expect them to. At least I hope this is true. These folks may find using a single database, and using limiting features to get just what they need, much easier than we give them credit for.
Concerns
A. Cost will be a factor. We will need to pay for a courier service to return materials from one library to another in a timely fashion. I can foresee problems if material that is checked in at another campus is returned at a third campus and takes over a week to wend its way home where it belongs. Other multi-campus institutions have address this problem and seem to have survived. So this is a problem, but I think it is one we must address and overcome. I do not think sticking with separate databases will get us any closer to the vision of the library we want in the future.
B. The PAC display is definately a concern. I think the PAC committees need to take a close look at how holdings display. We need to come up with short and LONG term solutions to this problem. I understand the new version of Voyager will be able to display local holdings first and follow with any other selected databases. I think this is ideal and we should move to this type of display of holdings ASAP.
C. According to what I hear from Acquisition and Cataloging, there will be a great deal of up-front work that needs to be done to make a single database a reality. For this reason I would hope the start date could be rolled back. I think slapping up a database full of errors is a disservice to students and staff. I think the extra work will be worthwhile in the long run. But there is no getting around the fact that this decision is really heavily front loaded with work for everyone. That also includes those of us who must teach patrons to use the system.
These are my thoughts. I hope some find them useful.
6. Tokiko Bazzell of UH Manoa Library's Asia Collection has further
comments related to Ralph Toyama's message (below):
I would like to second Ralph's statement. I was a business librarian at the American University of Washington, DC, which is one of 7 universities consortium forming "the Washington Research Library Consortium." Unlike here, each library (university) is a completely independent private and public university. Even prior to the Voyager implementation, these 7 universities realized that sharing resources was a vital component to meet patrons' needs. So we've been sharing databases and resources since 1989.
Among 7 independent universities, George Washington University has over
30,000 students (biggest of all) and Marymount Univ. has only 3,000
students (smallest). On top of that, George Mason University is a public
institution, which also belongs to Virginia University Library
Consortium. So you can see these 7 universities are very diverse in size,
background and location. You can read more about this unique consortium
on their web site
From my own experience, this arrangment is a huge enhancement for students and faculty. We had no problem limiting the display of holding to one particular university but patrons always want to see other univerities' holdings to see what other possible sources are. Each university has its own strenths and weaknesses and librarians and patrons both know that. The smallest Marymount cannot compete in terms of volumes but they have their own focused disciplines, which benefit other university students.
I do not think that students in Hawaii are not much different from the students in Washington, DC to whom I served. They can learn the new system and functions with proper instructions.
Also one more thing, as I mentioned that George Mason University also belongs to the Virginia Library Consortium, which uses a different system from WRLC, runs both Voyager with shared databases and Virginia's shared system. We can tailor the system and display based on each individual institution's needs.
To me shared resources are the only way to strengthen our resources. As a matter of fact, I was quite surprised to see that the UH System does not have shared databases when I moved here a year ago.
----- Original Message -----
From: Ralph Toyama
Subject: Shared DB - Solution?
Looking at the Washington Research Library Consortium's ALADIN system (http://www.wrlc.org), which supposedly is running off a shared database, it seems that they've found a way to allow pre-selection of a particular library's catalog before the patron ever gets to a search interface. Once at the interface, and on the subsequent results list, the library's name is still shown on the screen.
I haven't played with it hard enough to find any hidden problems with this arrangement, so it might very well be doing something weird below the surface. But from what I've seen so far, it looks like it might be a workable solution.
7. Lenore Maruyama from Leeward Community College Technical
Services offers the following:
A shared database (even with Manoa) is preferable for the following reasons:
(1) A shared patron database would expedite/facilitate our circulation functions. Since UH-West Oahu occupies the same building, we have a lot of patrons who are West Oahu students or faculty; we also have a number of patrons who are students at UH-M, Honolulu, and Kapiolani. [A shared patron database is only possible with a shared bib. database]
(2) "Timely and effective interlibrary loan or document delivery service for materials not owned by the library" and participation "in available consortial borrowing programs" are two areas in "Standards for College Libraries, 2000 Edition" that most of us in the community colleges do not have access to. UH-M distance education students on Oahu do not have the same borrowing/access privileges as those students at university centers on the other islands. Manoa and Hilo might become net lenders, but on the other hand, if a certain title is requested often enough, wouldn't that be a "trigger" to consider acquiring it for your own collection?
(3) Sharing of bibliographic resources (i.e., bibliographic and authority records) should result in savings in time and money for most of the [smaller] sites. Manoa might benefit from our (the other libraries') cataloging of federal and state documents, locally published reports, etc.
(4) Perhaps for the first time, the University of Hawaii system libraries would be acting as a system, benefiting students, faculty, and staff throughout the system.
That's the motherhood and apple pie stuff. We're not at the forefront of a trend but at the tail end of one.
All the foregoing doesn't mean that we don't have a lot of work and problem-solving to do. Even with just the community colleges and West Oahu in one database, I've concluded that deduping at time of "merger" will wipe out "extra" fields that were added to improve access, e.g., additional title fields, contents notes, added entries, subject headings. For small collections like ours, we probably wouldn't have individual titles on certain subjects, but these subjects might be included in an anthology or other compilation. Adding a contents note field in these cases would "stretch" our resources further. Deduping wouldn't catch those records where one library has cataloged the title as a serial, another as a monograph.
Once we're in Voyager, it would be much easier for us to add our holdings/item records to bibl. records already in the database. And to add authority records as needed. Enhancements to the bibl. and/or auth. records, assuming that we could all agree on what could be added, could be done on an "as needed" basis. As older records are revised or edited in some fashion or another, we could take that opportunity to transfer our holdings to another library's bibl. record and thus remove some duplicate bibl. records from the database.
We're in a far better position to share training/teaching aids among system libraries. Teaching/reaching students remains a problem, but haven't we had to do that every semester in one form or another? A shared database doesn't change that; but teaching students how to use Voyager has to emphasize different points.
From a cataloging standpoint, any form of shared database is better than none at all. In the past 31 years [since the start of the MARC distribution service], there have been so many changes in cataloging rules and MARC format specifications, many of which have not been updated in our respective databases. So "quality" cataloging is in the minds of the beholder ... what's changed is that some of our individual institution's oddball practices or mistakes are out in the view of everybody.
9. Ramona Kincaid from Kauai Community College adds her own
comments in addition to the UH Distance Education Librarians statement
earlier:
I am Ramona Kincaid from KauaiCC. I am one of two reference librarians here, I conduct most of the BI and am involved with Distance Learning. Some of you know that I authored the letter to the library directors in support of a shared library system. I would like to throw up a few points to consider along with the other very good points that have been made by our colleagues already.
As Tokiko stated in her email students like to see other holdings. When a student sees other library's holdings some obvious benefits are:
1. it broadens their information reach
2. it increases serendipity or browsability
3. it introduces a new resource (in the case where students actually visit another site) and potentially a new campus to consider
These are things that I would like all students to have without having to hop around from catalog to catalog. Students are constantly in the wrong catalog, moving to the wrong catalog and overlooking catalogs (UHM students here on Kauai automatically search UHM catalogs and frequently overlook the local catalog). For those of you who think that your libraries will be inundated with ILL requests, not to worry. We have offered ILL to our KauaiCC students (a free service) for years and about 99.9% of them cannot afford the time it will take to have the items shipped. And I am sure that the same will be true for Oahu CCs.
In a recent article (Bell, C&RL, 9/99) a study was conducted that measured affective behavior toward a web vs telnet interface (for Dialog), it was found that students were more comfortable in a web environment. I think that we can all attest to this when observing students in our libraries. (I notice this especially when students move from UHCARL to Medline or web-IAC.) This comfort level may help in overcoming some of the limiting problems (email K.Roddy, 17 March and H. Rogers, 16 March) posed by Voyager. For example, students are used to scrolling down and perusing search results, they often engage in randomly clicking on buttons out of curiosity and use web search engines that have limit functions. Maybe we are measuring their skills based on the telnet interface. Can we be so sure that students will not be able to cope better in a web environment? Are we underestimating their ability to learn or our ability to help them learn?
I wish we had more time, I wish we could wait for version 2000 but alas I have to count myself along with the rest of the KauaiCC students I mentioned in the first paragraph, I've let it go too long. I support a shared catalog, I see benefits for the students ahead and yes, lots of hard work for us.
9. Thelma Diercks provides this information from American
University, part of the Washington Research Library Consortium:
I've received answers from Janice Flug, Head of Acquisitions, at American University to questions I asked about a shared database. She has given her ok to post her answers to you.
Thelma Diercks,
Head, Acquisitions, UHM
A. When a user searches the OPAC, is the search preset a) to search AU only with b) an option to search more widely later?
ALL OF THE LIBRARIES HOLDINGS APPEAR - YOU CAN SET UP YOUR SEARCH TO ONLY GET AU'S TITLES OR AFTER YOU HAVE DONE YOUR SEARCH IT CAN SORT BY SCHOOL CODES. IT IS EASY TO TELL WHO OWNS WHAT. IT IS ALSO A GOOD WAY TO SEE IF WE ARE OR ARE NOT ADDING TITLES THAT WE SHOULD BE IN THE SHARED AREAS.
B. When a staff member searches the OPAC, is the search preset to search AU only with b) an option to search more widely later?
SAME AS ABOVE SINCE THE OPAC SEARCH DOES NOT KNOW IF WE ARE STAFF OR NOT. THIS IS TRUE IN ALL OF THE MODULES.
C. If the answer to part a) is NO, do the holdings of all libraries display in OPAC resulting in "monster" records (e.g., Statistical Abstracts for the United States)?
SOMETIMES THE LISTS ARE A BIT LONG BUT AS NOTED ABOVE YOU CAN SORT OR LIMIT THE SEARCH. ALSO SOMETIMES IT HELPS TO SEE A LARGER ANSWER TO A SEARCH QUERY BECAUSE SOMETHING HAS BEEN CATALOGED DIFFERENTLY.
D. If the answer to part b) is YES, is the wider search easy to execute? YES
E. Has the response to the WRLC shared database been generally favorable by a) users and by b) staff? Are people wildy enthusiastic or disappointed by sharing?
IT IS WHAT WE HAVE HAD FOR YEARS. STUDENTS LIKE SEEING WHAT THE OTHER LIBRARIES OWN BECAUSE OF ILL OPPORTUNITIES. FOR STAFF IT HELPS TO MONITOR APPROVAL PLANS. I DON'T SEE IT AS A PROBLEM.
F. Do you see any advantages for distance education?
YES - BECAUSE PEOPLE CAN GO TO THE CLOSEST LIBRARY. OUR STUDENTS CAN RETURN BOOKS TO ANY OF THE LIBRARIES AND PAY FINES AT ANY OF THE LIBRARIES. SO WE DO ALOT OF SHARING.
10. Dave Coleman of UH Manoa Library's Science Technology
Reference Department offers:
Shared vs. separate
Compromise, Cooperate, Negotiate... We didn't spend much time on those
things when I was in Library School, but it's what makes the world go
'round. Difficult, yes, frustrating, yes, but we owe it to our patrons and
the profession to overcome our differences, look beyond our individual
uncertainties at the bigger picture, and build the best possible system
that we can.
Vendor cooperation.
I think we have all learned from our "shared CARL experience" that we, as a
group, have to be diligent, observant, persistent, communicative and
professional, but aggressive in our demands to the vendor. We are paying a
considerable amount to Endeavor to provide us with a service. As Eric
Flower and others suggest, surely there is a way that users can select the
range of databases that they want to search. The things we ask may be
difficult to implement but surely the technology is up to it.
Student overload
Student web expertise varies widely but it is obviously growing. I think we
will sell our users short if we "dumb down" the system. It is pretty clear
that one of our primary roles as librarians is to provide access to
information, not restrict it. Given the speed with which technology is
advancing and the kind of challenges that students face in the real world,
I think it is far preferable to open the floodgates to information for the
advanced students and assist those that need help, than to hold back bright
students for the sake of those that may be a little behind the curve. We
should be the last ones to put barriers in their path. One of the concerns
of the Transfer Network Steering Committee is the experience of students
that transfer from the UH Community Colleges to the baccalaureate campuses.
The Library can serve as a bridge between all campuses. Hawaii has been
behind the technological curve for so long I hope we don't miss an
opportunity to play catch up.
11. Helen Rogers from UH Hilo writes:
From the standpoint of a librarian from one of the outer island sites (Hilo), I'd like to express my reservations about the possibility of a shared database. Unless we can pre-set the defaults so that our students' searches are automatically limited to our holdings, I'm opposed to a shared database.
My main concern is what the patron will see when he/she enters a search in the public catalog--I'm very concerned that Endeavor can't seem to completely filter out the records of off-site libraries and that, in order to limit at all, our students will have to jump through hoops before each and every search.
When our students search for books, they want to see a list of books at our library--ones they can get right now. I'm extremely concerned about the possibility that our holdings will be "swamped" by records from the other sites. In the present Endeavor version, it is not possible to limit all types of searches (for instance, you can't limit author or subject searches). How am I supposed to tell our students that they will have to pick through the records of each and every library in the system to find the ones which have been specially purchased to support the programs at their institution?
Why should our students have to know a whole bunch of rules (how to limit; what kinds of searches can be limited and what kinds can't) just so they can see the books which have been purchased for them? This is an impediment to service, not an enhancement. The students who haven't been specially trained to limit their searches (or who are reluctant to wait for the limit screens to appear--I've waited 10 seconds for the limit screen to come up at some of the sites) will end up picking through the results of "monster searches" to find the material here.
I've been told that the new version of Endeavor (next year) will allow our library's materials to appear first on results lists. That will be an improvement, however, think about the implications of the different kinds of searches there are ... for instance, subject heading searches: Given the numerous subheadings available for each topic, our students will often see ONLY UH Manoa results when we have ample material here, only perhaps under the general subject heading or a related heading.
We are charged with the responsibility of building a collection adequate to meet the needs of the students in the UHH educational programs. When the students see the material at UH Manoa (so very much more of it, even though perhaps not at the right level, not available for interlibrary loan in some cases, etc.), we're going to have an instant credibility problem. Will we have outsourced our book collection? When I show the students the difference between the amount searches will retrieve here and in UH Manoa's catalog, I'm careful to explain why UHM has so much more than we have. I tell them that Manoa has more books (and they're available when students need more than we have) but we have the right books. When unsophisticated students perform a search on a shared catalog, they're going to be powerfully disillusioned to find out that they have quick access only to the books tagged "HILO."
I can see why librarians at UH Manoa might see a shared public catalog as an enhancement ... UH Manoa has the VAST majority of the material in the system. Adding the holdings of the other campuses will cause their students minor problems. Here in Hilo, where the vast majority of the holdings our students will see are hundreds of miles away (over water) the situation is quite different.
Ask yourself how hard is it for the distance learner to switch a search from one library to another. Not too hard is it? Is it hard for them to conceptualize? I never met a student who couldn't get the concept. For the times a student wishes to search the holdings of a remote library, it should be made convenient to do that. But why should it be IMPOSED on them?
12. Kevin Roddy, an instruction and public services librarian from UH
Hilo Library provides a number of interesting examples of potential problems
with shared databases:
I do not favor a shared online environment *unless* Voyager software can be programmed to allow a site to see only its bib and holdings records.
In a shared environment, sites with one or two copies of an item (either as bib records or holdings records) would be swamped by Manoa's (and sometimes Hilo's) bib and holdings records.
For example, Manoa holds 13 copies of "'Olelo No'eau;" Hilo/Kona has 17 copies, while Leeward has 3, and Kaua'i 2. Students on those campuses would be hard pressed to find holding within their own libraries quickly. How Endeavor sorts bib holdings is still a mystery to me, and the shared Endeavor sites that Wil has recommended don't display all of one library's bib or holdings records on the same screen. They are scattered, much the same way CARL scatters records in no chronological order if you search by NAME.
Let's look at another title: the "Statistical Abstract for the United States." Living with CARL for as long as I have has turned me into a fairly efficient keyword searcher; however; put "statistical abstract united states" into the Manoa database, and you are initially hit with 16 bib records. The peculiar nature of CARL has always placed this particular record on the last page. When I finally find it and display it, there are 6 copies at four different library locations at Manoa. Hilo pulls up the "Statistical Abstract of the United States" on the first screen, but we have 26 holdings records. Since this is a popular title, I would imagine all of the sites have multiple copies. Is this fair for any of us to have to slog through all of these in a shared environment to find OUR copy(ies)?
The titles I have chosen are definite "known" titles. But what if students (or librarians) want to survey the literature on a particular subject and use keywords? What if they happen to combine 2 or 3 monster words and get a lot of bib records to sort through, and then have to go through sorting holdings records? In a shared environment, this immediately turns into a epic sorting chore (and that's not just for students-that goes for librarians as well). And this could happen many many times in the course of a day.
I'm not only thinking of myself as a instruction and public services librarian. I've read the e-mails and the concerns some have about cataloging data quality, and the fact that some sites have far better cataloging than others. "Deduping" is still up in the air. How sites will poll the database to find existing records and decide on which to attach their own bib holdings is still up in the air. Cataloging is a fine art, and under-appreciated by many. Great care and skill is needed to maintain the integrity and quality of records. Unless substandard cataloging (and catalogers) are markedly improved within 3 1/2 months, providing a shared environment is just asking for trouble. One solution would be to centralize cataloging at Manoa to maintain database quality-but do we really want to go to a centralized cataloging environment?
With all due respect to the Distance Education librarians, I don't think Distance Education is a strong enough argument to go with a shared database. Distance Education is the latest educational bandwagon that the University has jumped on, but Campus Administration has put forth very little thought, direction, and resources to make a unified, UH System Distance Education Program one for which we can be proud. (I have some personal experience with Distance Education, because I am enrolled in an excellent DE program out of Chicago.) In Hilo over the years we have been subjected to a bizarre number of colored user cards, rules, etc. for very few distance learning students. I agree that something must be done to make it easier for Circulation Departments to share patron information, but there just aren't large numbers of DE students right now that would make information sharing unbearable. Some may argue that DE will grow exponentially in the coming years. Well, DE takes a lot of patience, perseverance, and discipline to complete. I don't see a lot of our students going in this direction real soon. At least for now, this is a clear-cut case where the needs of the many (students in traditional on-site live teacher settings) outweigh the needs of the few (DE learners) here.
The Distance Education Librarians are quoted:
"No doubt there will be *much confusion* (emphasis mine) if we adopt a common catalog but the good bibliographic instruction and reference service that we have always provided can overcome this."
They've got that right! But what about instruction in the classroom and at point of use? At first, I assumed that Voyager would be a more difficult to teach than CARL because of its power, and welcomed the challenge. However, until migration to Voyager 2000 (which Endeavor is selling as a magic cure for existing bugs and problems), are instruction and public services librarians alone going to be saddled with teaching the growing intricacies of extracting information from Voyager in the beginning months? If it comes down to a final decision to go shared, I would expect contributions of time on the Reference floor from everyone connected with the decision to go shared, including administrators. Everyone should put a few hours in to see the outcome of the decision. I reckon that some sites will be very, VERY busy at the PCs explaining Voyager's eccentricities. Individuals that are far-removed from instructional environments and reference floors should take nostalgic trips back to these places to see how it's going. Individuals that have not had recent experience with the day to day point of use instruction need to be reminded how students think and use the library.
Remember, though we are migrating to a new system, we aren't going to be married to it forever! Online systems are dynamic and changing. In three years, we may want to give Voyager the heave-ho because something better has come along. (We would do a disservice to our public if we ignored a better, cheaper system.) I agree with Paula Mochida that the perfect system isn't here yet. But let's not make a hasty decision now that could have serious ramifications until our next migration to a different system.
It seems to me that we have a lot of decision-making to do, and not much time. The deliberations on the "shared vs. separate" issue should have begun MONTHS ago. I agree with Paul Wermager that we seem to be pressed into a corner on this-3 1/2 months to do all we need to do to go live in July. Paul also seems to be concerned with database integrity and quality, and that is a major concern of mine as well. I am hoping that Endeavor personnel will be more responsive to our needs than CARL personnel. But from personal experience here in Hilo, it took us FOUR YEARS to get to our last upgrade that allowed us to search for items by subject. Many many delays and problems put off this upgrade. Can Endeavor *really* get us online in 3 months?
I reiterate-can Voyager software be programmed to default bib records and holdings to the site that polls this information from a shared database environment (this goes for both public services and cataloging/acquisitions? If this can be done (with 100% success), I would then agree to go with a shared environment. Let the Endeavor folks earn their keep and have their programmers work on this for us. I personally don't care if the records live together in one environment, as long as we can "separate them out" when searching and displaying records.
13. Larry Goldstein of Leeward Community College acknowledges the
potential impacts of a shared database:
Helen, I too want to thank you for saying so well and so convincingly what effect a shared database would have on service to students whose home libraries can serve them well. Not only would the immensity of Hamilton's collection swamp the others, but I don't see any real value in having the other libraries' small collections mixed in with my own library's collection. LCC students search our collection first. We then recommend they search UHWO, since that library is in our building. Then, if need be, we recommend Hamilton library's collection. Very often a student comes to the reference desk asking how to get books from Hamilton. Querying the student, I find that he did not search our own collection thoroughly. When I aid him in his search, I often find the books he needs and at the same time teach him how to search the collection.
14. Lisa Sepa from Maui Community College Library comments on a
message from Ralph Toyama at Leeward Community College:
I looked at this (see Ralph's message below); it still requires that patrons limit. Those of us that object to this limit issue want the limit to be preset. If a student at Maui searches the database, he should see only Maui items, without having to pre-limit his search. He can then go and expand the search if he wants to see what other colleges have. This is logical and would make sense to patrons.
----- Original Message -----
From: Ralph Toyama
Subject: Shared DB - Solution?
Looking at the Washington Research Library Consortium's ALADIN system (http://www.wrlc.org), which supposedly is running off a shared database, it seems that they've found a way to allow pre-selection of a particular library's catalog before the patron ever gets to a search interface. Once at the interface, and on the subsequent results list, the library's name is still shown on the screen.
I haven't played with it hard enough to find any hidden problems with this arrangement, so it might very well be doing something weird below the surface. But from what I've seen so far, it looks like it might be a workable solution.
Whether the libraries go shared or separate, we will need a structure for joint decisions. This will be especially crucial in a shared environment, where certain decisions have to be the same for all sites, but it will also be necessary in a separate environment, to insure some degree of consistency in PAC behavior, PAC display, etc. from library to library.
A feature called Virtual Web Hosting on the server will allow each library to configure its own Web PAC display, whether we are in a shared or separate configuration. Web PAC configuration files reside on the server in a unix environment. If a library decides to change the default configuration, they will request that the changes be made by UH Systems personnel. In Windows PAC, (which some libraries use as their staff PAC), the configuration files reside on the PC workstation. The Endeavor project manager recommends playing around with Windows PAC on a PC to make decisions about possible Web PAC configurations on the server. Changes made in Windows PAC are generally reversible. In Web PAC, (which is unix-based), if you delete a file, it is gone.
In a shared configuration, PAC search settings such as which tags are indexed for which searches, and how tags are weighted in keyword relevancy searching are the same for all libraries. In a separate configuration, different libraries can have different search settings. (Voyager comes with default set-ups for some of these PAC settings, so libraries have the option of initially accepting the default settings and seeing how they work and receiving user feedback before making changes.)
In a shared configuration, the default search is to search holdings at all libraries. If a patron wants to just search for books at one library, he has to limit his search by that location. There is no "Search this library only" button. At the orientation training, (which used Windows PAC, not Web PAC), you had to go down about 4 levels in the searching hierarchy to limit to location, which caused some concern. However, in checking out some of the sample catalogs, the site Endeavor refers to as Tri-U has moved the limiting button to a prominent point on its Web PAC with a message about using it to search one library, so the limit function doesn't have to be buried in Web PAC the way it is in Windows PAC. (UH does not plan to offer Windows PAC to the public. The Endeavor project manager recommended it be an option for staff.) In a separate configuration, the default search can be to search just one library, and simultaneous searching can be used to search multiple libraries.
In a shared configuration, you can either have a deduped database, (in which an effort was made to eliminate duplicate bib records and link holdings for different institutions to a single bib) or a non-deduped database (in which every bib record migrates and holdings remain linked to the same bib they were linked to in CARL). The Endeavor project manager indicated that the latter is not desirable.
In a deduped database, even if a patron limits a search to one institution, all holdings linked to a bib record will display, even it they don't belong to that institution. (In Voyager 99.1, the holdings display order is fixed, (alphabetical by location code). In Voyager 2000, if the system is able to associate the patron with a particular library, (via IP address or login), it will display holdings for that library before all others.) In a non-deduped database, if a patron limits to one institution, he will only see holdings for that institution linked to any retrieved bib records.
On the other hand, if a patron is interested in the availability of an item at more than one site, he need only look at the one record to which all holdings are linked in the deduped database, while he has to look at the bib record for each site in the non-deduped database.
Even with deduping, a shared database built from our catalogs will initially have some degree of duplicate bib records due to a lack of common matching points.
The Endeavor project manager recommends that decisions about PAC indexing be made by catalogers and reference/BI folk together. Catalogers have the knowledge of the database and its structure, reference/BI people know about patron searching behavior and information needs. In a separate database configuration, each library can set up its own PAC indexing parameters. In a shared database configuration, libraries have to agree on a single set of indexing parameters. (This should not be confused with catalog _display_ parameters, which can be customized by library with Virtual Web Hosting.)
Looking at the Washington Research Library Consortium's ALADIN system, which supposedly is running off a shared database, it seems that they've found a way to allow pre-selection of a particular library's catalog before the patron ever gets to a search interface. Once at the interface, and on the subsequent results list, the library's name is still shown on the screen.
In a shared database, there is one database name that displays in the catalog as the database being searched.
In a shared database, each library will have its own locations and OPAC display names.
- Differences between Manoa, Hilo, CCs in searching needs of users may be a justification for separate databases.
In shared and separate configurations, each library can configure its Serials and Acquisitions module to suit itself. However, in cases where code tables are shared, site identification keys should be included to distinguish one site's codes from another's.
No site can view another site's ledger unless permissions are set up to allow it as part of a library's policy groups.
Libraries can have their own Cataloging module configurations in both shared and separate configurations. However, in a shared configuration, tables of locations are shared so it is important to use codes that distinguish which elements belong to which site. In a separate configuration, libraries have separate tables.
In a separate configuration, every bib record in a library's CARL database migrates to its Voyager database. In a shared configuration with NO deduping, every bib record in a library's CARL database migrates to the shared Voyager database. In a shared configuration WITH deduping, most libraries can expect that some of their bib records won't migrate because they matched a bib record already in the file. These records end up in a dedupe file. Libraries can ask that certain tags (such as 505, 590) be merged from records in the dedupe file to matching records in the new database, but this adds time to the implementation process.
In a separate configuration and a shared configuration with NO deduping,
item specific information in the bib record will be relevant to the attached
holdings. It will be clear to which institution local notes apply. In a
shared configuration WITH deduping, multi-institution holdings linked to a
single bib will make it difficult to determine which item the item specific
information IN THE BIB RECORD describes. Likewise, it may be unclear to which
institution a local note applies. If libraries decide they want to continue
the practice of including item specific info or local notes in the bib, they
should consider prefacing the information with an institutional code, e.g.:
590 ^aLCC: Accompanying CD-ROM not available.
590 ^aWCC: Shelved behind Circulation Desk.
Libraries can opt to have item specific information moved to a holdings field during migration, but this is only possible if the information is in a bib tag only used for item specific information. Again, this option adds time to the implementation.
In a shared configuration, all libraries must agree if a particular tag is to be suppressed from public display. In a separate configuration, each library can make its own decisions on tag suppression.
In a shared configuration, a library can link holdings to a bib record already put in the database by another institution, rather than always having to create a bib record. Some coordination of effort is required, however, to avoid a lot of duplicate bibs, (assuming we aim for a deduped, shared database). In a separate configuration, libraries adding the same item have to duplicate effort to some degree, (although Z39.50 and Voyager-to-Voyager MARC transfer features make it easy to grab records).
In a shared configuration, libraries share a single authority file. If libraries are in a shared database, it is possible (but not guaranteed) that there will be sufficient room on the server to have an LCSH authority file loaded by UH Systems for the shared database. In a separate configuration, each library has its own authority file. There would only be room on the server for UH Manoa Library to have the LCSH authority file. It is not confirmed whether the Z39.50 or Voyager-to-Voyager MARC transfer functions work with authority records.
In a separate configuration, cataloging departments can take more risks and feel freer to experiment, because if things go wrong, they only hurt their own data. Likewise, they can assign bib data creation or maintenance jobs to whomever they choose. In a shared configuration, there will be pressure on cataloging departments to limit who can edit bib data, since the data is shared. A risk taken by one site has potential consequences for all sites. There might also have to be negotiation on what kind of edits or enhancements to bib records are acceptable to all sites.
It was pointed out that each institution had complete control over "their" bib and holding records to the extent that they could block all editing and deleting. The presenter said each institution could password protect these functions down to the level that only one individual could manipulate the data in any way, shape, or form. However, if several libraries use the same bib record, there has to be agreement on who can edit it, or if it is "owned" by one particular library.
In a shared database...
- Shared authority file is more difficult when there are a number of sources for authorities because there are no owning libraries
- Models for shared bib file: (1) single owning library, records deduped (local tags a problem); (2) multiple owning libraries, deduped; (3) multiple owning libraries, not deduped, MFHDs attached to individual owning libraries' bibs (need to add codes to identify ho owns local tags because ID numbers the same. (2) and (3) - importing overwrites owning library's own bibs, not other libraries' bib. In the latter two models, each library can own its own its own bib records.
- One authorization profile sheet to fill in
Libraries can have their own Circ module configurations in both shared and separate configurations. However, in a shared configuration, tables of locations, item types and patron groups are shared, so it is important to include keys to distinguish which elements belong to which site. For example, codes for Kapi`olani locations and patron groups start with KAP, codes for Kauai locations and patron groups start with KAU, codes for Leeward start with LCC, etc. In a separate configuration, each library has a separate table of codes.
In a shared configuration, all sites use the same patron database, and a patron's information need only be entered once for it to be available to all sites. In a separate configuration, each site has its own patron database and a patron's information has to be entered into the database at each site a patron uses. Trying to copy and paste patron info from another site's record usually takes more time than just keying it in.
In a shared configuration, the library system as a whole can behave like one single library from the patron's perspective. If patron placed holds are activated, a patron can place holds on books at more than one site. (Libraries can place limits on this by setting limiting policies for different patron groups even if holds are activated.) (The same holds true for patron placed recalls.) A patron can view all transactions at all sites simultaneously. In a separate configuration, the library system as a whole behaves like 9+ individual libraries. None of the aforementioned conveniences are supported in a separate configuration.
Common patron files. The other big question deals with sharing borrower information. This requires a common database at this time. This may not be important to islands where there is only one library, but it is of vital importance to Oahu libraries where we have students registered at one or more schools and borrowing material from many libraries. Like the database file, there is complete password protection of virtually all access and editing.
Money collected. In a shared configuration, money collected from fines and fees is initially put into a shared "pot." A subsequently run report, requiring special programming by Systems using SQL, identifies which money goes to which library. It is this structure that makes it possible for libraries to accept fines for other libraries, (should they decide to implement such a practice). In a separate database configuration, each library has its own money "pot" and a separate report is not necessary, but the system probably can't help in keeping track of fines accepted for other libraries, (should that practice be implemented). According to John Awakuni, Fiscal Officer of UH Manoa Library, the "one pot" aspect is not critical. Collection and transfer of monies at libraries is handled with UH paper forms, not the library management system. Given training, Systems can program reports using SQL software to report financial information by institution.
In a shared database...
- Need item types distinguished by site codes: MANBK, LAWBK, etc to distinguish types by site (CCs in their own combined database might decide to simplify to just BOOK, VIDEO, etc if can agree on loan periods).
- Single patron file (users can see all of their activity in one place; student can make transactions with any library in same database.
- Courtesy Discharge allows one library to check out/in another library's item, using the owning library's policy
- Circulation Matrix for each library
- Large number of item types combined with a large number of patron groups can result in a huge matrix and a great deal of set up work.
- Each library can have its own item types
- Each library can have different loan periods
- Shared patron database: patrons can see all loans/fees in all libraries
- Every library can have its own circulation calendar
- Patron blocks by specific library
- A library's matrix governs your patron groups and your item types with its own locations; matrix of owning library governs loan
- Can block one library specific patron type from borrowing from other libraries
- Separate databases means all of the OPAC and Web Catalog configuration files have to be done multiple times.
For standard reports, in shared and separate configurations, each library can download its own reports from the server and send them to print stations at its own site, if desired. Non-standard reports are a topic we will have to work out with the Systems Office.
In either a shared or separate configuration, the individual library determines what each operator can do in each module.
Access to security is across-the-board; would want to restrict access to System Administration to a small number of people in a shared database.
Every library can have its own policy group for each service point associated with its own locations (viewability is protected by security)
In a shared configuration, certain settings have to be the same for all libraries because there is a single System Administration module. Changing one of these system-wide settings has a broad impact. The libraries would have to decide who has the responsibility for maintaining these system-wide settings, e.g. Database Manager or UH Systems. In a separate configuration, each library can have a unique system configuration, (but since Voyager is a highly integrated system, caution should be used when making changes since they can affect multiple modules at a library).
There is one default address for the shared database (need to enter unique activity location addresses in each module configuration for reports and notices).
- Calendar for CCs would be about two weeks longer if choose separate databases; no significant impact on other calendars
- All sites in a shared database have to sign off on a load
A separate database configuration will take up more space on the server and make more demands on the server than a shared configuration. A separate database configuration will require more Systems involvement to coordinate activities such as server backups, upgrades and reports than a shared configuration.
In a shared database, a canned or batched report (such as overdues) is run for the whole database at one time and stored on the server waiting for a library to download it to a PC. Data for each library can be distinguished based on unique parameters such as policy groups. The report is printed by a library or department on a local printer. Very long reports, such as some of those for UH Manoa Library can be printed by Systems overnight. In a separate database configuration, a canned or batched report has to be run separately for each library. For the most part, this can be automated.
The downtime required for system upgrades will be longer in a separate database configuration than in a shared configuration because the files for each database have to be updated separately. Minimum downtime for an upgrade is about 2 days.
|
Merged Databases - Pro |
Merged Databases - Con |
|
Separate Databases - Pro |
Separate Databases - Con |
|
Single source for shared bib info |
*De-duping problems; long term cleanup requirement |
|
No one has to change their bib records |
Dirty data doesn’t get cleaned up |
|
Single authority file shared by all; could share workload of maintenance |
*Authority control—who’s responsible? Manoa can’t do all; some sites can’t do their own |
|
Everyone does their own authority work—responsibilities clear cut |
Not as easy to share headings |
|
*Single patron file |
Problems with agreement about patron types |
|
Universal Patron capability in next 5 years will make sep files seem like single file to patrons |
No ability to borrow across sites |
|
Shared collection development potential |
Manoa’s research collection is different than CC’s |
|
Ability to maintain uniqueness of each library |
*Duplication and difficulties in sharing resources |
|
Can see other libraries notes |
Enormous non-hierarchical notes field |
|
*Notes are unique to the individual library |
Harder to share info on similar problems |
|
Cooperation |
*Unenforceable rules |
|
Independence |
Not fostering single-system idea |
|
Chance to work together as single system |
*Need for governing board to make decisions re: authority control, vendor file, patron file |
|
No need to set up elaborate, time-consuming system wide decision-making body |
" " |
|
New era of sharing |
*No infrastructure to determine policies about sharing |
|
No need to share, but still can on a smaller scale |
Lose the advantages of sharing |
|
Data for all to see |
Data for all to see, but some data is only relevant to one site |
|
*Data clarity of each site being separate |
" " |
|
*Decision made once & for all |
Can’t decide to split later |
|
Could decide to merge later |
Not very likely |
|
*Shared database with Law worked OK before on CARL |
Splitting off Law was messy when we did it later |
|
Law has no responsibility to Manoa |
Class K books missing from Manoa |
|
Opportunity for consortial purchasing arrangements |
*Many electronic resources accessible only to Manoa |
|
Can set up license agreements without consulting others |
May miss some opportunities for enhanced access |
|
May offer potential for shared contracts with materials, bindery vendors |
Difficult to work out details of these agreements, or change them later |
|
Ability to negotiate contracts independently |
*May miss some opportunities for cost savings or service advantages |
|
Ability to create more consistent standards in cataloging |
Manoa’s non-conformance to serials cataloging standards (latest entries) |
|
*Everyone can do their own thing; no question of trust of others’ quality |
Harder to share |
|
*Seems to take the long term view—10 years from now, when we are no longer with Voyager |
Difficulties in implementing now |
|
Easiest path |
May be too conservative |
|
*Great benefit to CC’s, who will use Manoa resources |
Manoa researchers won’t benefit from seeing CC holdings |
|
Manoa library is for Manoa users |
CC’s may have some items we don’t |
|
*Ability to share resources; advantage to distance ed. |
Extra workload for all, to share resources |
|
Can share, but don’t have to |
Not encouraged to share |
|
" |
*Manoa will take on the major workload of sharing with CC’s |
|
" |
|
|
*Statewide tool |
Manoa-specific needs |
|
Each institution has a unique mission |
Cooperation between campuses is part of mission |
|
*One stop shopping for patrons |
Recording Manoa’s call number when looking for books at another library |
|
The titles retrieved are for the library the patron is in |
Not as easy to see other libraries’ holdings |
|
All holdings in one place |
*Patron scrolling through list of all multiple locations |
|
Holdings unique to one site unless additional ones chosen |
" |
|
Single bib record for all copies |
Library specific codes |
|
*Info in records is specific to single site |
Separate bib records for sep sites |
|
*Single database to maintain |
Sharing dirty records |
|
Records specific to single site |
Workload impact for Systems; space requirements of server; cost |
|
*More eyes to look at and correct errors in records |
Uncertainty about who can fix records |
|
Clear responsibility for own records |
No help from other sites |
|
Relief of having this important decision made |
*Difficult to make important decisions by deadline |
|
Simplest decision to make |
Difficult for Systems to do by deadline |
|
TOTAL * = 10 |
9 |
|
4 |
2 |
Editor's opinion - We will make the right decision based on what is best for the students and faculty users of our libraries. As professionals we have to weigh the pros and cons. There are issues and we all know that much work will have to be done to make either a shared or separate decision work well for users and staff. Based on what I have heard and read, I believe we should take a system-wide perspective in making the decision. Although each campus may or may not have a current need to serve users beyond its own campus, we never know what the future will bring, except change. I believe that a system-wide perspective will serve the University best in the long run. Does a system-wide perspective mean a single database shared by all UH campus libraries?
In the end, I expect it is up the head librarians and University administrators to make the decision.
Content provided by: Eric Flower, Larry Goldstein, Ramona Kincaid,
Paula Mochida, Kevin Roddy, Helen Rogers, Michelle Sturges, Ralph Toyama, Paul
Wermager, Roberta Winjum and Wil Frost. Edited by Wil Frost.
Comments to Wil Frost, Head, Library Information Technology Division, University of Hawai'i at Manoa Library, 2550 The Mall, Honolulu, Hawaii 96822 USA. Last modified: March 21, 2000.