[Allegro] Feature request: Variable Trunkierungen in acon

[Thomas Berger]

Lieber Herr Lackhoff,

>> Eine Trennung in Serientitel- und Serienstueckregister (und Zeitschriften-
>> titel, Zeitschriftenjahrgang, Zeitschriftenfundstellenregister?) wie
>> von Ihnen vorgeschlagen stelle ich mir nicht einfach vor: Da muesste
>> ja im Browser die Logik hinterlegt werden, ab wievielen bzw. welchen
>> Zeichen der Benutzereingabe die Suggestions vom einen auf das
>> andere Register umgeschaltet werden. Oder hatten Sie im Sinn, dass
>> der Benutzer sich vorab fuer das eine oder das andere entscheiden
>> muss? Das faende ich aber eine enorme Zumutung.
> 
> Nicht im Browser und sicher auch nicht vom Benutzer, sondern in der
> (Web-)Anwendung. Die muesste die Logik enthalten, die meist sehr einfach
> sein kann. Wobei man dann immer noch sehen kann, wie viel von der Logik
> in (evtl. generierte) jobs geht und was direkt in PHP, Perl oder was
> auch immer gemacht wird.
> 
> Pseudocode-Beispiel:
> If (treffer in Serienindex) {
>   # <serientitel> trifft
>   # <serientitel> ; trifft nicht
>   zeige_die()
> }
> elsif (treffer in stuecktitelindex) {
>   # <serientitel> ; trifft
>   zeige_die()
> }
> else {
>   evtl_weitere_varianten()
> }

Warum muss ich den Index befragen, wenn ich doch anhand des
Suchbegriffs bereits sehen kann, ob es Treffer geben wird,
also ist es serverseitig auch nur der Fall des naechsten
Beispiels:


> So etwas sollte sich doch in Flex machen lassen, jedenfalls erinnere ich
> mich, aehnliche Jobs schon vor vielen Jahren auf avanti losgelassen zu
> haben.
> Auf jeden Fall geht aber doch das, was Sie sich von acon wuenschen
> (diemal nicht im job sondern in der Anwendung):
> if ($nutzeranfrage =~ / ; /) {
>   suche_stuecktitelindex()
> }
> else {
>   suche_serienindex()
> }

Beide Ansaetze haben dasselbe Problem:
Es wird aus dem Serienindex nie eine Completion kommen, die " ; "
enthaelt und die Weiche triggert, also kann man sich den Stuecktitelindex
direkt sparen, nicht nur hier sondern ueberhaupt...

Eine kompliziertere Logik mit Vorabkonsultationen ist m.E.
durchaus legitim, das muss aber im Job stattfinden, also
von avanti/acon mit sich selbst ausgemacht werden. Oder aber
das Ergebnis kann gefiltert werden, da sehe ich aber das
"uebliche" Problem, dass ich beim "qrix" nicht weiss, wieviele
Zeilen ich anfordern muss, um nach dem Filtern noch eine hinreichende
Anzahl uebrig zu haben, die dem Benutzer praesentiert werden
kann.

Vorab-Filter, etwa durch Normsaetze und Restriktionen, funktionieren
perfekt und effizient, vgl.
< hansdemo.gymel.com/cgi-bin/hansdemo.pl?t_tunnel=acindex&index=PER >
mit dem "Klopstock"-Eingabebeispiel:

Im eigentlichen Index sind die Ansetzungen meist um Lebensdaten
ausdifferenziert, d.h. ein Benutzer kann die nur tendenziell
vorab kennen und es ist ein guenstiger Anwendungsfall fuer
Autocompletions. Im Index sind die Objektsaetze aber noch durch
angehaengte Materialart und Funktionskennung ausdifferenziert,
die Anfrage nach dem Registerauszug fuer die Search Suggestions
setzt aber die Restriktion "nur Personennormsaetze" (und die
angebotenen Reihungen sind nicht so umfangreich, dass der
von mir bei Ihrem Vorschlag vermisste "Uebergang" in die differenzierte
Situation noetig waere)

In meinem vorigen Beispielen mit Schlagwort- oder Serienregistern
funktioniert der Ansatz aber nur beschraenkt, da dort in der
Praxis die Datenbanken nicht mit Normsaetzen gesaettigt sind
bzw. auch die Regelwerke (ungezaehlte Reihen) dagegen arbeiten.

Ich habe auch schon darueber nachgedacht (jetzt wieder bezogen
aufs Stuecktitelregister) die Qrix-Resultate im Job in eine
$-Variable zu packen und diese dann nach diversen Trunkierungen
auszuwerten, ggfls. weitere qrix-Resultate anzufordern und
dazu zu packen, etc. Damit bin ich noch nicht weit gediehen,
vermutlich wuerde das aber ein paar Feature-Requests zu $-Variablen
als Folge haben ;-)

viele Gruesse
Thomas Berger