Konzeption, Implementierung Und Evaluierung Eines TMQL-Parsers Und Interpreters

Konzeption, Implementierung und Evaluierung
eines TMQL-Parsers und Interpreters
Masterarbeit
zur Erlangung des Grades Master of Science (M.Sc.)
an der Fakultät Informatik
der Universität Leipzig
eingereicht von: Sven Krosse

Breisgaustraße 15
04209 Leipzig
Mat.Nr.: 1499090
Betreuer: Prof. Dr. Gerhard Heyer

Abstract
Mit der Entwicklung im Rahmen des Web 2.0. gewann die

Datenmodellierungstechnik Topic Maps zunehmend an Bedeutung als
Informationsbasis, für Anwendungen der verschiedensten Wirtschaftssektoren.
Durch die immer stärker wachsende Komplexität der Datenquellen nimmt die
Bedeutung von Anfragesprachen immer mehr zu. Sie bieten eine effiziente und
schnelle Variante, die Informationen zu extrahieren, die für den aktuellen
Prozess benötigt werden. Aktuell existiert im Umfeld von Topic Maps die
Abfragesprache Tolog, welche mangels Komplexität und Aussagekraft
aktuellen Anwendung unterlegen ist und den gewünschten Funktionsumfang
nicht mehr ausreichend abdecken kann. TMQL soll dieses Defizit lösen und
einen ähnlich hohen Stellenwert einnehmen, wie SQL. Im Rahmen dieser Arbeit
wird sich zeigen ob TMQL die Erwartung erfüllen kann. Ziel ist die Entwicklung
einer ersten prototypischen TMQL-Engine, sowie die Diskussion aktueller
Kritikpunkte des Drafts.
Inhaltsverzeichnis
Inhaltsverzeichnis ................................................................................................ I
Glossar ............................................................................................................. IV
Tabellenverzeichnis .......................................................................................... VI
Abbildungsverzeichnis ..................................................................................... VII
Codeverzeichnis ............................................................................................. VIII
Abkürzungsverzeichnis ...................................................................................... X
Literatur- und Quellenverzeichnis ..................................................................... XI
1. Vorwort, Einleitung und Motivation .............................................................. 1

2. Grundlagen .................................................................................................. 5
2.1. Das Topic Maps Data Model – TMDM ................................................... 5
2.2. Common Topic Map Application Programming Interface – TMAPI ........ 8
2.3. Serialisierung und Deserialisierung von Topic Maps ........................... 10
2.3.1. Compact-Topic-Maps-Syntax – CTM ............................................ 11
2.3.2. XML-Topic-Maps-Syntax – XTM ................................................... 13
2.4. Semantisch ähnliche Sprachen ........................................................... 15
2.4.1. Structured Query Language – SQL ............................................... 15
2.4.2. RDF und SPARQL Protocol and RDF Query Language ............... 18
2.4.3. XML Path Language – XPath ........................................................ 19
3. Topic Maps Query Language - TMQL ....................................................... 20
3.1. Anforderungen und Anwendungsfälle für TMQL .................................. 20
3.2. Notation und Semantik......................................................................... 21
3.2.1. Token Level ................................................................................... 21
3.2.2. Canonical Level ............................................................................. 22
3.2.3. Non-Canonical Level ..................................................................... 23
3.3. Ontologie-Abhängigkeit einer TMQL-Umgebung ................................. 24
3.4. Elementare Sprachbestandteile ........................................................... 25
3.4.1. Literale .......................................................................................... 26
3.4.1.1. Item-Referenzen und deren Auflösung...................................... 27
3.4.2. Navigationsachsen ........................................................................ 28
3.5. Untersuchung wichtiger Produktionsregeln und Teilausdrücke ........... 30
3.5.1. Simple- und Composite-Content ................................................... 30
I
3.5.1.1. XML-Content........................................................................... 32
3.5.1.2. TM-Content ............................................................................. 33
3.5.2. Tupel und Tupelsequenzen – Tupel-Expression ........................... 34
3.5.2.1. Vergleich und Sortierungen von Tupeln und Sequenzen........ 35
3.5.2.2. Stringifying - Serialisierung von Tupeln .................................. 37
3.5.3. Value-Expression und Function-Invocations ................................. 37
3.5.4. Wahrheitsausdrücke – Boolean-Primitive und Expression ............ 38
3.6. Query-Ausdrücke ................................................................................. 39
3.6.1. Verarbeitungsmodell ..................................................................... 40
3.6.2. Variablen und Variablenbindung ................................................... 42
3.6.3. Path-Expression ............................................................................ 44
3.6.3.1. Projektion und Filterung .......................................................... 44
3.6.3.2. Predicate-Invocations ............................................................. 46
3.6.4. Select-Expression – der SQL-Style ............................................... 47
3.6.5. FLWR-Expression ......................................................................... 50
4. Vergleich zu anderen Anfragesprachen - Toma und Tolog ....................... 52
4.1. Tolog und die Parallelen zu TMQL ...................................................... 52
4.2. Toma und TMQL .................................................................................. 54
5. Analyse der Kritikpunkte des aktuellen Drafts............................................ 57
5.1. Kritikpunkt - Navigationsachsen........................................................... 57
5.1.1. Die atomify-Achse ......................................................................... 57
5.1.2. Die characteristics-Achse .............................................................. 61
5.1.3. Die types- und supertypes-Achsen................................................ 63
5.1.4. Die traverse-Achse ........................................................................ 64
5.2. Kritikpunkt – Komplexität des Draft und der Grammatik ...................... 66
5.2.1. Inkonsistenz durch Auflösung eines Item-Identifier ....................... 66
5.2.2. Diskussion um das Non-Canonical Level ...................................... 67
5.2.3. Kritikpunkt – Variablennamen ....................................................... 68
6. Entwurf und Implementierung der TMQL-Engine - TMQL4J ...................... 70
6.1. Verwendung von TMQL4J ................................................................... 70
6.2. Hohe Flexibilität durch Modularisierung ............................................... 71
6.3. TMQL-Laufzeitumgebung .................................................................... 71
6.4. Abgrenzung der TMQL4J-Module ........................................................ 73
6.4.1. Navigationsmodul – Achsenimplementierung mit der TMAPI........ 73
II
6.4.2. Vorverarbeitungsroutine ................................................................ 77
6.4.3. TMQL-Lexer .................................................................................. 78
6.4.4. TMQL-Parser und Baumgenerierung ............................................ 79
6.4.5. TMQL-Interpreter........................................................................... 82
6.4.6. TMQL-Ergebnisverarbeitungsroutine ............................................ 85
6.5. Visualisierungstool TMQL4JViz ........................................................... 87
7. Testkonzeption .......................................................................................... 89
7.1. Testframework JUnit ............................................................................ 89
7.2. CXTM-Exports ..................................................................................... 91
8. Ausblick ..................................................................................................... 93
8.1. Weiterentwicklungen ............................................................................ 93
8.2. Optimierungsansätze ........................................................................... 94
9. Schlusswort ............................................................................................... 97
III
Glossar
Binding Binding bezeichnet den Vorgang der Bindung einer Variable

an ihren konkreten Wert, während der Verarbeitung eines
TMQL-Ausdruckes, sowie den Zustand der Wertbindung.
Canonizer Als Canonizer wird ein spezielles Computerprogramm

bezeichnet, welche die Produktionsregeln der TMQL-
Grammatik vom Non-Canonical Level(NCL) auf das
Canonical Level(CL) reduziert.
Context Der Begriff Context im Rahmen einer TMQL-Verarbeitung

beschreibt den aktuellen Zustand aller Variablen, sowie der
zu verarbeitenden Topic Maps.
Content Der Oberbegriff des Content beschreibt die Menge von

Inhalten, welche durch die erfolgreiche Verarbeitung eines
TMQL-Query erzeugt werden können.
Direktive Zusätzliches Wissen über die Ontologie der Topic Maps

wird auch als Direktive bezeichnet und ist Bestandteil des
Environment.
Engine Der Begriff der Engine repräsentiert ein Softwareprodukt

zur Kapselung komplexer Abläufe und Funktionalitäten
Environment Als Environment wird die TMQL-Ontologie bezeichnet. Die

Modellierung dieser Ontologie wird ebenfalls als Topic
Maps realisiert und enthält vordefinierte Typen, Operation
etc.
Expression Jede definierte Produktionsregel von TMQL wird als

Expression bezeichnet. Eine Expression kann dabei aus
einer beliebigen Anzahl von Expression bestehen
IV
Pragma Als Pragma wird die Definition von TMQL-Systemvariablen
bezeichnet, welche den Verarbeitungsprozess der TMQL-
Engine beeinflussen.
Stack Der Begriff des Stack beschreibt ein Konzept der

Modellierung von Datenhaltung als Stapel. Ein direkter
Zugriff ist stets nur auf das oberste Element möglich.
Terminalsymbol Terminalsymbole von TMQL sind zusammenhängende

Folgen von alphanummerischen Zeichen, sowie einiger
Sonderzeichen ohne Leerzeichen.
Token Als Token wird ein Element des TMQL-Query bezeichnet,

welches durch das lexikalische Scannen entsteht. Im
Allgemeinen entspricht ein Token einem Terminalsymbol.
Tupel Ein Tupel beschreibt exakt die Menge zusammen-

hängender Ergebnissen einer TMQL-Anfrage. Inhalt eines
Tupel sind atomare Werte, sowie Topic-Maps-Elemente.
Tupelsequenz Eine zusammenhängende Menge von Tupeln wird auch als

Tupelsequenz bezeichnet. Eine Tupelsequenz beschreibt
exakt die Ergebnismenge des gesamten TMQL-Query.
V
Tabellenverzeichnis
Tabelle 1 - kleiner Vergleich des Funktionsumfanges von SQL und TMQL ...... 17
Tabelle 2 - verwendete Namensräume anderer Standards innerhalb der TMQL-
Ontologie ................................................................................................... 25
Tabelle 3 - Übersicht über die gültigen Atome des aktuellen Drafts, sowie deren
möglichen Wertausprägungen[13] ............................................................. 27
Tabelle 4 - Navigationsachsen von TMQL, basierend auf der Struktur einer
Topic Maps nach TMDM ............................................................................ 30
Tabelle 5 - Achsennamen von Toma ................................................................ 55
Tabelle 6 - TMQL4J-Laufzeitmessung mit JUnit ............................................... 90
VI
Abbildungsverzeichnis
Abbildung 1 - Abstraktion der Klassenhierarchie des TMDM[8] .......................... 6

Abbildung 2 - Ablaufdiagramm der Verarbeitung von Element-Referenzen
innerhalb eines TMQL-Prozessors ............................................................ 28
Abbildung 3 - schematische Darstellung des Verarbeitungsmodells von TMQL-
Anfragen .................................................................................................... 42
Abbildung 4 - Abstraktion des Verarbeitungsprozesses einer Select-Expression
................................................................................................................... 49
Abbildung 5 - Abstraktion des Verarbeitungsprozesses einer FLWR-Expression
................................................................................................................... 51
Abbildung 6 - Occurrence-Konzept des TMDM[8]............................................. 61
Abbildung 7 - Names-Konzept des TMDM[8] .................................................... 62
Abbildung 8 - Variant-Konzept des TMDM[8] .................................................... 62
Abbildung 9 - Architektur einer fiktivem Anwendung mit Verwendung von
TMQL4J ..................................................................................................... 71
Abbildung 10 - Abstraktion der TMQL4J-Prozesskette ..................................... 72
Abbildung 11 - UML Klassendiagramm der Komponente zur Navigation ......... 74
Abbildung 12 - UML-Klassendiagramm des TMQL4J-Preprocessing ............... 78
Abbildung 13 - UML Klassendiagramm des lexikalischen Scanners................. 79
Abbildung 14 - Visualisierung der generierten Struktur des TMQL-Ausdrucks . 80
Abbildung 15 - UML-Klassendiagramm der Parser-Bestandteile ...................... 82
Abbildung 16 - UML-Klassendiagramm der Variablenverarbeitung .................. 83
Abbildung 17 - UML-Klassendiagramm des TMQL-Interpreter ......................... 85
Abbildung 18 - UML-Klassendiagramm der Ergebnisverarbeitung ................... 86
Abbildung 19 - Visualisierungstool TMQL4JViz ................................................ 88
Abbildung 20 - Topic Maps als Verdeutlichung des Multi-Set-Problems ........... 95
VII
Codeverzeichnis
Codefragment 1 – Beispielcode für RTM zur Veranschaulichung der

Vereinfachung und Erweiterungen gegenüber TMAPI................................. 9
Codefragment 2 - CTM-Syntax zur Definition von Topics[11] ........................... 12
Codefragment 3 – Beispiel zur Verdeutlichung der Syntax eines CTM-Fragment
................................................................................................................... 12
Codefragment 4 - XSD des XML-Elements für Topics[9] .................................. 14
Codefragment 5 - XSD des XML-Elements für Assoziation[9] .......................... 14
Codefragment 6 - Syntax einer SQL-Select-Anweisung[30] ............................. 16
Codefragment 7 - Syntax einer TMQL-Select-Anweisung[13] .......................... 16
Codefragment 8 - RDF-Beispiel ........................................................................ 18
Codefragment 9 - SPARQL-Query.................................................................... 19
Codefragment 10 - Menge gültiger Zeichen für Terminalsymbole .................... 22
Codefragment 11 - Produktionsregel als Beispiel der Notationsanpassung für
beliebiges Vorkommen eines Terminalsymbols ......................................... 23
Codefragment 12 - Muster für Datumsformate gemäß XSD dateTime[26] ....... 26
Codefragment 13 - Produktionsregeln für Simple-Content ............................... 31
Codefragment 14 - Produktionsregeln für Composite-Content ......................... 31
Codefragment 15 - Beispiel zur Abgrenzung der Content-Typen...................... 32
Codefragment 16 - Non-Canonical Regelsatz für Composite-Content.............. 32
Codefragment 17 - Untermenge der Prädikatenformeln von XML-Content ...... 32
Codefragment 18 - Produktionsregel eines TM-Content ................................... 33
Codefragment 19 - TMQL-Anfrage zur Verdeutlichung der Terminologie Tupel
und Tupelsequenz ..................................................................................... 35
Codefragment 20 - Tupel-Expression als Beispiel für Sortieroperation............. 36
Codefragment 21 - Select-Expression als Beispiel für Sortierung bei
Tupelkombination ...................................................................................... 36
Codefragment 22 - Value-Expression ............................................................... 37
Codefragment 23 - Function-Invocations .......................................................... 38
Codefragment 24 - Boolean-Expression und Primitive ..................................... 39
Codefragment 25 - Verwendung von Quantifizierungsoperatoren .................... 39
Codefragment 26 - Filterdefinition ..................................................................... 45
VIII
Codefragment 27 - spezielle Produktionsregeln für Filterdefinition auf dem Non-
Canonical Level ................................................................................................ 45
Codefragment 28 - Beispiel für eine Kombination von Projektion und Filtern ... 45
Codefragment 29 - Produktionsregel und Beispiel einer Predicate-Invocation . 46
Codefragment 30 - spezielle Predicate Invocation für Typ-Instanz- und
Supertyp-Subtyp-Beziehung ...................................................................... 47
Codefragment 31 - Grammatikregel der Select-Expression .............................. 47
Codefragment 32 - Grammatikregel des FLWR-Style....................................... 50
Codefragment 33 - einfacher Tolog-Query ....................................................... 52
Codefragment 34 - Verknüpfung von Prädikaten in Tolog ................................ 53
Codefragment 35 - Select-Style von Tolog ....................................................... 53
Codefragment 36 - Select-Style von Toma mit einem simplen Beispiel ............ 54
Codefragment 37 - Konzept der Verkettung von Spielern................................. 55
Codefragment 38 - XSD-Definition der Abbildung von Java-Datentypen auf
XSD-Datentypen ........................................................................................ 59
Codefragment 39 - manuelle Typdefinition innerhalb eines TMQL-Ausdruck[13]
................................................................................................................... 60
Codefragment 40 - Definition zweier Assoziationen.......................................... 65
Codefragment 41 - TMQL-Navigation und mögliche Ergebnismengen ............. 66
Codefragment 42 - Mehrdeutigkeit innerhalb des NCL am Beispiel zweier
Grammatikregeln ....................................................................................... 67
Codefragment 43 - Kritik an der semantische Bedeutung der nachstehenden
Anführungszeichen in Variablennamen ..................................................... 69
Codefragment 44 - Kritik an der semantischen Bedeutung von Präfixen in
Variablennamen......................................................................................... 69
Codefragment 45 - Realisierung der locators Achse auf Basis der TMAPI 2.0 . 75
Codefragment 46 - TMQL-Query und Ergebnissequenzen für Multi-Set-
Problematik ................................................................................................ 95
IX
Abkürzungsverzeichnis
Abkürzung Bedeutung
API Application Programming Interface
BNF Backus-Naur-Form
CTM Compact Topic Maps Syntax
CXTM Canonical XTM
DC Dublin Core
DCL Data Control Language
DDL Data Definition Language
DML Data Manipulation Language
DOM Document Object Model
IEC Internationale Elektrotechnische Kommission
IRI Internationalized Resource Identifier
ISO International Standards Organisation
JDBC Java Database Conectivity
RDF Resource Description Framework
RegExp Regular Expression
RTM Ruby Topic Maps
SAX Simple API for XML
SQL Structured Query Language
SVG Scalable Vector Graphics
TMAPI Common Topic Map Application Programming Interface
TMCL Topic Maps Constraint Language
TMDM Topic Maps Data Model
TMML Topic Maps Modification Language
TMQL Topic Maps Query Language
URL Uniform Resource Locator
XML Extensible Markup Language
XML Infoset XML Information Set
XPath XML Path Language
XSD XML Schema Definition
XTM XML Syntax for Topic Maps
X
1. Vorwort, Einleitung und Motivation
In der aktuellen Entwicklung von Portalen und Webanwendungen gewinnt das

Datenmodell von Topic Maps, als Repräsentierung der Ontologie bzw.
Wissensstruktur, immer mehr an Bedeutung. Die Modellierungstechnik von
Topic Maps, als Realisierung des aussagengegenstandszentrierten
Modellierungsparadigma, ermöglicht in effizienter und aussagekräftiger Art und
Weise die Modellierung der realen Welt auf einer beliebigen Abstraktionsebene.
Die Verwendung von Topic Maps als Modellierungsmethodik für Daten und
Wissen begründet sich in verschiedenster Weise. „Topic Maps stellt das einzige
Modell dar, welches für Menschen optimiert ist und nicht nur für Maschinen“1
und ermöglicht somit eine leichte und komfortable Modellierung der
Datenstrukturen. Zusätzlich erhöht das starke Rollenkonzept des Datenmodells
die Intuition bei der Benutzung der darüber liegenden Webanwendungen und
Softwareprodukte. Ein Nebenprodukt des starken Beziehungsmodells ist die
grobe Beschreibung der Navigationsstruktur des zu entwickelnden Portals und
die Vereinheitlichung des Verständnisses zwischen Informationssicht und
Anwendersicht. Das Topic-Maps-Datenmodell eignet sich somit in effizienter
und optimaler Weise für die Implementierung von Webanwendungen.
Je nach funktionalen und nicht-funktionalen Anforderungen existieren

zahlreiche Topic-Maps-Engines, welche die Verwendung der
Modellierungsmethodik mit modernen Programmiersprachen, wie Java und
Ruby, ermöglichen, unterstützen und erleichtern. Die meisten basieren auf
einheitlichen Schnittstellen, was die Austauschbarkeit des Backends
vereinfacht.
Ein Hauptproblem moderner und innovativer Anwendungen ist die zunehmende

Komplexität der Datenbasis. Im Bereich Cloud Computing ist die Klärung und
Analyse dieses Problems Bestandteil des Designkonzeptes. Je komplexer und
umfangreicher die Datenbasis einer Anwendung wird, desto höher ist der
potentielle Nutzen moderner Datenanfragesprachen, wie SQL im Bereich
1
Zitat: Benjamin Bock aus [24]
1
relationaler Datenbanksysteme. Im Bereich Topic Maps existiert aktuell nur der

Tolog-Standard, welcher auf Basis Prolog-artiger Abfragen, den Zugriff auf
Daten innerhalb einer Topic Maps ermöglicht. Tolog besitzt aber nur den
Umfang einiger rudimentärer Abfragen und kann die komplexen Strukturen des
TMDM nicht komplett widerspiegeln und bietet somit nicht die kompletten
Vorteile moderner Abfragesprachen. Aus genannten Gründen wurde eine
Sprache entwickelte, die sich eng am TMDM orientieren soll und die Abfrage
komplexer Beziehungen zwischen Objekten in Topic Maps ermöglichen und vor
allem wesentlich vereinfachen soll. Begründet durch die Modellierung und
Anlehnung an das TMDM und anderen Topic-Maps-Standards, wie TMCL,
weist TMQL eine wesentlich höhere Aussagekräftigkeit als Tolog auf. Aktuell
befindet sich TMQL innerhalb des ISO-Standardisierungsprozess, in dessen
Rahmen einige Kritikpunkte des aktuellen Drafts analysiert und gegebenenfalls
angepasst werden.
Ziel von TMQL ist die Realisierung einer mächtigen Sprache, wie SQL, im
Topic-Maps-Umfeld. TMQL ermöglicht die Verwendung und Handhabung sehr
großer Datenquellen in einfacher Weise, bietet effiziente Werkzeuge zur
Abfrage komplexer Beziehungen zwischen Informationselementen und
reduziert somit die Anzahl der benötigten Abfragen an die Datenbasis auf ein
Minimum. Die Sprache TMQL besitzt das Potential eine Bedeutung wie SQL zu
gewinnen und die Verwendung von Topic-Maps-Engines zu erleichtern und zu
optimieren, sowie den Zugriff auf ein konkretes Datenbackend transparent zu
gestalten. Dem Nutzer wird somit die Möglichkeit gegeben, die gewünschten
Informationen ohne Verständnis der internen Topic-Maps-Datenstrukturen zu
extrahieren und zu verwenden, sowie wichtige Abfragen vorhalten zu können,
um die Effizienz seiner Anwendung weiter optimieren zu können.
1.1. Zielstellung und Abgrenzung der Thematik
Zielstellung dieser Arbeit ist die Analyse des aktuellen Draft des TMQL-
Standards mit dem Ziel der Konzeption und Entwicklung einer TMQL-Engine.
Hintergrund der Analyse ist detaillierte Auseinandersetzung mit der Grammatik
von TMQL, sowie der syntaktischen Sprachelemente und deren semantischer
2
Verarbeitungen und Bedeutungen. Zusätzlich werden die wichtigsten

Diskussions- und Kritikpunkte des aktuellen Draft angesprochen und einige
Lösungsvorschläge aufgeführt und analysiert.
Ergebnisse dieser Analyse bilden die Grundlage des Entwurfes und der
späteren Implementierung der TMQL-Engine, sowie deren einzelnen
Komponenten.
Die resultierende Implementierung stellt primär eine prototypische Basis zur

späteren Anpassung an den finalen Standard von TMQL dar und stellt keinen
Anspruch auf Vollständigkeit gegen den aktuellen Draft. Die Implementierung
einiger Sprachbestandteile, wie TM- und XML-Content, sind beispielsweise
nicht Bestandteil des Prototyps und folglich auch nicht Gegenstand dieser
Arbeit.
1.2. Vorgehensweise
Um ein Verständnis der Terminologie von TMQL zu erhalten, werden im ersten

Kapitel, wichtige Standards der Topic-Maps-Standardfamilie betrachtet. Ziel
dieser Betrachtung ist die Einordnung von TMQL in diese Familie, sowie das
Verständnis einiger fundamentaler Bestandteile von TMQL. Ferner werden
semantisch und syntaktisch ähnliche Sprachen, wie SQL und SPARQL
betrachtet, um einen semantischen Vergleich mit TMQL zu ermöglichen.
Aufbauend auf den Grundlagen folgt die im Kapitel 3 angesprochene Analyse

des TMQL-Drafts, seiner Grammatik und der wichtigsten Sprachelemente und
Produktionsregeln. Dabei werden einige Kritikpunkte bereits kurz angerissen
um einen Ausblick auf die spätere Analyse wichtiger Diskussionspunkte zu
bieten. Im folgenden Kapitel wird ein direkter Vergleich zu bestehenden
Anfragesprachen im Topic-Maps-Umfeld angestrebt, um Parallelen aber auch
Unterschiede zwischen den Sprachen aufzuzeigen und den Mehrwert von
TMQL gegenüber diesen Sprachen abzubilden.
3
Kapitel 5 setzt sich kritisch mit den bereits angerissenen Diskussions- und
Kritikpunkten des aktuellen Draft, sowie daraus resultierenden Entwurfs- und
Implementierungsproblemen auseinander. Ferner werden aktuelle
Lösungsvorschläge aufgezeigt und diskutiert, sowie die verwendende Lösung
der TMQL-Engine benannt.
Zielstellung der Kapitel 2 bis 5 ist das fundierte Verständnis der Sprache TMQL,
deren Abgrenzung zu anderen Sprachen, sowie die Analyse von
Problemstellungen, welche im Rahmen des aktuellen Drafts entstehen. Dieses
fundierte Verständnis der Terminologie bildet die Grundlage des Entwurf, sowie
der Umsetzung der TMQL-Engine. Inhalt des Entwurfs ist die Betrachtung der
eingesetzten Softwaretechnologie, der Komponentenentwicklung bzw.
Modularisierung, sowie die Abgrenzung und Umsetzung der einzelnen
Komponenten der Engine.
Das vorletzte Kapitel befasst sich mit der Analyse der eingesetzten
Testverfahren, sowie der detaillierten Betrachtung der, im Rahmen der
Implementierung, eingesetzten Testansätze JUnit und CXTM.
Im letzten Kapitel wird ein Ausblick auf Weiterentwicklungen gegeben. Dabei

werden einige Optimierungsansätze des aktuellen Prototyps betrachtet und
vorgestellt.
Ziel dieser Arbeit ist die detaillierte Auseinandersetzung mit dem aktuellen Draft
hinsichtlich der Modellierung gemäß dem TMDM, der fundamentalen
Sprachkonzepte, sowie der größten Schwächen des kommenden Standards.
Inhalt der Arbeit ist neben der Analyse und Diskussion von Problemen und
Kritikpunkten, die Implementierung eines rudimentären Parsers und Interpreters
für TMQL-Abfragen auf Basis der TMAPI.
4
2. Grundlagen
2. Grundlagen
Die aktuelle Spezifikation von TMQL nimmt Bezug auf eine Zahl existierender
Standards aus dem Bereich Topic Maps und anderer Industriezweige und
Technologien. Ein grober Blick auf diese Standards ist grundlegend für das
Verständnis der Problemstellung und von TMQL.
2.1. Das Topic Maps Data Model – TMDM
Der Zugriff der Daten, sowie die Modellierung einzelner Ausdrücke in TMQL,
orientieren sich stark am Topic-Maps-Datenmodell. Um die Konzepte innerhalb
von TMQL verstehen zu können, ist eine Analyse der Konzepte des TMDM
grundlegend.
Das TMDM spezifiziert das Datenmodell einer Topic Maps und definiert die
abstrakte Struktur und Beziehung als Elemente von Topic Maps auf Basis einer
Menge von Regeln und Formalismen. Das Metamodell des ISO-Standards
13250 entspricht dem Metamodell vom XML Information Set, kurz XML Infoset.
Per Definition des Metamodells enthält jede Instanz des TMDM eine Menge von
Informationselementen, welche im Kontext von Topic Maps, jedes für sich ein
konkretes Element innerhalb einer Topic Maps beschreiben. Jedes
Informationselement besitzt, neben einer eindeutigen Identität, eine definierte
Menge benannter Attribute, welche über ihren abstrakten Informationstyp
(Information Type) spezifiziert werden. Abbildung 1 abstrahiert die
Klassenhierarchie von Information Typs des TMDM.
5
2. Grundlagen
Abbildung 1 - Abstraktion der Klassenhierarchie des TMDM[8]
Die eindeutige Identität eines Informationselements, auch Topic genannt,

