Abstract

Z39.50 ist ein (inter)nationales Protokoll zur Vernetzung von Datenbankanwendungen. Funktionen - Search, Display, Scan etc. -, die dem Benutzer eines Bibliotheks- oder Datenbankanbieter- (Host-) Systems bisher nur für den Zugriff auf das lokale System, d.h. auf die lokale(n) Datenbank(en) zur Verfügung standen, werden über dieses Protokoll auch auf entfernte Datenbanksysteme anwendbar.

Der erste Teil des vorliegenden Textes beschreibt zunächst allgemein die durch Z39.50 definierten Dienste. Eine anschließende detaillierte Betrachtung des Z39.50-Dienstes SEARCH - zusammen mit der einleitenden allgemeinen Beschreibung - vermittelt einen Eindruck von den Einsatzmöglichkeiten des Protokolls in virtuellen Bibliotheken. Z39.50 stellt geeignete Protokollelemente für den Zugriff auf die verschiedensten Arten von Datenbanken (Literatur-, Fakten-, Volltextdatenbanken etc.) bereit und erlaubt die Übertragung von Rechercheergebnissen in multimedialer Form. Es wird sich zeigen, daß Z39.50 weitaus mehr als nur die Vernetzung derzeit existierender OPACs oder Bibliothekssysteme ermöglicht.

Der zweite Teil des Textes befaßt sich mit den beiden grundsätzlichen Möglichkeiten der Einbindung von Z39.50-Anwendungen ins World-Wide-Web (W3). Eine signifikante Erweiterung des Nutzerkreises der über Z39.50 zugreifbaren Informationsquellen läßt sich erreichen, indem man den Zugriff auf Z39.50 Server-Anwendungen über - die weit verbreiteten, sog. - W3-Browser ermöglicht. Der zweite Teil des Beitrags beschreibt die beiden grundsätzlich Zugriffsmöglichkeiten auf Z39.50 Server-Anwendungen über W3-Browser.

Das ANSI/NISO-Protokoll Z39.50

Z39.50-1995 - auch als Z39.50 Version 3 bezeichnet - ist ein ANSI, d.h. ein amerikanischer nationaler Standard für die Vernetzung von Datenbankanwendungen [1]. Das Protokoll wird Anfang 1996 der ISO zur Verabschiedung als internationaler Standard vorgelegt.
Die Wurzeln des Protokolls reichen zurück ins Jahr 1984. Die Versionen 1 und 2 des Standards wurden in den Jahren 1988 und 1992 als Z39.50-1988 bzw. Z39.50-1992 verabschiedet.
Alle drei Protokollversionen definieren Z39.50 als OSI-Anwendungsprotokoll, d.h. als Protokoll der Ebene 7 des OSI-Modells. Ungeachtet dieser Tatsache wird Z39.50 in nahezu allen Realisierungen als Internet-Protokoll angewandt.

Bis vor wenigen Jahren waren Bibliothekssysteme in sich geschlossenene Systeme. Der Benutzer hatte über seine Benutzeroberfläche lediglich Zugriff auf die lokale(n) Datenbank(en) seines Systems. Um auf Datenbestände eines entfernten Systems zugreifen zu können, mußte sich der Benutzer in das entfernte System einwählen (z.B. über rlogin) und dann über die Benutzeroberfläche des entfernten Systems die gewünschten Recherchen durchführen. Der Benutzer mußte somit mit den Eigenheiten mehrerer Systeme vertraut sein (Abbildung 1). Für die Übertragung von Daten aus dem entfernten ins eigene System waren weitere proprietäre Mechanismen erforderlich.

Die Idealvorstellung, einem Benutzer über seine eigene, ihm vertraute Benutzeroberfläche, unter Verwendung der ihm vertrauten Funktionen den Zugriff auf alle für ihn relevanten Datenbestände zu ermöglichen, war die Basis für die Definition des Protokolls Z39.50. Über Z39.50 werden Funktionen, die dem Benutzer bisher nur für den Zugriff auf die lokalen Datenbestände zur Verfügung standen, auch auf entfernte Datenbanken anwendbar. Aus Sicht des Benutzers besteht prinzipiell kein Unterschied zwischen entfernten und lokalen Datenbanken (Abbildung 2).

Für Bibliotheksangestellte als Nutzer eines Bibliothekssystems vereinfacht sich durch diese Systemöffnung z.B. die Katalogisierung neuer Bibliotheksobjekte, indem Katalogisate aus entfernten Systemen ins eigene System übernommen werden können.
Der Endbenutzer einer Bibliothek - z.B. wissenschaftlicher Mitarbeiter, Student - hat die Möglichkeit, Monographien, Zeitschriften, Dokumente (als Volltext) etc., die im lokalen System nicht nachgewiesen bzw. vorhanden sind, in einem entfernten System ausfindig zu machen.

Der Zugriff auf ein entferntes System erfordert die Übertragung von Anfragen (in OSI-Terminologie, Request-APDU's) vom Client-System zum Server-System und die Übertragung von Antworten (in OSI-Terminologie, Response-APDU's) in umgekehrte Richtung.
Für die Übertragung von Request- und Response-APDU's definiert Z39.50 entsprechende Protokoll-Dienste. Diese seien im folgenden kurz beschrieben.

