Herr Weigel, Sie haben von 1988 bis 1996 an der Staats- und Universitätsblbiothek Hamburg Carl von Ossietzky (SUB) das auf allegro-C basierende System HANS entwickelt. Was waren die Entscheidungskriterien für dieses Projekt und welche Alternativen hat es gegeben?

Im Herbst 1988 bin ich in der SUB auf eine Stelle in der Handschriftenabteilung gewechselt und wurde im wesentlichen für die Nachlässe und Autographen zuständig. Es war klar, daß nicht Selbstdarstellung als Wissenschaftler, sondern Erwerbungsvorschläge, Bestandserschließung und Benutzerorientierung im Vordergrund stehen mußten. Vorgefunden habe ich umfangreiche Zettelkarteien und Repertorien einzelner Nachlässe, die von großem Fleiß und der Sachkunde meines Vorgängers Rolf Burmeister Zeugnis ablegten. Wie sollte ich weiterarbeiten? Das Einarbeiten in die Vielzahl von Nachweisinstrumenten bedeutete eine eigene Arbeitsleistung. Allerdings schien mir das Bilden von Expertenwissen in dieser Form nicht mehr zeitgemäß zu sein, da allenthalben von EDV-Projekten die Rede war. Für mich konnte die Lösung nur darin bestehen, ein PC-gestütztes Datenbanksystem einzuführen und alle verfügbaren Informationen dort zentral zusammen-zuführen. Ein weitgehend ungenutzter Siemens PCD-2 war in der Handschriftenabteilung vorhanden, einer der damals ganz wenigen PCs in der Bibliothek. Aber welche Software sollte eingesetzt und wie die Datenerfassung organisiert werden? Es standen ernsthaft eigentlich nur zwei Systeme zur Wahl: Dbase und allegro-C. Die Entscheidung fiel zugunsten des ja gerade in bibliothekarischer Hinsicht entwickelten Programms allegro aus, von dem erwartet werden konnte, daß es die notwendige Funktionalität besäße. Vielleicht der wichtigste Grund aber war die leichte Bedienbarkeit auch für ungeübte PC-Benutzer. Das war insofern von großer Bedeutung, als kein reguläres Personal für die Retrokonversion der Zettelkarten zur Verfügung stand und mit studentischen Hilfskräften gearbeitet werden sollte. Ende 1988 beantragte ich für das Jahr 1990 eine Summe von DM 30.000,- in der Illusion, damit fast alle Zettel konvertieren zu können - und erhielt das Geld tatsächlich, und dann jedes Jahr wieder einen ansehnlichen Betrag.

Zudem hatte ich das Glück, daß mich ein allegro-Experte in der SUB - Stefan Gradmann - bei der Entscheidungsfindung, der Installation und der Parametrierung unterstützte. Wir definierten die Datenbank 1989 in einer ersten einfachen Form, indem wir für die Anlage der Datenfelder und die Konfiguration der Datenbank Zwischenergebnisse einer Arbeitsgruppe der Deutschen Forschungsgemeinschaft (DFG) benutzten. In der Praxis gelang es, die Studenten in ungefähr ein bis zwei Stunden einzuführen. Mit etwas begleitender Kontrolle wurde sehr gut gearbeitet, und auch das Programm hat sich bewährt. Aufgrund des Erfolgs der Hamburger allegro-Datenbank wurde diese dann 1991 in der Publikation »Der Einsatz der Datenverarbeitung bei der Erschließung von Nachlässen und Autographen« (Berlin: Deutsches Bibliotheksinstitut 1991 [= Dbi-Materialien 108]) als Beispieldatenbank für die DFG-Richtlinien neben einer TUSTEP-Anwendung vorgestellt. Die Resonanz darauf bewog uns in der SUB, selbst einen DFG-Antrag zur Weiterentwicklung und gültigen Ausformung unserer Datenbank zu stellen. Mit dem Projekt »Autographendatenbank und -OPAC« beginnt dann im eigentlichen Sinn die Geschichte von HANS.

Und mittlerweile ist HANS ja auch ein weitverbreitetes System, das durch die SUB und die HANS-Anwendergruppe weiter gepflegt wird. Mit welchen anderen, für Literaturarchive interessanten Datenbanken kann HANS verglichen werden? Wo liegen die Stärken und Schwächen der anderen Systeme?

