Goettingen / Wunschzettel f. Version 15

Do Jun 8 21:03:25 CEST 1995

Liebe AllegrologInnen,

    [Erst die Einleitung, der Wunschzettel kommt auf der n"achsten Seite]

In Goettingen fand ich vor allem die Berichte betreffs der kommenden PND
interessant (alles, was im weiteren Sinne mit 'Online' zu tun hatte,
war vielleicht in einem gewissen Sinne interessant, andererseits auch
deutlich nur eine Reaktion auf das, was jeder Bibliothekar, der die
Chance hatte, seinen Computer zu beeinflussen, schon immer getan hat -
wenn er es sich getraut hat). Den Vortrag 'haben HTML-Kataloge eine
Chance in Deutschland' habe ich leider nicht geh"ort, vielleicht kann
jemand dar"uber berichten?

Alles in allem scheint mir die neue PND eine brauchbare Sache zu sein,
und notwendig ist sie sowieso immer mehr. Auff"allig ist, dass der Trend
zur st"arkeren Nutzung von Normdateien nicht nur da ist, sondern auch
allerseits bereits bemerkt wurde. Ich denke, dass wir uns bald mit der
Tatsache auseinandersetzen m"ussen, dass
1.) ein Normdatensatz Bezug auf andere Normdatens"atze nimmt
    (Beispiele: Personen- und Namensnormierungsrecords innerhalb der PND
                Affiliation (d.h. GKD-Verweis in der PND)
                Personenkennzeichnung in EST-Stamms"atzen
     aber auch: 'Verschlagwortung von Stamms"atzen, wie z.B. Zuordnung
                von geographischen und zeitlichen Schlagworten zu Personen-
                norms"atzen
2.) ein Normdatensatz mehrere Ansetzungen enth"alt:
    Beispiel: Ein Satz der neuen PND enth"alt nicht nur die RAK-Ansetzung
    (plus (RNA) Individualisierung), sondern ggfls. ausserdem noch die
    RSWK-Ansetzung (an einer Vereinheitlichung wird nat"urlich gearbeitet)
    und ausserdem eine evtl. abweichende lokale Ansetzung und vielleicht 
    auch noch die LC-Authority-Record Ansetzung.
[Nur am Rande: Begr"ussenswert finde ich, dass die neue PND auf Ident-
nummern (bei den Tp-Records) verzichtet, da ja die Ansetzungen so individu-
alisiert sind, dass die Ansetzung (als Zeichenkette, also als Hexadezimal-
zahl oder wie auch immer) vollkommen ausreicht, den Satz zu identifizieren]

   [Jetzt kommt also mein Wunschzettel. Kommentare von allen sind erw"unscht.
    kleinere Punkte stehen ganz am Ende dieser Mail]

F"ur die sowieso n"otige Konsolidierung des V-14-Ersetzungsmechanismus
scheinen mir folgende Konsequenzen zwingend:
Ia) 'Schl"usselersetzungen im Inneren' m"ussen funktionieren (f. Kurztitel-
    anzeige, normierte (Unter-)Schlagworte, Verweisungen innerhalb eines
    Thesaurus, 'Verschlagwortung' von Stamms"atzen etc.
Ib) Schl"usselersetzungen d"urfen nicht auf eine Stelle in einem Register
    beschr"ankt sein. Personen kommen ja evtl. z. B. im Sachregister und
    im Formalregister vor (obwohl die meisten diese bestimmt zusammenfassen)
Ic) Ein Stammsatz muss mehrere Ersetzungsschl"ussel produzieren k"onnen (siehe
    2) oben). d.h. die Methode mit Pseudoschl"usseln (die nur f"ur einen
    Pseudoschl"ussel pro Satz funktionieren KANN), muss durch eine bessere
    ersetzt werden.
Id) Es sollte eine M"oglichkeit gefunden werden, Recherchen auf 'Sekund"ar-
    schlagworte' auszuweiten: Sucht man nach einem Geographikum, so kann man
    durch Einschalten von Assoziativit"at diejenigen Titel einbeziehen, deren
    Verfasser z.B. mit diesem Geograhpikum 'verschlagwortet' ist.
