Apostrophes (')
Normalization in VICTOR vs. VICTORWeb
--Apostrophes in searches
(1999-02-15)
VICTOR follows CARL normalization rules for apostrophes
for all type searches, VICTORWeb follows those rules for
all searches except name browse search and subject browse
search.
Regarding VICTORWeb userreport problem #69: Normalization
problem Names: apostrophes
This problem applies only to //nb/ & //sb/
CARL normalization rules call for apostrophes to be
retained in //nb/ and for //sb/ for names used as subjects
(660,610,611).
Text-based VICTOR observes these rules for //nb/ and //sb/,
placing user in proper portion of name or subject index.
VICTORWeb specifically presents a problem with //sb/ and
//nb/ of names with apostrophes such as O'Neill, Eugene.
It appears that VICTORWeb does retain the apostrophe in the
browsable name & subject index, however, user is not placed
in the correct portion of the names or subject indexes
whether their query includes an apostrophe (O'neill,
eugene), substitutes a space for the apostrophe (O neill,
eugene), or omits the apostrophe (Oneill, eugene).
Hotlinked headings containing apostrophes in VICTORWeb
bibliographic records perform unsuccessful name or
subject browse searches.
At present, one may search the apostrophed-name with a
space rather than an apostrophe (O neill), then page down
through the index to that portion containing names with
apostrophes. Or forget about browse, and search name with
apostrophe in //n or //w or //sw.
CARL normalization rules indicate that punctuation such
as apostrophes are removed in //w, //n, and //sw/
searches, and apostrophes are retained for //t if they
are embedded in word (in fact, query must include embedded
apostrophe if title includes it).
I found that the rules hold true for both text-based VICTOR
& VICTORWeb. Both performed as expected.
Search for title: Eugene O'Neill review
search for name: Eugene O'Neill Society
search for subject word: Eugene O'Neill
Asterisks (*)
Normalization in VICTOR vs. VICTORWeb
--searches with Asterisks (*)
(1999-02-17)
VICTOR & VICTORWeb fail to perform according to the
CARL normalization rules regarding asterisks (*), except for //t
(and //sb/ in VICTOR).
Rules for asterisks in title browse call for them to be
retained unless they occur at the beginning of the title,
in which case they are removed. VICTOR & VICTORWeb both
observe this rule
//tm*a*s*h
places you in the index at M*a*s*h
Normalization rules for subject browse call for asterisks
to be retained if embedded within a word (unless the
subject in question is a 600/610/611, then the asterisk
should be replaced with spaces), and a VICTOR
//sb/m*a*s*h
search places user in the portion of the "M" index before
M subjects with hyphens (e.g., before M-19...) where it
should be according to the rules.
However, VICTORWeb search
of same term places user in that portion of "M" index
before "Ma". If the user then hits the change search button
and returns to the search box to see the previous term
searched, that search box contains:
m\*a\*s\*h
rather than
m*a*s*h
Hope you follow this, as clearer description fails me. The
content of the search box following the search indicates
the system has translated the original search in some way
that I do not understand yet. I witnessed the same
VICTORWeb "translation" with the problematic "names with
embedded apostrophe" searches about which I have previously
written.
Series browse rules call for removal of embedded
punctuation, however
//sm*a*s*h
results indicate VICTOR replaces asterisks with spaces
(places you same place as //sm a s h)
and VICTORWeb responds with
Sorry, there were no matches for the search "m*a*s*h"
In my opinion this is an wierd response to a browse search!
User should be placed somewhere within series index.
For //w, //n, and //sw/ asterisks are retained if embedded
in a word, otherwise they are removed, according to
normalization rules.
However in VICTOR text-based
//w, //n and //sw/ for: m*a*s*h
gets the following response,
No left hand truncation, or internal wildcarding is
allowed. Currently only right hand truncation is supported
and has the form:
[Partial Word]*
Please note that anything after the first * is illegal
In VICTORWeb
word: m*a*s*h
gets following response
Sorry, there were no matches for the search "m*a*s*h"
name and subject searches of : m*a*s*h
results indicate system removes asterisks, even though they
are embedded in the word, and user is presented with "Mash"
headings in response
Rules for asterisks in name browse call for the punctuation
to be replaced with spaces, however, in VICTOR
//nb/m*a*s*h
search places user in the portion of the "M" index before
M names with hyphens (e.g., before M-19...), not the same
place as //nb/m a s h (as the normalization rules for //nb/
would seem to indicate)
As with subject browse in VICTORWeb, the name browse of
VICTORWeb of : m*a*s*h
places the user in the part of the "M" index following
"M-19.." headings and before "Ma" headings
Returning to the seach box via the change search button,
one sees the system has translated the orginal search to:
m\*a\*s\*h
FYI: In writing, I have continued to use the quick search
notations (//w, //n, //sw/, etc.) as short-hand
reference to keyword, name, subject word, etc. searches.
When I have performed the searches in VICTOR I have usually
used the quick search commands, but have performed
menu-driven searches to compare results, and have not
tested normalization in VICTORWeb using the quicksearch
commands (though I have used various quickseach commands in
VICTORWeb for other purposes).
Commas (,)[still pending]
Diacritics (e.g., Alif, Ayn)
(1999-10-06)
While looking at some VICTOR/VICTORWeb searching problems
with hyphenated names I found a problem with VICTORWeb
retaining the Alif and Ayn in a hotlinks from headings on a
bibliographic record. CARL normalization rules call for
these and other diacritics to "drop out" and leave no
spaces in the posting. Instead, the Alif and Ayn caused the
hotlink Name/Author Browse searches to fail (placing user
in incorrect portion of Name index).
"Gal-Pe'er, Ilan" and "Mish‘al, Miryam" is what displays in
query box when user hits "change search" button following
failed hotlinks.
If the opac user inputs the name in a Name/Author Browse
search without the special character, the browse search
places the user in the correct part of the Name index.
Names in question:
Gal-Pe'er, Ilan {Alif}
Mish‘al, Miryam {Ayn}
Record in question:
Ramat-Gan
(BID28465480)
Exclamation points, Ampersands, Dollar signs, Equals signs, Plus sign (! & $ = + )
VICTOR vs. VICTORWeb normalization
-- ! (exclamation marks) in searches
(1999-03-29)
CARL normalization rules call for "!" to be replaced by spaces in all indexes except title where it must be retained in the search.
Both versions of VICTOR require "!" in title searches
and drop it in keyword or //w search.
After adding a subject title & author added entry "snap!crackle!pop!" to a record I found,
*VICTORWeb response for subject:
Sorry, there were no matches for the search "snap!crackle!pop!"
Response for subject browse: places in wrong part of subject index; doesn't translate "!" to spaces, although posting in the index shows spaces instead of "!"
Response for name:
Sorry, there were no matches for the search "snap!crackle!pop!"
Response for name browse: places in wrong part of name
index; doesn't translate "!" to spaces, although posting in
the index shows spaces instead of "!"
*VICTOR text-based
//nsnap!crackle!pop!
or
//sw/snap!crackle!pop!
translates "!" to space and gives successful result
//nb/snap!crackle!pop!
or
//sb/snap!crackle!pop!
places in wrong part of index; doesn't translate "!" to spaces,
although posting in the index shows spaces instead of "!"
NOTE: Following test, test tags were removed from live bibliographic record.
**************************
Problem reported:
> VICTOR apparently recognizes equal sign as a valid character.
> I was searching for the title Wen hsueh = wen xue.
> My first search attempt was //twen hsueh w, which didn't pick up my title.
> I then searched //twen hsueh and got it (3rd or 4th on the screen of 7).
> Then I did //twen hsueh = wen, and got my title as the first one on the screen of seven. Is that the way it should be?
Response given:
CARL normalization rules for title search state:
Slashes (/), colons (:), quotes ("), semicolons (;),
question marks (?), left and right brackets
([]}, underscores (_), grave accents (`), left and right braces ({}),
verticle lines (|), and tildes(~) are replaced with
spaces. Other punctuation is retained.
Additional punctuation retained, besides the equals (=),
are:
- plus sign (+),
- dollar sign ($),
- ampersand (&),
- and
exclamation point (!).
At least VICTORWeb searches these the same as VICTOR
text-based.
Hyphens (-)
Normalization in VICTOR vs. VICTORWeb
--searches with hyphens (-)
(1999-05-06)
CARL B500 normalization rules call for hyphens to be
replaced by spaces in the keyword searches (NAME, WORD,
SUBJECTS) and retained in the browse searches only if
separating numbers.
--VICTOR text-based & VICTORWeb behave the same and
in accord with the CARL B500 normalization rules for WORD searches and for TITLE BROWSE. Hyphens normalize properly for Series
Browse* in both versions of database, as well.
For example,
Opac user has same success searching:
//wone-dimensional
in VICTOR, and
one-dimensional as a Keyword in VICTORWeb
or
//tone-dimensional
in VICTOR, and
one-dimensional
as Title Browse in VICTORWeb
--VICTOR fails to normalize hyphens properly for Name
Browse (//nb/) and Subject Browse (//sb/) and
--VICTORWeb fails to normalize hyphens properly for
Name/Author Headings Searches or Subjects Searches.
Opac user must remove hyphens from queries to have any
success in these situations.
***Problem with hyphen in Subjects search in VICTORWeb,
Query on "one-dimensional" got response:
Sorry, there were no matches for the search
"one-dimensional"
whereas, //sw/one-dimensional in VICTOR returned 6 hits.
Opac user of VICTORWeb must drop out hyphen in Subjects
search to get proper response, whereas VICTOR normalizes
out the hyphen as it is supposed to do.
***Subject Browse with hyphen works in VICTORWeb, but fails
in VICTOR--cf.,
//sb/one-dimensional conductors
in VICTOR,
and
Subject Browse on "one-dimensional conductors" in VICTORWeb
This means the hotlinks from hyphenated topical subjects in
VICTORWeb bib records execute properly.
Opac user of VICTOR, however, will be placed in wrong
portion of Subject index, unless s/he drops out hyphen from
VICTOR //sb/ query.
---Problem with hyphenated names in Name/Author
Headings search of VICTORWeb but not in NAME search of
VICTOR
Hyphen presents no problem for //n search in VICTOR, but
Name/Author Headings search in VICTORWeb using hyphen in
name causes search to fail.
e.g.,
"Vizine-Goetz, Diane" as a Name/Author Heading search gets
the following response:
"Sorry, there were no matches for the search 'Vizine-Goetz,
Diane'"
even though VICTOR //n Vizine-Goetz, Diane
retrieves a record
---Problem with hyphenated names in //nb/ in VICTOR but not
corresponding search in VICTORWeb
Hyphen causes //nb/ search to fail in VICTOR, placing opac
user in wrong part of name index, however, Name/Author
Browse in VICTORWeb on hyphenated name works fine, placing
opac user in correct portion of name index. Hotlink from
hyphenated name in bib record also works, name is
normalized as documentation details.
cf.,
//nb/Vizine-Goetz, Diane
in VICTOR
and
Name/Author Browse: "Vizine-Goetz, Diane"
in
VICTORWeb
--*Series Browse in VICTORWeb continues to be weird, giving
response:
"Sorry, there were no matches for the search
'one-dimensional'"
rather than place the opac user in the appropriate part of the series index. The search fails with/or without the hyphen, merely because no series title begins with the words "one dimensional" or
"one-dimensional".
To test whether hyphens are problemmatic in Series Browse,
one must be searching a title with hyphenated words which
actually exists in the Series index.
Example: One-act plays in reprint
This is gets a successful response in VICTORWeb.
VICTORWeb Series Browse skips the "Browse Results" page it
gives for initial responses to Subject Browse or
Name/Author Browse queries. Instead, Series Browse
presents opac user with the secondary "Title List" page
with postings listed in alpha-numeric order by series
heading. The element being ordered (series heading) is not
visable from the "Title List", instead the "Title List"
displays the main entry posting for the bib record
containing the series heading being "Browsed".
In VICTOR, //sone-dimensional normalizes as expected and
places opac user in proper portion of series index, even
though no series begins with such words.
Parens (())[still testing]
Periods (.)
VICTOR vs. VICTORWeb normalization
--periods in searches
(1999-02-15)
Problems abound relating to normalization of periods in
searches in both versions of VICTOR
Rules for //w, //n, and //sw/ call for retaining periods if
they are embedded in a number, otherwise they are turned
into spaces.
keyword: "3.1 undong"
unsuccessful in VICTOR & VICTORWeb
[should match on bid22313475 title, 3.1 Undong kwa minjok
tongil : 3.1 Undong 70-chunyon Kinyom Simpojiom]
keyword: "h.b. fuller company"
works in VICTOR & VICTORWeb
[should match on bid30600849 where this term is in title,
and is a 610]
name: "3.1 Undong"
matches bid22313475 in VICTOR but gets no matches in VICTORWeb.
name: "h.b. fuller company"
matches bid30600849 in VICTOR but gets no matches in VICTORWeb
subject word: "4.1"
seems to be normalized as "4 1" in VICTOR but normalized as "41" in VICTORWeb
[I have no example of a subject heading in our database
containing a number with embedded period, though such may
exist]
subject word: "h.b. fuller company"
matches bid30600849 in VICTOR but gets no matches in VICTORWeb
Normalization of periods in title browses should be same as
for //w, //n, and //sw/.
title browse: "3.1 Undong..."
&
"Story of h.b. fuller"
both work according to rules in VICTOR & VICTORWeb
CARL normalization rules call for name browse to replace
periods with spaces, subject browse to retain periods
embedded in numbers otherwise turn periods into spaces
except that names as subjects would have periods always
replaced by spaces.
name browse & subject browse: "h.b. fuller company"
does not place user in correct portion of either browse index
in either VICTOR or VICTORWeb; search seems to normalize
period by removing them (h.b. = hb rather than h.b. = h b). This means hotlinks from bibliographic records do not work.
Slashes (/)
VICTOR vs. VICTORWeb normalization
--slashes in searches
(1999-03-29)
CARL documentation indicates slashes are translated into
spaces for all type searches, and it seems that for the
keyword & //w searches this is true. However, both
VICTORWeb & VICTOR text-based fail to translate slashes
into spaces for name, name browse or subject browse.
Browse name headings: FAO/Japan Expert ...
or:
Joint fao/who
VICTORWeb name: fao/japan
gets:
Sorry, there were no matches for the search "Fao/japan "
VICTOR text-based: //nfao/japan
gets:
Set of 6 will display on one page -- proceeding with display...
1 Fao technical confe> 1979 MCK FOLIO
Advances in aquaculture : papers presented at f> SH135.F24
2 Fao japan expert co> 1993 GOVDOC LC DOC
Papers presented at the fao/japan expert consul> SH331.F2 no.474 suppl.
3 Fao japan expert co> 1993 GOVDOC LC DOC
Report of the fao/japan expert consultation on > SH331.F2 no.474
4 Fao expert consulta> 1996 GOVDOC LC DOC
Status of interactions of pacific tuna fisherie> SH351.T8F36 1995
5 Fao expert consulta> 1995 GOVDOC LC DOC
Summary report of the second fao expert consult> SH331.F2 no.520
6 1968
Rice breeding with induced mutations; report of> See full record
ALL ITEMS HAVE BEEN DISPLAYED..
There are several inappropriate hits because, with the
slash in the query, VICTOR interprets this as a name/word
search (even with the menu-driven name search)and looks for
records with "fao" in an author tag and "japan" anywhere in
the record, rather than fao and japan in any author tag.
VICTORWeb name browse: fao/japan
gets placed in name index at: Faolain, turlough
Query must be entered with space instead of slash to be
placed in proper part of name index
VICTOR text-based: //nb/fao/japan
behaves same as VICTORWeb
In VICTORWeb and VICTOR text-based subject browse behaves
same way as name browse. Only way to get into correct part
of index is to enter heading with a space instead of a slash
search: Joint FAO/WHO ...
This all means the bibliographic record hot-linked headings
containing slashes will fail to take the user to the
correct portions of the indexes.
"A", "An", "The" as initial words in title browse
Searching titles in VICTOR or VICTORWeb which begin with
"a", "an", or "the" when these words are not
English-language initial articles--
(1999-02-17)
VICTOR skips the words "A", "An", or "The" when they begin
titles. VICTOR does not distinguish when those initial
"words" are not articles. The word which looks like an
English-language initial article to VICTOR, may be a
significant word in another language. Successful title
searches for such titles involve repeating the special
initial word, as follows:
titles title search
A.J. Lumsden --> //t a a j lumsden
An-hui ching chi nien chien --> //t an an hui ching chi nien chien
An alle Kunstler --> //t an an alle kunstler
Le the et chocolat --> //t the the et chocolat
[Actually, preceeding the title with "a" will accomplish a
successful search; one needn't repeat the same word
beginning the title being searched (e.g., "a the et
chocolat")]
VICTORWeb title browses do not require repetition of an
initial article, as VICTOR does, except with titles
beginning with "the" when "the" is not an English language
article.
Stopwords
Special NAME search problem:
VICTOR interprets part of name as BOOLEAN connector.
(1999-05-06)
This special name search problem exists for any names with
elements which could be construed to be a BOOLEAN operator
and makes them almost impossible to find via NAME search in
VICTOR.
Examples of such names in USM or UMCP databases:
- But, Paul P. H.
- Not, Louis
- And, Metin, 1927-
- Or, Daniel, 1913-
Opac users should use //nb/ in VICTOR to search for such
names, or, turn to VICTORWeb where Name/Author Heading
searches work with such elements.
**************BACKGROUND*************
User reported searching problem with hyphenated compound
surname: Gal-Or, Noomi
Just to complicate things, due to Romanization scheme
employed, the controlled form of author's name
(Gal-Or, Noemi) differs from name on t.p. (Noomi Gal-Or).
In the absence of cross references in the opac, the user
had even less to assist him in obtaining a successful
search response.
Opac user can obtain authorized form of name by consulting
USM Authority Database in MdUSA and search that form
against the database.
In VICTOR, Name/Author Browse search works for this
compound name if opac user inputs query without hyphen,
i.e.,
//nb/gal or, noemi
but presents special problem with NAME search:
//nGal-Or, Noemi
Hyphen & comma normalize to spaces but VICTOR thinks query
is
{GAL OR NOEMI} rather than GAL + OR + NOEMI
and requests that the search be further narrowed by WORD
VICTORWeb normalizes this name properly in Name/Author
Browse search (and hotlinks from bib records work), but
presents problem with Name/Author Heading search on same.
Name/Author Heading search: Gal-Or, Noemi
returns:
Sorry, there were no matches for the search "Gal-Or,
Noemi"
N/A Headings search will only work in VICTORWeb if opac user
drops out hyphen from query, i.e.,
Gal Or, Noemi.
*************************
Failure of VICTOR keyword (//w) searches containing stopwords
(1999-03-25)
Previously (11/98), when a VICTORWeb keyword query included
a stopword, the search failed.
User got message
"Sorry, there were no matches for the search ..."
Now the search is executed just great, even with stopwords.
Search keyword: Women in development collection
VICTOR text-based query for same fails. User must drop out
"in" (a stopword) to get the proper results. Perhaps the
combination of monster words with stopwords is too much for
text-based VICTOR.
Other queries containing stop words result in sets matching on the nonstop words, at least.
Search keyword: Gone with the wind
User is offered records matching GONE + WIND
|
|
|
© 1999 University of Maryland Libraries
