Ausarbeitung von Lösungsansätzen für die Erstellung eines Thesaurus-basierten Geologischen Informationssystems des Bayerischen Geologischen Landesamts München - Technologische Studie -
22.12.2001
Ingo Frommholz, Matthias Hemmje Fraunhofer-IPSI Dolivostr. 15 64293 Darmstadt {frommholz, hemmje}@ipsi.fraunhofer.de

2
Inhaltsverzeichnis1 Problemstellung und Ziel ............................................................................................3 1.1 Das bestehende Bodeninformationssystem..........................................................3 1.1.1 Kern...............................................................................................................3 1.1.2 Geoobjekte ....................................................................................................4 1.2 Anforderungen an das neue Bodeninformationssystem ......................................4 1.3 Ziel dieser Studie .................................................................................................5 2 Ist-Analyse ..................................................................................................................5 2.1 Thesaurus .............................................................................................................5 2.1.1 Relationen im Thesaurus...............................................................................5 2.1.2 Einsatzmöglichkeiten eines Thesaurus .........................................................6 2.2 Schlüssellisten......................................................................................................7 3 Erarbeitung von Lösungsansätzen ..............................................................................8 3.1 Überführung des Kerns in eine Thesaurus-basierte Form ...................................8 3.1.1 Lösung 1.1: Kern als Thesaurus....................................................................8 3.1.2 Lösung 1.2: Schlüssellistenthesaurus als Ontologie ...................................10 3.2 Einbindung eines externen Thesaurus ...............................................................12 3.2.1 Lösung 2.1: Verknüpfen des externen Thesaurus mit den Geoobjekten ....12 3.2.2 Probleme beim Einbinden externer Thesauri..............................................12 3.2.3 Lösung 2.2: Mapping zwischen Thesauri ...................................................13 3.2.4 Lösung 2.3: Mehrere Thesauri als Ontologie .............................................17 4 Marktanalyse einiger existierender externer Technologien ......................................18 4.1 Arten von Systemen...........................................................................................18 4.2 Beschreibung der Systeme.................................................................................19 4.2.1 IC Index 5.0 ................................................................................................19 4.2.2 MultiTes......................................................................................................22 4.2.3 SIS-TMS .....................................................................................................24 4.2.4 Synaptica.....................................................................................................26 4.2.5 Oracle Text..................................................................................................28 4.2.6 Protégé 2000 ...............................................................................................28 4.2.7 Retrievalware ..............................................................................................29 4.2.8 K-Infinity ....................................................................................................32 5 Evaluierung der Lösungsansätze bzgl. externer Technologien.................................35 5.1 Überführung des Kerns in eine Thesaurus-basierte Form .................................35 5.1.1 Evaluierungskriterien..................................................................................35 5.1.2 Evaluierung von Lösung 1.1 .......................................................................36 5.1.3 Evaluierung von Lösung 1.2 .......................................................................38 5.2 Einbindung eines externen Thesaurus ...............................................................39 5.2.1 Evaluierungskriterien..................................................................................39 5.2.2 Evaluierung von Lösung 2.1 .......................................................................39 5.2.3 Evaluierung von Lösung 2.2 .......................................................................40 5.2.4 Evaluierung von Lösung 2.3 .......................................................................41 5.3 Zusammenfassung der Evaluation .....................................................................41 6 Zusammenfassung und Ausblick ..............................................................................42

3
1 Problemstellung und Ziel 1.1 Das bestehende Bodeninformationssystem Das Bayerische Geologische Landesamt (BGLA) in München hat 1992 begonnen, nach den damals bestehenden Vorgaben ein Bodeninformationssystem aufzubauen. Als erster Baustein wurde eine zentrale Datenbank (zDB) für punktbezogene Daten erstellt, welche um den Bereich der so genannten Labordaten ergänzt wurde. Rahmenvorgabe bei all den Arbeiten war, ein Werkzeug für den internen Dienstgebrauch des BGLA zu erstellen, welches die Arbeit der einzelnen Sachbearbeiter unterstützen soll. Die Daten des derzeitigen Informationssystems werden in einer ADABAS-C-Datenbank gespeichert. Bei den Daten selbst handelt es sich um den so genannten Kern, der das wissenschaftliche Vokabular mit der dazugehörigen fachlichen Ordnung enthält, und um die Geoobjekte, die die eigentlichen geologischen Objekte darstellen. 1.1.1 Kern Der Kern setzt sich aus einer Menge von Schlüssellisten zusammen. Eine Schlüsselliste besteht dabei aus einem Schlüssellistenkopf und den Schlüsselelementen selbst. Der Zweck einer Schlüsselliste ist es, das zur Attributierung eines Feldes erlaubte Vokabular abzubilden und die wissenschaftliche Semantik von Begriffen abzubilden und bei der Recherche zu verwenden. Die Schlüsselelmente einer Schlüsselliste können auf verschiedene Art miteinander verknüpft sein: • Als lineare Liste: die Schlüsselelemente liegen in einer bestimmten Sortierreihenfolge vor. Die Sortierbeziehung ist dabei optional und kann auf vom Administrator frei wählbaren Attributfeldern definiert sein. • Als monohierarchische Liste: die Schlüsselelemente befinden sich in einer hierarchischen Beziehung zueinander, d.h. zwischen den einzelnen Objekten existiert eine Vater-Sohn-Beziehung, wobei jedes Objekt nur einen Vater haben kann. • Als polyhierarchische Liste: hier herrscht ebenfalls eine hierarchische Beziehung zwischen den Elementen, aber nun kann ein Objekt auch mehrere Väter haben. Die Schlüsselelemente können verschiedenen Datenmodellen unterliegen. Dieses Datenmodell kann relativ simpel sein, d.h. ein Schlüsselelement besteht nur aus einer eindeutigen ID, einem Kurz- und einem Langnamen. Schlüssellisten mit derartigen Elementen werden einfache Listen genannt. Schlüsselelemente können aber auch einem komplizierterem Datenmodell unterliegen, welches außer den drei genannten auch weitere Attribute und sogar weitere Tabellen, über Relationen verknüpft, enthalten kann. Schlüssellisten, deren Schlüsselelemente ein solches Datenmodell haben, werden komplexe Listen genannt.

4
Die Schlüssellisten werden von einem Datenbankadministrator bzw. von einem Datenadministrator über geeignete Masken gepflegt. Diese Masken reflektieren die unterschiedlichen Datentypen der Schlüsselelemente. Mit ihnen können neue Schlüssellisten angelegt, Schlüsselelemente neu hinzugefügt, modifiziert und gelöscht, sowie innerhalb der Hierarchiebene umgehängt werden. Ferner ist eine Druckfunktion vorhanden. 1.1.2 Geoobjekte Bei den Geoobjekten handelt es sich um punktbezogene Daten zu allen geowissenschaftlichen Fachbereichen. Die Geoobjekte haben keine flächige Ausdehnung, sind also daher durch ein Koordinatenpaar (x, y) eindeutig identifizierbar. Der Datenbestand ist nach Geoobjekttypen gegliedert; diese können zum Beispiel sein: Geohistorische Objekte, Bohrungen, Brunnen, Grundwassermessstellen, Höhlen, usw. Alle Geoobjekttypen haben einen Mindestdatensatz gemeinsamer Stammdaten (z.B. Mindestangaben zur Lage, Zugangsberechtigungen zu den Daten, etc.). Zusätzlich zu diesen gibt es noch fachspezifische Stammdaten, die für die einzelnen Geoobjekttypen spezifische Daten enthalten können. Zusätzlich zu den Stammdaten werden noch Schichtbeschreibungen, Geländebeobachtungen (Zustandsbeschreibungen mit zeitlicher Abhängigkeit), Messreihen und Probenbeschreibungen zu einem Geoobjekt gespeichert. In Abhängigkeit von den Proben können Analysen und Messwerte punktbezogen abgelegt werden. Für die einzelnen Attributfelder kommen meistens die oben erwähnten Schlüssellisten zum Einsatz; sie sorgen dafür, dass die entsprechenden Felder nur mit sinnvollen und gültigen Begriffen gefüllt werden. Für ein Geoobjekt kann es Langzeittransaktionen geben, die mehrere Tage betragen können. Aus diesem Grund wurden in der zDB zwei identische Datenbereiche aufgebaut, der Recherchedatenbestand und der Spiegeldatenbestand. In letzterem befinden sich die aktuell in Bearbeitung befindlichen Objekte; auf diesen Datenbestand haben nur ändernde Benutzer Zugriff. Alle anderen Benutzer greifen auf den Recherchedatenbestand zu. Sind die Änderungen abgeschlossen werden die Daten aus dem Spiegeldatenbestand in den Recherchedatenbestand überführt. Dieses Verfahren sichert einen stets konsistenen Recherchedatenbestand. 1.2 Anforderungen an das neue Bodeninformationssystem Das neu zu erstellende Bodeninformationssystem soll nun nicht mehr ausschließlich für die dienstlichen Belange des BGLA genutzt werden können, sondern als Datenbasis und unterstützendes Werkzeug für den Vollzug eines neu erlassenden Bodenschutzgesetzes gelten. Damit verbunden ist die Erweiterung des Benutzerkreises auf Anwender außerhalb des BGLA um andere Behördern und später evtl. behördenexterne Benutzer. Dies erfordert ein grundlegendes technisches Redesign der bestehenden zDB und der dazugehörigen Anwendungen, sowie eine erhebliche Erweiterung der Datenbasis um neue Datenbereiche (z.B. Flächendaten, Bilder, Originaldokumente, usw). Angedacht ist auch die Anbindung eines externen Umweltthesaurus (z.B. UmweltObjektKatalog UOK) um fachfremden Benutzern mit Hilfe des Thesaurus die Recherche auf den Geoobjekten zu ermöglichen. Ferner soll der Kern in eine Thesaurus-basierte oder ähnliche angemessene Form überführt werden. Dabei soll es auch weiterhin möglich sein, die Schlüssellisten wie gehabt

5
über geeignete Masken fachlich pflegen zu können, inklusive der dafür nötigen Konsistenzchecks. Das neue System soll für 150 konkurrierende Benutzer skalierbar sein; bei den Einzelrecherchen sollen die Antwortzeiten im Sekundenbereich liegen. 1.3 Ziel dieser Studie Diese Studie soll mögliche Lösungsansätz für die oben erwähnten Anforderungen aufzeigen und bereits bestehende Technologien und Produkte, die zur Problemlösung herangezogen werden können, vergleichend untersuchen. Es wird zunächst die Frage untersucht, ob und wie der Kern in eine Thesaurus-basierte oder andere zweckmäßige Form überführt werden kann. Weiterhin werden Möglichkeiten der technischen und konzeptuellen Anbindung der Geoobjekte und ggf. des Kerns an einen externen (Umwelt-)thesaurus betrachtet. Zum Schluß werden verschiedene auf dem Markt befindliche Lösungen beleuchtet, die im neuen Bodeninformationssystem zum Einsatz kommen könnten. 2 Ist-Analyse An dieser Stelle soll herausgearbeitet werden, wie der gegenwärtige Zustand des bisherigen Systems ist und welche Notwendigkeiten aus den Anforderungen an das neue Bodeninformationssystem entstehen. Es wird zunächst das Konzept eines Thesaurus vorgestellt und wo die Einsatzmöglichkeiten eines Thesaurus liegen können. Danach wird betrachtet, wie zurzeit die Schlüssellisten aufgebaut sind. 2.1 Thesaurus Monolinguale Thesauri sind in [ISO 2788] beschrieben. Ein Thesaurus setzt sich dabei aus Deskriptoren, Nicht-Deskriptoren und bestimmten Beziehungen (Relationen) zwischen diesen zusammen. Ein Thesaurus dient, salopp formuliert, dem Ordnen von Fachbegriffen. Dabei werden gleichbedeutende Begriffe (Synonyme) zu Äquivalenzklassen zusammengeführt, die durch einen Deskriptor eindeutig gekennzeichnet werden. So sind z.B. die Begriffe „Telefon“ und „Fernsprecher“ synonym und können mit dem Deskriptor „Telefon“ gekennzeichnet werden. Auf diese Art und Weise lassen sich auch unterschiedliche Schreibweisen für Begriffe (z.B. „Friseur“ und „Frisör“) handhaben. 2.1.1 Relationen im Thesaurus In [ISO 2788] werden folgende Beziehungen zwischen Termen definiert: Äquivalenzbeziehungen Diese dienen dazu, Synonyme und Quasi-Synonyme zusammenzufassen. Dazu werden die Relationen USE und UF (used for) eingeführt. Beispiel:
Telefon
UF Fernsprecher

