RSWK-Ketten, Indexierung etc.

[Heinrich Allers]

Bernhard Eversberg <EV at buch.biblio.etc.tu-bs.de>
schrieb am  Fri, 12 May 95 13:37:17 +0200:


> P. Oliver Kaftan aus Aachen hat einige interessante Vorschlaege 
> geschickt, ...

Pater Olivers (okaftan at ma-sun02.rz.rwth-aachen.de) Vorschläge von
Fri, 12 May 1995 07:01:43 +0100 hier auszugsweise und verkürzt:

>   Hier einige Vorschlaege zur Verarbeitung von Schlagwortketten
>   und deren Aufbau aus der SWD. .......

>   Vor einiger Zeit habe ich einmal angeregt, die Verarbeitung der
>   zu ersetzenden Schluessel durch Index ...

... gemeint ist wohl das Programm INDEX.EXE ...

>   .... zu ergaenzen: Wenn ein
>   Schluessel mit dem Steuerzeichen beginnt, wird er VOLLSTAENDIG
>   gelesen und alle Teile, die mit dem Steuerzeichen beginnen
>   ersetzt. ....

Eine solche Erweiterung wäre, auch unabhängig vom Blick auf die - 
wie ich meine: unseligen - Schlagwortketten nichts zu sagen, außer 
dem, was weiter unten die Entwicklungsabteilung einwendet:

> ...
> Fuer moeglich halte ich das schon, aber man muesste eine ERHEBLICH
> laengere Zeit fuer das Indexieren veranschlagen. ...

> Sollte sich dafuer eine Mehrheit finden, oder sagen wir eine 
> qualifizierte Minderheit von wenigstens vier oder fuenf Leuten, die 
> fest entschlossen sind, sowas dann zu nutzen, dann koennte man eine 
> Loesung in Angriff nehmen.

Zwar habe ich gerade neulich eine Allegro-Anwendung entwickelt, 
bei der ich eleganter hätte verfahren können, hätte es die hier 
vorgeschlagene Erweiterung des Leistungsumfangs von INDEX.EXE 
schon gegeben. Aber: 

Der Weg bis zu dem Punkt, an dem ich sagen könnte, ich sei FEST 
ENTSCHLOSSEN, besagte Erweiterung von INDEX auch einzusetzen, ist 
damit noch nicht vollständig zurückgelegt. Denn ich beobachte doch 
jetzt bereits bei Neuindexierungen der größeren (ca. 10.000 Sätze) 
Datenbank, die ich hier im Auge habe, wie sich INDEX beim "2nd run" 
abquält. Und wenn sich dieser zweite Schritt des Indexierungslaufes 
bei der vorgeschlagenen Neuerung um einen Faktor 5 verlängern würde, 
dann wäre ich schon gar nicht mehr so fest entschlossen, den neuen 
Komfort in das Datenbank-Design einfließen zu lassen ...


> Vielleicht ...

Das läßt sich schon jetzt sagen, daß im Fall dieser Weiterentwicklung
dieses "Vielleicht" durch "Unbedingt" zu ersetzen wäre!

> ... dann mit einem optionalen 
> Schalter, den man nur im begruendeten Ausnahmefall und im Wissen um 
> die Konsequenzen mit Bedacht umlegen wuerde...
> B.E.


Langer Rede kurzer Sinn:

Ich möchte mich erst einmal nicht dem Kreis jener zurechnen, die fest
entschlossen sind, von der Erweiterung des Indexierungsprogramms auch
tatsächlich Gebrauch zu machen. Zuvor würde ich von der Entwicklungs=
abteilung gern ungefähr wissen, mit welchen Faktoren die Laufzeit des
"2nd run" gegegebenenfalls multipliziert werden muß; ferner sollten 
wir
Anwender, die wir von der Entwicklungsabteilung dies und das und 
jenes 
zu verlangen gewohnt sind, uns überlegen, was wir ihr damit für Arbeit
einbrocken (ich gehe davon aus, daß das nicht mit einem halben Dutzend
Programmcodezeilen zu machen ist), und dabei im Auge haben, was uns
sonst noch fehlt, und womöglich dringender (Beispiele siehe im 
folgenden.)

***

Grundsätzlich ist es ja gut und begrüßenswert, wenn Programmerwei=
terungen in dieser Diskussionsrunde besprochen und vorgebracht werden
können, und hier gleich weitere 2 Punkte, die ich für die Wunschliste
der Allegro-Entwicklung anmelden möchte:


1.
Indexparameterdateien arbeiten normalerweise (implizit via Vorein=
stellung oder explizit mit ks=4 bei zwei- oder mit ks=5 bei drei=
stelligen Kategoriebezeichnungen).

Das ist sinnvoll, weil so z.B. mit 

ak=40+a
#-a
#u1
#+#

der Titel und nur der Titel (ohne Kategoriebezeichnung vorweg) zur
Schlüsselbildung hergenommen wird.

Will ich in solche Indexparameterdateien die in 12.2 bis 12.4 des
Allegro-Lehrbuches propagierte sogenannte kategorienanalytische
Indexierung integrieren, dann ist das unmöglich, denn ich vermag 
nicht, eine zu diesem Zweck erforderliche "Vorverlegung" des Kate=
goriestartes auf die Position 1 (anlog ks=1) vorzunehmen.

(Klar, auch hier müßte man natürlich wissen, ob es eine qualifi=
zierte Minderheit der Mächtigkeit >1 gäbe, die die kategorien=
analytische Indexierung überhaupt benutzt.)

Was ich mir also wünschte, wäre eine nur lokal wirksame Änderung
von 'ks'.

(Übrigens: die Indikator-Aktion #i - Systemhandbuch 10.2.6.4 - löst
nicht das Problem.)


2.
Ich wünsche mir bei PRESTO.EXE die Möglichkeit, in einer in einer
Exportparameterdatei auswertbaren Weise "zu wissen", von welchem
Register (vom Register welcher Nummer) aus ein Datensatz zur Anzeige
gebracht wird.

Wieder zur Frage der Legitimitation eines solchen Erweiterungs=
wunsches: Zugegeben, mir hat diese Möglichkeit noch nie gefehlt,
aber nachdem eine (nichtbibliothekarische) Anwenderin (einer 
nichtbibliographischen Anwendung wegen) danach gefragt hatte, 
habe ich mal drüber nachgedacht und fand den Wunsch danach gar 
nicht so abwegig.


Mit besten Grüßen:

*                               Heinrich Allers *
* Bibliothek der Carl-von-Ossietzky-Universität *
*              Postfach 2541, D-26015 Oldenburg *
*                      Telefax +49 441 798 4040 *
*           E-Post: allers at bis.uni-oldenburg.de *
****** LA BIBLIOTHEQUE, CE N'EST PAS MOI! *******