[rak-list] Indexierungsregeln

[Thomas Berger]

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

Lieber Herr Eversberg,

|>Man koennte Checkboxes davor setzen. Oder auch nicht. Wenn es zu einem
|>Begriff so viele verschiedene Schreibweisen gibt, dass es wirklich
|>unuebersichtlich wird, muesste man hier etwas regeln, sonst nicht.
|>Eine gewisse orthographische Normierung findet ausserdem bereits bei
|>der Katalogisierung statt: Beginnt der Titel mit "Égal", so muss doch
|>lt. deutscher Interpretation franzoesischer Orthographie "Egal" erfasst
|>werden, nicht wahr?
|>
|>Bei Normdaten haben wir etwas aehnliches:
|>
|
| Das ist was ganz anderes! Die Eintraege zum Normsatz entstammen alle dem
| Normsatz. Daher kann das Programm dann in jedem Fall ueber den
Normsatz suchen.
| Titelwoerter entstammen jedoch jeweils einem bestimmten Titelsatz.

Das ist ein denkbares Szenario. Es koennte aber auch in einer Datenbank
franzoesische Titel geben in denen "Goethe, Jean Wolfgang (1749-1832)"
steht und in italienischen steht "Goethe, Giovanni W. (1749-1832)" und
der Katalog fuehrt diese ueber den Normdatensatz zusammen. D.h. die
Katalogisate bevorzugen keine Ansetzungssprache, erst "der Katalog".
Der wuerde dann tendenziell auch im Index keine Verweisungen liefern
sondern unter jeder denkbaren Namensform alle Treffer auffuehren.

| Und wenn nun Brennessel und Brennnessel beide vorkommen, stehen die
nicht so nah
| beisammen, dass der Nutzer es sieht! Er kriegt also nur jeweils eine
Teilmenge,
| wenn man das mit der Normierung auf Brennessel nicht macht.
| Ohne die R-Reform waere das mit den Dreifachbuchstaben ja nicht so
schlimm, aber
| nun nimmt es tendentiell zu. Nein, tendenziell...

Aehnlich schrieb ich, aber "andersherum" haette ich ergaenzen sollen:
In einem Sachkatalog sollte man "Brennessel" und "Brennnessel"
zusammenfuehren (aber besser ueber ein Woerterbuch bzw. einen
woerterbuchgenerierten Thesaurus, nicht durch simplistische
Indexierungsvorschriften), bei Titelstichwoertern wuerde ich es
anders sehen: Eine Formularsuche mag so verfahren (d.h. mit
suchunterstuetzendem Thesaurus oder eingebauter Rechtschreib-
korrektur oder wie man es nennen mag, optional auch abschaltbar),
bei Wortlisten im Sinne von Indexregistern, wo man ja "sieht",
was fuer merkwuerdige Wortverstuemmelungen so auftauchen, ist
es nicht so wichtig und schadet m.E. auch der Transparenz:
Die Liste von Worten suggeriert viel staerker als ein leeres
Formular zum Ausfuellen, dass die angezeigten Worte in den
dahinterliegenden Treffern vorkommen.

Wir haben Datenfelder mit kontrolliertem Vokabular (Ansetzungen,
Sacherschliessungen) und solche ohne. Den Unterschied wird man
vor dem Benutzer nicht verbergen koennen, und wohl auch nicht
wollen.


| Also: wenn er Brennnessel oder Brennessel eingibt und landet im
Register bei dem
| einzig vorkommenden Wort "Brennessel", dann haette er jeweils alles.

Optional koennte eine Katalogsoftware linguistische Komponenten
haben und dann alle Brennnesseln zusaetzlich als Brennessel
verstichworten und umgekehrt. Dann haette der Benutzer ebenfalls
alles und wuerde nicht stillschweigend auf andere Alphabetstellen
gefuehrt als eingetippt (hier sehe ich einen Zielkonflikt: Fuer
Formularsuchen sollte weitgehend unsichtbar in die Benutzereingabe
eingegriffen werden, fuer Registersuchen aus naehliegenden Gruenden
weitgehend nicht. Aber eine automatische Umschaltung, zumindest in
den Ein-Wort bzw. Ein-Begriff-Suchen, die ja die Mehrzahl aller
Suchen ausmachen, soll auch sein).

Wie solche linguistischen Komponenten zu realisieren sind, sollte
das Regelwerk nicht regeln, sicherlich gehoert normalerweise mehr
dazu als nur das Normieren von dreifachen Kleinbuchstaben. Umgekehrt
sollte aber die Forderung nach der Normierung dreifacher Kleinbuchstaben
aus den Indexierungs- und Ordnungsregeln fuer Kataloge unbedingt
entfernt werden.

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

iD8DBQFAcZKGENVh3bB0lwMRAvNPAJ9JvsnMzZbvT1ERmOmhujKF+KPafACdGR7V
F/2ViYJUuv2bmn7mQZJIjuk=
=XIgT
-----END PGP SIGNATURE-----