Fernsprecher

6
USE Telefon
Hierarchische Relationen Diese können sein: • Generische Relationen, die eine IsA-Beziehung zwischen Begriffen bezeichnen. Beispiel: Jeder Papagei ist ein Vogel, einige Vögel sind Papageien. • Hierarchische Ganzes-Teil-Relationen, z.B. “München” - “Bayern” - “Deutschland”. Derartige Relationen werden mit BT (broader term) und NT (narrower term) gekennzeichnet:
Bayern
NT München

München
BT Bayern Assoziative Relationen Hiermit werden Beziehungen zwischen Begriffen hergestellt, die keine der o.g. Beziehung zueinander haben, aber doch irgendwie im Zusammenhang stehen. Diese werden mit der RT (related term) Beziehung miteinander verknüpft. Beispiel:
Schönheit
RT Ästhetik

Ästhetik
RT Schönheit Werden die oben genannten Relationen zusätzlich noch nach Aspekten unterschieden, so redet man von Polydimensionalität. Diese Polydimensionalität wird durch Facetten dargestellt. Beispiel:
Auto
<nach Antriebsart>
NT Dieselauto
NT Elektroauto

<nach Zweck>
NT Rennauto
NT Sportauto “Zweck” und “Antriebsart” sind hier zwei unterschiedliche Facetten. 2.1.2 Einsatzmöglichkeiten eines Thesaurus Ein Thesaurus kann auf zweierlei Art in einem Informationssystem eingesetzt werden. Zum einen bei der Indexierung, bei dem aus den Datenbeständen ein Indexat erzeugt

7
wird. Dies kann z.B. so aussehen, dass jeder vorkommende Term im Datenbestand auf seinen Deskriptor abgebildet wird. Würde ein Attribut in einem Geoobjekt z.B. den Wert “Stein” haben, und gäbe es im Thesaurus die Relation Stein USE Gestein, so würde im Indexat für das Geoobjekt nun als Attributwert “Gestein” stehen. Hieraus ergibt sich auch die zweite Einsatzmöglichkeit eines Thesaurus, bei der Wiedererlangung der Information, beim Retrieval. Gibt ein Benutzer nun als Suchwort Stein ein, so würde mit Hilfe der USE-Beziehung diese Anfrage in eine Anfrage nach Gestein umformuliert werden; dieses würde im Gegensatz zu Stein im Indexat gefunden werden. Vorteil dieser Methode, die Geoobjekte mit den Deskriptoren zu indexieren und die Suche nur auf Deskriptoren zu ermöglichen ist, dass auf diese Weise Synonyme wie “Stein” und “Gestein” gehandhabt werden können. Der Thesaurus kann ferner noch zur Anfrageerweiterung benutzt werden. So könnte man z.B. zulassen, dass bei der Suche alle narrower terms eines Terms mit einbezogen werden. Eine Anfrage Kernbohrung drehend könnte somit zu einer Anfrage Kernbohrung drehend OR Seilkernbohrung OR Rotationskernbohrung OR Rotationstrockenkernbohrung erweitert werden. 2.2 Schlüssellisten Wie bereits erwähnt, besteht eine Schlüsselliste aus einen Listenkopf und den eigentlichen Listenelementen. Die Listenelemente selbst können dabei als Liste, als Hierarchie und als Polyhierarchie aufgebaut sein. Zwischen den Listenelementen kann es unterschiedliche Relationstypen geben. Von diesen wurden im vorliegendem Auszug aus dem bisherigen Informationssystem folgende identifiziert: • Vater bezeichnet eine hierarchische Beziehung zwischen zwei Schlüsselelementen. • jünger und älter bezeichnen eine temporale Beziehung zwischen zwei Schlüssellelementen. • Erstspezialisierung • Referenz auf Spezialisierung Zusätzlich dazu hat jedes Schlüssellistenelement, welches kein anderes Schlüsselelement als Vater hat (sich also ganz oben in der Hierarchie befindet), den Schlüssellistenkopf als übergeordnetes Element. Dabei kann es durchaus sein, dass in einer Schlüsselliste mehrere Schlüsselelemente existieren, die ganz oben in der Hierarchie anzusiedeln sind. Da die Schlüssellisten der Verwaltung des Fachvokabulars des BGLA dienen, ist es sinnvoll, über eine Überführung der Schlüssellisten in eine Thesaurus-Form nachzudenken. Dies hat u.A. den Vorteil, dass man somit auf eine Fülle bereits existierender Softwareprodukte zur Thesaurusverwaltung zurückgreifen kann. Abbildung 1 zeigt ein Beispiel einer Schlüsselliste. Die Schlüssellisten im bisherigen Kern verteilen sich auf ca. 220 verschiedene Schlüssellistentypen. Schlüsselelemente eines Typs charakterisieren sich durch ihre Attribute und ihre Relationstypen. So taucht z.B. die Vater-Relation bei jedem Schlüsselelementtyp auf, während die jünger/älter-Relationen nur bei bestimmten Typen vertreten sind.

8


Abbildung 1. Beispiel einer Schlüsselliste
3 Erarbeitung von Lösungsansätzen Aus den Anforderungen an das neue Bodeninformationssystem und der Ist-Analyse ergeben sich folgende Aufgabenstellungen: 1. Überführung des Kerns in eine Thesaurus-basierte Form 2. Einbindung eines externen Thesaurus zur Recherche; dabei kann auch der aus Punkt 1 erzeugte Thesaurus zur Recherche herangezogen werden. Die Aufgabenstellungen sollen nun im Einzelnen betrachtet werden. 3.1 Überführung des Kerns in eine Thesaurus-basierte Form In Abschnitt 2.2 wurden bereits die Relationstypen, die in der Schlüsselliste vorkommen, identifiziert: Vater, jünger, älter, Erstspezialisierung und Referenz auf Spezialisierung. Je nach Schlüssellistentyp treten verschiedene Attribute und Relationstypen bei den Schlüsselelementen auf. 3.1.1 Lösung 1.1: Kern als Thesaurus Um nun den Kern, d.h. die Schlüssellisten, in eine Thesaurus-basierte Form zu bringen, muß man die vorhandenen Relationstypen auf die Thesaurus-üblichen Relationstypen, die in Abschnitt 2.1.1 eingeführt wurden, abbilden. Sieht man die einzelnen Schlüsselelemente als Deskriptoren, so läßt sich die Vater-Relation auf

9
hierarchische Relationen im Thesaurus abbilden, da durch die Vater-Relation eine Hierarchie der Schlüsselelemente gegeben ist. Ist A Vater von B, so ist im Thesaurus A broader term von B und B narrower term von A. Ferner: Ist A Schlüsselkopf der Schlüsselliste, so gilt für jedes Schlüsselelement B, welches in der Schlüsselliste keinen Vater hat: A ist broader term von B und B ist narrower term von A. Damit werden die Schlüssellistenköpfe ebenfalls in den Thesaurus eingebunden. Die anderen in Abschnitt 2.2 aufgeführten Relationstypen lassen sich leider nicht in die jeweiligen Thesaurus-üblichen umwandeln, da sie eine spezielle Semantik haben, die mit den Thesaurus-Relationen nicht abgedeckt werden kann. Aus diesem Grunde sollen sie so beibehalten werden, wie sie sind. Dementsprechend hat man es nicht mehr mit einem reinen Thesaurus und den nach [ISO 2788] definierten Relationstypen zu tun, sondern muß von einem erweiterten Thesaurus ausgehen, bei dem zusätzliche Relationstypen definiert werden. Um die verschiedenen Schlüssellistentypen zu überführen, muß man im erweiterten Thesaurus mehrere Objekttypen definieren, die die Attribute und Relationstypen der jeweiligen Schlüssellistenelemente enthalten. Die vorhandenen Schlüssellisten müssen alle in einen Thesaurus integriert werden; ggf. muß ein übergeordnetes Thesauruselement definiert werden, zu welchem die bisherigen Schlüssellistenköpfe eine NT-Beziehung haben. Abbildung 2 zeigt beispielhaft, wie aus zwei Schlüssellisten, die den Listenkopf “Bohrtechnik, Bohrverfahren” bzw. “Stratigraphische Einheiten” haben, ein Thesaurus entsteht. Um beide Schlüssellisten innerhalb eines Thesaurus zu integrieren, wurde das übergeordnete Element “Schlüsselliste” geschaffen, das broader term zu den beiden bisherigen Schlüssellistenköpfen ist.
Abbildung 2. Schlüsselliste als Thesaurus Im Folgenden wird der durch eine wie auch immer geartete Transformation aus den Schlüssellisten erzeugte Thesaurus geologischer Thesaurus oder Schlüssellistenthesaurus genannt.

