Meta-OPAC | HUB | IB | Erstellt: am 22.11.98 - Letzte Änderung: 22.11.98 - Hinweise bitte an GG

Gerrit G. Gragert

Der Meta-OPAC Berlin-Brandenburg

Konzeption, Entwicklung & Implementation

Zusammenfassung

Der Meta-OPAC wurde als studentisches Projekt am Institut für Bibliothekswissenschaft der Humboldt-Universität Berlin entwickelt. Mit seiner Hilfe ist es möglich, in mehreren Bibliotheken der Region, die ihren OPAC über das World-Wide-Web zugänglich gemacht haben, gleichzeitig zu recherchieren. Der vorliegende Text behandelt überblicksartig Vorbilder wie den Karlsruher virtuellen Katalog (KVK) oder geplante Projekte auf diesem Gebiet wie die Suchmaschine des Kooperativen Bibliotheksverbunds Berlin-Brandenburgs (KOBV). Ausführlich wird der Aufbau und die Arbeitsweise des in der Programmiersprache JAVA entwickelten Meta-OPACs erläutert sowie bestehende Probleme aber auch Erweiterungsmöglichkeiten diskutiert.

Summary

The Meta-OPAC was developed by a group of students of the Institute for Library Science of the Humboldt-University Berlin. He enables the search in multiple library catalogs at the same time. These regional catalogs have a World-Wide-Web-Interface. The article describes other projects like the Karlsruher virtuellen Katalog (KVK) or the Search Engine of the Kooperativer Bibliotheksverbund Berlin-Brandenburg (KOBV). The main part deals with the architecture and working order of the Meta-OPAC written in the language JAVA. It also discusses existing problems and possible future improvements.

Überblick

Credits
Darstellung der Situation

Die Situation
Existierende Lösung : Der Karlsruher virtuelle Katalog
Geplante Lösung : Der KOBV

Der Lösungsansatz Meta-OPAC

Grundlegende Probleme
Programmsystem Meta-OPAC
Eine Recherche im Meta-OPAC aus Systemsicht

Existierende Probleme und Erweiterungsmöglichkeiten

Existierende Probleme
Erweiterungsmöglichkeiten

Anhang

Quellen, URLs
Fußnoten

Credits

Der Meta-OPAC Berlin-Brandenburg [Lit1]wurde und wird als studentisches Projekt am Institut für Bibliothekswissenschaft der Humboldt-Universität Berlin entwickelt. Die Teammitglieder sind im einzelnen (in alphabetischer Reihenfolge):

Betreut wurde das Projekt von Michael Heinz, der durch seine wegweisenden Ideen maßgeblich am Erfolg beteiligt ist.

Zurück zum Überblick

Darstellung der Situation

Eine der wichtigsten Fragen bei der Aufklärung eines Verbrechens ist stets die Frage nach dem Motiv. Nun haben wir (hoffentlich) kein Verbrechen begangen, doch um den Meta-OPAC zu verstehen, ist es sicherlich hilfreich zu wissen, warum wir ihn entwickelt haben. Denn die Antwort auf die Frage Warum habt Ihr das getan? lautet nicht (zumindest nicht ausschließlich) Weil es sowas vorher noch nicht gab.

Die Situation

Das World-Wide-Web bietet bekanntermaßen eine sehr einfache Möglichkeit, Informationen zu vermitteln. Der HTML-Standard ermöglicht es, nicht nur passiv Seiten zu konsumieren, sondern auch aktiv - durch entsprechende Schnittstellen - z.B. in Datenbanken zu recherchieren. Auch Bibliotheken offerieren einen entsprechenden Service ihren Lesern [1]. Als lobenswerten Seiteneffekt kann nun nicht nur der "lokale" Leser einfach und mit einem ihm bekannten Programm (seinem Browser) nach Titeln suchen, auch ein Student in Berlin kann sich kundig machen, ob z.B. die Bibliothek der TU Cottbus genau das Buch führt, welches er sucht, bevor er sich entscheidet, den weiten Weg nach Cottbus auf sich zu nehmen. So haben sich mittlerweile 22 Bibliotheken im Raum Berlin-Brandenburg dazu entschlossen, ihren OPAC auch über das World-Wide-Web zugänglich zu machen [2].

