[mab-list] Sitzung des MAB-Ausschusses am 27.

[Thomas Berger]

Liebe Liste,

Herr Eversberg kommentierte die Umlautproblematik:

>  In den momentan existierenden Daten haben wir keine solche
>  Unterscheidung.
>  Daher könnte eine Konversion nicht stattfinden, haette man
>  denn in Unicode tatsaechlich eine Differenzierung.
>  Ergo muessten wir undenklich lange mit erheblichen Altlasten
>  in diesem Punkt eben.
>  Abgehandelt wurde diese Frage bereits vor laengerer Zeit in einer
>  Studie, beauftragt von der damaligen Regelwerkskommission, mit dem
>  Titel "Zur Ordnung und Codierung der Umlautbuchstaben"
>    http://www.biblio.tu-bs.de/allegro/papiere/umlaute.htm
>  Die Kommission hatte die Resultate der Studie als Empfehlung
>  angenommen, und ein Resultat lautete, die Unterscheidung auch in Zukunft nicht
>  vorzunehmen. Die vorgeschlagene Doppelindexierung der Umlaute haette
>  naemlich als Nebenwirkung, "dass eine differenzierende Codierung
>  keinen Nutzeffekt haette".

Ich moechte aus dem von mir gestern angegebenen Dokument
http://www.niso.org/pdfs/Wg1_240.pdf
zitieren, das ein Arbeitspapier des entsprechenden
Standardisierungsgremiums zu sein scheint. Es datiert
vom 5.2.2000 und traegt den Titel:

        TC46/SC4/WG1 N 240
        Analysis of proposed mapping between characters of ISO 5426
        and ISO/IEC 10646-1 (UCS)

Der Umlaut-Problematik ist hier eine lange Fussnote gewidmet,
da nicht nur Unicode, sondern vor allem auch ANSEL bzw. USMARC21
die Unterscheidung zwischen Umlaut und Trema nicht macht.

Zitat: "[...] The distinction made between the two characters 
is said to be to support German filing conventions.

The advantage of having two discrete characters is that German 
collation practice can be supported easily. The disadvantage 
of having two characters is that they can be confused in both 
data input and searching, thus obviating the benefit of the 
distinction. [...]"


>  Sprachcodes, nebenbei bemerkt, obwohl das jedem klar ist,
>  waeren nur dann nutzbar, wenn jede Titelangabe, also auch Neben- und
>  Einheitstitel, einen eigenen Code haette.

Es gibt zu viele gemischtsprachige Titel, und wenn man an die 
Schriftsatzregeln fuer die Nutzung von Antiqua bzw. Fraktur 
anhand etymologischer Anhaltspunkte denkt oder an Ihre 
Anmerkungen "Wie finden Sie Goethe..." ("Goethe" sortiere im 
Brockhaus von "vor 1970" genau wie "Götterspeise" aus 
etymologischen Gruenden bei G-O-T, "Goethals" - Staatsbuerger-
prinzip? - jedoch bei G-O-E), so wird folgendes klar:

- Die "deutschen" Sortierregeln fuer Umlaute sind ein recht
  neues Phaenomen, frueher wurden sie wie im angelsaechsischen
  sortiert, dafuer gab es einen Sonderweg fuer scheinbare
  Diphtonge. Dahin will natuerlich niemand zurueck. Die
  von Herrn Eversberg in seinem zitierten Artikel getroffene
  Aussage, dass PI bereits "modern" (also gegen die Lexika
  der damaligen Zeit) sortierte, ist wie folgt zu relativieren:
  §22 2.: "Beim Auswerfen der Ordnungswoerter wird umgeschrieben:
   im Deutschen, Schwedischen usw.: ä, ö, ü, äu in ae, oe, ue,
   aeu;
   [...]"
  §34: "Diaktritische Zeichen werden nicht beruecksichtigt"
  Der Effekt ist natuerlich derselbe, jedoch scheint mir
  der Hinweis angebracht, dass die *Sortierregel* RAK §803.3
  in PI noch keine Sortierregel war, sondern eine Umschreibungs-
  regel innerhalb der vielen Regeln zur Konstruktion des 
  Sortierkopfs. In dieser Tradition muesste man also bei
  deutschen Namen oder Hauptsachtiteln nur haeufiger einen
  Ansetzungssachtitel MAB 300 bilden und alle Probleme
  waeren geloest :-)