10
3.1.2 Lösung 1.2: Schlüssellistenthesaurus als Ontologie Eine Ontologie ist ein formales Modell einer Anwendungsdomäne, das dazu dient, den Austausch und das Teilen von Wissen zu erleichtern. Die Ontologie wird ausgedrückt durch eine logische Theorie, die sich zusammensetzt aus einem Vokabular und einer Menge von logischen Aussagen zu der jeweiligen Anwendungsdomäne [Mädche et. al 2001]. Die Elemente einer Ontologie können polyhierarchisch angeordnet sein. Sehr häufig werden sie, wie aus der objektorientierten Welt bekannt, als Klassen gesehen, die Instanzen haben können. Elemente einer Ontologie unterscheiden sich aber von den Klassen in der objektorientierten Welt dadurch, dass sie keine Methoden haben. Ontologieelemente können so genannte Slots haben, mit deren Hilfe man Relationen und Attribute erstellen kann (ein Attribut wird z.B. als eine Relation zu einem String oder einem numerischen Wert angesehen). Der Einfachheit halber nennen wir die Ontologieelemente Klassen, die zu anderen Klassen Relationen haben können und Attribute besitzen. Es ist möglich, den Schlüssellistenthesaurus als Ontologie darzustellen. Abbildung 3 zeigt eine mögliche Modellierung. Jedes Kästchen markiert eine Klasse in der Ontologie. Die durchgehenden Linien zeigen eine IsA-Beziehung an, die gestrichelten Linien Relationen zwischen Instanzen der jeweiligen Klassen. „Ding“ ist dabei die jeder Ontologie übergeordnete Klasse. Darunter befinden sich Terme und der Thesaurus. Terme wiederum können Deskriptoren1 und Nicht-Deskriptoren sein. Deskriptoren haben zueinander die bekannten BT-, NT- und RT-Beziehungen und zu Nicht-Deskriptoren die UF-Beziehung. Wie Schlüssellisten auch, können Deskriptoren in unterschiedliche Typen aufgeteilt werden. So kann es bei den Deskriptoren z.B. die Typen „Regis“ und „Stratigraphische Einheiten“ geben, die durch die entsprechenden Klassen modelliert werden. Jeder Typ kann zusätzlich zu den Deskriptor-Relationen noch eigene Relationen haben, z.B können die stratigraphischen Einheiten eine jünger/älter-Relation haben. Die BT/NT-Relationen der „Deskriptor“-Klasse sollte dabei überladen werden, d.h. BT/NT sollte z.B. nur zwischen stratigraphischen Einheiten gelten, oder zwischen „Regis“-Instanzen usw. Nicht-Deskriptoren haben eine USE-Relation zu Deskriptoren. Ein Thesaurus selbst ist eine Instanz der Klasse „Thesaurus“. Jede dieser Instanzen hat Beziehungen zu einer Anzahl Instanzen von Deskriptoren (bzw. deren Subklassen) und Nicht-Deskriptoren. Der Vorteil dieser Vorgehensweise ist die, dass man fast nur Instanzen verwalten muß und wenig Klassen. Nicht-Deskriptoren sind frei zugänglich. Allerdings hat diese Methode den Nachteil, dass zu einer Klasse sehr viele Instanzen existieren können. Wenn man nun z.B. für einen Deskriptor einen Nicht-Deskriptor auswählen muß, bekommt man u.U. eine sehr lange Liste von möglichen Termen präsentiert. Hier muß die Aufarbeitung im User Interface entsprechend effizient gestaltet werden.
1 Genauer: Instanzen der Klasse “Deskriptor”. Genauso ist ein Term eine Instanz der Klasse “Term” usw.

11
Abbildung 3. Thesaurus als Ontologie Eine andere Möglichkeit, einen Thesaurus als Ontologie zu modellieren, ist die, jeden Deskriptor als Klasse dieser Ontologie anzusehen. Die Ontologie würde dann ähnlich aussehen wie in Abb. 2. Jede Klasse hat nur eine Instanz, in der die Relationen zu anderen Deskriptoren abgebildet werden und alle Terme, die mit der USE-Relation mit dem Deskriptor verbunden sind, in einem Listenattribut dieser Instanz geführt werden. Abbildung 4 zeigt ein Beispiel. Es ist bei dieser Vorgehensweise auch möglich, die verschiedenen Typen von Deskriptoren im Schlüsselthesaurus abzubilden. So können die Klasse „Stratigraphische Einheiten“ und alle Subklassen die zusätzliche jünger/älter-Beziehung erhalten und die BT/NT-Relationen können entsprechend überladen werden, so dass derartige Relationen nur zwischen den Elementen, die früher einer Schlüsselliste angehörten, möglich sind.
Abbildung 4. Deskriptoren als Klassen Vorteil dieser Vorgehensweise ist, dass die Sichtweise, Deskriptoren als Konzepte zu sehen, hier besser unterstützt wird und diese Sichtweise natürlicher wirkt als jene, die Deskriptoren und Nicht-Deskriptoren als Instanzen zu sehen. Nachteil ist, dass die Nicht-Deskriptoren in den Attributfeldern der Deskriptoren „versteckt“ sind. Hat man den Schlüssellistenthesaurus derartig als Ontologie modelliert, kann man die auf dem Markt befindlichen Tools zur Verwaltung von Ontologien für die Problemstellung berücksichtigen.

12
3.2 Einbindung eines externen Thesaurus Eine Zielsetzung des neuen Bodeninformationssystems ist es, einen externen Thesaurus, z.B. den UmweltObjektKatalog UOK, einzubinden. Dies bedeutet, dass Benutzer mit Hilfe dieses externen Thesaurus Recherchen auf dem geologischen Datenbestand des BGLA durchführen können. Es soll in diesem Abschnitt 3.2.1 zunächst einmal vorgestellt werden, wie ein externer Thesaurus mit den Geoobjekten verknüpft werden kann. Danach wird auf mögliche Probleme bei der Einbindung externer Thesauri hingewiesen. Eine in der Literatur vorgeschlagene Lösung dieser Probleme ist das Mapping zwischen den Thesauri. Es wird erläutert, welche Möglichkeiten des Mappings vorhanden sind und welche Probleme existieren. 3.2.1 Lösung 2.1: Verknüpfen des externen Thesaurus mit den Geoobjekten Eine Möglichkeit, einen externen Thesaurus einzubinden, besteht darin, unter Umgehung des internen Thesaurus den externen Thesaurus direkt mit den Geoobjekten zu verknüpfen. Eine Art, dies zu tun, ist zu schauen, ob der jeweilige Deskriptor eines externen Thesaurus als Attributname oder Attributwert in den Metadaten des Geoobjekt als Substring enthalten ist. Abbildung 5 zeigt dies exemplarisch an dem Deskriptor “Boden”. Dieser Deskriptor würde nun mit den grau gefärbten Objekten und Attributen des Geoobjekts verknüpft werden.
Abbildung 5. Verknüpfung der Geoobjekte mit einem externen Thesaurus 3.2.2 Probleme beim Einbinden externer Thesauri Die einfachste Form, einen externen Thesaurus einzubinden besteht darin, mit den Termen des externen Thesaurus selbst eine Recherche durchzuführen, den internen Thesaurus also nicht zu berücksichtigen (wie oben beschrieben). Eine Anfrage, die mit Hilfe des externen Thesaurus erstellt wurde, würde also unverändert an das Informationssystem gestellt werden. Diese Vorgehensweise kann jedoch einige Probleme beinhalten, die in [Doerr 2001] beschrieben werden: • Für ein und denselben Sachverhalt können sich in unterschiedlichen Thesauri unterschiedliche Wörter befinden (z.B. weil in Thesaurus A für einen Sachverhalt ein anderer Deskriptor gewählt wurde als in Thesaurus B).

13
• Unterschiedliche Abdeckung eines Themengebietes. Zum Beispiel könnte ein geographischer Thesaurus A Staaten und Städte beinhalten, währen ein Thesaurus B nur Staaten und Bundesländer enthält. • Unterschiedliche Bedeutung eines Deskriptors. Beispiel: In Thesaurus A kann mit dem Begriff “Parlament” ein Gebäude gemeint sein, während Thesaurus B eine Versammlung meint. In der Literatur wird meist ein Mapping zwischen den Termen des externen Thesaurus und den Termen des internen Thesaurus vorgeschlagen. 70% der Attribute in der zDB werden mit Werten aus Referenzfelder gefüllt, die direkt mit den Termen der Schlüsselliste (und damit mit den Termen des späteren internen Thesaurus) verknüpft sind ([Kern]). Aus diesem Grund bietet es sich an, die Möglichkeiten des Mappings näher zu betrachten. 3.2.3 Lösung 2.2: Mapping zwischen Thesauri Mapping bedeutet, dass zwischen den Termen eines externen Thesaurus und denen des internen Thesaurus eine Beziehung besteht, ein Term des externen Thesaurus also auf einen oder mehrere Terme des internen Thesaurus abgebildet werden. Die Beziehung zwischen den Termen soll dafür sorgen, dass letztendlich eine sinnvolle Anfrage an das System mit Hilfe der Thesauri erstellt wird, dient also der Anfrageerweiterung. Dies kann z.B. durch die Transformation eines Anfrageterms geschehen. Beispielhaft ist dies in in Abb. 6 dargestellt; hier wird die Benutzereingabe t1 durch das Mapping zwischen dem externen und internen Thesaurus in die für das System sinnvollere Anfrage t5 umgewandelt. Es ist aber nicht nur eine Ersetzung des Ausgangterms denkbar; die Anfrage hätte auch in t1 OR t5 umgewandelt werden können. In beiden Fällen wäre das relevante, fett umrandete Datenobjekt gefunden worden.
Abbildung 6. Termtransformation zwischen Thesauri Das Mapping eines einzelnen Terms in Thesaurus A auf einen anderen Term in Thesaurus B kann allerdings unvollkommen sein. Wie oben erwähnt, kann es sein,

14
dass ein Sachverhalt in dem einen Thesaurus anders abgedeckt wird als in dem anderen. Zum Beispiel könnte Thesaurus A den Zeitabschnitt “Pleistozaen” kennen, während Thesaurus B nur “Mittelpleistozaen” und “Jungpleistozaen” kennt. Eine mit Hilfe von Thesaurus A erstellte Anfrage Pleistozaen müßte dann u.U. in die Anfrage Mittelpleistozaen OR Jungpleistozaen umgewandelt werden. In [ISO 5964] werden multilinguale Thesauri besprochen. Multilinguale Thesauri dienen dazu, für einen Begriff in einer Sprache einen Begriff in einer anderen Sprache zu finden. Dabei wird gefragt, inwieweit Äquivalenzen zwischen den Begriffen der Thesauri herrschen. Folgenden Äquivalenzen werden in [ISO 5964] ermittelt: • exact equivalence, bei denen ein Term in Thesaurus A exakt durch einen Term in Thesaurus B ausgedrückt werden kann, • inexact equivalence, bei denen ein Term in Thesaurus A zwar durch einen Term in Thesaurus B ausgedrückt werden kann, die Semantik aber nicht exakt getroffen wird, • partial equivalence, bei denen ein Term in Thesaurus A nicht exakt durch einen Term im Thesaurus B ausgedrückt werden kann, es aber einen Term in B gibt, der eine breitere Bedeutung hat als der Term in Thesaurus A, • single-to-multiple equivalence, bei denen die Semantik eines Terms in Thesaurus A durch mehrere Terme in Thesaurus B ausgedrückt werden kann. Die in [ISO 5964] besprochene Problematik hat Ähnlichkeiten mit der vorliegenden. Freilich haben wir es aber nicht mit einem multilingualen Thesaurus zu tun, sondern Begriffe eines Fachgebiets sollen in Begriffe eines anderen Fachgebiets “übersetzt” werden. Aus diesem Grund sollten Deskriptoren mit Konzepten identifiziert werden. Jedes Konzept wird als eine Menge von Objekten gesehen, die es repräsentiert. Ein Deskriptor in Thesaurus A kann mit dem Deskriptor “Houses” dasselbe meinen wie ein Deskriptor “Haus” in Thesaurus B. In [Doerr 2001] wird das so genannte concept based mapping vorgeschlagen. Die Sichtweise, dass jeder Deskriptor für ein Konzept steht, wird hier übernommen. In diesem Kontext kann man nun einige Prinzipen des concept based mapping aufstellen: • Ein Term wird auf jene Menge von Objekten abgebildet, die er korrekt klassifiziert. Somit ist z.B. festgelegt, dass ein Term “Haus” auf Gebäude abgebildet wird und nicht auf eine Herkunftsbezeichnung (“er kommt auf gutem Haus”). • Die BT/NT-Beziehungen bezeichnen eine generische Beziehung, d.h. die BT/NT-Beziehungen definieren ein echtes Unter-/Obermengenverhältnis. So würde z.B. Gebäude BT Haus bedeuten, dass jedes Objekt, das als Haus klassifiziert wurde, zugleich auch ein Gebäude ist. • Relationen zwischen Termen können somit als Mengenrelationen angesehen werden. Es können nun, basierend auf den Inter-Thesaurus-Relationen, die in [ISO 5964] vorgestellt werden, folgende Äquivalenzen zwischen Termen definiert werden ([Doerr 2001]):