innerhalb des TMDM definiert sich über eine Menge von Subject-Identifier,
Subject-Locator und Item-Identifier. Faktisch existieren somit zu keinem
Zeitpunkt zwei Informationselement mit demselben Identifier, andernfalls
müssen die entsprechenden Informationselemente, anhand definierter Regeln,
zu einem neuen Informationselement verschmolzen werden. Das daraus
resultierende Informationselement erbt alle Identifier und enthaltenen Elemente
der Ausgangsobjekte.
Unter dem Begriff der Informationselemente bzw. Topic-Maps-Elemente

definiert das TMDM die Elemente Topics, Topic Maps, Assoziation, Occurrence
und Namen. Topic Maps besitzen als einziges Informationselement keine
semantische Bedeutung oder kein Bezug auf die reale Welt, sondern stellen
einen Container für eine Menge von Topics und Assoziationen dar. Die
Reifikation stellt die einzige Möglichkeit dar, Informationen über das
korrespondierende Element der Topic Maps zu beschreiben. Das Konzept der
Reifikation wird im späteren Verlauf dieses Kapitels genauer betrachtet.
Kernkonzept des aussagegegenstandszentrierten Modellierungsparadigma, als

theoretische Basis des TMDM, ist die Repräsentierung von Subjekten der
realen Welt bzw. von Subjekten mit einer unverwechselbaren Charakteristik.
Die Repräsentierung dieser Subjekte erfolgt innerhalb des Datenmodells durch
Topics. Ein Topic ist dabei immer Instanz, des abstrakten Topic TopicType. Im
6
2. Grundlagen
Gegensatz zur Objektorientierung kann ein Topic gleichzeitig Instanz

verschiedener Typen und selber Typ anderer Instanzen sein. Ein Beispiel
hierfür sei das Topic Stadt, welches Instanz des Typs TopicType ist, aber auch
als Typ der Instanz Leipzig agiert.
Topics enthalten eine Menge von Occurrences und Namen, welche je nach
Interpretation der Rolle eines Topics verschiedene Bedeutungen umfassen, so
definiert ein Typ A die Menge von Occurrences und Namen, welche alle
Instanzen des Typs besitzen müssen. Instanzen hingegen besitzen stets
konkrete Wertausprägungen für die enthaltenen Namen und Occurrences. So
definiert der Typ Stadt beispielsweise eine Occurrence für seine Einwohnerzahl,
besitzt selber aber keinen Wert dafür. Das Topic Leipzig als Instanz beinhaltet
hingegen die konkrete Wertausprägung dieser Eigenschaft von ca. 515 000
Einwohnern.
Die Informationselemente Occurrences und Namen, definieren eine Menge von

Eigenschaften der konkreten Topics. Occurrences beschreiben eine beliebige
Informationsressource und besitzen einen entsprechenden Datentyp zur
Charakterisierung der Ressource. Namen stellen eine besondere Form von
Eigenschaften dar und werden als menschliche Benennung für das jeweilige
Informationselement verwendet. Sie können verschiedene Ausprägungen
besitzen, welche als Varianten bezeichnet werden.
Beziehungen zwischen konkreten Subjekten der realen Welt werden als

Assoziationen modelliert. Ein konkretes Topic bzw. eine Instanz spielt dabei
immer eine definierte Rolle innerhalb einer Instanz dieser konkreten
Assoziation. Instanzen einer Assoziation werden auch als Association Item
bezeichnet. Assoziation können eine beliebige Anzahl von Rollenspielern und
Rollentypen umfassen. Vordefinierte Assoziation des TMDM modellieren den
Typ-Instanz-Beziehung und die Supertyp-Subtyp-Beziehung.
Zusätzliche Konzepte des TMDM sind die bereits angesprochene Reifikation,

sowie das Konzept des Scope.
7
2. Grundlagen
Als Reifikation wird der Prozess der Erstellung eines neuen Topics bezeichnet,
welches kein Subjekt der realen Welt repräsentiert, sondern als Repräsentation
eines anderen Topic-Maps-Elementes derselben Topic Maps agiert. Folglich
kann jedes Topic-Maps-Element reifiziert werden, mit Ausnahme von Topics
selber, da die Reifikation eines Topic semantisch gleichbedeutend mit der
Erzeugung zweier Topics für denselben Gegenstand wäre, welche automatisch
verschmolzen werden müssten. Das Konzept der Reifikation ermöglicht somit
die Definition zusätzlicher Informationen über eine Struktur oder ein Element
innerhalb der Topic Maps mit Ausnahme von Topics.
Jedes Topic-Maps-Element kann einen Scope besitzen. Der Scope definiert

den Gültigkeitsbereich, unter dessen Bedingung die Aussage als gültig
angesehen wird.
2.2. Common Topic Map Application Programming Interface – TMAPI
Das Common Topic Map Application Programming Interface, kurz TMAPI, stellt
den aktuellen De-facto-Standard zur Implementierung und von Topic-Maps-
Engines dar. Die TMAPI spezifiziert eine Menge von Schnittstellen für den
Zugriff und die Manipulation von Daten beliebiger Topic-Maps-Backends, wie
SQL-Datenbanken oder In-Speicher-Lösungen und abstrahiert stark von der
darunterliegenden Datenhaltung.
„TMAPI hopes to do for topic maps what SAX and DOM did for XML”2, dieses
Zitat der TMAPI-Community beschreibt kurz und prägnant die Idee hinter der
Programmierschnittstelle. Aktuell existieren eine Menge proprietäre, aber auch
freie Engines, welche alle ihre eigenen Schnittstellen besitzen, was eine
Portierung von Softwarecodes erschwert oder gar unmöglich macht. Durch
Verwendung einer einheitlichen Schnittstelle soll dieses Problem gelöst werden.
„Die TMAPI ist dabei allerdings bewusst kein ISO-Standard“, so die Meinung
von Robert Barta (Entwickler von TMAPI und Topic-Maps-Experte). Seiner
Auffassung nach würde der Prozess der ISO-Standardisierung den schnellen
2
Zitat aus [23]
8
2. Grundlagen
Integrationsprozess der TMAPI in die Topic-Maps-Community und somit die

hohe Verbreitung der TMAPI als De-facto-Standard behindern oder verzögern.
Gegenüber dieser Meinung steht die Frage, ob eine Standardisierung der
TMAPI als Mindeststandard für Topic-Maps-Engines nicht die Entwicklung von
Topic-Maps-Anwendungen begünstigen würde. Die Bindung an einen
Mindestumfang an Funktionalitäten aller Topic-Maps-Engines könnte die
Verwendung beliebiger Topic-Maps-Engines in äquivalenter Weise
ermöglichen. Dies führe eventuell zur Reduktion von Entwicklungskosten, sowie
zur Sicherung von Investitionskosten, da eine entwickelte Anwendung in
erhöhtem Maße von der Topic-Maps-Engine unabhängig wäre.
Aktuell erfüllt eine Vielzahl der Topic-Maps-Engines die Testfälle der TMAPI
1.0, welche die volle und korrekte Funktionalität auf Basis der Schnittstelle und
die Kompatibilität sicher stellen. Die sich aktuell im Alpha-Status befindliche
TMAPI 2.0 wird noch von wenigen Engines unterstützt, da einige Bestandteile
noch nicht zu einhundert Prozent spezifiziert und integriert sind.
Eine der bekanntesten Umsetzung der TMAPI 2.0 ist die Ruby-Topic-Maps-
Engine (RTM). Dabei bietet RTM neben dem angesprochen Minimalumfang der
TMAPI weitere hilfreiche Funktionen und Methoden, welche die Verwendung
von Topic-Maps-Engines weiter vereinfacht und effizienter gestaltet. Anders als
durch die TMAPI spezifiziert, ermöglicht RTM die Verwendung von
Zeichenketten als IRI-Repräsentation der Identifier von Topics, als Parameter
jeder Funktionen der TMAPI. Die TMAPI sieht an diesen Stellen einzig die
Verwendung der Klasse Locator vor, wodurch der Aufruf einer weiteren
Funktion zur Erzeugung eines Locator bedingt wird. Ferner ermöglicht RTM den
direkten Zugriff auf Namen und Occurrences per Hash-Access oder Array-
Syntax und abstrahiert weiter von der TMAPI.
leipzig = topicmap.get!(„leipzig“)
population = leipzig[„population“]
Codefragment 1 - Beispielcode für RTM zur Veranschaulichung der Vereinfachung und

Erweiterungen gegenüber TMAPI
9
2. Grundlagen
Die aktuellste Version von RTM unterstützt zusätzlich einen TMQL-Modus zur
Simulation der TMQL-Achsen. Dieser Modus ermöglicht die Verwendung der
TMQL-Achsen als Methoden der einzelnen Objekte der TMAPI, bildet allerdings
nicht die komplette syntaktischen Möglichkeiten des TMQL-Drafts ab, sondern
bezieht sich lediglich auf die TMQL-Achsen.
2.3. Serialisierung und Deserialisierung von Topic Maps
Der aktuelle TMQL-Draft spezifiziert Möglichkeiten zur Generierung von Topic-

Maps- und XML-Fragmenten durch Verwendung spezieller Ausdrücke im
Rahmen einer TMQL-Anfrage. Die konkreten Ausdrücke werden in dem
entsprechenden Kapitel (3.5.1.1 und 3.5.1.2) genauer analysiert und
beschrieben, es sei allerdings an dieser Stelle erwähnt, dass die Definition
dieser Ausdrücke auf vorhandenen Serialisierungsmethoden, innerhalb der
Topic-Maps-Standardfamilie, basieren. Ein kurzer Einblick in die verwendeten
Serialisierungverfahren ist aus Gründen einer syntaktischen Überschneidung zu
TMQL sinnvoll. Ziel der Betrachtung ist ein grundlegender Überblick über die
beiden Standards.
Durch Überführung eines Datenbestandes der konkreten Datenbasis in CTM

oder XTM, auch Serialisierung genannt, kann ein plattformunabhängiger
Austausch von Informationen zwischen Topic-Maps-Anwendungen realisiert
werden. Der Umkehrprozess zur Erzeugung der konkreten Datenbasis auf
Basis des CTM- oder XTM-Dokumentes wird Deserialisierung genannt,
Die genaue Realisierung des Prozesses der Serialisierung bzw.

Deserialisierung wird nicht weiter betrachtet, da diese für das Erreichen des
Zieles dieser Arbeit keine direkte Bedeutung besitzen. An dieser Stelle sei nur
erwähnt, dass die Repräsentierung der Topic-Maps-Elemente in die Instanzen
der entsprechenden Informationselemente des TMDM (2.1) überführt werden.
Innerhalb des Prozesses werden alle Attribute (Occurrences und Namen)
einem entsprechenden Konstrukt zugeordnet und alle Topics
zusammengeführt, welche das gleiche Subjekt referenzieren. Verstöße gegen
10
2. Grundlagen
das TMDM bzw. die verwendete Syntax (CTM oder XTM) führen während des
Prozesses zu einem Fehler.
2.3.1. Compact-Topic-Maps-Syntax – CTM
Die Compact-Topic-Maps-Syntax (CTM) stellt eine auf Text basierte, kompakte

und menschenlesbare Notation zur Beschreibung von Topic Maps zur
Verfügung und definiert zusätzlich eine einheitliche Syntax für TMCL und
TMQL. Die Syntax von CTM umfasst spezifische Elemente zur Beschreibung
jedes TMDM-Konstrukts. Eine Ausnahme dessen stellt die Definition eines
Item-Identifier für Topic-Maps-Elemente dar, welche kein Topic sind.
Jedes CTM-Dokument beschreibt dabei immer genau eine konkrete Topic

Maps, folglich erfolgt die Beschreibung einer Topic Maps indirekt per Definition
der enthaltenen Elemente. CTM besitzt daher keine Syntax zur Beschreibung
und Definition von Topic Maps innerhalb des Dokumentes.
Das Konstrukt zur Definition von Topics kann neben einer Menge von
eindeutigen Identifier, optional eine Menge von Occurrences, Namen, Typ-
Instanz-Beziehungen und Supertyp-Subtyp-Beziehungen enthalten. Die
Verwendung spezifischer vorangestellter Zeichen innerhalb der IRI spezifiziert
die Art des Identifier. Ein Subject-Locator wird durch das Gleichheitszeichen
und ein Item-Identifier durch das Zeichen (^) modelliert. Die Schlüsselwörter isa
bzw. ako repräsentieren eine Typ-Instanz- bzw. eine Supertyp-Subtyp-
Beziehung. Einige der spezifizierten Zeichen finden auch im Rahmen des
Navigationskonzeptes von TMQL (3.4.2) Anwendung.
Die folgende Produktionsregel spezifiziert die Definition eines Topics unter

Verwendung der CTM-Syntax und soll den eben angerissenen Sachverhalt
noch einmal verdeutlichen.
11
2. Grundlagen
topic ::= topic-identity topic-tail* '.'

topic-tail ::= identity | assignment | topic-template-invocation |
instance-of | kind-of ';'
identity ::= subject-identifier | subject-locator | item-identifier
assignment ::= name | occurrence
instance-of ::= 'isa' topic-ref
kind-of ::= 'ako' topic-ref
Codefragment 2 - CTM-Syntax zur Definition von Topics[11]
Als Beispiel sei folgendes CTM-Fragment zur Definition eines Topics für die
Stadt Leipzig genannt, sowie die Definition der Occurrence für die
Einwohnerzahl.
http://www.leipzig.de isa city;

– „leipzig“;
population: 51500^^xsd:integer.
Codefragment 3 – Beispiel zur Verdeutlichung der Syntax eines CTM-Fragment
Namen und Occurrences werden durch Verwendung das entsprechende CTM-

Konstrukt definiert. Die Definition von Namen erfolgt durch ein führendes
Minuszeichen, gefolgt von einem optionalen Typ, sowie die konkrete
Wertausprägung repräsentiert durch eine Zeichenkette. Varianten des Namens,
werden als Menge von Zeichenketten in Klammern hinter dem Konstrukt
spezifiziert. Die Definition von Occurrences basiert auf ähnlichen Mustern mit
der Ausnahme, der zwingenden Typangabe.
Die Beschreibung von Assoziation erfolgt durch Angabe des Typs, sowie eine
Menge von Rollentyp-Spieler-Beziehungen. Rollentypen und Spieler werden
über einen Topic-Identifier repräsentiert, die konkrete Beziehung zwischen
Rollentyp und Spieler durch Doppelpunkt beschrieben. Die Position der
Leerzeichen ist dabei nahezu frei, mit Ausnahme der Regel, dass mindestens
ein Leerzeichen vor oder nach dem Doppelpunkt eingefügt werden muss. Diese
Syntax wird auch von TMQL verwendet, die genaue Beschreibung erfolgt in
dem entsprechenden Kapitel (3.6.3.2).
12
2. Grundlagen
2.3.2. XML-Topic-Maps-Syntax – XTM
Die XML-Topic-Maps-Syntax (XTM) ist ein XML basiertes Austauschformat für

Topic Maps. Die Notation und Syntax von XTM stellt im Gegensatz zu CTM
keinen Anspruch an Menschenlesbarkeit und maschinenfreie Modifizierbarkeit.
Mit der Version 2.0 wurden einige Modellierungskonzepte der Vorgängerversion
1.0 modifiziert. Im Gegensatz zu XTM 1.0 nutzt der aktuelle Standard kein
XLink oder XML Base mehr. Weiter wurden einige Attribute aus XML-Knoten
des XTM 1.0 Standards entfernt oder durch andere ersetzt. Eine vollständige
Übersicht über die Unterschiede beider Versionen ist unter [9] aufgeführt.
Während der Serialisierung, gemäß dem XTM-Standard, wird jedes

Informationselement des TMDM in eine eindeutige XML-Repräsentierung
überführt. Der umgekehrte Prozess ermöglicht die Generierung der Topic Maps
auf Basis der XML-Repräsentierung. Inhaltlich behandelt der aktuelle Draft nur
den Prozess der Deserialisierung einer XTM-Instanz in eine TMDM-Instanz. Der
Serialisierungsprozess wird nur implizit beschrieben, es besteht einzig die
Anforderung, dass die Serialisierung in dem Maße zu realisieren ist, dass auf
Basis des beschrieben Prozesses, die generierte Topic Maps identisch zur
Ursprungsinstanz ist.
Die Beschreibung des XML-Schema, einer XTM-Instanz, erfolgt wahlweise mit

XSD oder einer DTD. Die Definition einer Informationsressource des TMDM
erfolgt über die gleichnamigen XML-Elemente. Die Struktur der enthaltenen
Kinderelemente einer solchen XML-Repräsentierung orientiert sich ebenfalls
stark an der erlaubten Struktur des TMDM. Zur Veranschaulichung des
Sachverhaltes sei die Repräsentierung einer Topic Instanz genannt.
13
2. Grundlagen
<xs:element name="topic">
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="itemIdentity"/>
<xs:element ref="subjectLocator"/>
<xs:element ref="subjectIdentifier"/>
</xs:choice>
<xs:element ref="instanceOf" minOccurs="0" maxOccurs="1"/>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="name"/>
<xs:element ref="occurrence"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
Codefragment 4 - XSD des XML-Elements für Topics[9]
Der XSD-Typ für ein Topic besitzt, wie die Informationsressource des TMDM,
eine Menge von Occurrences und Namen, sowie eine Menge eindeutiger
Identifier zur Repräsentierung des beschrieben Gegenstandes. Typ-Instanz
Informationen des Topics werden über den instance-of Block definiert, welcher
eine Menge von Referenzen auf definierte Topic-XML-Elemente beinhaltet.
Als Realisierung des fundamentalen Beziehungskonzeptes zwischen Topics

erscheint ein weiterer Blick auf die Informationsressource einer Assoziation als
relevant. Die Definition erfolgt wieder als komplexer XSD-Typ
<xs:element name="association">
<xs:complexType>
<xs:sequence>
<xs:element ref="itemIdentity" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="type"/>
<xs:element ref="scope" minOccurs="0"/>
<xs:element ref="role" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="reifier" type="xs:anyURI"/>
</xs:complexType>
</xs:element>
Codefragment 5 - XSD des XML-Elements für Assoziation[9]
Neben der eindeutigen Identität der Instanz der Assoziation, sowie dem Bezug
auf einen Assoziationstyp, definiert der komplexe Typ eine Menge von Rollen
sowie Topics zur Repräsentierung des Scope der Assoziation. Der Rollentyp
14
2. Grundlagen
beinhaltet eine Sequenz von Identifiern, Typen und einer Referenz auf den
konkreten Spieler dieser Rolle.
Alle reifizierbaren Informationsressourcen können das optionale reifier Attribut

enthalten, welches als Wert einen Verweis auf das reifizierende Topic besitzt.
Die XML-Repräsentierung aller anderen Informationsressourcen des TMDM ist
nahezu intuitiv und kann im entsprechenden Kapitel des Standards
nachgeschlagen werden.
2.4. Semantisch ähnliche Sprachen
Zur exakten Einordnung von TMQL empfiehlt sich die Betrachtung existierender
und inhaltlich ähnlicher Standards. Als wichtigste Standards in diesem Bereich
sind SQL als Abfrage- und Manipulationssprache für relationale Datenbanken,
sowie SPARQL für RDF und XPath für XML anzusehen. Die Sprachen
SPARQL und XPath werden dabei nur kurz angerissen.
2.4.1. Structured Query Language – SQL
Die Betrachtung von SQL als Abfrage- und Manipulationssprache für relationale
Datenbanken im Vergleich zu TMQL erscheint als sinnvoll unter der Annahme,
dass TMQL sich als wichtigstes Ebenbild von SQL im Bereich Topic Maps
etablieren wird. Ziel der Betrachtung ist die Abgrenzung des
Funktionsumfanges von TMQL im Vergleich zu SQL. Dabei werden einzelne
funktionale Bestandteile von SQL unter dem Gesichtspunkt einer Übernahme in
den aktuellen TMQL-Draft analysiert. Eine solche Untersuchung erscheint als
sinnvoll, da sich SQL bereits seit 23 Jahren als Standard behauptet und in
einem jahrelangen Anpassungsprozess durch Zusammenarbeit einer großen
Community einen hohen Grad an Vollständigkeit, Konsistenz und
Verwendbarkeit aufweist.
Funktional bietet SQL eine mächtige Sprache zur Definition von

Datenstrukturen nach der relationalen Algebra (Data Definition Language -
DDL), zur Abfrage von Daten, sowie zur Manipulation von Datensätzen (Data
15
2. Grundlagen
Manipulation Language - DML). Ein weiterer fundamentaler Bestandteil von

SQL ist die Rechteverwaltung und Transaktionskontrolle (Data Control
Language - DCL). Aktuell bildet der TMQL-Draft nur einen Bruchteil dieser
Funktionalitäten ab und orientiert sich im Bereich der DML, dies ist aber nur
beschränkt auf die Abfrage von Datensätzen (Topic-Maps-Elementen). Die
Manipulation von Datenstrukturen wird eventuell durch den zukünftigen TMML-
Standard abgedeckt oder als Erweiterung von TMQL umgesetzt. Das
Gegenstück zur DDL im Kontext von Topic Maps stellt der TMCL-Standard dar.
Die Funktionalität der DCL wird aktuell von keinem Standard im Bereich Topic
Maps abgebildet.
Syntaktisch orientiert sich SQL stark an der englischen Umgangssprache und

erleichtert somit das Verständnis, sowie die Lesbarkeit von SQL-Ausdrücken.
Aus Gründen der menschlichen Lesbarkeit und des schnellen Verständnisses
orientiert sich auch TMQL an der menschlichen Sprache (Englisch) und besitzt
einen Anfragetyp(3.6.4) mit starker syntaktischer Ähnlichkeit zu SQL. Aufgrund
des eingeschränkten Funktionsumfanges von TMQL wird nur die Abfragesyntax
von SQL näher betrachtet.
SELECT [DISTINCT] Auswahlliste

FROM Quelle
[WHERE Where-Klausel]
[GROUP BY (Group-by-Attribut)
[HAVING Having-Klausel]]
[ORDER BY (Sortierungsattribut [ASC|DESC])]
[OFFSET Index]
[LIMIT Number];
Codefragment 6 - Syntax einer SQL-Select-Anweisung[30]
Um einen direkten Vergleich zur TMQL zu ermöglichen sei, die syntaktische

Struktur des TMQL-Select-Style(3.6.4) hier vorweggenommen.
SELECT <value-expression>
[FROM value-expression]
[WHERE boolean-expression]
[ORDER BY <value-expression>]
[UNIQUE]
[OFFSET value-expression]
[LIMIT value-expression]
Codefragment 7 - Syntax einer TMQL-Select-Anweisung[13]
16
2. Grundlagen
Die starke syntaktische Ähnlichkeit beider Sprachen ist offensichtlich, welches

durch die Herkunft des Select-Style von TMQL begründet ist. Einige
Unterschiede der syntaktischen Ansätze begründen sich in den verschiedenen
zu Grunde liegenden Datenmodellen beider Sprachen. Besitzt eine Datenbank
stets eine Menge von mehr oder weniger unabhängigen Tabellen, so kapselt
eine Topic Maps alle enthaltenen Informationsressourcen. Als Folge daraus
definiert sich die FROM Klausel einer SQL-Anweisung nicht als optional. Da
Aggregationsfunktionen aktuell nur bedingt ein Bestandteil von TMQL sind,
existiert innerhalb der Sprache keine GROUP BY Klausel. Eine Erweiterung um
weiterer solcher Funktionen könnte im Rahmen einiger Anwendungen als
sinnvoll erscheinen und zukünftig Bestandteil des TMQL-Drafts bzw. des
späteren Standards werden.
Sowohl SQL auch als TMQL bietet eine Menge von Funktionen, welche im
Kontext von Anfragen verwendet werden können, um Informationen zu
extrahieren oder den Wert temporär zu manipulieren. Zum Funktionsumfang
von SQL gehören die bereits angesprochen Aggregationsfunktionen,
Zeichenkettenfunktionen, sowie Funktionen für Zahlen und
Datumsinformationen. Im Vergleich zum Funktionsumfang zu TQML zeigt sich
eine geringe Schnittmenge, was in folgender Tabelle verdeutlicht werden soll.
Funktionstyp SQL TMQL

Aggregation count, sum, min, max, count für Tupelsequenzen
avg, stddev
String-Funktion concat, length upper, concat, length
lower, substr, replace
Tupel-Funktionen slice, count, uniq, concat,
zigzag, zagzig
Tabelle 1 - kleiner Vergleich des Funktionsumfanges von SQL und TMQL
Die Aufzählung der Funktionen stellt sowohl für TMQL als auch für SQL keinen
Anspruch auf Vollständigkeit. Eine vollständige Liste der TMQL-Funktionen
kann unter [13] eingesehen werden. TMQL besitzt aktuell kaum Zeichenketten-
bzw. Aggregationsfunktionen, eine Erweiterung um einige der benannten
Funktionen erscheint allerdings sinnvoll, da diese sich im SQL-Umfeld als
nützlich herausgestellt haben. Die Aggregationsfunktionen könnten im Bereich
17
2. Grundlagen
der Wertaggregation von Occurrences Verwendung finden und die

Zeichenkettenfunktionen im Bereich der Namen und Varianten.
Eine weitere Überscheidung beider Standards ist im Bereich verfügbarer

Datentypen zu erkennen. Die Übereinstimmung betrifft allerdings lediglich die
Wertebereiche der existierenden Datentypen. Eine gemeinsame Basis der
Datentypen von TMQL und SQL existiert nicht. Die TMQL-Datentypen
orientieren sich an existierenden Standards, wie XSD und CTM.
Als Erweiterung zu SQL existiert der SQL/XML-Standard, welcher die

