I think a few (namely Jon Stroop) have stated that a keying utility would work here. I agree with that solution and think that implementing a key/keyref mechanism in MODS on names and titles could work well.
For instance, define an attribute called "nameID" on the name element. Then introduce an attribute on titleInfo called "nameRef". These would work like ID/IDREF constructs, except that we can apply XPath within the schema to constrain the usage of the shared common value to ONLY these attributes on these two elements. The binding on these elements and attributes would imply a relation between the two. This could also trickle down into cases where you want to use name-titles as subjects. We could also bind subjects to the name by using nameRef. (Of course we could put the keys on titleInfo instead of name, this is just an example.)
Personally I like the keying solution more than introducing a new element called nameTitle or the like, because it seems to me that name-titles are simple concatenations of strings that already exist in the record whose end result form an unnecessarily coordinated heading. The key/keyref alone can serve as a trigger to someone making an app to process the instance that says "these names and titles need to be processed together for my output".
>>> "Riley, Jenn" <[log in to unmask]> 07/06/08 10:03 AM >>>
I have a record extract for a project we've been working on that I think illustrates the problem pretty well - records for sound recordings that have 100/240/245 but no 700s with $t. All I have access to today is a subset of the record (100/240/245/7xx - we were doing some analysis on them). Here's an example:
100 10 Hahn, Reynaldo,|d1875-1947.
240 10 Ciboulette
245 10 Ciboulette|h[sound recording] :|bop‚erette en 3 actes /|cReynaldo Hahn ; [libretto par] R. de Flers et F. de Croisset.
700 10 Flers, Robert de,|d1872-1927.
700 10 Croisset, Francis de,|d1877-1937.
700 10 Mespl‚e, Mady|4prf.
700 10 Gedda, Nicolai.|4prf.
700 10 Dam, Jos‚e van.|4prf.
700 10 Diederich, Cyril.|4cnd.
710 20 Ensemble vocal Jean Laforge.|4prf.
710 20 Orchestre philharmonique de Monte-Carlo.|4prf.
I'm pretty sure that would end up in MODS with lots of name elements for each of the 700s. Many (maybe even most) of our records here at IU have $4 relator codes, but I know that's fairly unusual.
Let me know if this full set of MARC records would help you and I'll see if I can dig it up to send your way.
> -----Original Message-----
> From: Metadata Object Description Schema List [mailto:[log in to unmask]] On
> Behalf Of Rebecca S. Guenther
> Sent: Wednesday, July 02, 2008 1:42 PM
> To: [log in to unmask]
> Subject: Re: [MODS] uniform titles in mods
> This is a good question. We have discussed the situation with
> headings here and have wondered whether there is a need to make any
> changes for this sort of thing. We had intended that the uniform title
> in <title type="uniform">, and you are correct that this doesn't
> explicitly link it to a particular name. We probably need to analyze
> examples to see where this won't work. In some cases when you need to
> the name and the uniform title, they are cases of related items (e.g.
> constituents) where they get linked because they are in the same
> relatedItem container. But there may be other cases where this doesn't
> suffice, so some other mechanism perhaps resulting in a change to MODS
> could be considered. The intention was NOT to put the name in title
> type=uniform. Someone mentioned the use of xlink; the general linking
> mechanism in MODS would be use of the ID attribute (i.e. if 2 elements
> have the same ID value they are linked). That could be used in the
> meanwhile while we analyze this situation with more examples.
> It would be interesting to hear from others whether they have had a
> similar problem.
> ^^ Rebecca S. Guenther ^^
> ^^ Senior Networking and Standards Specialist ^^
> ^^ Network Development and MARC Standards Office ^^
> ^^ 1st and Independence Ave. SE ^^
> ^^ Library of Congress ^^
> ^^ Washington, DC 20540-4402 ^^
> ^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^
> ^^ [log in to unmask] ^^
> ^^ ^^
> On Sun, 29 Jun 2008, Riley, Jenn wrote:
> > Hello all,
> > I'm having trouble figuring out how to encode a Uniform Title in a
> > MODS record. While some Uniform Titles (e.g., for the Bible) only
> > a title component, most have both a name and title components, with
> > the title not making sense without the name. This is common for
> > This is what a sample MARC name-title authority record would show:
> > 100 10 |a Beethoven, Ludwig van, |d 1770-1827. |t Symphonies, |n no.
> > 5, op. 67, |r C minor
> > And this is how the UT would appear in a MARC bibliographic record:
> > 100 1_ |a Beethoven, Ludwig van, |d 1770-1827.
> > 240 10 |a Symphonies, |n no. 5, op. 67, |r C minor
> > The full UT is split across the 100/240 pair. For a MODS record, one
> > would think Beethoven would go in <name> and Symphonies... in
> > <titleInfo type="uniform">. But how is the connection between the
> > and the title parts of the full UT made in the MODS record? In MODS,
> > lists all the contributors in <name> elements, whereas in MARC you
> > only have one 100 field - other names are in 7xx fields.
> > I'm not advocating MODS adopt the concept of main entry, but to use
> > the UT effectively (which presumably is a goal of MODS since
> > type="uniform" is defined for <titleInfo>) there needs to be *some*
> > way to connect the right name with the UT. I'm very uncomfortable
> > the idea of including the name as part of the <titleInfo
> > type="uniform"> - is that what is intended? The MARC to MODS mapping
> > seems to support this not being the right thing to do. At
> > <http://www.loc.gov/standards/mods/mods-mapping.html>, it just pulls
> > in 240 data into <titleInfo> - it doesn't include data from the 100.
> > But what other options are there?
> > Thanks,
> > Jenn
> > ========================
> > Jenn Riley
> > Metadata Librarian
> > Digital Library Program
> > Indiana University - Bloomington
> > Wells Library W501
> > (812) 856-5759
> > www.dlib.indiana.edu
> > Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com