15
• broader equivalence: breitere Äquivalenz, “ist Obermenge von” • narrower equivalence: engere Äquivalenz, “ist Untermenge von” • exact equivalence: exakte Äquivalenz, “ist dieselbe Menge” • inexact equivalence: inexakte Äquivalenz, “ist überlappend mit” • single-to-multiple equivalence wird hier als compound equivalence definiert, mit den booleschen Operatoren AND, OR und NOT. So kann ein Term aus Thesaurus A eine der vier oben definierten Äquivalenzen zu einer Verknüpfung von Termen in Thesaurus B haben, also z.B.eine narrower equivalence zu a AND b. Die broader und narrower equivalence sind dabei eine Weiterentwicklung der in [ISO 5964] erläuterten partial equivalence. Man kann Mengen und deren Operationen auch mit Hilfe boolscher Ausdrücke beschreiben. Hat man die Mengen A und B, so bezeichnet der Ausdruck A AND B alle Objekte, die sich in der Schnittmenge von A und B befinden. Der Ausdruck A OR B bezeichnet alle Objekte, die sich in der Vereinigung von A und B befinden. In diesem Sinne kann man nun mit Hilfe der oben angegeben Äquivalenzen das Mapping zwischen Termen zweier Thesauri ausnutzen, um eine sinnvolle Anfrageerweiterung zu bekommen. Im Falle der exact equivalence kann man das Mapping eines Terms a auf die Terme b und c mittels einer AND oder OR-Verknüpfung realisieren. Abb. 7 zeigt eine OR-Verknüpfung. Eine Anfrage nach dem Term a in dem einen Thesaurus kann in eine Anfrage nach b OR c im anderen Thesaurus umgewandelt werden. Dies wäre gleichbedeutend damit, im Thesaurus B den Term a als broader term von b und c zu installieren. Durch das vorausgesetzte echte Ober-/Untermengenverhältnis der BT/NT-Relation bedeutet ja ein Einsetzen von a als broader term von (ausschließlich) b und c nichts anderes als die Vereinigung der durch b und c dargestellten Mengen.
Abbildung 7. Exact equivalence mit OR compound Ähnlich kann man auch eine exakte Äquivalenz mittels AND realisieren. Wird a auf b AND c abgebildet, so wäre das gleichbedeutend damit, a in Thesaurus B als gemeinsamen narrower term von b und c einzufügen; alle Objekte würden damit

16
addressiert, die in der Schnittmenge von b und c liegen. Abbildung 8 veranschaulicht die Situation.
Abbildung 8. Exact equivalence mit AND compound Es kann allerdings vorkommen, dass ein Term im externen Thesaurus A nicht exakt in der oben beschriebenen Art und Weise auf einen oder mehrere Terme des Thesaurus B abgebildet werden kann. In [Doerr 2001] wird deshalb vorgeschlagen, in diesem Fall die Annäherung an den internen Thesaurus so weit wie möglich zu verfeinern. Dafür benötigt man nun die broader und narrower equivalence. Für einen Term a sollen der nächste broader und der nächste narrower term gefunden werden. Folgende Regeln können dabei aufgestellt werden (anlehnend an [Doerr2001]): 1. Hat ein Term a keine exakte Äquivalenz zu einem oder mehreren Termen im Thesaurus B, so sollte zumindest eine broader equivalence und eine narrower equivalence zu geeigneten Termen in Thesaurus B gefunden werden. 2. Die broader equivalence sollte minimal sein, d.h. es sollte kein Term im Thesaurus B zu finden sein, der broader term zum Term a, aber enger als die gegebene broader equivalence ist. 3. Die narrower equivalence sollte maximal sein, d.h. es sollten keine Terme im Thesaurus B zu finden sein, die narrower terms zu a und breiter als die gegebenen narrower terms sind. 4. Dem Benutzer sollte die Möglichkeit gegeben werden, zwischen der broader equivalence und der narrower equivalence zu wählen.

17
Abbildung 9 verdeutlicht beispielhaft den Einsatz der broader und narrower equivalence. a hat eine broader equivalence zu d und narrower equivalences zu b und c.
Abbildung 9. Broader/narrower equivalence Das bisher Besprochene bezieht sich, wie erwähnt, auf generische Relationen. Es gibt aber noch die hierarchischen Ganzes-Teil-Relationen, die in [ISO 2788] vorgestellt werden. Eventuell läßt sich das oben besprochene aber auch auf solche Relationen anwenden. So kann zwischen “Bayern” und “München” keine generische IsA-Beziehung realisiert werden; wohl kann man aber sagen, dass z.B. eine Person, die in München lebt, sicher eine Person ist, die in Bayern lebt. Es hängt also von der eigentlichen Semantik ab, inwieweit sich oben Besprochenes praktisch auf das Problem anwenden lassen kann. 3.2.4 Lösung 2.3: Mehrere Thesauri als Ontologie In Abschnitt 3.1.2 wurde besprochen, wie man einen Thesaurus als Ontologie modellieren kann. Die dort entwickelte Ontologie soll nun erweitert werden, um mehrere Thesauri verwalten zu können. Abbildung 10 zeigt als Beispiel, wie der UmweltObjektKatalog UOK und der geologische Thesaurus GLA als Ontologie modelliert werden könnten. Deskriptoren sind nun aufgeteilt in UOK-Deskriptor und GLA-Deskriptor. Wie in Abschnitt 3.1.2, werden auch hier die GLA-Deskriptoren in ihre unterschiedlichen Typen unterteilt. Dabei sollten wieder die NT/BT- und RT-Relationen entsprechend überladen werden, so dass kein GLA-Deskriptor eine solche Beziehung zu einem UOK-Deskriptor hat. Zwischen UOK-Deskriptoren und GLA-Deskriptoren kann eine der im letzten Abschnitt besprochenen Äquivalenzbeziehungen herrschen. Auch bei den Nicht-Deskriptoren gibt es eine Aufteilung in UOK-Nicht-Deskriptoren und GLA-Nicht-Deskriptoren. Die beiden Thesauri UOK und GLA sind nun Instanzen der Klasse “Thesaurus”. Sie haben Beziehungen zu ihren jeweiligen Deskriptoren und Nicht-Deskriptoren.

18

Abbildung 10. Mehrere Thesauri als Ontologie Wenn man die Thesauri als Ontologie dermaßen modelliert, dass jeder Deskriptor eine Klasse darstellt, dann kann man auch hier zwei Thesauri in eine Ontologie packen. Dies geschieht, indem man zu den jeweiligen Top-Deskriptoren (die Wurzeln der Deskriptor-Hierarchie) ein übergeordnetes Element draufpackt. Man muss dann allerdings dafür sorgen, dass die Inter-Thesaurus-Relationen (die im letzten Abschnitt besprochenen Äquivalenzen) nur zwischen den Deskriptoren verschiedener Thesauri, und die Intra-Thesaurus-Relationen (BT, NT, RT, USE, UF) nur zwischen Deskriptoren desselben Thesaurus gebildet werden. 4 Marktanalyse einiger existierender externer Technologien In diesem Kapitel sollen nun einige bereits existierende Produkte vorgestellt und die bisher erarbeiteten Lösungsansätze anhand dieser evaluiert werden. 4.1 Arten von Systemen Die betrachteten Technologien und Produkte lassen sich grob in zwei Kategorien einteilen: • Modulare Lösungen können zur Bewältigungen von einzelnen Teilproblemen herangezogen werden. Der Vorteil ist, dass man vorhandene Lösungen für das Gesamtproblem nach dem Baukastenprinzip benutzen kann, man also einen gewissen Grad an Flexibilität bekommt. Der Nachteil ist, dass ein höherer Intergrations- und Implementierungsaufwand beim Einsatz solcher Produkte nötig ist. Es werden beispielsweise Systeme vorgestellt, die zum Anlegen und Verwalten eines Thesaurus fähig sind, aber keine Funktionalität zum Indexieren und Retrieval bereitstellen.

19
• Stand-alone Lösungen können zur Lösung des Gesamtproblems herangezogen werden. Der Vorteil ist, dass man meist nur noch einen geringen Integrations- und Implementierungsaufwand hat (was u.U. die höheren Kosten solcher Systeme kompensieren kann) und das Zusammenspiel der einzelnen Komponenten in der Regel reibungslos verläuft. So bieten die betrachteten Stand-alone Produkte neben der Möglichkeit, Thesauri anzulegen, auch entsprechende Indexierungs- und Retrievalfunktionalität. Der Nachteil ist, dass man weniger Flexibilität in den präsentierten Lösungen hat und evtl. mehr Funktionalität eingekauft wird, als man eigentlich benötigt. 4.2 Beschreibung der Systeme Es wurden folgende modulare Lösungen betrachtet (in keiner bestimmten Reihenfolge aufgeführt): • IC Index 5.0, AGI Information Management Consultants • MultiTes, Multisystems • SIS Thesaurus Management System, ICS-FORTH • Synaptica, Synapse • Oracle Text, Oracle • Protégé 2000, Stanford University Folgende Stand-alone Lösungen wurden betrachtet: • Retrievalware, Convera • K-Infinity, Intelligent Views Bei den betrachteten Stand-alone Lösungen handelt es sich um Knowledge-Management-Produkte, die inzwischen bei mehreren Kunden im Einsatz sind. Die Produkte sollen nun kurz vorgestellt werden. Zu den gegebenen Preisinformationen ist anzumerken, dass diese meist verhandelbar sind; bei einigen besteht z.B. die Möglichkeit, für den nicht-kommerziellen Einsatz Sonderkonditionen zu bekommen. Es handelt sich um grobe Preisangaben, die auf den gemachten Angaben zur Problemstellung beruhen. Detailliertere Preisauskünfte müssen dementsprechend gesondert bei den Ansprechpartnern angefragt werden. Alle gemachten Angaben beruhen zum großen Teil auf den Angaben der Hersteller, nachdem diesen die Problematik so weit wie möglich geschildert wurden. Sie sind daher ohne Gewähr. Zur besseren Entscheidungsfindung ist es ratsam, mit den Herstellern selbst in Kontakt zu treten; zumeist ist es möglich, dass eine Teststellung erstellt wird, mittels der das BGLA dann die Tauglichkeit des Systems für die Problemstellung besser abschätzen kann. 4.2.1 IC Index 5.0 IC Index ist ein Modul, das zum “Information Center”-Paket der AGI Management Consultants gehört. Es wird allerdings auch als fertiges Produkt verkauft. IC Index ist ein Thesaurus-Management-System, das eine Neuentwicklung einer bewährten Lösung (INDEX aus der MS-DOS-Ära) ist. IC Index kann polyhierarchische,