Bei der Bewertung oder gar Abwertung von anderen Software-Lösungen muß man natürlich vorsichtig sein. Einen Produktüberblick will ich gar nicht erst versuchen. Wenn man sich einmal entschieden hat, verfolgt man die Entwicklung der anderen Programme bzw. deren Sterben oder auch das Auftauchen neuer Systeme nicht mehr bis in alle Verästelungen - und mein Urteil würde bei Namensnennungen sicher auf den Protest des jeweiligen Spezialisten stoßen. Welches Programm und welche Variante desselben für ein bestimmtes Literaturarchiv am besten geeignet ist, muß außerdem vor Ort nach eigentlich immer anderen Vorgaben und intensiven Tests entschieden werden. Die Produktevaluierung kann einem Archiv zum aktuellen Zeitpunkt niemand abnehmen.

Grundsätzlich lassen sich jedoch Kriterien für eine Entscheidungsfindung angeben. Ist das Literaturarchiv Teil einer größeren Einrichtung, ist abzuklären, inwieweit es von dieser Seite Vorgaben gibt. Ob etwa ein bestehendes Verbund- oder überhaupt ein bibliothekarisches Großsystem geeignet ist, auch die Bestände eines Literaturarchivs nachzuweisen, wird man derzeit wohl eher skeptisch beurteilen. Wir in der Vorarlberger Landesbibliothek hatten ebenfalls geplant, langfristig nur noch eine Software - Aleph 500 - zu pflegen. Aber bis alle Spezialitäten integrierbar sind, wird noch einige Zeit vergehen. Und ob dies wirklich sinnvoll ist, ist nicht so sicher. Möglicherweise können Besonderheiten im kleineren Rahmen professioneller und flexibler verwaltet werden. Man darf auch nicht den Aspekt unterschätzen, daß Literaturarchivare in der Regel auch selbst über technische Dinge Bescheid wissen sollten, da extensiver Support eher untypisch ist und die Realisierbarkeit der eigenen Wünsche vom Wissen über das Potential eines EDV-Systems abhängig ist. Mein Ehrgeiz bei der Entwicklung von HANS bestand darin, neben der Verbundkatalogisierung für Drucke ein zweites Datenbanksystem zu etablieren, das in allen Sondersammlungen der Bibliothek und für die verschiedensten Materialien einsetzbar wäre. Somit würde es in der Bibliothek immerhin noch zwei Systeme geben, aber nicht für jede Besonderheit ein eigenes. In Deutschland ist HANS auch für Museen ein Thema, die gemeinsame Arbeit insbesondere mit Monika Steffens vom Stadtmuseum Oldenburg trägt hier Früchte.

Auf der Ebene der Entscheidungsverantwortung des Literaturarchivs wird der Kostenfaktor dominieren und werden selten teure Client-Server-Systeme in Frage kommen können, nicht nur wegen der Anschaffungskosten. Andererseits will ich vor den selbstgestrickten Varianten der massenhaft verbreiteten Software aus dem Privatanwenderbereich warnen. Damit ist es selten möglich, langfristig in der Sache profes-sionell zu arbeiten; diese können trotz des häufig schönen Scheins der bunten Bildchen nur Zwischenlösungen darstellen. Meines Erachtens kommen für Datenbankanwendungen in Literaturarchiven nur Programme in Frage, die neben den Anforderungen an jede Software (z. B. Ergononomie, langfristige Verfügbarkeit, transpararente Bedieneroberfläche, Support) folgende Kriterien erfüllen:

Selbstverständlich sollte das Programm bei allen inhaltlichen Anforderungen - diese sind aber für uns zunächst der wesentliche Punkt - auch annähernd dem aktuellen technischen Standard entsprechen, als Beispiel für eine dieser Mindestanforderungen würde ich die Verfügbarkeit eines WWW-OPAC nennen.

Ihren Ausführungen entnehmen wir, daß Sie von dem Einsatz von Datenbanken wie beispielsweise Access oder Filemaker, die eigentlich sehr beliebt sind, strikt abraten. Nun nutzt auch das beste Archivsystem nichts, wenn die Daten nicht konsistent eingegeben werden. Angesichts des großen Spielraums bei der Datenerfassung, den etwa die RNA gewähren, drängt sich die Frage auf, welchen Stellenwert der Datenredaktion zukommt. Unserer Meinung nach ist dies ein sehr hoher. Wie schätzen Sie vor dem Hintergrund Ihres Wissens um die Kompetenzen und Ressourcen (Zeit, Geld, Personal) in Literaturarchiven diesen Sachverhalt ein?

