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>
   <namePart type="date">1201-1274</namePart>
      <roleTerm authority="marcrelator" type="code">aut</roleTerm>

(I'll leave an image of this XML here: 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 
this problem.

Jon Stroop
Metadata Analyst
C-17-D2 Firestone Library
Princeton University
Princeton, NJ 08544

Email: [log in to unmask]
Phone: (609)258-0059
Fax: (609)258-0441

Joe Altimus wrote:
> Ashley,
> 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:
>     Jenn,
>         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
>     non-roman
>     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?
>     No.
>         3) Have you made changes to the MODS schema locally to allow
>         for additional elements not in the MODS schema?
>     No.
>     Regards,
>     Ashley.
>     -- 
>     Ashley Sanders               [log in to unmask]
>     <mailto:[log in to unmask]>
>     Copac A Mimas service funded by JISC