INITIALIZE

Über diesen Dienst authentifiziert sich die Client-Anwendung gegenüber der Server-Anwendung. Darüber hinaus handeln die beiden Anwendungen für die Dauer der Z39.50-Verbindung (eine physikalische Verbindung kann mehrere aufeinanderfolgende Z39.50-Verbindungen umfassen) gültige, protokollspezifische Parameter, z.B. anzuwendende Protokollversion, anwendbare Dienste, maximale Größe zu übertragender Datenbank-Records etc., aus. Das Client-System initiiert diesen Dienst durch das Senden einer InitializeRequest-APDU. In der zugehörigen InitializeResponse-APDU bestätigt das Server-System die Initialisierung oder lehnt die Initialisierung ab. In letzerem Fall sind (außer erneut dem Dienst INITIALIZE) keine weiteren Dienste anwendbar.

SEARCH

Der Dienst wird von der Client-Anwendung durch Senden einer SearchRequest-APDU initiiert. Die APDU enthält u.a. die im Server-System auszuführende Query, den Namen des durch Ausführung der Query zu erzeugenden ResultSets und den Namen des für die Übertragung der Rechercheergebnisse bevorzugten Formats. Die Server-Anwendung überträgt in der SearchResponse-APDU das Resultat der Query (Anzahl der Treffer), Statusinformation und ggf. ein oder mehrere Records.

PRESENT

Über diesen Dienst fordert die Client-Anwendung die Übertragung von Suchergebnissen (Datenbank-Records) an. In der PresentRequest-APDU spezifiziert der Client neben dem Namen des ResultSets, auf das sich der PresentRequest bezieht, die Nummern der gewünschten Records und das bevorzugte Übertragungsformat. Die Server-Anwendung überträgt die gewünschten Records in der zugehörigen PresentResponse-APDU.

DELETE-RESULT-SET

Dieser Dienst erlaubt das Löschen einzelner oder aller im Server-System innerhalb der aktuellen Z39.50-Verbindung erzeugter ResultSets.

SCAN

Dieser Dienst bietet dem Benutzer die Möglichkeit, (im Server-System lokalisierte) geordnete Listen (z.B. Autoren-, Titel-Index) zu durchsuchen. Die Server-Anwendung liefert die Ergebnisse in einer entsprechenden Antwort (ScanResponse-APDU).

SORT

Über diesen Dienst hat der Benutzer die Möglichkeit, ein im Server-System lokalisiertes ResultSet (das Ergebnis einer vorangegangenen Suche) zu sortieren. Die Server-Anwendung zeigt dem Benutzer in der zugehörigen SortResponse-APDU das Ergebnis der Sortier-Operation (erfolgreich, nicht-erfolgreich) an.

ACCESS-CONTROL

Der Dienst erlaubt es der Server-Anwendung, eine laufende Operation zu unterbrechen, um von der Client-Anwendung weitere Authentifizierungs-Information für den Zugriff auf eine Datenbank oder einen einzelnen Datenbank-Record zu fordern. Die Client-Anwendung muß auf die Anforderung antworten.

RESOURCE-CONTROL

Der Dienst RESOURCE-CONTROL erlaubt es dem Server-System, eine laufende Operation zu unterbrechen um das Client-System zu informieren, daß vereinbarte Resource-Limits überschritten wurden, bzw. voraussichtlich überschritten werden. Im Gegensatz zu ACCESS-CONTROL ist dieser Dienst nicht unbedingt ein bestätigter Dienst. Das Server-System zeigt in der RecourceControlRequest-APDU an, ob es eine Antwort erwartet. Wenn ja, wird die laufende Operation bis zum Eintreffen der ResourceControlResponse-APDU unterbrochen. Im anderen Fall wird die Operation weiter ausgeführt.

TRIGGER-RESOURCE-CONTROL

Der Dienst bietet dem Benutzer die Möglichkeit, vom Server-System das Senden einer zu bestätigenden ResourceControlRequest-APDU, das Senden einer nicht zu bestätigenden ResourceControlRequest-APDU oder den Abbruch der laufenden Operation zu fordern. Der Dienst ist nicht-bestätigt und es bleibt dem Server-System überlassen, ob es die geforderte Aktion ausführt oder nicht. Die Client-Anwendung kann diesen Dienst jederzeit anfordern.
Falls der Benutzer den Abbruch der laufenden Operation angefordert hat und das Server-System die Operation abbricht, muß das Server-System eine der abgebrochenen Operation entsprechende Response-APDU (SearchResponse-, PresentResponse-APDU etc.) an das Client-System übertragen.

RESOURCE-REPORT

Über den Dienst RESOURCE-REPORT hat der Benutzer bzw. das Client-System die Möglichkeit, vom Server-System Information über die bis zum momentanen Zeitpunkt angefallenen Kosten (verbrauchten Ressourcen) anzufordern. Das Server-System stellt die Information in einer entsprechenden Antwort (ResourceReportResponse-APDU) bereit.

SEGMENTATION

