[477] in Public-Access_Computer_Systems_Forum
OPAC Functionality
daemon@ATHENA.MIT.EDU (Public-Access Computer Systems For)
Thu Jun 11 12:13:42 1992
Date: Thu, 11 Jun 1992 10:54: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>
2 Messages, 113 Lines
*-----
From: johnsonm@ohsu.EDU (Millard Johnson)
Subject: Re: Library Automation--Comments and Questions
Charles Hildreth asks what features should be in the next-
generation on-line catalog. I have several thoughts but here I will
discuss only USER RESPONSIVENESS.
The design feature I propose is that the system should
personalized itself to each individual users preferences and it
should be responsive to the users particular needs.
We spend an enormous resource indexing millions of
"publications" but we spend almost nothing indexing the USERS
of the publications. This forces the library to be almost totally
passive in the information exchange in an environment where
computers allow libraries to be responsive, and it ignores a big
part of the fundamental function of the library which is -- to get
the user in contact with the information he/she needs. The next
generation system needs a subject index the patron file. The first
screen on the system should ask:
Who are you? >
If the user chooses to be anonymous, he/she gets traditional
PASSIVE catalog access, but if the user chooses to identify
him/herself, he/she gets a system that has LEARNED to tailor
itself to his/her preferences.
Preferences include:
command Vs menu Vs window interface
key word Vs authority searching
context-sensitive Vs prompted Vs no on-line help
access to fee-based Vs free-only databases.
Lots more stuff is possible in a system that teaches itself the
preferences of the user. Think about it.
It is not really that difficult for academic libraries to index their
users. We don't have to start from scratch. We know what users
have read in the past and what they have published. We know
which authors they have read and collaborated with, whom they
have cited and who has cited them. We can use that information
to generate pretty good profiles. With that information, and what
we add, we can be an ACTIVE service. We can send users a list
of new books received by the library that are likely to be of
interest and a bibliography of papers published by authors of
interest. We can even put them in contact with other users with
similar interests.
A side benefit is that we can use the user subject profiles in the
selection process.
KEY POINTS --
1. System designers have to start thinking of an interface that
adapts itself to the interest and preferences of each user.
2. The system has to learn the users preferences and it has to
keep up with his interests.
KEY CAUTION --
The system is not a computer program. It is a SYSTEM of
software, hardware, information resources and PROFESSIONAL
LIBRARIANS. The inherent utility of each component should be
designed into the system.
I would rather risk failure than achieve it without risk.
Millard Johnson, PORTALS
johnsonm@ohsu.edu
*-----
From: <JANET@HUJIVMS>
Subject: Accounting
I would like to open up a discussion on the kinds of system
accounting/monitoring that are useful for OPAC managers.
What are the kinds of things that we want to ask our systems
people to tabulate for us?
Our OPAC runs on a VAX, and therefore we can take advantage
of the VAX system monitors, which take many different measures
of the computer's operation. The monitors run on-line, however,
and extra routines will have to be written to analyze the
huge amounts of information that they generate.
Our OPAC system also has the capacity to log all operations
performed at a terminal, and all responses given by the computer.
But it doesn't analyze this information for us in any useful
manner - just gives us screen after screen of saved operations.
I have been asked to present specifications for additional
programs which will analyze the information given to us both
by our OPAC and by our system, in order to answer the following
questions:
Which terminals in which libraries are being used most heavily?
Which operations most heavily tax different "areas" of the
computer (I/O; memory; CPU); and which of the terminals
are "responsible" for heavy use of these areas.
These questions are being asked in an effort to come to some
kind of equitable distribution of terminals in different libraries
and areas of the campus, where budget considerations are foremost.
Have any pacs-l participants been faced with these questions?
Have your systems people been able to help you answer them?
Have your OPAC vendors been able to help you answer them?
Do any of you know of ready-made software for the VAX that can
help us?
Janet Lefkovitz
Automation and Development
Mt Scopus Library, Hebrew University,
Jerusalem
Bitnet: janet@hujivms
Internet: janet@vax.huji.ac.il
