[207] in ad-lib
B.Index questions to discuss at meeting Thursday
daemon@ATHENA.MIT.EDU (sbyrd@MIT.EDU)
Wed Mar 22 18:17:36 1995
From: sbyrd@MIT.EDU
To: ad-cat@MIT.EDU
Date: Wed, 22 Mar 1995 18:17:12 EST
B.Index, Part 2
Questions, questions, questions!! For discussion at Ad-cat, 3/23
1. Update/more questions than answers about this daggone series
numbering issue:
To summarize where we are so far, we suggested 2 ways to deal with
indexing volume numbering:
1. index subfield v only, with dcode=N, in Note Words index.
2. set up separate layer for entire series field including
subfield v, and index that second layer as T, as an uncontrolled title
search.
Geac comments on #1: Miriam Blake: Geac's "leery" about doing
this. Grant: lt's talk to Matt about it. Me: We need to pin MR
down
on this. I still feel this is the best solution. I don't think it'll
gum up
word index that much, and besides, we have a big machine; we can
handle it.
Geac comments on #2: MR: "may be the most workable solution",
altho we would have to live with unclever sorting of the
volumes--well,
that's what we have now in Glis. Still better than the modify search
option with its "imprecise matching" that to me is totally
unacceptable. Besides, sorting isn't as much an issue as retrieval
is;
users often come in with a specific citation to a specific volume, and
it is these users that we are addressing here.
So: Method 1:
pros: 1. users could in a single search, up front, get right
to
a specific volume. w = lectures chemistry 13
2. easy to achieve: simply change b.index by
adding v with dcode=N to the following fields: 440, 400, 410, 411,
800, 810, 811, 830, 840.
cons: 1. Geac seems to feel this could gum up the word
index with extraneous data. {convince me that this is so. Patrons
usually don't do keyword searches on "v" or "vol" or a number, do
they??}
Method 2:
pros: 1. users could get to a specific series volume with a
single search-- t = lectures chemistry 13
cons: 1. that search would not be subject to authority
control, since the subfield v and the subfield a of the series would
both be indexed together as dcode = T alone, without the M. With
Method 1, the subfield a portion of the series would come from the
authority-controlled index whereas the v would come from the N note
words index.
2. It seems to me that this method would require
more fancy, involved changes to the B.index than Method 1 would. A
whole second layer of indexes would have to be added to 440, 400,
410, 4211, 800, 810, 811, 830, and 840.
We need to discuss this and see where we are on this. Obviously, I
personally think it's an important issue, important enough to pursue
in an agressive way. Why? Because whatever we decide here has
implications not only for the Advance product we're testing now, but
for the Geopac and for the new client-server co-development thing.
And dammit, a system should be able to do this!
2. The other, related but separate, issue of all series being
searchable as titles:
This has now been accomplished via the opac set-up, by adding P to
dcode for title and title word searches. Unfortunately, we can't fix
other things like the series volume thing until the groundwork is laid
for them in B.Index. But the fact that we could make series
searchable as titles via opac set-up is pretty cool. BUT this change
is only done for the Advance product. This change does NOT work
in Geopac. Which leads to a bigger issue:
3. Just what does the B.Index control, anyway? If it controls
Advance AND Geopac AND presumably (in the future) the new
product, then whatever fixes we make need to be done to B.Index. If
not, how do we make indexing changes for the Geopac?
I'm working on an exhaustive list of changes that need to be made to
the B.Index. How crucial is this list? Why do I have a headache
now?
4. Uniform titles 130 and 730.
B.Index: dcode = 4MP [4=uniform title, P=series,
M=subject to authority control]
Brushing aside for a minute the fact that I still don't understand how
4, 5, and 6 play into the dcode values [1,2,and 3 dictate different
types of author searches, but 4,5,and 6 don't seem to], we see that
130 and 730 are not searchable as titles, so we change the title and
title word dcode values in opac set-up to include P. Great. Now 130
and 730 are searchable as titles.
Problem: when you do a title search, browse or keyword, the system
displays in parentheses the index used to retrieve each record.
for example: the search "t=atlantic monthly" gets among other
things, this:
4. The Atlantic monthly (Title)
3
5. Atlantic monthly (Boston, Mass. : 1857) (Series) 1
6. Atlantic monthly (Boston, Mass. : 1971) (Series) 1
7. Atlantic monthly (Boston, Mass. : 1993) (Series)
1
8. The Atlantic nations in the 1990s : implications (Title)
1
for United States policy
The 130 is displayed as a Series, not as a Title the way it should
be.
Why? Because its dcode value in B.index is P, not T. So even
though our opac fix solved the searching/retrieval problem, it's still
misleading to the patron to call 130s and 730s series. They're not.
They're uniform titles.
Solution?: In B.Index, CHANGE 130 and 730 dcode value from P to
T.
Implications: is the P important here because of authority control?
In the authority record, uniform titles are coded as 130s. Bib 130,
730, 440, 830 = Auth. 130. Is it the P that determines that it's
subject to authority control, or is it the M alone? What about the 4?
If we change 130 dcode P to T, what does that do? can MR explain
all this to us? Obviously Miriam didn't. Of course the more I work
with B.Index the more questions I have.
If we can't change P to T because of its connection to authority
control, are we stuck with 130 and 730s displaying as "series" in
search displays?
What can we live with? How will what we do now affect us down the
road?
4,. Why aren't 400, 410, 411 subfield t treated in same way in
B.Index as 800, 810, 811 subfield t?
5. More to come!! I have many more questions, but I wanted to get
this out now, so y'all can read it before our meeting Thursday.
dcode=go home now,
Sam
