Quoting Jonathan Rochkind <[email protected]>:
How does software know when to get exactly what from a 240 or 740 ,
and when to use it as a title label? (A 240 is often useless as a
title label, eg "Selections", that is NOT in fact the title of the
work it's attached to, to any user at all; A work cited in a 740
may or may not actually be the work in the record at hand, it could
also be a 'related' work in some way).
The uniform title is an interesting example of what programmers might
call "overloading." Although identically coded, these 240 fields have
totally different meanings:
24010 $a Selections
-- For an item ..."consisting of three or more works in various
forms..." The title of the work is NOT "Selections"
24010 $a Pendolo di Foucault. $l English
-- For a translation of a Work. "Pendolo di Foucault" IS the
title of the work (in the FRBR sense of Work) that was translated. The
subfield $l tells you what it was translated to.
24010 $a Concertos, $m harpsichord, string orchestra, $n BWV 1052,
$r D minor
-- I'm not sure how to describe this, except that it is a coded
description of music that has little or nothing to do with the actual
title of the thing begin described. This is to music as the
hierarchical place name (752) is to newspapers. It's great data, and
undoubtedly very useful, but it really needs its own data element.
It gets even worse when you start looking at 700 $t's. The music
people always want to have an index that includes the 100/240 and the
700 $a $t. Unfortunately, not all 700 $t's are equivalent to a 240,
not even in music records. So you either throw every 700 with a $t
into a uniform title field (and most of the time they won't look like
uniform titles, so the value of that diminishes), or you do a title
index that includes all of the titles, and the music folks are unhappy
that they can't search only on THEIR uniform titles.
Clearly, if instead of throwing every kind of title into 700 $t we
could have a data element for that valuable, constructed music title,
then we could serve music library patrons much better.
If we start digging we will find many similar examples in our data --
problems that make it hard to use our data for better user service. As
someone who has worked on software it just breaks my heart to see the
effort that goes into, for example, the creation of these music
constructed titles and to know that it's all be undone because of
ambiguity in our coding.
kc
--
Karen Coyle
[email protected] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