Speicherung von XML-Dokumenten in Datenbanken ermöglicht. Interessanter
erscheint allerdings die Möglichkeit der Abfrage von Informationen aus den
XML-Dateien unter Verwendung von XQuery und XPath, sowie die
Deserialisierung von relationalen Daten als XML. Die starken inhaltlichen
Parallelen zu XTM(2.3.2) und Path-Expression von TMQL(3.6.3) sind
unverkennbar, die genaue Syntax unterscheidet sich aber auch hier auf Grund
der verwendeten Datenmodelle.
2.4.2. RDF und SPARQL Protocol and RDF Query Language
Die Sprache RDF stellt genau wie Topic Maps eine Realisierung des
aussagegegenstandszentrierten Modellierungsparadigmata dar und besitzt
äquivalent zu TMQL eine eigene Abfragesprache, SPARQL.
Kernkonzept von RDF sind Aussagen über Fakten und Subjekte der realen
Welt. Die Formulierung von Aussagen erfolgt als Trippel von Subjekt, Prädikat
und Objekt. Zur eindeutigen Repräsentierung von Subjekt, Objekt und Prädikat
werden URIs verwendet, eine Ausnahme dieser Regelung stellt die
Verwendung atomarer Werte als Objekt dar. Folgendes Beispiel soll dieses
fundamentale Konzept verdeutlichen.
http://www.leipzig.de assocc:located_in http://www.sachsen.de
Codefragment 8 - RDF-Beispiel
18
2. Grundlagen
Die Syntax von SPARQL weißt ebenfalls eine gewisse syntaktische Ähnlichkeit
zu SQL auf, variiert auf Basis des Datenmodells allerdings ein wenig. SPARQL-
Anfragen werden äquivalent zu RDF als Trippel formuliert, wobei die
Verwendung von Variablen, die gewünschte Information innerhalb des Query
kennzeichnet. Um die Information über das Subjekt Leipzig des
vorrangegangen Beispiels zu extrahieren ist folgende Abfrage nötig.
SELECT ?city WHERE {?city assocc:located_in http://www.sachsen.de.}
Codefragment 9 - SPARQL-Query
2.4.3. XML Path Language – XPath
XPath stellt eine Abfragesprache zur Extraktion von Informationen aus XML-
Dokumenten dar und ermöglicht die Adressierung von Teilfragmenten innerhalb
des XML-Dokumentes. Die Betrachtung eines XML-Dokumentes erfolgt dabei
als Baumstruktur, wobei alle XML-Elemente, sowie Attribute, Kommentare und
textueller Inhalt, als Knoten betrachtet werden.
Die Formulierung eines XPath-Ausdruck besteht aus der Adressierung des

gewünschten Knoten (Lokalisierungsschritte), sowie einer optionalen
Benennung von Prädikaten. Die Adressierung erfolgt auf Basis verschiedener
Achsen, welche neben der reinen Eltern-Kind-Beziehung, auch Bezug auf den
abstrakten Index innerhalb des XML-Dokumentes nehmen. Als abstrakter Index
ist die Position innerhalb des Eltern-Knoten gemeint. Jeder so adressierte
Knoten kann unter Verwendung definierter Operatoren und Funktionen einem
Test unterzogen werden.
Als Prädikate unterstützt XPath einige Funktionen, welche bereits aus SQL
bekannt sind und im Rahmen von Zeichenketten- und Aggregationsfunktionen
unterstützt werden.
19
3. Topic Maps Query Language - TMQL
Die Topic Maps Query Language, kurz TMQL, stellt eine aktuelle
Standardisierungsbemühung der ISO und IEC für eine einheitliche und
mächtige Abfragesprache im Umfeld von Topic Maps dar.
Dieses Kapitel soll einen kurzen Einblick in die aktuelle Materie des TMQL-
Drafts geben. Ob alle der beschriebenen Elemente als Bestandteil des finalen
Standards übernommen werden, bleibt offen.
3.1. Anforderungen und Anwendungsfälle für TMQL
Die Grundlage und Basis der Entwicklung des aktuellen TMQL-Drafts bildeten
eine Menge von Anforderungen, welche der zu entwickelnde Standard
abdecken sollte. Weiter werden einige fundamentale Anwendungsfälle definiert,
welche unter Verwendung von TMQL effizient und einfach zu realisieren sein
sollten.
Hauptanforderung der Sprache bildete die Möglichkeit des Zugriffes auf

Informationen, welche gemäß dem Topic-Maps-Paradigma gespeichert sind.
Ziel ist die Modellierung einer Sprache zur effizienten und einfachen Abfrage
komplexer Informationen und Beziehung zwischen Topics und anderen
Elementen einer Topics Maps. Neben der reinen Abfrage einzelner
Informationselemente, sollen auch direkte und indirekte Verkettungen einzelner
Topics und Assoziationen extrahierbar sein. Als indirekte Beziehung sind
Interaktionen zwischen Topics gemeint, deren Verkettung nur über ein drittes
Topic sichtbar wird. Als Beispiel seien zwei Einwohner der Stadt Leipzig
genannt, welche nur über die gemeinsame Beziehung zum Topic Leipzig in
Verbindung stehen.
Zu den angesprochen Anwendungsfällen zählen die Visualisierung und

Introspektion von Topic Maps. Ziel der Introspektion ist die Vereinfachung der
Integration und von Topic Maps mit unbekannter Ontologie und Struktur. Dieser
Anwendungsfall fokussiert die Verwendung von TMQL, als Analysesprache zur
20
Ermittlung der internen Terminologie einer Topic Maps durch Formulierung

weniger TMQL-Statements.
Die für einen konkreten Anwendungsfall benötigten Informationen variieren

stark in Art und Umfang. Auf Basis von TMQL-Anfragen ist es möglich einer
Anwendung die benötigten Informationen in verschiedenen Formaten zur
Verfügung zu stellen. Die Integration von XML als Rückgabetypen bildet
beispielsweise die Grundlage einer Abbildung in alle XML-basierten Formate,
wie SVG, und ermöglicht somit die Visualisierung der enthalten Informationen.
3.2. Notation und Semantik
Basis der Sprache TMQL ist eine kontextfreie Grammatik zur Definition von
Produktionsregeln. Diese Produktionsregeln bilden die Basis der späteren
Validierung der an den Parser übergebenen Ausdrücke.
Die Untersuchung der syntaktischen Grundlage der Grammatik stellt die

Voraussetzung für das spätere Verständnis der Sprache und Produktionsregeln
dar.
Die Grammatik von TMQL wird auf drei Ebenen definiert, welche jede für sich
auf einem bestehenden Industriestandard aufbaut und von unten nach oben
betrachtet eine höhere Aussagekraft besitzt.
3.2.1. Token Level
Die unterste syntaktische Ebene der Grammatik von TMQL wird als Token
Level bezeichnet und basiert auf regulären Ausdrücken (RegExp). Reguläre
Ausdrücke werden verwendet um gültige Terminalsymbole als Zeichenfolgen zu
definieren und sind dabei immer case-sensitive. Die Interpretation von
Schlüsselwörtern erfolgt allerdings ohne Berücksichtigung der Groß- und
Kleinschreibung.
21
Die definierten Terminalsymbole können im Kontext einer Anfrage als

Schlüsselwörter, Funktionsnamen oder Konzepte verwendet werden. Gültige
Variablennamen werden in einem gesonderten Kapitel weiter untersucht und
beschrieben, da sie sich von der genannten Terminalsymbolgrammatik
unterscheiden dürfen.
Die restriktive Syntax erlaubt innerhalb von Terminalsymbolen nur die

Verwendung alphanumerischer Zeichen, sowie eine Menge von Sonderzeichen.
Zu den erlaubten Zeichen gehören:
@ $ % ^ & | * - + = ( ) { } [ ] " ' / \ < > : . , ~ _
Codefragment 10 - Menge gültiger Zeichen für Terminalsymbole
Alle nicht aufgeführten Zeichen sind innerhalb von TMQL als Terminalsymbole
nicht erlaubt und werden während der Validierung als Fehler erkannt.
Eine gesonderte Rolle nehmen Leerzeichen (’ ’), Absätze (’\n’) und Einschübe
(’\t’) ein. Diese sogenannten Leerraumzeichen werden zur Separation von
Terminalsymbolen eingesetzt und sind in beliebiger Anzahl zwischen zwei
beliebigen Token verwendbar. Die Art und Anzahl dieser Zeichen wird nicht
weiter spezifiziert und besitzt keine semantische Bedeutung. Die einzige
Ausnahme stellen Zeichenketten innerhalb von XML- oder CTM-Fragmenten
dar. Darin enthaltene Leerräume werden beibehalten.
Die Raute (’#’) nimmt ebenfalls eine besondere Rolle innerhalb der Grammatik
ein. Alle auf dieses Zeichen folgenden Symbole werden als Kommentare
angesehen und nicht weiter interpretiert. Eine Ausnahme dieser Regelung stellt
die Verwendung innerhalb eines Variablennamen dar, welche im späteren
Kapitel noch mal genauer betrachtet wird.
3.2.2. Canonical Level
Die zweite Sprachebene wird als Canonical Level bezeichnet und definiert sich
auf Basis der kontextfreien Grammatik von XML 1.0. Um Inkonsistenz innerhalb
22
der Sprache zu vermeiden, werden einige Konventionen eingeführt.

Gegenstand des Canonical Level bildet die Definition von Produktionsregeln auf
Basis der Terminalsymbole des Token Level.
Die Verwendung eines beliebigen gültigen Terminalsymbols in beliebiger

Anzahl wird nicht wie üblich als regulärer Ausdruck A* bzw. A?, sondern durch
Verwendung von geschweiften Klammern {A} bzw. eckigen Klammern [A]
definiert. Als Beispiel sei folgende Produktionsregel von TMQL genannt.
environment-clause ::= { directive | pragma }
Codefragment 11 - Produktionsregel als Beispiel der Notationsanpassung für beliebiges

Vorkommen eines Terminalsymbols
Eine potentiell leere und durch Kommata getrennte Liste von Terminalsymbolen
wird nicht in üblicher Syntax ( A ( ’, ’A ) * ) ? beschrieben, sondern wie folgt
definiert <A>.
Für Alternativen wird die Backus-Naur-Form (BNF) verwendet. Die Grammatik

ist dabei so konzipiert, das jegliche Mehrdeutigen aufgelöst werden. Die
Auswahl von konstanten Token wird dabei gegenüber der Auswahl von Token,
welche auf regulären Ausdrücken basieren, bevorzugt.
3.2.3. Non-Canonical Level
Um die Komplexität der Produktionsregeln des Canonical Level zu reduzieren,

definiert das Non-Canonical Level eine Menge von Vereinfachungen für
bestehende Produktionsregeln. Diese Terminologie wird innerhalb der Sprache
durch Term-Transformationen modelliert. Dabei unterscheidet sich der
transformierte Term semantisch nicht vom Ursprungsterm. Term-
Vereinfachungen stellen somit keine Komplexitätserhöhung innerhalb der
Sprache dar und vereinfachen lediglich die Lesbarkeit von Ausdrücken. Diese
Vereinfachung spielt im Kontext der Navigationsachsen eine wesentliche Rolle
und wird dort gesondert behandelt.
23
Folge dieser Vereinfachungen ist allerdings die Erhöhung des Rauschens und
die Erzeugung von Inkonsistenz innerhalb der Sprache. Der aktuelle Draft sieht
zwar diese Sprachebene noch vor, allerdings werfen die genannten Probleme
die Frage der Notwendigkeit und der Unterstützung dieser Spracheebene auf.
Aktuell bleibt abzuwarten, ob diese Grammatikebene Gegenstand des finalen
Standards wird oder entfernt wird.
Da der im Rahmen dieser Arbeit zu entwickelnde Prototyp sich eng am Draft

orientiert, wird diese Spracheebene unterstützt.
3.3. Ontologie-Abhängigkeit einer TMQL-Umgebung
Der aktuelle Draft von TMQL sieht abgesehen von zwei Ausnahmen die
absolute Ontologie-Unabhängigkeit von TMQL-Umgebungen vor. Dieses
Konzept ermöglicht die gleiche Verarbeitung von Anfragen innerhalb
verschiedener Terminologien.
Die beiden Ausnahmen dieser Regelung stellen die Typ-Transitivität und die
Typ-Instanz-Beziehung dar. Beide Konzepte verwenden und erweitern die
Interpretation gemäß des Topic-Maps-Datenmodells (TMDM).
Typ-Transitivität bezeichnet die Eigenschaft, dass sich in Folge eine Supertyp-

Typ-Beziehung zwischen zwei Typen A und B, sowie eine Supertyp-Typ-
Beziehung zwischen B und C, eine Supertyp-Typ-Beziehung zwischen A und C
automatisch impliziert. Derselbe Ansatz gilt für Typ-Subtyp-Beziehung zwischen
zwei Typen. Per Definition wird die Transitivität als reflexiv angesehen, folglich
ist jeder Typ auch Supertyp und Subtyp von sich selbst. Im Bezug auf
transitivfreie Operation werden durch diesen Ansatz keine Mehrdeutigkeiten
erzeugt.
Die Typ-Instanz-Beziehung beinhaltet hingegen die Konzeption, dass jede

Instanz A eines Konzeptes B, gleichzeitig eine Instanz aller Supertypen dieses
Konzeptes darstellt. Bei transitivfreien Operatoren wird zweifelsfrei immer der
direkte Typ geliefert.
24
Beide Regeln bilden das Fundament für Anfragen innerhalb einer

Typhierarchie.
Zusätzlich verwendet der Standard eine Menge von bestehenden Ontologien.

Neben den bereits genannten Modellen des TMDM, werden innerhalb des
TMQL-Standards die Datentypen der XML Schema Definition (XSD) verwendet,
um ein einheitliches Datentypsystem über alle Topic Maps zu spezifizieren.
Weiter werden Bestandteile von Dublin Core (DC) verwendet, um die
Terminologie zu definieren. Als Zusatz definiert TMQL einen eigenen
Namensraum, welcher alle Konzepte und Funktionen des Standards umfasst
bzw. später umfassen wird.
Alle genannten externen Ontologien werden innerhalb der Umgebung einer

TMQL-Laufzeitumgebung als Topic repräsentiert und können als solche
innerhalb einer TMQL-Anfrage verwendet werden. Die folgende Tabelle listet
noch einmal zusammenfassend die genannten Namensräume und die von
TMQL definierten Präfixe.
Namensraum Präfix Verwendung

XML Schema Definition xsd Datentypenkonvention in TMQL
Topic Maps Data Model tm Transitivität und Instanzbeziehung
TMQL-Konzepte tmql Basiskonzepte von TMQL
TMQL-Funktionen fn Hilfsfunktionen von TMQL
Dublin Core dc Bestandteile des Metadatenmodells
Tabelle 2 - verwendete Namensräume anderer Standards innerhalb der TMQL-Ontologie
3.4. Elementare Sprachbestandteile
In diesem Abschnitt werden die wichtigsten Sprachbestandteile des aktuellen

Drafts untersucht. Dabei werden nur die TMQL-Elemente analysiert, welche für
die Entwicklung des späteren Prototyps und das Verständnis der Sprache
notwendig sind.
25
3.4.1. Literale
Als Atome gelten in TMQL konstante Literale zur Definition von Datentypen,
sowie deren Operatoren. Die Menge der gültigen Atome des aktuellen Drafts
bildet ein kleiner Auszug aus den Datentypen des CTM-Standards, sowie von
XSD-Datumsformaten. Neben Zeichenketten, IRI und Wahrheitswerten, werden
numerische Werte unterstützt. Dabei unterscheidet TMQL zwischen
Ganzzahlen und Gleitkommawerten. Zur Definition von Null-Werten wird ein
spezieller Datentyp mit der Bezeichnung undefined und der einzigen
Ausprägung undef verwendet.
Als Zeitformate verwendet TMQL die beiden Datentypen date und dateTime
von XSD. Dadurch kann eine starre und eindeutige Darstellung von
Zeitformaten unabhängig von der Implementierung realisiert werden. Das
Format entspricht dabei immer dem folgenden Muster.
'-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?
Codefragment 12 - Muster für Datumsformate gemäß XSD dateTime[26]
Datumsformate werden entsprechend formuliert und definieren ein Zeitintervall,

welches sich gemäß XSD-Restriktion von 00:00:00 bis 24:00:00 eines
definierten Datums erstreckt [26].
Die nachfolgende Tabelle listet die gültigen Atome, sowie die möglichen
Wertausprägung gemäß des XSD- und CTM-Standards.
26
Atom mögliche Wertausprägungen

atom undefined|boolean|number|date|dateTime|string|iri
undefined Undef
boolean true|false
number decimal|integer
decimal /[+-]?\d+(\.\d+)?/
integer /[+-]?\d+/
date '-'? yyyy '-' mm '-' dd (zzzzzz)?
dateTime '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?
iri
string /"([^"]|\")*"/ | /'([^']|\')*'/
Tabelle 3 - Übersicht über die gültigen Atome des aktuellen Drafts, sowie deren
möglichen Wertausprägungen[13]
3.4.1.1. Item-Referenzen und deren Auflösung
Referenzen können als Bestandteil einer TMQL-Anfrage zur Identifikation

existierender Elemente der Topic Maps verwendet werden. TMQL unterstützt
dabei die beiden grundlegenden Konzepte des TMDM, welches eine Referenz
unter Verwendung eines Item- oder Subject-Identifier spezifiziert.
Als Item-Identifier bezeichnet das TMDM Referenzen auf

Informationselemente. innerhalb der verarbeiteten Topic Maps. Der Standard
definiert allerdings nicht, in welcher Form diese Referenz von der verwendeten
Topic-Maps-Engine aufzulösen ist ([8], Abs. 5.1 General). Diese Schwachstelle
des TMDM bietet ein erhöhtes Potential der Inkonsistenz, da eine Verarbeitung
im Extremfall in verschiedenen Ergebnissen unter Verwendung verschiedener
Engines resultieren kann.
Subject-Identifier als fundamentaler Bestandteil von Topic Maps hingegen stellt

eine sichere und eindeutige Referenz von Topic-Elementen dar und wird von
jeder Topic-Maps-Engine gleichermaßen interpretiert und verarbeitet. Dabei
können Subject-Identifier als absolute oder relative IRI beschrieben werden.
Letztere werden dann vom jeweiligen Prozessor aufgelöst um eine eindeutige
Auflösung der Referenz sicher zu stellen.
27
Im Falle einer ungültigen Referenz endet die Verarbeitung des TMQL-

Prozessors in einem Fehler. Im nachfolgenden Flussdiagramm werden die
eben genannten Abläufe noch mal verdeutlicht.
Abbildung 2 - Ablaufdiagramm der Verarbeitung von Element-Referenzen innerhalb eines

TMQL-Prozessors
3.4.2. Navigationsachsen
Durch die grundlegende Struktur einer Topic Maps, modelliert durch das
TMDM, können 12 Navigationsachsen definiert werden. Jeder
Navigationsschritt erfolgt innerhalb der Topic-Maps-Instanz entlang einer
definierten Achse in einer definierten Richtung. Zusätzliche Attribute
ermöglichen die optionale Einschränkung bzw. Steuerung des
Navigationsschrittes, allerdings wird dieses Konzept nicht von jeder Achse
unterstützt.
28
Alle Navigationsachsen definieren gemeinsam einen abgeschlossenen Raum,

d.h. zwischen zwei beliebigen Knoten innerhalb des abstrakten Topic-Maps-
Graphen existiert stets mindestens ein Pfad unbekannter Länge. Der Pfad
definiert sich als Menge von Navigationsschritten. Per Definition werden nahezu
alle Achsen als konsistent angesehen. Eine Achse ist konsistent, genau dann,
wenn die Kombination einer Vorwärts- und Rückwärtsnavigation entlang dieser
Achse in einer Menge resultiert, welche mindestens das Ursprungselement
enthält. Im Allgemeinfall enthält diese Menge allerdings zusätzliche
Informationselemente, ein Beispiel für diesen Fakt stellt die types-Achse dar,
welche in Vorwärtsrichtung alle Typen einer Instanz und in Rückwärtsrichtung
die Instanzen dieser Typen liefert. Die Menge von Typen enthält infolge der
Transitivität (3.3) aber auch alle Supertypen.
Die Verwendung der Navigation entlang einer Achse wird innerhalb der Anfrage
durch die speziellen Zeichenmuster << bzw. >> definiert, gefolgt von der
abstrakten Bezeichnung der jeweiligen Achsen, sowie dem optionalen Attribut
zur Steuerung. Für einige der Navigationsachsen definiert TMQL auf der
3.Sprachebene eine Menge von speziellen Zeichenmustern, welche die
Navigationsrichtung und die abstrakte Bezeichnung der Navigationsachse
impliziert. Diese Abkürzungen werden durch spezielle Term-Transformationen,
auf ihre Entsprechung abgebildet und dem Prozessor zur Verarbeitung
übergeben. Ein wesentliches Problem dieser Abkürzungen besteht in der
Mehrdeutigkeit gegenüber anderer Standards, wie SQL, sowie der
Interpretation durch den Prozessor. Die genannten Probleme werden während
der Analyse genauer betrachtet und ihr Einfluss auf die Implementierung
abgeschätzt.
Die nachstehende Tabelle benennt die 12 Achsen namentlich und definiert die
semantische Bedeutung ihrer Ergebnismenge.
29
Achsen Vorwärtsrichtung Rückwärtsrichtung

types alle Typen der aktuellen alle Instanzen des aktuellen
Instanz Typs
supertypes alle Supertypen des aktuellen alle Subtypen des aktuelle
Typs Typs
players alle an dieser Assoziation alle Assoziation, an dem das
teilnehmenden Topics Topic teilnimmt
roles alle Rollentypen der alle Assoziation, welche den
Assoziation Rollentyp verwenden
traverse alle Topics, welche alle Assoziation, welche über
gemeinsam mit dem Topic an ein Topic mit der Assoziation
einer Assoziation teilnehmen verbunden sind
characteristics alle Eigenschaften ( Namen alle Topics, welche die
und Occurrences) des Topics Eigenschaft besitzen
indicators alle Subject-Identifier des das Topic, welches den
Topics Subject-Identifier besitzt
locators alle Subject-Locator des das Topic, welches den
Topics Subject-Locator besitzt
item alle Item-Identifier des Topics das Topic, welches den Item-
als Zeichenkette Identifier besitzt
scope liefert den Scope der liefert alle Eigenschaft des
Assoziation bzw. der optionalen Topics, welche im
Eigenschaften aktuellen Scope gültig sind
reifier liefert das reifizierte Element liefert alle Reifizierungen des
innerhalb der Topic Maps aktuellen Elementes
atomify Serialisierung des aktuellen Deserialisierung des Wertes
Elementes zu einem Element der Topic
Maps
Tabelle 4 - Navigationsachsen von TMQL, basierend auf der Struktur einer Topic Maps
nach TMDM
3.5. Untersuchung wichtiger Produktionsregeln und Teilausdrücke
Zur Realisierung des Parser und der späteren Interpretation ist die Analyse der
Produktionsregel bzw. Teilausdrücke zwingend notwendig. Im Folgenden
werden die wichtigsten Arten von Teilausdrücken näher untersucht, um deren
Struktur und Auftreten innerhalb eines Query genauer verstehen zu können.
3.5.1. Simple- und Composite-Content
Der Oberbegriff des Content beschreibt die Menge von Inhalten, welche durch
die erfolgreiche Verarbeitung eines TMQL-Query erzeugt werden können.
Innerhalb der Terminologie von TMQL umfasst der Begriff Content, somit
jeglichen atomaren Wert, aber auch die Menge von Informationselementen
30
einer Topic Maps. Dabei unterscheidet TMQL ähnlich wie XSD zwischen
einfachen Inhalten (Simple-Content) und zusammengesetzten komplexeren
Inhalten (Composite-Content).
Atomare oder einfache Inhalte werden gemäß des aktuellen Drafts durch
Verwendung von Konstanten bzw. des Werts einer Variable, sowie einer Menge
von Navigationsschritten gebildet. Die Anzahl der Navigationsschritte unterliegt
keiner Einschränkung und bewegt sich theoretisch von 0 bis unendlich.
Folgende Abbildung zeigt die definierte Regel für Simple-Content des aktuellen
Drafts.
simple-content ::= anchor [ navigation ]

anchor ::= constant | variable
navigation ::= step [ navigation ]
Codefragment 13 - Produktionsregeln für Simple-Content
Jegliche andere Inhalte werden als komplexe Inhalte oder Composite-Content

bezeichnet, dies umfasst Tupelsequenzen, welche bei der Verarbeitung eines
TMQL-Ausdruckes generiert werden. Der Draft spezifiziert eine Vielzahl von
Möglichkeiten zur Inhaltsgenerierung und Strukturierung. Neben der
Verwendung von Kombinationsoperatoren von Content (++, --, ==) bzw.
Tupelsequenzen, unterstützt der aktuelle Draft die Verarbeitung bedingter
Anweisung, sowie XML- und TM-Content. Content kann für sich wieder
verschiedene Ausdrücke enthalten.
content ::= content ( ++ | -- | == ) content

content ::= { query-expression }
content ::= if path-expression then content [ else content ]
content ::= tm-content
content ::= xml-content
Codefragment 14 - Produktionsregeln für Composite-Content
Zur genauen Abgrenzung der beiden Content-Typen wird folgendes Beispiel

betrachtet.
31
leipzig / population #is simple-content

{leipzig, leipzig / population} #is complex-content
Codefragment 15 - Beispiel zur Abgrenzung der Content-Typen
Zur Vereinfachung spezifiziert der aktuelle Draft die folgende Menge von
Regeln auf dem Non-Canonical Level. Unter der Annahme der
Inhaltsgenerierung durch Verwendung einer einfachen Path-Expression,
werden die geschweiften Klammern als optional angesehen. Äquivalent dazu
können bedingte Anweisung drastisch reduziert werden, unter der Annahme,
dass es sich bei dem Content nur um Path-Expression handelt.
content ::= path_expression

{ path_expression }
content ::= path-expression-1 || path-expression-2
if path-expression-1 then { path-expression-1 } else {
path-expression-2 }
Codefragment 16 - Non-Canonical Regelsatz für Composite-Content
3.5.1.1. XML-Content
Die Spezifikation von XML-Content erfolgt auf einer Untermenge der

grammatikalischen Regeln von XML 1.0 mit einer Anpassung der Notation zur
Vermeidung von Mehrdeutigkeiten. Die folgende Menge von Regeln ist
Bestandteil des aktuellen Drafts.
xml-content ::= { xml-element }

xml-element ::= < xml-tag { xml-attribute } xml-rest
xml-tag ::= [ prefix ] xml-fragments
xml-attribute ::= [ prefix ] xml-fragments = " xml-fragments "
xml-rest ::= /> | > { xml-element|xml-fragments } </ xml-tag >
xml-fragments ::= { xml-text | { query-expression } }
xml-text ::= ...see text...
Codefragment 17 - Untermenge der Prädikatenformeln von XML-Content
Der XML-Content stellt XML-Fragmente zur Verfügung, welche über die

Einbettung beliebiger XML-Elemente und von statischem Text, sowie die
Verwendung von TMQL-Ausdrücken, statische und dynamische Inhalte
32
besitzen können. TMQL-Ausdrücke innerhalb eines XML-Content müssen

durch geschweifte Klammern klar vom statischen Inhalt abgegrenzt werden. Die
Verwendung der Zeichen <, >, { und } ist innerhalb eines statischen Textblockes
nicht legitim und muss durch entsprechende Escapesequenzen der XML-
Syntax ersetzt werden.
Die Validierung und Verarbeitung von XML-Content erfolgt nach einem