20
polydimensionale Thesauri verwalten. Zu jedem Begriff kann eine Erläuterung gespeichert werden. Es ist möglich, den Benutzer neue Vorschläge machen zu lassen. Dazu existiert die Möglichkeit, jedes neue, vorgeschlagene Wort über das System zu diskutieren, um somit kollaboratives Arbeiten zu ermöglichen. IC Index basiert auf Lotus Notes und Lotus Domino. Der Thesaurus ist entweder über ein Web-Interface oder über einen Notes-Client (Notes Datenbank) vom Anwender zugreifbar. Jeder Thesaurus-Autor benötigt einen Lotus Notes-Client. Um gleichzeitig an der Terminologie zu arbeiten, ist der Lotus Domino-Server 5.0 notwendig, welcher für unterschiedliche Windows- und Unix-Betriebssysteme verfügbar ist. IC Index 5.0 bietet standardmäßig 26 Relationstypen. Es ist allerdings möglich, bei Bedarf neue zu definieren. Eine Attributisierung der Instanzen ist möglich. Dabei ist es möglich, eine Termgewichtung auf verschiedene Attribute zu erstellen, welche beim Retrieval ausgenutzt werden kann. Abbildung 11 zeigt ein Screenshot der Demo-Version von IC Index, in der Worte mit ihren Relationen angezeigt werden. Abb. 12 zeigt, wie ein Begriff angezeigt werden kann. Beide letztgenannten Abbildungen stammen aus der Demo-Version von IC Index.
Abbildung 11. IC Index - Worte mit Relationen IC Index besitzt eine CORBA-API. Darüber ist ein direkter Zugriff auf den Domino-Server möglich. Auf diese Weise kann der Thesaurus unter Domino direkt in die Erfassungsmaske eines Fremdsystems, z.B. einer Anwendung unter Oracle, implementiert werden. Alternativ kann ODBC zum Zugriff auf den Server genutzt werden.

