[rak-list] Indexierungsregeln
Thomas Berger
ThB at gymel.com
Mon Apr 5 10:52:59 CEST 2004
-----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-----
More information about the rak-list
mailing list