1.
Historischer Exkurs ^
[1]
In den 1970er Jahren – also noch in der Vor-PC-Zeit – entstanden die ersten großen Datenbank-Hosts; genannt seien hier einige willkürliche Beispiele wie DIALOG, LexisNexis oder in Deutschland juris und GBI. Aus dieser Zeit stammen auch die ersten «Standard»-Volltextsysteme wie etwa STAIRS (IBM), GOLEM/PASSAT (Siemens) oder MISTRAL (Honeywell). Unternehmen wie LexisNexis programmieren ihre Systeme bis heute selbst1 . Ebenfalls in diese Zeit fällt die Entwicklung von SGML, die als Basis für juristische Informationssysteme gedacht war. SGML ist die Basis von HTML und heute als XML die Grundlage für fast jede Datenschnittstelle darstellt2 .
[2]
Die Krux schon damals war: Jede Datenbank hatte ihre eigene Nutzerschnittstelle, ihre eigene Retrieval-Sprache und hoch komplexe und individuelle Datenstrukturen. Die Sprachen und Retrievalsystem waren sehr leistungsfähig. Sie beherrschten deutlich mehr Möglichkeiten, als heute typischerweise angeboten werden. Sie waren damit aber auch kompliziert zu handhaben. Die Optimierung der Präzision stand im Fordergrund. Eine Relevanzsortierung fehlte in der Regel.
[3]
Allen gemeinsam war bestenfalls der primitive Zugang über ein TTY-basiertes Verfahren. Die Verbreitung war aufgrund der mangelnden Infrastruktur, der hohen Kosten aber auch der komplexen Bedienung gering. Sie beschränkte sich auf wenige Information Professionals in großen Unternehmen, Kanzleien und Behörden und Freiberuflichen Rechercheuren.
[4]
Durch die steigende Zahl der Datenbanken und die wachsende Vielfalt der Anwenderschnittstellen wurde der Ruf nach Vereinheitlichung laut. Zum Beispiel auf der eigens für Datenbanken entwickelten Messe «infobase» in Frankfurt:
Diverse Referenten auf dem Kongreß monierten, zwischen Bedarf und Angebot klafften immer noch große Diskrepanzen ... Das derzeitige Angebot beschränkte sich noch zu sehr auf unvollständige Lösungen. In puncto Benutzerfreundlichkeit ließen die Datenbanken noch einiges zu wünschen übrig – so fehle eine einheitliche Benutzerschnittstelle. Außerdem hapere es bei den Möglichkeiten der Weiterverarbeitung der aus den Datenbanken gewonnenen Informationen im Unternehmen. (www.computerwoche.de/heftarchiv/1986/22/1164647/ ).
[5]
Entsprechend wurden auch in den 1980er Jahren bereits Lösungen angeboten, die eine einheitliche und übergreifende Recherche in mehreren Datenbanken erlaubten. Zudem wurde mit der Common Command Language (CCL) ein Versuch unternommen, die Abfragesprachen zu vereinheitlichen. Bereits bei diesen Versuchen einer plattformübergreifenden Suche wurde allerdings rasch klar, dass bestenfalls der größte gemeinsame Nenner realisierbar war, und gerade viele lieb gewonnene Sonderfunktionen der einzelnen Anbieter entfielen. Damit verlor aber auch die individuelle Dokumentation mit sehr aufwändig gepflegten Metadaten im globalen Umfeld an Nutzen.
[6]
In den 1990er Jahren begann der Vormarsch der PCs und mit ihnen der CD-ROMs. Damit änderten sich die Benutzeroberflächen und die Kommandozeilen der Terminals wurden von komplexen Suchmasken abgelöst. Mit der Einführung graphischer Benutzeroberflächen verstärkte sich der Druck auf die Anbieter, benutzerfreundliche Lösungen zu bieten. Bereits damals erschienen erste Angebote, die eine Suche über eine einzelne Eingabezeile ermöglichten und fragen der Precision über ein Relevance-Ranking abfingen. Die Einführung einer gemeinsamen kommandozeilenorientierten Retrievalsprache wie CCL hatte sich jedenfalls weitgehend erledigt.
[7]
Durch die Kleinteiligkeit der CD-ROM Angebote potenzierte sich allerdings das Problem der Interoperabilität von einzelnen Informationsangeboten. Zum einen sollten mehrere CD-ROM Angebote gleichzeitig durchsuchbar sein, zum anderen sollten Vernetzungsfunktionen wie aktiver und passiver Hypertext sowie update-haltige Anmerkungen über CD-ROMs mit teilweise unterschiedlicher Software hinweg ermöglicht werden.
[8]
Der juristische Verlag, C.H.Beck ergriff in Deutschland sehr früh die Initiative und entwickelte hierfür ein Konzept, das die neuen Anforderungen prinzipiell erfüllte3 . Eine besondere Herausforderung für umfangreiche Vernetzung von CD-ROMs gerade im juristischen Bereich war die Tatsache, dass die konkreten beim Benutzer installierten Produkte nicht bekannt waren und dieselben Informationen (Gesetze, Entscheidungen) in unterschiedlichen Produkten angeboten wurden. Hierfür wurde in der Schnittstelle ein einheitliches abstraktes Adressschema entwickelt und ein Protokoll definiert, mit dem die Verfügbarkeit etwa von Link-Zielen zur Laufzeit abgefragt werden konnte. Im Falle von Dubletten wurden Kollisionsregeln eingesetzt, die der Benutzer beeinflussen konnte. Dasselbe Verfahren fand bei der Abfrage von Zusatzinformationen zu einem Dokument (Passivverlinkung) Anwendung. Zudem stellte ein virtuelles Bücherregal4 einen einheitlichen Zugriffspunkt auf die installierten Produkte und eine produkt- und softwareübergreifende Suche zur Verfügung.
[9]
Eine andere Art von datenbankübergreifender Suche bot juris an, die eine parallele Suche auf CD und im Onlinebestand ermöglichten.
[10]
Mit dem Siegeszug des Internet schwappte die Welle wieder von der Offline- zur Onlinelösung. Anders freilich als in Österreich wurde wohl in den meisten anderen Ländern eine Vielfalt von Online-Angeboten aufgebaut bzw. in das Internet portiert. Die nun deutlich verbesserte Infrastruktur und die freundlichen HTML-Oberflächen erhöhten die Akzeptanz der Datenbanken. Das HTTP-Protokoll zwang zudem zu neuen Geschäftsmodellen; eine Tendenz zur Flat-Rate war und ist deutlich erkennbar. Die anfänglichen 1:1 Portierungen althergebrachter Online- oder CD-ROM Konzepte wichen sowohl bei der Nutzbarkeit als auch bei der inhaltlichen Ausrichtung und bei den Geschäftsmodellen moderneren Ideen. Datenbanken entwickelten sich vom Ultima-Ratio Instrument zum alltäglichen Arbeitsmittel.
[11]
Insbesondere das rasante Wachstum von Web-Suchmaschinen wie Google signalisiert den Wunsch des Benutzers nach noch einfacheren und umfassenderen Informationswerkzeugen. Diese Angebote stehen mit Sicherheit auch im Wettbewerb zu den klassischen Fachinformationsdatenbanken.
2.
Die Lindeonline Metasuche ^
[12]
Die zunächst – hier natürlich mit einem Fokus auf den deutschen Markt – geschilderte Entwicklung gilt für viele Länder aber nicht ganz so für Österreich. Die technische Entwicklung mag ähnlich gewesen sein aber die Inhalte wurden über lange Zeit von einem Anbieter unter einer Software integral angeboten. Aus Sicht der professionellen Rechtsinformation war dies eine Art Idealzustand.
[13]
Durch die jüngsten Entwicklungen hat der österreichische Markt mit der Entwicklung anderer Märkte gleich gezogen. So hat sich nach dem Vorbild von LexisNexis nun auch der Linde Verlag entschlossen, seine Kernzielgruppen mit einem eigenen maßgeschneiderten Angebot zu versorgen.
[14]
Auch wenn dieses Angebot für Alltagsfragen umfassendes Informationsmaterial zur Verfügung stellt, ergibt sich aufgrund der Angebotsvielfalt – nicht zuletzt durch öffentliche Datenbanken wie RIS, FinDok oder auch EUR-Lex – für den Nutzer immer wieder die Notwendigkeit, ein Problem in mehreren Quellen zu recherchieren.
[15]
Der Linde Verlag hat sich deshalb entschlossen, mit einer eigenen Metasuche (auf eine Abgrenzung von «Metasuche» und dem modernen Buzzword «Federated Search» wird hier verzichtet) dem Benutzer den Zugang zu mehreren Quellen zu ermöglichen. Dabei ging es von Anfang an nicht darum, eine perfekte integrierte Suche zu entwickeln. Vielmehr soll sich der Nutzer an einer praktikablen Einstiegsseite einen Überblick über die Informationsangebote und deren Relevanz für sein Problem machen können. Kernziele der Entwicklung waren deshalb:
- Eine einheitliche einfache Suchmaske für den ersten Einstieg.
- Verteilte parallele Suche auf mehreren Datenbanken.
- Vereinheitlichung der Suchlogik (Standardoperator «UND»; «ODER» und «NICHT» optional).
- Quellenübergreifende Zitierungssuche; d.h. sobald der Nutzer eine Zitierung eingibt, wird das Dokument in der passenden Quelle ohne Umwege geöffnet.
- Gemeinsame Trefferanzeige.
- Nutzung von Schnittstellen der Datenbankanbieter ohne vorherige Authentifizierung.
- Möglichkeit der kundenspezifischen Individualisierung.
[16]
Im Zuge der Planung und Entwicklung wurde von einigen Optionen und Ideen bewusst Abstand genommen:
- Eine eigene Indexierung der Daten wurde als wenig aussichtsreich angesehen, insbesondere wenn es um die Einbindung von individuellen Inhalten der Nutzer oder der anderer Informationsdienstleister geht.
- Eine gemeinschaftliche Trefferanzeige im Sinne einer gemischten Trefferliste ist aus systematischen Gründen nicht möglich. Die Sortierkriterien unterschiedlicher Retrievalsysteme sind nicht vergleichbar. Insbesondere die Relevanzsortierung und das ausgeworfene Ranking sind inkompatibel. Eine gemeinsame Sortierung würde zu keinen brauchbaren Ergebnissen führen.
- Auf eine Umsetzung ausgefeilter Suchstrategien wird ebenfalls verzichtet, da auch hier die Datenstrukturen und insbesondere die Semantik der einzelnen Felder zu unterschiedlich sind. Dem Benutzer wird eine einfache Volltextsuche angeboten. Für detaillierte Suchen wird er in das jeweilige Angebot weitergeleitet.
- Für die Anzeige der Dokumente wird in das jeweilige Angebot geleitet. Eine Anzeige von Dokumenten innerhalb der Metasuche findet nicht statt.
- Eine einheitliche Authentifizierung (Single-Sign-On) ist nicht implementiert.
- Ein unmittelbarer Aufbau des Suchergebnisses auf Seiten des Servers stellte sich als nicht praktikabel heraus. Einige Suchmaschinen haben Antwortzeiten, die mehrer Minuten in Anspruch nehmen können. Es wurde deshalb auf ein asynchrones Verfahren auf Basis von AJAX zurückgegriffen.
[17]
Für den Zugriff auf die Suche von Lindeonline wurde eine eigene Schnittstelle entwickelt, die keine Authentifizierung verlangt. Dabei wurden Ideen aus dem Bereich Open Search (www.opensearch.org ) berücksichtigt. Im Übrigen sind derzeit nur kostenfreie Angebote eingebunden. Hier wurde in der Regel auf die bestmögliche öffentlich zugängliche Benutzerschnittstelle zurückgegriffen.
[18]
Die Anwendung wurde mit Python entwickelt. Die Architektur zeigt Abbildung 1. Jede Datenbank wird über einen Connector angebunden. Das ist ein Objekt mit einheitlichem Interface, das für die Umsetzung der Suche in die jeweilige Datenbanklogik und für die einheitliche Rückgabe der Suchergebnisse zuständig ist. Der Connector erkennt auch die Zitierungsmuster für die in dieser Datenbank zitierten Dokumente und kann die Muster in eine entsprechende URL auflösen.
[19]
Damit ist die gesamte Suchlogik auf dem Metasuchserver implementiert. Der AJAX-Client beschränkt sich auf die Kopie der gelieferten Trefferlisten an die vorgesehenen Stellen.
[20]
Das Ergebnis nach der Ausführung aller Abfragen zeigt Abbildung 2. Der Benutzer erhält eine Liste der durchsuchten Datenbanken mit der jeweiligen Trefferzahl. (Die hier noch ausgegebene Antwortzeit kann natürlich ausgeblendet werden).
[21]
Der Nutzer hat nun die Wahl: Er kann direkt in die jeweilige Datenbank springen und dort die Suche erneut (i.d.R. automatisch) auslösen bzw. noch verfeinern. Er kann sich aber auch durch Klick auf die entsprechenden Einträge die ersten Treffer in der jeweiligen Datenbank anzeigen lassen (Abbildung 3). Der Aufbau ist so gewählt, dass er auch mehrere Trefferlisten öffnen kann. Damit sieht er eine Liste aller Top-Treffer, die er ggf. auch ausdrucken kann.
[22]
Sofern verfügbar werden Ranking-Indikatoren als Sternchen angezeigt, wobei der beste Treffer immer fünf Sternchen (100%) erhält. Der Benutzer kann nun durch Klick auf den Treffer das Dokument in der jeweiligen Datenbankumgebung öffnen.
[23]
Dieses sehr schlichte aber pragmatische Verfahren kommt bisher bei Testnutzern erfreulich gut an. Insbesondere die parallele Recherche in der FinDok wird von Steuerberatern honoriert. Auch die einfache Erschließung von internationalen Quellen stößt auf Interesse.
3.
Ein kleiner Ausblick ^
[24]
Durch das Angebot immer neuer E-Book Lesegeräte, insbesondere aber durch multifunktionale Geräte wie Appels iPad ist ein erneutes Kippen des Marktes von Online- wieder zurück zu Offlinelösungen nicht ganz auszuschließen. Selbst eine umfangreiche juristische Onlinedatenbank passt prinzipiell spielend auf die 16GB bis 64GB Speicher eines iPads oder Smartphones. Die buchartige Bedienung spricht gerade konservative Nutzer an ebenso wie das eher am Kauf als an der Miete orientierte Lizenzmodel.
[25]
Betrachtet man allerdings die aktuellen E-Book Reader, so findet man dieselben Schwachstellen wie in der CD-Ära. Es gibt de facto keine produktübergreifende Suchfunktion und schon gar keine entsprechende Vernetzung. Hypertext ist zwar ins Internet möglich, aber nicht zu einem anderen E-Book auf demselben Gerät. Die Probleme, die sich aus den vielfältigen Kombinationsmöglichkeiten der Produkte und dem hohen Risiko von Dubletten ergeben, sind heute womöglich noch evidenter als früher. Insbesondere sind die Ansprüche der Nutzer an Komfort und Vernetzung eher gestiegen.
[26]
Man darf also gespannt sein, wohin die Entwicklung letztlich geht und ob das Rad noch mehrfach neu erfunden wird.
Matthias Kraft, Lindeverlag Wien AT,matthias@effipub.de
Matthias Kraft, Lindeverlag Wien AT,matthias@effipub.de
- 1 Eine gute Quelle für Interessierte ist das Archiv der Computerwoche, das bis 1974 zurück reicht.
- 2 Lesetipp:www.sgmlsource.com/history/roots.htm .
- 3 Die entsprechende Webseite ist leider nicht mehr verfügbar. Einige Teile der Dokumentation sind noch abrufbar unterhttp://web.archive.org/web/19970625083552/http://www.beck.de/rsw/mats/bcctv/dev/index.html .
- 4 Hansen inwww.jurawelt.com/literatur/mmprogramme/295 .