Es steht mir nicht zu, von bestimmten Programmen strikt abzuraten, aber gegen Individual- oder Insellösungen möchte ich schon argumentieren. Und genau an diesem Punkt stellt sich auch die naheliegende Frage nach der Datenkonsistenz. Entscheidend ist hierfür ein eindeutiges, verbindliches, auf dem Regelwerk basierendes Datenformat. Selbst bei der Verwendung unterschiedlicher Programme wird so durch standardisierte Konvertierungsroutinen sichergestellt, daß die Daten austauschbar oder an eine zentrale Sammelstelle lieferbar sind. Wie sich jetzt aus den Berichten über die vielen neuen HANS-Installationen - z. B. beim jüngsten Wiener HANS-Anwendertreffen - ergibt, wäre es vielleicht doch besser gewesen, den RNA wenigstens für den Kernbereich ein Datenaustauschformat mitzugeben, an dem man sich bei der Definition der lokalen Datenbank und der Verteilung der Informationen auf Datenfelder hätte orientieren können. Ich habe für die RNA daran lange gearbeitet. Die erste Veröffentlichung der RNA von 1991 hatte neben dem Regelwerk auch ein zugehöriges Datenformat enthalten. Letztlich wurde bei der neuen Publikation darauf verzichtet, weil - eigentlich einleuchtend - dieses Austauschformat das MAB-Format sein sollte und neben dem MAB-Ausschuß keine zweite Zentralstelle zur Pflege dieses besonderen Datenformats sinnvoll oder realisierbar schien bzw. wohl auch nicht gewünscht wurde. Die Folge ist nun aber, daß in Einrichtungen, die keine nachhaltige Unterstützung durch Experten bibliothekarischer Datenformate erhalten, Unsicherheit bei der Umsetzung der RNA in die konkrete Anwendung besteht. Bis heute gibt es ja auch keine Vorgaben für elektronische Lieferungen an die Zentralkartei der Autographen in Berlin. Die Vorgabe MAB ist zu unspezifisch, als daß sie von Literaturarchiven - noch dazu ohne MAB-Experten - im Detail umgesetzt werden könnte. Man darf auch nicht vergessen, daß MAB ein Austauschformat ist, d. h. der Zweck ist der Transport von Daten und nicht die lokale Datenstrukturierung. Dieses Defizit wird nun eigentlich von HANS kompensiert. Der einzelne Anwender kann sich darauf verlassen, daß es für die Standardanwendung demnächst ein Handbuch und Prozeduren der Datenlieferung an eine Zentrale - falls überhaupt gewünscht - geben wird. In jeder Einrichtung muß es aber jemand geben, der die HANS-Datenredaktion verantwortlich betreibt, und das bedeutet im Kern: Womit und in welcher Form sollen Datenfelder besetzt werden? Unterstützt werden sollten die Betreuer vor Ort durch die HANS-Anwendergruppe und die E-mail-Diskussionsliste. Was wir möglichst rasch benötigen, ist eine Beispielsammlung mit verbindlichem Charakter. Zu viele Mißverständnisse sind noch auszuräumen. Auch inhaltliche Schulungen wie Datenbank-Kurse für Neueinsteiger und regelmäßige Treffen der Anwender müssen sein, sonst bleibt das notwendige Mindestmaß an Standardisierung eine Illusion.

Wie gesagt, ist HANS in Deutschland sehr weit verbreitet. Wie beurteilen Sie die Entwicklung in Österreich?

Die Akzeptanz der RNA und der Fragen des Datenaustauschformats weisen auf den Willen hin, gemeinsam arbeiten zu wollen. Die Anstrengungen des ÖLA unter dem Titel »Vernetzung der österreichischen Literaturarchive« finden meine begeisterte Zustimmung. Dabei ist es unerheblich, mit welcher Stoßrichtung die Arbeit begonnen wird und das Fernziel - mir jedenfalls - nicht ganz klar ist. Es zeigte sich, daß aktuell die Förderung der Kommunikation und die mit großem Einsatz betriebene Betreuung der Literaturarchive bei der HANS-Installation schon ein erster Schritt zum »Netz« hin bedeuten. Ob nun einmal in einer großen Datenbank die Bestände der österreichischen Archive zusammengeführt werden oder ein virtueller Katalog deren je eigene Web-Kataloge bei Recherchen durchsucht, wird erst nach einer gewissen Zeit zu entscheiden sein. Die Parameter dieser Entscheidung ändern sich womöglich von Jahr zu Jahr. Wird es etwa eine Infrastruktur und Personal für eine Zentralredaktion geben? Wie aufwendig ist die Datenkonversion und Lieferung, wenn nicht nur HANS-Kataloge betroffen sind? Ist die Software der Zentrale für die Zwecke der Literaturarchive wirklich die geeignetste? Das sind nur einige Fragen. Aber ich glaube, wir sind auf einem guten Weg und sollten pragmatisch Schritt für Schritt weitergehen. Daß auf Initiative des ÖLA in relativ kurzer Zeit eine so enge Zusammenarbeit und auch kollegiale Gemeinsamkeit entstanden sind, das macht das Wesen des »Netzes« aus, das uns trägt - Spinnen mag es ruhig mehrere geben.