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?
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
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net