Dieser nur in Version 3 definierte Dienst ermöglicht die Optimierung speziell der Übertragung großer Datenbank-Records zwischen Server und Client-System. Für den Dienst sind zwei Varianten definiert:
Level 1 Segmentation läßt nur die Übertragung vollständiger Datenbank-Records innerhalb eines Segments zu (ein Datenbank-Record darf nicht gesplittet werden).
Level 2 Segmentation ermöglicht, daß ein zu übertragender Datenbank-Record auf zwei oder mehr aufeinanderfolgende Segmente aufgesplittet wird.

EXTENDED-SERVICES

Über diesen Dienst initiiert die Client-Anwendung die Ausführung einer sog. Extended Service Task im Server-System. Die Ausführung der Task erfolgt i.a. außerhalb der Z39.50-Verbindung. Über den Dienst SEARCH kann sich der Benutzer, durch Abfrage einer speziellen, im Server-System lokalisierten Extended Services Database, über den Bearbeitungszustand der Task informieren. Derzeit sind folgende Extended Services definiert:

• PersistentResult Set
• PersistentQuery
• PeriodicQuerySchedule
• ItemOrder
• DatabaseUpdate
• ExportSpecification

EXPLAIN

Der Dienst erlaubt dem Benutzer bzw. der Client-Anwendung im Server-System lokalisierte Information über das Server-System abzufragen. Die Server-Anwendung stellt dazu globale Information (Betriebszeiten, Nutzungskosten etc.) und Information über die verfügbaren Datenbanken (Namen der Datenbanken, Unterstützte Attribute etc.) in einer speziellen Explain Database zur Verfügung. Die Client-Anwendung kann diese Datenbank über die Dienste SEARCH und PRESENT abfragen.

MULTIPLE-CONCURRENT-OPERATIONS

MULTIPLE-CONCURRENT-OPERATIONS ist kein Dienst im eigentlichen Sinne, d.h. bietet keine spezifische Funktionalität. In den Protokollversionen 1 und 2 laufen alle Operationen streng sequentiell ab. Nach Senden beispielsweise einer SearchRequest-APDU darf die Client-Anwendung bis zum Eintreffen der SearchResponse-APDU keine weiteren Request-APDUs versenden. In Version 3 sind, falls sich Client- und Server-Anwendung bei der Initialisierung der Z39.50-Verbindung darauf geeinigt haben, parallele Operationen erlaubt. Der Benutzer (die Client-Anwendung) kann in diesem Fall mehrere z.B. SearchRequest-APDUs versenden, ohne auf das Eintreffen der Ergebnisse vorangegangener Requests zu warten.

CLOSE

Über diesen nur in Version 3 verfügbaren Dienst kann die Client- oder Server-Anwendung die Z39.50-Verbindung schließen, ohne dabei die physikalische Verbindung zwischen den beiden Systemen zu beenden.

Für eine detailliertere Beschreibung der einzelnen Dienste muß an dieser Stelle auf die Protokolldefinition [1] verwiesen werden.

Eine protokollkonforme Z39.50-Anwendung muß zumindest die Dienste INITIALIZE, SEARCH und PRESENT unterstützen. Derzeit existierende, über Z39.50 geöffnete Bibliothekssysteme unterstützen darüber hinaus hauptsächlich die optionalen Dienste DELETE-RESULT-SET und SCAN.
Welche der oben beschriebenen Dienste innerhalb einer konkreten Client-Server Verbindung potentiell anwendbar sind, hängt davon ab, welche Dienste von beiden involvierten Anwendungen gemeinsam unterstützt werden. Die Bestimmung der gemeinsam unterstützen Dienste erfolgt dynamisch über den Dienst INITIALIZE. Nach Aufbau der physikalischen Verbindung zwischen Client und Server zeigt das Client-System dem Server-System in der InitializeRequest-APDU die von der Client-Anwendung unterstützen Dienste an. In der InitializeResponse-APDU zeigt das Server-System umgekehrt die von der Server-Anwendung unterstützten Dienste an. Die gemeinsam unterstützten Dienste sind ab diesem Zeitpunkt über die konkrete Verbindung anwendbar.

Die Qualität des Zugriffs auf eine entfernte Datenbank wird, aus Sicht des Benutzers, im wesentlichen durch die Qualität des Dienstes SEARCH bestimmt. Für den Benutzer soll zwischen dem Zugriff auf eine lokale Datenbank und dem Zugriff auf eine entfernte Datenbank kein Unterschied erkennbar sein. Beim Zugriff auf eine entfernte Datenbank muß die Eingabe (Suchfrage) eines Benutzers des Systems A an das entfernte System B übertragen werden. Die in den beiden Systemen lokal verwendeten Query-Syntaxen werden i.a. verschieden sein. Die Suchfrage nach dem von Issac Asimov geschriebenen Buch "Sternstunden der Forschung" könnte beispielsweise in System A in der Form

Um den Aufwand für erforderliche Syntax-Transformationen zu minimieren, sind Suchfragen vor dem Transfer zwischen Client- und Server-System in eine, über das Protokoll definierte, systemunabhängige Transfer-Syntax zu transformieren. Jede Z39.50-Anwendung muß damit max. zwei Transformationen unterstützen:

