[Allegro] Stopwortliste
Thomas Berger
ThB at Gymel.com
Fr Jan 9 00:23:44 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hallo Herr Wolf,
> Ich habe eine Indexparameterdefinition mit Umcodierung
>
> ic=1
>
> und der Stopwortliste
>
> tswl1
>
> Und jede Menge an symbolischen Registern.
>
> Die Stopworte sind nach der Reorganisation nicht mehr in den Registern zu
> finden. Aber bei der Suche werden diese Stopworte nicht automatisch
> eliminiert.
>
> Beispiel:
>
> Aus dem Titel 'Aus dem Himmelreich' wird nur 'himmelreich' indiziert. Das
> ist korrekt.
>
> Aber wenn ich nach 'aus dem himmelreich' suchen lasse, findet allegro
> nichts, sollte aber die Datensätze mit 'himmelreich' finden. Die Stopworte
> werden nicht automatisch entfernt.
>
> Was mache ich falsch ?
Je nachdem:
Es gibt ja zunaechst keinen Suchmodus, der
find REG "Aus dem Himmelreich"
automatisch in eine kombinierte Suche
find (REG "Aus") AND (REG "dem") AND (REG "Himmelreich")
umwandeln wuerde, es sei denn, Ihre Web-Anwendung leistet dies (und die
muss dann dummerweise tatsaechlich die Stopwortliste der Indexparameter
kennen und kann nicht an allegro delegieren).
D.h. zunaechst einmal ist "falsch", dass Sie eine Suche fuer ein
Title-string-Register absetzen, so ein Register aber gar nicht
haben, denn "Aus dem Himmelreich" als ganzes ist nach Ihrer Beschreibung
ja gerade nicht indexiert.
Ein verwandtes Problem gibt es allerdings bei den Uebergehworten / der
Artikelliste auch bei Vorhandensein eines String-Registers:
"Des Knaben Wunderhorn" ist typischerweise als "¬Des¬ Knaben Wunderhorn"
erfasst und als "Knaben Wunderhorn" indexiert. Suchbegriff kann aber
auch "Des Knaben Wunderhorn" sein, Benutzern kann man nicht unbedingt
klarmachen, einleitende Artikel wegzulassen und noch weniger, sie in
Alt+170-Zeichen einzuschliessen ;-).
Auch hier muss entweder die Indexierung auch die Form mit Artikel
vorhalten und/oder die den avanti-Job zusammenbauende Anwendung muss
eine eigene Artikelliste fuehren und gegebenenfalls automatisch
die Suche erweitern:
find (REG "Des Knaben Wunderhorn") OR (REG "Knaben Wunderhorn").
Ganz vertrackt wird es bei Personennamen, wenn der Nachname ein
Prefix hat, das zur Ordnungsgruppe des Vornamens genommen wird
(aber auch dort nach strenger Lehre nicht sortierrelevant ist):
Beethoven, Ludwig ¬van¬
wird stets als "Beethoven, Ludwig" indexiert, Benutzer suchen
aber gerne nichtinvertiert nach "Ludwig van Beethoven". Auch hier
benoetigt man eine Kombination aus schlauer Suchbegriffsaufbereitung
(in den Faellen von Eingaben ohne Komma) plus eventueller
Doppelindexierung im Fall von Uebergehworten im Personennamen plus
u.U. spezieller Analyse von Praefixen bei der Suchbegriffsaufbereitung.
Es ist aber wirklich schwierig, da sehr kulturspezifisch: Je weiter
man nach Suedwesten kommt, umso eher wird der angesetzte "Meier, Peter"
natuerlich-sprachlich nicht als "Peter Meier" gesucht sondern als "MEIER
Peter" und man kann sich nicht einmal darauf verlassen, dass die
Leute ihrem Browser "DE-AT" oder "DE-CH" als Standardsprache eingestellt
haben...
viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBSWaLAGITJZieluOzAQJKKQP/a4VwwYj/YI65iq5TmFl4SNzXqhlw4pHR
zOGuE+66a4cFfLraZIhSgCm2beIl/YDloKAtZY7d9sEwXD/WDyVx6VoRs9LwRM+L
zaYaziCP/GB/HizT1DH5SE1ZEeaHiY+OqI5Ym7/8x3Ac70V/1PBb/KRr0w76BzTG
HxuFRgSYVE4=
=AC7f
-----END PGP SIGNATURE-----
Mehr Informationen über die Mailingliste Allegro