- Sprachkennzeichnung muesste auf Wortniveau passieren,
  definitiv intellektuell:
  * Unicode sieht Language Tags vor (UTR #7 zu Unicode 3.0
    bzw. Unicode 3.1, Section 31.7:
    "However, the use of these characters is strongly discouraged.
    [...] The requirement for language information embedded in 
    plain text data is often overstated"
    Damit waere es theoretisch moeglich, "ä", "ö", "ü" als
    deutsch bzw. nicht-deutsch zu kennzeichnen, wenn das 
    konkrete Wort entgegen dem zutreffenden hypothetischen
    Sprachcode (des Records, des Feldes, des Teilfeldes ...)
    zu behandeln ist. Ich habe aber schon so lange nicht mehr
    die (englischen) Worte "contiguüs" (contiguöus?) oder
    "homeömorphism" gesehen, dass ich gar nicht mehr weiss,
    wie sie geschrieben werden.
    Jedenfalls kann man die gewuenschte Unterscheidung mit
    Unicode regeln, 
  * Die entscheidende Frage fuer MARC, MAB und Konsorten ist
    aber in der Tat ein Verzeichnen von Sprachinformation,
    wie es alle XML-Formate, selbst Dublin Core, seit langem
    als Selbstverstaendlichkeit haben: Sei es als
    Element-Attribute (<feld320 lan="de">...</>) oder aber
    als eigene Elemente fuer Textbestandteile: <feld320>Der
    <phrase lan="en">State of the art</> in MAB-ologie</feld320>
    Besitzt man einen Sprachauszeichnungsmechanismus der
    notwendigen Feinheit auf Formatebene, ist die Umlautproblematik
    von ISO 5426 irrelevant.

- Man muss aufpassen, nicht in aehnliche Fallen zu tappen wie
  beim Retrieval von stark angesetzter Information in OPACs,
  etwa bei Koerperschaften: 
  * Entweder man zwingt den Benutzer, bereits mehr zu wissen, 
    als er je erfahren wollte, bevor man ihn einen Datensatz
    finden laesst (vgl. "Olympic Games <24, 1988, Soul>",
    auf dem "o" sitzt ein Brevis), dies sehe ich in Analogie
    zum Umstand, Besitzer von auslaendischer Schulbildung
    und Tastatur nach "Mueller" suchen zu lassen, wenn sie
    den ihnen bekannten "Müller" oder "Muller" suchen.
  * Oder aber man "verwaessert" bewusst die Information aus
    Normdateien oder Zeichencodierung, um im Beispiel der
    Koerperschaft zu bleiben, muss der OPAC regeln, dass
    auch eine Suche nach "Seoul" oder eine Suche ohne die
    Zaehlung "24" moeglich ist. Auf die Umlaute bezogen muss
    der OPAC entweder herausfinden, was gemeint ist (und den 
    Kontext entweder ueber Sprachcodes mitgeteilt bekommen 
    oder mittels Sprachthesauri rekonstruieren) oder eben
    alle denkbaren Varianten (Müller, Mueller, Muller)
    indexieren.
  Denn: Man muss doch die in den Daten theoretisch 
  wuenschenswerte Differenzierung zwischen Trema und Umlaut 
  in Beziehung setzen zu der praktischen Unmoeglichkeit,
  einem Benutzer diese Beziehung zu vermitteln und ihn
  aufzufordern, diese Distinktion auch bei der Recherche
  zu spezifizieren!

Auch wenn dieser Text jetzt etwas laenger als beabsichtigt
ausgefallen ist, bin ich mir immer noch bewusst, dass es
sich hier um die MAB-Liste handelt und nicht um eine Liste
fuer OPAC-Empfehlungen. Ich halte MAB (-Titel) persoenlich
aber immer noch fuer ein Austauschformat primaer fuer
*Katalog*-Daten, und die Daten in einem Katalog messe ich 
nicht am Input, sondern an ihrer Relevanz fuer die Nutzung
des Katalogs. Fuer einen Online-Katalog schafft der 
Umlaut-Unterschied tendenziell Probleme (es sei denn, man
nivelliert den Unterschied als ersten Schritt). 

Ich habe oben aufgezeigt, dass auch in Unicode ein u mit
Trema von einem Umlaut-u unterschieden werden kann, 
theoretisch braucht daher gegen die Ausnahme in § 803.3
nicht unbedingt verstossen werden. Die Sortierregeln 
in den RAK-800er-Paragraphen bergen noch viele andere
Ueberraschungen und mir ist nicht bekannt, dass irgendwo
nennenswerte Anstrengungen unternommen werden, groessere
Bibliographien vollautomatisch und 100% RAK-konform
in Druckformate zu ueberfuehren.

viele Gruesse
Thomas Berger
----------------------------------------------------------------------
Zum Austragen aus dieser Liste senden Sie bitte eine Mail an
majordomo at ddb.de mit unsubscribe mab-list im Textfeld.