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>
<role>
<roleTerm authority="marcrelator" type="code">aut</roleTerm>
</role>
</name>
(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?
-Jon
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
http://diglib.princeton.edu
http://diglib.princeton.edu/ead
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:
>
>
> http://copac.ac.uk/search?ti=Qian+gu+zhi+mi&rn=1&format=XML+-+MODS
> <http://copac.ac.uk/search?ti=Qian+gu+zhi+mi&rn=1&format=XML+-+MODS>
>
>
> 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 http://copac.ac.uk A Mimas service funded by JISC
>
>
|