Print

Print


Title in transliteration is a title in different form for type, it provides
an access point to the record.

It may be easier if transliteration is stored in a separated element with
all necessary attributes to identify the content.

Nest transliteration as an element  in another element will make the program
logic more difficult than it is in a separated xml element.
You do not need to associate elements together by nesting, you can use name
of the element, and/or type of the element to achieve the same result with
xml data.

Transliterating field as an attribute is not going to work, because you will
have a situation that you need to describe an attribute with another
attribute.

Foster Zhang
===============================================
Systems Department         (650) 725-7924
Green Library East, 2nd Fl.(650) 723-3038 (fax)
Stanford University        [log in to unmask]
Stanford, CA  94305-6069   library.stanford.edu




-----Original Message-----
From: Metadata Object Description Schema List [mailto:[log in to unmask]]On Behalf
Of Joe Zeeman
Sent: 2002?11?22?(???) 9:44
To: [log in to unmask]
Subject: Re: [MODS] language attributes for MODS element - transliterations


But how, then, is the transliteration to be linked to the element it is a
transliteration of (assuming there is one in the record)?  In my mind, the
best approach would be to find a way to carry them in the same field.
Possibly a <transliteration> element needs to be available for nesting
inside other elements as needed.

For example:

<titleInfo>
     <title>[a title in Cyrillic]
          <transliteration scheme="Marc21">[transliteration of Cyrillic
title] </transliteration>
     </title>
     <partNumber>[a part number in Cyrillic]
          <transliteration scheme="Marc21">[transliteration of Cyrillic
part number</transliteration>
     </partNumber>
</titleInfo>

It would be unfortunate if we end up needing to use application logic to
link arbitrary fields along the lines of the 880s in MARC, when XML gives
us an opportunity to have an explicit dependency.

An alternative would be to carry the transliteration itself as an
attribute, but this would cause awkwardnesses when the transliteration is
the only data available for the field (as in LOTS of MARC records). Mind
you, in most of those we don't even know that the title is transliterated,
at least not in any way that a mapping algorithm could easily use.

Of course, the easier thing to do would be to ban transliteration
altogether.

Joe Zeeman
Research Libraries Group




                    Karen Coyle
                    <kcoyle@KCOYLE       To:     [log in to unmask]
                    .NET>                cc:
                    Sent by:             Subject:     Re: [MODS] language
attributes for MODS element -
                    Metadata              transliterations
                    Object
                    Description
                    Schema List
                    <[log in to unmask]>


                    11/22/2002
                    06:53 AM
                    Please respond
                    to Metadata
                    Object
                    Description
                    Schema List






I was assuming it to be an attribute on a field. We could cover both pieces
of info (it's a transliteration, and what transliteration scheme) by having
an attribute that is simply:

    transliteration=[pinyin, wade-giles, etc.]

There would have to be a "cop-out" value ("other" and/or "unknown"). There
would have to be an authoritative list of transliteration schemes and we
could limit it to a few very common ones, with everything else being
"other." I think we can justify this in that transliteration, as many have
stated here, should be a thing of the past and this would primarily be used
for older metadata that is being transformed to MODS, not for metadata
being created currently or in the future.

kc