Daß dies für den regionalen Bibliothekskunden von enormen Nutzen ist, steht außer Diskussion. Doch daß die Situation gleichzeitig noch nicht hunderprozentig befriedigend ist, zeigt bereits die einfache Frage In welcher Bibliothek bekomme ich "Informationssysteme und Datenbanken" von Carl August Zehnder? Für eine vollständige Antwort ist nun jeweils eine Recherchen in 22 OPACs nötig. Diese OPACs sind natürlich Teil verschiedener Systeme, verlangen andere Handhabungen, haben unterschiedliche Feldkennungen und Anfragesprachensyntax. Zudem muß sich der Suchende merken, in welcher Bibliothek er nun den Titel gefunden hat, denn auch eine Gesamtliste aller Treffer gibt es nicht. Abspeichern der einzelnen Listen und eigenhändiges Zusammenfügen gestaltet sich ebenfalls sehr umständlich, da auch die Ausgabeformate der OPACs verschiedene sind. Zusammengefaßt: Eine schnelle und umfassende Suche nach einem Titel ist nicht möglich.

Zurück zum Überblick

Existierende Lösung : Der Karlsruher virtuelle Katalog (KVK)

In Karlsruhe hatte man schon 1996 die oben aufgeführten Schwierigkeiten erkannt und Abhilfe in Form des Karlsruher virtuellen Katalog, auch kurz unter KVK bekannt, entwickelt [Lit2]. Über ihn sind nunmehr

9 Verbundkataloge
3 Bibliothekskataloge (einzelne Bibliotheken)
3 Buchhandelsverzeichnisse

recherchierbar. Der KVK gewährt die Möglichkeit der Erstellung einer sortierten Gesamtliste aller Treffer, in der jedoch aus technischen Gründen die Einzeltreffer (also wenn in einer Bibliothek nur ein Treffer gefunden wurde) nicht enthalten sind.

Das Prinzip des KVK ist vergleichbar mit dem Prinzip bekannter Meta-Suchmaschinen wie MetaCrawler oder MetaGer : vom Nutzer eingegeben Suchdaten werden von der Meta-Suchmaschine in eine Suchanfrage für mehrere Zielsysteme umgewandelt, dann werden diese Anfragen an die einzelnen Kataloge geschickt und schließlich die Trefferlisten gesammelt und analysiert, um daraus eine Gesamttrefferliste zu erstellen. Wie unten aufgeführt wird, baut auch der Meta-OPAC auf diesem Prinzip auf, daher sind nähere Erläuterungen dazu unter dem Punkt Der Lösungsansatz Meta-OPAC zu finden.

Zurück zum Überblick

Geplante Lösung : Der Kooperative Bibliotheksverbund Berlin-Brandenburg (KOBV)

Ebenfalls erkannt hat das Problem der Kooperative Bibliotheksverbund Berlin-Brandenburg (KOBV) [Lit3], der jedoch einen anderen Lösungsweg beschreiten wird. In Planung ist eine Suchmaschine mit jedoch dezentralem Datenbestand, d.h., daß die Titeldatensätze weiterhin bei den beteiligten Bibliotheken in einem Rechner abgespeichert sind und nur ein zentrales virtuelles Register über ausgewählte Attribute bei der Suchmaschine existiert. Mit Hilfe dieses Registers kann eine schnelle Suche durchgeführt werden, nach der die kompletten Titeldaten von Treffern dann über das Netzwerk von der jeweiligen Bibliothek geladen werden. Diese Vorgehensweise wird durch die Nutzung einer standardisierten Kommunikationsschnittstelle (die sog. Z39.50-Schnittstelle) ermöglicht. Ungefähr vergleichbar mit dem Maschinellen Austauschformat für Bibliotheken (MAB) ist in der Spezifikation exakt festgelegt, wie ein Datensatz auszusehen hat. Dies bietet folgende Vorteile:

Für die Anfrage ist nur eine Anfragesyntax notwendig
Die Antworten aller Bibliotheken erfolgen im gleichen Format
Somit ist eine Dublettenkontrolle einfacher
Wenn eine Bibliothek intern ihre Software austauscht, muß keine Änderung in der zentralen Suchmaschine erfolgen, da nach Außen weiterhin über die Z39.50-Schnittstelle kommuniziert werden kann

