[rak-list] Indexierungsregeln

[Thomas Berger]

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

Lieber Herr Eversberg,

|>- - Die "Beseitigung von Dreifach-Kleinbuchstaben" halte ich fuer hoechst
|>~  problematisch:
|
| Nicht, wenn man zugleich, wie empfohlen, die Beseitigung auf die
Nutzereingabe
| gleichermassen anwendet! Dann merkt er das gar nicht und wird alle
Seelefanten
| finden, egal ob die Schreibweise in den Dokumenten eee ist oder ee,
oder ob der
| Nutzer ee oder eee eingibt! Ohne diese Methodik wuerde immer einer der
beiden
| Anteile nicht gefunden. Selbst der Blick ins Register hilft bei sehr
grossen
| Datenbanken oft nicht weiter, die Dinge stehen trotzdem zu weit
auseinander.

Es steht den OPACs frei, irgendeine Form phonetischer Suche zu
implementieren. Hier ging es aber um die fuer die Benutzer sichtbaren
Register (so hatte ich es verstanden). Ich finde, man sollte (in der
Realitaet aber auch durchaus im Regelwerk) den Ansatz verfolgen, bei
formulargesteuerter Suche tendenziell etwas staerker zu normieren als
beim Browsen. Bei ersterem *koennte* ein OPAC kommentarlos alle Treffer
liefern oder auch (Woerterbuch- bzw. thesaurusgestuetzt, ontology-driven
:-) versuchen, weitere Suchworte vorschlagen. Das Regelwerk sollte hier
nicht vorgreifen, indem es zu speziell vorschreibt, alle Schreibweisen
zu planieren, so dass fuer (zukuenftige) behutsamere Algorithmen kein
Raum mehr bleibt.

Fuer die Register sehe ich es aehnlich, nur sollte sich die
Praesentation der findbaren Begriffe naeher an der Vorlage orientieren.
Wenn dort "Seeelefant" mit drei "e" steht, dann muss es auch darunter
findbar sein (und es betrifft hier nicht nur die automatische Normierung
der Eingabe, sondern auch das Zeigen einer Wortliste). M.E. sollte
fuer Wortlisten das Regelwerk explizit sagen, dass orthographische
Normalisierung - auch teilweise - optional ist, Vorlagentreue jedoch
wichtig (wenn auch nicht unbedingt zwingend, was Akzente, Gross- und
Kleinbuchstaben, Interpunktion) angeht.


| Diese Formulierung ist mir entschieden zu heftig. Und *den* Stand der
Technik
| gibt es doch in unserem Bereich gar nicht! Wo waere der nachzulesen?

Heute oder morgen ;-? Ich stelle mir das durchaus schwierig vor fuer
das Regelwerk, Forderungen an die Funktionalitaet von Katalogen zu
stellen, ohne dass ein Minimalstandard auf ewig festgeschrieben wird
oder - im anderen Extrem - keine real existierende Software
uebrigbleibt. Ich sehe aber genau wie Sie die Notwendigkeit, dort
etwas vorzuschreiben, damit sich nicht die Traegheit der Software-
hersteller in unsinniger Mehrarbeit fuer Katalogisierer niederschlaegt.

Klar ist z.B., dass es Wortlisten (Indexregister) zum browsen geben
soll. Diese haben in bester Katalogtradition den Zweck, aehnliches
zusammenzufuehren und verschiedenes zu unterscheiden. *Vermutlich*
laesst sich dieser Zweck durch Serialisierung am besten erreichen
(also alphabetische und/oder numerische Sortierung). Klar ist auch,
dass fuer Bindestrichwoerter zusaetzliche "Binnen-"Treffer ermoeglicht
werden sollen. Schon weniger klar ist, ob diese Binnentreffer auch
in den Wortlisten zum Browsen auftauchen sollen (eine Software, die
bei einer Recherche in den internen Indizes oder im Volltext *Worte*
erkennen kann, kann auch das "Anna-Selbdritt-Tryptichon" finden, wenn
nach "Selbdritt" gesucht wird, muss auch beim Browsen ein Treffer /
eine Anzeige bei "Selbdritt" sein?).

Nicht geregelt werden sollten Aspekte der Praesentation: Ob eine
Wortliste zwei Zeilen zu "Caesar" und "Cäsar" direkt hintereinander
anbieten soll oder nur eine zu "caesar" finde ich nicht regelungswuerdig
(in der Kartenwelt hatten wir so etwas auch nicht) und - vgl. meine
vorige Mail - auch fuer schaedlich.


|>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!).
|
| Das mag ja so sein, aber es ueberzeugt mich nicht - ich meine, dass
noch viele
| Systeme von diesem Stand etwas weiter entfernt sind.

Klar.


| Eines der Probleme dabei: Wenn Woerter mit verschiedener Schreibweise
| aufeinandertreffen, die durch die Normierung gleich werden, wie sollen
sie denn
| dann im Index erscheinen? Trotzdem zwei oder mehr Schreibweisen
untereinander?

Muss das geregelt werden? Hauptsache sie stehen beieinander.


| Und jede soll dann dennoch die komplette Ergebnismenge liefern - oder
nicht?

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:

shakespere, william  -> shakespeare, william
shakspear, ... -> shakespeare, william
shakspear, william  -> shakespeare, william
shakspeare, ...-> shakespeare, william
shakspeare, guglielmo -> shakespeare, william
shakspeare, guillaume -> shakespeare, william
shakspeare, william -> shakespeare, william
shakspere, william -> shakespeare, william

Auch hier sollte der Software die Freiheit gelassen werden, Verweise
zu realisieren (wie hier gezeigt) oder hinter jeder Namensform alle
Treffer zur Ansetzung (falls die Software mit "Ansetzungen" arbeitet,
sie koennte die Normdatei auch zur Bildung von "Aequivalenzen" nutzen,
wenn sie symmetrisch mehrsprachig funktioniert) anbieten.


|>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!
|>
|
| Es gibt aber wohl sehr weniges, wovon man wirklich ausgehen kann. Das
macht die
| Sache schwierig.

Man kann und sollte Forderungen stellen. Dabei aber vor allem immer den
Zweck der Forderung ganz deutlich mitformulieren. Dann kann 2007 eine
Software diesen Zweck mit voellig anderen Mitteln erfuellen, als wir
uns heute vorstellen koennen. Es darf nicht zu dem Paradox kommen, dass
sich Kataloge rechtfertigen muessen, die zwar perfekt sortieren koennen,
aber es versaeumen, das Sortierergebnis brachial normiert anzuzeigen.

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

iD8DBQFAcWtzENVh3bB0lwMRAgqlAKCvkBJwM+dSEpefZiz6EeS9kikEiwCdGHuJ
3QbttefhMAZluZpy0Fjttjw=
=WLAo
-----END PGP SIGNATURE-----