[407] in Public-Access_Computer_Systems_Forum
Future of Automation
daemon@ATHENA.MIT.EDU (Public-Access Computer Systems For)
Wed Jun 3 12:14:23 1992
Date: Wed, 3 Jun 1992 11:09:13 CDT
Reply-To: Public-Access Computer Systems Forum <PACS-L%UHUPVM1.BITNET@RICEVM1.RICE.EDU>
From: Public-Access Computer Systems Forum <LIBPACS%UHUPVM1.BITNET@RICEVM1.RICE.EDU>
To: Multiple recipients of list PACS-L <PACS-L%UHUPVM1.BITNET@RICEVM1.RICE.EDU>
5 Messages, 168 Lines
*-----
From: "Ethelle S. Bean" <ETHELLE@SDNET>
Subject: Re: Future of Automation
Re: Back to basics and library automation. I would say that our experience
is more of a movement toward becoming a "just-in-time" library. We are
shifting budget resources to support a reference collection fine-tuned to
meet our curriculum needs; purchasing CD-ROM-based indexes that are curriculum
appropriate and fine-tuning the periodical holdings (via useage statistics)
ruthlessly dropping unused titles in favor of requested titles (ILL requests,
etc.); adding services like FirstSearch and training faculty and students to
access them via the Internet; proactively reaching out to our faculty and admin
to spread the gospel of Info Literacy and showing them how using the library
actually helps them cover more subject material in a class. We are also expand-
ing ILL to include document delivery to services like UMI and Faxon. We are
part of the South Dakota Library Network (SDLN), which has catalog, circ-
ulation, serials, acqusistions, and ILL, all integrated. Our budget is finite.
Automation costs money. By trying to become a "just-in-time" library we are
shifting from the "library as warehouse" mode. And even as we shift, we are
concerned about the long term costs, not dollar costs but access costs.
As someone recently mentioned, what happens in the future when only three
libraries hold an item and they are unable or unwilling to share? What happens
when serials holdings are concentrated in the hands of a few vendors? I don't
know the answers but I don't really see any other option for a small academic
than to move in the direction of "information - just in time" either.
Ethelle S. Bean, Director of the Library, Karl E. Mundt Library
Dakota State University, Madison SD 57042-1799
phone: 605-256-5203 Fax: 605-256-5208 Bitnet: ETHELLE@SDNET
*-----
From: <BUNTON@UTSW>
Subject: RE: Future of Automation
A very provocative question regarding libraries downsizing and going
"back to basics". My personal opinion is that the idea of getting down
to basics may very well be true but the "basics" have changed in our
society and part of the basics assume automation. Particularly in
environments such as my own (an academic medical center community), the
type of information needed, the immediacy of its need, and the
interpretation and manipulation of such information all lead us further
away from "printed" text. I do believe information centers will need to
be selective and discerning in the automation they appropriate, making sure
it fits their need and solves the problems of their environment rather than
just purchasing anything that looks great but I can't see us reverting back
to a previous society.
Glenn Bunton
Head, Educational Technology Laboratory
UT Southwestern Medical Center
bitnet: bunton@utsw
*-----
From: johnsonm@ohsu.EDU (Millard Johnson)
Subject: future of automation
I have been away from PACS-L for a while and return to it from the
new perspective of an employee of a consortium of research libraries
in a state facing SEVER cuts in library services due to a tax payers
revolt. From my new perspective, the issue of the future of
automation in libraries is more than theoretical interest.
How does an institution propose to operate in the face of double digit
cuts in funding and double digit increases in the cost of material? We
could, of course, go back below basics, but that strategy is best
described as "head in the sand" librarianship. It solves nothing, only
hands the problem to more creative problem solvers.
In the past, the benefits of library automation have been to decrease
personnel intensive operations (cataloging), increase accuracy
(circulation), and cultivate more intensively the library's collection
(OPAC).
I believe we are now in need of a paradigm shift from ownership of
information to access to it. We ARE going to buy less and less of
what is "published" -- we have no choice. We ARE going to be able
to browse what we do not own. It is not all that difficult to deliver
information electronically. What we need is a change in concept of
what the library is.
Suppose a library collected intensively in a small subject domain and
purchased nothing else -- until someone asked for it, but when asked,
the library purchased every item requested or paid the full market cost
for 24 hour document delivery. How would the user feel about 24
hour service from the equivalent of the library of congress? Would
publishers rise to the increased demand for on-demand publication?
What would it do to the relevance of the local collection? What would
be the impact on the budget? I don't know either but I believe that
conventional library functioning is a reflection of pre-electronic
information technology.
An interesting question is who could change the current system.
Librarians could, but there is a mighty risk and a strong professional
identity to change. Automation vendors cant. The issue is philosophy
not technology and automation companies are not in the game.
Copyright holders (publishers) have the most to gain and the most to
lose.
"I would rather risk failure than achieve it without risk."
Millard Johnson johnsonm@ohsu.edu
*-----
From: James A. Nauer <jan3@po.cwru.edu>
Subject: Re: Future of Automation
>Unfortunately, the OPAC vendors are not going to see a lot of this
>money, unless they radically change their product line. OPACS are going
>the SPELLING CHECKER way. ie. the function is still needed, but no one
>wants to buy a stand alone spell checker anymore, it must come as a part
>of a word-processor. Similarlily, an OPAC will have to be packaged as a
Please, NO! Let's consider where the PC (all PC's, not just DOS machines)
software industry is headed--not where it's at right now. Currently, we
see raging featuritis in most word processors: spell checking, thesaurus,
grammar checking, table editing, graphics, equation editing all in one
program. When one w.p. package tries to do all of these functions, some of
them invariable turn out to be very weak implementations. Take the MS Word
spell checker (please! I hate it!). I would dearly love to throw it away
and use the MacWrite II spell checker in its place. Fortunately, after all
the years of adding features to programs, this is exactly where PC
operating systems and applications are headed (OLE/DDE under Windows 3.x
and AppleEvents/Publish&Subscribe under Mac System 7). Already, I can
get rid of the yucky graphics module in Word 5.0, and use Canvas instead.
Now if only the spell checker was an external module...
So...what does this have to do with ILS's? Everything. ILS's should
be every bit as modular as PC software is (slowly) becoming. We should
be able to replace the vt100 (or 3270) based interface with X Windows.
Add access to services running on other systems--say, a full-text search
& retrieval module that access a WAIS server, or an image-display
module that uses a search/retrieve engine running on a mainframe on the
other side of campus.
I agree completely that ILS's will need to do much more that the "usual
OPAC stuff," but I think that expecting any ILS vendor (or in-house
development team) to do *everything* in one monster, killer OPAC is un-
realistic. The best path I can see, in the long run, is a modular
system capable of accessing services from other vendors, running on
other machines.
Jim Nauer jan3@po.cwru.edu | "I need a vacation."
Library Information Technologies|
Facilities Manager | --The Terminator
Case Western Reserve University |
(216) 368-MACS |
#include <std_disclaimer.h> | -=| Save a tree . . . send e-mail |=-
*-----
From: JUDYK@LIB.TECHNION.AC.IL
Subject: RE: Future of Automation
My two cents' worth to Bernie's question: depends what "downsizing"
means. I don't see a library with a system that costs $50,000 a year
plus 150 terminals throwing it out and buying a new one that costs
only 30,000 a year and cutting 50 terminals! I do see such a library
deciding not to *add* terminals or delaying the *upgrading* of
its software. For that library, this is not "downsizing" but simply
staying in the same place; but obviously if enough libraries make
that decision it will result in a contraction of the market as a
whole, relative to what it was expected to have been.
Anyone out there seriously envisaging going back to manual methods,
because of the size of the acquisitions budget...? :-)
| Judy Koren, |
| Head, Technical Services |
| The Technion -- Israel Institute of Technology |
| Haifa, Israel. |
| |
| Email: judyk@lib.technion.ac.il |
| or: lbjudy@vmsa.technion.ac.il |