Ie) Zumindest '-' sollte innerhalb der Ersetzungsschl"ussel erlaubt sein.
    Diese sind ja meistens doch stark strukturiert, und sollten eigentlich
    fast immer folgende Informationen enthalten:
    Typ (Person, K"orperschft, EST, Schlagwort, Systematik, ...)
    Provenienz der ID (lokales K"urzel, das die numerische ID eindeutig macht
    Numerische ID
    'Variante' (siehe Ic)
    Beispiel:
    ppnd1234a    f"ur die RSWK-Ansetzung des PND-Satzes 1234
    Da w"are p-pnd-1234-a
    nicht nur f"ur Menschen, sondern auch f"ur Maschinen besser lesbar!
[Zu a-c werden P. Oliver Kaftan aus Aachen und ich innerhalb der n"achsten 
Zeit eine 'Machbarkeitsstudie' mit konkreten Vorschl"agen vorlegen]

Mit Id) und der letzten 'Verlautbarung der Entwicklungsabteilung' (#8), aber
auch mit Herrn Allers lauter Klage "uber die Unm"oglichkeit der Bildung
gewisser Suchbegriffe im Schnellzugriff h"angen folgende Vorschl"age zusammen,
die Trunkierung und Ergebnismengenbildung betreffen:
IIa) komfortablere Trunkierung: Trunkierung 'xyz' heisst dann:
     Trunkiere beim ersten 'z' hinter dem ersten 'z' hinter dem ersten 'x'
     Beispiel: '//': die ersten zwei Glieder einer Schlagwortkette werden 
                     angezeigt
               '--': ISBN's werden nach Verlagen zusammengefasst
IIb) Voreingestellte Trunkierung: (F"ur jedes Register separat spezifizierbar)
     Personen werden zwar nach M"oglichkeit individualisiert indexiert,
     diese Individualisierung wird aber standardm"assig nicht dargestellt,
     da trunkiert. Erst das Erweiterte Register oder ein explizites Aufheben
     der Trunkierung (Ebenfalls F7?) zeigt, dass es dort in Wirklichkeit 
     mehrere Schl"ussel gab.
IIc) Auch PRESTO sollte Ergebnismengen einlesen k"onnen, so wie QRIX sie seit
     neustem produziert und die Exportsprache sie jetzt komfortabel verar-
     beiten kann. Zusammen mit der Globalen Manipulation hat man dann die
     M"oglichkeit, mittels Volltextsuche Datens"atze zu selektieren und
     dann an der lebenden Datenbanken zu verarbeiten, ohne die Gefahr von 
     Datenverlusten, wie sie bei Selektion und Manipulation und erst an-
     schliessendem Neueinspielen mit UPDATE vorkommen k"onnen (es sei denn,
     man legt die Datenbank f"ur diese Zeit still).
IId) PRESTO sollte auch Ergebnismengen in dieser Form wegschreiben k"onnen.
     [Kann es zugegebenermassen, wenn man vorher den richtigen Export einstellt
      und durchf"uhrt]. Mit c) und d) zusammen kann man etwa eine m"uhsam
     erarbeitete Ergebnismenge, die noch nicht komplett manuell verarbeitet
     worden ist, f"ur den n"achsten Arbeitstag 'retten'.
IIe) PRESTO sollte einen Stack (Stapelspeicher) von Ergebnismengen (auf
     der Platte) anlegen und bearbeiten k"onnen. Bekanntlich sind Benutzer
     von HP-Taschenrechnern schneller als die von anderen, dies liegt an
     der umgekehrten Polnischen Notation (UPN). Bei dieser, auch Postfix-
     notation genannt, wird 3 <Enter> 5 + eingegeben, statt 3 + 5 =
     Klammerungen entfallen vollst"andig und man kann trotzdem alles berechnen.
     Mit dieser Postfixmethode kann ich also (mit Bin"aroperatoren) auch
     folgende Recherche durchf"uhren:
     (Stichwort bunt ODER farbig) UND (Stichwort Baum ODER Holz)
     N"amlich: 
     bunt / farbig /  <Push> Baum / Holz <Meta-+>
     liefert genau die gew"unschte Ergebnismenge.
     Mit dieser Methode l"asst sich jede - auch noch so komplizierte Operation
     mit Treffern und Ergebnismengen durchf"uhren, man braucht dazu nur die
     Stackverarbeitung und die zus"atzlichen (Benutzer-)Befehle
     <Push>, <Meta-/>, <Meta-+>, <Meta--> und <Vergessen>
     Die Frage ist nat"urlich berechtigt, ob das irgendjemand 'auf die Reihe
     kriegt'. Meine pers"onliche Ansicht ist, da"s der durchschnittliche
     Benutzer von den sogenannten 'Booleschen Operationen' sowieso "uber-
     fordert ist, egal ob in Postfix- oder Infix-Notation (letztere ist die,
     an die wir gew"ohnt sind). Selbst wenn er das Konzept begreift, verheddert
     er sich sp"atestens bei den Klammern. Damit ist meine Meinung etwa in
     der Mitte der H"arteskala angesiedelt, es gibt auch solche, die behaupten,
     dass Trunkierung den durchschnittlichen Benutzer "uberfordert.
     Aber: 
IIf) PRESTO sollte (parametrierbar) die Manipulation von Ergebnismengen
     (und die Kontrolle "uber den Stack von IIe) erm"oglichen. Damit (und
     mit einem geeigneten Thesaurus) ist es meiner Meinung nach recht einfach,
     die unter Id) beschriebene Ausweitung einer Recherche auf Oberbegriffe
     des Schlagwortes oder auf Sekund"arschlagworte der Person etc.
     durchzuf"uhren. Der Benutzer dr"uckt eine geeignete Taste und die
     'komplizierte' Bedienung unter IIe) erledigt die Parametrierung.