Die zu definierende Transfer-Syntax muß dabei so "mächtig" sein, daß - theoretisch - eine Abbildung aller in Frage kommenden lokalen Syntaxen in die Transfer-Syntax möglich ist, d.h. daß jede in einem beliebigen Datenbanksystem formulierbare Query auch in der Transfer-Syntax formulierbar ist. In Z39.50 wurde unter der Bezeichnung RPNQuery eine geeignete Transfer-Syntax definiert.
Die Z39.50 RPNQuery-Definition erlaubt die Formulierung - und damit Übertragung - beliebig komplexer Suchfragen. Suchterme können über die Operatoren AND, OR, AND-NOT und PROXIMITY verknüpft werden. Namen von Suchfeldern (Database Entry Points) - z.B. Name des Titel- Autoren- etc. Suchfelds einer konkreten Datenbank - werden als numerische Werte formuliert und übertragen. Die Zuordnung

Suchfeldname -> numerischer Wert

ist durch das ebenfalls innerhalb des Protokolls definierte sog. Attribute-Set Bib-1 festgelegt. Tabelle 1 zeigt einen Ausschnitt des Attribute-Sets Bib-1. (Die Semantik der Attribute ist in [3] beschrieben.)

Durch die Übertragung von Zahlen anstelle von Suchfeldnamen wird das Problem der Groß-/Kleinschreibung von Feldnamen und das Problem, daß semantisch gleiche Suchfelder in verschiedenen Systemen über verschiedenen Namen angesprochen werden, eliminiert.

Im folgenden seien einige als RPNQuery formulierbare Suchfragen verbal beschrieben. Gesucht ist in jedem der folgenden Beispiele der Titel "Sternstunden der Forschung".

1. TIT = Sternstunden der Forschung
   Der genaue Titel ist bekannt.

2. TIT = Sternstunde#
   Nur das erste Wort des Titels ist teilweise bekannt. Das Zeichen # stehe für 0 oder 1 Zeichen.

3. TIT = Sternstunden Forschung
   Mehrere Wörter aus dem Titel sind bekannt. Es ist bekannt, daß die Wörter in der angegebenen Reihenfolge auftreten.

4. TIT = Forschung Sternstunden
   Mehrere Wörter aus dem Titel sind bekannt. Es ist nicht bekannt, in welcher Reihenfolge die angegebenen Wörter auftreten.

term

Relation-Attributes (Typ 2)

Position-Attributes (Typ-3)

Structure-Attributes (Typ 4)

Truncation-Attributes (Typ 5)

Completeness-Attributes (Typ 6)

Die Übertragung der Suchfrage (2)

FIND TIT = Sternstunde#< /dd>

1,4; 3,1; 4,2; 5,1; 6,1; "Sternstunde"

Die bisherigen Beispiele bezogen sich auf typische Recherchen in Literaturdatenbanken. Bei einer Volltextrecherche sucht der Benutzer i.a. nach Dokumenten, die bzgl. eines vom Benutzer vorgegebenen Suchterms (z.B. ein oder mehrere Fachbegriffe) relevant sind. Für die Formulierung solcher Suchfragen sind die Attribut-Typen 3, 5 und 6 ohne Bedeutung. Eine an eine Volltextdatenbank gerichtete Suchfrage könnte - wiederum vereinfacht dargestellt - folgende Form haben

1,1010; 2,102; 4,105, ""

1,1016; 2,102; 4,106; ""

1,1016; 2,102; 4,107, ""

In den vorangegangenen Beispielen wurde stets von Bib-1 als zugrunde liegendem Attribute-Set ausgegangen. Das Protokoll erlaubt jedoch die Verwendung beliebiger, Bib-1 entsprechender Attribute-Sets. Denkbar wären beispielsweise Attribute-Sets in denen musikalienspezifische Use-Attribute (z.B. Komponist, Typ des Werks, Orchesterbesetzung etc.) oder gemäldespezifische Use-Attribute (z.B. Maler, Titel des Bildes, besitzendes Museum etc.) für den Zugriff auf Datenbanken mit entsprechendem Inhalt definiert sind.

Die bisherigen Betrachtungen konzentrierten sich auf die Übertragung von Suchfragen zwischen Client- und Server-Anwendung. Für die Übertragung von Suchergebnissen in die umgekehrte Richtung sind ebenfalls Festlegungen innerhalb des Standards erforderlich.
Z39.50 definiert 15 bibliographische Formate, z.B. UNIMARC, USMARC, CANMARC, MAB etc. und vier ASN.1-definierte Formate für die Übertragung von Suchergebnissen. Während die bibliographischen Formate außerhalb des Standards (in separaten Standards) definiert sind, ist die Definition der vier letzteren Formate Teil des Standards. Die vier Formate seien kurz beschrieben:

SUTRS (Simple Unstructured Text Record Syntax)
Der Inhalt (Autor, Titel, etc.) eines über die Query identifizierten Datenbank-Records wird zeilenorientiert, aber nicht weiter strukturiert bereitgestellt. Die Information ist somit in der Client-Anwendung nicht per Programm bearbeitbar.

