[rak-list] Indexierungsregeln

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Liste,

| Nach der Diskussion der letzten Tage habe ich das Indexierungspapier:
|
| http://www.allegro-c.de/formate/indxierg.htm
|
| nochmals überarbeitet und erweitert. Es soll als Vorbereitung und
Einführung für
| die nun zu formulierenden Regeln als Teil der RFK dienen. (Die Regeln
müssen die
| formale Paragraphenstruktur haben, die für RFK gelten soll und dürfen
nicht so
| weitschweifig sein wie dieses Papier.)
|
| Bevor darangegangen wird, die Regeln zu formulieren, soll aber hiermit
das
| vorliegende Papier nochmals einer Diskussion ausgesetzt werden.

Ich habe leider nicht die Zeit, mich tief genug mit dem Papier
auseinanderzusetzen, daher nur kurz:

- - Sonderregeln fuer die Erkennung und Behandlung von Akronymen mit Punkt
~  machen m.E. Sinn, falls diese nicht (s.u.) mit anderen Mitteln
~  zusammengefuehrt werden koennen.

- - Regeln fuer die Bildung von Zusatzindexaten bei Bindestrichwoerten
~  machen m.E. viel Sinn

- - Die "Beseitigung von Dreifach-Kleinbuchstaben" halte ich fuer hoechst
~  problematisch: Jemand formuliert 2004 der besseren Lesbarkeit wegen
~  "See-Elefant" und das wird dann auf das aus zwei Gruenden schlechter
~  lesbare Seelefant der alten Orthographie normiert. Es gibt vermutlich
~  genug andere Stellen, wo man alte und neue (und was ist mit der von
~  vor 1890?) Orthographie nicht maschinell zur Deckung bringen kann
~  ("ph" und "f" etwa), hier sollte man es m.E. auch nicht versuchen,
~  auch wenn es moeglich waere.

- - Normierung durch Wegwerfen von Bindestrichen halte ich fuer absolut
~  unlesbar

- - Titel und Zusaetze: Gibt es nicht Regelwerke (oder nur Datenformate?),
~  die zwischen formalen Sachtitelergaenzungen (". Roman") und "echten"
~  unterscheiden? Wegen Altdaten und Interpretationsspielraeumen bei
~  Bestimmung kuenstlicher Verfasserschaft und Sachtitel halte ich es
~  fuer wichtig, auch die Zusaetze stringzuindexieren.

- - Die Problematik der Eckigen Klammern als Ergaenzungen (Inhalt ohne
~  die Klammerzeichen mitzuindexieren) bzw. Alternativen (voran geht
~  eine in Nichtsortierzeichen umschlossene Sequenz) bei Titeln in
~  "Mischform" ist m.E. richtig erkannt und behandelt. Allerdings
~  moechte ich den Eintrag "vierhundertsechsundachtziger und Pentium"
~  nicht missen (das ist aber wohl nur ein Formulierungsproblem in
~  dem entsprechenden Absatz)

- - Am wichtigsten ist mir aber, dass der vorgeschlagene Algorithmus
absolut anachronistisch ist und den Stand der Technik voellig ausser
Acht laesst: Ziel ist es ja, dass auch in einem Index oder Register
~aehnliche~ Worte beieinander stehen, Ziel ist es *nicht*, dass dort
alles in Kleinbuchstaben steht. Stand der Technik ist "multi-level
sorting", d.h. Zeichenketten werden nicht transformiert ("See-elefant",
"seeelefantig", "séelenfant") und das Resultat primitiv sortiert,
sondern sie werden so gelassen, wie sie sind und dann sortiert. Ein
Beispiel hierfuer ist der Unicode Collation Algorithm (vgl. <
http://www.unicode.org/reports/tr10/ >, da gibt es auch viele
Beispiele!).

Im Register stuenden dann die Begriffe unmittelbar beeinander, jedoch
in ihrer urspruenglichen Form:
See-Elefant
Seeelefant
séeelenfant
Eine (Formular-, Freischuetz-, whatever) Suche hingegen (nach "see-el*")
wuerde eine groebere Aequivalenz benutzen und alle auf einmal treffen.

M.E. darf das Regelwerk von der Indexierung nur fordern, dass
aquivalentes (im vom Regelwerk zu spezifizierenden Sinn, also etwa,
dass "-" wie in den alten RAK-Sortierregeln keinen Sortierwert
haben soll, dass Gross-Kleinschreibung und Akzente nicht von Belang
sein sollen) im Register entweder zusammengefuehrt werden muss oder
aber unmittelbar beieinander auftreten soll (auch das ist schliesslich
"Zusammenfuehren").

- - Fuer Umlautbuchstaben wurde richtig bemerkt, dass auslaendische
~  Benutzer ein "ü" vermutlich als "u" suchen: Die Tastatur erlaubt
~  nicht die Eingabe von "ü" und der kulturelle Hintergrund wird den
~  Unterschied als nicht gross erachten, evtl. wurde auch bereits
~  falsch zitiert. Die Regeln koennten vorschreiben, dass die
~  "Sortiersprache" Deutsch ist, d.h. die Umlaute gemaess unseren
~  Traditionen sortiert werden, jedoch [optional, je nach Zielgruppe]
~  auch die Grundbuchstaben-form gesucht und gefunden werden koennen
~  muss. Dies kann durch eine Zusatzindexierung erreicht werden, evtl.
~  aber auch mit anderen Mitteln (ein besonders fortgeschrittener
~  Katalog benutzt etwa abweichende Collation Tables je nach Sprache
~  des Benutzers). Zu beachten ist ja, dass die Indizes (bzw. deren
~  Ausschnitte!), die dem Benutzer praesentiert werden, ja nicht
~  unbedingt praekombiniert sein muessen, sondern vielleicht auch
~  "live" aufgebaut werden koennen. Jedenfalls sollte man nicht
~  davon ausgehen, dass diese Benutzer-Indizes oder Register identisch
~  sind mit den Tabellenindizes, die das zugrundeliegende Datenbank-
~  system zur eigenen Optimierung nutzt!

- - Die Regeln sollten nicht zementieren, dass es einen fundamentalen
~  Unterschied zwischen Umlautbuchstaben und solchen mit Dieaerese
~  gibt. Ich will diese alte Diskussion hier nicht wieder aufgreifen,
~  daher nur so viel:
~  * Beharren auf dem Unterschied hilft keinem Benutzer
~  * Es gibt keine Datenbank- oder Anwendungssoftware, die den
~    Unterschied beherrscht
~  * Auszaehlen eines groesseren Datenbestands hat m.E. gezeigt,
~    dass es auch keine Daten gibt: ca. 50% der Zeichen, die (in der
~    verschwindenden Menge von Faellen, wo es nicht sowieso nur eine
~    Interpretation gibt) behaupteten, dass sie Trema statt Umlaut seien,
~    waren Fehlerfassungen

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAcR5rENVh3bB0lwMRAgvBAJsGCe1e+LrcwK1YZ+06QrLg52imsgCfa70z
rRqr9cs1Fbr9G+rt9bJU36M=
=HX3P
-----END PGP SIGNATURE-----