Doch hat dieser Lösungsweg einen bislang nicht behobenen Nachteil: Noch ist nicht abzusehen, wann alle Bibliotheken im Bibliotheksverbund über Systeme mit einer Z39.50-Schnittstelle verfügen. Erst dann kann von einem (virtuellen) Verbundkatalog gesprochen werden.

Zurück zum Überblick

Der Lösungsansatz Meta-OPAC

Ein Problem ist also vorhanden. Eine Lösung für die Region jedoch noch nicht genau absehbar. Darum haben wir uns darangemacht, das bereits vorhandene - nämlich die WWW-OPACs einzelner Bibliotheken - zu nutzen, um damit eine adäquate Lösung zu finden, zumindest, bis der KOBV voll funktionsfähig ist.

Grundlegende Probleme

Bei der Untersuchung der entdeckten WWW-OPACs wurde sehr schnell deutlich, daß sehr heterogene Systeme zu behandeln sind. Zwar überwiegen zwei Systeme, zum einen der W3-OPAC, der wohl zum Programmpaket der Firma Siemens gehört, sowie die CGI-Schnittstelle [3] des von vielen Öffentlichen Bibliotheken verwendeten allegroC-Katalogs. Doch auch wenn zwei oder mehrere Bibliotheken das gleiche System nutzen, machen es doch kleine Unterschiede in der jeweiligen Konfiguration unmöglich, ein einziges Programm für beide Bibliotheken zu verwenden. Die Unterschiede bestehen vor allem in den angebotenen Suchfeldern (Autor, Titel etc.) und den verwendbaren boolschen Operatoren. Während AND von allen Bibliotheken unterstützt wird, ist dies bei dem Operator OR nur noch eingeschränkt der Fall. NOT wird ebenfalls nur von einigen Bibliotheken angeboten.

Ein weiteres Problem ist der - bei einigen Katalogen zumindest - sehr hohe Kommunikationsaufwand [4]. Manche Kataloge sind nur nach einem Login-Vorgang und aufwendiger Auswahl von Suchmodi und einzelnen Katalogen recherchierbar. Für den normalen Nutzer gestaltet sich dies nicht als große Hürde, ein Programm muß jedoch aus den empfangenen Seiten stets unter größerem Aufwand die nötigen Daten, die verlangt werden, um eine Anfrage an den Katalog stellen zu können, extrahieren. Mitunter noch aufwendiger wird der Vorgang, wenn - wie es einige Bibliotheken tun - spezielle Rechercheserver dynamisch beim Aufruf der Einstiegsseite des Katalogs zugeteilt werden und der Nutzer dann einen (zeitabhängigen) Zugriffscode erhält.

Sind diese Hürden überwunden und wurde die Anfrage erfolgreich gestellt, taucht bei den erhaltenen Trefferlisten das nächste Problem auf. Um diese auf ein einheitliches Format zu bringen, muß das Programm erkennen, welche Zeichenketten den Titel, den Autor und das Jahr darstellen. Dies ist schwierig, da nur einige Trefferliste die einzelnen Felder explizit kennzeichnen. Andere Listen tun dies nicht, und für das menschliche Auge mag es ersichtlich sein, wie die Felder zu trennen sind, nicht jedoch für ein Programm. Solange die Felder durch ein eindeutiges Merkmal von einander getrennt sind oder eine feste Länge besitzen, ist diese Trennung noch relativ einfach. Doch leider fehlt bei einigen Listen ein solches Trennungsmerkmal und die Felder weisen eine variable Länge auf. Hier ist ein sehr hoher Aufwand nötig, um das Problem zu lösen.

Ebenfalls mit den Trefferlisten verbunden ist die Schwierigkeit, daß manche Kataloge ihre Trefferlisten in "kleinen Häppchen" von i.d.R. zehn Treffern pro Seite senden. Dies ist für den menschlichen Nutzer in Hinblick auf die Ladezeiten günstig, nicht jedoch für einen Meta-OPAC, der natürlich die gesamte Liste auf einmal benötigt. Gerade bei sehr hohen Trefferzahlen muß der Katalog sehr oft kontaktiert und um die nächste Seite gebeten werden. Auch dies erhöht den zu betreibenden Aufwand.