definierten Schema. Die Validierung der eingebettet TMQL-Ausdrücke erfolgt in
beliebiger Reihenfolge. Nach erfolgreicher Verarbeitung werden die
Ergebnismengen in XML-Content konvertiert. Die Art der Transformation ist
dabei abhängig vom Typ der generierten Inhalte, so werden Atome
beispielsweise durch ihre Zeichenkettenrepräsentation ersetzt. Zeichenketten
werden direkt eingebettet mit Ausnahme der oben genannten Zeichen. Eine
Tupelsequenz wird ebenfalls in eine Zeichenkette konvertiert (3.5.2.2). Topic-
Maps-Fragmente bzw. Elemente werden auf Basis von XTM 2.0 serialisiert.
Hierbei wird jedes Element in Abhängigkeit seines Typs durch einen
spezifischen XML-Tag repräsentiert und als XML-Elemente in den XML-Content
eingebettet.
Das Ergebnis dieses Prozesses wird als gültiges XML gemäß XML 1.0
interpretiert und als solches von einem XML-Parser validiert. Leerzeichen und
Zeilenumbrüche besitzen dabei, innerhalb von XML-Content, eine hohe
semantische Bedeutung und werden vollständig in das XML-Fragment
übernommen.
3.5.1.2. TM-Content
Durch Verwendung der CTM-Syntax ist es möglich Topic-Maps-Fragmente

durch TMQL-Ausdrücke zu erzeugen. TM-Content ist nur als Bestandteil der
Return-Klausel des FLWR-Style erlaubt und kann daher nur dort verwendet
werden.
tm-content ::= """ ctm-instance """
Codefragment 18 - Produktionsregel eines TM-Content
33
Per Definition der Produktionsregel, beinhaltet der TM-Content genau einen

CTM-Text-Strom als CTM-Instanz, welcher für sich wieder TMQL-Ausdrücke
enthalten darf. Es gelten dabei dieselben syntaktischen Notationen, wie beim
XML-Content. Die Evaluierung der TMQL-Ausdrücke erfolgt unabhängig von
der CTM-Syntax. Erst im Anschluss daran, werden die generierten
Ergebnismengen, gemäß der Deserialisierungsregeln, von CTM validiert und in
die CTM-Instanz importiert.
Die Position des verwendeten TMQL-Ausdruck innerhalb des CTM-Stroms ist

nicht frei und an bestimmte Regeln gebunden. So ist die Verwendung von
eingebetteten Ausdrücken nur dort erlaubt, wo die Deklaration von Topics oder
Assoziationen gemäß CTM-Syntax erwartet wird bzw. gültig ist. Als
Ergebnismenge des eingebetteten Ausdruck wird eine Tupelsequenz aus
Singelton-Elementen erwartet, welche Tupel für Tupel in eine TMDM-Instanz
importiert werden, indem alle Topic-Elemente inklusive aller Eigenschaften,
Namen und Identifier bzw. alle Assoziationen übernommen werden. Die
potentielle Reifikation dieser Elemente geht verloren und wird nicht explizit
importiert. Im Falle einer gültigen IRI oder eines gültigen Identifier wird ein Topic
mit diesem Identifier erzeugt.
Im Rahmen von Definition (Assignment) für Topics, Namen und Occurrences ist
die Verwendung von eingebetteten Ausdrücken ebenfalls erlaubt. Im Kontext
der Definition von Namen oder Occurrences werden alle Tupel der
Ergebnismenge gemäß der Serialisierungsregeln in ihre
Zeichenkettenrepräsentierung überführt und in den CTM-Strom eingebettet.
Die Verwendung innerhalt eines CTM-Strings oder als Topic-Identifier ist

ebenfalls valide.
3.5.2. Tupel und Tupelsequenzen – Tupel-Expression
Die erfolgreiche Verarbeitung einer TMQL-Abfrage erzeugt eine Menge von

Content. Dieser Content wird durch eine Sequenz von Tupelsequenz
beschrieben. Jede Sequenz enthält je nach Kontext der Anfrage, Tupel als eine
34
Menge von atomaren Werten, wie Ganzzahlen oder Zeichenketten, aber auch
XML- bzw. Topic-Maps-Fragmenten. Der Begriff Tupel bezeichnet also eine
zusammenhängende Menge von Informationselementen der konkreten
Abfrage. Zum exakten Verständnis der Terminologie sei folgende TMQL-
Anfrage benannt, welche eine Sequenz aus zwei Tupel liefert.
SELECT $city , $city / population WHERE $city ISA city

:= { leipzig, 515000 }; { berlin, 3431000 };
Codefragment 19 - TMQL-Anfrage zur Verdeutlichung der Terminologie Tupel und

Tupelsequenz
Der aktuelle TMQL-Draft unterstützt verschiedene Mengenoperatoren zur

Kombination von Sequenzen, wie Vereinigung, Differenz und symmetrische
Differenz, sowie Kontrollflussoperatoren aus modernen Programmiersprachen.
Diese Operatoren stellen die einzige Möglichkeit dar, Tupel zu erzeugen. Eine
direkte zielgerichtete Erzeugung von Tupel ist nicht möglich.
Ein Tupel enthält dabei, wie bereits erwähnt, eine Menge von Literalen
verschiedener Typen. Die Länge des Tupel definiert sich über die Mächtigkeit
der Literalmenge. Tupel mit einer Mächtigkeit von eins werden als Singelton
bezeichnet. Die Werte eines jeden Tupel können per Projektion ausgelesen
werden, zu diesem Zweck erzeugt der TMQL-Parser im Kontext einer jeden
Anfrage eine Menge von Variablen, welche auf die einzelnen Stellen des
aktuellen Sets verweisen.
3.5.2.1. Vergleich und Sortierungen von Tupeln und Sequenzen
TMQL spezifiziert in welcher Art und Weise die Ergebnistupel zu vergleichen

bzw. zu ordnen sind. Dabei werden zwei Tupel genau dann als identisch
angesehen, wenn sie dieselbe Mächtigkeit besitzen und jeder Wert gemäß
seines Typs und Wertes übereinstimmt. Der Vergleich erfolgt bei nicht leeren
Tupel iterativ, Stelle für Stelle und wird vorzeitig abgebrochen, wenn der
aktuelle Wertvergleich an der Stelle x auf nicht-identische Tupel schließen lässt.
35
Eine Tupelsequenz ist per Definition immer ungeordnet, solange keine explizite
Sortierung angegeben wurde. Die Sortierung erfolgt auf Basis spezieller
Sequenzen, welche als Werte nur asc, für aufsteigende Sortierung, und desc,
für absteigende Sortierung, enthalten dürfen. Die Interpretation und Angabe der
Sortierreihenfolge ist abhängig vom Typ des Ausdrucks, welcher die Sequenz
erzeugt
Unter Verwendung von Tupel-Expression, als Menge von Value-Expression,

erfolgt die Definition der Sortierrichtung innerhalb jeder Value-Expression und
die Interpretation immer von links nach rechts. Unter der Annahme, dass im
Minimum eine Sortierreihenfolge definiert wurde, werden fehlende
Spezifikationen durch den Standardparameter asc ersetzt. Das folgende
Beispiel sortiert alle Instanzen des Typs Person aufsteigend nach ihrem
Namen. Jeder Block von gleichem Namen, wird dann zusätzlich absteigend
nach dem Geburtstag sortiert.
// person ( . / name , . / birthdate desc )

Codefragment 20 - Tupel-Expression als Beispiel für Sortieroperation
Die Sortierung von Sequenzen als Ergebnis von Kombinationsoperationen aus

zwei Tupel T1 und T2 erfolgt getrennt. Zuerst werden alle Tupel von T1 sortiert
und die Sortierung von T2 wird nur berücksichtigt, insofern Blöcke gleicher
Werte in T1 auftreten. Fehlende Sortierungsreihenfolgen, werden nicht durch
einen Standardparameter ersetzt und die Tupel bleiben immer unsortiert. Als
Beispiel sei das Codefragment 21 genannt. T1 wird hier nicht sortiert, da
innerhalb der Select-Klausel keine Sortierrichtung definiert wird, folglich werden
alle Instanzen des Typs Person nur nach ihrem Geburtstag sortiert.
select $p / name
order by $p / birthdate desc
where $p isa person
Codefragment 21 - Select-Expression als Beispiel für Sortierung bei Tupelkombination
36
3.5.2.2. Stringifying - Serialisierung von Tupeln
Als Stringifying wird der Prozess der Serialisierung von Tupeln zu ihrer
Repräsentation als Zeichenketten bezeichnet.
Die Serialisierung von Tupeln erfolgt elementweise, d.h. zu Beginn werden alle
Elemente in ihrer Zeichenkettenrepräsentierung konvertiert, durch Komma
getrennt und zu einer Zeichenkette zusammengefasst. Die Reihenfolge definiert
sich über den abstrakten Index innerhalb des ursprünglichen Tupel. Leere
Tupel erzeugen immer auch eine leere Zeichenkette.
Die Serialisierung von Sequenzen erfolgt ebenfalls komponentenweise, d.h. zu

Beginn werden alle Tupel wie oben beschrieben in ihre
Zeichenketterepräsentierung überführt durch das Zeichen #x0D getrennt und zu
einer Zeichenkette vereinigt. Stellt die Sequenz eine Sortierung zur Verfügung
bleibt diese während des Prozesses erhalten, andernfalls definiert sich die
Reihenfolge ebenfalls durch abstrakten Index der Tupel innerhalb der Sequenz.
3.5.3. Value-Expression und Function-Invocations
Als Value-Expression werden in TMQL alle Ausdrücke bezeichnet, welche

einen einzelnen Wert oder eine Wertmenge generieren. Diese Ausdrücke
generieren somit direkt eine Menge von Inhalten (Content) oder enthalten
einfache Literale, wie Konstanten oder Atome.
value-expression ::= value-expression infix-operator value-expression

value-expression ::= prefix-operator value-expression
value-expression ::= function-invocation
value-expression ::= content
Codefragment 22 - Value-Expression
Im Rahmen der Terminologie von TMQL werden verschiedene Konzepte

definiert, welche im Kontext eines solchen Ausdrucks Anwendung finden. Die
Definition der Umgebung erfolgt dabei gemäß dem Topic-Maps-
Modellierungsparadigmata, d.h. jede Umgebung definiert eine eigene Topic
37
Maps. TMQL beschreibt zusätzlich das Konzept einer Funktion und dessen
Unterkonzepte der binären und unären Operatoren. Neben den vordefinierten
Funktionen, wird dem Anwender die Möglichkeit der Konzeption eigener
Funktionen und Operatoren ermöglicht. Die Definition eigener Konzepte ist
Bestandteil der Environment-Klausel.
Der aktuelle Draft liefert eine Liste vordefinierter Operatoren, wie

mathematische Operatoren, Vorzeichen oder Zeichenkettenverknüpfungen,
sowie Vergleichsoperatoren und Funktionen, welche im Kontext einer Value-
Expression verwendet werden können.
Ein Funktionsaufruf wird über so genannte Function-Invocations realisiert,

welche neben der Item-Referenz auf das Topic der Funktion eine optionale
Liste von Parametern umfassen. Innerhalb der Parameterliste sind beliebige
Tupel-Expression oder Value-Expression erlaubt. Die folgende
Produktionsregel verdeutlicht den kompletten Sachverhalt.
function-invocation ::= item-reference parameters
Codefragment 23 - Function-Invocations
3.5.4. Wahrheitsausdrücke – Boolean-Primitive und Expression
Im Kontext der Filterung oder einer bedingten Auswahl von Elementen werden
Wahrheitsausdrücke verwendet. TMQL unterscheidet zwischen Ausdrücken
(Boolean-Expression) und Primitiven (Boolean-Primitive), ein Ausdruck kann
dabei genau eine Primitive enthalten oder eine Menge von Ausdrücken.
Wie in anderen Sprache üblich sind diese Art von Ausdrücken über den binären
Operator &(AND) oder |(OR) kombinierbar, die Auswertung der Ausdrücke
basiert auf den üblichen Regeln der Operatoren. Die Kombination mit dem
unären Operator not ist nur mit Primitiven gestattet. Die Verarbeitung solcher
Kombinationen erfolgt immer von links nach rechts, diese Routine kann nur
durch Verwendung von Klammern gesteuert werden.
38
boolean-expression ::= boolean-expression | boolean-expression |

boolean-expression ::= boolean-expression & boolean-expression |
boolean-expression ::= boolean-primitive
boolean-primitive ::= ( boolean-expression ) |
boolean-primitive ::= not boolean-primitive |
boolean-primitive ::= forall-clause | exists-clause
Codefragment 24 - Boolean-Expression und Primitive
Eine Primitive untersucht die Häufigkeit des Auftretens eines bestimmten

Sachverhalts durch Verwendung der Quantifizierungsoperatoren ∀ und ∃ . Die
Quantifizierungsoperatoren werden durch die beiden Schlüsselwörter every und
some repräsentiert. Für den Existenzquantor stehen zusätzlich die drei
Schlüsselwörter some, at least und at most zur Verfügung. Die Verwendung
von some wird als mengenfrei bezeichnet, da keine Unter- bzw. Obergrenze
definiert werden muss und das einmalige Erfüllen der nachfolgenden
Bedingung untersucht wird. At least und at most werden als mengenrestriktiv
bezeichnet, da sie die Menge der erfüllenden Tupel exakt spezifizieren. Das
Schlüsselwort exists wird verwendet, wenn die Erfüllung eines konkreten
Sachverhaltes nicht relevant ist, sondern einzig die Prüfung auf die Existenz
einer nicht leeren Sequenz von Tupeln gegeben ist.
forall-clause ::= every binding-set satisfies boolean-expression

exists-clause ::= quantifier binding-set satisfies boolean-expression
quantifier ::= some | at least integer | at most integer
exists-clause ::= exists content
Codefragment 25 - Verwendung von Quantifizierungsoperatoren
3.6. Query-Ausdrücke
Ein TMQL-Ausdruck wird als Query-Expression bezeichnet und kann eine der
drei Ausprägungsformen, Path-Expression (3.6.3), Select-Expression (3.6.4)
und FLWR-Expression (3.6.5), annehmen. Alle drei Ausprägungsformen
besitzen faktisch die gleiche Ausdrucksstärke, dies begründet sich dadurch,
dass sowohl der FLWR-, als auch der Select-Style, eine beliebige Menge von
Path-Expression im Kontext ihrer Klauseln verwenden. Die einzige Ausnahme
39
stellt die Generierung von XML- und Topic-Maps-Fragmenten dar, welches nur
dem FLWR-Style vorbehalten ist.
Die drei Ausprägungsformen können beliebig verwendet werden und

miteinander innerhalb einer komplexeren Anfrage verknüpft werden.
Der optionale Bestandteil einer Query-Expression, die Environment-Klausel,

ermöglicht die Definition zusätzlichen Wissens über die Ontologie. Dieses
ontologische Wissen besitzt allerdings nur im Rahmen dieser Anfrage eine
Gültigkeit.
Die effektiv verwendete Topic Maps bildet sich aus der Kombination der
Environment-Map (%%), sowie der gesetzten Topic Maps (%_). Die
Kombination ist dabei aber nur virtuell. Während der Verarbeitung werden
Anfragen an beide Topic Maps gestellt und deren Ergebnisse kombiniert.
3.6.1. Verarbeitungsmodell
Zu Beginn einer Evaluierung und Verarbeitung eines TMQL-Ausdruck generiert

die TMQL-Engine bzw. der TMQL-Parser eine Menge vordefinierter Variablen-
Bindings. Der genaue Ablauf dieses Prozesses ist nicht Bestandteil des
aktuellen Drafts und erfolgt für jede Implementierung individuell. Per Definition
stellt die Umgebungsvariable (%%) die einzige zwingend gebunden Variable
dieser Menge dar. Die zusätzliche Definition globaler Variablen erfolgt innerhalb
einer Environment-Klausel.
Die Environment-Klausel enthält dabei eine Menge von Direktiven und Pragma.
Als Direktive wird zusätzliches Wissen über die Ontologie der Topic Maps
bezeichnet. Die Direktiven werden als Topics in der Environment-Map
repräsentiert und müssen eine Instanz des abstrakten Topic-Typs tmql:ontology
sein. Im Gegensatz zu einer Direktive stellt ein Pragma eine erweiterte Kontrolle
über den Evaluierungsprozess selber dar. Aktuell wird nur der Einfluss auf die
Transitivitätseigenschaft innerhalb der Topic Maps spezifiziert. Die
Repräsentierung eines Pragma innerhalb der Laufzeitumgebung bleibt offen.
40
Nach der Definition der Environment-Map erfolgt die Verarbeitung der Query-
Expression getrennt im Kontext verschiedener Variablen-Bindings (3.6.2).
Während dieses Prozesses erzeugt jedes neue Binding eine Menge von
Variablen-Wert-Beziehung und legt diese auf einen Variablen-Stack ab. Diese
Variablendefinitionen bilden den Kontext der aktuellen Verarbeitung und werden
am Ende der Verarbeitung wieder entfernt.
Tritt während der Verarbeitung einer Fehler auf, verursacht durch einen
ungültigen Ausdruck, wechselt die Engine in einen Fehlerzustand und
benachrichtigt die darüber liegende Anwendung. Form und Art dieser Nachricht
wird aktuell nicht spezifiziert, die Umsetzung erfolgt in Abhängigkeit des
Frameworks bzw. der üblichen Konzepte der verwendeten
Programmiersprache.
Ein gültiger Ausdruck liefert per Definition eine Menge von Ergebnissen an die
Umgebung bzw. die darauf aufbauende Anwendung zurück. Aktuell ist die Art
und Weise des Zugriffs auf diese Ergebnismenge und der Zeitpunkt der
Rückmeldung kein Bestandteil des Drafts und ist wiederum von der
Implementierung der Engine abhängig.
41
Abbildung 3 - schematische Darstellung des Verarbeitungsmodells von TMQL-Anfragen
3.6.2. Variablen und Variablenbindung
Das Konzept der Variablen in TMQL ist ähnlich zu anderen

