[Allegro] Indexparameter cat.api modernisieren?

[Thomas Berger]

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



Am 22.07.2010 15:42, schrieb Bernhard Eversberg:
> 
> Recht überladen und unangenehm komplex sind die Indexparameter cat.api.
> Sollten wir nicht wenigstens als Alternative etwas haben, was einerseits
> den für aLF/ORDER/ZAbom notwendigen Apparat enthält, andererseits aber
> bei der bibliographischen Indexierung weniger aufwendig oder nach
> moderneren Erkenntnissen arbeitet?

Es gaebe da einiges zu tun, Z.B. sind ja Koerperschafts- und Zeitschriften-
Stichworte ganz Browse-Freundlich im Register durch irgendwelche Sonderzeichen
als Suffixe gekennzeichnet, die fuehren aber dazu, dass mit einer Masken-
Suche die Begriffe gar nicht getroffen werden, und um sie bei hoeheren
Trefferzahlen mit einem expliziten "find" zu erwischen, ist eine Sonder-
behandlung in den Umcodierungsabschnitten erforderlich, die cat.api nie
gehabt hat.

Zur Unterstuetzung von Suchen gehe ich in letzter Zeit oft dazu ueber,
neben dem traditionellen Browse-Register ein separates Schattenregister
anzulegen, das enthaelt dann z.B. als Ergaenzung des Personenregisters
alle moeglichen Einzelworte, z.B. die Vornamen: Eine Web-Suche beruecksichgt
dann nicht nur den vom Benutzer eingegebenen Mehrwortbegriff fuer das
angegebene Register, sondern ver-odert das Ergebnis mit der tendenziell
breiteren Suche nach den (ver-und-edten) Einzelbestandteilen im Schatten-
register. Vorteil ist, dass man dem Benutzer immer noch einen "Registereinblick"
anbieten kann, der halbwegs sinnvoll ist, ohne jedoch komplizierteste
Umcodierungen und Spezialtrunkierungen einbauen zu muessen, damit Eintraege
mit "*" am Ende oder mit Uebernahmeschluessel oder Verweise stets mit
erwischt werden.


> Vor allem: wie wär's mit einem ALL-Register, das alles Wortgut pauschal
> zusammenfaßt, auch die Namensbestandteile, und damit einen
> Einzeilen-Einwurfschlitz zum Standard machen kann?
> Ob man gleich soweit gehen sollte, daß dieses Register als separate
> Indexdatei (MultiX-Technik) ausgebildet wäre, da bin ich mir nicht sicher.
> Platzprobleme wird kaum ein Normalanwender damit kriegen, der
> weniger als 5 Millionen Daten hätte.

Was ist "alles Wortgut"? Alle Felder, alle "bibliographischen" Felder, alle
Felder mit Transkriptionen aus der Vorlage? Sie hatten neulich ja erst
die Lucene-Indexierung vorgestellt, die ja die Trunkierungsmodi und
Distanzkennungen beherrscht, die man benoetigt, um solch eine Salat-Suche
noch beherrschbar zu machen. Der Weg geht m.W. aber ueber n-Gramm-Indizes
zur effizienten Vorauswahl nebst ausgefeilterer Volltextsuche in den gefundenen
Saetzen.


> Wie wär's, mit einem Minimum an Aufwand zu lösen, das Reg. 2 zum
> ALL-Register zu machen und die Körperschaften ins Reg. 6 zu verfrachten?
> Sie mit den Verlagen zu vereinen ist vielleicht sowieso keine schlechte

Hochgradig angesetztes wie die #6er-Kategorien und (leider) traditionell
unnormiertes wie #7er in ein Register zu werfen, ist eher problematisch
(die Verlage sind ja wiederum mit den Erscheinungsorten "vereint").
Bezueglich Register 6 ist allerdings z.B. wieder die Frage, ob die
praekombinierte Form Verlag,Jahr noch zeitgemaess ist.

Seit der Erfindung des WWW und der a99-Flips ist m.W. nie systematisch
untersucht worden, ob es nicht (weitere) wuenschenswerte Navigation
zwischen Datensaetzen gibt, die guenstig realisiert werden koennte,
wenn man gewisse Hilfsschluessel irgendwo haette (vgl. die Diskussion
zu Aufsaetzen aus Sammelbaenden neulich hier).

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

iJwEAQECAAYFAkxIUIQACgkQYhMlmJ6W47P7pAP/YHk0NsT50yRNVk168aWObMdb
7oLe4Ki8Ek1e6AL76T768gaPcIo3ngvvpL2zg/03NT91jTdCmzhCq7PlTcpjhJKB
Ld65IPMXlPQXIXJWGrHkxRx9wNTVcyhlH9/2UI2RNYl8cTXVNZywgY923qLO+rKm
u35mT5H6K4tmTqbctos=
=0os8
-----END PGP SIGNATURE-----