Zurück zum Überblick

Programmsystem Meta-OPAC

Nachdem nun geklärt wurde, auf welche Probleme bei der Programmierung zu achten ist, sollte der nächste Schritt den Programmentwurf darstellen. Zunächst einige allgemeine Angaben zum Meta-OPAC:

Objektorientierte Programmierung in JAVA [Lit4]
ca. 30.000 LoC (Lines Of Code) [5]
insgesamt 30 Programmdateien

Die letzte Zahl der Programmdateien deutet bereits darauf hin, daß es sich um ein modular aufgebautes System handelt. Dies meint, daß nicht alle Funktionen in einem großen Programm vereint sind, sondern sinnvoll in mehreren kleinen Programmen zusammengefaßt wurden. Diese Programme laufen dann später gemeinsam ab, so daß dennoch der Eindruck eines großen Programms entsteht. Diese Vorgehensweise hat den Vorteil, daß eine einfache Wartung des Programms gewährleistet ist : Veränderungen kann man schnell und einfach in einem kleinen Programm vornehmen, ohne die gesamten 30.000 Zeilen durchforsten zu müßen. Außerdem kann auf diese Art sehr einfach eine weitere Bibliothek hinzugefügt werden, die vorher getrennt getestet werden konnte, um nicht das gesamte System zu gefährden. Doch nun zu einer kurzen Beschreibung der einzelnen Module:

Zentrales Programm zur Steuerung einer Anfrage
Dieses Modul aktiviert die einzelnen Programme zur Kommunikation mit den Bibliotheken je nach Auswahl des Nutzers auf der Meta-OPAC-Startseite. Die von dort empfangenen Recherchedaten werden an diese Programme übergeben und schließlich die Anfragen gleichzeitig gestartet und parallel ausgeführt. Erfolgte nach 60 Sekunden keine Antwort von einer Bibliothek, wird die entsprechende Anfrage abgebrochen. Zuletzt wird die Trefferübersicht erzeugt, aus der auf einen Blick ersehen werden kann, welche Bibliothek nicht geantwortet hat und wieviele Treffer in den anderen Bibliotheken gefunden wurden.
Bibliotheksspezifisches Programm
Für jede vom Meta-OPAC abgedeckte Bibliothek existiert ein solches Programm, dessen Aufgabe zum einen ist, aus den übergebenen Anfragedaten ein für die jeweilige Bibliothek syntaxkonforme Anfrage zu formulieren. Zweite Aufgabe ist es, diese Anfrage an die Bibliothek zu senden, und zwar mit dem gesamten kommunikativen Aufwand, der dazu nötig ist (vgl. Grundlegende Probleme). Die dritte Aufgabe ist es schließlich, die erhaltenen Trefferlisten in das vom Meta-OPAC verwendetet einheitliche Format zu bringen und sie in eine temporäre Datei zu schreiben. Dies gewährleistet, daß die Trefferliste für eine Recherchesitzung im Meta-OPAC nur einmal geladen werden müssen.
Anzeigeprogramm
Dieses Programm dient einzig und allein dazu, die in den temporären Dateien abgespeicherten Trefferlisten auszugeben.
Löschprogramm
Um den Server des Meta-OPACs vor anwachsendem "Datenmüll" zu bewahren, müssen die bei einer Recherche erzeugten temporären Dateien auch wieder gelöscht werden (sonst wäre sie auch nicht temporär). Dies kann der Nutzer entweder selbst auslösen, in dem er den entsprechenden Logoff-Button auf einer der Meta-OPAC-Seiten drückt, oder das System übernimmt diese Aufgabe für ihn. Die temporären Dateien werden von dem Löschprogramm auf jeden Fall entfernt, sobald sie älter als 30 Minuten sind.

Zurück zum Überblick

Eine Recherche im Meta-OPAC aus Systemsicht

Da es am günstigsten ist, eine Recherche im Meta-OPAC aus Nutzersicht sich nicht einfach beschreiben zu lassen, sondern sie selbst durchzuführen (einfach dem Link folgen), soll der Fokus nun auf eine Recherche aus Systemsicht gerichtet werden.

