[Allegro] Feature request: Variable Trunkierungen in acon

[Anando Eger]

Lieber Herr Berger, lieber Herr Eversberg,

ThB:
> x var ""\qrix f1\qrix PER "shak"\ins _^I_<TAB>_\ins _^T_^J_\mess
> 
> zeigt, dass auch die a99-Version von heute morgen noch die von
> Ihnen neulich bemerkte ungute Verklebung von Indexzeile und
> Satznummernliste hat.

Schön, dass Sie das noch mal ansprechen - das war mir neulich mal 
wieder auf die Füße gefallen - im Index gab es ":"-Zeichen.

Ich bin dann auf qrix f 3 ausgewichen - ist aber nicht schön, da dadurch 
die Unterschiede zur korrespondierenden Funktion unter avanti/acon wieder 
größer werden.

Herr Eversberg: Wie groß wäre der Aufwand, beim Ergebnis von qrix f 1
den fehlenden TAB vor der Liste der Satznummern zu ergänzen?

ThB weiter:
> Ich sehe eigentlich kein Umcodierungsproblem, solange der
> Mechanismus Indexzeilen und nicht Datensaetze auswertet.

mmm. Spontan fällt mir dazu ein:
- ich denke an wunderschön strukturierte Signaturenregister, deren
  Form mit der der Sucheingabe oft nur wenig zu tun hat
- das "Wegoptimieren" von Sonderzeichen im Index dürfte dann nicht
  mehr zugelassen werden
- der Umgang mit Umlauten muss dann im php/perl-Code, im Flex und in
  den Registerparametern immer synchron gehalten werden

Viele Grüße
Anando Eger


On 4 Oct 2012 at 10:41, Thomas Berger wrote:

> Lieber Herr Eger, lieber Herr Eversberg,
> 
> 
> Am 04.10.2012 10:06, schrieb Anando Eger:
> > Hallo Herr Berger,
> > 
> > Ihre Wunschliste  (1...4) sollte sich in ein Allegro-Flex-UP
> > packen lassen.
> > 
> > Als Parameter könnte ich mir vorstellen:
> >  - bisheriger Suchbegriff
> >  - Trennzeichenliste
> >  - max. Anzahl der zu liefernden Einträge
> >  - max. Länge eines Eintrags
> > 
> > Damit könnte man erst mal experimentieren und das fertige
> > Verfahren dann evtl. in eine neue Allegro-Flex-Funktion gießen.
> 
> klar.
> N.B.:
> 
> x var ""\qrix f1\qrix PER "shak"\ins _^I_<TAB>_\ins _^T_^J_\mess
> 
> zeigt, dass auch die a99-Version von heute morgen noch die von
> Ihnen neulich bemerkte ungute Verklebung von Indexzeile und
> Satznummernliste hat.
> 
> 
> > Noch nicht angesprochen wurde hier die Problematik der
> > Umcodierung. Zu lösen wäre das meiner Meinung nach nur
> > durch einen Wunsch #5 (Berücksichtigung der Umcodierungsmarken
> > in der dbn.?pi) oder durch spezielle Sonderregister für die 
> > Verwendung mit der Autovervollständigung (diese könnten
> > auch Verarbeitungszeit sparen).
> 
> Ich sehe eigentlich kein Umcodierungsproblem, solange der
> Mechanismus Indexzeilen und nicht Datensaetze auswertet.
> Feste Trunkierungen an Zeichenpositionen sind allerdings
> gerade nach switch coding problematisch, klar ist, dass
> UTF-8-Sequenzen nicht zerhackt werden duerfen und der
> Benutzer ohnehin Zeichen will und nicht Bytes, unklar ist
> aber, ob die Akzentvertauschung nicht besser vor der
> Trunkierung ausgefuehrt werden sollte...
> 
> Auch eine VuFind-artige Variante, die mir gerade eingefallen
> ist, hat keine Umcodierungsprobleme: alle Eingabeworte im
> All-Register ver-ANDet suchen, die Ergebnismenge durchaspeln
> und die Indexschluessel einsammeln, diese nach dem aktuellen
> Register filtern und (mittels $-Variable muesste das einfach
> sein) sortiert ausgeben: Dann hat man Search Suggestions,
> die das ganze Register abdecken ("William" schlaegt "Shakespeare"
> vor) mit einer tendenziellen Haeufung (hoffentlich) bei den
> Eintraegen, die so aehnlich sind wie die Eingabe...
> 
> viele Gruesse
> Thomas Berger
>