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.

I

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

II

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

III

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

IV

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

V

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.

VI

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

VII

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

VIII

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

IX

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

X

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

1. Vorwort, Einleitung und Motivation

1


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]


2

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


3

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.


4

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.

2. Grundlagen

5

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.

2. Grundlagen

6

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

2. Grundlagen

7

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.

2. Grundlagen

8

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 Inter face – 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]

2. Grundlagen

9

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 Veranscha ulichung der Vereinfachung und Erweiterungen gegenüber TMAPI

2. Grundlagen

10

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

2. Grundlagen

11

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.

2. Grundlagen

12

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

topic-tail ::= identity | assignment | topic-templ ate-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 Topi cs[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 Sy ntax 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).

2. Grundlagen

13

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.

2. Grundlagen

14

<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" max Occurs="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="requir ed"/> </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 Assoziati on[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

2. Grundlagen

15

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

2. Grundlagen

16

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]

2. Grundlagen

17

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,

avg, stddev count für Tupelsequenzen

String-Funktion concat, length upper, lower, substr, replace

concat, length

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

2. Grundlagen

18

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 Langua ge

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

2. Grundlagen

19

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.

3. Topic Maps Query Language - TMQL

20


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


21

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.


22

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 Termin alsymbole

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


23

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.


24

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.


25

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 Standard s 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.


26

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äß XS D 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.


27

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 a ktuellen 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.


28

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 E lement-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.


29

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.


30

Achsen Vorwärtsrichtung Rückwärtsrichtung types alle Typen der aktuellen

Instanz alle Instanzen des aktuellen Typs

supertypes alle Supertypen des aktuellen Typs

alle Subtypen des aktuelle Typs

players alle an dieser Assoziation teilnehmenden Topics

alle Assoziation, an dem das Topic teilnimmt

roles alle Rollentypen der Assoziation

alle Assoziation, welche den Rollentyp verwenden

traverse alle Topics, welche gemeinsam mit dem Topic an einer Assoziation teilnehmen

alle Assoziation, welche über ein Topic mit der Assoziation verbunden sind

characteristics alle Eigenschaften ( Namen und Occurrences) des Topics

alle Topics, welche die Eigenschaft besitzen

indicators alle Subject-Identifier des Topics

das Topic, welches den Subject-Identifier besitzt

locators alle Subject-Locator des Topics

das Topic, welches den Subject-Locator besitzt

item alle Item-Identifier des Topics als Zeichenkette

das Topic, welches den Item-Identifier besitzt

scope liefert den Scope der Assoziation bzw. der Eigenschaften

liefert alle Eigenschaft des optionalen Topics, welche im aktuellen Scope gültig sind

reifier liefert das reifizierte Element innerhalb der Topic Maps

liefert alle Reifizierungen des aktuellen Elementes

atomify Serialisierung des aktuellen Elementes

Deserialisierung des Wertes zu einem Element der Topic Maps

Tabelle 4 - Navigationsachsen von TMQL, basierend a uf der Struktur einer Topic Maps nach TMDM

3.5. Untersuchung wichtiger Produktionsregeln und T eilausdrü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


31

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-Cont ent

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-C ontent

Zur genauen Abgrenzung der beiden Content-Typen wird folgendes Beispiel

betrachtet.


32

leipzig / population #is simple-content {leipzig, leipzig / population} #is complex-content

Codefragment 15 - Beispiel zur Abgrenzung der Conte nt-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 Compo site-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


33

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


34

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


35

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 c ity

:= { leipzig, 515000 }; { berlin, 3431000 };

Codefragment 19 - TMQL-Anfrage zur Verdeutlichung d er 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.


36

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


37

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-operato r value-expression

value-expression ::= prefix-operator value-expressi on

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


38

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 E xpression

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.


39

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-cl ause

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 Quantifizierungsop eratoren

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


40

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.


41

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.


42

Abbildung 3 - schematische Darstellung des Verarbei tungsmodells 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


43

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


44

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.


45

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 F ilterdefinition 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-co mposed-by ])

Codefragment 28 - Beispiel für eine Kombination von Projektion und Filtern


46

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: univers ity-of-leipzig)

Codefragment 29 - Produktionsregel und Beispiel ein er 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.


47

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 ] [ WHERE boolean-expression ] [ ORDER BY < value-expression >] [ UNIQUE] [ OFFSET value-expression ] [ LIMIT value-expression ]

Codefragment 31 - Grammatikregel der Select-Express ion

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)


48

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


49

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 Verarbeitungsprozesse s einer Select-Expression


50

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 ]

[ WHERE boolean-expression ]

[ ORDER BY < value-expression >]

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.


51

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.

Abbildung 5 - Abstraktion des Verarbeitungsprozesse s einer FLWR-Expression

FLWR-Expression

existiert For-

Klausel?

Erzeugung aller

Bindingsets

Bindingstack

@_

Ja

existiert weitere

For-Klausel?

Ja

existiert Where-

Klausel?

existiert Order-By-

Klausel?

Sortierung der

Bindings

Test gegen null

Test gegen

Wahrheits-

ausdruck

Ja

Nein

Nein

Nein

@_

@_

Nein

Evaluierung der

Return-Klausel

Verknüpfen der

Sequenzen

existiert weiteres

Binding?

Ergebnis

Ja

Nein

4. Vergleich zu anderen Anfragesprachen – Toma und Tolog

