[Allegro] Beobachtungen zu Volltextsuche(n)

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

ich habe leider die Diskussion neulich nicht verfolgt, wo es
um die Gelegenheiten ging, wann welcher Hilfetext eingeblendet
wird und weiss auch nicht, was sich daraufhin geaendert hat,
also vergleichsweise "frisch" ist.

In einer Ergebnismenge kann man ueber das Fernglas-Menue ("Finde-
Menue" beim Einstieg ueber Menue->Finden) eine Volltextsuche
absetzen, und dort auch nach Unterfeldern suchen, etwa als

#99,▼o

(treffe alle Saetze, die in irgendeinem #99er Datenfeld ein Unterfeld ▼o
haben)

Die Erlaeuterung der Syntax solcher Suchen ist notorisch schlecht
findbar, frueher gab es den Hinweis, dass es dieselbe Syntax wie
fuer die Suchbefehlszeile ist: Positioniert man die Maus dort und
gibt F1, so erscheint die Hilfeseite "cmmd", die dieser Suche einen
Absatz widmet: "." maskiert und Eingabe von Umlauten ist moeglich.

Ueber Menue->Finden gelangt man alternativ zur "Volltextsuche",
da muss man sich entscheiden, ob man suchen will oder die Hilfe
konsultieren ("am besten ausdrucken": Ist /das/ das Ergebnis der
Diskussionen mit Herrn Fischer?). Hier gibt es recht weit am
Anfang den Hinweis, dass Umlaute aufzuloesen sind, spaeter dann
versteckt der Hinweis, dass das stanadardmaessig ueber die
Umcodierung der Indexparameter abgewickelt wird. Das erklaert
natuerlich auch, warum ich nicht nach "▼" suchen kann: Das wird
seit spaeten V23'ern auf "/" abgebildet (Kommentar dazu: wegen
zu ergaenzender Urheber, d.h. die problematische Syntax im
Datenformat zu #20 wird dadurch getoppt, dass die Indexparameter
zu faul sind, diese Situation explizit zu behandeln). Ich kann
also suchen nach

#99.*/o

aber dafuer muss ich vorher die Indexparameterdatei konsultieren,
denn nur dort kann ich nachlesen, dass derzeit "▼" auf "/" umcodiert
wird und ich letzteres daher einzugeben habe. D.h. was fuer "normale"
Suchbegriffe mit Umlauten nur laestig ist (ich bin selber fuer
Kleinschreibung und Umlautaufloesung zustaendig), ist fuer Sonder-
Zeichen schlichtweg aussichtslos.

Die Beispiele in ftr.txt sind konsistent, diejenigen, wo "▼"
vorkommt, schalten via "_" die Umcodierung aus. Suche muss fuer
das obige Beispiel also eingegeben werden als

_#99.*▼o

Einen Weg, tolerant nach "Müller" oder "Mueller" in Unterfeldern
zu suchen, gibt es anders als bei der Volltextsuche ohne regulaere
Ausdruecke wohl nicht (diese kann aber ohnehin nicht "in"
Unterfeldern suchen, hoechstens nach Begriffen irgendwo nach dem
einschlaegigen Unterfeldzeichen, evtl. also in einem folgenden
Unterfeld...).

Unmittelbare Handlungsmoeglichkeiten sehe ich nicht (Handlungsbedarf
jedoch schon: Fuer meinen Geschmack muss ein Nutzer viel zu viel
wissen, um halbwegs erfolgreich suchen zu koennen), mittel- oder
langfristig gibt es jedoch einige Moeglichkeiten:

* Zunaechst einmal bedarf es einer regular expression library, die
  die Treffer markieren kann: Sei es fuer Ersetzungen oder fuer
  Syntax-Highlighting: Derzeit bekommt man ja nur ja/nein-Antworten,
  der Suchbegriff ist im Satz / im betrachteten Ausschnitt ein
  Treffer, aber welche Zeichenkette in welchem Datenfeld, ob ein
  oder mehrere Treffer vorliegen: Das kann nicht ermittelt werden.
  Und solange dem so ist, braucht es die zahllosen anderen Ersetzungs-
  befehle, von denen niemand so genau weiss, welche syntaktischen
  Spezialitaeten da gelten.

* die "bibliothekarische" (deutsche Telephonbuch)-Umcodierung "ue"
  vs. "ü" ist in unserer Tradition wichtig, aber das "ü" koennte auch
  als "ü" oder "ü" oder separat als Diaerese plus u in
  diversen Codierungen erfasst sein: Je nach gewaehlten V23-Einstellungen
  und Quelle von Fremddaten ist das in realen Datenbanken zu $A.CFG
  bereits alles moeglich, vorgesehen und implementiert: Gewisse Normierungen
  vor dem eigentlichen Vergleich werden also zunehmend wichtiger.
  Sie duerfen m.E. aber nicht willkuerlich sein, sich insbesondere
  nicht auf Sonder- und Steuerzeichen beziehen und muessen den
  Suchbegriff (genauer: Seine textuellen Terme) auch beruecksichtigen.
  Sobald in den allegro-Modulen intern staerker mit UTF-8 gearbeitet
  wird, haben wir hier die Unicode-Semantik uebernommen, d.h. es gibt
  Regeln und Tabellen, die Aequivalenzen bestimmen, "zugehoerige" Gross-/
  Kleinbuchstaben deklarieren, definierte Normalformen und vieles mehr:
  Man muss da nicht alles neu erfinden.

* Da "Markieren des getroffenen Abschnitts" und "Normierung vor dem
  Vergleich" tendenziell im Konflikt stehen (extremes Beispiel: Von
  Zeichen, die ich ganz ausblende, kann ich nicht entscheiden, ob
  sie unmittelbar vor dem Treffer stehen oder an seinem Anfang),
  haengt ansonsten viel von den Faehigkeiten der Library ab: Diese
  wird bestimmen, welche Vorab-Aufbereitung der Suchterme erforderlich
  ist und welche Stellschrauben es gibt.

viele Gruesse
Thomas Berger