From: Resource Description and Access / Resource Description and Access
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle
Sent: May 14, 2012 8:53 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L]
[BIBFRAME] RDA, DBMS and RDF
>All that to say that if we are not going to display our records in
>alphabetical order by their headings, then I'm >not sure if creating headings
>during cataloging makes all that much sense. Or at least, not the kinds of
>headings >that we do create, which are designed to be viewed in alphabetical
>order. You are supposed to see "Hamlet" before >you see
>Hamlet. French.
>Hamlet. German.
>Hamlet. German. 1919
>Maybe you don't see "Hamlet" first, but the logic of adding on to the right
>hand side of the heading implies that >the order conveys something to the user
>that facilitates finding what he is looking for.
>Thus, I question to creation of headings that are designed to be encountered
>in alphabetical order unless we adopt >an ordered display around those
>headings. And if we think it is important to adopt such a display, we need to
>>understand the implications for system design.
There are numerous effects of the alphabetical browse display of headings in
online systems that force catalogers and systems designers to make all sorts of
unexpected decisions and difficult choices and workarounds. And even at that,
the conventions that bring us those headings are often found out of context.
For example, some of those headings with "extra bits" at the end exist to
differentiate entities, and otherwise appear arbitrary without much relation to
the headings around them which omit the extra bits.
End-users have their complaints browsing a catalog index. They complain when
they expect to find different records attached to each unique heading, but
instead find that the record happened to have several headings that all began
with the same words.
Multiple indexes in online catalogs fracture and distort the intended effect of
browsing headings. For the four ILS's I've worked with and customized I've had
to make choices about MARC index mapping that would mitigate these issues:
1. Author Browse may or may not contain name-title headings for works and
expressions. These headings could be pulled from related or analytical or
series added entries. Should subject name-title headings be included? What
about title SEE references to these headings? One system I used actually
reconstructed the 1XX+240 heading on-the-fly. And what about persons and
corporate bodies as subjects? Shouldn't the user benefit from seeing all
related works together?
This is why FRBR is so important. So much of the indexing is built around a
cacophony of different implicit relationships, with little that is explicit to
the end-users in terms of building expectations of what should be found with
what. Being clear about the relationships matter, because that information
needs to survive as catalogs records and indexes are torn apart and rebuilt in
any number of different ways - we can't assume the implicit logic that exists
when all card catalog and heading data are found together in context.
2. Title Browse often doesn't include authority information such as SEE and
SEE ALSO references, so much of the information available in authority records
is effectively lost. Should Title Browse draw in all titles, such as series
titles or subject titles? I always mapped these together because I felt it
wrong for an end-user to decide upon a title AND a relationship when searching
(i.e., the end-user knows the title, but may not know it's a series title - why
expect the end-user to be forced to choose between Title Browse and Series
Browse?)
3. Subject Browse - similar to the issue above about end-users being forced to
choose indexes, an end-user needs to differentiate William Shakespeare as
author from William Shakespeare as subject ahead of time to find all the
records attached to that name. The records are not found together with a single
search in many cases. In an early system I had with minimal authority control,
there were actually two system generated authority records for William
Shakespeare - one as an author and one as a subject. There is a benefit to
maintenance when one record per entity is updated, but the end-user may not
encounter all the benefits because of the bewildering choices of indexes and
the truncated and chopped up displays of bibliographic and authority data in
online catalogs.
Once web-based catalogs appeared, there were choices that could be made as well
when a heading is clicked.
In the case of a related name-title work heading, I had three choices in one
system:
A. Click the heading and bring up only those records attached to the heading.
B. Click the heading and have a keyword search initiated using all the words
in the heading (not good with long and unique subject headings as the only
result that would often satisfy the search would be the record in hand)
C. Click the heading and go to the entry point in the respective Browse index
I chose option C because the end-user would encounter potentially useful
information (SEE references, SEE ALSO references, and related headings that
were filed closely alphabetically).
There is a fourth option out there now, and that is to take the user to a web
page for the ENTITY represented by the heading, as in this web page for
Virginia Woolf from WorldCat Identities:
http://www.worldcat.org/identities/lccn-n79-41870
Alphabetical lists can still exist, but now it's possible to subsume them in
frames within a web page dedicated to an entity - where one can see all
attributes and relationships for that entity (as opposed to having that
information be scattered amongst bibliographic and authority records).
In the case of this WorldCat Identities page for Virginia Woolf, one can see
the works BY her and the works ABOUT her. This in some ways reconstructs a
benefit to card catalogs, in that a unified catalog with all headings together
would draw together all related works attached to one unique heading. Another
benefit to the web page per entity approach is that related works can be drawn
in by any number of mechanisms - algorithms that look at user data (a person
who looked at this entity also looked at this other entity) or citations links
or links to external sources and web sites. Or perhaps full text search results
that show all resources that mention the person's name.
The current situation in online catalogs with so many indexes is that end-users
have to make decisions about relationships by choosing the right index, and
know to try out different indexes. Keyword searches are simpler, but much of
the useful navigation to related entities is lost because hyperlinks usually
just launch new keyword searches, producing results that don't show explicitly
the relationship to the original entity.
There is value in what the alphabetical listing of headings in card catalogs
did - but the better road to travel in the future to maintain that utility is
to utilize the entity-relationship model, because by making relationships more
explicit, data about those relationships can be maintained across different
kinds of interfaces and catalog implementations. This is better than saying "oh
just code this related work in a 700" - it's hard to tell how an online catalog
will handle that heading because the original intent is just to file that
name-title in with other entries alphabetically beginning with the author's
name. Instead, saying explicitly and designating the relationship explicitly -
"this work is related to that work because it's a derived work" - we can map
out interfaces that don't rely on mechanisms such as the alphabetical access
points that worked reasonably in card catalogs but not so well in other
implementations.
Thomas Brenndorfer
Guelph Public Library
