Email list hosting service & mailing list manager


Indexing linking fields (Frieda Rosenberg) Marcia Tuttle 19 Feb 1993 08:16 UTC

It is time for me to send my promised summary to serialst reporting on
the results of my previous query concerning the indexing of serials
linking fields in online catalogs.  My two questions were as follows:
--Has any library made a conscious decision to use (or not) linking
fields as access points in the online catalog? If so which ones and why?
Are you happy with the decision?`
--Has anyone devised a way to use the control numbers in linking fields
in some other way to improve access to serial records? Is any processing
recommended for these so that they can be manipulated in some future,
more sophisticated environment?

Before I provide a summary, I must confess I do so rather sadly, because
the decision my campus (UNC-Chapel Hill) arrived at was the one our main
library strongly opposed, which was that all the linking fields proposed
by anyone for indexing in our brand-new system (762, 770, 772, 773, 780,
785, and 787) be indexed.  My sheaves of printouts from serialst, most
favoring minimal or no linking entry indexing, brought to the committee
deciding such matters (of which I am not a member) were of no avail.
Our medical library, joined by our special collections cataloger and one
of our law librarians, carried the day.  I am going to give some
background because it is clear from the responses that our experiences
would be useful to some others.

My initial confession that our serials cataloging unit is actually
deleting linking fields in order not to have them cluttering our
retrieval may have been an unfortunate distraction from the real
question. I heartily agreed with all the respondents who urged the
benefits of these fields per se, and I answered some of them personally,
explaining that if only these fields were left unindexed, we would
happily retain them all!
The question is this: If we own __College & research libraries__ and
__College & research libraries news, do we want the reader searching the
title "college & research libraries" to see a screen that reads

     College & research libraries
     College & research libraries news

or a screen that reads

     College & research libraries
     College & research libraries news
     College & research libraries news
     College & research libraries        ?

On the other hand, if we didn't own the C.r.l. news, would we want the
screen to read

     College & research libraries
     College & research libraries news

or simply, College & research libraries?

(Another suggested solution, displaying the 245 and not the 772, would
give, in the second case, two entries reading College & research
libraries, retrieving the same record.

(The keyword user would have even more fun, since on keying in college
research libraries, he or she would retrieve also the same titles with the
addition of variants with __and__ instead of ampersand; a question for
another day!

Our argument was that anyone wishing to let users retrieve  extra titles
has an entirely legitimate option of doing so by means of entering added
entry fields for them, in this case, 730's.   This procedure, in the
imperfect world of information retrieval, gives catalogers a choice
instead of tying their hands.  (Some of our committee members disliked
the extra work; others treated removing any possibilities like some
ultimate cataloging sin.)  Probably the most ultimate of the ultimate sins
was the prospect of giving the searcher of the unowned College & research
libraries news no retrieval at all--which need not happen, of course, if
one provides the 730 for it, too, on its parent record.

Former titles and later titles were a little more knotty, since there is
no real precedent for using added entry fields for these--is there?  Our
new system, and at least one other system mentioned by respondents, has
a "related works" function which does index those titles, and the user
is prompted to enter a command to retrieve them as soon as a record is
displayed.  We favored relying on this function because users __can__
learn to use it, and it had the virtue of showing on the index screen
the very title that would be displayed.  Again, the prospect of null
retrieval if a title was not owned was chilling to some; but we thought
clearer information in 90% of cases outweighed the dangers of giving no
information in 10% of cases at most--when information might only
mislead, anyway.   We had a lot of dismissing of my examples as "worst-
case scenarios", but one need think only of Atlantic/Atlantic
monthly/Atlantic monthly magazine, or Saturday review in its various
epochs, or newspapers with their changing regional editions, scientific
journals with changing sections-- hundreds of others that anyone out
there could name as well as I.  Country reports, right?

I urge serials and systems people, and vendors, to give this matter some
thought.  What would be a genuine system solution to this problem?  One
message suggested that an indicator be provided for the cataloger's
decision to make an added entry or not.  What about suppressing display of
the same record more than once on the same screen, from any access point?

Now to the summary to Question 1:  I received 10 responses to my
question; 11 and 12 also answered another question from SUNY-Syracuse.

1. Yes, as related works only--happy (Universite de Montreal)
2. 765, 767, 780, 785, and happy (Occidental College)
3. None, and happy (University of Kentucky)
4. None, and happy (Yale Divinity School)
5. None, and happy (University of Victoria, B.C.)
6. Yes, but not happy; displays title retrieved instead of linking entry
   on index screen, which improves somewhat (Santa Clara University)
7. Especially likes 773, 780-785; but only if much programming is
   done to improve display--displays title retrieved, not linking field;
   system enables making added entries for other fields (Lakehead
   University, Ont.)
8. All, but would prefer only 780-785 (Hamilton College)
9. All, and happy because of collocation benefits (University of Chicago)
10. Previous and later title, considers this important because it
    provides link between titles shelved alphabetically (SUNY-Syracuse)
11. Agreed with this, but restricted to 780-785 (Lakehead Univ.)
12. Agreed also (San Francisco State) but noted that reference
   librarians objected to retrieving a title they did not key in.

Question 2 excited some interest, but the only positive response was from
Lakehead University; Lynn Barber, correct me if I'm wrong--MultiLis checks
the control number within a linking entry against the database to see if
the linked title is held before displaying it in the index.  MultiLis is
also willing to pursue other modes of serials access from these fields.

Thanks so much to all who responded!

Frieda Rosenberg
Serials Cataloging
University of North Carolina at Chapel Hill
FRIEDAR@UNC.BITNET   Phone: 919-962-2050