Nebenstehende Abbildung soll den Ablauf eine Anfrage im System verdeutlichen. Nachdem der Nutzer die gewünschte Anfrage im Meta-OPAC-Interface eingegeben hat und die Bibliothek gewählt hat, in denen er suchen möchte, werden diese Daten als erstes vom System eingelesen und von der standardisierten CGI-Formatierung [3] in eine systeminterne Form umgewandelt. Diese Form vereinfacht späteres Arbeiten mit den Daten. Nun beginnt der Meta-OPAC zu arbeiten: als erstes wird geprüft, ob der Nutzer überhaupt eine Anfrage eingegeben hat und nicht versehentlich das System gestartet hat, ohne Daten zu senden. Dann wird geprüft, ob der Nutzer mindestens eine Bibliothek gewählt hat, in der gesucht werden soll. Andernfalls wird ihm dazu erneut die Gelegenheit geboten. Sind diese beiden Punkte gewährleistet, werden die Bibliotheksmodule entsprechend der Auswahl des Nutzers aktiviert, die Anfragedaten werden ihnen zwecks Überführung in eine korrekte Anfrage für den entsprechenden Katalog übergeben und alle Anfragen schließlich gestartet.

Das System wartet nun auf eine Antwort von den Bibliotheken. Nach 60 Sekunden werden alle Anfrage, die noch keine Antwort lieferten, abgebrochen. Aus allen vorhandenen Daten erzeugt der Meta-OPAC nun die Trefferübersicht, in die die Trefferzahl bzw. die Nicht-Antwort aller gewählten Bibliotheken einfließen. Diese Übersicht wird ausgegeben und dem Nutzer so die Möglichkeit präsentiert, sich eine der Trefferlisten anzeigen zu lassen.

Durch einfachen Knopfdruck kann der Nutzer seine Wahl treffen, worauf der Meta-OPAC die entsprechende temporäre Datei ausgibt. Diese Dateien sind gekennzeichnet durch einen zeitabhängigen Zugriffscode und einen systeminternen Code für die Bibliotheken. Nach der Ausgabe kann sich der Nutzer Einzeltreffer anzeigen lassen, zu anderen Trefferlisten springen, eine neue Recherche durchführen oder auch den Meta-OPAC ganz verlassen.

Systemsicht Detail- Flowchart Ein näherer Blick soll nun noch auf den genauen Ablauf einer einzelnen Anfrage an eine Bibliothek geworfen werden. Wieder wird dies durch nebenstehende Abbildung visualisiert.

Die Recherchedaten werden nach Feldern (Autor, Titel, Jahr, ISBN sowie die Operatoren) getrennt an das Bibliotheksmodul übergeben. Die Feldinhalte werden an den Leerstellen zerlegt und evtl. erkannte boolsche Operatoren in die Syntax des entsprechenden Systems übertragen. Dann werden die Felder wieder so zusammengefügt, daß sie als zusammenhängende Zeichenkette an den jeweiligen OPAC gesendet werden können.

Sobald eine Antwort erhalten wurde, wird dies dem Steuerprogramm mitgeteilt. Das Bibliotheksprogramm bricht sich nicht selbst ab, wenn keine Antwort nach 60 Sekunden empfangen wurde, sondern das Steuerprogramm tut dies, sofern es keine anderslautendende Mitteilung von dem Bibliotheksprogramm erhalten hat. Im entgegengesetzten Fall einer Antwort wird jedoch nicht gewartet, sondern sofort mit dem Laden der Trefferlisten begonnen. Diese können sich über mehrer Seiten erstrecken, so daß das Programm die Bibliothek u.U. mehrmals bitten muß, die nächste Seite mit Treffern zu senden. Diese Anfrage varieren stets in der Angabe, welche Seite der Trefferliste als nächstes geschickt werden soll. Alle Listen werden vom Bibliotheksprogramm beim zeilenweisen Empfang umformatiert, so daß sie dem generellen Listenformat des Meta-OPACs entsprechen. Die umformatierte Zeile wird in eine temporäre Datei auf die Festplatte des Meta-OPAC-Servers geschrieben.

