But we already have multiple types of title, each of which may need to be
transliterated. So transliteration can't be a type of title parallel with
uniform title, etc. It has to be something else. We also have names,
publication info, abstract, etc.., which may also need to be
transliterated.
Is a transliterated title a useful access point to anyone other than a
cataloguer?
j.
Foster Zhang
<fjzhang@STANF To: [log in to unmask]
ORD.EDU> cc:
Sent by: Subject: Re: [MODS] language attributes for MODS element -
Metadata transliterations
Object
Description
Schema List
<[log in to unmask]>
11/22/2002
11:07 AM
Please respond
to Metadata
Object
Description
Schema List
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
|