52

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.


53

city-of-birth($PERSON : person, leipzig : city),

date-of-birth($PERSON : person, $DATE : date)?

Codefragment 34 - Verknüpfung von Prädikaten in Tol og

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.


54

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_sele ct ] [ ORDER BY expr1 [ ASC | DESC ] [, expr2 [ ASC | DE SC ] ...] ] [ LIMIT integer ] [ OFFSET integer ];

select $person.name where $person.oc(date_of_birth) = “01.01.1970“;

Codefragment 36 - Select-Style von Toma mit einem s implen 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


55

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 Spiele rn


56

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).

5. Analyse der Kritikpunkte des aktuellen Drafts

57


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.


58

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,


59

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.

Codefragment 38 - XSD-Definition der Abbildung von Java-Datentypen auf XSD-Datentypen

<complexType name="entryNode"> <attribute name="type" type="anySimpleType" defaul t="*" /> <attribute name="class" type="string" /> <attribute name="serializer" type="string" use="op tional" /> <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" />


60

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 # integ er "http://example.org/something"^^xsd:string # strin g "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.


61

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


62

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


63

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


64

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


65

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.


66

Sven_Krosse >> traverse = {Leipzig, Leipzig} | {Lei pzig}

Codefragment 41 - TMQL-Navigation und mögliche Erge bnismengen

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 Gr ammatik

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-Iden tifier

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


67

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


68

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.


69

...

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 Bedeut ung 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 Bedeut ung 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.

6. Entwurf und Implementierung der TMQL-Engine TMQL4J

70

6. Entwurf und Implementierung der TMQL-Engine - TM QL4J

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.


71

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.


72

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.


73

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-


74

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 z ur 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


75

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 a uf 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


76

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).


77

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.


78

Abbildung 12 - UML-Klassendiagramm des TMQL4J-Prepr ocessing

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


79

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 lexikalische n 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


80

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 Struk tur des TMQL-Ausdrucks

jack << players member >> roles [ 1 .. 2 ]


81

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


82

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.

+parse()

+getParserTree() : IParserTree

«interface»

IParser

+root() : IExpression

+getQuery() : IQuery

«interface»

IParserTree

+subExpression() : List<IExpression>

+tokens() : List<String>

+tmqlTokens() : List<TMQLTokens>

+getType() : int

+subExpression(ein ex : IExpression)

+getParent() : IExpression

+interpret(ein runtime : TMQLRuntime)

«interface»

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)

-children : List<IExpression>

-tmqlTokens : List<TMQLTokens>

-tokens : List<String>

-type : int

-parent : IExpression

ExpressionImpl

+root() : IExpression

+getQuery() : IQuery

#create(ein lexer : ILexer) : IParserTree

-root : IExpression

-query : IQuery

ParserTreeImpl

+getParserTree() : IParserTree

+parse()

-lexer : ILexer

-tree : IParserTree

TMQLParser

Abbildung 15 - UML-Klassendiagramm der Parser-Besta ndteile

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.


83

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 Variablenver arbeitung

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


84

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.


85

Abbildung 17 - UML-Klassendiagramm des TMQL-Interpr eter

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.


86

Neben den Standardmethoden der Schnittstelle kann jeder Typ eine Menge

spezifischer Funktionen enthalten, wie die Extraktion als XTM.

Abbildung 18 - UML-Klassendiagramm der Ergebnisvera rbeitung

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).


87

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.


88

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.

7. Testkonzeption

89

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

7. Testkonzeption

90

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 Select-Expression Flwr-Expression

< 1 ms < 1 ms < 1 ms

15 ms 16 ms 15 ms

1,5 ms 1,6 ms 1,5 ms

Canonizer Path-Expression Select-Expression Flwr-Expression

< 1 ms < 1 ms < 1 ms

15 ms 15 ms 16 ms

1,5 ms 1,5 ms 3,2 ms

Lexer Path-Expression Select-Expression Flwr-Expression

< 1 ms < 1 ms < 1 ms

16 ms 15 ms 15 ms

6,3 ms 6,0 ms 3,0 ms

Parser Path-Expression Select-Expression Flwr-Expression

< 1 ms < 1 ms < 1 ms

16 ms 16 ms 63 ms

9,4 ms 12,4 ms 19,1 ms

Interpreter Path-Expression Select-Expression Flwr-Expression

75 ms 7156 ms 350 ms

93 ms 7266 ms 390 ms

78,9 ms 7214,3 ms 373,1 ms

Results Path-Expression Select-Expression Flwr-Expression

< 1 ms < 1 ms < 1 ms

15 ms 16 ms 15 ms

1,5 ms 1,6 ms 1,5 ms

Tabelle 6 - TMQL4J-Laufzeitmessung mit JUnit

7. Testkonzeption

91

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.

7. Testkonzeption

92

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.

8. Ausblick

93

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

8. Ausblick

94

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

8. Ausblick

95

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.

Typ A Typ B

Instanz

a

Instanz

b

Instanz

c

Instanz

d

isa

iko

Abbildung 20 - Topic Maps als Verdeutlichung des Mu lti-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

8. Ausblick

96

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.

9. Schlusswort

97

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.

9. Schlusswort

98

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.

XI

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].

XII

[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


XIII

[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].

XIV

[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


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

Documents

Transcript of Konzeption, Implementierung und Evaluierung eines TMQL-Parsers und Interpreters