This does get a bit murky. There are basically three types of name/title
combination in MARC/AACR cataloging. They are all intended to function as a
compound informational units identifying a work.
700 1_ Name. $t Title. -- used for identifying works related to the main
object described--earlier editions, work referred to (e.g., for a
concordance), etc. also called "related work added entries."
700 12 Name. $t Title. -- used for identifying "analyzed" or constitutent
works, i.e., added entries for works contained within the main object
described. Also called "analytic added entries."
100 Name + 240 Title. -- Two MARC fields used jointly to identify the
standard or generic name/title identifier of a work. The data in 1XX/240
corresponds to data that in a MARC authority record is coded 1XX $a Name.
$t Title. Also called "uniform title entered under name."
The question of whether these are "controlled" data is also vexing. Only
some of cases found in each of these codings are actually established with
authority records; but all of them implicitly follow AACR rules for their
formulation, are expected to be consistent in all cases, and so are
implicitly "controlled" by those rules.
It's not clear to me whether the proposal to add a nameTitle element to
MODS is meant only for certain categories of added entries, or whether it
is meant as an alternative to using relatedItem with its separable Name and
Title elements. Rebecca's original note seems to say that nameTitle is
needed for non-"constituent" work entries identifying works, which in AACR
terminology would be "related work added entries;" while "relatedItem" in
MODS is used for "constituent" work entries, called in AACR "analytic added
entries."
So, now that that's cleared up ...
Despite the previous remarks about the non-use of 1XX $t in MARC, one value
I see in adding nameTitle to MODS would be that it would give a better
translation for MARC data in 1XX/240. For a user population not schooled in
MARC and AACR this notion of a single compound unit of data spread across
two fields is not intuitive. Catalogers are trained to see the 1XX in these
cases as serving a double function--it is an author entry, AND it is the
first element of a work identifier that's completed in the 240. Splitting
these two functions into two explicit data elements--Name and
nameTitle--sounds like a good idea to me. This compacting of these two
functions into one data element is one of the weaknesses in MARC, and a
source of perennial complaint.
Likewise, it's not clear to me why nameTitle could not be used in MODS also
for related work and constituent work cases, if the intent was to present a
"controlled" compound work identifier rather than a mini-record with
separate Name and Title elements in addition to other information.
Stephen
At 08:56 AM 3/1/2005, you wrote:
>MODS doesn't make the main entry/added entry distinction, so it's
>100/700$a with $t. Yes, noone uses 100$t. It could be a name/uniform title
>or a name/some other title. The project here is used relatedItem to do
>sort of subrecords for constituent items within the larger item and would
>like a way to bind together name and title outside of relatedItem, similar
>to 700$a with $t.
>
>Rebecca
>
>On Mon, 28 Feb 2005, Karen Coyle wrote:
>
> > Rebecca,
> >
> > What would map to this field? It sounds like a 1xx with a $t (apologies
> > to the non-librarians on the list -- I don't know another way to say
> > this), but that is never used, as far as I know. Are you thinking of it
> > as being for uniform titles? or?
> >
> > kc
> >
> > Rebecca S. Guenther wrote:
> >
> > >A project here at LC wants to use the name/title combination in MODS that
> > >we have defined for MADS. Right now, we map 700/710/711 with $t to related
> > >item with <name><titleInfo>. This is because we use that combination in
> > >cases where the work contains another work, so in MODS is considered a
> > >related item with type=constituent. This project wants the flexibility to
> > >give a name/title combination at the higher level of the MODS record, not
> > >as a sort of subrecord under relatedItem. The only way now to bind
> > >together a name and title is under relatedItem, which also could have a
> > >lot of additional information. The name/title combination may or may not
> > >be an authoritative heading.
> > >
> > >MADS has a nameTitle for this sort of construct, where you would have an
> > >authoritative heading for that combination. We did that because we wanted
> > >to allow for only one heading type under <authority>. So it allows for
> > >more consistency between MODS and MADS to have this construct in MODS as
> > >well. The other advantage is that one could then reference the record for
> > >this name/title combination in an authority file (MARC or MADS), as we do
> > >for other authoritative headings in MODS records, by just using a link to
> > >a name/title record. You couldn't really do this if it's under relatedItem
> > >since name and title are not bound together there since there would
> > >probably be additional elements.
> > >
> > >Is there any harm in allowing for this?
> > >
> > >If everyone agrees that this is a good idea, we would propose putting it
> > >into MODS version 3.1, which we will be issuing to go with MADS. This
> > >revision is mostly structural with a few corrections and a few additions.
> > >Nothing that changes would result in invalidating any existing records,
> > >but would include some enhancements. So newer instances could take
> > >advantage of some of the enhancements, while older ones would still be
> > >valid.
> > >
> > >Rebecca
> > >
> > >
> > >
> >
> > --
> > -----------------------------------
> > Karen Coyle / Digital Library Consultant
> > [log in to unmask] http://www.kcoyle.net
> > ph.: 510-540-7596
> > fx.: 510-848-3913
> > mo.: 510-435-8234
> > ------------------------------------
> >
****************************************************
Stephen Hearn
Authority Control Coordinator
Database Management Section Head
University of Minnesota
160 Wilson Library Voice: 612-625-2328
309 19th Avenue South Fax: 612-625-3428
Minneapolis, MN 55455 E-mail: [log in to unmask]
|