OPAC Record Syntax
Der Inhalt eines über die Query identifizierten Datenbank-Records wird in einem der bibliographischen Formate bereitgestellt. Darüber hinaus wird Information bzgl. der Verfügbarkeit, Ausleihbarkeit etc. des realen Objekts in strukturierter Form geliefert.

SUMMARY Record Syntax
Dieses Format ermöglicht die Bereitstellung definierter, ausgewählter Elemente eines Datenbank-Records (z.B. Autor, Titel, Abstract, Dokumentnummer ) in strukturierter Form.

GRS-1 (Generic Record Syntax 1)
GRS-1 ist das weitaus flexibelste aber auch komplexeste Format. Es erlaubt die Bereitstellung beliebiger, vom Benutzer im PresentRequest angeforderter Elemente eines Datenbank-Records in strukturierter Form und beliebiger Repräsentation (z.B. Text als HTML-Dokument, Bild als .gif-Datei etc.).

Die wesentlichen Eigenschaften des Dienstes SEARCH lassen sich wie folgt zusammenfassen:
Der Dienst ermöglicht den Zugriff auf Datenbanken der verschiedensten Art (Literatur-, Fakten-, Volltextdatenbanken) und verschiedenstem Inhalt (literaturspezifisch, musikalienspezifisch etc.). Die im Protokoll definierte RPNQuery erlaubt, für jeden Datenbanktyp und unabhängig vom Datenbankinhalt, die Formulierung sehr präziser Suchfragen. Für die Übertragung von Rechercheergebnissen existieren mehrere Alternativen, wobei GRS-1 die Übertragung multimedialer Information erlaubt.

Daß Z39.50 ein geeignetes Protokoll zur Öffnung von OPAC-, Bibliotheks- und Host-Systemen ist, zeigt die Tatsache, daß in einer Vielzahl solcher Systeme diese Öffnung bereits vollzogen ist, bzw. derzeit vollzogen wird.
In der Bundesrepublik werden, voraussichtlich ab Oktober diesen Jahres, die Datenbanken der Dienstleistungszentren DDB und DBI, der Verbundsysteme BVB, SWB und GBV sowie der Hosts FIZ Karlsruhe und DIMDI über Z39.50 zugreifbar sein. Die innerhalb des Projekts DBV-OSI II realisierte Öffnung dieser Systeme befindet sich zu diesem Zeitpunkt (Mitte März 1996) kurz vor Beginn der beta-Testphase.
Die wichtigsten Bibliotheken der meisten europäischen Länder haben ihre Systeme über Z39.50 geöffnet bzw. werden dies in absehbarer Zeit tun.
In den USA sind mehr als 70 Bibliotheken und Dienstleistungszentren über Z39.50 zugreifbar.

Daß das Protokoll auch außerhalb des Bibliotheks- und Hostbereichs Anwendung findet, zeigen die Beispiele WAIS (Wide Area Information Server) und GILS (Gouvernment Information Locator Service). Beides sind Informationssysteme basierend auf Z39.50-1992.
Jeder WAIS-Server bietet Zugriff auf eine (oder mehrere) Volltextdatenbank(en) und unterstützt die Funktion Relevance-Feedback. Der Benutzer hat die Möglichkeit, über eine erste Recherche (durch Eingabe von Suchbegriffen) ein oder mehrere für ihn interessante Dokumente zu identifizieren. Unter Verwendung eines dieser Dokumente als Suchterm, kann der Benutzer in einer zweiten Recherche Dokumente, die ähnlich dem als Suchterm verwendeten Dokument sind, identifizieren.
Jeder WAIS-Server muß die im Attribute-Set Bib-1 definierten Use-Attribute Any, DocId und Local number, die Relation-Attribute Relevance und Equal, die Structure-Attribute Document text, URx und Local number sowie für die Übertragung von Suchergebnissen GRS-1 unterstützen. Die Unterstützung weiterer Attribut-Typen, -Werte und Übertragungsformate ist optional. Diese und weitere Anforderungen an einen WAIS-Server sind innerhalb des Dokuments Z39.50 Profile for WAIS [2]definiert.

In den USA wird derzeit unter der Bezeichnung GILS ein Netz von Referenzdatenbanken aufgebaut. Ziel dieses Dienstes ist es, der (amerikanischen) Öffentlichkeit Informationsmaterial (z.B. Wirtschaftsdaten, Umweltdaten etc.), das die Regierung mit einem jährlichen Aufwand von mehreren Millionen Dollar erstellt (bzw. erstellen läßt), auf einfache Weise zugänglich zu machen. Die Datenbanken enthalten Hinweise auf verfügbares Informationsmaterial, der eigentliche Zugriff auf die Information wird durch den Dienst nicht abgedeckt. Die Anforderungen an einen GILS-Server sind auch hier in einem entsprechenden Dokument - Z39.50 Profile for GILS [2] - definiert. Jeder GILS-Server muß sechs innerhalb des Profils ausgewählte Bib-1 Use-Attribute und zwei ausgewählte GILS Use-Attribute sowie die Übertragungsformate UNIMARC, SUTRS und GRS-1 unterstützen. Das GILS Attribute-Set ist innerhalb des Profils definiert.