Damit hat das Bibliotheksprogramm seine Aufgabe erledigt und ist beendet. Andere Programme des Meta-OPACs dienen nun dem Nutzer dazu, die Trefferlisten aus den temporären Dateien auf seinem Bildschirm darzustellen. Über das Steuerprogramm findet die notwendige Kommunikation zwischen diesen Programmen statt, so daß das Anzeigeprogramm die richtige Datei zwecks Ausgabe finden kann. Der Nutzer erhält eine Tabelle im HTML-Format, die er auch zu späteren Verwendungszwecken mit der entsprechenden Funktion seines Browsers abspeichern kann.

Zurück zum Überblick

Existierende Probleme und Erweiterungsmöglichkeiten

Keine Software ist perfekt und fehlerfrei [Lit5]. Dies gilt auch für diese. Neben sicherlich noch vielen unentdeckten Fehlern gibt es jedoch auch Probleme, die nicht so leicht durch kleine Änderungen in den Programmen behoben werden können. Außerdem läßt sich das System noch weitaus verbessern und erweitern. Beide Punkte seien zum Abschluß noch kurz angesprochen.

Existierende Probleme

Ein Problem, welches aber nicht nur den Meta-OPAC betrifft, sondern alle "Meta-Dienste" (Meta-Suchmaschinen, KVK) im Internet, ist die Abhängigkeit von den jeweiligen Zielsystemen. Ein simpler Fall in diesem Zusammhang ist ein Ausfall eines dieser Systeme. Dies kann viele Gründe haben, von der gewollten Abschaltung über den Stromausfall bis hin zu Fehlern im Netzwerk. Im Grunde genommen kann dieses Problem - wie im Meta-OPAC realisiert - nur durch eine eingebaute Wartezeit abgefangen werden, wenn dies auch für den Nutzer auf der Suche nach einer umfassenden Antwort keine befriedigende Lösung darstellt. Eine kompliziertere Variante dieses Problems wäre, wenn eine Bibliothek zwar antworten würde, dies jedoch nur sehr langsam geschieht. Gerade bei langen Trefferlisten entstehen so für den Nutzer lange Wartezeiten, in denen er evtl. gar nichts sieht und die Abfrage schließlich abbricht. Zudem wird dadurch das Netz zum und vom Meta-OPAC über längere Zeit belastet, was dazu führt, daß auch andere Nutzer länger warten müssen. Am schwierigsten gestaltet sich jedoch die Form, daß die empfange Antwort nicht dem Erwarteten entspricht. Natürlich kann ein Programm nur das verarbeiten, was es kennt, und Abweichungen davon führen unweigerlich zu Problemen bis hin zum abrupten Ende (um das Wort Absturz zu vermeiden) der Programmausführung. Dies kann im Meta-OPAC vor allem dann passieren, wenn in den Titeldatensätzen Felder nicht so formatiert sind, wie sie es bei der entsprechenden Bibliothek sein sollten.

Zurück zum Überblick

Erweiterungsmöglichkeiten

Erweitert werden soll der Meta-OPAC noch um eine sortierte Gesamtliste. Da diese "Ineinandersortierung" der einzelnen Listen im günstigsten Fall einen Dublettencheck beinhalten sollte, gestaltet sich dies als schwierig. Schuld sind die schon oft erwähnten uneinheitlich Trefferlisten. Diese enthalten auch entsprechend unterschiedliche Angaben zum Titel und Autor eines Werkes: Manche Kataloge liefern den kompletten Titel, manche schneiden nach einer festgelegten Anzahl von Zeichen diesen ab. Auch das Autorenformat unterscheidet sich in Abkürzungen von Namen, Reihenfolge von Vor- und Nachname sowie in der Anzahl der am Werk beteiligten Autoren. Alles in allem läßt sich deswegen kein vollständiger Dublettencheck durchführen, eine bestmögliche Annäherung läßt sich jedoch realisieren, wenn auch der hohe Sortieraufwand den Server zusätzlich belasten wird. Neben den Titeldaten müßte dann auch die Kennung der Bibliothek in die Trefferliste aufgenommen werden.

