Joe, Jenn, et al,
I've mentioned a need for a method of linking fields that contain the
same metadata in romanized and native scripts on this list before--in
particular, here at Princeton we have Arabic and in the coming year
we'll have Chinese and Russian materials that contain parallel name,
title, and note fields.
In the past I thought a common parent element the wrapped the two
elements that share the same data might be a possibility. That approach
would probably constitute a pretty major schema change. Here's another
idea, which I think I like more: what about a global @romanization? I
seem to remember that there was a discussion (and maybe a resolve?) on
this list a while back for including data about romanization rules in in
a new MODS 3.4 attribute or element, but I can't seem to quickly locate
it in the archives.
So, for example:
<name type="personal" authority="naf" script="Arab" lang="ara">
<namePart romanization="Ṭūsī, Naṣīr al-Dīn Muḥammad ibn Muḥammad">طوسي، نصير الدين محمد بن محمد</namePart>
<roleTerm authority="marcrelator" type="code">aut</roleTerm>
(I'll leave an image of this XML here:
http://diglib.princeton.edu/_images/mods-roman.png for a while, in case
any of the characters don't come across well in this email)
The script for the romanization is known, obviously, and the language is
the same as the native-script version, so there's no need to include or
repeat that data, or the role data.
This is somewhat similar to @altrender in EAD, but more specific, and
not necessarily intended solely for display--in fact, one could imagine
indexing this attribute and not displaying it. I'm not a
language/script specialist, so I can't be sure that this would always
work, particularly for names. Anyone?
PS: Rehashing the linking issue, though it's a different type of linking
from the MARC 880/‡6 type of linking, and not related to the direction
this thread has taken; Jenn has also mentioned a need for the ability to
link names and titles, to replicate MARC 1xx/240 and 7xx ‡a ‡t
behavior. We definitely need a better way to do that as well--I would
think anyone dealing with music or collected works must have run into
C-17-D2 Firestone Library
Princeton, NJ 08544
Email: [log in to unmask]
Joe Altimus wrote:
> Regarding the non-roman data in your MODS records, I wonder if
> <extension> is merely a storage place for that data, or if it is used
> in a functional way for indexing or display in your systems? The MARC
> $6 feature permits a field-specific ability to toggle roman and
> non-roman data in a user display -- would a similar feature in MODS be
> useful for you (and other MODS implementors)?
> Joe Altimus
> Metadata Librarian
> Arizona State University Libraries
> On Wed, Aug 12, 2009 at 1:59 AM, Ashley Sanders
> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
> 1) What type of data are you currently putting in the
> top-level <extension> element?
> We use the <extension> element for local holdings info and for
> data. If a MARC record contains 880 fields, then we create a second
> <mods> element using the 880s and stick it in <extension>. You can
> see an example here:
> 2) Do you have specific cases in which it would be helpful to
> you to have <extension> inside a specific MODS element rather
> than at the top level to convey additional semantics?
> 3) Have you made changes to the MODS schema locally to allow
> for additional elements not in the MODS schema?
> Ashley Sanders [log in to unmask]
> <mailto:[log in to unmask]>
> Copac http://copac.ac.uk A Mimas service funded by JISC