Bei IIf) fehlte also noch die geeignete Taste:
III) [Was bislang wohl nur "uber die c-Schnittstelle geht]: Es gibt - trotz
     langj"ahriger Anstrengungen der Entwickler - immer noch einige Tasten,
     die in bestimmten Kontexten keine Bedeutung haben. Mein Vorschlag:
     Tasten, mit denen weder das Programm noch die c-Schnittstelle (oder das
     aktuellen Zusatzmodul ORDER, REF, etc) etwas anfangen kann, werden als
     #u1 an eine bestimmte Sprungmarke "ubergeben (nicht die Tasten selber,
     sondern eher ihre ANSI-Codierung, die auch mitteilt, ob es <Alt>, <Shift>
     <Ctrl>, ... <Crtl>+<Shift>+<Alt> <Fn> gewesen ist.
     Und zwar wird beim Bet"atigen aus dem Index an eine Sprungmarke in der
     .cPI gesprungen, beim bet"atigen aus der Anzeige an eine Sprungmarke
     in der .cPR f"ur die Anzeige.
     Beim Aufruf aus dem Index stehen dann die gedr"uckte Taste und der
     aktuelle Indexbegriff (und Register) sowie nat"urlich die derzeitige
     Ergebnismenge zur Verf"ugung. Das sollte ausreichen, um die Ergebnis-
     menge auf die eine oder andere Art und Weise sinnvol zu manipulieren.
     [Auf diese Weise l"asst sich z.B. Linkstrunkierung simulieren, aber
     eventuell doch die sinnvolle Suche nach Zeitr"aumen, dazu dieser Tage
     vielleicht mehr].
     Beim Aufruf aus der Anzeige l"asst sich dieser Mechanismus z. B.
     benutzen, um eine neue Ergebnismenge, bestehend aus den Norms"atzen
     aller am aktuellen Titel beteiligten Personen und K"orperschaften
     zu bilden und den ersten Satz dieser Menge anzuzeigen. Oder Angaben
     zur Reihe. Oder Bildung einer Ergebnismenge mit allen Ausgaben 
     dieses Titels...

Miscellanea:
IV) Importsprache: Hilfreich w"are ein Befehl, der den ENDE-Zeiger vom 
    Ende her nach vorne verschiebt (vergleichbar mit 'T' bzw. 't' in der
    Exportsprache. Allerdings finde ich gleichzeitig, dass die Importsprache
    in Punkto M"achtigkeit und Universalit"at nicht mit der Exportsprache
    in Konkurrenz treten braucht: Die Feinbearbeitung kann ja immer mit
    dem (per -e -Parameter) nachgeschalteten Export gemacht werden.

V)  SRCH: Es w"are gut, beim Aufruf eine Datei angeben zu k"onnen, die
    den Infotext oberhalb des Eingabefeldes enth"alt (derzeit: UIF4).
    Ich produziere h"aufiger sortierte Listen, wo ich, da die Datens"atze
    beim ersten Export zerteilt werden, die Selektion erst beim zweiten
    Export (also nach dem Sortieren) eingeben kann. Typischerweise erinnere
    ich mich dann nicht mehr, ob ich #u1<19950101 oder #u2<950101 eingeben
    muss. "Uber (#40,goethe)-schiller hingegen haben alle schon genug gelernt.

