Two IDs with the same value renders the document invalid (as it should),
and the schema doesn't allow for IDREFs (and this seems like an
inappropriate use of xlink:href to me). Is this something that is
planned for a future version? Also, linking one node TO the other
implies an unintended hierarchy, which I don't think one would always
want to do (though perhaps with name/title it's OK).
I think what we really need is some way to simply provide elements with
a common key. As I mentioned in my last message, a keying facility
would also be useful for replicating the use of MARC 880 fields.
C-17-D2 Firestone Library
Princeton, NJ 08544
Email: [log in to unmask]
Rebecca S. Guenther wrote:
> This is a good question. We have discussed the situation with name/title
> 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 be
> in <title type="uniform">, and you are correct that this doesn't
> explicitly link it to a particular name. We probably need to analyze some
> examples to see where this won't work. In some cases when you need to link
> 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 have
>> a title component, most have both a name and title components, with
>> the title not making sense without the name. This is common for music.
>> 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 name
>> 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 with
>> 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?
>> Jenn Riley
>> Metadata Librarian
>> Digital Library Program
>> Indiana University - Bloomington
>> Wells Library W501
>> (812) 856-5759
>> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com