Eine weitere Verbesserung wäre - durch den Einsatz von JAVA leicht gegeben - neben der Nutzung des Meta-OPACs via CGI ein weiterer Zugang über JAVA-Applets bzw. JAVA-Applications, die großen Brüder der Applets. Dies hätte zum Vorteil, daß die Kommunikation mit dem Meta-OPAC nicht über einen allgemeinen Browser stattfinden würde, sondern über eine eigens für dieses Problem erstellte Anwendung. Eine in weitem Maße höhere Interaktivität wäre möglich und zudem ließen sich einige Aufgaben wie das Erstellen und Sortieren einer Gesamtliste vom Server auf den Client verlagern, welches eine Entlastung des Servers mit sich brächte. Bislang wurde von dieser Möglichkeit jedoch noch nicht gebrauch gemacht, da nur der CGI-Standard als allgemein verbreitet angesehen werden kann. Schon bei der Nutzung von JAVA-Applets bauen sich technische Hürden auf, durch die man viele Nutzer von vornherein ausgeschlossen hätte.

Zurück zum Überblick

Anhang

Quellen, URLs

[1] Der Meta-OPAC selbst hat die Adresse http://www.ib.hu-berlin.de/~mh/projekte/metaopac/index.html.

[2] Der Karlsruher Virtuelle Katalog ist zu finden unter: http://www.ubka.uni-karlsruhe.de/. Nähere Informationen finden sich auf den KVK-Hilfeseiten unter http://www.ubka.uni-karlsruhe.de/hylib/kvk_help.html und in einem Artikel der RZ-News des Rechenzentrums der Universität Karlsruhe unter http://www.uni-karlsruhe.de/Uni/RZ/Schriften/RZ-News/96/Sep/.

[3] Ausführliche Informationen zum KOBV und Dokumente aller Entwicklungsstadien sowie eine Auflistung aller beteiligten Bibliotheken finden sich unter der zentralen Adresse http://www.kobv.de. Auch Näheres zur Z39.50-Schnittstelle ist dort zu erfahren.

[4] JAVA (http://java.sun.com) ist ein - Entschuldigung für diesen Gefühlsausbruch - wundervolles Produkt der Firma Sun (http://www.sun.com). Eine wichtige Hilfe bei der Meta-OPAC-Entwicklung waren folgende Titel:

Java 1.1 in 21 Tagen : lernen Sie die Grundlagen der Programmierung mit Java 1.1 ; entdecken Sie, wie Sie dynamische und interaktive Web-Seiten mit Java-Applets erstellen ; erkunden Sie die neuen Möglichkeiten wie JDBC, RMI und JavaBeans / Laura Lemay ; Charles L. Perkins.- Haar bei München : SAMS, 1997.- ISBN 3-8272-2009-2

Harold, Elliotte Rusty
Java Network Programming / Elliotte Rusty Harold.- Cambridge : O'Reilly, 1997.- 1. Aufl.- 422 S.- ISBN 1-56592-227-1

[5] Näheres zu bestehenden und behobenen Problemen im Meta-OPAC findet sich unter http://141.20.126.207/testphase.html.

Fußnoten

¹ Zur Vereinfachung verwende ich in diesem Text bei abstrakten Personenbezeichnungen die männliche Form, wobei ich hiermit ausdrücklich weibliche Personen impliziere.

² Diese Zahl ist nicht offiziell, soviele OPACs haben wir im Vorfeld der Meta-OPAC Entwicklung jedenfalls in der Region gefunden. Stand: September 1998.

³ CGI : Common Gateway Interface. Dies ist eine standardisierte Schnittstelle, über welche vom Clienten (Browser) Daten an den (WWW-)Server gesendet werden können. Diese Daten können z.B. vom Nutzer eingegeben worden sein und der Server kann daraus dynamisch eine neue Webseite erzeugen. Die Verwendungsmöglichkeiten sind vielfältig.

⁴ Ein Extrembeispiel ist hier der Berlin-OPAC bei DBI-LINK.

⁵ Lines of Code (Anzahl der Programmzeilen) ist eine gängige Metrik, um die Größe von Softwareprodukten zu spezifizieren. In den 30.000 LoC sind Kommentare und Leerzeilen mitenthalten. Es mag viel klingen, doch handelt es sich "nur" um eine Software mittlerer Größe.