[378] in ad-lib
B.Index questions for meeting today
daemon@ATHENA.MIT.EDU (sbyrd@MIT.EDU)
Thu Apr 20 11:38:28 1995
From: sbyrd@MIT.EDU
To: ad-cat@MIT.EDU
Date: Thu, 20 Apr 1995 11:37:23 EDT
(I will distribute print copies of this as well---Sam)
Recommended changes to B.Index Rev. 950419
from Ad-Cat
Types of changes:
I. Changes to existing fields already in B.Index
II. Additions -- New fields to add to B.Index
III. Deletions -- Fields to delete from B.Index
IV. Possible problems, discussion modules, nagging nodelets
I. Changes to existing fields
1. 130 should index as title.
Change dcode P to T
OR add dcode T [preferable]
*Does P need to be there for auth. control
purposes? See discussion of this issue in my
B.Index questions e-mail of 950322.
[Fixed in OSI, but with attendant problem of displaying as
"Series" in search display, which we may be able to fix by
deleting that parenthetical display altogether]
2. 246 /i should not index.
Add "i" to PASS column.
3. 246 BIND : indicator 1 value 3 should be indexed in addition to
value 1.
should be: @, M1 OR 3 [don't know exactly how this
should look]
4. 400 /t should index separately as title.
400 should be consistent with 800 AFTER 800 is
fixed (see below).
Add second layer for /t that is consistent with 800.
Change dcode to 1AMPX (add X to indicate 2nd
layer).
[Fixed in OSI, sorta]
5. 410 /t should index separately as title.
410 should be consistent with 810 AFTER 810 is
fixed (see below).
Add second layer for /t that is consistent with 810.
Change dcode to 2AMPX (add X to indicate 2nd
layer).
[Fixed in OSI, sorta]
6. 411 /t should index separately as title.
411 should be consistent with 811 AFTER 811 is
fixed (see below).
Add second layer for /t that is consistent with 811.
Change dcode to 3AMPX (add X to indicate 2nd
layer).
[Fixed in OSI, sorta]
7. 440 should index as title as well as series.
Add dcode T?
[Fixed in OSI]
8. 600 /t should NOT be separately indexed as a title.
Delete 2nd layer of /n,p,s,t from 600
Change 600 dcode to 1MS (X no longer
neccesary if 600 only indexed once, correct?)
In other words, treatment of 600 should be
consistent with treatment of 610 and 611.
9. 700 --remove all title-related subfields from the first layer
(dcode = 1AMX), but keep in second layer (dcode = T)
remove these subfields (in Valid column) from 1st layer:
f,h,k,l,m,n,o,p,q,r,s,t
10. 710 --remove all title-related subfields from the first layer
(dcode = 2AMX), but keep in second layer (dcode = T)
remove these subfields (in Valid column) from 1st layer:
f,h,k,l,m,n,o,p,r,s,t
11. 711 --remove all title-related subfields from the first layer
(dcode = 3AMX), but keep in second layer (dcode = T)
remove these subfields (in Valid column) from 1st layer:
f,h,k,l,m,n,o,p,q,r,s,t
12. 711 dcode value should be 3AMX, not just 3AM, to indicate
2nd layer of index for /t (as done for 700 and 710).
13. 711 /t T index should include other title-specific subfields in
2nd layer index (like /n, /p, etc.) as done for 700 /t
and 710 /t.
--add these subfields (in Valid column) to 2nd layer:
f,k,l,n,p,s,t
14. 730 /h should not index.
Delete /h from Valid column.
15. 730 should index as title.
Change dcode P to T
OR add dcode T [preferable]
*Does P need to be there for auth. control
purposes? See discussion of this issue in my
B.Index questions e-mail of 950322.
[Fixed in OSI, but with attendant problem of displaying as
"Series" in search display, which we may be able to fix by
deleting that parenthetical display altogether]
16. 800 /t should index as title as well as series.
Add dcode T?
[Fixed in OSI]
19. 810 /t should index as title as well as series.
Add dcode T?
[Fixed in OSI]
20. 811 /t should index as title as well as series.
Add dcode T?
[Fixed in OSI]
21. 830 should index as title as well as series.
Add dcode T?
[Fixed in OSI]
22. 840 should index as title as well as series.
Add dcode T?
[Fixed in OSI]
II. Additions -- New fields to add to B.Index
1. Add 027
Files = PUBNUM
2. Add 074
Files = PUBNUM
3. Add 088
Files = PUBNUM
4. Add 490 w/first indicator = 0 ONLY
(BIND for 1st indicator = M0?)
Prep = NOTE, Files = WORDS, dcode = N
5. Add 260 subfields b, f ONLY
Valid = b,f Prep = NOTE, Files = WORDS
dcode = N
6. For the following notes to be added, Prep = NOTE,
Files = WORDS, dcode = N
500 general note
501 "with" note
503 bibliographic history note
504 bibliography note
506 restrictions on access
507 scale note for graphic material
508 creation/production credits
511 participant/performer note
513 type of report and period covered
515 numbering peculiarities
518 date/time and place of event
520 summary
521 target audience
522 geographic coverage
523 time period of content
525 supplement note
530 additional physical form available
533 reproduction note
534 original version note
536 funding information note
537 source of data
538 system details
545 biographical or historical note
546 language note
547 formal title complexity note
550 issuing body
555 cumulative index/finding aids
556 information about documentation
561 provenance note
580 linking entry complexity note
581 publications about described materials note
586 awards note
590 local note
7. Add 780 /t Files = A.TREE Dcode = T
8. Add 785 /t Files = A.TREE Dcode = T
III. Deletions -- Fields to delete from B.Index
1. Delete 870
2. Delete 871
3. Delete 872
4. Delete 873
IV. Possible problems
1. 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. Add numbering terms to stopword list.
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??} [Plus: add to WORDS stopword list (or whatever it's
called): vol., v., no.]
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.
2. Questions from Walter's e-mail
3. 780 should be indexed.
Not in B.Index at all. In Marcive index as Author.
Should /t be indexed as title? Or what?
Should /a be under authority control?
(implications of ........)
4. 785 should be indexed.
Not in B.Index at all. In Marcive index as Author.
Should /t be indexed as title? Or what?
Should /a be under authority control?
(implications of....)
