[Allegro] Neue cat.api schon im SVN

[Thomas Berger]

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

Liebe Liste,

Am 30.07.2010 08:04, schrieb Bernhard Eversberg:
> Klaus Lehmann schrieb:
>>
>> mir fällt erstmal diese zeile auf.
>> " EJahr an Verlag u. Ort angehaengt ist obsolet"
>> warum ist sie "obsolet"?
> 
> Das war Bergers Meinung, die wir sehr schätzen und in diesem Fall
> sofort umgemünzt haben. Es wurden 4 Zeilen eingerückt, die man
> bei Bedarf wieder aktivieren kann.

Es ist schon so, dass die angehaengten Erscheinungsjahre das
Register zum Browsen brauchbar machten (in gewisser Weise, Verlags-
und Ortsnamen der Vorlage werden nach RAK ja nur leicht gebuerstet
und nicht stringent normiert, ~gleiches~ ist im Register also nicht
zusammengefuehrt). Diese Praekombination macht die Registerinhalte
aber ziemlich unbrauchbar fuer "normale" Suchen: Um "Suhrkamp" zu
finden muss man entweder Trunkierung erzwingen oder ausgekluegelt
im Hintergrund an den Suchbegriff ",?" anhaengen (und bei Ortsnamen
wuerde man sich u.U. eine echte Verstichwortung wuenschen, um die
diversen "Frankfurt/M". "Frankfurt a.M." zu erwischen, auch um den
Preis, dass Frankfurt a.d.O. nicht mehr trennbar ist).

Mit obsolet (oder schrieb ich "nicht mehr zeitgemaess") sollte
angedeutet werden, dass ein Register, das eigentlich nur zum Browsen
taugt, in Webumgebungen hoechst problematisch ist (umgekehrt ist
allerdings die Faehigkeit, durch Praekombination Inhalte browse-
tauglich zu machen, eine der grossen Staerken von allegro). Dahinter
steckt einfach ein Wandel im Benutzerverhalten: Der Benutzer
wuenscht weder, vor der Recherche belehrt zu werden ueber das,
was er in diesem Feld eingeben muss, noch wird er haeufig genug
den Registerinhalt sehen um von sich aus zu lernen, wie die
Inhalte strukturiert sind und seine Eingabe entsprechend anpassen.

Optimal (in Bezug auf Benutzererwartungen) waere eigentlich eine
Volltextsuche in den Browse-Registern, das aber nur als grobes
Paradigma, denn bei mehreren gleichzeitigen Suchbegriffen ist
"Treffer" meist doch ~meist~ auf den dahinterliegenden Datensatz
zu beziehen und nicht auf das Vorkommen aller Begriffe in einer
Registerzeile...

Im Laufe der Zeit hat es verschiedene Strategien gegeben, Stichwortsuchen
zu vereinfachen, etwa

1. Stichworte (Titel, Koerperschaft, Gesamttitel) in String-Register
einzusortieren. Stichwortsuche ist damit zunaechst prima moeglich, die
Qualitaet des Browsens wird allerdings reduziert, die Gegenstrategien
(das erste Wort der Strings nicht verstichworten, Stichworte zur
Abgrenzung von echten, Ein-Wort-Inhalten mit einem Sonderzeichen suffixen)
haben dann allerdings die Stichwortsuche mehr oder weder verunmoeglicht
(man landet nur in der Naehe und muss durch Browsen nachhelfen, bei mehr
als einem Suchwort kein praktikabler Weg).

2. Praekombination einzuschraenken und darauf zu hoffen, dass die
Inhalte filterbar sind (avanti/acon kann ja Registerausschnitte zu
einer gesetzten Restriktion liefern, a99 m.W. nicht, jedenfalls gibt
es im Indexfenster keine Moeglichkeit, Restriktionen zu setzen). Nachteil
allerdings, dass das Laufzeitverhalten beim Index-Filtern nicht abschaetzbar
ist, ein "ummoeglicher" Filter auf einer grossen Datenbank im Netzwerk
ist ein Problem.

3. Die von mir angeregten "Schattenregister", zu denen eigentlich auch
der jetzt angeregte Global-Stichwortindex gehoert: Die *Suche* nutzt andere
(alternative oder zusaetzliche) Indizes, als diejenigen, die dem Benutzer
zum Browsen angeboten werden und solange ~ungefaehr~ dieselben Inhalte
ausgewertet sind, wird das dem Benutzer gegenueber auch nicht thematisiert
(sind aus #39 oder #20k oder #81 gewonnene Worte "Stichwort" oder muss die
Bezeichnung fuer Inhalte aus Titelkategorien reserviert bleiben).
Diese Zusatzindizes werden zum Browsen nicht angeboten und koennen daher
durch radikale Normierung (Uebergehworte, Umlaute, Bindestriche, ...) den
Recall drastisch erhoehen. Irritationen entstehen allerdings, wenn Inhalte
indexiert sind, die dem Benutzer nie gezeigt werden.

4. Man koennte natuerlich noch weiter gehen und Indizes nur zur Vorermittlung
einer sehr grossen Ergebnismenge nutzen und das tatsaechliche Vorhandensein der
Suchworte erst in einem zweiten Schritt durch Volltextsuche in der
Ergebnismenge, ggfls. eingeschraenkt auf gewisse Kategorien, etablieren ("man"
ist dabei die Maschine, nicht der Benutzer). In diese Richtung ist m.W. noch
nicht viel unternommen worden, evtl. reicht die aktuelle srx-Implementation
dazu auch noch nicht aus (ein analoges Problem muesste man auch mit einer
Lucene-enhanced Suche haben wenn man die extern ermittelten Treffer
nachtraeglich durch Hervorhebung in den Datensaetzen plausibel machen will.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAkxSjA8ACgkQYhMlmJ6W47P45wP9HjeCAGA8MYRFIjbajRxv/Ub9
kB06WZ7fF1fuFi7tsdg6+/wYu23sI8H5P3wwzTB0jW+CUygljC07GhpuHWgFsGaN
coYLMTRGRMP4Mwv/yetZfgzlzm/2uRIgUyxT4akKLdWAK/kpRegC8PjgsyGQ7vue
R4RfbWzBAqYgJfE60vQ=
=dL6s
-----END PGP SIGNATURE-----