"Topic Map Query Language"-Abfragesprache für die Groupware

Seminararbeit
Prototypische Implementierung der
"Topic Map Query Language"-Abfragesprache für die
Groupware-basierte Topic Map Engine
Prof. Dr. Ludwig Nastansky
Wintersemester 2004/2005
Vorgelegt von:
Christian Temath
Student der Wirtschaftsinformatik
Matrikelnummer 6090502
Ferdinandstraße 30
33102 Paderborn
Inhaltsverzeichnis
1. Einleitung ............................................................................................................................... 4
2. Konzeption ............................................................................................................................. 4
2.1. Die „Topic Map Query Language“-Abfragesprache ...................................................... 4
2.2. Prototypische Implementierung auf Basis von tolog ...................................................... 6
2.3. Unterstützte Sprachelemente von tolog........................................................................... 7
2.4. Rückgabeformate .......................................................................................................... 11
2.4.1. Rückgabe im HTML-Format ................................................................................. 12
2.4.2. Rückgabe im XML Topic Maps (XTM) Format ................................................... 12
2.5. Integration in bestehende Architektur ........................................................................... 13
3. Technische Realisierung ...................................................................................................... 14
3.1 Komponenten ................................................................................................................. 14
3.2 Java Klassen ................................................................................................................... 15
3.2.1. Tmql Parser package .............................................................................................. 15
3.2.2. Tmql Query package .............................................................................................. 15
3.2.3. Tmql package ......................................................................................................... 15
3.2.4. TmqlQueryServlet.................................................................................................. 15
3.3. HTML Dateien .............................................................................................................. 16
3.4. Änderungen in Konfigurationsdateien .......................................................................... 16
4. Funktionen des Prototyps ..................................................................................................... 16
4.1. Anmeldung und Navigation im Prototypen .................................................................. 16
4.2. Die Abfragemaske......................................................................................................... 17
4.2.1. Abfrage mittels vorgegebener Abfrage .................................................................. 17
4.2.2. Definition eigener Abfragen................................................................................... 18
4.2.3. Auswahl des Rückgabeformates ............................................................................ 18
5. Installation............................................................................................................................ 18
6. Fazit & Ausblick ................................................................................................................. 19
7. Abkürzungsverzeichnis ........................................................................................................ 20
8. Quellenverzeichnis ............................................................................................................... 20
Seite 2
Abbildungsverzeichnis
Abbildung 1: Grundlegendes Konzept der TMQL-Abfragesprache.......................................... 5
Abbildung 2: Übersicht über Vorschläge für die neue TMQL-Abfragesprache........................ 6
Abbildung 3: Ergebnis einer „instance-of“-Abfrage.................................................................. 7
Abbildung 4: Ergebnis einer Abfrage mit einem dynamischen Prädikat nach Variante 1 ........ 8
Abbildung 5: Ergebnis einer Abfrage mit einem dynamischen Prädikat nach Variante 2 ........ 8
Abbildung 6: Erste Variante der UND-Verknüpfung ................................................................ 8
Abbildung 7: Zweite Variante der UND-Verknüpfung ............................................................. 9
Abbildung 8: Beispielhafte UND-Verknüpfung nach Variante 1 .............................................. 9
Abbildung 9: Ergebnis der beispielhaften UND-Verknüpfung nach Variante 1 ....................... 9
Abbildung 10: Beispielhafte UND-Verknüpfung nach Variante 2.......................................... 10
Abbildung 11: Ergebnis der beispielhaften UND-Verknüpfung nach Variante 2 ................... 10
Abbildung 12: Ergebnis einer beispielhaften Projektionsoperation......................................... 11
Abbildung 13: Ergebnis einer beispielhaften Sortieroperation ................................................ 11
Abbildung 14: Das Abfrageergebnis überführt in eine HTML-Tabelle .................................. 12
Abbildung 15: Das Ergebnis einer TMQL-Abfrage im XTM-Format .................................... 13
Abbildung 16: Das um die TMQL Schnittstelle erweiterte GTME Framework...................... 14
Abbildung 17: Die Komponenten des TMQL-Prototyps......................................................... 14
Abbildung 18: Die Anmeldemaske des Prototyps ................................................................... 16
Abbildung 19: Navigationsbereich des TMQL-Prototyps ....................................................... 17
Abbildung 20: Die Abfragemaske des TMQL Prototyps......................................................... 17
Seite 3
1. Einleitung
Die folgende Dokumentation beschäftigt sich mit den Ergebnissen der Seminararbeit zum Thema
„Prototypische Implementierung der "Topic Map Query Language"-Abfragesprache für die
Groupware-basierte Topic Map Engine“, die im Rahmen des Seminars Wirtschaftsinformatik II am
Groupware Competence Center entstanden ist.
Im Rahmen des Dissertationsprojektes „K-Discovery“ von Stefan Smolnik am Groupware
Competence Center entstand der Prototyp einer Groupware-basierten Topic Map Engine1. Diese
Umgebung stellt verschiedene Werkzeuge zur Modellierung, Erstellung und Visualisierung von Topic
Maps in einem Groupware-basierten Umfeld zur Verfügung2. So reichen die vorhandenen Werkzeuge
von einem grafischen Modellierungswerkzeug für die Erstellung von Topic Maps, bis hin zu
Suchwerkzeugen, die grafisch oder textbasiert die Suche nach Informationen erleichtern. Zusätzlich
existiert eine Exportschnittstelle, die es ermöglicht, die Daten der erzeugten Topic Map in ein
standardisiertes XML-Format, dem XML Topic Maps (XTM) Format, zu exportieren. Dies stellt eine
erste, rudimentäre Schnittstelle zum Abfragen von Topic Map Informationen für die Groupwarebasierte Topic Map Engine (GTME) dar.
Im Rahmen internationaler Standardisierungsbemühungen wird zurzeit an einem Abfragestandard für
Topic Maps gearbeitet, der so genannten „Topic Map Query Language (TMQL)“-Abfragesprache.
Ziel dieser Arbeit ist es nun, einen Überblick über den aktuellen Stand des Standardisierungsprozesses
für die TMQL-Abfragesprache aufzuzeigen und basierend auf den im Standardisierungsprozess bisher
erarbeiteten Ergebnissen eine prototypische Implementierung für die Groupware-basierte Topic Map
Engine zu erstellen. Das Ziel ist demnach eine standardisierte Schnittstelle zum Abfragen von Topic
Map Daten zu schaffen, um die Groupware-basierte Topic Map Engine einem neuen
Anwendungsspektrum zugänglich zu machen.
2. Konzeption
2.1. Die „Topic Map Query Language“-Abfragesprache
Im Rahmen der Arbeit der Arbeitsgruppe ISO/IEC JTC1 SC34 WG33 wird an einer Abfragesprache
für Topic Maps gearbeitet. Die „Topic Map Query Language“-Abfragesprache soll als ISO/IEC ISO
18048 verabschiedet werden. Die Arbeitsgruppe beschäftigt sich im ersten Schritt zunächst mit
„retrieval scenarios“4, also der lesenden Abfrage von Topic Map Daten. In einem späteren zweiten
Schritt sollen dann auch „update scenarios“, das heißt, Zugriffe die Daten der Topic Map verändern,
behandelt werden. In Abbildung 1 wird das grundlegende Konzept der TMQL-Abfragesprache
deutlich.
1
Vgl. MEIRONKE, J.; MEYER, M.; PETER, M. (2001)
2 Vgl. K-DISCOVERY (2005): K-Discovery Architecture
3
Vgl. ISO/IEC JTC1 SC34 WG3 (2005A)
4
Vgl. ISO/IEC JTC1 SC34 WG3 (2005B): Introduction
Seite 4
Abbildung 1: Grundlegendes Konzept der TMQL-Abfragesprache5
Die Abfragesprache soll als standardisiertes Abfrageinstrument dienen, ohne dabei die Datenhaltung
kennen zu müssen, die der abzufragenden Topic Map zu Grunde liegt. Damit wird ein Datenaustausch
zwischen verschiedenen Topic Map Applikationen erleichtert. Der neue Abfragestandard für die
„Topic Map Query Language“-Abfragesprache befindet sich momentan noch im
Entwicklungsstadium. Ein aktueller Überblick über den Standardisierungsprozess kann auf der
Projektwebseite6 gefunden werden. Auf der Webseite finden sich alle für den
Standardisierungsprozess relevanten Informationen. Im „Requirements document“7 werden alle
grundlegenden Anforderungen an die TMQL-Abfragesprache definiert. Dort werden zunächst
Anforderungen an die Abfrageumgebung8 definiert. Weiterhin finden sich Anforderungen an das zu
definierende Sprachdefinitionsdokument für die Beziehung zu anderen Standards, zur Struktur, zur
Syntax und Semantik. In einem weiteren Kapitel9 werden die Anforderungen an die TMQLAbfragesprache selbst definiert. Zu diesen zählen Anforderungen an Kernfunktionalitäten, Eingabe
und Ausgabe, Benutzerfreundlichkeit und der Implementation der Sprache.
In einem weiterem Dokument, dem „TMQL Use Case Document“10 werden Anwendungsfälle für die
„Topic Map Query Language“-Abfragesprache definiert, nach denen einzelne Sprachvorschläge
bewertet werden können. In diesem Dokument finden sich einige globale Anwendungsszenarien, wie
zum Beispiel „Knowledge Web Sites, Web Portals, Content Management (Horizontal and Vertical
Markets), Enterprise Information Integration, High-Integrity Systems, Meta-Data Syndication,
Knowledge Management und Intangible Asset Management“. Darüber hinaus werden 29 konkrete
Anwendungsfälle definiert, die von der TMQL-Abfragesprache unterstützt werden sollen.
Für die „Topic Map Query Language“-Abfragesprache existieren einige Vorschläge, die sich
hinsichtlich ihres Implementierungsgrades teilweise stark unterscheiden. Die bisher in den
Standardisierungsprozess eingebrachten Vorschläge führt Abbildung 2 auf.
5
Vgl. ISO/IEC JTC1 SC34 WG3 (2005B)
Vgl. ISO/IEC JTC1 SC34 WG3 (20056)
7
Vgl. ISO/IEC JTC1 SC34 WG3 (2003A)
8
Vgl. ISO/IEC JTC1 SC34 WG3 (2003A): Query environment
9
Vgl. ISO/IEC JTC1 SC34 WG3 (2003A): Requirements for the language
10
Vgl. ISO/IEC JTC1 SC34 WG3 (2003B)
6
Seite 5
verfügbares
Sprachvorschlag Material
URL
TMRQL
Spezifikation
http://www.networkedplanet.com/download/TMRQL.pdf
tolog
Anleitung
http://www.ontopia.net/omnigator/docs/query/tutorial.html
Spezifikation
http://www.ontopia.net/topicmaps/materials/tolog-spec.html
kein Material
Empolis TMQL verfügbar
AsTMa?
Anleitung
http://astma.it.bond.edu.au/astma%3F-tutorial.dbk
Spezifikation
http://astma.it.bond.edu.au/astma%3F-spec.dbk
TMPath
Einführung
http://homepage.mac.com/dmitryv/TopicMaps/TMPath/TMPathRevisited.html
Anleitung/
Spezifikation
Toma
http://www.spaceapplications.com/toma/Toma.html
TMQL strawman Grundprinzip
http://www.y12.doe.gov/sgml/sc34/document/0186.doc
XTMPath
Anleitung
http://topicmaps.bond.edu.au/docs/13?style=printable
Spezifikation
http://cpan.uwinnipeg.ca/htdocs/XTM/XTM/Path.html
tmfun
Vorstellung
http://www.isotopicmaps.org/tmql/tmql-london-intro.pdf
Abbildung 2: Übersicht über Vorschläge für die neue TMQL-Abfragesprache
Eine aktuelle Übersicht über die eingereichten Vorschläge findet sich auf der Projektwebseite11.
Des Weiteren wird die „Roadmap“12 für den Standardisierungsprozess angegeben. Die einzelnen
Stufen bis zum endgültigen Standard sind als „Clay Man“, „Wood Man“, „Tin Man“, „Iron Man“ und
„Steel Man“ bezeichnet. Die aktuell fertig gestellte „Clay Man“ Version13 geht auf das Arbeitstreffen
vom April 2004 in Amsterdam14 zurück. Dort wurde der von der Firma Ontopia entwickelte Vorschlag
tolog als Basis für die „Topic Map Query Language“-Abfragesprache ausgewählt. Dieser Vorschlag
soll nun um noch nicht erfüllte Anforderungen erweitert werden. Für die prototypische
Implementierung der TMQL-Abfragesprache im Rahmen dieser Arbeit wurde aus diesem Grunde
tolog gewählt.
2.2. Prototypische Implementierung auf Basis von tolog
Wie im Abschnitt zuvor beschrieben, wurde tolog für die im Rahmen dieser Arbeit zu erstellende
prototypische „Topic Map Query Language“-Abfragespracheschnittstelle ausgewählt. Eine detaillierte
Beschreibung von tolog gibt die tolog Spezifikation15 und die tolog Anleitung16. Tolog ist eine Datalog
und SQL ähnliche Sprache. Mit ihr können Daten aus einer Topic Map ähnlich wie Daten aus einer
relationalen Datenbank mit SQL abgefragt werden. Eine Basisabfrage dieser Logik-basierten
Abfragesprache17 besteht grundsätzlich aus einer Behauptung, wobei das Ergebnis aus der Menge der
Fälle besteht, bei denen diese Behauptung wahr ist. Die Behauptungen in tolog bestehen im
Wesentlichen aus Prädikaten. Diese beschreiben Beziehungen zwischen Mengen von Werten. Die
Ergebnisse dieser Standardabfragen können als zweidimensionale Relation beschrieben werden, was
in seiner Form den Ergebnissen einer SQL-Abfrage gleicht. Die Ergebnisrelationen einzelner
Abfragen können mittels UND- und ODER- Verknüpfungen kombiniert werden. Durch Projektion ist
es möglich, aus einer Ergebnisrelation bestimmte Spalten auszuwählen. Wie bei SQL ist es außerdem
möglich, Ergebnismengen nach bestimmten Kriterien zu sortieren oder bestimmte Vorkommen in den
Ergebnisrelationen zu zählen.
Zu den erweiterten Funktionalitäten von tolog zählen eingebaute Prädikate, die Möglichkeit
Folgerungsregeln zu definieren und vergleichende Prädikate. Im Rahmen dieser Arbeit wurden die
nachfolgend beschriebenen Basisfunktionalitäten von tolog prototypisch implementiert.
11
Vgl. ISO/IEC JTC1 SC34 WG3 (2005B): Proposals
Vgl. ISO/IEC JTC1 SC34 WG3 (2005A): Roadmap
13
Vgl. ISO/IEC JTC1 SC34 WG3 (2005C)
14
Vgl. ISO/IEC JTC1 SC34 WG3 (2004)
15
Vgl. ONTOPIA (2003)
16
Vgl. ONTOPIA (2004)
17
Vgl. ONTOPIA (2004): Introduction
12
Seite 6
2.3. Unterstützte Sprachelemente von tolog
Aus den im vorherigen Kapitel vorgestellten Sprachelementen wurden im Rahmen dieser Arbeit
ausgewählte Elemente prototypisch für die Groupware-basierte Topic Map Engine implementiert. Die
Syntax von tolog ist als formale, kontext-freie Grammatik definiert. Zur Notation wird die erweiterte
Bachus Naur Form verwendet. Eine Basisabfrage hat bei tolog die folgende Form:
query ::= selectpart? clauselist orderpart? ‚?’
Im „Clauselist“-Teil werden ein oder mehrere verknüpfte Prädikate aufgeführt, die den Kern der
tolog-Abfrage bilden. Der optionale „Selectpart“-Teil ermöglicht die Nutzung der Projektion in
der Ergebnisrelation. Die so entstandene Ergebnisrelation kann mittels des ebenfalls optionalen
„Orderpart“-Teils in unterschiedlicher Weise sortiert werden.
Der Prototyp unterstützt zwei Arten von Prädikaten. Das instance-of($TOPIC, TYPE)Prädikat ist ein fest in tolog verankertes Prädikat, welches die Beziehung eines Topics zu einem Topic
Type beschreibt. Das instance-of($TOPIC, TYPE)-Prädikat ist genau dann wahr, wenn das
angegebene Topic ($TOPIC) vom Typ des angegebenen Topic Types (TYPE) ist. In diesem
Zusammenhang wird vorausgesetzt, dass der Basename des Topic Types für TYPE übergeben wird.
Das unterstützte instance-of($TOPIC, TYPE)-Prädikat veranschaulicht weiterhin die Nutzung
von Variablen. Variablen werden mit einem vorgestellten „$“-Zeichen gebildet. Der nachfolgende
Variablenname muss zusammengeschrieben werden und darf keine Umlaute enthalten. Sollten die
Bezeichnungen von Topic Types oder von Assoziationstypen Leerzeichen oder Umlaute enthalten, so
müssen diese mit einem “’“-Zeichen beginnen und mit einem „’“-Zeichen enden. Im Falle des
instance-of($TOPIC, TYPE)-Prädikats werden nun alle Topics vom Typ TYPE in der Spalte
mit dem Namen, den $TOPIC bezeichnet, zurückgegeben. Beispielsweise würde „instanceof($Lehrveranstaltung, Lehrveranstaltung) ?“ alle Lehrveranstaltungen in einer
einspaltigen Ergebnismenge zurückliefern. Die Spalte in dieser Ergebnismenge wäre in diesem Fall
mit $Lehrveranstaltung bezeichnet. Lehrveranstaltung muss hierbei nicht in
Anführungszeichen gesetzt werden, da es zusammengeschrieben wird und keine Umlaute enthält.
Abbildung 3 zeigt das Ergebnis der beispielhaften Abfrage.
$Lehrveranstaltung
Wirtschaftsinformatik
Wirtschaftsinformatik
Wirtschaftsinformatik
Wirtschaftsinformatik
…
2
4
1
3
Abbildung 3: Ergebnis einer „instance-of“-Abfrage
Neben dem instance-of($TOPIC, TYPE)-Prädikat unterstützt der Prototyp dynamische
Assoziationsprädikate. Diese können die folgende syntaktische Form annehmen:
1) Association($VAR1:TYPE1, TOPIC: TYPE2) oder
2) Association($VAR1:TYPE1, $VAR2: TYPE2)
Dynamische Assoziationsprädikate können genutzt werden, um Beziehungen zwischen Topics
abzufragen. Der Name des Prädikats ist der Name des Assoziationstyps, der die Beziehung zwischen
den Topics beschreibt. Für Association können somit alle in der Topic Map definierten
Assoziationstypen eingesetzt werden. TYPE1 und TYPE2 geben bei der Abfrage den Basename des
Topic Types an, von dem die Topics bei der angegeben Assoziation sein sollen. Im Falle einer
Abfrage nach 1) kann nun für einen Topic Type der Assoziation festgelegt werden, welchen Basename
das Topic haben soll. Der gewünschte Basename wird mit TOPIC bezeichnet. Das Ergebnis dieser
Abfrage ist dann eine Ergebnisrelation mit einer Spalte, die mit dem in $VAR1 angegebenen Namen
Seite 7
benannt ist. In dieser Spalte befinden sich nun alle Topics vom Type TYPE1, die in der in
Association definierten Beziehung zu einem Topic vom Typ TYPE2 stehen, welches den
Basename hat, der in TOPIC bezeichnet ist. Im Fall 2) wird die zusätzliche Einschränkung mit dem
Topic Basename nicht gemacht, so dass eine zweispaltige Ergebnisrelation besteht, die alle in der
Topic Map hinterlegten Beziehungen zwischen Topics vom Typ TYPE1 und TYPE2 enthält. Die erste
Spalte ist analog zum ersten Fall mit $VAR1 benannt, die zweite Spalte mit dem Wert von $VAR2.
Beispielsweise liefert das Assoziationsprädikat „‚findet statt im’($Semester :
Semester, ‚Wirtschaftsinformatik 2’
: Lehrveranstaltung)“ in einer
einspaltigen Ergebnisrelation alle Semester zurück in denen die Lehrveranstaltung mit dem Namen
„Wirtschaftsinformatik 2“ stattfindet. Das Ergebnis dieser Abfrage kann in Abbildung 4 betrachtet
werden.
$Semester
Sommersemester
Abbildung 4: Ergebnis einer Abfrage mit einem dynamischen Prädikat nach Variante 1
Lässt man wie in Fall 2) beschrieben den Topic Basename weg und nutzt man eine zweite Variable,
dann werden alle Kombinationen von Lehrveranstaltungen und dem zugehörigen Semester in dem sie
stattfinden zurückgegeben. Die Abfrage „‚findet statt im’($Semester : Semester,
$Lehrveranstaltung : Lehrveranstaltung) ?“ führt dann beispielsweise zu dem in
Abbildung 5 veranschaulichten Ergebnis.
$Semester
Sommersemester
Sommersemester
Wintersemester
Wintersemester
…
$Lehrveranstaltung
Wirtschaftsinformatik
Wirtschaftsinformatik
Wirtschaftsinformatik
Wirtschaftsinformatik
…
2
4
1
3
Abbildung 5: Ergebnis einer Abfrage mit einem dynamischen Prädikat nach Variante 2
Wie im vorherigen Kapitel beschrieben, bietet tolog die Möglichkeit Ergebnisrelationen logisch
miteinander zu verknüpfen. Verknüpfungen mit Operatoren werden bei tolog von links nach rechts
ausgewertet. Der in dieser Arbeit vorgestellte Prototyp unterstützt aus Demonstrationszwecken
lediglich die UND-Verknüpfung. UND Verknüpfungen werden in tolog durch ein einfaches „,“
zwischen zwei Prädikaten dargestellt. Syntaktisch sieht eine UND-Verknüpfung demnach so aus:
Prädikat1 ‚,’ Prädikat2
In diesem Fall kann Prädikat1 für das Ergebnis eines einzelnen Prädikats stehen oder selber das
Ergebnis einer Verknüpfung von zwei Ergebnisrelationen sein. Prädikat2 ist das Ergebnis eines
oben beschriebenen Basisprädikats und kann entweder eine ein- oder zweispaltige Ergebnisrelation
sein. Daraus ergeben sich zwei unterstützte Anwendungsszenarien. Eine n-spaltige Ergebnisrelation
wird mit einer einspaltigen Ergebnisrelation verknüpft oder eine n-spaltige Ergebnisrelation wird mit
einer zweispaltigen Ergebnisrelation verknüpft. Abbildung 6 und Abbildung 7 verdeutlichen
schematisch die beiden Varianten.
$1Sp_1
…
…
$1Sp_2
…
…
…
…
…
$1Sp_n
…
…
$2Sp_1
…
…
Abbildung 6: Erste Variante der UND-Verknüpfung
Seite 8
$1Sp_1
…
…
$1Sp_2
…
…
…
…
…
$1Sp_n
…
…
$2Sp_1
…
…
$2Sp_2
Abbildung 7: Zweite Variante der UND-Verknüpfung
Die UND-Verknüpfung führt nur dann zu einer Verknüpfung der Ergebnisrelationen, wenn der Name
von genau einer Spalte der ersten Ergebnisrelation mit dem Namen von genau einer Spalte der zweiten
Ergebnisrelation übereinstimmt. Stimmen nun zum Beispiel $1Sp_1 und $2Sp_1 überein, dann
werden aus der ersten Ergebnisrelation alle Zeilen entfernt, bei denen das Topic in der Spalte $2Sp_1
nicht in irgendeiner Zeile der Spalte $2Sp_1 der zweiten Relation vorhanden ist. Dies gilt analog
wenn $2Sp_1 mit einer anderen Spalte $1Sp_2, ..., $1_Sp_n übereinstimmt. Beispielsweise
kann die UND-Verknüpfung im ersten Fall wie in Abbildung 8 aussehen.
$Semester
Sommersemester
Sommersemester
Wintersemester
Wintersemester
$Lehrveranstaltung
Wirtschaftsinformatik 2
Wirtschaftsinformatik 4
Wirtschaftsinformatik 1
Wirtschaftsinformatik 3
$Lehrveranstaltung
Wirtschaftsinformatik 2
Wirtschaftsinformatik 3
Abbildung 8: Beispielhafte UND-Verknüpfung nach Variante 1
Der Name der zweiten Spalte der ersten Relation stimmt mit dem Namen der ersten Spalte der zweiten
Relation überein. Wird nun die UND-Verknüpfung zwischen beiden Ergebnisrelationen durchgeführt,
dann werden alle Zeilen der ersten Ergebnisrelation entfernt, in denen in der Spalte
$Lehrveranstaltung
nicht
entweder
„Wirtschaftsinformatik
2“
oder
„Wirtschaftsinformatik 3“ steht. Abbildung 9 zeigt das resultierende Ergebnis.
$Semester
Sommersemester
Wintersemester
$Lehrveranstaltung
Wirtschaftsinformatik 2
Wirtschaftsinformatik 3
Abbildung 9: Ergebnis der beispielhaften UND-Verknüpfung nach Variante 1
Die zweite Variante ist ein wenig komplexer und gibt als Ergebnis eine Ergebnisrelation R3 zurück,
die eine Spalte mehr enthält als die erste Ergebnisrelation R1. Wiederum ist Voraussetzung, dass
genau ein Spaltenname aus R1 mit dem Namen einer Spalte aus der zweiten Ergebnisrelation R2
übereinstimmt. Das ist zum Beispiel wiederum für $1Sp_1 und $2Sp_2 der Fall. Jede Zeile aus R1
wird nun mit jeder Zeile aus R2 verglichen. Stimmen die Topics in Spalte $1Sp_1 und $2Sp_2
überein, dann wird eine neue Zeile in R3 erstellt, die alle Spalten aus der Zeile aus R1 enthält und
zusätzlich um den Eintrag in der Spalte $2Sp_1 erweitert wird. Die letztgenannte Spalte in R3 wird
dementsprechend mit $2Sp_1 bezeichnet. Abbildung 10 veranschaulicht das Prinzip.
Seite 9
$Semester
Sommersemester
Sommersemester
Wintersemester
Wintersemester
$Lehrveranstaltung
Wirtschaftsinformatik 2
Wirtschaftsinformatik 4
Wirtschaftsinformatik 1
Wirtschaftsinformatik 3
$Lehrveranstaltung
Wirtschaftsinformatik 2
Wirtschaftsinformatik 3
Wirtschaftsinformatik 3
$Veranstaltungsart
Übung
Vorlesung
Übung
Abbildung 10: Beispielhafte UND-Verknüpfung nach Variante 2
In diesem Beispiel stimmen die Namen der zweiten Spalte der ersten Relation mit dem Namen der
ersten Spalte der zweiten Relation überein. Für die erste Zeile der ersten Relation gilt nun, dass der
Eintrag „Wirtschaftsinformatik 2“ in der ersten Zeile mit dem Eintrag der ersten Zeile der
zweiten Relation übereinstimmt. Nun wird in der zu bildenden Ergebnisrelation eine Zeile gebildet, in
der alle Einträge der ersten Relation und der Eintrag „Übung“ aus der Spalte
$Veranstaltungsart enthalten sind. Für die nächsten beiden Zeilen der ersten Relation findet
sich für die Spalte $Lehrveranstaltung kein übereinstimmender Eintrag in der zweiten
Relation. Dementsprechend wird in der Ergebnisrelation keine neue Zeile gebildet. Für den Eintrag
„Wirtschaftsinformatik 3“ der ersten Relation gibt es in zwei Zeilen der zweiten Relation
eine Entsprechung. Die Zeile der ersten Relation wird nun in der Ergebnisrelation sowohl um
„Vorlesung“, als auch um „Übung“ ergänzt. Das Ergebnis der UND-Verknüpfung kann in
Abbildung 11 betrachtet werden.
$Semester
Sommersemester
Wintersemester
Wintersemester
$Lehrveranstaltung
Wirtschaftsinformatik 2
Wirtschaftsinformatik 3
Wirtschaftsinformatik 3
$Veranstaltungsart
Übung
Vorlesung
Übung
Abbildung 11: Ergebnis der beispielhaften UND-Verknüpfung nach Variante 2
Des Weiteren wurde auch die in dem optionalen „Selectpart“-Teil definierte Projektion im
Prototyp implementiert. Grundsätzlich besteht der Projektionsteil aus den Schlüsselwörtern
„SELECT“ und „FROM“. In der „selectlist“ werden alle Spaltennamen aufgeführt, die aus der
ursprünglichen Ergebnisrelation ausgewählt werden sollen. Die einzelnen Spaltennamen sind jeweils
durch ein „,“ getrennt. Die folgenden Produktionsregeln definieren den „selectpart“-Teil:
selectpart ::= 'SELECT' selectlist 'FROM'
selectlist ::= variable (',' variable)*
Zum Beispiel würde die Abfrage „SELECT $Semester FROM ‚findet statt
im’($Semester : Semester, $Lehrveranstaltung
: Lehrveranstaltung)
?“ aus der in Abbildung 5 gezeigten Ergebnisrelation die Spalte $Semester auswählen. Das
Ergebnis der gesamten Abfrage kann in Abbildung 12 betrachtet werden.
Seite 10
$Semester
Sommersemester
Sommersemester
Wintersemester
Wintersemester
…
Abbildung 12: Ergebnis einer beispielhaften Projektionsoperation
Die letzte im Prototyp implementierte Funktionalität ist die Sortierung. Der optionale „Orderpart“Teil der Abfrage ist syntaktisch folgendermaßen definiert:
orderpart
::=
'ORDER' 'BY' orderlist
orderlist
::=
ordpart (',' ordpart)*
ordpart
::=
variable ('ASC' | 'DESC')?
Der Sortierteil beginnt mit den Schlüsselwörtern “ORDER BY”. Danach werden in der „orderlist“
die einzelnen Spaltennamen der Ergebnisrelation angegeben, nach denen sortiert werden soll. Es ist
möglich nacheinander nach verschiedenen Spalten sortieren zu lassen. Dabei werden die einzelnen
Spaltennamen durch das Kommazeichen „,“ getrennt. Die den Variablen folgenden Schlüsselwörter
„ASC“ und „DESC“ geben an, ob aufsteigend („ASC“) oder absteigend („DESC“) sortiert werden
sollen. Wird weder „ASC“ noch „DESC“ angegeben, so wird standardmäßig aufsteigend sortiert. Die
Reihenfolge der Sortierung ist von rechts nach links. So wird bei einem Sortierteil „ORDER BY
$Spalte1, $Spalte2“ die Ergebnisrelation zuerst nach $Spalte2 und danach nach
$Spalte1 sortiert. Das verwendete Sortierverfahren sortiert stabil, was bedeutet, dass gleiche
Elemente nicht in ihrer Reihenfolge vertauscht werden. Das Ergebnis der folgenden Abfrage
„’findet statt im’($Semester : Semester, $Lehrveranstaltung
:
Lehrveranstaltung) ORDER BY $Lehrveranstaltung ASC ?“ kann in Abbildung 13
betrachtet werden.
$Semester
…
Wintersemester
Sommersemester
Wintersemester
Sommersemester
…
$Lehrveranstaltung
…
Wirtschaftsinformatik
Wirtschaftsinformatik
Wirtschaftsinformatik
Wirtschaftsinformatik
…
1
2
3
4
Abbildung 13: Ergebnis einer beispielhaften Sortieroperation
Damit sind alle vom Prototyp unterstützten Sprachelemente von tolog beschrieben.
2.4. Rückgabeformate
Laut Anforderungsdokument der „Topic Map Query Language“-Abfragesprache sollen die
„ResultSets“, also die Ergebnismengen einer Abfrage, sowohl möglichst primitive Formate, als auch
XML Formate unterstützen18. Ergebnisse von tolog-Abfragen entsprechen in ihrer Form grundsätzlich
denen von ResultSets aus SQL-Abfragen. Dies orientiert sich an der zweidimensionalen Struktur der
Ergebnisrelationen. Die Ergebnisse der Abfragen im vorliegenden Prototyp werden zunächst in der
Form eines von SQL bekannten ResultSets dargestellt. Die ResultSets bieten die Möglichkeit die
einzelnen Zeilen der Ergebnisrelation zu betrachten und in jeder Zeile das Topic einer bestimmten
Spalte abzufragen. Die Topics in den ResultSets beinhalten alle zugehörigen Informationen wie die
Basenames, die Topic Types und die Occurrences der Topics. Diese Form der Ergebnisdarstellung
kann vor allem in Applikationen eingesetzt werden, die die abgefragten Daten direkt
18
Vgl. ISO/IEC JTC1 SC34 WG3 (2003A): ResultSets
Seite 11
weiterverarbeiten. Zusätzlich zu der Darstellung in ResultSets wurden Möglichkeiten implementiert,
das ResultSet zu serialisieren und somit den Datenaustausch zu erleichtern. Im Folgenden werden die
beiden unterstützten Überführungen in ein serialisiertes Format näher beschrieben.
2.4.1. Rückgabe im HTML-Format
Die Ausgabe im HTML-Format dient vor allem der Visualisierung der Abfrageergebnisse. Die
zweidimensionale Ergebnisrelation wird in einer Tabelle dargestellt. Dabei werden die Topics jeder
Zeile der Ergebnisrelation in eine Zeile in der HTML-Tabelle dargestellt. Die einzelnen Spalten der
Ergebnisrelation werden als Tabellenspalten dargestellt. Als Eintrag in jeder Zelle dient der Basename
eines Topics. Zusätzlich wird ein Link hinter dem Basename hinterlegt, der auf das Occurrence des
Topics verweist. Diese Art der Darstellung kann vor allem in einem Suchkontext verwendet werden,
bei dem Abfrageergebnisse in einem Webbrowser angezeigt werden und über die hinterlegte
Verlinkung direkt auf die entsprechenden Occurrences zugegriffen werden kann. Abbildung 14 zeigt
eine beispielhafte Darstellung eines ResultSets überführt in eine HTML-Tabelle.
Abbildung 14: Das Abfrageergebnis überführt in eine HTML-Tabelle
2.4.2. Rückgabe im XML Topic Maps (XTM) Format
Zusätzlich zu den oben genannten Formen der Ergebnisdarstellung wurde im Rahmen dieser Arbeit
auch die Möglichkeit vorgesehen, die Ergebnisrelation in ein XML-Format zu überführen. Für dieses
Format wurde das XML Topic Maps Format19 ausgewählt. Damit wird dem Anforderungsdokument
Rechnung getragen, in dem gefordert wird, sich möglichst an existierenden Standards zu orientieren.
Das Ergebnis einer TMQL-Abfrage ist nur ein Teil der gesamten Topic Map und kann somit nicht
ohne weiteres in das XTM-Format überführt werden. Nach einem von Kalil Ahmed vorgeschlagenen
Algorithmus20 ist es jedoch möglich, das Ergebnis einer Abfrage in ein Topic Map Fragment zu
überführen. Ein Topic Map Fragment ist eine eigenständige, vollständige Topic Map, die in der XTM
1.0 Austauschsyntax ausgedrückt wird21. In diesem Topic Map Fragment befinden sich alle
Informationen des Abfrageergebnisses, jedoch keine weiteren Daten aus der abgefragten Topic Map.
Mit folgendem Algorithmus kann ein wie oben beschriebenes ResultSet in das XTM 1.0 Format
überführt werden. Zuerst werden für alle Spaltennamen Topics erzeugt. Zusätzlich wird für jedes in
der Ergebnisrelation vorhandene Topic ein Topic in dem XTM-Dokument angelegt. Nun wird für jede
Zeile der Ergebnisrelation eine Assoziation erzeugt, bei der jede Spalte ein Member-Element der
Assoziation darstellt. In diesen Member-Elementen ist das in der Spalte vorliegende Topic das
„Player“-Topic und der Spaltenname das „Role“-Topic. Aus diesen Informationen kann nachträglich
wieder eindeutig das ResultSet zusammengesetzt werden. Zusätzlich werden in dem XTM-Dokument
noch Topics für alle Topic Types der im Ergebnis enthaltenen Topics angelegt. Der XTM-Standard
selbst sieht keine Elemente für Topic Types vor22/23. Diese Beziehungen werden über das „instanceOf“
Element der einzelnen Topics abgebildet. Somit ist es nachträglich weiterhin möglich zu erkennen,
19
Vgl. TOPICMAPS.ORG (2001)
Vgl. AHMED, KALIL (2003): tolog ResultSets
21
Vgl. AHMED, KALIL (2003): Topic Map Fragment Exchange
22
Vgl. SCHMITZ, M.;SILLEKENS, T, (2003)
23
Vgl. TOPICMAPS.ORG (2001)
20
Seite 12
von welchem Typ ein bestimmtes Topic ist. Das umgewandelte Ergebnis einer beispielhaften Abfrage
kann in Abbildung 15 betrachtet werden.
Abbildung 15: Das Ergebnis einer TMQL-Abfrage im XTM-Format
2.5. Integration in bestehende Architektur
Die im Rahmen dieser Arbeit implementierte Schnittstelle fügt sich nahtlos in die bestehende
Architektur der Groupware-basierten Topic Map Engine ein. Neben einer Vielzahl bereits vorhandener
Visualisierungswerkzeuge und speziell für die Groupware-basierten Topic Map Engine entwickelten
Suchwerkzeuge, stellt die prototypische TMQL-Schnittstelle eine weitere Schnittstelle dar, die den
Anwendungsspielraum der Topic Map Engine erhöht. Die erweiterte Architektur wird in Abbildung
16 dargestellt. So greift die prototypische „Topic Map Query Language“-Abfragespracheschnittstelle
über die schon vorhandenen Schnittstellen auf die relationale Datenbank und die
Konfigurationsdatenbank in Lotus Domino zu.
Seite 13
Abbildung 16: Das um die TMQL Schnittstelle erweiterte GTME Framework
3. Technische Realisierung
Dieses Kapitel erläutert die technische Umsetzung der im Kapitel „Konzeption“ beschriebenen
Funktionalitäten des Prototyps. Im Einzelnen werden die verwendeten Komponenten, die darin
enthaltenen Javaklassen und weitere Änderungen erläutert.
3.1 Komponenten
Die drei wichtigsten Komponenten des Prototyps werden in Abbildung 17 dargestellt.
Abbildung 17: Die Komponenten des TMQL-Prototyps
Abfragen werden vom „TMQL-Query-Servlet“ entgegengenommen und an die „TMQL-Parser“Komponente weitergegeben. Der Parser wird benötigt, um generisch die vom Prototyp unterstützten
Sprachelemente erkennen zu können. Der Parser durchläuft dann die gegebene Abfrage und überführt
diese in eine Objektstruktur, die sich an den Produktionsregeln der unterstützten Sprachelemente
orientiert und die Abfrage in Objekten nachbildet. Diese „TMQL-Query“-Objektstruktur führt nun die
Abfrage auf der relationalen Datenbank durch und gibt das Ergebnis der Abfrage an das „TMQLSeite 14
Query-Servlet“ zurück. Die einzelnen Komponenten werden in den folgenden Kapiteln ausführlicher
beschrieben.
3.2 Java Klassen
Im folgenden Kapitel wird auf die einzelnen Javaklassen eingegangen, die im Rahmen dieser Arbeit
erstellt worden sind. Diese sind in drei Pakete eingeteilt worden, die sich grundsätzlich an der
beschriebenen Komponentenstruktur orientieren.
3.2.1. Tmql Parser package
Um eine kontextfreie Grammatik generisch verarbeiten zu können, ist ein Parser notwendig. Für Java
existiert mit dem Java Compiler Compiler (JavaCC) eine freies Entwicklungspaket, dass die
Entwicklung eines angepassten Parsers ermöglicht24. Dazu werden alle Produktionsregeln in der Datei
„TmqlParser.jjt“ aufgeführt. Diese Regeln können zusätzlich noch um Javabefehle erweitert werden,
so dass es möglich ist, die vom Parser vorgefundene Abfragestruktur in eine eigene Objektstruktur zu
überführen. Der Java Compiler Compiler überführt die Datei „TmqlParser.jjt“ in zwei Schritten in eine
eigene Javaquellcode Datei, die dann wiederum mit einem normalen Java Compiler in ausführbaren
Javacode übersetzt werden kann.
3.2.2. Tmql Query package
Im TmqlQuery Paket sind alle Elemente der Produktionsregeln der unterstützten Sprachelemente als
Javaklassen abgebildet. Diese werden vom TmqlParser benötigt, um die Abfrage in eine nutzbare
Objektstruktur zu überführen. In diesem Paket sind die „TmqlQuery“-Klasse in Verbindung mit der
„TmqlDatabaseSearchEngine“-Klasse die wichtigsten Konstrukte. Die „TmqlQuery“-Klasse enthält
die gesamte Logik, um Funktionen wie Projektion, Verknüpfungen und weitere Funktionen
durchzuführen. Die Daten aus der relationalen Datenbank liest in diesem Kontext die
„TmqlDatabaseSearchEngine“-Klasse aus.
3.2.3. Tmql package
Im Tmql Paket befindet sich vor allem die „ResultSet“-Klasse. Diese Klasse implementiert die weiter
oben beschriebenen Rückgabefunktionen in das HTML –Format und das XTM-Format. Sie ist das
zentrale Element, um mit den Abfrageergebnissen zu arbeiten. Zusätzlich werden in diesem Paket
auch die zentralen Elemente der Sortierfunktion implementiert, die direkt von der „ResultSet“-Klasse
ausgeführt werden. Die Klassen „Connection“ und „Statement“ orientieren sich an dem Java.sql Paket.
Vor allem die „Connection“-Klasse kann in einer weiteren Ausbaustufe des Prototyps dazu verwendet
werden, Abfragen auf verschiedene Topic Maps beziehungsweise Topic Map Engines zu ermöglichen.
Über verschiedene „Connection“-Objekte könnten Verbindungen zu verschiedenen Datenquellen
realisiert werden. Zusätzlich enthält dieses Paket die „Topic“-Klasse. Objekte von diesem Typ können
für ein TMQL-Abfrage Ergebnis aus dem ResultSet abgefragt werden.
3.2.4. TmqlQueryServlet
Die Klasse „TmqlQueryServlet“ ist das zentrale Element der Webanwendung des Prototyps. Über das
TmqlQueryServlet werden alle angefragten HTML-Seiten angezeigt und zusätzlich die TMQLAbfragen an den Parser weitergeleitet und das Abfrageergebnis zurückgegeben. Des Weiteren
implementiert das TmqlQueryServlet die in der Groupware-basierten Topic Map Engine vorhandene
Benutzerverwaltung.
24
Vgl. JAVACC (2005)
Seite 15
3.3. HTML Dateien
Für die Darstellung der einzelnen Seiten des TmqlQueryServlets wurden einige HTML-Seiten erstellt.
Sie befinden sich im „resource\html“ Ordner und können ohne Neukompilieren des Prototyps geändert
werden. Damit können Änderungen am Design der Webanwendung vorgenommen werden, ohne den
Quellcode der Applikation kennen und ändern zu müssen.
3.4. Änderungen in Konfigurationsdateien
Der in dieser Arbeit entstandene Prototyp greift auf wesentliche Klassen der Groupware-basierten
Topic Map Engine zurück. Aus diesem Grund mussten einige Konfigurationsdateien angepasst
werden, um bestimmte Funktionen nutzen zu können. In der Datei „log.properties“ wurde der Name
des Logs auf das TmqlQueryServlet angepasst. Die vom Prototyp benutzten HTML-Seiten wurden in
der „resources.properties“-Datei eingetragen. Zusätzlich wurden in der Datei „statements.properties“
die vom Prototyp benötigten SQL-Abfragestatements aufgenommen und diese durch zusätzliche
Einträge in der „rdb.properties“-Datei nutzbar gemacht.
4. Funktionen des Prototyps
In diesem Kapitel werden die einzelnen Funktionen des Prototyps vorgestellt.
4.1. Anmeldung und Navigation im Prototypen
Im Prototypen der „Topic Map Query Language“-Abfrageschnittstelle ist eine Benutzerverwaltung
integriert, die auf die registrierten Benutzer der GTME Lotus Domino Konfigurationsdatenbank
zurückgreift. Will ein Benutzer den Prototypen nutzen, so muss er sich zuerst am System anmelden.
Abbildung 18 zeigt die Anmeldemaske des Prototyps.
Abbildung 18: Die Anmeldemaske des Prototyps
Nach erfolgreicher Anmeldung wird das Hauptfenster des Prototyps angezeigt. Auf der linken Seite
findet sich der Navigationsbereich über den auf die einzelnen Seiten zugegriffen werden kann. Dieser
kann in Abbildung 19 betrachtet werden. Standardmäßig wird im Hauptteil des Fensters die
Abfragemaske angezeigt, auf die weiter unten detailliert eingegangen wird. Zu dieser kann man immer
durch die Verlinkung „Search“ im Navigationsbereich zurückkehren. Zusätzlich kann man über die
Verlinkung „Help“ die Hilfeseite anzeigen lassen. Weiterhin kann eine Informationsseite über das „KDiscovery“-Projekt aufrufen und sich den Haftungsausschluss („Disclaimer“) ansehen. Über den
Navigationspunkt „Logout“ kann man sich vom System abmelden.
Seite 16
Abbildung 19: Navigationsbereich des TMQL-Prototyps
4.2. Die Abfragemaske
Die nach der Anmeldung standardmäßig angezeigte Abfragemaske wird in diesem Kapitel ausführlich
beschrieben. Die Abfragemaske kann in Abbildung 20 betrachtet werden. Der Benutzer kann mithilfe
der Abfragemaske die auszuführende Abfrage definieren und das Rückgabeformat des
Abfrageergebnisses festlegen.
Abbildung 20: Die Abfragemaske des TMQL Prototyps
4.2.1. Abfrage mittels vorgegebener Abfrage
Der vorliegende Prototyp bietet einige vorgegebene Abfragen. Diese in Abbildung 20 abgebildeten
Abfragen können durch das Auswahlfeld ausgewählt werden. Durch das Betätigen des „Send Query“
Knopfes wird die Abfrage ausgeführt. Die vorgegebenen Beispielabfragen führen den Benutzer Schritt
für Schritt in die Fähigkeiten der Abfrageschnittstelle ein. Ausgehend vom „instance-of“-Prädikat,
werden dynamische Prädikate in ihren verschiedenen Varianten behandelt. Weiterhin werden
Beispiele für die Projektion mittels „SELECT … FROM“ und der Sortierung mittels „ORDER BY“
Seite 17
gegeben. Die letzte Abfrage befasst sich mit der UND-Verknüpfung. Da die beiden verknüpften
Prädikate auch einzeln als Beispiele aufgeführt sind, wird der Benutzer in die Lage versetzt, die
Funktionsweise der UND-Verknüpfung einfach nachzuvollziehen.
4.2.2. Definition eigener Abfragen
Weiterhin ist es für den Benutzer möglich, eigene Abfragen zu definieren und sich die Ergebnisse
ausgeben zu lassen. Dazu muss das Auswahlfeld neben dem Textfeld eingegeben werden und in das
Textfeld eine gültige TMQL-Abfrage eingegeben werden. Nach dem Betätigen des „Send query“
Knopfes wird das Ergebnis der Abfrage ermittelt und ausgegeben. Das Textfeld zur freien
Abfrageerstellung kann vom Benutzer genutzt werden, um sich mit der Syntax und den Fähigkeiten
der implementierten „Topic Map Query Language“-Abfragesprache vertraut zu machen.
4.2.3. Auswahl des Rückgabeformates
Für das Rückgabeformat stehen wie in dem Kapitel „Konzeption – Rückgabeformate“ beschrieben,
zwei Möglichkeiten zur Verfügung. Eine Möglichkeit ist, dass sich der Benutzer das Ergebnis im
HTML-Format im Webbrowser anzeigen lässt. Dies wird durch die Auswahl der Option „HTML
output“ erreicht. Dabei wird die zweidimensionale Ergebnisrelation wie oben beschrieben und in
Abbildung 14 dargestellt in eine Tabelle überführt. Hinter den einzelnen Einträgen ist das Occurrence
des Topics verlinkt. Eine weitere Möglichkeit ist die Ausgabe des Abfrageergebnisses im XTMFormat im Webbrowser. Verfügt dieser über einen XML-Parser, dann wird das Ergebnis in der XMLBaumansicht dargestellt. Zusätzlich ist es möglich über die Auswahl der Option „XTM download“ das
Abfrageergebnis als XTM-Dokument lokal zu speichern. Damit ist es möglich, die durch die Abfrage
erhaltenen Daten weiterzuverarbeiten und gegebenenfalls weiterzugeben.
5. Installation
Die Installation des „Topic Map Query Language“-Abfragespracheprototyps gestaltet sich bei einer
installierten Groupware-basierten Topic Map Umgebung als sehr einfach. Die einzelnen Schritte
werden hier zusammengefasst:
•
Die Datei „TmqlQueryServlet.war“ muss in das Apache Tomcat „webapps“-Verzeichnis
werden.
Beispiel: „C:\jakarta-tomcat-3.3.1a\webapps\TmqlQueryServlet.war“
•
Nun muss weiterhin die Datei „uriworkermap.properties“ angepasst werden. Diese befindet
sich im Tomcat Konfigurations-Verzeichnis „\conf\jk“.
Beispiel: „C:\jakarta-tomcat-3.3.1a\conf\jk\uriworkermap.properties”
In dieser Datei müssen folgende Zeilen ergänzt werden, damit Anfragen an das Servlet
weitergeleitet und verarbeitet werden:
/TmqlQueryServlet/*=ajp12
/TmqlQueryServlet =ajp12
•
Der Lotus Domino Server, und damit auch der Apache Tomcat, müssen neu gestartet werden.
Beim Neustart von Apache Tomcat wird die „TmqlQueryServlet.war“-Datei automatisch
entpackt und das Servlet steht als Webanwendung zur Verfügung
•
Der Prototyp der „Topic Map Query Language“-Abfragesprache kann nun durch Eingabe
folgender
URL
in
einem
Browser
gestartet
werden:
„http://servername/TmqlQueryServlet“
Seite 18
Diese Anleitung sollte benutzt werden, falls bereits eine Groupware-basierte Topic Map Engine
Umgebung eingerichtet ist. Für den Fall, dass diese noch nicht eingerichtet ist, sollte zuerst die
Groupware-basierte Topic Map Engine installiert werden. Eine Installationsanleitung findet sich in der
Konfigurationsdatenbank. Danach kann dann wie oben beschrieben der TMQL-AbfragesprachePrototyp installiert werden.
6. Fazit & Ausblick
Als Fazit der vorliegenden Arbeit lässt sich sagen, dass es möglich war, eine prototypische
Abfrageschnittstelle für die „Topic Map Query Language“-Abfragesprache für die Groupware-basierte
Topic Map Engine zu konzipieren und implementieren. Mit der in dieser Arbeit implementierten
Schnittstelle erhöhen sich die Nutzungsmöglichkeiten der Groupware-basierten Topic Map Engine für
weitere Anwendungsfelder. Die Abfrage von Topic Map Informationen ist nun über eine sich in der
Standardisierung befindliche Abfragesprache für andere Applikationen möglich geworden.
Für die Zukunft wäre es wünschenswert, den Standardisierungsprozess weiter zu verfolgen und den
Prototyp auf die endgültig verabschiedete „Topic Map Query Language“-Abfragesprache anzupassen.
Des Weiteren wäre es wünschenswert, den Prototypen um die Möglichkeit zu erweitern, Abfragen an
unterschiedliche Instanzen der Groupware-basierten Topic Map Engine stellen zu können. Eine
zusätzliche Erweiterung würde ein Importmechanismus darstellen, der mit Hilfe der „Topic Map
Query Language“-Abfragesprache Daten aus anderen Topic Maps abfragt und diese in der
Groupware-basierten Topic Map Engine speichert und über die vorhandenen Such- und
Visualisierungswerkzeuge nutzbar macht.
Seite 19
7. Abkürzungsverzeichnis
GTME
Groupware-basierte Topic Map Engine
JavaCC
Java Compiler Compiler
SQL
Structured Query Language
TMQL
Topic Map Query Language
URL
Uniform Resource Locator
XTM
XML Topic Maps
8. Quellenverzeichnis
AHMED, KALIL (2003):
TMShare – Topic Map Fragment Exchange In a Peer-To-Peer Application; 2003;
http://www.idealliance.org/papers/dx_xmle03/papers/02-03-03/02-03-03.pdf (Stand:
19.04.2005)
ISO/IEC JTC1 SC34 WG3 (2003A):
TMQL Requirements 1.2.0; Working Draft; 2003;
http://www.y12.doe.gov/sgml/sc34/document/0448.htm (Stand: 19.04.2005)
ISO/IEC JTC1 SC34 WG3 (2003B):
Topic Map Query Language, Use Cases; Technical Document; 2003;
http://www.y12.doe.gov/sgml/sc34/document/0448.htm (Stand: 19.04.2005)
ISO/IEC JTC1 SC34 WG3 (2004):
TMQL 0.1 – Design Notes; Notes from SC34/WG3 meeting; 2004; Amsterdam
http://www.jtc1sc34.org/repository/0502.pdf (Stand: 19.04.2005)
ISO/IEC JTC1 SC34 WG3 (2005A):
ISO/IEC JTC1 SC34 WG3; Arbeitsgruppenwebseite; 2005; http://www.isotopicmaps.org
(Stand: 19.04.2005)
ISO/IEC JTC1 SC34 WG3 (2005B):
Topic Map Query Language; Projektwebseite; 2005; http://www.isotopicmaps.org/tmql/
(Stand: 19.04.2005)
ISO/IEC JTC1 SC34 WG3 (2005C):
Topic Maps Query Language; Working Draft; 2005;
http://www.isotopicmaps.org/tmql/spec.html (Stand: 19.04.2005)
JAVACC (2005):
Projektwebseite;2005; https://javacc.dev.java.net/ (Stand 20.04.2005)
K-DISCOVERY (2005):
K-Discovery; Projektwebseite; 2005; http://gtm.upb.de (Stand 20.04.2005)
Seite 20
MEIRONKE, J.; MEYER, M.; PETER, M. (2001):
Konzeption und Implementation einer Groupware-basierten Topic Map Engine;
Seminararbeit; Universität Paderborn; Lehrstuhl Wirtschaftsinformatik 2; Paderborn; 2001
ONTOPIA (2004):
tolog – Language Tutorial; 2004; http://www.ontopia.net/omnigator/docs/query/tutorial.html
(Stand: 19.04.2005)
ONTOPIA (2003):
tolog 1.0;Technical Report; 2003; http://www.ontopia.net/topicmaps/materials/tolog-spec.html
(Stand: 19.04.2005)
SCHMITZ, M.; SILLEKENS, T. (2003)
Entwicklung einer XML Schnittstelle; Projektarbeit; Universität Paderborn; Lehrstuhl
Wirtschaftsinformatik 2; Paderborn; 2003
TOPICMAPS.ORG (2001):
XML Topic Maps (XTM) 1.0; TopicMaps.Org Specification; 2001;
http://www.topicmaps.org/xtm/1.0/ (Stand: 19.04.2005)
Seite 21