21
Bestandteil von Lotus Notes Clients und dem Server ist die GTR-Suchmaschine (Global Text Retrieval Engine), die problemlos mit IC Index verknüpft werden kann. Diese Suchmaschine unterstützt Retrieval-Merkmale wie z.B. Relevance Feedback, bei dem mit Hilfe des Benutzers und den im ersten Anlauf gefunden Dokumente versucht wird, weitere relevante Dokumente (oder Objekte) zu finden. Über GTR ist jedes Feld in der Datenbank recherchierbar. AGI würde den Import der Daten selbst übernehmen. Eine Zusammenarbeit mit einer dritten Firma ist grundsätzlich möglich, wurde aber eher als “Verkomplizierung” gesehen. Folgende Kosten wurden von AGI grob geschätzt: Unternehmenslizenz IC Index 5.0 16.500 DM Aufwand Import der Schlüssellisten und Export Richtung Oracle 30.000 DM Lotus Domino Server (abhängig von der An- zahl Prozessoren ca. 10.000 DM Lotus Notes Client (pro Arbeitsplatz) ca. 200 DM
Beim Notes-Server und -Client könnte es für Ministerien Sonderkonditionen geben. Kontakt: AGI - Information Management Consultants Dipl.-Inf.wiss. Manfred Hauer M.A. Mandelring 238b 67433 Neustadt an der Weinstraße 06321 / 96 35 - 0 E-Mail: Manfred.Hauer@agi-imc.de http://www.agi-imc.de/ Eine Demoversion von IC Index 5.0 befindet sich auf der Homepage.

22
Abbildung 12. IC Index - Anzeige eines Wortes
4.2.2 MultiTes Bei MultiTes der Firma Multisystems, Miami handelt es sich um ein reines Thesaurus-Management-Tool. Mit Hilfe von MultiTes kann ein Thesaurus angelegt und verwaltet, und diverse Reports generiert werden. Es ist überdies sehr einfach möglich, eine HTML-Version des Thesaurus zu erstellen. Abbildung 13 zeigt das User Interface von MultiTes. Im oberen Berich befindet sich eine Auflistung aller im Thesaurus befindlichen Terme. Die vier kleineren Fenster beinhalten verschiedene Reports zu einem bestimmten Term. Es ist möglich, diese Reports z.B. in eine ASCII-Datei zu generieren. In MultiTes ist es möglich, eigene Attribute und Relationstypen zu definieren und diese dann mit Thesauruselementen zu verknüpfen. Die selbstdefinierten Relationstypen lassen sich in die in Abschnitt 2.1.1 definierten Klassen (äquivalent, hierarchisch, assoziativ) unterteilen. Es existiert ein Konsistenzcheck, mit dem bei hierarchischen Relationstypen Zyklen verhindert werden.

23
Abbildung 13. MultiTes In Abb. 14 sieht man die HTML-Version eines mit MultiTes verwalteten Thesaurus. Es ist ohne Weiteres möglich, CGI-fähige Suchmaschinen oder generell Informationssysteme, die über eine URL zugreifbar sind und darüber die Eingabe von Termen ermöglichen, aus der HTML-Version heraus anzusteuern. So ist es in dem Beispiel möglich, Yahoo! nach dem gerade angezeigten Term suchen zu lassen. Somit ist es möglich, externe Tools aus der HTML-Seite heraus zumindest eingeschränkt mit Eingaben zu versehen. Neben der Möglichkeit, Reports zu generieren, besteht zusätzlich noch die Möglichkeit, die Daten im Thesaurus zu exportieren. Die exportierten Daten können in einer externen Applikation eingelesen und verwendet werden. Eine API, durch die man auf das System und die Daten zugreifen könnte, existiert nicht. Folgende Preisinformationen wurden übermittelt: Single-user Lizenz : $295.00 10-user LAN Lizenz : $1,990.00 Site Lizenz : $3,500.00 Shipping und Handling: USA : $17.00 Canada : $35.00 Übersee : $65.00 E-mail : $0.00 (no charge)
Es existiert eine Mailingliste, auf der MultiTes-Benutzer sich einander beraten oder Rat suchen können.

24
Abbildung 14. MultiTes - Thesaurus als HTML Kontakt: Multisystems P.O. Box 833205 Miami, FL 33283 Toll Free in the U.S. and Canada: 1-888-45-Multi (1-888-456-8584) From other countries: (786) 242-1313 Fax: (786) 242-5534 E-mail: MultiTes@aol.com http://www.multites.com
Über die Homepage kann eine kostenlose Evaluierungsversion beantragt werden.
4.2.3 SIS-TMS SIS-TMS wurde vom Institute of Computer Science, FORTH, Heraklion, entwickelt. Das System wurde von Anfang an darauf konzipiert, die Einbindung externer Thesauri zu unterstützen. Semantische Relationstypen innerhalb und zwischen verschiedenen Thesauri werden unterstützt; SIS-TMS beruht dabei auf den theoretischen Überlegungen in [Doerr 2001], die in Abschnitt 3.2.3 besprochen wurden. Bei hierarchischen Relationen können Konistenzchecks vorgenommen werden. Es ist möglich, das System bei Bedarf um neue Relationen und dazugehörigen Konsistenzchecks zu erweitern. SIS-TMS bietet ein User Interface, mit dessen Hilfe verschiedene Thesauri verwaltet werden können. Zusätzlich kann mit Hilfe des User Interface GAIN (Graphical Analysis Interface) innerhalb der Thesauri navigiert werden. Abb. 14 zeigt, wie mit GAIN ein Term und dessen Relationen angezeigt werden. In der Abbildung sieht man auch, wie per Menü verschiedene Relationenstypen graphisch angezeigt werden können, darunter auch Relationen zwischen den verschiedenen Thesauri.

25
Abbildung 15. SIS-TMS - Narrower term tree in GAIN Neben GAIN existiert noch die so genannte Entry Form (EF), ein Tool zum interaktiven Verwalten der Thesauri. Es ist mittels EF möglich, den einzelnen Elementen zusätzliche Attribute zuzuweisen, neue Hierarchien anzulegen, Deskriptoren zu verknüpfen usw. Sollten Relationen von der EF nicht unterstützt werden, so bietet der Hersteller an, im Einzelfall Abhilfe zu schaffen. Da das drunterliegende Basissystem auf einem genuinen semantischen Netz beruht, ist dies ohne größeren Aufwand möglich. Eine Java-API ist vorhanden, ebenso wie eine C- und C++-API. Das System läuft als Client-Server mit Socket-Schnittstelle unter Windows. Kundenspezifische Anpassungen, zum Beispiel am User Interface, werden gerne an dritte Partner abgegeben. FORTH sieht sich eher als Technologielieferant. Folgende Preisvorstellung wurde genannt: Einmalige Lizenz zur unbegrenzten Nutzung von SIS-TMS an einem Ort, und Entwicklungslizenz fuer Integrationsarbeiten durch eine Drittfirma: 8000 Euro. Kundenspezifische Konfiguration Server 0.25 MM (1 Woche) Anpassung der Dateneingabe 0.25 MM (1 Woche) Laden von 2 Thesauren 0.75 MM (3 Wochen) Training am API u. System, incl Vorbereitung 0.25 MM (1 Woche) Berechnungsbasis: 50 Euro/Stunde, 140 Stunden pro Monat. Wartungsvertrag: 12% des Lizenzpreises

26
Entwicklern wird ein dreitägiges Training auf Kreta angeboten. Darüber hinaus gibt es Unterstützung per E-Mail und Telefon zu Geschäftszeiten. Für den Nicht-kommerziellen Einsatz kann ein Rabatt eingeräumt werden. FORTH ist als Forschungseinrichtung an jeder neuartigen Nutzung des Systems interessiert, sowie an enger Zusammenarbeit mit Firmen, die Userinterfaceanpassungen vornehmen; dafür können u.U. Komponenten zur Verfügung gestellt werden. FORTH besitzt Erfahrung darin, einen Thesaurus aus Access-Daten heraus zu importieren. Kontakt: Dr. Martin Doerr, Project Leader SIS Centre for Cultural Informatics Information Systems Laboratory Institute of Computer Science Foundation for Research and Technology - Hellas (FORTH) Vassilika Vouton P.O.Box1385 GR71110 Heraklion,Crete Greece Tel: +30(81)391625 Fax: +30(81)391609 E-Mail: martin@ics.forth.gr http://www.ics.forth.gr/proj/isst/Systems/sis-tms.html Auf der Homepage ist umfangreiche Dokumentation, auch zur API, vorhanden, die einen tieferen Einblick in das System ermöglicht. 4.2.4 Synaptica Synaptica wurde von der Firma Synapse in Denver, Colorado entwickelt. Es verfügt über ein webbasiertes User Interface, mit dem ein Thesaurus angelegt, verwaltet und mit dem im Thesaurus gesucht werden kann. Thesauruselemente sind Instanzen verschiedener Objektklassen. Auf dieser Grundlage kann auch das gleichzeitige Verwalten mehrere Thesauri, dessen Elemente verschiedenen Objektklassen zugehörig sind, geschehen. Es kann definiert werden, welche Relationen zwischen Objektklassen existieren, und welche innerhalb einer Objektklasse. Hierarchische, assoziative und äquivalenz Relationen können definiert werden; entsprechende Konsistenzchecks für diese Relationstypen existieren. Abbildung 16 zeigt die Suchmaske von Synaptica, mit deren Hilfe nach Termen gesucht werden kann. Wie diese und die dazugehörigen Attribute angezeigt werden, zeigt Abbildung 17.

27
Abbildung 16. Synaptica - Suchmaske
Abbildung 17. Synaptica - Item Details Synaptica basiert auf der COM- und Active Server Pages- (ASP) Technologie. Benötigt werden Windows NT/2000 Server, Internet Informations Server (IIS), Microsoft SQL Server 2000 oder Oracle DBMS auf Unix oder NT. Such- und Display-Komponenten sind als COM-DLL Objekte in Visual Basic implementiert. Diese können von einer externen Applikation benutzt werden.

28
Preisinformation: Mit 150 Benutzern und API-Zugriff ist man bei Synapse in der “Enterprise”-Klasse. Software Lizenz, inklusive technischem Support: $45.000 (einmalig) $25.000 (pro Jahr) Zusätzliche Kosten (Installation, Training, Import/Export, Assistenz für Programmierer): $15.000 - $20.000 (grob geschätzt) Kontakt: Dave Clarke Tel.: USA (303) 796 9220 E-Mail: dclarke@synaptica.com http://www.synaptica.com/ 4.2.5 Oracle Text Bei Oracle Text handelt es sich um eine integrierte Volltext-Retrieval Technologie, die ein rudimentäres Thesaurusmanagement enthält und Teil der Oracle 9i Enterprise- und Standard-Edition ist. Ein Thesaurus kann mit Hilfe des Oracle Enterprise Managers verwaltet werden. Oracle Text stellt Mechanismen zur Verfügung, dass bei SELECT-Statements z.B. die broader terms eines Terms mit einbezogen werden können. Es ist noch zu evaluieren, inwiefern Oracle Text für die Problemstellung interessant sein kann. Aus diesem Grunde wird Oracle Text zunächst einmal nicht weiter berücksichtigt. 4.2.6 Protégé 2000 Bei Protégé 2000 handelt es sich um kein eigentliches Thesaurus-Management-System, sondern um ein Tool zum Anlegen und Verwalten von Ontologien. Da ein Thesaurus sich als Ontologie modellieren lassen kann, ist es dennoch interessant, Protégé 2000 zu betrachten. Das Besondere an Protégé 2000 ist, dass es ein sehr einfach zu bedienendes Interface zum Verwalten einer Ontologie besitzt. Die Ontologie selbst und die dazugehörigen Daten können in einem eigenen Format, als RDF (Resource Description Framework) oder per JDBC in einer Oracle-Datenbank gespeichert werden; letzteres ist bei höherem Datenaufkommen die empfohlene Herangehensweise. In Protégé sind die Ontologielemente Klassen. Zu jeder Klasse lassen sich Attribute und Relationen beliebig hinzufügen, die mittels Vererbung an die Subklassen weitergegeben werden. Über die Java-API besteht Zugriff zu Klassen, Instanzen, Attributen und Relationen.

29
Protégé 2000 ist frei verfübar unter der Mozilla Public License2, die einen kommerziellen Einsatz ermöglicht.
Abbildung 18. Protégé 2000 Abbildung 18 zeigt das User Interface von Protégé 2000. Links sieht man die Klassen der Ontologie, in der Mitte die Instanzen der aktuellen Klasse, und rechts die kompletten Daten einer aktuellen Instanz. Support wird direkt nicht angeboten, aber es existiert eine Mailing-Liste, in denen Probleme mit und um Protégé diskutiert werden. Ferner existiert das Protégé Affiliates Program (Möglichkeiten zur Zusammenarbeit mit den Protégé-Entwicklern, siehe http://protege.stanford.edu/affiliatesprogram/index.html). Weitere Informationen gibt es auf der offiziellen Homepage von Protégé: http://smi-web.stanford.edu/projects/protege/ 4.2.7 Retrievalware Retrievalware von der Firma Convera ist ein vollwertiges Knowledge-Management-System, mit dem nicht nur mehrere Thesauri verwaltet, sondern diese auch zum Retrieval auf eine Datenbasis hinzugezogen werden können. Die Funktionalität von Retrievalware geht somit weit über das Anlegen und Verwalten eines Thesaurus hinaus. Mit so genannten Synchronizern können verschiedene Datenbasen, wie eine Oracle Datenbank, Exchange Server oder auch Dokumente in den verschiedensten Formaten, indexiert werden und es kann auf ihnen recherchiert werden. Die Suche auf der Datenbasis kann dabei fehlertolerant geschehen, d.h. z.B. Tippfehler können korrigiert werden. Dabei können Tippfehler auch abgefangen werden, bevor ein Suchbegriff an den Thesaurus übergeben wird. 2 http://www.mozilla.org/MPL

30
Retrievalware bietet eine Java-API, mit deren Hilfe User Interfaces erstellt werden können und auf alle Komponenten von Retrievalware zugegriffen werden kann. Die Thesauri selbst werden in einem eigenen Format im Filesystem verwaltet. Es existiert ein User Interface, mit dem Thesauri verwaltet werden können (Abb. 19). Relationen können frei definiert werden; es ist möglich, Objekten Attribute zuzuweisen und auch Relationen zwischen Thesauri festzulegen. Konsistenzchecks sind dabei extern zu implementieren. Das in Abb. 19 ersichtliche Interface ist allerdings nur zur rudimentären Pflege geeignet. Es können hier z.B. keine Objekttypen definiert werden. Die Philosophie hinter Retrievalware ist, dass ein oder mehrere Thesauri als Textdatei im Filesystem vorliegen, die dann kompiliert wird. Wie diese Textdatei erstellt wird, ist völlig frei; es können dazu selbst implementierte oder bereits bestehende Thesaurus-Management-Systeme herangezogen werden, deren exportierte Daten dann in das für Retrievalware nötige Format umgewandelt werden müssen. Retievalware selbst ist deshalb weniger ein Produkt zur Thesaurusverwaltung, sondern zur Anwendung eines oder mehrerer Thesauri bei der Recherche.
Abbildung 19. Retrievalware - Semantic Network Editor Der Vorteil von Retrievalware ist, wie bereits erwähnt, dass es sich um ein integriertes System handelt, mit dem man unter Berücksichtigung diverser Retrievaltechniken und vorhandener Thesauri Recherchen auf die Datenbasis, die durchaus sehr heterogen sein darf, durchführen kann. Durch den Zukauf verschiedener Synchronizer kann die Datenbasis z.B. um multimediale Objekte erweitert werden. Zukünftige Technologien können theoretisch durch neu erstellte Synchronizer unterstützt und integriert werden. Abbildung 20 gibt einen Überblick über Retrievalware. Man sieht hier, wie auf der unteren Ebene die Datenbasis durchaus heterogen sein kann. Eine Suchanfrage auf die Datenbasis kann nun mit Hilfe der Thesauri durchgeführt werden. Mit Hilfe der API können Suchergebnisse in einem Portal aufbereitet werden.

31
Abbildung 20. Retrievalware - Überblick Folgendes unverbindliche Angebot wurde von der Firma Convera gemacht: Serverlizenz zum Betreiben von RetrievalWare 6.9 (Deutsch) auf einem physikalischen Rechnern und einem Betriebssystem (Unix, Win NT, 2000) für eine Intranet- Internetanwendung.
Komponenten:
• Search Server • Indexing Server • Command Line Interface • System Administration Tools • Intranet Search Interface • Document filters • Web Server • Security Server • RDBMS Bridge Oracle Synchronizer 60.000 DM Wartung ist erforderlich ab Datum der Lizenzierung. Die jährlichen Wartungsgebühren betragen 15% des entsprechenden Produktlistenpreises. Berechnungsgrundlage sind die in 2.1 (Lizenzen RetrievalWare 6.9) ausgezeichneten Kosten.
Vom Tage der Lizensierung ist CONVERA Software durch eine 90 Tage Garantie abgedeckt. Diese gilt nur für reproduzierbare Fehler.
Die Leistungen des Wartungsvertrages beinhalten:
• Hotline Telefonsupport während der normalen Bürozeiten (9:00 – 18:00)
• Regelmäßige Maintenance Releases
• Zugriff auf die FTP Site 9.000 DM

32
Alle Preise verstehen sich zzgl. der gesetzlichen Mehrwertsteuer. Bei Dienstleistungen, die vor Ort erbracht werden, sind Spesen, Übernachtung, Reisekosten nicht im Preis enthalten und werden gesondert in Rechnung gestellt. Basis hierfür sind die in Ihren Angebotsbedingungen (Convera Honorarpreisliste 2001) festgelegten Sätze.
Kontakt: Dipl.-Wirt.-Ing. (FH) Erwin Weiler Account Manager Höglwörther Str. 1 81739 München Tel.: (089) 710 502 0 und (0171) 4 58 32 47 (mobil) Fax: (089) 710 502 77 E-Mail: eweiler@convera.com http://www.convera.com/ 4.2.8 K-Infinity Bei K-Infinity von der Firma Intelligent Views in Darmstadt handelt es sich ebenfalls um ein vollwertiges Knowledge-Management-Tool, mit dem die Thesaurus-unterstützte Suche auf eine Datenbasis realisiert werden kann. K-Infinity besteht aus mehreren Modulen, die der redaktionellen Aufbereitung eines Wissensnetzes (in diesem Fall einer oder mehrerer Thesauri) und der Wissensnutzung dienen. Mittels des Schema-Editors können Objekt- und Beziehungstypen bzw. deren operationale Semantik definiert werden. Mit Hilfe des Knowledge-Builders können nun neue Wissensobjekte angelegt, umbenannt, modifiziert, als auch Beziehungen zwischen Objekten angelegt werden. Bestandteil des Knowledge Editors ist der Graph-Editor, der es erlaubt, die Wissensobjekte über eine graphische Oberfläche zu pflegen, mit dem eine Gesamtsicht auf das Beziehungsgepflecht möglich ist. Ein weiterer Bestandteil des Knowledge Editors ist der Konzept-Editor, der eine Ergänzung des Graph-Editors darstellt. Mittels des Konzept-Editors können Beziehungen und Attribute auf komfortable Weise im Detail erfasst und modifiziert werden. Die verteilte Pflege des Wissensnetzes ist mit dem Knowledge-Accelerator möglich; mit diesem browserbasierten Werkzeug können verschiedene Nutzer an unterschiedlichen Standorten die Pflege des Wissensnetzes übernehmen. Um das im Wissensnetz gespeicherte Wissen abrufen zu können, existieren mehrere Tools. Mit Hilfe des Semantic-Finder kann eine Suche auf das Wissensnetz formuliert werden. Die Suche kann über verschiedene Kategorien und Relationen stattfinden; beispielsweise ist es möglich, in einem Literatur-Wissensnetz nach einem Werk einer bestimmten Person zu suchen, in der eine andere Person als Figur vorkommt. In Abbildung 21 sieht man den Net-Navigator, mit dessen Hilfe es möglich ist, auf den Wissensobjekten zu navigieren. Die graphische Ansicht des Wissensnetzes, die dem Graph-Editor und dem Net-Navigator zu Grunde liegt, ist eine der Stärken von K-Infinity. In Abb. 22 sieht man beispielhaft, wie ein Wissensnetz repräsentiert werden kann.

33
Abbildung 21. K-Infinity - Net-Navigator Für die kundenspezifische Anpassung des Designs existiert eine Layout-Engine, mit deren Hilfe Webseiten und Webportale erstellt werden können. In Abbildung 23 sieht man beispielhaft, wie ein Webportal aussehen kann. Hier wird auch die Suche in einem Wissensnetz und die graphische Aufarbeitung der Ergebnisse dargestellt. Mittels des Wissensnetzes kann nun auf der eigentlichen Datenbasis, die aus Dokumenten, Datenbankobjekten etc. bestehen kann, gesucht werden. Das Wissensnetz wird dabei insofern ausgenutzt, dass nicht nur ein Begriff, sondern semantisch in Beziehung stehende Objekte (z.B. narrower terms) zur Suche herangezogen werden können. Zusätzlich zu dieser semantischen Suche ist auch noch eine Volltextsuche möglich. K-Infinity bietet direkt keine API, es existiert aber eine generische XML-Schnittstelle, die Such- und Navigationsrequests und Schreiboperationen bereitstellt. In K-Infinity können mehre Thesauri verwaltet werden, die mittels eines Mapping-Tools miteinander verknüpft werden können. Zurzeit wird dabei nur ein Relationstyp unterstützt, was laut Auskunft von Intelligent Views aber erweiterbar ist. Für alle Relationstypen sind Konsistenzkontrollen möglich (z.B. Test auf Zyklen, Duplikate). Das Wissensnetz wird in einer eigenen Datenbank gehalten, eine Integration in Oracle ist möglich. K-Infinity befindet sich preislich in Dimensionen von 250.000 DM aufwärts. Es wurde aber von Intelligent Views betont, dass für den nicht-kommerziellen Einsatz

34
und im Rahmen einer Zusammenarbeit durchaus große Rabatte eingeräumt werden können. Es wird gebeten, bei Interesse Gespräche zu führen, es herrscht bei Intelligent Views eine große Verhandlungsbereitschaft diesbezüglich.
Abbildung 22. K-Infinity - Darstellung eines Wissensnetzes Kontakt: Intelligent Views GmbH Klaus Reichenberger Julius-Reiber-Str. 17 64293 Darmstadt Tel.: (06151) 5006-118 Fax: (06151) 5006-138 E-Mail: k.reichenberger@i-views.de http://www.i-views.de/ Auf der Homepage befinden sich einige Demonstrationen des Systems.

35
Abbildung 23. K-Infinity - Internetportal, Suche im Wissensnetz 5 Evaluierung der Lösungsansätze bzgl. externer Technologien 5.1 Überführung des Kerns in eine Thesaurus-basierte Form Zunächst sollen einige Evaluierungskriterien aufgestellt werden, um diese danach an den einzelnen Produkten anzuwenden. 5.1.1 Evaluierungskriterien Um den Kern in eine Thesaurus-basierte Form zu überführen und diesen Thesaurus geeignet zu verwalten, sind einige Kriterien nötig, die ein Thesaurus-Management-System (TMS) möglichst erfüllen sollte. Diese wären: 1. Es sollte möglich sein, dass jedem Thesauruselement benutzerdefinierte Attribute und Relationen zugewiesen werden können. Es wäre gut, wenn man dabei pro Elementtyp verschiedene Attribute und Relationen zuweisen könnte (z.B. stratigraphische Einheiten haben die jünger/älter-Relationen und einige für sie spezifische Attribute, die in anderen Elementtypen nicht auftauchen sollten). Alternativ dazu können diese Attribute in der Datenbank gehalten werden; es sollte dann aber zumindest möglich sein, über ein entsprechendes Attribut eine Referenz auf den jeweiligen Datenbankeintrag herzustellen. Es sollte möglich sein, polyhierarchische Beziehungen zu verwalten. 2. Im TMS sollten Konsistenzchecks möglich sein, z.B. um zu prüfen, dass keine BT-Relation einen Zyklus bildet. Gut wäre es, wenn diese Konsistenzchecks auch

36
auf benutzerdefinierte Relationen anwendbar sind (z.B. Test auf Zyklen in der jünger-Relation). 3. Es sollte ein User Interface existieren, welches die Wartung des Thesaurus durch einen oder mehrere Administratoren unterstützt. Es sollte möglich sein, dass an der Terminologie gearbeitet werden kann, ohne dass der produktive Betrieb dabei gestört wird. Ferner soll es möglich sein, dass mehrere Autoren gleichzeitig die Terminologie bearbeiten. 4. Es sollte eine API existieren, mit der auf den Thesaurus zugegriffen werden kann. Idealerweise sollte es sich dabei um eine Java-API handeln. Wenn möglich, sollte Oracle als Datenbank zur Speicherung der Terme unterstützt werden. Mit Hilfe der API sollte es ggf. möglich sein, die unter Punkt 2 erläuterten Konsistenzchecks extern zu implementieren. Ferner sollte beim Fehlen eines User Interface dieses mit Hilfe der API erstellt werden können. 5.1.2 Evaluierung von Lösung 1.1 Lösung 1.1 beschreibt, wie der Kern in eine Thesaurus-basierte Form überführt werden kann. Für die einzelnen Produkte soll nun gezeigt werden, inwiefern sie die Problemstellung lösen können. IC Index 1. In IC Index können neben den bereits definierten Relationstypen neue hinzugefügt werden. Somit ist es möglich, z.B. für stratigraphische Einheiten die jünger/älter-Relation zu modellieren. Polyhierarchie ist mit IC Index möglich. Ferner ist es möglich, jedem Objekt zusätzliche benutzerdefinierte Attribute zuzuweisen. 2. IC Index bietet standardmäßig keine Konsistenzchecks an; diese müssen über die API extern implementiert werden. 3. Über ein Web Interface oder den Lotus Notes-Client ist es möglich, den Thesaurus zu pflegen. Wird der Lotus Domino-Server eingesetzt, kann der Thesaurus dezentral gepflegt werden, auch von verschiedenen Standorten aus. Auf diese Weise pflegen bereits einige Kunden von AGI ihren Thesaurus. Interessant an IC Index ist auch die Möglichkeit, neue Terme vorzuschlagen und diese kollaborativ zu diskutieren. 4. Über die CORBA-API ist ein direkter Zugriff auf den Domino-Server möglich; auf diese Weise kann der Thesaurus direkt in fremde Systeme integriert werden. Ferner besteht noch eine ODBC-Schnittstelle. MultiTes 1. Attribute und Relationen können definiert werden. Relationen können dabei als hierarchisch, assoziativ oder äquivalenz klassifiziert werden. Es ist allerdings nicht möglich, Objekttypen oder Templates zu definieren, z.B. für stratigraphische Einheiten. 2. Für hierarchische Relationen existiert ein Konsistenzcheck, der den Test auf Zyklen realisiert. Zum Beispiel könnte eine jünger/älter-Relation auf diese Art und Weise definiert und deren Konsistenz überprüft werden.

37
3. Über das MultiTes User Interface kann der Thesaurus komplett verwaltet werden. Es können dabei diverse Reports erzeugt werden. Der verteilte Zugriff ist nicht vorgesehen. Terme können explizit freigegeben werden. 4. Eine API existiert nicht, es ist aber möglich, Daten zu ex- und importieren. Eventuell ist auf diese Weise z.B. ein Zusammenspiel mit Retrievalware von Convera möglich. SIS-TMS 1. Semantische Relationstypen innerhalb eines Thesaurus können definiert werden. Laut Auskunft des FORTH stellen die im BGLA-Kontext identifizierten Relationstypen keine Probleme dar. Den Thesauruselementen können individuell Attribute zugewiesen werden. Attribute und Relationen können vererbt und spezialisiert werden. Polyhierarchische Beziehungen können verwaltet werden. 2. Bei hierarchischen Relationen können Konsistenzchecks vorgenommen werden. Es ist prinzipiell möglich, zu neu definierten Relationen ebenfalls Konsistenzchecks einzuführen. 3. Über das User Interface kann ein Thesaurus vollständig verwaltet werden. Mittels GAIN kann innerhalb des Thesaurus navigiert werden, es können Begriffe und deren Relationen graphisch aufbereitet werden. 4. Es existiert eine C++- und Java-API. Mit deren Hilfe kann auf den Thesaurus zugegriffen werden, und es kann auf diese Art und Weise auch ein den Kundenwünschen entsprechendes User Interface implementiert werden. Synaptica 1. Es können verschiedene Klassen definiert werden, die verschiedene Attribute und Relationstypen besitzen. So kann z.B. die Klasse “Stratigraphische Einheiten” definiert werden, die dann die jünger/älter-Relation enthält. Es kann definiert werden, dass z.B. die BT/NT-Relation von einer stratigraphischen Einheit nur zu einer anderen stratigraphischen Einheit führt. Polyhierarchische Beziehungen können verwaltet werden. 2. Sowohl auf den bereits vorhandenen Relationen, als auch auf den neu erstellten sind Konsistenzchecks definierbar, die nach der Art der Relation (hierarchisch, assoziativ, äquivalenz) entsprechend angepaßt sind. 3. Synaptica stellt ein Web-Frontend zur Verfügung, das individuell angepaßt werden kann. Das Suchen innerhalb des Thesaurus, das Anzeigen von Suchergebnissen und einzelnen Elementen ist darüber ebenso möglich wie die Pflege des Thesaurus. Es ist möglich, dass mehrere Personen gleichzeitig den Thesaurus pflegen. 4. Eine COM-DLL-API ist vorhanden. Such- und Display-Komponenten können damit in einer externen Applikation benutzt werden. Protégé 2000 Da es sich hierbei um ein Tool zum Verwalten von Ontologien handelt, wird Protégé 2000 im Zusammenhang mit Lösung 1.2 betrachtet.

38
Retrievalware 1. Es ist möglich, Relationen und Attribute zu definieren und diese mit den Thesauruselementen zu verbinden. Templates und Vererbungsmechanismen können ohne Weiteres nicht angelegt werden, da der Thesaurus in einer Textdatei gehalten wird, die objektorientierte oder ähnliche Strukturen nicht anbietet. 2. Konsistenzchecks müssen extern implementiert werden. 3. Da der Thesaurus im Filesystem gehalten wird, kann man ein Duplikat anlegen, welches dann verändert werden kann. Verteilter Zugriff müßte gesondert implementiert werden. 4. Retrievalware bietet eine Java-API. Mit dieser kann das User Interface und Konsistenzchecks implementiert werden. Ferner kann ein angepaßtes Web-Frontend entwickelt werden. Da Retrievalware von sich aus Mechanismen bietet, auf dem Datenbestand zu recherchieren, bei denen ein Thesaurus ausgenutzt werden kann, ist zumindest für diesen Zweck ein Zugriff auf Suchergebnisse nicht nötig. Anfrageerweiterungen können ohne Weiteres automatisch vorgenommen werden. Programmieraufwand würde also für das User Interface und die Verwaltung des Thesaurus anfallen. K-Infinity 1. In K-Infinity können Objektklassen definiert werden, die spezifische Attribute und Relationen beinhalten, welche über Vererbungsmechanismen an Unterklassen weitergegeben werden können. Auf diese Weise ist es z.B. möglich, eine Klasse “Stratigraphische Einheiten” zu definieren, die die jünger/älter-Relation enthält. 2. Konsistenzchecks auf alle Relationentypen sind möglich. 3. Es existiert ein ausgeprägtes User Interface, das sehr vielfältige Möglichkeiten enthält, den Thesaurus darzustellen, in ihm zu suchen und den Thesaurus zu verwalten. Verteilte Pflege des Thesaurus ist möglich. 4. Es existiert keine eigentliche API, aber über eine generische XML-Schnittstelle lassen sich Such- und Navigationsrequests sowie Schreiboperationen steuern. Es sei aber darauf hingewiesen, dass es innerhalb des Systems sehr viele Möglichkeiten gibt, auch ohne eine API z.B. das User Interface an die speziellen Kundenbedürfnisse anzupassen und die Recherche auf dem Datenbestand zu unterstützen. Größere Implementierungsarbeiten sind dazu nicht erforderlich, es handelt sich um ein autonomes System, bei dem nur einzelne Anpassungen nötig sind. 5.1.3 Evaluierung von Lösung 1.2 Da die Lösung 1.2 auf Ontologien ausgerichtet ist, soll hier nur das Ontologietool Protégé 2000 betrachtet werden. Protégé 2000 1. Protégé 2000 arbeitet objektorientiert, d.h. mit Klassen und Instanzen. Es ist daher ohne Probleme möglich, für eine Klasse Attribute und Relationstypen zu definieren, die an Unterklassen weitervererbt werden. Es kann also z.B. die Klasse “Stratigraphische Einheiten” definiert werden, die zusätzliche Attribute und jünger/älter-Relationen enthält. 2. Konsistenzchecks sind nicht enthalten, sie müssen extern implementiert werden.

39
3. Eine mit Protégé erstellte Ontologie kann mittels JDBC in einer Oracle-Datenbank gespeichert werden. Es sollte prinzipiell möglich sein, dass ein verteiltes Pflegen der Ontologie durch die in der Datenbank existenten Transaktionsmechanismen abgesichert ist. Protégé bietet ein User Interface an, welches die Pflege des Thesaurus und rudimentäre Suchfunktionen ermöglicht. Über so genannte Plugins kann das User Interface erweitert werden. 4. Es existiert eine umfangreiche Java-API, mit der auf Klassen, Relationen, Instanzen, Attribute etc. zugegriffen werden kann. Sie unterstützt die Herstellung eines eigenen Interfaces; auf Grund der Tatsache, dass es sich um Java handelt, sind potentiell auch Web-Interfaces damit möglich (die dann z.B. zur verteilten Pflege des Thesaurus dienen können). 5.2 Einbindung eines externen Thesaurus
5.2.1 Evaluierungskriterien Für die Einbindung eines externen Thesaurus sollte ein TMS möglichst folgende Kriterien erfüllen (gilt nicht für Lösung 2.1): Es sollte möglich sein, zwei Thesauri getrennt zu führen und zwischen den Deskriptoren dieser Thesauri die in Abschnitt 3.2.3 definierten Äquivalenzbeziehungen definieren zu können. Alternativ sollte es möglich sein, die Thesauri in einen Thesaurus zu überführen, in dem ein gemeinsames, abstraktes Oberelement existiert. Die Attributisierung der Elemente sollte derart möglich sein, dass die einzelnen Terme eindeutig den jeweiligen Thesauri zugewiesen werden können; ferner müssen die Äquivalenzbeziehungen modellierbar sein. Abbildung 24 skizziert diese Vorgehensweise.
Abbildung 24. Verwaltung zweier Thesauri in einem gemeinsamenThesaurus
5.2.2 Evaluierung von Lösung 2.1 Da Lösung 2.1 ein einfaches String Matching auf die Geoobjekte beschreibt, ist an ein Thesaurus-Management-System keine besondere Anforderung zu stellen. Alle

40
vorgestellten Systeme können Lösung 2.1 verwirklichen, sofern der externe Thesaurus überhaupt gesondert mit einem TMS verwaltet werden muß. Nötigenfalls ist der externe Thesaurus gemeinsam mit dem internen Thesaurus zu verwalten, z.B. indem man ein gemeinsames abstraktes Oberelement definiert. 5.2.3 Evaluierung von Lösung 2.2 Die Produkte sollen nun anhand der in Abschnitt 5.2.1 vorgestellten Anforderungen betrachtet werden. IC Index Der Hersteller AGI hat laut eigenen Angaben langjährige Erfahrungen mit der Integration externer Thesauri. Externe Thesauri können importiert und unterscheidbar gemacht werden (z.B. über ein Quellenfeld). Da neue Relationstypen definiert werden können, können die in Abschnitt 3.2.3 besprochenen Äquivalenzen zwischen den Thesauri abgebildet werden. MultiTes MultiTes bietet standardmäßig keine Möglichkeit, externe Thesauri einzubinden. Es ist aber möglich, über ein gemeinsames Oberelement beide Thesauri als einen Thesaurus zu betrachten. Problematisch könnte dabei aber die Pflege des externen Thesaurus werden - was geschieht, wenn der externe Thesaurus Veränderungen unterworfen ist (diese Frage stellt sich generell bei allen betrachteten Systemen)? Diese müssen von den Administratoren manuell nachgepflegt werden. Da das Definieren von beliebigen Relationen möglich ist, können die in Abschnitt 3.2.3 besprochenen Äquivalenzen zwischen den Thesauri abgebildet werden. Man kann ein Attributfeld “Quelle” definieren, auf Grund dessen die Herkunft eines Terms entscheidbar ist. SIS-TMS In der Integration und dem Mapping externer Thesauri liegt die große Stärke von SIS-TMS. SIS-TMS baut auf den in Abschnitt 3.2.3 besprochenen Äquivalenzen zwischen den Thesauri auf, setzt die Theorie sozusagen in die Praxis um. Es besteht standardmäßig eine Unterstützung für die Inter-Thesaurus-Relationen. Im User Interface können mehrere Thesauri verwaltet und recherchiert werden. Dies macht SIS-TMS zu einem besonders interessanten Produkt, wenn es um die Integration externer Thesauri geht. FORTH forscht seit Jahren auf diesem Gebiet und es wurde in dieser Zeit eine gewisse Expertise aufgebaut. Die Frage, was bei Updates des externen Thesaurus geschehen soll, kann mit den entsprechenden Mitarbeitern am FORTH erörtert werden. Synaptica Synaptica bietet die Möglichkeit, mehrere Objektklassen zu definieren. Zwei verschiedenen Thesauri können zwei unterschiedlichen Objektklassen angehören, was sie unterscheidbar macht. Es können in Synaptica Relationstypen innerhalb einer Objektklasse und zwischen Objektklassen definiert werden. Somit stellt die Einbindung eines externen Thesaurus mittels Mapping und der Äquivalenzen aus Abschnitt 3.2.3 kein Problem dar.

41
Protégé 2000 Da Protégé 2000 mit Ontologien umgeht, wird dieses Tool im Zusammenhang mit Lösung 2.3 besprochen. Retrievalware Laut Auskunft von Convera stellt das geschilderte Szenario mehrerer Thesauri mit den in Abschnitt 3.2.3 erläuterten Äquivalenzen kein Problem dar. Ein User Interface zur Thesaurusverwaltung, das wahrscheinlich ohnehin implementiert werden muß, könnte Mechanismen enthalten, die eine gemeinsame Pflege mehrerer Thesauri ermöglicht. K-Infinity In K-Infinity existiert ein Mapping-Tool, mit dem externe Thesauri eingebunden werden können. Nach Angaben von Intelligent Views ist es kein größerer Aufwand, das Mapping-Tool dahingehend zu erweitern, die in Abschnitt 3.2.3 definierten Äquivalenzen abbilden zu können. Durch das Mapping-Tool ist K-Infinity von vorneherein darauf ausgelegt, externe Thesauri handhaben zu können. 5.2.4 Evaluierung von Lösung 2.3 Da Lösung 2.3 ausschließlich von Ontologien redet, soll hier nur Protégé 2000 betrachtet werden. Protégé 2000 Alle für Lösung 2.3 vorgeschlagenen Verfahren, mehrere Thesauri mittels einer Ontologie zu modellieren, wurden mit Protégé 2000 prototypisch verwirklicht und getestet. 5.3 Zusammenfassung der Evaluation Im vorliegenden Kapitel wurden verschiedene Produkte vorgestellt und hinsichtlich der in Abschnitt 3 erarbeiteten Lösungsansätze evaluiert. Dabei wurden modulare und Stand-alone-Lösungen betrachtet. Alle vorgestellten Lösungen sind grundsätzlich für die Problemstellung geeignet. Für die abschließende Bewertung der Einsetzbarkeit dieser Produkte im Kontext des BGLA müssen noch einige andere Kriterien betrachtet werden: - Gibt es einen direkten Zugang zu den Entwicklern? Welche Art von Support wird geleistet? - Sind die Sourcen verfügbar? Was passiert, wenn ein Unternehmen aufhört zu existieren? Liegen die Sourcen vor, kann ein System an weitere Anforderungen des BGLA angepasst werden. Für dieses Kriterium sind besonders Open Source-Lösungen wie Protégé interessant. - Die Schlüssellisten liegen im relationalen Format vor. Zur Wahrung der Konsistenz wäre es sinnvoll, dass die eingesetzte Lösung direkt auf die Schlüssellisten in der relationalen Datenbank zugreifen kann. Es sollte evaluiert werden, inwiefern dies möglich ist.

42
- Mit Protégé wurde eine Lösung vorgestellt, bei welcher der Source Code vorliegt, ein anderes Kriterium des BGLA damit erfüllt wäre. Es ist allerdings noch zu evaluieren, welche Erfahrungswerte für Protégé in hochverfügbaren Systemen vorliegen, auch hinsichtlich des Finanz- und Datenvolumens. - Es ist ferner mit den Herstellern noch detaillierter zu klären, welche konkreten Maßnahmen zur Problemlösung mit dem jeweiligen Tool durchgeführt werden können. 6 Zusammenfassung und Ausblick In dieser Studie wurden Lösungsansätze für die Erstellung eines Thesaurus-basierten geologischen Informationssystems des BGLA diskutiert. Dabei wurden zunächst mal die beiden Hauptanforderungen an das neue geologische Informationssystem, die Transformation der bisher existierenden Schlüssellisten in eine Thesaurus-basierte Form, und die Einbindung externer Thesauri (wie z.B. des UOK) in das neue Informationssystem, identifiziert. Für beide Anforderungen wurden mögliche Lösungen entwickelt. Die bisherigen Schlüssellisten können dabei als Thesaurus oder auch als Ontologie modelliert werden. Ein externer Thesaurus kann eingebunden werden, indem dessen Elemente direkt mit den Geoobjekten verknüpft werden, oder (wie in der Literatur vorgeschlagen) ein Mapping zwischen dem externen und einem internen Thesaurus definiert wird. Letzteres wurde in dieser Studie ausführlich diskutiert, und es wurde auch eine Lösung auf Basis einer Ontologie vorgestellt. Ein weiterer Fokus dieser Studie war, existierende Produkte zu betrachten, mit deren Hilfe die erarbeiteten Lösungsansätze implementiert werden können. Diese Produkte wurden beschrieben und bzgl. der Problemstellungen evaluiert. Es zeigte sich dabei, dass alle vorgestellten Produkte geeignet sind, die beschriebenen Lösungsansätze umzusetzen. Es ist nun zu klären, inwiefern und wie die in dieser Studie erarbeiteten Lösungsansätze im BGLA-Kontext zur Erstellung eines neuen geologischen Informationssystems eingesetzt werden können. So ist z.B. zu definieren, wie ein Mapping zwischen den Thesauri konkret aussehen kann. Die Frage ist zu klären, ob ein externer Thesaurus dem BGLA als Kopie vorliegt und wenn ja, wie die Konsistenz im Falle von Änderungen im ursprünglichen externen Thesaurus gewahrt werden kann. Es sind also konkrete Strategien zu entwickeln, wie interner und externen Thesaurus miteinander korrespondieren und in vernünftiger Weise gewartet werden können. Natürlich muß auch evaluiert werden, wie diese Strategien durch die vorgestellten Tools unterstützt werden können; hier sind ggf. weitere Nachforschungen bei den Herstellern nötig. In diesem Kontext sind auch die in Abschnitt 5.3 beschriebenen Fragen zu klären.

43
Literaturverzeichnis[Doerr 2001] Martin Doerr, Semantic Problems of Thesaurus Mapping, 2001. http://jodi.ecs.soton.ac.uk/Articles/v01/i08/Doerr/ [ISO 2788] International Organization for Standardization, Guidelines for the Establishment and Development of Monolingual Thesauri, 1986 [ISO 5964] International Organization for Standardization, Guidelines for the Establishment and Development of Multilingual Thesauri, 1985 [Kern] Bayerisches Geologisches Landesamt, Übergreifendes Dokument Kern, 2001 [Mädche et. al 2001] Alexander Mädche, Steffen Staab, und Rudi Studer, Ontologien, 2001. http://www.aifb.uni-karlsruhe.de/~sst/Research/Publications/stichwort.pdf