Der Vollständigkeit halber sei an dieser Stelle erwähnt, daß mit Z39.50 Profile for ATS-1 (Author Title Subject) ein auf OPAC- und Bibliothekssysteme anwendbares Profil existiert und mit Z39.50 Profile for Access to Digital Collections bzw. Z39.50 Profile for Museum Collections Information zwei weitere anwendungsspezifische Profile in Bearbeitung sind [2].

Die Definition spezieller Z39.50-Anwendungen, d.h. die Definition von Z39.50 Profilen, ermöglicht die Entwicklung profilspezifischer Z39.50 Client-Anwendungen, z.B. die Entwicklung von WAIS- oder GILS-Clients. Solche speziellen Clients können vor allem bzgl. der Benutzeroberfläche auf das zugrunde liegende Profil abgestimmt sein.

Für die Zukunft denkbar wäre die Entwicklung von Multiprofile Z39.50 Client-Anwendungen. Über solche Clients könnte eine Bibliothek ihren Endbenutzern - abhängig von den vom Client unterstützten Profilen - Zugriff auf die verschiedensten Arten von Z39.50 (basierenden) Server-Anwendungen ermöglichen.

Bibliotheksspezifische Z39.50 Client-Anwendungen sind als public domain Software (z.B. Willow, CanSearch) und kommerziell (z.B. BookWhere?^TM; verfügbar.

Z39.50 Server-Anwendungen sind ein spezieller Typ von Informationsquellen innerhalb des Internet. Der Zugriff auf diese Informationsquellen ist zunächst nur über entsprechende Z39.50 Client-Anwendungen, und damit nur für Nutzer, die Zugang zu solchen Client-Anwendungen haben, möglich. Eine signifikante Erweiterung des Nutzerkreises der über Z39.50 zugreifbaren Informationsquellen läßt sich erreichen, indem man den Zugriff auf Z39.50 Server-Anwendungen über W3-Browser ermöglicht.

Der zweite Teil des vorliegenden Textes beschreibt, die beiden grundsätzlich Zugriffsmöglichkeiten auf Z39.50 Server-Anwendungen über W3-Browser.

Z39.50 Server-Anwendungen im World-Wide-Web (W3)

Das W3 ist charakterisierbar als ein virtuelles Netz von Rechnersystemen mit folgenden Eigenschaften:

• jedes beteiligte Server-System stellt Information verschiedenster Art - Datenbankinformation, Text-, Hypertextdokumente etc. - zur Verfügung
• die von einem Server-System bereitgestellte Information ist über ein Internet-Anwendungsprotokoll - ftp, Gopher, HTTP, Z39.50 etc. - zugreifbar
• der Benutzerzugriff auf die in einem Server-System bereitgestellte Information ist über einen W3-Client (W3-Browser) möglich.

• jedes Z39.50 Server-Anwendung stellt Information (Datenbankinformation) bereit
• die Information ist über das Anwendungsprotokoll Z39.50 zugreifbar

Direkter Zugriff über W3-Browser

Jeder W3-Browser unterstützt (bzw. macht Gebrauch von) mehreren Internet-Anwendungsprotokollen. Im Normalfall sind dies HTTP, ftp und Gopher. Verschiedene Browser unterstützen darüber hinaus das WAIS-Protokoll (basierend auf Z39.50 Version 1). Durch Erweiterung eines Browsers um eine Z39.50 Client-Komponente wird der direkte Zugriff auf Z39.50 Server-Anwendungen möglich. Abbildung 3 zeigt das W3 aus Sicht eines so erweiterten W3-Browsers.

Das dem W3 zugrunde liegende Modell geht davon aus, daß jedes im Internet verfügbare Informationsobjekt (Dokument, "Information-Page", Datenbankinformation etc.) über einen sog. Uniform Ressource Locator (URL) - oder Uniform Ressource Identifier (URI) - adressierbar und damit für einen Benutzer auffindbar ist.
Ein URL ist eine Adresse, die einer allgemeinen Syntax genügt und die gesamte, für das Retrieval des adressierten Objekts erforderliche Information enthält:

• das für den Zugriff auf das Objekt erforderliche Anwendungsprotokoll (z.B. ftp, Gopher, Z39.50, HTTP)
• die physikalische Adresse des Systems, in dem das Objekt lokalisiert ist
• den Pfad zum Objekt innerhalb des Systems.

ftp://user1:user1_passwd@ftp.nlc.bnc.ca/nlc.txt

http://vinca.cnidr.org/reference.html

gopher://president.oic.unc.edu/11/library.d

z39.50r://ddb.dbf.de/PublicOPAC?Doc4711

• eine Verbindung zum Z39.50 Server ddb.dbf.de aufbauen
• die Z39.50 Verbindung mit INITIALIZE eröffnen
• eine RPNQuery mit Use-Attribut docid und Suchterm Doc4711 an das Server-System übertragen (die dort in der Datenbank PublicOPAC ausgeführt würde)
• nach Empfang des Rechercheergebnisses die Verbindung abbauen
• dem Benutzer das Resultat (aufbereitet als HTML-Dokument) präsentieren.

Die Syntaxdefinition des Z39.50 Session-URL entspricht der Syntaxdefinition des Retrieval-URL. Während jedoch über einen Retrieval-URL genau eine vorgegebene Query ausgeführt wird, ist die Intension des Session-URL die, einen Z39.50-Client für eine vollständige Z39.50 Session zu aktivieren. Diese Zugriffsmethode entspricht somit funktional dem Zugriff über den Z39.50-Client.
Durch Aktivieren eines Session-URL öffnet sich dem Benutzer die Oberfläche des Z39.50-Client und dem Benutzer steht die gesamte Funktionalität des Client (SEARCH, PRESENT, SCAN etc.) zur Verfügung. Suchfragen werden in diesem Fall vom Benutzer spezifiziert, die Suchergebnisse werden auf die Z39.50-Client spezifischen Weise (d.h., abhängig vom Client nicht notwendigerweise als HTML-Dokument) aufbereitet und angezeigt. Seit Dezember 1995 stellt die University of Massachusetts die (-Version eines Z39.50-Client als add-on zum W3-Browser Netscape( (Version 1.1N unter Windows 3.11, Windows95 und Windows NT, Version 2.0B1 unter Windows 95) zur Verfügung. Die (-Version der add-on Software ist für nicht-kommerzielle Zwecke frei verfügbar (ftp://www.usgs.gov/pub/gils/ciir/dtic_a02).

Zugriff über HTTP-Z39.50 Gateways

Diese Art des Zugriffs auf SR/Z39.50 Anwendungen erfordert keine Erweiterung des W3-Browsers, dafür aber die Existenz geeigneter HTTP- Z39.50 Gateways. Abbildung 4 zeigt das Zugriffsprinzip.

Die Kommunikation zwischen W3-Browser und Gateway-System erfolgt über das W3-eigene HTTP Protokoll (die HTTP-Komponente der beiden involvierten Systeme). Die Kommunikation zwischen Gateway-System und Z39.50 Server-System erfolgt über das Z39.50 Protokoll (die Z39.50-Komponente der beiden involvierten Systeme).

Das Gateway-System kann entweder als lokales oder als zentrales Gateway realisiert sein. Ein lokales Gateway ermöglicht lediglich den Zugriff auf die lokalen Datenbanken des Systems. Ein zentrales Gateway ermöglicht darüber hinaus den Zugriff auf - aus Sicht des Gateway-Systems - entfernte Z39.50-Anwendungen. Der Aufwand für die Administration eines lokalen Gateways ist dabei weitaus geringer als der Aufwand für die Administration eines zentralen Gateways.

Ein zentrales Gateway-System mit der in Abbildung 4 gezeigten Funktionalität wird beispielsweise von der Library of Congress (LC) betrieben (http://lcweb.loc.gov/z3950/gateway.html). Über dieses Gateway bietet die Library of Congress einem Benutzer Zugriff auf ihre lokalen Datenbanken, und Zugriff auf mehr als 70 weitere amerikanische, kanadische und europäische Z39.50 Server-Anwendungen.

Die folgenden Abbildungen zeigen einen Kommunikationsverlauf zwischen dem W3-Browser Netscape und dem LC-Gateway.

Nachdem der Benutzer, durch Aktivierung eines entsprechenden URL's das LC-Gateway ausgewählt hat, initiiert Netscape das Retrieval der über den URL referenzierten, im Gateway-System lokalisierten Maske (das Retrieval eines HTML-Dokuments) und stellt diese(s) wie in Abbildung 5 gezeigt dar.

Diese Seite enthält die Liste aller über das LC-Gateway erreichbaren Z39.50 Server-Systeme.

Der Netscape-Benutzer wählt nun zunächst den Z39.50-Server, in dem die Recherche durchgeführt werden soll. Nach Auswahl des Z39.50-Servers State Library of Florida initiiert Netscape das Retrieval des referenzierten HTML-Dokuments und präsentiert das Dokument wie in Abbildung 7 gezeigt.

Der Benutzer hat nun die Möglichkeit, Suchbegriffe in die Felder Enter Term 1 ... Enter Term 3 einzutragen und für jeden Suchbegriff auszuwählen, in welchem Suchfeld - Author, Title, Subject, es stehen für jeden Suchterm 19 Suchfelder zur Auswahl - die Suche durchgeführt werden soll. Die einzelnen Suchterme können über die logischen Operatoren AND, OR, AND-NOT verknüpft werden.
Nach Aktivieren des Submit Query Feldes konkateniert Netscape die in den einzelnen Feldern der Maske vorhandene Information auf vordefinierte Weise zu einem Character-String und überträgt diesen - über das HTTP-Protokoll - an das Gateway-System. Dort wird die Query-Information an den Z39.50-Client übergeben, in eine Z39.50 SearchRequest-APDU transformiert und - über das Z39.50 Protokoll - an den zuvor gewählten Z39.50-Server übertragen. Der Z39.50-Client empfängt die vom adressierten Z39.50-Server gesendete Z39.50 SearchResponse-APDU übergibt die Resultate der Suche an das HTTP-Z39.50 Gateway, das diese in ein HTML-Dokument transformiert und an Netscape überträgt. Netscape stellt das empfangene HTML-Dokument wie in Abbildung 8 gezeigt dar.

Das LC-Gateway basiert auf public domain Software und unterstützt die Dienste SEARCH und PRESENT.

Ein von OCLC entwickeltes und vertriebenes Produkt, WebZ Server^TM; , bietet erweiterte Recherchemöglichkeiten und unterstützt zusätzlich den Dienst SCAN. Neben diesem funktionalen Unterschied zwischen den beiden Realisierungen existieren technische Unterschiede, auf die an dieser Stelle jedoch nicht eingegangen werden soll.

Der Umfang der von einem Gateway sinnvollerweise bereitzustellenden Funktionalität hängt wesentlich davon ab, ob der Zugriff auf die über das Gateway erreichbaren Z39.50 Server-Anwendungen kostenfrei erfolgt oder nicht. Falls nur Systeme erreichbar sein sollen, die ihre Datenbanken kostenfrei zur Verfügung stellen, sind die WebZ Server Dienste ausreichend. Soll der Zugriff auf kostenpflichtige Anwendungen (z.B. Datenbankanbieter-Systeme) ermöglicht werden, ist die Bereitstellung weiterer Dienste - z.B. RESOURCE-REPORT, RESOURCE-CONTROL, ACCESS-CONTROL - sinnvoll bzw. sogar erforderlich.

Bei beiden beschriebenen Zugriffsvarianten - Zugriff über erweiterten W3-Browser, Zugriff über Gateway - wird die dem Benutzer zur Verfügung stehende Z39.50 Funktionalität durch die Funktionalität der Z39.50 Client-Anwendung bestimmt.
Die Realisierung von W3-Browsern die den direkten Zugriff auf Z39.50 Server-Anwendungen unterstützen, steckt noch in den Anfängen. Die Zukunft wird zeigen wie leistungsfähig als add-on zu W3-Browsern verfügbare Z39.50 Client-Anwendungen sein können.
Gateway-Realisierungen sind bereits seit einiger Zeit kommerziell und als public domain Software verfügbar und in Betrieb. Diese existierenden Gateway-Realisierungen decken die Anforderungen bzgl. des Zugriffs auf kostenfrei zugreifbare bibliotheksspezifische Z39.50 Server-Anwendungen weitgehend ab.

Beide Zugriffsvarianten haben das Ziel, dem W3-Benutzer über einen W3-Browser den Zugriff auf Z39.50-Anwendungen zu ermöglichen. Vorausgesetzt die Entwicklung erweiterter W3-Browser führt zum gewünschten Erfolg, so werden in Zukunft beide Zugriffsvarianten Anwendung finden. Welche Variante die bevorzugte sein wird, wird von den Anforderungen der W3-Benutzer abhängen. Der Zugriff über die Gateway-Variante wird die für den Benutzer einfachere sein (keine Konfiguration der Z39.50 Client-Komponente erforderlich).

Für die Zukunft sollte der Betrieb eines zentralen Gateways auf nationaler Ebene angestrebt werden. Dieses Gateway sollte alle über ein Gateway sinnvoll zu nutzenden Z39.50-Dienste und ggf. mehrere Z39.50 Profile unterstützen. Direkt über das Gateway erreichbar wären dann alle nationalen Z39.50-Anwendungen. Über entsprechende Links könnte dem Benutzer der Zugriff auf entsprechende zentrale Gateways anderer Länder ermöglicht werden.

Zusammenfassung

Eine Vielzahl von Bibliotheken, Host- und Informations-Systemen hat bereits heute ihre Ressourcen (Literatur-, Fakten-, Referenz-, Volltextdatenbanken) über Z39.50 zugreifbar gemacht. Die Zahl solcher Z39.50-Systeme wird weiter zunehmen.

Einer Bibliothek, die ihr eigenes System über Z39.50 geöffnet hat, ist in der Lage

• entfernte Z39.50-Informationsquellen für bibliotheksinterne Arbeiten (z.B. Katalogisierung) zu nutzen
• ihre eigenen Daten entfernten Bibliotheken für entsprechende Arbeiten zur Verfügung zu stellen
• dem Endbenutzer (einer beliebigen Bibliothek) den Zugriff auf die bibliothekseigenen Daten zu ermöglichen
• dem Endbenutzer der Bibliothek den Zugriff auf entfernte Z39.50-Informationsquellen zu ermöglichen.

Für die Zukunft anzustreben ist der Aufbau und Betrieb eines zentralen Gateways. Über dieses Gateway wären auch nicht-Z39.50-Bibliotheken (z.B. Stadt-, Gemeindebibliotheken, die ihre Systeme nicht über Z39.50 geöffnet haben) in der Lage, ihren Benutzern Information aus Z39.50-Systemen zugänglich zu machen.

Referenzen

1 http://lcweb.loc.gov/z3950/agency
--> The ANSI/NISO Z39.50-1995 document

2 http://lcweb.loc.gov/z3950/agency
--> Z39.50 Profiles

3 http://lcweb.loc.gov/z3950/agency
--> Registered Objects and other definitions
--> Bib-1 Attribute Set semantics

4 http://lcweb.loc.gov/z3950/agency
--> Registered Objects and other definitions
--> Z39.50 URL definition

Begriffe und Abkürzungen