VI) PRESTO: "Ubernahme von Schl"usseln in die gerade editierte Aufnahme sollte
    mit <Strg>+<Enter> (Statt <Enter> <Strg>+<Enter> wie bisher) machbar sein.

VII) In Hinblick auf PV und auf den Schl"usselersetzungsmechanismus stimmt
    es immer weniger, da"s sich die Daten stets aus den ALD-Dateien rekon-
    struieren lassen. Genauer: Die Aussage an sich stimmt zwar immer noch, 
    ist aber immer weniger von Belang, da die Fehlerm"oglichkeiten bei der 
    'Eingabe', der (halb-)automatischen Feldgenerierung also zum Zeitpunkt 
    der Eingabe oder Modifikation durch den Benutzer durch einen eventuell 
    inkonsistenten Index gewaltig und absolut unkontrollierbar sind. Es fehlt
    ein Tool, das "ahnlich wie QRIX (aber im Netzbetrieb) den Index Schl"ussel
    f"ur Schl"ussel durchsucht, den jeweils zugeh"origen Datensatz holt, 
    dessen Schl"ussel berechnet und dann herausfindet ob
    a) der urspr"ungliche Schl"ussel "uberhaupt auf diesen Satz zeigen darf
    und
    b) alle Schl"ussel, die dieser Satz produziert, tats"achlich vorhanden sind.
    Im Fall von Inkonsistenzen sollte dieses Programm wahlweise nur ein
    Protokoll ausgeben oder auch die Schl"ussel korrigieren.
    Mir ist klar, dass dieses Programm (wegen n"otiger Pausen) im Netzwerk-
    betrieb schon bei mittleren Datenbanken viele Stunden Laufzeit ben"otigt.
    Ich stelle mir aber vor, da"s dieses Programm nach M"oglichkeit sogar
    immer laufen sollte (ich weiss nat"urlich, dass keine Bibliothek einen
    PC f"ur solche Zwecke er"ubrigen kann, aber vielleicht ein DOS-Fenster
    unter Windows?): St"undlich soll es besonders heikle Stellen ("Ubernahme-
    und Ersetzungsschl"ussel) "uberpr"ufen, aber der Rest der Datenbank auch:
    Vielleicht jeden Tag ein anderes Register.
    Wie QRIX also sollte man diesem Tool einen Indexbereich als Aufrufparameter
    "ubergeben k"onnen.

VII) ASORT sollte eine Aufrufoption bekommen, die es erm"oglicht, dublette
    Zeilen auf eine zu reduzieren. 

Dies also meine Liste von Vorschl"agen. Sie ist ziemlich lang geworden und
vielleicht trotzdem in einigen Punkten nicht gen"ugend begr"undet. Ich kann
nat"urlich nicht erwarten, da"s irgendjemand das alles liest, aber vielleicht
manche von Ihnen wenigstens einen Teil.
Jedenfalls hoffe ich auf eine Diskussion.

[nicht in Goettingen geblieben]
Thomas Berger