[Evergreen-catalogers] MODS indexing and 700 |t

[Hardy, Elaine]

1) Yes -- too many records aren't returned in a search as it is now. And
yes for adding the field to the OPAC display. I would make it part of the
default, actually, with or without the |t. But, I argued for a much more
comprehensive OPAC display from the very beginning. I think the default
leaves out too many needed fields.

2) In general, I agree that the 7xx fields should be weighted differently
than an 1xx field. An good example of a problem with not doing so is the
author search for John Sandford -- the author of adult thrillers and an
illustrator of children's books (different people). In the PINES catalog
(currently out of the box ranking), the children's books display first and
then the others even though the illustrator is in a 700 field and the
other Sandford is in the 100.. It would be a little more relevant to have
the 100 Sandford, John records first in the relevance ranking. But, what
would the overall result be in putting them in separate name indexes?
Would it slow down search returns?

Elaine
 

J. Elaine Hardy
PINES Bibliographic Projects and Metadata Manager
Georgia Public Library Service,
A Unit of the University System of Georgia
1800 Century Place, Suite 150
Atlanta, Ga. 30345-4304
404.235-7128
404.235-7201, fax

ehardy at georgialibraries.org
www.georgialibraries.org
http://www.georgialibraries.org/pines/


-----Original Message-----
From: evergreen-catalogers-bounces at list.evergreen-ils.org
[mailto:evergreen-catalogers-bounces at list.evergreen-ils.org] On Behalf Of
Galen Charlton
Sent: Wednesday, May 02, 2012 11:17 AM
To: Evergreen Community Catalogers
Subject: Re: [Evergreen-catalogers] MODS indexing and 700 |t

Hi,

On May 2, 2012, at 10:53 AM, Hardy, Elaine wrote:
> As most of you are probably aware, Evergreen uses MODS for indexing. One
odd element that exists in MODS is that 7xx fields with a subfield t are
not defined as a name element
(seehttp://www.loc.gov/standards/mods/mods-mapping.html#name). I see this
as a problem since it means that the Evergreen application of MODS as an
indexing tool excludes any 700 field with a subfield t from the author
index. So, all of those nice analytical entries we add to records aren’t
useful in locating an author (and perhaps the title, but I haven’t tested
that recently).

Looking at the mapping, 7xx$t are available in the MODS representation in
relatedItem elements.  For example,

700 12 $a Fodi, John, $d 1944- $t Down endless lanes where cherries
flower.

becomes

    <relatedItem type="constituent">
      <titleInfo>
        <title>Down endless lanes where cherries flower</title>
      </titleInfo>
      <name type="personal">
        <namePart>Fodi, John,</namePart>
        <namePart type="date">1944-</namePart>
      </name>
    </relatedItem>

Consequently, since the data is available in the MODS, it would be
possible to include name elements that are part of relatedItems in the
various author indexes by either adding entries in config.metabib_field to
create "analytic name" indexes or adjusting the XPath in the existing name
indexes to cast a wider net.  That raises a few questions to me:

[1] Would it be a good idea to make this part of the default index
definitions?  I lean towards yes, but if so, I think it should go
hand-in-hand making sure that 7xx with $t are included in the default bib
details display in the OPAC.

[2] Should it be possible to give names coming from relatedItems a
different weight for the purposes of relevance ranking?  If the answer is
yes, that implies that those names would go into separate name indexes
rather than being added to the existing ones.

Regards,

Galen
--
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org

_______________________________________________
Evergreen-catalogers mailing list
Evergreen-catalogers at list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-cataloger
s