Topic 4. Transcription

Robert L. Maxwell robert_maxwell at byu.edu
Thu Jan 21 08:47:05 MST 1999


At 12:31 AM 1/21/99 -0500, Richard Noble wrote:
>At 06:07 PM 1/20/99 -0700, Bob Maxwell wrote:
>>Please add option 4: Transcribe according to a regular, predictable method
>>[which dcrb is NOT], such as the LCRI (1.0E) or the "solution of last
>>resort" in OH. I think we need to seriously consider such an option for
>>several reasons:
>
>RCN: I have not got LCRI in reach (got to get a copy for the home office!)
>to refresh my memory of 1.0E. In any case, if we're going to jettison the
>current rules (fine by me) then I think the best alternative is simply to
>modernize IJUV (and VV?) to the extent that they represent archaic
>*typography*, rather than *orthography*. (This may be tricky sometimes in
>languages in which i/j particularly are not as easily differentiable as
>vowel/consonant as they are in English.)  This treatment would have to be
>applied also to matter that is lower-case in the original for there to be
>any kind of consistency--which is no less important a criterion than it is
>in the method that we currently use, by which lower-case text is
>transcribed directly and upper-case matter is lower-cased to match it.
>(N.B.: The idea was not to imitate the printer's conventions just for the
>sake of doing so, but to ensure that the text of any transcription should
>be consistent throughout--an aesthetic motive, to be sure. One looks
>further into the book only in cases where the printer's conventions are not
>all exemplified in the whole of the text being transcribed.)

I should have recapped the LCRI, which is easily done since it is extremely
simple:

"1) use v for consonants, e.g., vox, Victoria;
2) use u for vowels, e.g., uva, Ursa Major;
3) use w for consonantal uu or vv, e.g., Windelia. 
... transcribe i and j as they appear; do not attempt any regularization"

Is this what you mean by modernizing to reflect orthography rather than
typography? (The LCRI is based on orthography, though one would think I and
J could be treated the same as U and V.) Or do you have a fifth option to
propose? Could you explain further?


>
>> 1. Patrick's point about the way these things sort in library systems.
>>Especially for titles that are used frequently (either containing common
>>terms or for works that have been issued in many editions), both dcrb
>>transcribed titles and exact transcriptions give an entirely arbitrary sort
>>order in title searches. Same titles should sort together, shouldn't they,
>>independent of the vagaries of printers' preferences of u's and v's and
>>catalogers' guesses about those preferences?
>
>RCN: This opens a can of really wiggly worms. Granted, in card files it was
>easy enough to disregard IJUV variants in filing, according to algorithms
>that are easily enough programmed in wetware. If we were, for example, to
>modernize, as I suggested above, then at least this bit of the problem
>would go away when we're stuck with software.
>
>BUT unless we are prepared to abandon the 245 as a transcribed field
>altogether, or at least impose all sorts of interesting rules to suppress
>all the other possible variations in titles proper, we'll have to live with
>our unpredictable displays. We must beware of distorting the rules at a
>fundamental level in order to solve system problems. That the collocating
>function of uniform titles is not fully realized (to say the least) in many
>systems doesn't mean that we'll have much better luck stuffing the 245 into
>an ill-fitting uniform of its own. By this criterion we ought to change the
>first sentence of 1B1, or at least redefine title proper as *not* including
>anything preceding the chief title, but I have a feeling that that could be
>a messy agony in Latin. We could at least strongly suggest a 246 30 for the
>chief title?

No, I think somehow we've got to solve the problem and still keep the 245
as a representation of the title page, i.e., a transcribed field. This is
one of the principles of title transcription under AACR2, too, and AACR2
doesn't call for abandoning grammatically connected stuff that appears
before what I think you are referring to as the chief title here.

>>[...] "exact" with the exception that we will lower-case the letters that
>need to
>>be lower-cased? Or should we be REALLY exact and transcribe caps as caps?
>[...]
>
>RCN: I don't think that would go down very well, and we long ago gave up on
>the idea of quasi-facsimile transcription in library catalogues. But is the
>Maxwellian tongue in the Maxwellian cheek?

Of course. I hope this suggestion won't be taken seriously! (We have a fair
number of records in our system done by someone who went wild with the
exact transcriptions and did exactly that--and they are quite illegible; I
change them whenever I run across them.) I was just taking the exact
transcription argument to its logical conclusion.

>
>>To change the topic slightly, 0H and the LCRI to 1.0E both call for
>>separating ligatures with the exception of oe in French; and ae in Danish
>>(LCRI), or oe or ae in Scandinavian languages (DCRB). Why is this
>>distinction being made? [...]
>
>RCN: Does this reflect any sort of French or Scandinavian pressure, I
>wonder? They may not be entirely happy with character deficiencies imposed
>on them by anglophones. Native speakers linguae Latinae have less influence
>these days.

I don't know about Scandinavian languages, but I was a French major as an
undergraduate and I am not aware that "oe" is considered a separate letter
(which might be one argument for this, since we do attempt to transcribe
actual separate letters such as thorn or the Polish L). I suggest some
research into this and if there is no good reason for keeping the oe and ae
ligatures in these particular cases that aspect of the rule, at least, be
dropped.

Bob
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert L. Maxwell
Special Collections and Ancient Languages Cataloger
6428 Harold B. Lee Library
Brigham Young University
Provo, UT 84602
(801) 378-5568
robert_maxwell at byu.edu
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



More information about the DCRM-L mailing list