Programmiersprachen. Während der Evaluierung eines Ausdrucks werden
Variablen verwendet um aktuelle Werte der Verarbeitung zu speichern. Die
Bindung erfolgt innerhalb eines Variable-Assignment. Jede Variable kann,
abhängig vom gewählten Präfix, an einfache Werte, wie Literale oder Topic-
Maps-Elemente, sowie an Tupel oder Tupelsequenzen gebunden werden.
Variablennamen müssen folglich immer mit einem der definierten Präfix ($, %
oder @) beginnen und können mit einer beliebigen Anzahl von einfachen
Anführungszeichen (Primes) enden. Weiter sind alle alphanumerischen
Zeichen, sowie der Unterstrich und die Raute, erlaubt. Variablen deren Namen
sich nur in der Anzahl der nachstehenden Primes ` unterscheiden, müssen an
verschiedene Werte gebunden werden. Der Präfix $ signalisiert der Engine, das
die entsprechende Variable nur an atomare Werte und Topic-Maps-Elemente
42
gebunden werden darf. Die Bindung von Tupeln ist nur an Variablen mit dem
Präfix @ gestattet, Sequenzen von Tupel hingegen nur an Variablen mit dem
Präfix %.
Im Kontext einer jeden Verarbeitung definiert die TMQL-Engine eine Menge

spezieller vordefinierter Systemvariablen. Eine Neubindung dieser Variablen an
Werte innerhalb eines jeden Ausdrucks ist untersagt und führen zwangsweise
zu einem Fehler. Eine Ausnahme stellen die Projektions- und Indexvariablen
dar.
Der Zugriff auf die vordefinierten Konzepte, wie die Funktionen und Operatoren,
wird über die Umgebungsvariable %% realisiert. Die aktuell gebunden Topic
Maps der Anfrage wird an die Systemvariable %_ angehangen und als
Standardwert im Rahmen einer fehlenden From-Klausel des Select-Style
verwendet. Optional angegebene Topic Maps in der Klausel erzeugen ein Kopie
dieser Variable. Das im Kontext eines Ausdrucks aktuell referenzierte Tupel
wird automatisch an die Variable @_ gebunden, als automatische Projektionen
der Werte innerhalb dieses Tupel stehen die Variablen $0 bis $n zur Verfügung,
wobei n die höchste gültige Stelle innerhalb des Tupel widerspiegelt.
Eine besondere Rolle nehmen die anonymen Variablen $_ ein, sie können als
Platzhalter innerhalb eines Ausdruckes Verwendung finden, wo der konkrete
Wert der Variable als irrelevant angesehen wird. Anonyme Variablen können
nur geschrieben werden, das Auslesen der gebunden Werte führt zu einem
Fehler in der Verarbeitung.
Die Gültigkeit von Variablen wird durch den definierenden TMQL-Ausdruck

festgelegt und beginnt mit der Variablenbindung innerhalb der
Variablendefinition. Die vordefinierten Systemvariablen besitzen immer eine
globale Gültigkeit.
Jede Variable kann lokal und zu jedem Zeitpunkt nur an einen Wert gebunden
werden, die Bindung an neue Werte ist nur innerhalb einer neuen
Variablendefinition (Binding) möglich. Die TMQL-Engine realisiert für jede
43
Verarbeitung einen Stack von Bindings. Erfolgt die Definition und Wertbindung
der Variable, wird ein neu generiertes Variablenset auf den Stack gelegt.
Verliert die Variable ihre Gültigkeit wird das Set vom Stack entfernt, jede
Variable besitzt daher pro Zeiteinheit genau eine gültige Wertausprägung. Die
Evaluierung jedes Binding erfolgt getrennt von allen anderen. Generiert ein
TMQL-Ausdruck in diesem Kontext ein leeres Tupel, so wird der Standardwert
undef verwendet.
3.6.3. Path-Expression
Konzeptionell behandelt die Path-Expression den Ansatz der Navigation durch

den abstrakten Graphen einer Topic Maps, sowie die Filterung bzw. Projektion
auf bestimmte Werte innerhalb eines Ergebnistupel.
Die Navigation erfolgt schrittweise auf einer Menge definierter Achsen (3.4.2)
durch den Topic-Maps-Graphen. Die Bezeichnung als Achsen ist etwas
irreführend, da sie semantisch nicht im Sinne eines Koordinatensystems zu
verstehen sind, sondern vielmehr als Kantenbezeichnungen, bzw. abstrakte
Beziehungen zwischen Elementen innerhalb einer Topic Maps. Ausgangspunkt
einer Navigation kann ein einziges Topic-Maps-Element oder ein atomarer Wert
sein, sowie eine Tupelsequenz. Die Verwendung von Variablen innerhalb einer
reinen Path-Expression ist nicht gestattet.
Zur Nachverarbeitung der Ergebnismenge der gesamten Navigation stellt

TMQL die optionale Verwendung von Filtern und Projektionen zur Verfügung.
3.6.3.1. Projektion und Filterung
Eine Filterdefinition erfolgt auf Basis von Bedingungen bzw.

Wahrheitsausdrücken (3.5.4). Während der Prüfung wird jedes Tupel iterativ
einzeln gegen die Bedingungen evaluiert und bei Erfüllung in die neue
Ergebnismenge eingefügt. Die neue Sequenz besitzt somit maximal dieselbe
Mächtigkeit wie die Ursprungssequenz.
44
filter-postfix ::= [ boolean-primitive ]
Codefragment 26 - Filterdefinition
Auf Basis des Non-Canonical Level stellt die Grammatik einige spezielle
Bedingungen zur Verfügung, wie die Angabe der abstrakten Indizes der
Tupelsequenz, sowie die explizite Typprüfung einzelner Elemente. Zur
Interpretation der abstrakten Indizes, wird die Systemvariable $# verwendet,
welche während einer Iteration die aktuelle Stelle der Tupelsequenz speichert.
Der Wert dieser Variable wird bei jedem Schritt innerhalb einer Bedingung
gegen die definierten Bereichsgrenzen bzw. Indizes geprüft. Diese
Herangehensweise kostet im Vergleich zu einem direkten Zugriff auf die
Elemente, eventuell mehr Rechenzeit, schützt allerdings vor einem Zugriff
außerhalb der Bereichsgrenzen möglicher Indizes.
filter-postfix ::= // anchor

[ ^ anchor ]
filter-postfix ::= [ integer ]
[ $# == integer ]
filter-postfix ::= [ integer-1 .. integer-2 ]
[ integer-1 <= $# & $# < integer-2 ]
Codefragment 27 - spezielle Produktionsregeln für Filterdefinition auf dem Non-
Canonical Level
Als Projektion wird die Extraktion einzelner Komponenten der Ergebnismenge

bezeichnet, welche abschließend zu einer neuen Sequenz zusammengefasst
werden. Projektionen werden unter Verwendung von Tupel-Expression (3.5.2)
definiert, welche in Abhängigkeit der Mächtigkeit der enthaltenen Tupel mehrere
indexabhängige Projektionen beschreiben kann. Die Verarbeitung erfolgt iterativ
für jede Projektion getrennt und resultiert in einer Menge von Sequenzen,
welche abschließend zu einer einzigen Sequenz zusammengefasst werden. Die
Verschachtelung von Projektionen ist nicht erlaubt und führt während der
Verarbeitung zu Fehlern. Die Angabe von Filtern innerhalb einer Projektion ist
erlaubt.
// opera ( . / name [ @ opus ], . <- work [ ^ is-composed-by ])
Codefragment 28 - Beispiel für eine Kombination von Projektion und Filtern
45
Per Definition stellen Filterung und Projektion stabile Operationen dar, d.h.
eventuell vorhandene Sortierungen innerhalb der Eingangssequenz bleiben
erhalten, mit Ausnahme der Definition einer neuen Sortierung innerhalb der
Projektion selber.
3.6.3.2. Predicate-Invocations
Eine aus dem TMCL bekannte Beschreibung von Assoziation, die Predicate-
Invocation, stellen eine besondere Form von Path-Expression in TMQL dar. Sie
ermöglichen die Suche nach Assoziationen eines speziellen Typs bzw. eine
Menge von Rollen-Spieler-Kombinationen. Die Definition des Typen der
Assoziation erfolgt als Item-Referenz innerhalb des Ausdrucks, gefolgt von
einer Liste von Rollen-Spieler-Kombinationen. Die Spieler werden in diesem
Kontext als Value-Expression formuliert. Das folgende Codefragment zeigt die
syntaktische Struktur einer Predicate-Invocation in TMQL.
predicate-invocation ::= anchor (<anchor: value-expression>[ , ... ] )
is-located-in (location: leipzig, building: university-of-leipzig)

Codefragment 29 - Produktionsregel und Beispiel einer Predicate-Invocation
Ergebnis der Verarbeitung ist eine Sequenz von Assoziation-Items, welche

gemäß dem TMDM eine Instanz des definierten Typs darstellen. Die
Verarbeitung erfolgt schrittweise. Der Prozessor verarbeitet zu Beginn, alle
Rolletyp-Spieler-Kombinationen getrennt, das Ergebnis einer jeden
Kombination ist eine Sequenz von Topic-Elementen als potentielle Spieler der
Assoziation. Jeder potentielle Spieler muss in Folge innerhalb des
durchsuchten Assoziationstypen eine Rolle vom angegebenen Typ bzw. eines
seiner Untertypen einnehmen.
Per Definition wird die Operation als strikt angesehen, da sie keine
Assoziationselemente liefert, welche mehr oder andere Rollentypen beinhalten
als innerhalb des Ausdruckes beschrieben wurde. Durch Angabe der optionalen
Ellipse (…) besteht die Möglichkeit diese Operation für den Prozessor als nicht
strikt zu spezifizieren.
46
Im Rahmen des Non-Canonical Level beinhaltet die Sprache TMQL zwei

spezielle Predicate-Invocations, welche sich direkt auf den Assoziationstyp der
Typ-Instanz- bzw. Supertyp-Subtyp-Beziehung des TMDM beziehen. Die
Verwendung der Ellipse in diesem Kontext ist nicht gestattet bzw. macht
semantisch keinen Sinn.
path-expression ::= simple-content-1 iko simple-content-2

tm:subclass-of ( tm:subclass : simplecontent-1 ,
tm:superclass : simplecontent-2 )
path-expression ::= simple-content-1 isa simple-content-2
tm:type-instance ( tm:instance : simplecontent-1 ,
tm:type : simple-content-2 )
Codefragment 30 - spezielle Predicate-Invocation für Typ-Instanz- und Supertyp-Subtyp-

Beziehung
3.6.4. Select-Expression – der SQL-Style
Als zweite Ausprägung einer Query-Expression unterstützt der aktuelle Draft

einen Expressions-Typ, der syntaktisch stark an den bestehenden Standard
SQL angelehnt ist. Ein solcher Ausdruck verwendet nur die bereits definierten
Expression, mit Ausnahme der entsprechenden Schlüsselwörter.
select-expression::= SELECT <value-expression>

[FROM value-expression]
[UNIQUE]
[OFFSET value-expression]
[LIMIT value-expression]
Codefragment 31 - Grammatikregel der Select-Expression
Im Gegensatz zu SQL stellt bei TMQL die Select-Klausel, dass einzige nicht
optionale Element eines Query dar. Alle anderen Klauseln werden vom Draft
mit Standardwerten hinterlegt, welche unter der Voraussetzung der fehlenden
Definition, automatisch von der Engine eingefügt bzw. verwendet werden.
Der Kontext der Verarbeitung definiert sich über die From-Klausel, fehlt eine
solche Klausel wird automatisch die im Environment definierte Topic Maps
verwendet. Als Kontexttyp werden nur Topic Maps gemäß des TMDM(2.1)
47
unterstützt, wobei eine Menge von Tupel automatisch als temporäre Topic
Maps interpretiert wird. Der zu verarbeitende Kontext wird an die
Systemvariable %_ gebunden.
Als zweiter Schritt erfolgt die Evaluierung der Offset- und Limit-Klauseln. Die
Evaluierung beider Klauseln muss in einer nicht-negativen Ganzzahl (Integer)
resultieren, als einzige Abweichung dieser Regelung ist der Null-Wert erlaubt.
Sofern die entsprechenden Klauseln existieren, werden die Ergebnisse zur
späteren Interpretation an die Systemvariablen $_lower und $_limit gebunden,
andernfalls werden die sprachspezifischen Standardwerte angenommen. Ein
Standardwert für Limit existiert nicht und die Variable bleibt entsprechend
ungebunden.
Die eigentliche Verarbeitung und Interpretation der Anfrage erfolgt durch

Auswertung der Where-Klausel. Während dieses Prozess werden alle nicht
gebunden Variablen innerhalb der Klausel ermittelt und zu einem abstrakten
Binding-Set(3.6.2) zusammengefasst. In Folge dessen erfolgt die iterative
Bindung möglicher Wertausprägungen aus dem aktuellen Kontext der From-
Klausel an die entsprechenden Variablen. Eine Bindung erfolgt dabei in
Abhängigkeit der Erfüllung des Wahrheitsausdrucks innerhalb der Where-
Klausel. Unter der Annahme einer nicht leeren Ergebnismenge, erfolgt die
Evaluierung anhand der Select-Klausel, im Allgemeinen bedeutet dies die
Projektion bzw. Navigation zum gewünschten Ergebnis. Enthält die Select-
Klausel eine Variable, welche nicht innerhalb der Where-Klausel definiert wird,
wird zwangsweise ein Fehler geworfen, da eine Zuordnung zu einem Wert
unmöglich ist.
Eine gültige Select-Klausel vorausgesetzt, wird pro Iterationsschritt maximal

eine Tupelsequenz generiert, welche zur Ermittlung des Gesamtergebnis zu
einer neuen Sequenz zusammen gefasst wird, Duplikate bleiben dabei vorerst
erhalten.
Wichtig in diesem Verarbeitungsprozess sind die Unique- und Order-Klauseln.

Die Order-Klausel definiert die optionale Sortierung der Abfolge der iterativen
48
Bindung der Variablen im Kontext der Where-Klausel und erfolgt anders als bei
SQL nicht nach der Selektion der Daten. Die Unique-Klausel wird abschließend
verwendet und durch eine spezielle TMQL-Funktion zur Entfernung von
Duplikaten realisiert.
Der letzte Schritt der Verarbeitung stellt die Auswahl des Selektionsfensters
durch die gespeicherten Variablen $_lower und $_limit dar.
Abbildung 4 - Abstraktion des Verarbeitungsprozesses einer Select-Expression
49
3.6.5. FLWR-Expression
Der dritte unterstützte Typ besitzt eine hohe syntaktische Ähnlichkeit zu dem
Kontrollkonstrukt der For-Schleifen moderner Skript- bzw.
Programmiersprachen, wie Java oder Ruby. Der FLWR-Style besitzt dadurch
ein erhöhtes Maß an Kontrolle über die Bindung der Variablen, sowie die Art
des generierten Content. Als einziger Typ ermöglicht dieser Style die
Generierung von Topic-Maps-Fragmenten, gemäß des CTM-Standards(2.3.1),
bzw. von XML-Fragmenten. Im Falle eines XML-Fragmentes werden nicht
atomare Werte, gemäß des XTM-Standards(2.3.2) serialisiert und in die XML-
Fragmente eingebettet. Atomare Werte hingegen werden als reiner Text in das
XML-Dokument eingebettet.
flwr-expression::= [FOR binding-set]

RETURN content
Codefragment 32 - Grammatikregel des FLWR-Style
Innerhalb einer einzigen FLWR-Expression kann die Verwendung einer Vielzahl

von For-Klauseln und somit die Bindung von Variablen erfolgen. Die
Verarbeitung dieser Menge von Bindings erfolgt in lexikalischer Reihenfolge
und erzeugt für jede For-Klausel eine Menge möglicher
Variablenwertausprägungen, welche ähnlich zum Select-Style iterativ
verarbeitet werden. Als Ergebnis der Verarbeitung aller For-Klauseln wird eine
Sequenz von Bindings erzeugt, welche durch Angabe der optionalen Order-
Klausel sortiert werden könnte. Fehlt die For-Klausel komplett ist die
resultierende Sequenz leer.
Als zweiter Schritt erfolgt die Prüfung jeder Wertkombination der Sequenz
gegen die Wahrheitsausdrücke innerhalb der Where-Klausel, fehlt eine solche
Klausel erfolgt lediglich die Existenzprüfung gegen null. Bei erfolgreicher
Prüfung wird die Wertkombination im Kontext der Return-Klausel verarbeitet.
50
Ergebnis einer jeden Iteration ist eine Sequenz von Tupeln, welche unter
Verwendung des Verknüpfungsoperators ++ zu einer komplexen Sequenz
zusammengefasst werden. Generierte XML-Fragmente werden in einem XML-
Dokument gekapselt. TM-Fragmente werden als eigenständige Topic Maps
interpretiert und unter Verwendung der Merge-Regeln des TMDM zu einer
Topic Maps zusammengefasst.
FLWR-Expression
existiert For-
Ja
Klausel?
Erzeugung aller
Bindingsets Ja
@_
existiert weitere
For-Klausel?
Bindingstack
Nein Nein
existiert Order-By- Sortierung der

Klausel? Bindings
@_
Nein
@_
Nein existiert Where-
Klausel?
Ja
Test gegen
Test gegen null Wahrheits- Ja
ausdruck
Evaluierung der existiert weiteres

Return-Klausel Binding?
Verknüpfen der
Nein
Sequenzen
Ergebnis
Abbildung 5 - Abstraktion des Verarbeitungsprozesses einer FLWR-Expression
51
4. Vergleich zu anderen Anfragesprachen – Toma und Tolog
4. Vergleich zu anderen Anfragesprachen - Toma und Tolog
Die Idee der Spezifikation und Entwicklung einer einheitlichen Sprache zur
Manipulation und Selektion von Daten aus Topic Maps existiert bereits seit
einigen Jahren. Erste Konzeptionen entstanden bereits vor dem aktuellen
TMQL-Draft, wie das einleitend erwähnte Tolog.
4.1. Tolog und die Parallelen zu TMQL
Tolog spezifiziert eine der ersten Anfragesprache für Topic Maps und besitzt im
Kontrast zu TMQL aber nur eine eingeschränkte Funktionalität. Konzeptuell
basiert die Formulierung eines Tolog-Query auf einer Menge formaler
Aussagen über Assoziationen zwischen einzelnen Informationselementen. Die
formale Beschreibung solcher Beziehungen besitzt eine starke syntaktische
Ähnlichkeit zur Struktur der beschriebenen Predicate-Invocation(3.6.3.2) von
TMQL.
date-of-birth($PERSON : person, $DATE : date)?
Codefragment 33 - einfacher Tolog-Query
Optional besteht die Möglichkeit der logischen Verknüpfung einzelner

Aussagen, sowie die Abfrage komplexer Sequenzen durch Kombination
einzelner Aussagen und die Prüfung einzelner Wertausprägungen.
Durch Verwendung einer Variablen im Kontext zweier aufeinander folgender

Aussagen innerhalb einer Abfrage, erfolgt die Verarbeitung der zweiten
Aussage auf Basis der Ergebnisse der Evaluierung des ersten Prädikates. Die
Wertausprägung der konkreten Variablen wird also durch die Bindung des
ersten Prädikates stark eingeschränkt. Als Beispiel sei der folgende Query
aufgeführt, welcher als Ergebnis eine Sequenz aus Tupel mit je zwei Werten
liefert. Begründet durch dich Bindung der Variable $PERSON im Kontext des
ersten Prädikates an alle Personen mit Geburtsstadt Leipzig, stellt $PERSON
innerhalb des zweiten Prädikates eine nicht freie Variable dar.
52
city-of-birth($PERSON : person, leipzig : city),

date-of-birth($PERSON : person, $DATE : date)?
Codefragment 34 - Verknüpfung von Prädikaten in Tolog
Eine zweite Parallele zum aktuellen TMQL-Draft bildet die Verwendung des
Schlüsselwortes SELECT. Konzeptuell orientiert sich die Formulierung solcher
Anfragen an SQL und realisiert ein ähnliches Vorgehen wie der Select-
Style(3.6.4) von TMQL.
select $A, count($B) from

composed-by($A : composer, $B : opera )
order by $B desc?
Codefragment 35 - Select-Style von Tolog
Einige Beziehungen zwischen Topics einer Topic Maps werden nicht direkt über
eine existierende Assoziation beschrieben, sondern definieren sich über die
Verkettung mehrerer Assoziationen. Die Verwendung solcher impliziter
Beziehungen zwischen Elementen können innerhalb eines Tolog-Query durch
Regeln definiert werden. Die Prüfung der Werte erfolgt anhand des daraus
generierten temporären Funktionsprädikates. Die Definition solcher implizierter
Beziehung in TMQL wird durch die Möglichkeit der Definition eigener
Funktionen innerhalb Environment-Klausel realisiert. Die Interpretation der
neuen Funktion erfolgt durch einen registrierten Interpreter innerhalb der
Laufzeitumgebung und ist nicht Bestandteil des Drafts. Syntaktisch orientieren
sich beide Ansätze am TMCL-Standard und sind somit ähnlich.
Zusammenfassend lässt sich ein hoher Grad der Überschneidung in Syntax

und Funktionalität zwischen beiden Sprachen erkennen. Es ist festzustellen,
dass für jedes Konstrukt von Tolog ein äquivalentes, aber eventuell syntaktisch
differierendes, Konstrukt in TMQL existiert. Der Umkehrschluss ist nicht
möglich. Viele Konzepte von TMQL werden von Tolog nicht realisiert, wie der
FLWR-Style bzw. das Navigationskonzept.
53
4.2. Toma und TMQL
Im Rahmen der Diskussionen um den aktuellen Draft von TMQL differiert die
Meinung über Syntax und Semantik. Daraus resultierend entwickelte sich
parallel zum beschriebenen Draft ein syntaktisch differierender Ansatz.
Konzeptuell stellt der Toma-Draft eine starke Vereinfachung des
Möglichkeitsraums von TMQL dar und reduziert den Draft um eine Vielzahl von
Funktionen und syntaktischen Ausdrücken, wie dem FLWR-Style. Das
Designkonzept von Toma orientiert sich an existierenden Konzepten, wie der
Objektorientierung und TMQL bzw. SQL.
Toma reduziert die Möglichkeiten der Abfrage auf einen Typ, welche dem
Select-Style(3.6.4) von TMQL entspricht, wobei die verwendete Syntax sich
noch enger am SQL-Standard orientiert.
SELECT [ ALL | DISTINCT ] navigation_list

[ WHERE formula ]
[ { UNION | INTERSECT | EXCEPT } [ ALL ] other_select ]
[ ORDER BY expr1 [ ASC | DESC ] [, expr2 [ ASC | DESC ] ...] ]
[ LIMIT integer ]
[ OFFSET integer ];
select $person.name where $person.oc(date_of_birth) = “01.01.1970“;
Codefragment 36 - Select-Style von Toma mit einem simplen Beispiel
Ein fundamentaler Bestandteil des Toma-Draft sind Pfadausdrücke, ähnlich

dem Navigationskonzept von TMQL. Inhaltlich weißt dieses Navigationskonzept
einen hohen Grad der Übereinstimmung zu TMQL auf und unterstützt die
größte Zahl der spezifizierten TMQL-Achsen. Im Unterschied zu TMQL besitzt
das Konzept von Toma keine Richtung und wird über dem Kontext des
aktuellen Schritts definiert. Voraussetzung der Realisierung eines solchen
Konzeptes ist die Typisierung von Variablen im Kontext der Toma-Engine und
die typenspezifische Zuordnung der Navigationsachsen. Jeder einzelne
Navigationsschritt wird über den Punkt-Operator (.) gefolgt vom Achsenname
eingeleitet. Die typenspezifische Bindung und der Achsennamen orientiert sich
an den TMQL-Achsen(3.4.2), welche durch die fehlende
Richtungsunterstützung um weitere Namen für Instanzen, Untertypen und
54
Varianten erweitert werden. Die folgende Tabelle bietet eine kleine Übersicht
über mögliche Namen.
Namen Bedeutung
.si Subject-Identifier
.sl Subject-Locator
.id Item-Identifier
.oc Occurrences
.name Names
.var Variants
.type Typen
.instance Instanzen des Typs
.super Supertypen des Typs
.sub Subtypen des Typs
.sc Scope
.player Spieler der Assoziation
.role Rollentypen der Assoziation
.reifier reifizierendes Topic
.data Wert der Eigenschaft
Tabelle 5 - Achsennamen von Toma
Äquivalent zum Filterkonzept von TMQL unterstützt Toma eine Menge von
Filterfunktionen. Im Gegensatz zu TMQL ist die Verwendung der Filter nach
jedem Navigationsschritt möglich. Informationselemente können dabei anhand
des Typs, der abstrakten Indizes der Sequenz, den konkreten Werten, sowie
ihres Scope gefiltert werden. Die Interpretation der Filter orientiert sich genau
wie TMQL am TMDM.
Die Navigation im Kontext von Assoziation wird durch den Zeigeroperator (->)
eingeleitet und realisiert den Zugriff auf die Spieler und Rollentypen der
konkreten Ausprägung. Ähnlich zum Konzept der indirekten Verkettung von
Tolog, unterstützt auch Toma eine Verkettung von Spieler über Assoziationen
um eine direkte Beziehung zwischen Elementen der Topic Maps kürzer
formulieren zu können. Die anonyme Variable $$ dient in diesem Ausdruck als
Platzhalter.
id(“leipzig”).$$<-(place_of_birth)->$$
.$$<-(date_of_birth)->$$ = $topic;
Codefragment 37 - Konzept der Verkettung von Spielern
55
Zusammenfassend lässt sich auch hier ein hoher Grad der Überschneidung
zwischen Toma und TMQL erkennen, was durch den gemeinsamen Ursprung
begründet scheint. Dem Modellierungsziel der Einfachheit von Toma
verschuldet, sieht der aktuelle Draft nur die Unterstützung des Select-Style vor,
eine Erweiterung um den normalen Path-Style ist denkbar. Funktional
unterstütz der TMQL-Draft eine Vielzahl weiterer Konzepte, welche von Toma
nicht realisiert werden, wie die Quantifizierungsoperatoren (3.5.4).
56
5. Analyse der Kritikpunkte des aktuellen Drafts
Da es sich bei TMQL nicht um einen festen Standard handelt, sondern lediglich
um eine in Standardisierung befindliche Abfragesprache, ist der aktuelle Draft
keinesfalls als perfekt oder vollständig anzusehen. Einige Autoren definieren
den aktuellen Draft als nicht perfekt in Hinsicht auf einige Aspekte der dritten
Grammatikebene.
Aktuell umfasst der Draft eine Vielzahl von Funktionen und syntaktischen
Varianten, welche die Implementierung erschweren könnte und die
Verwendung eines Canonizer bedingt.
In diesem Kapitel werden die Bestandteile des aktuell vorliegenden Drafts

analysiert, sowie eine persönliche Einschätzung gegeben.
5.1. Kritikpunkt - Navigationsachsen
Auf Basis des TMDM lassen sich die bereits in früherem Kapitel
angesprochenen Achsen für TMQL definieren und umsetzen. Einige der
Achsen erscheinen im Kontext einer Implementierung des Standards allerdings
als nicht eindeutig bzw. führen zu hohen Kosten. Einige der Achsen sind
eventuell semantisch unverständlich und könnten entsprechend ersetzt bzw.
entfernt werden.
5.1.1. Die atomify-Achse
Als größte Problematik wird die atomify-Achse, vor allem in der

Rückwärtsrichtung, angesehen. Eine solche Navigation konvertiert einen
atomaren Wert in alle Occurrences oder Namen, welche als Wertausprägung
genau diesen Wert besitzen. Die Mehrdeutigkeit ist offensichtlich, da die
genaue Interpretation eines solchen Ansatzes für eine TMQL-Engine nicht
spezifiziert wird. Für die Interpretation eines Wertes sind theoretisch genau zwei
Ansätze möglich.
57
Der erste Ansatz würde den aktuellen Wert als datentypfrei bzw. vom Datentyp
irrelevant verwenden, d.h. die TMQL-Engine überprüft schrittweise alle
Occurrences bzw. Namen aller Topics innerhalb der Topic Maps und vergleicht
deren Wertausprägungen mit dem zu deserialisierenden Wert. Bei sehr großen
Topic Maps dürfte sich diese Variante als sehr langsam und teuer
herausstellen.
Die zweite Variante besteht in der Typerkennung durch die TMQL-Engine. Die
Typerkennung erfolgt dabei entweder automatisch oder manuell über einige
Bestandteile des aktuellen Drafts. Eine automatische Erkennung auf Basis des
Wertes ist allerdings keinesfalls trivial. Im Rahmen dieser Arbeit wurde eine
Bibliothek für die Programmiersprache Java entwickelt, welche eine
automatische Erkennung des Datentyps, in diesem Kontext Java-Datentypen,
sowie die Erzeugung einer Instanz dieses Typs mit dem Wert ermöglicht.
Bereits hier zeigten sich zwei wesentliche Probleme. Das erste Problem besteht
in der Referenz zwischen den Java-Datentypen und den TMDM-Datentypen,
innerhalb einer Topic Maps. Das zweite Problem besteht in der eigentlichen
Erkennung des Datentyps durch den Serialisierer. Bereits bei numerischen
Werten ist eine eindeutige Erkennung nicht möglich und somit nicht produktiv
einsetzbar. Wie in jeder Sprache existieren verschiedene numerische Typen,
welche an der reinen Wertausprägung nicht immer erkennbar sind und sich nur
im abgedeckten Wertebereich unterscheiden, wie Ganzzahlen oder
Fließkommazahlen. Dieses Problem scheint noch lösbar, allerdings verstärkt
sich das Problem zusätzlich durch die Mächtigkeit des Wertebereichs, wie 32-
Bit-Integer- oder 64-Bit-Long-Werte. Die Trennung einer Long-Zahl mit einem
Wert innerhalb des Wertebereichs einer Integer-Zahl (im Allgemeinen unter
65535) von der gleichen Integer-Zahl ist faktisch unmöglich. Das Problem
erscheint im Rahmen einer Anfragesprache durchaus als nichtig, bezogen auf
eine spätere Erweiterung um die Aspekte einer Manipulationssprache (Topic
Maps Manipulation Language) kann sich dieser Fakt zu einem Problem
entwickeln. TMML sollte äquivalent zu SQL auf der Anfragesprache aufbauen,
das bedeutet allerdings, dass genau das genannte Problem betrachtet werden
muss. Das Problem beschränkt sich aber nicht nur auf numerische Werte,
58
sondern betrifft auch die Trennung zwischen Zeichenketten und der

Repräsentation eines Objektes als solches. Als Beispiel sei hier das ISO-
Datumsformat erwähnt. Dem Designer einer Topic Maps ist es frei das Datum
eines historischen Ereignisses als Namen des zugehörigen Topics zu
modellieren. Modelliert er zusätzlich eine Occurrences für historische Personen
als solches, würde ein Serialisierer den Namen nicht erkennen, sondern zu
einem Datum konvertieren.
Die Referenz zwischen Topic-Maps-Datentypen und Datentypen einer

Programmiersprache stellt ein in Ansätzen lösbares Problem dar, welches
allerdings ein hohes Maß an Konfiguration erfordert. Der angestrebte
Lösungsansatz definiert eine Abbildung von Java-Datentypen auf XSD-
Datentypen. Diese Abbildung wird momentan über eine XML-Datei realisiert,
unter deren Verwendung die TMQL-Engine den erkannten Datentyp in einen
XSD-Datentyp übersetzt.
Das folgende Codefragment zeigt die XML-Schema-Definition der

angesprochenen XML-Datei.
<complexType name="entryNode">
<attribute name="type" type="anySimpleType" default="*" />
<attribute name="class" type="string" />
<attribute name="serializer" type="string" use="optional" />
<attribute name="deserializer" type="string" use="optional" />
</complexType>
<complexType name="mappingsNode">
<sequence>
<element type="entryType" />
</sequence>
</complexType>
<complexType name="defaultNode">
<sequence minOccurs="1" maxOccurs="1">
<element type="entryType" />
</sequence>
</complexType>
<complexType name="datatypesNode">
<all>
<element name="mapping" type="mappingsNode" />
<element name="default" type="defaultNode" />
</all>
</complexType>
<element name="datatypes" type="datatypesNode" />
Codefragment 38 - XSD-Definition der Abbildung von Java-Datentypen auf XSD-

Datentypen
59
Erste Testdurchläufe mit dem Serialisierer und der definierten XML-Datei

waren, bis auf die oben bereits beschriebenen Probleme der automatischen
Typerkennung, erfolgreich. Hauptproblem bei diesem Ansatz bleibt allerdings
die Annahme, dass alle Topic-Maps-Occurrences auf XSD-Datentypen
aufbauen. Eine solche Festlegung ist allerdings kein Bestandteil des TMDM. In
TMCL werden in der Regel XSD-Datentypen verwendet, allerdings ist auch dies
kein Bestandteil des TMCL-Standards, da die Verwendung einer beliebigen
URL als eindeutige Referenz auf den Datentyp legitim ist. Die fehlende
Standardisierung macht den beschrieben Ansatz unkomfortabel und erfordert
die erneute Anpassung der Konfigurationsdatei für jede Topic Maps.
Durch die optionale Definition des zu verwendeten Datentyps über das Pattern
^^ liefert der aktuelle Draft einen eigenen möglichen Lösungsansatz. Die
Lösung ist aber nur bedingt verwendbar, da die optionale Angabe keine
Sicherheit über die tatsächliche Verwendung liefern kann, sie bietet aber die
Möglichkeit, denselben Wert auf verschiedene Datentypen abzubilden, wie das
folgende Beispiel zeigt.
"42"^^xsd:integer # integer
"http://example.org/something"^^xsd:string # string
"http://example.org/something"^^xsd:anyURI # iri
"w3 0wn u"^^what:ever # what:ever
Codefragment 39 - manuelle Typdefinition innerhalb eines TMQL-Ausdruck[13]
Zusammenfassend ist erkennbar, dass keine der beiden theoretischen

Lösungsansätze durchweg zufriedenstellende Ergebnisse liefern kann. Bei der
Deserialisierung treten ungewollte Mehrdeutigkeiten auf bzw. erscheinen
Ergebnisse für den Nutzer nicht intuitiv. Die Serialisierung wirft ähnliche
Probleme, sowie die Frage der Notwendigkeit auf. Eine Serialisierung in einen
Datentyp der jeweiligen Sprache ist nur über den angesprochenen Serialisierer
möglich, welche durch den massiven Grad an Konfigurationsaufwand ein
geringes Maß an Komfort aufweist. Als Beispiel sei hier erneut die Verwendung
des Datumsformat genannt, welche verschiedene Repräsentationen als
Zeichenkette besitzt, abhängig von der Genauigkeit und Lokalisierung.
60
Die Frage der Notwendigkeit einer solchen Implementierung stellt sich

zunehmend im gleichen Kontext. Eine TMQL-Engine besitzt die Notwendigkeit
die Werte in verschiedenen Formaten zurückzugeben, allerdings macht es
kaum Sinn bzw. bringt es keinen Mehrwert, diese direkt in der eigentlichen
Anfrage zu definieren. Folglich ist eine Implementierung dieser Achse sehr
fehleranfällig besitzt auf der anderen Seite aber keinen relevanten Mehrwert für
den Nutzer nach außen. Eine interne Abbildung durch die TMQL-Engine bleibt
dabei Aufgabe der Engine und ist abhängig von der eingesetzten
Programmiersprache.
5.1.2. Die characteristics-Achse
Ein weiterer Gegenstand der aktuellen Diskussion ist die characteristics-Achse.

Gemäß der Spezifikation ermöglicht eine Implementierung dieser Achse die
Navigation von einem Topic hin zu seinen Eigenschaften und Namen bzw.
umgekehrt. Das Problem wird ersichtlich bei der Analyse der drei Konzepte des
TMDM für Eigenschaftsrepräsentierung.
Eine Occurrence stellt laut TMDM eine spezielle Assoziation zwischen einem
Topic und einer Informationsressource dar. Die verknüpfte
Informationsressource kann sich innerhalb oder außerhalb der Topic Maps
befinden. Eine Occurrence besitzt dabei immer einen Wert als
Zeichenkettenrepräsentierung oder als externe Ressource, sowie einen
eindeutigen Datentyp und einen Scope innerhalb dessen diese Occurrence eine
Gültigkeit besitzt.
Abbildung 6 - Occurrence-Konzept des TMDM[8]
Ein Topic-Name stellt hingegen eine Benennung für das jeweilige Topic dar,
welcher beispielsweise als Label innerhalb der Nutzerschnittstelle verwendet
61
werden kann. Ein Name kann dabei mehrere Varianten umfassen, welche
andere Schreibweisen oder andere Sprachen abdecken. Namen stellen laut
Spezifikation des TMDM ein Subjekt dar, welches die Natur des beschriebenen
Topics verkörpern sollte. Der Wert eines Namens ist dabei immer eine
Zeichenkettenrepräsentierung und der Datentyp immer der abstrakte Typ
String.
Abbildung 7 - Names-Konzept des TMDM[8]
Zur Vollständigkeit sei an dieser Stelle noch das Konzept der Varianten eines
Namens erwähnt, welche alternative Formen des zugehörigen Namen
beschreiben und im Gegensatz zu Namen jede Art von Informationsressource
darstellen kann. Ein Variant besitzt daher ähnlich wie eine Occurrence einen
Datentyp.
Abbildung 8 - Variant-Konzept des TMDM[8]
Es ist erkennbar, dass die Konzepte des Name und der Occurrence semantisch
von Grunde auf verschieden sind, allerdings durch die oben angesprochene
Achse vereinheitlicht werden. Diese Vereinheitlich stellt, im Bezug des TMDM,
einen semantische Bruch dar und muss aus Konsistenzgründen aufgehoben
werden, um eine Inkonsistenz innerhalb der zukünftigen Topic-Maps-Standards
(TMDM, TMQL, TMCL …) zu vermeiden. Weiter ist festzustellen, dass das
62
Konzept der Variants keine Berücksichtigung innerhalb von TMQL findet, was
eine Verwendung dieser innerhalb eines TMQL-Statements unmöglich macht.
Ein Lösungsvorschlag der Community zu diesen Problemen sieht die Trennung

der characteristics-Achse in eine names- und occurrences-Achse, sowie die
Einführung einer variants-Achse vor. Die variants-Achse ermöglicht ausgehend
von einem Namensobjekt den Zugriff auf die Varianten. Inwiefern dieser
Vorschlag in den Draft aufgenommen wird, bleibt allerdings abzuwarten.
Der entwickelte Prototyp unterstützt aktuell diese Achse, gemäß des TMQL-
Drafts und ermöglicht den getrennten Zugriff auf Namen und Occurrences
durch Verwendung des optionalen Typen gemäß dem TMDM. Die Abfrage von
Variantes wird aktuell nicht unterstützt.
5.1.3. Die types- und supertypes-Achsen
Innerhalb des TMDM wird zwischen der Typ-Instanz-Beziehung und der

Supertyp-Subtyp-Beziehung unterschieden. Im Gegensatz zur
Objektorientierung kann ein Topic sowohl die Rolle einer Instanz, sowie die
Rolle eines Typen einnehmen.
Dabei kapselt ein Topic-Typ eine Menge von Gemeinsamkeiten innerhalb eines
internen Sets. Jedes Element dieses Sets wird als Instanz dieses Typs
bezeichnet. Jede Instanz kann für sich wieder die Rolle eines Typs einnehmen.
Es besteht dabei keine Transitivitätseigenschaft, d.h. sei A eine Instanz von B
und B eine Instanz von C, so ist A keine Instanz von C. Eine Typ-Instanz-
Beziehung wird innerhalb einer Topic Maps als Assoziation modelliert. Die
Assoziation besitzt dabei genau zwei Rollenspieler mit definierten Typen, sowie
den eindeutigen Subject-Identifier http://psi.topicmaps.org/iso13250/
model/type-instance.
Eine Supertyp-Subtyp-Beziehung beschreibt den Sachverhalt der

Verallgemeinerung bzw. Spezialisierung von Topic-Typen. Ein Topic kann dabei
die Rolle des Supertypen, sowie des Subtypen einnehmen. Es gilt dabei die
63
Transitivitätseigenschaft in doppelter Hinsicht. Sei A ein Supertyp von B und B

ein Supertyp von C, sowie c eine Instanz von C, so ist A ein Supertyp von C
und c eine Instanz von A und B. Dies gilt nicht in umgekehrter Richtung. Jeder
Topic-Typ besitzt per Definition den abstrakten Supertypen Topic-Type und
jede Instanz einer Topic Maps ist somit eine Instanz dieses abstrakten Typs.
Eine Supertyp-Subtyp-Beziehung wird innerhalb einer Topic Maps als
Assoziation modelliert. Die Assoziation besitzt dabei genau zwei Rollenspieler
mit definierten Typen, sowie den eindeutigen Subject-Identifier
http://psi.topicmaps.org/iso13250/model/supertype-subtype.
Diese strikte Trennung beider Konzepte spiegelt sich auch innerhalb des
Achsenkonzeptes von TMQL in den Achsen types und supertypes wider. Ein
Rückwärtsnavigation der types-Achse resultiert somit gemäß der
Transitivitätseigenschaft in der Menge von Typen und Supertypen der
angegeben Instanz.
5.1.4. Die traverse-Achse
Einen weiteren Anstoß zur Diskussion liefert die traverse-Achse. Wie bereits im
entsprechenden Kapitel(3.4.2) beschrieben, liefert diese Achse ausgehenden
von einer Topic-Instanz eine Menge von Topics, welche über eine Assoziation
direkt mit dem Ursprungselement verbunden sind. In Rückwärtsrichtung liefert
diese Achse ausgehenden von einem Topic immer eine leere Menge.
Ein ähnliches Verhalten weißt diese Achse ausgehenden von einer Assoziation
auf. In diesem Kontext liefert die Rückwärtsrichtung eine Menge von
Assoziationen, welche über ein Topic in der Art verbunden sind, das dieses
Topic an beiden Assoziationen teilnimmt. Das Verhalten während einer
Vorwärtsnavigation wird vom aktuellen Draft nicht weiter spezifiziert, liefert also
im Extremfall eine leere Menge oder einen Null-Wert.
Das gerade beschriebene Verhalten dieser Achse ist hochgradig inkonsistent.

Der Beweis dieser Behauptung erfolgt durch Betrachtung des Verhaltens aller
anderen Achsen. Eine Kombination von Vorwärts-und Rückwärtsnavigation
64
resultiert hier stets in einer Ergebnismenge, welche im Minimum das

Ursprungselement enthält. Die einzige Ausnahme dafür stellt die leere Menge
als Ergebnis einer Vorwärtsnavigation dar. Die traverse-Achse bleibt allerdings
nur in Kombination zweier Vorwärtsnavigationen konsistent, da eine
Rückwärtsnavigation wie beschrieben immer eine leere Menge liefert, von der
ausgehenden keine Navigation zum Ursprungselement möglich ist. Die
Betrachtung im Kontext von Assoziation ist äquivalent mit der Ausnahme, dass
die Achse nur im Kontext zweier Rückwärtsnavigationen ein konsistentes
Verhalten besitzt.
Eine Lösung der Problematik wäre die Definition eines äquivalenten Verhaltens
der Achse unabhängig von der Navigationsrichtung. Resultat dieser
Modifikation wäre die vollständige Abgeschlossenheit des durch die Achsen
definierten Raumes, sowie ein vollständig konsistentes und einheitliches
Verhalten aller Achsen. Dabei wird eine Achse genau dann als konsistent
angesehen, wenn eine Kombination der Navigation in beiden Richtungen
entlang einer Achse, stets in einer Menge resultiert, welche das
Ursprungselement enthält. Einzige Ausnahme dieser Definition stellt die leere
Ergebnismenge in Vorwärtsrichtung dar, da eine Navigation zurück hier nicht
möglich ist.
Ein weiteres Missverständnis provoziert die fehlende Definition der

Eigenschaften der Ergebnismenge. Aktuell enthält der Draft kaum
Informationen und Restriktion über den Umgang mit Duplikaten innerhalb der
Ergebnismenge. Zur Verdeutlichung des Sachverhaltes seien folgende
Assoziations- und Topic-Instanzen definiert.
geboren-in (Person: Sven_Krosse , Stadt: Leipzig)

studiert-in (Person: Sven_Krosse, Stadt: Leipzig)
Codefragment 40 - Definition zweier Assoziationen
Des Weiteren seien die möglichen Ergebnismengen, im Folgenden mit

geschweiften Klammern gekennzeichnet, des folgenden TMQL-Ausdrucks
betrachtet.
65
Sven_Krosse >> traverse = {Leipzig, Leipzig} | {Leipzig}
Codefragment 41 - TMQL-Navigation und mögliche Ergebnismengen
Beide genannten Ergebnismengen besitzen nach aktuellem Draft Gültigkeit und

können von einer Implementierung geliefert werden. Eine strikte Definition über
Duplikate innerhalb der Ergebnismenge, wie bei anderen Navigationsachsen
erscheint zur Vorbeugung von Missverständnissen als sinnvoll.
5.2. Kritikpunkt – Komplexität des Draft und der Grammatik
Der aktuelle Draft wird von vielen Autoren als zu komplex und nicht
implementierbar angesehen. Aktuell stellt sich die Frage der Umsetzbarkeit des
aktuellen Draft in seiner jetzigen Form bzw. die Auswahl der Kernkomponenten
des finalen Standards. Der finale Standard sollte alle Elemente umfassen,
welche für eine Implementierung des TMQL-Parsers unabdingbar sind und zur
Erfüllung der grundlegenden Funktionalität der Datenselektion enthalten sein
müssen. Um die Frage zu klären ist ein detaillierter Blick auf die einzelnen
Bestandteile, sowie eine Abschätzung der Notwendigkeit und Performance
erforderlich. Die Frage der Performance sollte dabei allerdings nur eine
nachgestellte Rolle besitzen, da die Frage eines Standards nicht an der
Performance auszumachen ist, allerdings werfen sich an einigen Stellen Zweifel
auf, ob eine langsame Implementierung, den Mehrwert dieses Features nicht
aufwiegt.
5.2.1. Inkonsistenz durch Auflösung eines Item-Identifier
Der erste Diskussionspunkt nimmt dabei nur indirekt Bezug auf TMQL und
befasst sich mit der aktuelle Schwachstelle des TMDM. Hauptgegenstand der
Diskussion ist die Verwendung und Handhabung eines Item-Identifier als
eindeutige Referenz eines Topics. Problem dieser Verwendung ist die fehlende
Spezifizierung der Verarbeitung bzw. Auflösung solcher Item-Identifier durch die
Topic-Maps-Engine ([8], Abs. 5.1 General).
Die genannte Schwachstelle des TMDM bietet ein erhöhtes Potential der
Inkonsistenz, da eine Verarbeitung im Extremfall in verschiedenen Ergebnissen
66
unter Verwendung verschiedener Engines resultieren kann. Dies kann auch im

Rahmen einer TMQL-Anfrage zu mehrdeutigen bzw. verschiedenen
Ergebnissen führen.
5.2.2. Diskussion um das Non-Canonical Level
Der erste Blick erfolgt dabei auf die verschiedenen grammatikalischen

Sprachenebenen der Grammatik von TMQL. Die Frage der Notwendigkeit
einiger Elemente des Non-Canonical Level erscheint schwer zu beantworten,
ohne den Mehrwert genau zu betrachten. Diese Sprachebene erweitert wie
bereits ausführlich beschrieben, die grammatikalischen Regeln der Sprache um
Term-Transformationen mit dem Ziel der Reduktion einiger Ausdrücke. Gemeint
sind in diesem Kontext die Kurzformen der Achsennavigationen und anderer
formaler Bestandteile. Oft entfallen aufgrund genannter Kurzformen, lediglich
die Achsenbezeichnungen oder einzelne Zeichenketten. Die gewählte Syntax
orientiert sich dabei strikt am CTM-Standard und wird somit konsistent
weitergeführt.
Einige der Regeln erhöhen dabei deutlich die Komplexität der Grammatik und
reduzieren die Sprache von einer kontextfreien zu einer kontextabhängigen
Sprache. Um den Sachverhalt zu verdeutlichen sei folgendes Beispiel genannt.
exists-clause ::= exists-quantifier binding-set

satisfies boolean-expression
exists-clause ::= exists content
some $_ in content satisfies not null
exists-clause ::= content
exists content
value-expression ::= content
Codefragment 42 - Mehrdeutigkeit innerhalb des NCL am Beispiel zweier

Grammatikregeln
Die erste genannte Regel beschreibt die Syntax einer Exists-Klausel in

vollständiger Form und ist Bestandteil des Canonical Level der Sprache. Unter
der Voraussetzung einer quantitativen Unabhängigkeit der Bedingung,
unterstütz TMQL die Reduktion auf die zweite Form. Diese Regel hingegen ist
67
dann Bestandteil des Non-Canonical Level der Sprache, stellt aber durch die
Eindeutigkeit des Schlüsselwortes exists noch keine Mehrdeutigkeit dar. Durch
Definition einer weiteren Term-Reduktion auf die dritte Prädikatenformel erhöht
sich die Komplexität des Parser-Prozesses. Als Beispiel sei die vierte Regel
genannt. Einem Parser ist es nur auf Basis der vollständigen Kenntnis über
vorangegangene Token möglich an besagter Stelle die richtige Klausel zu
erkennen und an den Interpreter zu melden. Mit Kenntnis sei hier das Wissen
über das Auftreten innerhalb der Anfrage gemeint.
Im Rahmen der Erkenntnis ist eine Interpretation auf Ebene des Non-Canonical
Level schwer und eventuell zu fehlerbehaftet. Eine Vollständige Reduktion des
Non-Canonical Level auf das Canonical Level ist ohne Kontextinformation nicht
möglich, da bereits an gezeigtem Beispiel zwei mögliche Pfade entstehen,
welche beide ohne Wissen des Kontextes eine Gültigkeit besitzen.
Zusammenfassend stellt sich die Frage ob die Implementierung eines

Canonizer, zur Reduktion auf das Canonical Level, losgelöst vom Parser-
Prozess realisiert werden kann bzw. eine vollständige Implementierung der
Term-Reduktion außerhalb des Parser-Prozesses umgesetzt werden kann. Im
Rahmen der Entwicklung erschien die ein hundertprozentige Trennung nicht
realisierbar. Der in aktuellen TMQL-Engine enthaltene Canonizer ist aktuell nur
in der Lage eindeutige Reduktionen aufzulösen. Bei Mehrdeutigkeit bleibt die
Reduktion erhalten und wird später vom Parser durch Analyse des Kontextes
aufgelöst.
5.2.3. Kritikpunkt – Variablennamen
Wie in Kapitel 3.6.2 beschrieben, erfolgt die Bindung von Werten in

Abhängigkeit von Variablennamen. Per Definition ist die Bindung derselben
Werten nur an Variablen mit verschiedenen Namen gestattet, wobei sich die
Namen nicht nur in der Anzahl nachstehenden Primes (´) unterscheiden dürfen.
Die folgenden beiden Anfragen liefern daher laut aktuellem Draft verschiedene
Ergebnisse.
68
...
where is-neighbour-of (tm:subject : $a, tm:subject : $a')
& is-neighbour-of (tm:subject : $a', tm:subject : $a'')
...
where is-neighbour-of (tm:subject : $a, tm:subject : $b)
& is-neighbour-of (tm:subject : $b, tm:subject : $c)
Codefragment 43 - Kritik an der semantische Bedeutung der nachstehenden

Anführungszeichen in Variablennamen
Weiter ist die Gültigkeit der Bindung verschiedener Wertausprägungen vom

gewählten Präfix der Variable abhängig, so erlaubt der Präfix $ beispielsweise
nur die Bindung an atomare Werte oder Topic-Maps-Elemente. Folglich ist nur
die erste der nachfolgenden Variablenbindungen gültig.
{ $a => 23, $b => "text" }

{ @a => 23, %b => "text" }
Codefragment 44 - Kritik an der semantischen Bedeutung von Präfixen in

Variablennamen
Meiner persönlichen Meinung nach ist die semantische Bindung von Variablen
an ihren Namen, wie hier gezeigt, nicht sinnvoll. Das Verständnis des Lesers für
eine solche semantische Regel ist nur beschränkt zu erwarten. Angenommen
dem oberen Fall, liefern zwei völlig identische Anfragen, angesehen vom
verwendeten Variablennamen, verschiedene Ergebnisse, was wiederum zu
völlig Unverständnis beim Anwender führen kann. Die Bezeichnung von
Variablen sollte, ähnlich wie in modernen Programmiersprachen, wie Java oder
Ruby, keine semantische Bedeutung besitzen bzw. im Rahmen gültiger Muster
frei von jedem semantischen Bezug über Ausprägung und Gültigkeit
gebundener Werte sein.
69
6. Entwurf und Implementierung der TMQL-Engine TMQL4J
6. Entwurf und Implementierung der TMQL-Engine - TMQL4J
Auf Basis der Analyse der Standardbestandteile und des aktuellen

Standardisierungsprozesses muss ein Entwurf entwickelt werden, welcher die
wichtigsten Bestandteile des Drafts umfasst, sowie eine spätere Anpassung in
Folge von Änderungen im finalen Standard zu vereinfachen. Im Umfeld einer
sich schnell ändernden Umgebung, wie die des aktuellen Drafts, sowie
aufgrund der aktuellen Komplexität des Drafts bietet sich eine modulare
Entwicklung der TMQL-Engine an.
6.1. Verwendung von TMQL4J
Die entwickelte TMQL-Engine TMQL4J kann als Abstraktionsschicht zwischen

der eigentlichen Anwendung und der TMAPI eingesetzt werden. Ziel dieser
weiteren Abstraktion ist die zunehmende Transparenz der darunterliegenden
Datenstruktur, sowie die Reduktion der Anzahl benötigter Methodenaufrufe zur
Extraktion der gewünschten Informationen.
Durch das Entwurfsziel der Verwendung von TMAPI und der Abstraktion von
der konkreten Topic-Maps-Engine kann TMQL4J in Verbindung mit allen
Engines eingesetzt werden, welche die aktuelle TMAPI-Spezifikation umsetzen.
Durch Kombination mit Technologien zur Sprachüberbrückung, wie JRTM, ist
ein Einsatz auch in Kombination mit RTM oder anderen Programmiersprachen
denkbar. Folglich ist es möglich TMQL4J auch in eine bereits bestehende
Anwendung zu integrieren.
Die folgende Abbildung ordnet TMQL4J in die Architektur einer fiktiven Topic-
Maps-Anwendung ein und verdeutlicht deren Einsatzgebiet im Kontext solcher
Anwendungen.
70
Abbildung 9 - Architektur einer fiktivem Anwendung mit Verwendung von TMQL4J
6.2. Hohe Flexibilität durch Modularisierung
Die Vorteile des modularen Ansatzes sind vielseitig. Ein modularer Ansatz
ermöglicht einzelne Komponenten einfach auszulagern und für andere
Anwendung zu nutzen. Ein Modul kapselt gerade so viel Funktionalität um seine
definierte Aufgabe zu erfüllen, wobei diese Aufgabe so feingranular wie möglich
definiert werden muss. Der zweite Vorteil liegt in der Fehlererkennung und
Behebung. Hauptmerkmal einer Softwarekomponente ist die vollständige
Kapselung einschließlich der Fehlerbehandlung. Ein Fehler welcher innerhalb
einer Komponente auftritt, sollte in dieser behandelt werden. Folglich lassen
sich einzelne Funktionalitäten unabhängig voneinander testen und validieren.
Ein weiterer Vorteil und Hauptargument für die aktuelle Implementierung ist die
flexible Austauschbarkeit und Anpassbarkeit von einzelnen Komponenten der
Engine. Ein sich änderndes Verhalten innerhalb einer Komponente, kann und
sollte auch genau dort angepasst werden. Des Weiteren ermöglicht diese Art
der Softwarearchitektur eine iterative und funktionale Entwicklung einzelner
Sprachbestandteile von TMQL, so kann beispielsweise die Navigation von den
semantischen Sprachmuster getrennt werden.
6.3. TMQL-Laufzeitumgebung
Die TMQL-Laufzeitumgebung kapselt alle Module der TMQL-Engine TMQL4J

und abstrahiert die Funktionalität nach außen.
71
Die Modellierung der Laufzeitumgebung einer TMQL-Verarbeitung der

TMQL4J-Engine orientiert sich am Modell der linearen Prozesskette. Jeder
Prozess innerhalb der Kette realisiert eine spezifische Aufgabe bzw. Funktion
und stellt den Input des folgenden Prozesses dar. Die Betrachtung auf einer
höheren Abstraktionsstufe ermöglicht die Einteilung der Prozesskette in 4
unabhängige Prozessschritte: Initialisierung, Vorverarbeitung, Parsen und
Interpretation. Jeder Prozessschritt kann allerdings in einzelne feinere Prozesse
aufgeteilt werden, welche jeder für sich genau eine atomare Aufgabe im
Kontext einer TMQL-Verarbeitung realisiert.
Abbildung 10 - Abstraktion der TMQL4J-Prozesskette
Jeder Prozess kapselt dabei eines oder mehrere der in den folgenden Kapiteln
beschrieben Module.
Die Initialisierung stellt nur indirekt einen TMQL-Prozess dar und bildet die
Grundlage für eine Realisierung der späteren Verarbeitungen einer Query
gemäß dem im Draft spezifizierten Vorgehensmodell. Innerhalb der
Initialisierungsphase erfolgt die Definition der TMQL-Environment-Map als
Topic Maps. Die Environment-Map enthält dabei alle im Draft vordefinierten
Konzepte, wie Funktionen und Datentypen. Die Definition und initiale Bindung
der Systemvariablen stellt die zweite Kernfunktionalität dieser Phase dar.
Ergebnis dieser Phase ist der initiale Kontext einer jeden TMQL-Verarbeitung,
repräsentiert durch die abstrakte Klasse IInitialContext. An die
Initialisierungsphase schließt sich direkt die Vorverarbeitung an. Innerhalb der
Vorverarbeitung erfolgen die Bereinigung des TMQL-Query, sowie die
Kanonisierung. Die komplette Trennung der Kanonisierung vom Prozess des
Parsens ist allerdings nicht möglich.
72
Der Prozess des Parsens setzt sich aus dem Vorgang der Zerlegung in
einzelne semantische Token (Lexikalisches Scannen) gefolgt vom eigentlichen
Parser-Prozess zusammen und resultiert in einer Instanz des generierten
Parser-Baum, welcher die Zerlegung eines Query in seine Expression
repräsentiert.
Der letzte und entscheidende Schritt der Verarbeitung ist die Interpretation des
generierten Parser-Baumes. Die Interpretation erfolgt dabei auf Ebene
einzelner Expressions und orientiert sich an den Restriktionen des aktuellen
Drafts. Ergebnis der Interpretation ist eine Sequenz von Tupeln, welche in der
Nachverarbeitung bzw. der Ergebnisverarbeitung in den gewünschten
Ergebnistyp transformiert werden können.
6.4. Abgrenzung der TMQL4J-Module
Grundlage der Entwicklung mit modularer Softwarearchitektur ist die exakte

Abgrenzung einzelner Komponenten. Der Entwurf der Komponenten umfasst
die Spezifikation der feingranularen Funktion der Komponente, sowie ihre
Schnittstelle nach außen. Im Folgenden werden die wichtigsten Module
angerissen und ihre Funktionalität, sowie deren Abgrenzung nach außen
benannt.
6.4.1. Navigationsmodul – Achsenimplementierung mit der TMAPI
Die in TMQL spezifizierten Navigationsachsen des aktuellen Drafts bilden einen

wesentlichen Bestandteil der Implementierung eines TMQL-Parsers bzw. einer
TMQL-Engine. Sie ermöglichen eine schnelle und einfache Ausführung von
Navigationsstatements und sollten als eigene Module ausgelagert werden. Da
aktuell nicht abschätzbar ist, welcher Draft sich final durchsetzen wird bzw.
welche der Achsen Bestandteil des Standards wird, werden alle der 12
benannten Achsen trotz der angesprochenen Problematiken implementiert.
Die Funktionalität dieses Moduls setzt dabei auf Kernkomponenten der TMAPI
2.0 auf. Jeder einzelne Navigationsschritt wird in eine Menge von TMAPI-
73
Anfragen abgebildet. Zusätzlich enthält jede Achse eine Typprüfung der

übergebenen Ursprungsknoten, welche die Einhaltung der aktuellen
Spezifikation sicherstellen soll. Da sich die Funktion jeder Achse nur in der
späteren Ausführung, nicht aber im Verhalten nach außer unterscheidet, ist es
sinnvoll eine einheitliche Schnittstelle nach außen zu definieren, um eine
schnelle Integration neuer Achsen bzw. die Anpassung bestehender
Implementierung zu vereinfachen.
Abbildung 11 - UML-Klassendiagramm der Komponente zur Navigation
Die Implementierung der einzelnen Achsen erfolgt unabhängig voneinander,

obwohl einige Achsen in gewisser Weise oder in bestimmten Kontexten
dieselbe Aufgabe bzw. dieselben Funktionsaufrufe realisieren, an dessen Stelle
die Verwendung der anderen Achse möglich wäre. Als Beispiel dafür sei die
traverse-Achse genannt, welche in Vorwärtsrichtung alle Topics extrahiert,
welche mit dem Navigationsursprung über eine Assoziation verknüpft sind. In
diesem Kontext kann die players-Achse Verwendung finden. Gegenargument
und folglich Ursache für die gewählte strikte Trennung, ist die Einhaltung des
Entwurfsziels der späteren Anpassung bzw. des späteren Entfernens einiger
Achsen.
Als Realisierung der eindeutigen Identität eines Topics gemäß dem TMDM
besitzt jede Instanz von Topic innerhalb der TMAPI ein Set von Subject-
Identifier, Subject-Locator und Item-Identifier. In Folge dessen, ist es der
Anwendung zu jedem Zeitpunkt möglich, die entsprechende Instanz zu
74
identifizieren. Die drei Identitätsachsen item, indicators und locators lassen sich
daher ohne Zusatzfunktionen direkt auf die TMAPI abbilden. Das folgende
Codefragment zeigt am Beispiel der locators-Achse die Implementierung auf
Basis der TMAPI.
public class LocatorNavigationAxis extends BaseNavigationAxisImpl{

public LocatorNavigationAxis() {
super(NavigationAxis.locator);
}
public Collection<?> navigateBackward(Object c,
Construct a) throws NavigationException {
if ( c instanceof Locator && a instanceof TopicMap ){
TopicMap map = (TopicMap) a;
Locator locator = (Locator)c;
Topic t = map.getTopicBySubjectLocator(locator);
Collection<Topic> col = new HashSet<Topic>();
col.add(t);
return col; }
throw new InvalidValueException();
}
public Collection<?> navigateForward(Construct c,
Construct a) throws NavigationException {
if ( construct instanceof Topic ){
Topic topic = (Topic) c;
return topic.getSubjectLocators();
}
throw new InvalidValueException(); } ...
Codefragment 45 - Realisierung der locators-Achse auf Basis der TMAPI 2.0
Einen ähnlichen Ansatz verfolgt die Implementierung der Achsen

characteristics, scope, players und roles. Jede Instanz von Topic besitzt gemäß
TMAPI eine Menge von Occurrences und Namen, welches sich somit für eine
Implementierung der Achse effizient abfragen lassen. Jede Assoziation besitzt
im Gegenzug eine Menge von Rollen, welche für sich nach außen die Spieler
der Rolle kapseln. Eine Implementierung der beiden Achsen ist somit durch
wenige Funktionsaufrufe der TMAPI realisierbar. Ein Problem wirft die
Rückwärtsrichtung der characteristics-Achse auf, da eine effiziente Abfrage von
Eigenschaften auf Basis der Wertausprägung von der TMAPI richtigerweise
nicht unterstützt wird, da hier die bereits angesprochenen Probleme der
atomify-Achse ebenfalls von Relevanz sind. Die aktuelle Implementierung der
Achse, durchläuft jedes Topic der Topic Maps und vergleicht folglich jede
Eigenschaft der Topics mit dem übergeben Wert. Dies wird notwendig, da
innerhalb der Anfrage von TMQL nur die Zeichenkettenrepräsentierung einer
Eigenschaft beschrieben werden kann und maximal auf Basis des aktuellen
75
Kontextes der Anfrage eine eindeutige Auflösung zum gewollten Objekt möglich
erscheint.
Die beiden Achsen der Typhierarchie types und supertypes lassen sich nur
bedingt auf Basis definierter TMAPI-Methoden realisieren. In Vorwärtsrichtung
stellt die API, Methoden bereit um iterativ alle Typen eines Topics zu
extrahieren. Im Gegensatz zur types-Achse ist die Abfrage aller Subtypen oder
Supertypen keinesfalls über einen Aufruf möglich. Ferner werden in der
aktuellen Implementierung die Assoziationen extrahiert, welche die Supertype-
Subtype-Beziehung zweier Typen gemäß TMDM innerhalb der Topic Maps
beschreiben. Dies wird allerdings nur möglich, wenn die im TMDM definierten
Subject-Identifier verwendet werden. Zur Erkennung der Instanzen eines Typs
stellt die TMAPI 2.0 einen Index zur Verfügung, welcher innerhalb der Engine
die Instanzen eines Typs speichert.
Die reifier-Achse wird bezügliches ihres Funktionsumfangs vollständig von der

TMAPI 2.0 unterstützt.
Die atomify-Achse lässt sich ohne ein weiteres Modul aus genannten Gründen
nicht umsetzen. Die Integration der Funktionalität in diese Komponente stellt
ebenfalls keine richtige Lösung dar, da sie kontroverse zur gewählten
Softwarearchitektur ist. Die beiden völlig verschiedenen Aufgaben sind in zwei
eigene Module zu zerlegen. Zur Realisierung der atomify-Achse wird eine
Komponente zur Serialisierung und Deserialisierung von atomaren Werten
benötigt. Die TMAPI 2.0 besitzt zwar einen speziellen Index aller Namen bzw.
Occurrences, welcher zu jeder gegeben Zeichenkettenrepräsentation die
entsprechenden Objekte liefen kann, dass vorweg angesprochene Problem
besteht weiterhin.
Interessant erscheint nach der Implementierung der Achsen die Untersuchung

der Geschwindigkeit der einzelnen Achsen und Richtungen. Dabei stellt sich die
Frage, ob sich eine Implementierung auf Basis der TMAPI als effizient
herausstellt. Eine solche Betrachtung erfolgt im Rahmen der Testphase
(Tabelle 6).
76
6.4.2. Vorverarbeitungsroutine
Die Vorverarbeitung bildet die Basis der eigentlichen TMQL-Verarbeitung und

bereinigt bzw. modifiziert den TMQL-Query zur Vereinfachung des späteren
Parsens. Die beiden wichtigsten Module der Vorverarbeitung sind der TMQL-
Screener und der TMQL-Canonizer.
Der TMQL-Screener bereinigt dem TMQL-Query von unnötigen Leerzeichen

oder Zeilenumbrüchen, sowie Kommentaren, welche für die spätere
Verarbeitung keine Relevanz besitzen. Die Verarbeitung des Ausdrucks erfolgt
zeilenweise auf Zeichenkettenebene durch Verwendung eines Tokenizer. Jede
Zeile wird dabei nach dem Kommentarzeichen # durchsucht und alle
nachstehenden Zeichen der entsprechenden Zeile werden entfernt.
Der TMQL-Canonizer reduziert die Repräsentierung eines TMQL-Query vom

Non-Canonical Level(3.2.3) auf das Canonical Level(3.2.2). Die Verarbeitung
erfolgt hier auf Ebene der Terminalsymbole. Jedes Terminalsymbol wird dabei
eingelesen und gegen seine eventuelle Entsprechung auf Canonical Level
ersetzt. Terminalsymbole des Canonical Level bleiben dabei unverändert.
Als drittes Modul beinhaltet der Vorverarbeitungsprozess einen TMQL-

Whitespacer. Ein solches Modul ist nicht üblich innerhalb eines Parsers, wird
allerdings verwendet um den Vorgang des lexikalischen Scannens zu
vereinfachen. Innerhalb des Query werden zusätzliche Leerzeichen eingefügt,
die im Rahmen des aktuellen Drafts als optional definiert sind, wie das
Leerzeichen vor dem Doppelpunkt innerhalb einer Predicate-
Invocation(3.6.3.2). Die Verarbeitung erfolgt auf Zeichenebene innerhalb eines
Terminalsymbols. In Abhängigkeit des Auftretens eines Symbols und im
Kontext zu seinem Vorgänger und Nachfolger werden eventuelle Leerzeichen
eingefügt.
Jede der drei Module wird als eine eigene Java-Klasse implementiert, folgendes
UML-Diagramm liefert einen Überblick über die Schnittstellen, sowie
implementierenden Klassen.
77
Abbildung 12 - UML-Klassendiagramm des TMQL4J-Preprocessing
Die beiden Klassen SpaceCharacterTransformer und ShortcutTransformer

kapseln aus Gründen der Übersichtlichkeit die eigentliche Umsetzung der
Funktionalität der darüber stehenden Module und stellen keine eigenständigen
Komponenten dar.
6.4.3. TMQL-Lexer
Eines der drei Kernmodule der TMQL-Engine bildet der lexikalische Scanner,
im Folgenden als TMQL-Lexer bezeichnet. Per Definition handelt es sich bei
einem lexikalischen Scanner um einen speziellen Parser bzw. ein spezielles
Computerprogramm zur Zerlegung von Eingaben in eine Folge logischer
Einheiten, auch als Token bezeichnet [27].
Während der so genannten Lexikalischen Analyse zerlegt der TMQL-Lexer, den

kanonisierten und bereinigten TMQL-Query anhand der definierten Grammatik
in eine Folge von Token, repräsentiert durch die Enumeration TMQLTokens.
Der Prozess der Lexikalischen Analyse erfolgt in zwei Phasen, dem
Tokenisieren und dem Schlüsselwortabgleich. Ein spezieller Tokenizer zerlegt
die Eingabe in eine Menge von Terminalsymbolen, anhand der definierten
Leerräume (Whitespaces) der Sprache TMQL. Die Zuordnung der
entsprechenden Schlüsselwörter findet auf Terminalsymbolebene statt. Dabei
wird jedes Terminalsymbol gegen eine Menge definierter Token geprüft und
eine eventuelle Übereinstimmung zurückgeliefert. Begründet durch den
fehlenden semantischen Bezug, werden alle nicht erkennbaren Token als
78
Konstrukte bzw. Informationselemente der Topic Maps angesehen und als

solches kategorisiert.
Herzstück der Implementierung des TMQL-Lexer ist die Schnittsteller ILexer,

sie definiert eine Menge von Funktionalitäten die durch die Implementierung
abgedeckt werden müssen. Durch die Verwendung der Schnittstelle wird
innerhalb der Verarbeitung von der konkreten Implementierung abstrahiert und
somit eine spätere Integration verschiedener Implementierungen in die
Prozesskette ohne weitere Codemodifikationen ermöglicht. Als
Basisimplementierung stellt der Prototyp der TMQL-Engine die Klasse
TMQLLexer bereit. Das folgende UML-Diagramm zeigt die wichtigsten
Komponenten des lexikalischen Scanners von TMQL4J.
Abbildung 13 - UML-Klassendiagramm des lexikalischen Scanners
Nach Abschluss der lexikalischen Analyse stellt der TMQL-Lexer die Eingabe
als eine Folge von Token, sowie eine Folge der korrespondierenden
Terminalsymbole zur Verfügung.
6.4.4. TMQL-Parser und Baumgenerierung
Zweites Kernmodul der TMQL-Engine ist der TMQL-Parser. Unter einem Parser
versteht man ein spezielles Computerprogramm, zur Realisierung der zur
79
Zerlegung und Transformation einer beliebigen Eingabe in ein gewünschtes

und weiter verarbeitbares Format eingesetzt wird [28]. Je nach Struktur der
verarbeiteten Sprache bestehen zwei verschiede Varianten der Ausgabe eines
Parsers.
Man unterscheidet zwischen der Realisierung als sequentiellen Datenstrom und

der Generierung der kompletten Ausgabe, als Baum- oder Graphstruktur. Die
sequentielle Verarbeitung liefert jedes erkannte syntaktische Gefüge über
spezielle Events oder Funktionen an das verarbeitende Programm zurück.
Vorteil dieser Variante ist der geringe Speicherbedarf, im Verhältnis zur nicht
freien Navigation. Ein Beispiel für eine solche Verarbeitung bildet die Gruppe
der SAX-Parsers für XML. Im völligen Gegensatz dazu agieren DOM-Parser,
auf dem Prinzip, das Verarbeitung erst nach Abschluss des Parsens erfolgen
darf. Ein DOM-Parser bildet die komplette Struktur der XML-Datei als Baum ab
und liefert diesen an die Anwendung zurück. Der Vorteil hier ist die freie
Navigation auf Kosten des Speicherverbrauchs.
Da die Struktur der TMQL-Grammatik eine hohe Ähnlichkeit zu XML-

Dokumenten aufweist, ist die Realisierung beider Varianten denkbar. Jeder
Ausdruck in TMQL besitzt eine Menge von Teilausdrücken, welche für sich
abgeschlossen sind und sich nicht überlagern dürfen. Einem TMQL-Parser ist
es somit möglich ausgehend von einer Query-Expression, die Eingabe als
Baumstruktur abzubilden und als solche zur Verfügung zu stellen. Dagegen ist
eine Realisierung als sequentieller Datenstrom denkbar, welcher auf Basis der
Produktionsregeln spezielle Events an die Anwendung zurückliefern kann.
Abbildung 14 - Visualisierung der generierten Struktur des TMQL-Ausdrucks

jack << players member >> roles [ 1 .. 2 ]
80
Wie im Fall von XML gibt es keine überlegene Variante, da beide ihre Vor- und
Nachteile aufweisen. Der Speicherbedarf des DOM-Ansatzes steigt mit
zunehmender Länge und Komplexität der Eingabe, erleichtert allerdings die
spätere semantische Analyse, durch die enge Bindung an die Grammatik,
sowie die fein granulare Aufteilung in atomare Einheiten innerhalb der
Baumstruktur. Die Vor- bzw. Nachteile des SAX-Ansatzes sind nahezu
umgekehrt, erweitert um den Vorteil der Geschwindigkeit der Verarbeitung. Die
Erkennung eines ungültigen Ausdruckes ist schneller möglich, da die
Verarbeitung parallel zum Parsen realisiert wird und nicht erst nach Abschluss
des kompletten Parsens.
Da beide Varianten ihre Existenzberechtigung besitzen und jede für sich im

Rahmen verschiedener Szenarien die optimale Wahl darstellen würden, wird
innerhalb des Verarbeitungsprozesses von der konkreten Implementierung
durch Definition einer allgemeinen Schnittstelle abstrahiert. Dem Entwickler ist
somit die Möglichkeit der Umsetzung eines eigenen domänenspezifischen
Parsers gegeben ohne eine einzige Quellcodezeile innerhalb der
Laufzeitumgebung ändern zu müssen. Als Basisimplementierung liefert die
TMQL4J-Engine einen DOM-Parser, welche die Folge des lexikalischen
Scanners in eine Baumstruktur überführt.
Die Realisierung der Baumstruktur wird innerhalb eines Parser-Baumes

gekapselt und als abstrakte Schnittstelle vom Typ IParserTree repräsentiert.
Die Baumstruktur bildet sich als Menge von ineinander verschachtelten
Teilausdrücken, realisiert als Implementierung der Schnittstelle IExpression. Die
Generierung des Baumes erfolgt als rekursiver Backtracking-Algorithmus. Jeder
Knoten definiert sich über eine Folge lexikalischer Token und Terminalsymbole
und bildet auf Basis der Analyse von Schlüsselwörter und Produktionsregeln
seine eigene Menge von Unterknoten. Die Generierung von Unterknoten erfolgt
somit durch den Vaterknoten und nicht durch den Parser selber. Der Vorgang
endet, wenn keine Unterknoten mehr generiert werden können und die Eingabe
komplett als Baumstruktur abgebildet werden konnte. Als Optimierung des
Prozesses bricht der Vorgang mit einem Fehler ab, sobald eine ungültige Folge
von Terminalsymbolen erkannt wurde. Für jeden Typ von Teilausdrücken der
81
TMQL-Grammatik existiert genau eine Klasse als Realisierung der Schnittstelle

IExpression. Die TMQL4J-Engine kann somit Ausdruck für Ausdruck erweitert
und implementiert werden. Aus Platzgründen enthält das UML-Diagramm nur
die drei angesprochenen Schnittstellen, sowie deren abstrakte
Basisimplementierungen.
«interface» «interface» «interface»

IParser IParserTree IExpression
+parse() +root() : IExpression +subExpression() : List<IExpression>
+getParserTree() : IParserTree +getQuery() : IQuery +tokens() : List<String>
+tmqlTokens() : List<TMQLTokens>
+getType() : int
+subExpression(ein ex : IExpression)
+getParent() : IExpression
+interpret(ein runtime : TMQLRuntime)
TMQLParser ParserTreeImpl ExpressionImpl

-lexer : ILexer -root : IExpression -children : List<IExpression>
-tree : IParserTree -query : IQuery -tmqlTokens : List<TMQLTokens>
+getParserTree() : IParserTree +root() : IExpression -tokens : List<String>
+parse() +getQuery() : IQuery -type : int
#create(ein lexer : ILexer) : IParserTree -parent : IExpression
+subExpression() : List<IExpression>
+tokens() : List<String>
+tmqlTokens() : List<TMQLTokens>
+getType() : int
+subExpression(ein ex : IExpression)
+getParent() : IExpression
+interpret(ein runtime : TMQLRuntime)
+isValid() : boolean
+setType(ein type : int)
Abbildung 15 - UML-Klassendiagramm der Parser-Bestandteile
6.4.5. TMQL-Interpreter
Auf Basis der generierten Baumstruktur lässt sich eine semantische Analyse
realisieren. Die semantische Analyse basiert auf der Menge der erkannten
Teilausdrücke und liefert nach erfolgreicher Verarbeitung eine Menge von
Objekten zurück. Bei der Menge von Objekten kann es sich um Elemente der
Topic Maps handeln, aber auch um eine Menge von XML-Objekten oder um
eine CTM-Instanz.
Grundlage der erfolgreichen Verarbeitung aller TQML-Query ist die

Implementierung der Variablenunterstützung. Eng am Standard orientierend
wird die Verarbeitung von Variablen als Stack modelliert. Für jede Variable wird
im Rahmen der Verarbeitung genau eine Definition erzeugt. Die Bindung an
den konkreten Wert erfolgt erst zur Laufzeit innerhalb eines Variablenset bzw.
82
eines Bindings. Innerhalb eines Binding darf jeder Variable nur genau einmal
ein Wert zugeordnet werden, alle weiteren Versuche führen, wie im Standard
spezifiziert, zu einem Fehler. Ein Variablenset hält zudem eine Menge
geschützter Variablen, die im Rahmen einer Verarbeitung niemals an
denselben Wert gebunden werden dürfen. Per Definition gelten Variablen als
geschützt, wenn sich deren Namen nur durch die Anzahl der nachgestellten
Primes voneinander unterscheiden.
Abbildung 16 - UML-Klassendiagramm der Variablenverarbeitung
Die semantische Analyse eines TMQL-Query erfolgt iterativ auf Basis der
einzelnen Teilausdrücke. Jeder Teilausdruck erhält zu Beginn der Verarbeitung
den aktuellen Kontext und verändert diesen gemäß des TMQL-Drafts. Unter
dem Prozess der Veränderung wird eine Menge von Operationen spezifiziert,
welche neue Variablen setzen, eine Sequenz generieren oder eine Sequenz
modifizieren. Um eine ungewollte Interferenz zwischen Teilausdrücken zu
vermeiden, erzeugt jeder Ausdruck vor dem Aufruf eines Teilausdrucks eine
Kopie des obersten Variablensets und legt es auf den Variablen-Stack, bevor er
83
die Kontrolle an den Teilausdruck abgibt. Am Ende seiner Verarbeitung wird es

vom Stack entfernt und gemäß dem aktuellen Draft verarbeitet.
Ein einfaches Beispiel des Prozesses liefert die Verarbeitung der Limit-Klausel
des Select-Style. Der Select-Ausdruck erzeugt zunächst wie beschrieben, eine
Kopie des Variablensets und gibt die Verarbeitung an die Limit-Klausel ab. Im
Rahmen der Verarbeitung der Limit-Klausel wird die Variable $_limit erzeugt
und an den entsprechenden Wert gebunden. Nach erfolgreicher Verarbeitung
kehrt die Routine zum Select-Ausdruck zurück, welcher den Wert der Variable
vom Stack extrahiert und mit der Verarbeitung anderer Teilausdrücke fortfährt.
Der komplette Prozess ist abgeschlossen, wenn kein Teilausdruck mehr
ausgewertet werden muss und die Verarbeitung des obersten Ausdrucks
abgeschlossen ist. Fehler während der Verarbeitung, wie die fehlgeschlagene
Referenzauflösung (Abbildung 3), führen zum sofortigen Unterbrechen.
Äquivalent zu den bereits genannten Modulen wird auch der Interpreter als
abstrakte Schnittstelle repräsentiert. Die TMQL-Engine kann somit um eine
domänenspezifische Implementierung erweitert werden. Eine
domänenspezifische Implementierung bietet die Möglichkeit der Verarbeitung
auf Basis von zusätzlichem ontologischem Wissen.
84
Abbildung 17 - UML-Klassendiagramm des TMQL-Interpreter
6.4.6. TMQL-Ergebnisverarbeitungsroutine
Den letzten Schritt der TMQL4J-Prozesskette bildet die Ergebnisverarbeitung.

Hauptaufgabe dieses Prozesses ist die Transformation der Ergebnismenge des
Interpreters in ein bearbeitbares Format für angeschlossene Anwendungen.
Innerhalb des Prozesses erfolgt allerdings keine semantische bzw. syntaktische
Analyse der Ergebnisse oder des TMQL-Query.
Kernkomponente des Prozesses ist ein Ergebnisprozessor, welche die

Umsetzung der oben benannten Aufgabe realisiert. Die Transformation erfolgt
auf Basis verschiedener Eingangswerte, wie dem Ergebnistyp und der
Ergebnismenge. Der Prozessor initialisiert den entsprechenden Typ durch
Verwendung von Java Generics und übergibt die Ergebnismenge an die neu
generierte Instanz. Als Ergebnistypen werden Implementierungen der
Schnittstelle IResultSet unterstützt, welche die Informationen intern in das
entsprechende Format transformieren und nach außer zur Verfügung stellen.
85
Neben den Standardmethoden der Schnittstelle kann jeder Typ eine Menge
spezifischer Funktionen enthalten, wie die Extraktion als XTM.
Abbildung 18 - UML-Klassendiagramm der Ergebnisverarbeitung
Der Prototyp der TMQL4J-Engine stellt aktuell zwei Ergebnistypen zur

Verfügung, kann aber durch die verwendete Abstraktion und Transparenz
einfach erweitert werden.
Um die Prallelen zu SQL aufrecht zu erhalten, realisiert die TMQL4J-Engine

einen ähnlichen Ergebnistyp, wie das Java-Database-Connectivity-Konzept,
kurz JDBC. Gegenstand des Konzeptes ist die Bereitstellung des Ergebnisses
als dreidimensionales Objekt. Die erste Dimension bildet das konkrete Objekt
innerhalb eines Tupel. Die zweite Dimension stellt das Tupel selber dar,
innerhalb der dritten Dimension, der Tupelsequenz. Der Zugriff erfolgt durch
Iteration über die jeweiligen Dimensionen zum konkreten Objekt.
Der zweite Ergebnistyp dient der Evaluierung und Testphase der Entwicklung.
Die Tupelsequenz wird dafür in eine Canonical XML Topic Maps (CXTM)
überführt und als solche gespeichert. Ziel dieses Ergebnistyps ist der Vergleich
zu anderen TMQL-Engines (siehe 7.2).
86
Die Verarbeitung und semantische Interpretation der Ergebnisse im Kontext der

Anwendung, erfolgt dann durch die konkrete Anwendung selber.
6.5. Visualisierungstool TMQL4JViz
Um die Verwendbarkeit und Benutzerfreundlichkeit der entwickelten TMQL-

Engine zu erhöhen, enthält der aktuelle Prototyp das Visualisierungstool
TMQL4JViz. Hauptaufgabe von TMQL4JViz ist die Visualisierung der
generierten Baumstruktur eines TMQL-Query.
Der aktuelle Prototyp von TMQL4JViz besitzt eine Java-basierte graphische

Oberfläche, welche auf Basis des Swing-Frameworks entwickelt wurde. Die
beschriebene graphische Oberfläche besteht aktuell aus drei
Hauptkomponenten. Die Eingabemaske bildet die erste Komponente und
ermöglicht dem Nutzer die Angabe eines einzeiligen TMQL-Query. Bei der
zweiten Komponente handelt es sich um eine Textkonsole, welche
Informationen über den laufenden Parser-Prozess liefert und eventuell Fehler
während der Verarbeitung visualisiert.
Die Ausgabe der geparsten Baumstruktur bildet zweifelsfrei die wichtigste

Komponente des Visualisierungstools. Sie stellt die Baumstruktur in einer
übersichtlichen Art und Weise dar und liefert durch die Auswahl einzelner
Knoten wichtige Informationen über die enthaltene Folge von Token und
Terminalsymbolen des Teilausdrucks.
87
Abbildung 19 - Visualisierungstool TMQL4JViz
Im Rahmen der Testphase liefert die Visualisierung erste Informationen über

die Funktionsfähigkeit und eventuell Fehlinterpretationen des lexikalischen
Scanners bzw. Parsers. Es bildet somit die Grundlage für einen ersten und
groben Funktionstest, ohne die Verwendung von Testframeworks wie JUnit.
88
7. Testkonzeption
7. Testkonzeption
Die Testphase bildet keinen abgeschlossenen Prozess am Ende der

Entwicklung, sondern verläuft quasi parallel zur eigentlichen Implementierung.
Dabei werden einzelne neu implementierte Funktionalität direkt auf Fehler und
Funktionsfähigkeit hin untersucht, um Fehler schnell zu erkennen, mit dem Ziel
eine Fehlerfortpflanzung zu anderen Modulen zu vermeiden.
Im Rahmen der Testphase der TMQL4J-Engine kommen zwei Testansätze zur

Anwendung. Die Funktionalität einzelner Module wird durch Verwendung des
Testframeworks JUnit geprüft und überwacht. Zur Vergleichbarkeit zu anderen
TMQL-Engines wird der Ergebnistyp CXTM integriert.
Innerhalb der Tests wurde bewusst auf die Formulierung und Definition von
Testqueries verzichtet, da die Ergebnisse solcher TMQL-Anfragen nur im
Bezug auf eine konkrete Topic Maps vorhersagbar und überprüfbar sind und
somit keine Möglichkeit der allgemein gültigen Überprüfbarkeit von TMQL-
Engines bieten. Folglich wurde die Testphase auf eine Überprüfung der
Funktionalitäten, sowie der Möglichkeit der Vergleichbarkeit durch CXTM,
begrenzt.
7.1. Testframework JUnit
Das Testframework JUnit ist ein Java-basiertes Framework zum Testen

einzelner feingranularer Einheiten (Unit). Die Verwendung des JUnit ist dabei
einfach und wird von vielen Entwicklungsumgebungen, wie Eclipse, unterstützt.
Grundlage eines jeden Tests bildet ein so genannter Testfall. Ein Testfall
umfasst eine Menge von Operationen und Funktionsaufrufen, um die
Funktionalität einzelner Module automatisiert zu untersuchen. Die Ergebnisse
werden dann auf Basis von Behauptungen (Asserts) geprüft. Wird eine solche
Behauptung nicht erfüllt wird der Test mit einem Fehler abgebrochen.
Das feingranulare Konzept des Testframeworks JUnit, sowie die enge

Integration in die Entwicklungsumgebung selber, ermöglichen eine effiziente
89
7. Testkonzeption
und prozessbegleitende Umsetzung des Funktions- und Laufzeittests für

TMQL4J. Durch die starke Modularisierung der TMQL-Engine kann jede
Komponente theoretisch unabhängig voneinander einem solchen Test
unterzogen werden. Eine völlige Entkopplung ist allerdings nur bedingt möglich,
da einige Prozessschritt auf vorangegangen Ergebnissen aufbauen.
Ein weiterer Vorteil der Verwendung von JUnit als Testframework ist die
automatische Erfassung der Laufzeit eines Testfalles und der einzelnen Tests
innerhalb dieses Testfalls. Schwachstelle innerhalb der Implementierung oder
gar des TMQL-Drafts sind somit erkennbar, können analysiert und letztlich
behoben werden.
Im Rahmen des Entwicklungsprozesses wurden jeder Typ von Produktionsregel

des TMQL-Drafts, die Vorverarbeitungsroutine, der Lexikalische Scanner, der
Parser, sowie die Ergebnisverarbeitung im Minimum einem Testfall unterzogen.
Dabei wurde, neben der Funktionalität und Fehlerfreiheit, das Laufzeitverhalten,
d.h. die benötigte Rechenzeit dokumentiert. Die erfassten Ergebnisse werden in
der folgenden Tabelle dargestellt.
Testumfang Minimum Maximum Durchschnitt

Screener Path-Expression < 1 ms 15 ms 1,5 ms
Select-Expression < 1 ms 16 ms 1,6 ms
Flwr-Expression < 1 ms 15 ms 1,5 ms
Canonizer Path-Expression < 1 ms 15 ms 1,5 ms
Lexer Path-Expression < 1 ms 16 ms 6,3 ms
Parser Path-Expression < 1 ms 16 ms 9,4 ms
Interpreter Path-Expression 75 ms 93 ms 78,9 ms
Select-Expression 7156 ms 7266 ms 7214,3 ms
Flwr-Expression 350 ms 390 ms 373,1 ms
Results Path-Expression < 1 ms 15 ms 1,5 ms
Tabelle 6 - TMQL4J-Laufzeitmessung mit JUnit
90
7. Testkonzeption
Die Lauzeitmessungen der einzelnen TMQL4J-Module zeigen durch den

Vergleich aller drei Anfragetypen einen deutlichen Trend und erlauben die
Annahme, dass die Hauptverarbeitungszeit innerhalb des Interpreter liegt. Der
direkte Vergleich zwischen den drei Anfragetypen ist nicht sinnvoll, einzig die
Erkenntnis das Path-Expression durch ihr Verarbeitungsmodell meist schneller
verarbeitet werden als die beiden anderen Typen ist abschätzbar. Der Umfang
der einzelnen TMQL-Anfragen, sowie die Verwendung und Komplexität der
einzelnen Teilklauseln erhöhen bzw. minimieren die gemessenen Zeiten in
gewissem Umfang. Einzig die Schlussfolgerung, das Optimierung der Laufzeit
nur innerhalb des Interpreters als sinnvoll erscheinen, sei auf Basis der
gemessenen Zeiten möglich.
Die Tests sind keinesfalls als vollständig und abgeschlossen anzusehen, da im

Rahmen der Testphase nicht jede mögliche Kombination von TMQL-
Ausdrücken untersucht werden kann.
7.2. CXTM-Exports
Das Format der Canonical XML Topic Maps, CXTM, wurde entwickelt, um die
Vergleichbarkeit von einzelnen Topic-Maps-Engines zu ermöglichen. Grundlage
der Vergleichbarkeit, ist der Export der jeweiligen Topic Maps in ein CXTM-
Format, sowie der Vergleich beider Dateien auf Byteebene. Gemäß TMDM
besitzt eine Topic Maps allerdings keine interne Sortierung, was den Vergleich
auf Byteebene quasi unmöglich macht. Zur Lösung dieses Problems zwingt das
CXTM-Format allen Konstrukten der Topic Maps eine Sortierung auf. Die
Sortierung einzelner Informationselemente basiert auf einer Menge von
typspezifischen Regeln. Die Sortierung einer Sequenz orientiert sich
beispielsweise an der Mächtigkeit der Sequenzen und der enthalten Tupeln. Je
mehr Tupel ein Set enthält, desto höher wird es einsortiert. Die Sortierung
innerhalb des Sets, erfolgt paarweise nach kanonischer Sortierung.
Ergebnis eines CXTM-Exportes ist eine kanonische Repräsentierung der Topic

Maps in einer CXTM-Datei. Durch die Einhaltung dieser strikten Regeln wird
zudem die Vergleichbarkeit unabhängig von der verwendeten Topic-Maps-
Engine sichergestellt.
91
7. Testkonzeption
Der CXTM-Standard wurde allerdings für Topic-Maps-Engines konzipiert und

lässt sich somit nur bedingt für TMQL verwenden, der grundlegende Ansatz der
Verwendung von CXTM zum direkten Vergleich der Ergebnismengen zweier
TMQL-Engines auf Byteebene. Darauf aufbauend sind zwei konzeptuelle
Ansätze denkbar. Der erste Ansatz umfasst die Definition einer temporären
Topic Maps, welche genau die Elemente enthält, welche durch die
Ergebnissequenz des TMQL-Query abgedeckt werden. Eine Sortierung gemäß
den Regeln von CXTM stelle somit keine große Problematik dar. Ein zweiter
Ansatz ist die Erweiterung von CXTM um die XML-Elemente sequence und
tuple. Die Sortierung der einzelnen Tupel und Sequenzen orientiert sich wieder
an den bestehenden Regeln des aktuellen CXTM-Standards, dies ist möglich,
da es sich nur um Elemente einer Topic Maps handeln kann. Die Interpretation
als temporäre Topic Maps entfalle.
Der aktuelle Prototyp realisiert das erste Konzept, da eine Anpassung des
CXTM-Standards zeitaufwendig und die Anpassung bestehender
Implementierung eines CXTM-Exports ebenfalls den zeitlichen Rahmen der
TMQL-Engine-Entwicklung sprengen würden. Eine spätere Anpassung sollte
allerdings auch hier keinen großen Mehraufwand nach sich ziehen.
Ein positiver Nebeneffekt dieses Testkonzeptes ist die Möglichkeit der

Vergleichbarkeit über den Sprachstandard hinweg. Der Vergleich zu Toma bzw.
Tolog ist im Rahmen deren Sprachfähigkeiten möglich.
Aufgrund der fehlenden Unterstützung von CXTM durch existierende Topic-

Maps-Engines, wie die PerlTM, ist ein Vergleich zu anderen Implementierung
aktuellen nicht möglich.
92
8. Ausblick
8. Ausblick
In diesem Kapitel soll ein kleiner Ausblick auf mögliche Weiterentwicklungen

bzw. Anpassung des Prototyps gegeben werden. Ferner werden
Optimierungsansätze vorgestellt, um die Leistung des entwickelten Prototyps
verbessern zu können.
8.1. Weiterentwicklungen
Aktuell handelt es sich bei der TMQL4J-Engine um einen Prototyp, der noch
nicht den gewünschten Funktionsumfang des gesamten TMQL-Drafts abdecken
kann und soll. Eine Erweiterung zur vollständigen Abdeckung des Draft ist
geplant und befindet sich in Entwicklung. Zu den aktuell nicht unterstützten
Komponenten des Drafts zählen die Rückgabe der Ergebnisse als CTM- oder
XTM-Instanz. Begründet durch die Modularisierung der einzelnen
Komponenten, sowie der feingranularen Integration der Ergebnisverarbeitung,
stellt die Implementierung dieser Ergebnistypen keine große Problematik dar,
ist aber nicht Bestandteil dieser Arbeit.
Um die Verwendung der TMQL-Engine in komplexen, aber auch in privaten

Anwendungen, einfacher und intuitiver zu gestalten, wäre die Konzeption eines
Objektrelationen Mapping für Topic-Maps-Engines hilfreich. Der dadurch
erzielte Komfort lässt sich durch Betrachtung äquivalenter Ansätze im
Datenbanksektor sehr gut abschätzen. Hier erfreut sich das Framework
Hibernate schon heute sehr großer Beliebtheit und wird in vielen
Wirtschaftssektoren aktiv eingesetzt. Realisierungen solcher Konzepte im
Topic-Maps-Umfeld stellen aktuelle Entwicklungen um ActiveTM dar. ActiveTM
bildet einzelne Topics als Objekte der entsprechenden Programmiersprache ab
und ermöglicht den Zugriff auf Eigenschaftswerte über Instanz-Methoden. Die
Kombinationen der Entwicklung der TMQL-Engine und ActiveTM könnte in
Zukunft die Realisierung es Hibernate-Ansatzes für Topic Maps ermöglichen.
Aktuell bietet die TMQL4J-Engine nicht die Möglichkeit der Definition und
Integration eigener Operatoren bzw. Funktionen über die Environment-Klausel
93
8. Ausblick
eines TMQL-Query. Dieses Defizit soll ebenfalls durch die nächste Version der
TMQL4J-Engine beseitigt werden.
Eine wesentliche Erweiterung wird das Visualisierungstool TMQL4JViz

betreffen. Die graphische Oberfläche wird um eine Komponente, die
Ergebnisausgabe erweitert, um das Visualisierungstool iterativ zu einem
komplexen Werkzeug auszubauen. Die finale Version des Tools bietet dem
Nutzer die vollständige Funktionalität eines Datenbrowsers, zum Durchsuchen
von Topic-Maps-Backends, zum Selektieren von Daten und eventuell zum
Exportieren von Informationen. Das Tool soll somit die Funktionalität moderne
SQL-Tools im Umfeld von Topic Maps abdecken können. Eine spätere
Integration als Plug-In in Eclipse ist denkbar.
Als letzte wichtige Erweiterung ist die Integration einer

Konfigurationsschnittstelle geplant. Über Konfigurationsdateien soll die
Definition der zu verwendenden Implementierungen der einzelnen
Komponenten der TMQL4J-Prozesskette ermöglicht werden. Zusätzlich wird die
Konfigurationsschnittstelle um die Integration eines TMQL-Query-Caches
erweitert. Ziel dieser Integration ist die Unterstützung eines äquivalenten
Konzeptes zu LINQ. Das LINQ-Projekt ermöglicht die Definition von Statements
unter Verwendung definierter Platzhalter zur späteren Interpretation.
Optimierungsziel ist dabei die einmalige Verarbeitung bis zur eigentlichen
Interpretation mehrfachverwendeter TMQL- bzw. SQL-Anfragen.
Ferner ist der Einsatz von TMQL4J in diversen Projekten des Topic Maps Lab,
wie Musica Migrans oder Maiana, geplant.
8.2. Optimierungsansätze
Die TMQL4J-Engine wird sich dem aktuellen ISO-Standardisierungsprozess

von TMQL gemäß weiterentwickeln und die Funktionalitäten entsprechend
anpassen und erweitern, bzw. einzelne Funktionen verwerfen. Dabei zeigt sich
aber schon jetzt die Hauptproblematik der Engine, da eine exakte Orientierung
an den Draft mit Optimierungsproblemen verbunden ist. Auf der Grundlage
94
8. Ausblick
dieser Erkenntnis sind einige Optimierungsansätze denkbar, die in den

folgenden Entwicklungsprozess mit einfließen können und werden.
Hauptoptimierungsansatz ist die Schwachstelle der Verwendung von Multi-Sets

bzw. Listen innerhalb des Drafts. Laut der aktuellen Version liefert nahezu jede
Operation von TMQL, d.h. jede Interpretation eines atomaren Teilausdruckes
ein Multi-Set als Ergebnismenge. Als atomare gelten Teilausdrücke, welche
keine weiteren Teilausdrücke mehr enthalten, wie Navigation oder
Wahrheitsausdrücke. Die Problematik der Multi-Sets zeigt sich bei der
Verkettung von Teilausdrücken, wie die Navigation über verschiedene Achsen.
Es sei eine Topic Maps wie folgt angenommen, auf die Angabe von Rollentypen
wurde aus Übersichtlichkeit verzichtet.
iko
Typ A Typ B
isa
Instanz Instanz Instanz Instanz

a b c d
Abbildung 20 - Topic Maps als Verdeutlichung des Multi-Set-Problems
Im Folgenden wird der TMQL-Query, sowie dessen Ergebnissequenzen

betrachtet.
Typ_A << types >> types >> supertypes >> …

==> {A} << {a, b, c, d} >> {A, A, A, A} >> {B, B, B, B} >> …
Codefragment 46 - TMQL-Query und Ergebnissequenzen für Multi-Set-Problematik
Durch die strikte Verwendung von Multi-Sets im Rahmen eines einzigen

Navigationsschrittes entsteht eine Menge von Duplikaten schon innerhalb der
Ergebnissequenz dieses einfachen Bespiel. Faktisch ergibt sich daraus die
95
8. Ausblick
Problematik, dass die Engine eine gewisse Anzahl von Operationen unnötig
wiederholen muss, obwohl ihr das Ergebnis aufgrund von Duplikaten bereits
bekannt sein könnte. Diese Problematik verstärkt sich mit Komplexität der Topic
Maps rapide und führt zu einem signifikant höheren Verbrauch von Rechenzeit.
Um kompatibel zum aktuellen Draft zu bleiben und trotzdem dieses Problem
lösen zu können, ist die Verwendung eines intelligenten Multi-Sets denkbar.
Eine solche Implementierung ermöglicht eine Iteration nur über die Menge
verschiedener Tupel und repliziert die Ergebnisse beim wiedereinfügen in das
Ergebnisset. Zur Realisierung dieses Multi-Sets sind noch einige Fragestellung
offen bzw. zu klären. Die Programmiersprache Java ermöglicht keine
Manipulation der Iteration über solche Datenkollektion im Kontext des
Kontrollkonstrukts einer For-Schleife. Das zweite Problem bildet, die
Entkopplung der Eingabesequenz und der Ausgabesequenz, da die Information
über Duplikate nur der Eingabesequenz bekannt sind, ist es der
Ausgabesequenz nicht möglich die Anzahl an Duplikaten nach der Operation
einzufügen. Diese Probleme sind theoretisch lösbar, der wirkliche Mehrwert
müsste allerdings weiter untersucht werden. Die aktuelle Implementierung von
TMQL4J bietet durch Setzen der entsprechenden Systemvariablen die
Verwendung von Sets anstelle von Multi-Sets.
Eine weitere Problematik ergibt sich durch die strikte Ontologie-Unabhängigkeit

eines TMQL-Query. Zusatzwissen über die Ontologie einer konkreten Topic
Maps kann die Performance der Verarbeitung eines entsprechenden
Ausdruckes entscheidend beeinflussen. Die starke Modularisierung der
TMQL4J-Engine und die Integration eigener Interpreter bietet aber jederzeit die
Möglichkeit, domänenspezifische Anpassung mit ontologischem Zusatzwissen
vorzunehmen. Die Höhe des erzielten Performancegewinns ist dabei abhängig
vom Umfang des Domänenwissens, sowie der Anwendbarkeit im Bezug auf
einen konkreten TMQL-Query.
96
9. Schlusswort
9. Schlusswort
Im Rahmen dieser Arbeit wurde der TMQL-Draft analysiert. Zu Beginn wurde

TMQL in die Topic-Maps-Familie eingeordnet, um ein Verständnis des aktuellen
Topic-Maps-Umfeldes zu gewinnen, sowie ein Verständnis der grundlegenden
Konzepte des Topic-Maps-Paradigmata zu erlangen. Zusätzlich wurde ein
Vergleich zu syntaktisch ähnlichen Anfragesprachen anderer Datenmodelle
angerissen, um ein Verständnis der Terminologie von Anfragesprachen zu
gewinnen. Dabei wurde der Standard SQL hervorgehoben und Parallelen, aber
auch Unterschiede, zum aktuellen TMQL-Draft aufzuzeigen, sowie potentielle
Weiterentwicklungsansätze heraus zu filtern.
Aufbauend auf dem grundlegenden Verständnis der Terminologie von Topic

Maps, sowie dem Verständnis für Anfragesprachen, wurde der TMQL-Draft in
seiner aktuellen Form analysiert. Gegenstand der Analyse war die
Beschreibung der Grammatik, sowie die Abgrenzung der wichtigsten
Sprachbestandteile und Statement-Typen. Ziel dieser Analyse ist ein fundiertes
Verständnis der Sprache, sowie einzelner Sprachelemente.
Zur Vervollständigung der Terminologie wurde im Kapitel 4 der Vergleich zu

bestehenden bzw. sich parallel in Entwicklung befindlichen Abfragesprachen für
Topic Maps hergestellt. Dabei wurden Schwachstellen und Stärken gegenüber
TMQL gesondert hervorgehoben, sowie Parallelen zu TMQL aufgezeigt. Als
Erkenntnis dieses Vergleiches sei genannt, das Tolog-Anfragen sich komplett
durch TMQL-Anfragen ersetzten lassen, der Umkehrschluss ist nicht gegeben.
Toma hingegen stellt eine eigene Sprachsyntax, die äquivalent zu TMQL,
Schwächen und Stärken besitzt.
Ferner wurden Kritikpunkte und Probleme im aktuellen Draft aufgezeigt, sowie

Lösungsvorschläge analysiert. Als wichtigste Punkte sind die Inkonsistenz
einiger Achsen, die Problematik des Non-Canonical Level, sowie das Konzept
der Variablennamen benannt. Einige der Probleme sind aktuell nur bedingt
lösbar und können nur durch Anpassung des Draft vollständig behoben werden.
97
9. Schlusswort
Im darauf folgenden Kapitel wurden die Vorteile der verwendeten

Softwarearchitektur hervorgehoben, die einzelnen Module des entwickelten
Prototyps der TMQL4J-Engine voneinander abgegrenzt und deren Aufgaben
definiert, sowie deren Implementierung kurz angerissen. Im vorletzten Kapitel
wurden einige Testkonzepte vorgestellt, sowie deren Ergebnis soweit möglich
aufgezeigt und interpretiert.
Abschließend wurde ein Ausblick auf kommende Entwicklungen an der

TMQL4J-Engine gegeben, sowie Optimierungsansätze benannt. Als
wesentliche Punkte seien hier die Unterstützung von Multi-Sets, sowie die
Optimierung der TMQL-Verarbeitungsroutinen genannt.
Als Gesamtfazit lässt sich die Erkenntnis gewinnen, dass die Entwicklung einer
Engine zur Verarbeitung eines sich verändernden Drafts bzw. Standards,
Analyse, Entwurf und Implementierung vor einige Probleme stellt und
Fragestellungen aufwirft, welche gelöst werden mussten. Im Kontext von TMQL
war dies gleichbedeutend mit der Verwendung einer Softwarearchitektur, die
eine spätere Anpassung ohne großen Aufwand ermöglicht.
Da die Einsatzszenarien einer Sprache wie TMQL vielseitig sind, wird oft eine
domänenspezifische Implementierung benötigt, welche die Terminologie des
konkreten Szenarios abbilden kann. Der hohe Abstraktionsgrad, sowie das
feingranulare Modularisierungskonzept von TMQL4J bildet die Grundlage
genau dieses Ziel durch Verwendung der Engine umzusetzen.
Letztlich bleibt aber zu berücksichtigen, dass die Veränderung innerhalb des

Standardisierungsprozesses immer auch eine Anpassung von TMQL4J
bedeutet und einige Schwachstellen des Standards zu Performanceproblemen
innerhalb der Implementierung führen. Weiter liefern die Tests nur einen groben
Überblick über die Funktionalität und garantieren nie eine 100% Fehlerfreiheit
des Softwareproduktes. Einzige die Verwendung innerhalb konkreter Szenarien
wird zeigen, wie leistungsfähig und stabil der Einsatz von TMQL4J ist.
98
Literatur- und Quellenverzeichnis
[1] Andresen, A. (2004) Komponentenbasierte Softwareentwicklung mit

MDA, UML 2 und XML, 2nd edition, München: Carl Hanser Verlag
München Wien
[2] Bock, B. (2008) Topic-Maps-Middleware, Leipzig.
[3] Box, D. and Hejlsberg, A. (2007) LINQ:.NET Language-Integrated Query,

Februar, [Online], Available: http://msdn.microsoft.com/de-
de/library/bb308959(en-us).aspx [8. September 2009].
[4] Bracha, G. (2004) Generics in the Java Programming Language, 5. Juli,

[Online] [Juli 2009].
[5] Garshol, L.M. (2004) tolog - a topic maps query language, 16. Februar,
[Online], Available: http://www.ontopia.net/topicmaps/materials/tolog.html
[1. September 2009].
[6] Garshol, L.M. (2007) tolog - language tutorial, 24. August, [Online],
Available: http://www.ontopia.net/omnigator/docs/query/tutorial.html
[7] Heuer, L. and Schmidt, J. (2008) 'TMAPI 2.0', in Subject-centric

Computing, Leipzig.
[8] ISO/IEC 13250-2 (2006) Topic Maps - Data Model, 19. Juni, [Online],
Available: http://www.isotopicmaps.org/sam/sam-model/
[1. August 2009].
[9] ISO/IEC 13250-3 (2006) Topic Maps - XML Syntax, 19. Juni, [Online],
Available: http://www.isotopicmaps.org/sam/sam-xtm/#xtm1.0-
differences [1. August 2009].
XI
[10] ISO/IEC 13250-4 (2009) Topic Maps - Canonicalization - CXTM,
27. Januar, [Online], Available:
http://www.isotopicmaps.org/cxtm/cxtm.html [September 2009].
[11] ISO/IEC 13250-6 (2008) Topic Maps - Compact Syntax, 15. Mai,
[Online], Available: http://isotopicmaps.org/ctm/ctm.html
[5. August 2009].
[12] ISO/IEC 18048 (2002) Topic Maps Query Language, Use Cases,
12. April, [Online], Available: http://www.isotopicmaps.org/tmql/use-
cases.html [7. September 2009].
[13] ISO/IEC 18048 (2008) Topic Maps Query Language, 15. Mai, [Online],
Available: http://www.isotopicmaps.org/tmql/tmql.html [2009].
[14] ISO/IEC 19756 (2009) Topic Maps Constraint Language, 7. Juli, [Online],
Available: http://www.isotopicmaps.org/tmcl/tmcl.html
[15] Louis, D. and Peter, M. (2007) Java 5, München: Markt+Technik Verlag.
[16] Maicher, L. and Bock, B. (2008) ActiveTM - The Factory for Domain-
customised Portal Engines, Leipzig.
[17] Pinchuk, R. (2006) Toma Language Description, 31. Oktober, [Online],

Available: http://topiwriter.com/toma/Toma.html [August 2009].
[18] Pinchuk, R. (2009) Toma - Draft Suggestion for TMQL, 1. Juli, [Online],
Available: http://topiwriter.com/toma/TW_UM_TOMA_100.pdf [Juli 2009].
[19] Prasetya, W. (2009) JUnitQuickTurtorial: A quick JUnit tutorial for

beginners, 8. September, [Online], Available:
http://code.google.com/p/t2framework/wiki/JUnitQuickTutorial
XII
[20] RDF Core Working Group (2004) RDF/XML Syntax Specification,
10. Februar, [Online], Available: http://www.w3.org/TR/rdf-syntax-
grammar/ [7. September 2009].
[21] RDF Data Access Working Group (2008) SPARQL Query Language for
RDF, 15. Januar, [Online], Available: http://www.w3.org/TR/rdf-sparql-
query/ [7. September 2009].
[22] Schneider, U. and Werner, D. (2001) Taschenbuch der Informatik, 4th

edition, Leipzig: Fachbuchverlag Leipzig.
[23] TMAPI Community (2008) Common Topic Map Application Programming

Interface, 26. August, [Online], Available: http://www.tmapi.org/
[10. August 2009].
[24] Topic Maps Lab (2009) Topic Maps Lab, Leipzig: Matthes & Hofer.
[25] Ullenboom, C. (2009) Java ist auch eine Insel, 8th edition, Bonn: Galileo
Press.
[26] W3C XML Schema Working Group (2004) XML Shema Part 2:
Datatypes Second Edition, 28. Oktober, [Online], Available:
http://www.w3.org/TR/xmlschema-2/ [Juli 2009].
[27] Wikibooks (2009) Einführung in SQL: Funktionen, 20. Juli, [Online],

Available:
http://de.wikibooks.org/wiki/Einf%C3%BChrung_in_SQL:_Funktionen
[25. Juli 2009].
[28] Wikipedia (2009) Lexer - Lexikalischer Scanner, 12. April, [Online],

Available: http://de.wikipedia.org/wiki/Lexikalischer_Scanner [Juli 2009].
[29] Wikipedia (2009) Parser, 24. Januar, [Online], Available:

http://de.wikipedia.org/wiki/Parser [Juli 2009].
XIII
[30] Wikipedia (2009) SQL, 4. Juli, [Online], Available:
http://de.wikipedia.org/wiki/SQL [25. Juli 2009].
[31] XSL Working Group (1999) XML Path Language (XPath) Version 1.0,
16. November, [Online], Available: http://www.w3.org/TR/xpath
XIV
Selbstständigkeitserklärung
Ich versichere wahrheitsgemäß, die Masterarbeit selbstständig angefertigt, alle

benutzen Hilfsmittel vollständig und genau angegeben und alles kenntlich
gemacht zu haben, was aus Arbeiten anderer unverändert oder mit
Abänderungen entnommen wurde.
Leipzig, den 22.09.2009

……………………………….
Unterschrift des Verfassers

Konzeption, Implementierung Und Evaluierung Eines TMQL-Parsers Und Interpreters

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Konzeption, Implementierung Und Evaluierung Eines TMQL-Parsers Und Interpreters

Hochgeladen von

Copyright:

Verfügbare Formate

Konzeption, Implementierung und Evaluierung

eines TMQL-Parsers und Interpreters

eingereicht von: Sven Krosse

Betreuer: Prof. Dr. Gerhard Heyer

Mit der Entwicklung im Rahmen des Web 2.0. gewann die

1. Vorwort, Einleitung und Motivation .............................................................. 1

Binding Binding bezeichnet den Vorgang der Bindung einer Variable

Canonizer Als Canonizer wird ein spezielles Computerprogramm

Context Der Begriff Context im Rahmen einer TMQL-Verarbeitung

Content Der Oberbegriff des Content beschreibt die Menge von

Direktive Zusätzliches Wissen über die Ontologie der Topic Maps

Engine Der Begriff der Engine repräsentiert ein Softwareprodukt

Environment Als Environment wird die TMQL-Ontologie bezeichnet. Die

Expression Jede definierte Produktionsregel von TMQL wird als

Stack Der Begriff des Stack beschreibt ein Konzept der

Terminalsymbol Terminalsymbole von TMQL sind zusammenhängende

Token Als Token wird ein Element des TMQL-Query bezeichnet,

Tupel Ein Tupel beschreibt exakt die Menge zusammen-

Tupelsequenz Eine zusammenhängende Menge von Tupeln wird auch als

Abbildung 1 - Abstraktion der Klassenhierarchie des TMDM[8] .......................... 6

Codefragment 1 – Beispielcode für RTM zur Veranschaulichung der

1. Vorwort, Einleitung und Motivation

In der aktuellen Entwicklung von Portalen und Webanwendungen gewinnt das

Je nach funktionalen und nicht-funktionalen Anforderungen existieren

Ein Hauptproblem moderner und innovativer Anwendungen ist die zunehmende

relationaler Datenbanksysteme. Im Bereich Topic Maps existiert aktuell nur der

1.1. Zielstellung und Abgrenzung der Thematik

Verarbeitungen und Bedeutungen. Zusätzlich werden die wichtigsten

Die resultierende Implementierung stellt primär eine prototypische Basis zur

Um ein Verständnis der Terminologie von TMQL zu erhalten, werden im ersten

Aufbauend auf den Grundlagen folgt die im Kapitel 3 angesprochene Analyse

Im letzten Kapitel wird ein Ausblick auf Weiterentwicklungen gegeben. Dabei

2.1. Das Topic Maps Data Model – TMDM

Abbildung 1 - Abstraktion der Klassenhierarchie des TMDM[8]

Die eindeutige Identität eines Informationselements, auch Topic genannt,

Unter dem Begriff der Informationselemente bzw. Topic-Maps-Elemente

Kernkonzept des aussagegegenstandszentrierten Modellierungsparadigma, als

Gegensatz zur Objektorientierung kann ein Topic gleichzeitig Instanz

Die Informationselemente Occurrences und Namen, definieren eine Menge von

Beziehungen zwischen konkreten Subjekten der realen Welt werden als

Zusätzliche Konzepte des TMDM sind die bereits angesprochene Reifikation,

Jedes Topic-Maps-Element kann einen Scope besitzen. Der Scope definiert

2.2. Common Topic Map Application Programming Interface – TMAPI

Integrationsprozess der TMAPI in die Topic-Maps-Community und somit die

Codefragment 1 - Beispielcode für RTM zur Veranschaulichung der Vereinfachung und

2.3. Serialisierung und Deserialisierung von Topic Maps

Der aktuelle TMQL-Draft spezifiziert Möglichkeiten zur Generierung von Topic-

Durch Überführung eines Datenbestandes der konkreten Datenbasis in CTM

Die genaue Realisierung des Prozesses der Serialisierung bzw.

2.3.1. Compact-Topic-Maps-Syntax – CTM

Die Compact-Topic-Maps-Syntax (CTM) stellt eine auf Text basierte, kompakte

Jedes CTM-Dokument beschreibt dabei immer genau eine konkrete Topic

Die folgende Produktionsregel spezifiziert die Definition eines Topics unter

topic ::= topic-identity topic-tail* '.'

Codefragment 2 - CTM-Syntax zur Definition von Topics[11]

http://www.leipzig.de isa city;

Namen und Occurrences werden durch Verwendung das entsprechende CTM-

2.3.2. XML-Topic-Maps-Syntax – XTM

Die XML-Topic-Maps-Syntax (XTM) ist ein XML basiertes Austauschformat für

Während der Serialisierung, gemäß dem XTM-Standard, wird jedes

Die Beschreibung des XML-Schema, einer XTM-Instanz, erfolgt wahlweise mit

Als Realisierung des fundamentalen Beziehungskonzeptes zwischen Topics

Alle reifizierbaren Informationsressourcen können das optionale reifier Attribut