Entwicklung eines Expertensystems zur automatischen Erstellung

Transcription

Entwicklung eines Expertensystems zur
automatischen Erstellung effizienter
Information-Extraction-Pipelines
von
Mirko Rose
Fakultät für Elektrotechnik, Informatik und Mathematik
Warburger Straße 100
33098 Paderborn
Entwicklung eines
Expertensystems zur
automatischen Erstellung
effizienter
Master-Arbeit
im Rahmen des Studiengangs Informatik
zur Erlangung des Grades
Master of Science
von
Mirko Rose
Gebrüder-Grimm-Straße 6
33154 Salzkotten
vorgelegt bei
Prof. Dr. Gregor Engels
und
Dr. Theodor Lettmann
Paderborn, April 2012
Erklärung
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer
als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder
ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen worden ist. Alle Ausführungen, die
wörtlich oder sinngemäß übernommen worden sind, sind als solche gekennzeichnet.
Ort, Datum
Unterschrift
v
Zusammenfassung
In natürlichsprachigen Texten verborgene Informationen automatisiert sichtbar zu
machen ist die Aufgabe der Information Extraction. Die Ergebnisse der einzelnen
Algorithmen der Information Extraction bauen dabei größtenteils aufeinander auf.
Daher werden diese Algorithmen üblicherweise in einer sogenannten InformationExtraction-Pipeline (IE-Pipeline) sequentiell angeordnet und ausgeführt. Der Aufbau dieser Pipeline erfordert ein Wissen und Verständnis über die vielfältigen
Abhängigkeiten zwischen den einzelnen Algorithmen. Hinzu kommen Anforderungen an die Qualität der zu konstruierenden Pipeline hinsichtlich ihrer Effektivität
und Laufzeiteffizienz. Diese Anforderungen müssen bei der Auswahl der Algorithmen für die Pipeline beachtet werden. Die manuelle Erstellung von IE-Pipelines
erfordert daher einen großen Aufwand. Das macht sie zeitaufwendig und damit teuer. In dieser Arbeit wird deshalb ein automatisiertes Verfahren zur Konstruktion
von IE-Pipelines in Form eines Expertensystems entwickelt. Das Expertensystem
berücksichtigt dabei für seine Arbeit alle eben genannten Aspekte zur Konstruktion von effizienten und effektiven IE-Pipelines.
vii
Inhalt
1 Einleitung
1
2 Grundlagen
2.1 Expertensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Aufgabenbereiche von Expertensystemen . . . . . . . . . .
2.1.2 Architektur von Expertensystemen . . . . . . . . . . . . .
2.2 Formale Wissensrepräsentation . . . . . . . . . . . . . . . . . . .
2.2.1 Formen der Wissensrepräsentation . . . . . . . . . . . . .
2.2.2 Ontologien und Wissensbasen . . . . . . . . . . . . . . . .
2.3 Schlussfolgerungsverfahren in Expertensystemen . . . . . . . . . .
2.3.1 Schlussfolgern in OWL-Ontologien . . . . . . . . . . . . .
2.3.2 Planungsverfahren . . . . . . . . . . . . . . . . . . . . . .
2.4 Information Extraction . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Die Domäne Information Extraction . . . . . . . . . . . .
2.4.2 Information-Extraction-Pipelines . . . . . . . . . . . . . .
2.4.3 Effizienz und Effektivität im Bereich Information Extraction
5
5
6
6
9
10
12
17
17
19
30
30
32
35
3 Stand der Technik
3.1 Übersicht über existierende Expertensysteme . . . . . . . . . . . .
3.2 Effiziente Information-Extraction-Pipelines . . . . . . . . . . . . .
3.3 Automatische Konstruktion von Information-Extraction-Pipelines
3.3.1 Im Umfeld Information Extraction . . . . . . . . . . . . .
3.3.2 Ähnliche Arbeiten aus anderen Bereichen . . . . . . . . . .
41
41
44
47
47
50
4 Konzeptueller Lösungsansatz
4.1 Konstruktion der Information-Extraction-Pipeline . . . . . . . . .
4.1.1 Untersuchung von Planning und Reasoning zur Konstruktion der IE-Pipeline . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Planungsproblem der Konstruktion der IE-Pipeline . . . .
4.1.3 Lösungsansatz des Algorithmenauswahlproblems . . . . . .
4.1.4 Topologische Sortierung des vom Planer erzeugten Abhängigkeitsgraphen . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.5 Zusätzliche Filter zur Erfüllung von Randbedingungen . .
4.1.6 Ausführung der IE-Pipeline zum Erhalt der Ergebnisse . .
4.2 Die Wissensbasis des Expertensystems . . . . . . . . . . . . . . .
4.2.1 Konzept der entwickelten Ontologie . . . . . . . . . . . . .
53
55
57
58
65
72
78
80
81
81
ix
Inhalt
.
.
.
.
.
.
86
87
88
89
90
91
5 Realisierung
5.1 Vorstellung des eingesetzten IE-Frameworks . . . . . . . . . . . .
5.2 Importieren der Informationen des eingesetzten IE-Frameworks . .
5.3 Zusätzliche Elemente der Wissensbasis . . . . . . . . . . . . . . .
5.4 Anpassungen an der Berechnung und Ausführung der IE-Pipeline
5.4.1 Realisierungsaspekte der Berechnung der IE-Pipeline . . .
5.4.2 Realisierungsaspekte der Ausführung der IE-Pipeline . . .
93
93
95
97
99
99
103
4.3
4.2.2 Begründung für eine Ontologie als Wissensbasis
4.2.3 Hinzufügen von neuem Wissen in die Ontologie
4.2.4 Kapselung der Ontologie durch ein Datenmodell
Anfragen an das Expertensystem . . . . . . . . . . . .
4.3.1 Eingaben in das Expertensystem . . . . . . . .
4.3.2 Erklärungen von Seiten des Expertensystems . .
6 Implementierung
6.1 Implementierung der Expertensystemarchitektur . . .
6.1.1 Implementierungsdetails der Ontologie . . . .
6.1.2 Implementierungsdetails des Datenmodells . .
6.1.3 Implementierungsdetails der Berechnung und
der IE-Pipeline . . . . . . . . . . . . . . . . .
6.2 Möglichkeiten zur Erweiterung des Gesamtsystems . .
6.2.1 Wechseln des IE-Frameworks . . . . . . . . . .
6.2.2 Erweiterung der Ontologie . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
107
. . . . . . . 107
. . . . . . . 110
. . . . . . . 111
Ausführung
. . . . . . . 112
. . . . . . . 114
. . . . . . . 114
. . . . . . . 115
7 Evaluierung
117
7.1 Evaluierung der Funktionalität des entwickelten Expertensystems 117
7.1.1 Analyse einer berechneten IE-Pipeline . . . . . . . . . . . 119
7.1.2 Evaluierung des Lösungsansatzes des Algorithmenauswahlproblems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.1.3 Evaluierung des Filteransatzes . . . . . . . . . . . . . . . . 126
7.2 Evaluierung des Problems der nicht vollständigen Maximum Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8 Zusammenfassung und Ausblick
129
Anhang
A Tabellen
135
B Abbildungen
141
C UML-Diagramme
147
D Inhalte der beigefügten DVD
157
x
Inhalt
Literatur
159
xi
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
2.6
Architektur eines Expertensystems [Pup91] . . . .
Beispielontologie der Domäne Computer . . . . .
Blocksworld im Zustand Zustand0 . . . . . . . .
Zustandsraumgraph für das Blocksworld Beispiel .
Topologische Sortierung eines Beispielgraphen . .
Beispiel eines partiellen Teilplans . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
7
14
20
24
26
28
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Architektur des Expertensystems . . . . . . . . . . . . . . . . .
Berechnung der IE-Pipeline . . . . . . . . . . . . . . . . . . . .
Durch Benutzer wählbare Priorisierungen . . . . . . . . . . . . .
Beispiel DAG mit zwei möglichen topologischen Sortierungen . .
Ein Beispieldurchlauf der eingesetzten topologischen Sortierung.
Resultierende Pipeline aus gegebenem partiellen Plan . . . . . .
Ontologie des Expertensystems . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
54
64
68
73
77
78
82
5.1
5.2
Übersetzung einer fiktiven UIMA-Typenhierarchie in Ontologieform 96
Ein fiktiver Algorithmus Umsatzaussagenklassifizierer in Ontologieform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
Aktivitätendiagramm des internen Arbeitsablaufs des Expertensystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.1
6.2
6.3
Architekturübersicht des Expertensystems . . . . . . . . . . . . .
Schnittstelle des Expertensystems . . . . . . . . . . . . . . . . . .
Die Komponenten des ProblemSolver . . . . . . . . . . . . . . . .
108
109
113
7.1
7.2
7.3
7.4
Abhängigkeitsgraph nach Planung . . . . . . .
Berechnete Evaluierungspipeline . . . . . . . .
Berechnete Evaluierungspipeline mit Fokus auf
Berechnete Evaluierungspipeline mit Textfilter
.
.
.
.
121
122
124
126
B.1 Im Expertensystem benutzte Annotationstypenhierarchie als Klassendiagramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Bildschirmoberfläche der Interviewerkomponente (1) . . . . . . . .
B.3 Bildschirmoberfläche der Interviewerkomponente (2) . . . . . . . .
B.4 Bildschirmoberfläche der Erklärungskomponente . . . . . . . . . .
B.5 Bildschirmoberfläche der gefundenen Ergebnisse . . . . . . . . . .
142
143
144
145
146
C.1 Klassendiagramm des Datenmodells für das Package type . . . . .
148
. . . . . . .
. . . . . . .
Effektivität
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
xiii
Abbildungsverzeichnis
C.2
C.3
C.4
C.5
C.6
C.7
C.8
xiv
Klassendiagramm des Datenmodells für das Package algorithm . . 149
Klassendiagramm des Datenmodells für das Package qualityCriterion150
Klassendiagramm des Datenmodells für das Package filter . . . . . 151
Klassendiagramm der Wissensbasis . . . . . . . . . . . . . . . . . 152
Klassendiagramm der OntologyImporter -Komponente . . . . . . . 153
Klassendiagramm der ProblemSolver -Komponente . . . . . . . . . 154
Sequenzdiagramm mit Beispielablauf in der Problemlösungskomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Tabellenverzeichnis
2.1
Beziehung zwischen manueller und algorithmischer Annotation [SR02] 37
4.1
Datatype Properties der Ontologie . . . . . . . . . . . . . . . . . .
85
5.1
5.2
Erklärung der UIMA-Begriffe . . . . . . . . . . . . . . . . . . . .
Gütekriterien in der Ontologie . . . . . . . . . . . . . . . . . . . .
94
98
6.1
Beispielmethoden der Ontologieschnittstelle . . . . . . . . . . . .
110
7.1
7.2
Die in der Pipeline Πeval vorkommenden IE- und NLP-Algorithmen 118
Laufzeitwerte für Teile des Expertensystems . . . . . . . . . . . . 123
A.1 OWL-Konstruktoren in Beschreibungslogik (DL) [BHS07] . . . . . 136
A.2 OWL-Axiome in Beschreibungslogik (DL) [BHS07] . . . . . . . . 136
A.3 Die vom Expertensystem verwendbaren IE- und NLP-Algorithmen. 137
xv
Algorithmenverzeichnis
1
2
Pseudocode Vorwärtssuche (vgl. [NGT04]) . . . . . . . . . . . . .
Pseudocode Partial Order Planning (vgl. [Wel94]) . . . . . . . . .
25
27
3
4
5
6
7
8
Pseudocode für die Berechnung der IE-Pipeline . . . . . . . . .
planPipeline(Actions A, Goals G, Constraints C) . . . . . . .
selectBestAction(Subgoal (p, a), Actions A, Constraints C) .
getBestActions(Actions A, Quality Criterion q) . . . . . . .
getValue(Action a, Quality Criterion q) . . . . . . . . . . . . .
topologicalSort(Partial Plan partialP lan) . . . . . . . . . .
62
62
69
69
70
75
.
.
.
.
.
.
xvii
1 Einleitung
Das Finden von Informationen in Texten, welches über eine bloße Stichwortsuche hinausgeht, ist von allgemeinem Interesse. Die meisten Dokumente sind allerdings von Menschen für Menschen geschrieben worden. Sie enthalten eine Vielzahl
von Informationen in Fließtextform. Die Informationen sind daher nicht explizit
gekennzeichnet, sondern ergeben sich erst aus dem Zusammenhang und den Beziehungen der einzelnen Textteile zu- und untereinander. Diese Zusammenhänge
können sehr komplex sein und die Komplexität natürlicher Sprache erschwert zudem noch ihre Aufdeckung.
Ein Wirtschaftsanalyst könnte zum Beispiel Informationen benötigen, die Marktvorhersagen betreffen. Eine solche Vorhersage ist beispielsweise die Aussage eines
Unternehmens, mit welchem Umsatz es in Zukunft rechnet (vgl. [SMGW05]). Der
Analyst verwendet diese Informationen, um erfolgreicher auf dem Aktienmarkt
agieren zu können. Wirtschaftsmeldungen auf verschiedensten Webseiten sind die
Quelle seiner Informationen. Allerdings müssen alle diese Artikel mühsam von
ihm gelesen werden, um die gesuchten Marktvorhersagen zu identifizieren. Bei
der großen Menge an Wirtschaftsmeldungen jeden Tag in vielen verschiedenen
Sprachen, hat dies einen sehr großen Zeitaufwand zur Folge, wenn es überhaupt
für eine Einzelperson schaffbar ist. Aus diesem Grund wurden sogenannte TextMining-Computeranwendungen entwickelt. Sie entlasten den Menschen, indem sie
versuchen, die gewünschten zunächst unstrukturierten Informationen automatisch
aus Texten zu extrahieren und zu strukturieren und sie damit für einen einfachen
und schnellen Zugriff verfügbar zu machen.
Die Komplexität der Aufgabe macht die maschinelle Verwertung und Analyse
der Texte zu einer Herausforderung. Sätze müssen erkannt und korrekt in ihre
Bestandteile wie Subjekte und Verben zerlegt und Informationen, wie Geldaussagen und Unternehmensnamen, identifiziert werden. Für jede dieser Teilaufgaben
existieren eigene Algorithmen. Diese Algorithmen finden und strukturieren die
in natürlichsprachigem Text vorkommenden unstrukturierten Informationen und
lassen sich damit in den Aufgabenbereich der Information Extraction einordnen.
Die Algorithmen der Information Extraction bauen bei ihren Analysen größtenteils aufeinander auf. So kann für die Identifizierung von Firmennamen eine vorherige Erkennung von Sätzen und deren Sub- und Objekte notwendig sein. Das
Fehlen dieser Informationen kann dazu führen, dass der die Firmennamen erkennende Algorithmus seine Analyse nicht durchführen kann. Die Reihenfolge der
Ausführung der Algorithmen ist daher von großer Bedeutung. Aus diesem Grund
werden die Algorithmen in der Information Extraction üblicherweise in einer sogenannten Information-Extraction-Pipeline (IE-Pipeline) angeordnet, um eben jene
1
1. Einleitung
Abhängigkeiten zwischen den Algorithmen berücksichtigen zu können. Die Algorithmen erweitern dabei sukzessiv die verfügbare Menge an Informationen für
einen Text, um das Ziel einer IE-Pipeline zu erfüllen. Ein solches Ziel könnte etwa
die Extraktion von Marktvorhersagen aus Texten sein. Nach der Ausführung einer
solchen IE-Pipeline liegen dann die gesuchten Informationen vor.
Die Konstruktion einer IE-Pipeline ist aber keineswegs trivial. Dazu müssen
zuallererst die Abhängigkeiten zwischen den einzelnen Algorithmen identifiziert
und beachtet werden. So gilt es für jeden Algorithmus festzustellen, welche schon
vorliegenden Informationen er für seine erfolgreiche Ausführung benötigt und welche weiteren Informationen dann nach seiner Ausführung zusätzlich bereitstehen.
Die alleinige Betrachtung der Ein- und Ausgaben“ der Algorithmen reicht al”
lerdings nicht aus. Es kann vorkommen, dass verschiedene Algorithmen für die
gleiche Analyse implementiert worden sind. Sie liefern die gleichen Informationen,
unterscheiden sich aber hinsichtlich anderer Parameter, wie ihrer Effizienz und
Effektivität. Die präzise Abarbeitung eines Textes kann zum Beispiel sehr lange dauern. Oft reicht es aber aus, auf einen Teil der gesuchten Informationen zu
verzichten, wenn die anderen Informationen nur schnell genug gefunden werden.
Gerade bei großen Textmengen, wie sie zum Beispiel im World Wide Web vorliegen, ist die schnelle Suche nach Ergebnissen oft wünschenswerter als das Auffinden
von allen möglichen Ergebnissen. Dies gilt vor allem dann, wenn auf Basis der gewonnen Informationen zeitnahe Entscheidungen getroffen werden sollen, wie es
bei dem Eingangsbeispiel durch die Berücksichtigung von Marktvorhersagen für
das erfolgreiche Agieren auf dem Aktienmarkt der Fall wäre. Hier kann es zusätzlich notwendig sein, dass nur bestimmte Informationen verfolgt werden, etwa nur
Informationen über bestimmte Branchen. Eine nachträgliche Filterung der Ergebnisse wäre demnach notwendig. In anderen Fällen kommt es aber gerade auf die
Güte und Menge der Ergebnisse an. Dies gilt zum Beispiel bei der Extraktion von
bio-medizinischen Informationen aus Texten, die dann zur einfacheren Weiterverarbeitung in eine Datenbank geschrieben werden (vgl. [HFM+ 05]).
Das bedeutet, der Experte in der Domäne Information Extraction muss bei der
Konstruktion einer IE-Pipeline immer auch die zusätzlichen Randbedingungen
hinsichtlich der Effizienz und Effektivität der entstehenden IE-Pipeline berücksichtigen. Das Ziel ist demnach nicht nur, eine korrekte IE-Pipeline zu bauen,
die die gewünschten Ergebnisse liefert, sondern dabei auch die Anforderungen an
deren Qualität sicherzustellen.
Die große Anzahl an unterschiedlichen Algorithmen, mit verschiedenen benötigten und erzeugten Informationen sowie deren unterschiedliche Effizienz und Effektivität, macht die manuelle Planung und Entwicklung von IE-Pipelines zeitaufwendig und damit teuer. Hier kann ein automatisiertes Expertensystem helfen,
welches den Experten bei dieser Arbeit entlastet und für ihn die Konstruktion
von IE-Pipelines durchführt. Der Computer berücksichtigt dabei das vorhandene
Wissen über die zur Verfügung stehenden Algorithmen zum Bau der IE-Pipeline.
Außerdem bezieht er die vom Anwender gesetzten Randbedingungen mit ein, um
automatisch eine passende effiziente oder effektive IE-Pipeline aufzubauen. Auch
2
die Ausführung der IE-Pipeline auf einer zu analysierenden Menge an Texten
kann von dem Expertensystem durchgeführt werden. Anschließend werden dann
die erzielten Ergebnisse aggregiert und dem Anwender präsentiert.
Dieses Expertensystem ersetzt damit die manuelle Erstellung. Der Computer
kann die Aufgabe in weit weniger Zeit lösen. Dadurch werden die Kosten gesenkt.
Ein weiterer Vorteil ist, dass auch Nicht-IE-Experten das System ohne Expertenwissen verwenden können. Ein bestehendes Informationsbedürfnis wird in den
Computer zusammen mit einer Menge zu untersuchender Texte eingegeben. Das
Expertensystem trägt daraufhin automatisch alle in der Textmenge vorhandenen,
gewünschten Informationen zusammen und liefert sie anschließend an den Anwender zurück.
Zielsetzung
Diese Masterarbeit verfolgt das Ziel, ein Expertensystem für die automatische
Konstruktion und Ausführung von IE-Pipelines zu entwickeln. Dabei gilt es, die
verfolgten Ziele der zu erstellenden IE-Pipeline in Form der gesuchten Informationsart, zum Beispiel Marktvorhersagen, zu berücksichtigen. Neben der dadurch
sichergestellten korrekten Arbeitsweise der Pipeline ist aber auch deren Effizienz und Effektivität wichtig. Der Benutzer des Expertensystems soll daher eine
Präferenz von Effizienz oder Effektivität in Form von Randbedingungen angeben können, welche das Expertensystem dann bei der Erstellung der Pipeline
berücksichtigt. Das Wissen um verwendbare Algorithmen in einer IE-Pipeline,
deren Eigenschaften, sowie anderes wichtiges Wissen aus der Domäne Information Extraction sollen in eine formalisierte Form gebracht werden, damit es dem
Expertensystem als Wissensbasis zur Verfügung steht.
Die entstandene IE-Pipeline muss außerdem immer so effizient wie möglich
sein, unter Berücksichtigung der getroffenen Randbedingungen. Daher muss auch
verfügbares Wissen um die Effizienzsteigerung von IE-Pipelines in dem Expertensystem Anwendung finden.
Neben der eigentlichen Konstruktion der IE-Pipeline soll das Expertensystem
weiterhin diese berechnete Pipeline auf einer Textmenge ausführen und die so erzielten Ergebnisse dem Anwender zurückgeben können. Der Anwender darf hierbei
Einschränkungen der Ergebnismenge festlegen, womit er zum Beispiel bei zu findenden Marktvorhersagen nur jene zurückgeliefert haben möchte, die ein bestimmtes Unternehmen betreffen. Diese Masterarbeit soll daher untersuchen, inwiefern
solche Einschränkungen schon direkt innerhalb der IE-Pipeline berücksichtigt und
eventuell so zu ihrer Effizienzsteigerung genutzt werden können.
Ein weiteres Ziel betrifft den Entwurf und die Implementierung des Expertensystems selbst. Hierbei soll darauf geachtet werden, dass das entstehende System
leicht erweitert und angepasst werden kann. Es muss zum Beispiel möglich sein,
das IE-Framework, also die Grundlage für die Algorithmen einer IE-Pipeline und
deren Ausführung, auszutauschen, ohne dass dazu große Teile des Expertensys-
3
1. Einleitung
tem neu geschrieben werden müssen. Neue IE-Algorithmen, oder auch Kriterien
bezüglich der Effizienz oder Effektivität eines Algorithmus, sollen einfach hinzuzufügen sein. Daher muss das Expertensystem so konzipiert sein, dass dieses neue
Wissen auf eine einfache Art und Weise der Wissensbasis des Expertensystems
hinzugefügt werden kann, ohne umfangreiche Anpassungen am Quellcode vornehmen zu müssen.
Aufbau der Arbeit
Im folgenden Kapitel wird der Leser in die für diese Arbeit wichtigen Grundlagen eingeführt. Dies betrifft zuallererst den Bereich der Expertensysteme. Da die
in dieser Arbeit entwickelte Wissensbasis in Form einer Ontologie vorliegt, werden Ontologien ebenfalls erläutert. Die eigentliche Konstruktion der IE-Pipeline
wird mit der Hilfe eines Planungsverfahrens durchgeführt. Die dazu notwendigen Grundlagen sind ebenso in Kapitel 2 beschrieben. Außerdem wird auf das
Schlussfolgern in Ontologien eingegangen, um eine spätere Abgrenzung des verwendeten Ansatzes dazu durchführen zu können. Mit der Beschreibung der Domäne
Information Extraction, den IE-Pipelines, dem notwendigen Wissen zur Konstruktion effizienter IE-Pipelines und den gebräuchlichen Gütekriterien hinsichtlich deren Effektivität und Effizienz, schließt das Kapitel über die Grundlagen ab.
Im dritten Kapitel werden die verwandten Arbeiten und der Stand der Forschung beschrieben. Hierbei geht es um Arbeiten, die die Entwicklung von Expertensystemen und die Konstruktion effizienter IE-Pipelines zum Ziel haben.
Der konzeptuelle Lösungsansatz wird in Kapitel 4 vorgestellt. Der Fokus liegt
auf dem Konzept zur Konstruktion von effizienten IE-Pipelines und dem dafür
benötigten Wissen innerhalb der dazu entwickelten Wissensbasis des Expertensystems, sowie des Gesamtaufbaus des Expertensystems.
Bei der Realisierung des Lösungsansatzes in Kapitel 5 geht es vor allem um die
Besonderheiten des verwendeten Information-Extraction-Frameworks und der verwendeten Algorithmenmenge, aus der sich eine IE-Pipeline zusammen setzen kann.
Deren Berücksichtigung im Expertensystem, sowie deren größtmögliche Kapselung
vom Rest des Expertensystems stehen hier im Mittelpunkt.
In Kapitel 6 werden Details zur Implementierung des Expertensystems erläutert.
Hierbei liegt der Fokus vor allem auf dem Aufzeigen von einfachen Anpassungssowie Erweiterungsmöglichkeiten. Es werden weiterhin die entwickelten Komponenten des Expertensystems vorgestellt.
Die Evaluierung in Kapitel 7 zeigt, dass das entwickelte Expertensystem die vorher erarbeiteten Konzepte zur Berechnung einer IE-Pipeline und dem Ausführen
dieser auf einer gegebenen Textmenge korrekt umsetzt. Hierfür werden die einzelnen Teile des Expertensystems auf das korrekte Arbeiten hin überprüft.
Zuletzt werden die Erkenntnisse und Ergebnisse dieser Arbeit in Kapitel 8 zusammengefasst. Außerdem wird ein Ausblick über weiterführende Arbeiten gegeben, die sich auf Basis des entwickelten Expertensystems ergeben.
4
2 Grundlagen
In diesem Kapitel werden alle Grundlagen erläutert, die für das Erreichen der Ziele
dieser Arbeit notwendig sind.
Die Entwicklung eines Expertensystems zur automatischen Erstellung effizienter Information-Extraction-Pipelines (IE-Pipelines) ist das Ziel dieser Arbeit. Daher wird in Abschnitt 2.1 beschrieben, was Expertensysteme sind und was sie
ausmacht. Das Wissen um Konzepte und Rollen in der Domäne Information Extraction, vor allem jenes Wissen, welches bei der Konstruktion von IE-Pipelines
hilfreich sein kann, soll in einer formalen, dem Computer zugänglichen Form, vorhanden sein. Auf Basis dieses Wissens kann dann die Konstruktion eben jener
IE-Pipelines durch das Expertensystem erfolgen. Mit Formen der für das Expertensystem wichtigen formalen Wissensrepräsentationen, vor allem den vom zu
entwickelnden Expertensystem als Wissensbasis benutzten Ontologien, beschäftigt
sich daher der Abschnitt 2.2. Verfahren zum automatischen Schlussfolgern auf dem
Wissen des Expertensystems werden anschließend in Abschnitt 2.3 vorgestellt.
Diese machen eine automatische Berechnung der IE-Pipelines möglich. Für diese
Arbeit wichtige Verfahren, wie das Schlussfolgern in Ontologien und besonders
das später genutzte Planen, stehen hierbei im Mittelpunkt. Das Einsatzgebiet des
zu entwickelnden Expertensystems ist die Domäne Information Extraction. Aus
diesem Grund beschäftigt sich der letzte Abschnitt 2.4 dieses Kapitels mit der
Vorstellung dieser Domäne. Dazu gehören insbesondere die Vorstellung der vom
Expertensystem zu konstruierenden IE-Pipelines, sowie Verfahren für deren effiziente Konstruktion. Auch die Kriterien, wann ein Algorithmus aus der Domäne
IE effektiv oder effizient ist und damit zusammenhängend, wann eine IE-Pipeline
effektiv oder effizient ist, werden erklärt. Auf Basis diesen Wissens wählt das zu
entwickelnde Expertensystem später die Algorithmen für eine IE-Pipeline aus.
2.1 Expertensysteme
Expertensysteme werden immer dann eingesetzt, wenn zur Lösung eines gegebenen Problems das Wissen eines menschlichen Experten benötigt wird, sich dessen
Expertenwissen für den Computer formalisieren lässt und damit die Lösung durch
den Computer bestimmt werden kann. Sie gehören damit zu den wissensbasierten Systemen. Expertensysteme sollen für ganz bestimmte Anwendungsfälle den
menschlichen Experten ersetzen, aber ihn auch bei alltäglichen Routineaufgaben
entlasten. Die Gründe hierfür liegen in den hohen Kosten eines Experten, aber
auch in den langen Zeitspannen, die es braucht, eine Person in einen Experten
5
2. Grundlagen
zu verwandeln. Der Experte erlangt viel von seinem Wissen über die Zeit als Erfahrungswissen, daher kann es Jahre dauern bis eine Person in einem bestimmten
Fachgebiet zum Experten wird. Ein weiterer Grund ist auch, dass ein Experte
nicht gleichzeitig an mehreren Orten sein kann, auch wenn sein Wissen zeitgleich
an diesen Orten gebraucht wird. Dies zeigt auch, dass ein normaler Benutzer eines
Expertensystems selbst kein Experte in der seinem Problem, und vor allem den
Strategien und Verfahren zu dessen Lösung, zugrundeliegenden Domäne sein muss
[Pup91].
Ein Expertensystem könnte zum Beispiel im medizinischen Umfeld dazu dienen,
Krankheiten zu diagnostizieren. Hierzu würde das Expertenwissen eines Mediziners in das Expertensystem aufgenommen. Anschließend könnten Personen Anfragen an das Expertensystem stellen. So würde bei der Eingabe von Krankheitssymptomen in das Expertensystem dieses automatisch eine mögliche Krankheit,
welche am besten auf die beschriebenen Symptome passt, diagnostizieren und dazu
noch die erfolgversprechendsten Heilungsmethoden aufzeigen.
2.1.1 Aufgabenbereiche von Expertensystemen
Die einem Expertensystem zugrundeliegenden Problemlösungstypen, und damit
fundamentalen Aufgabenbereiche eines Expertensystems, lassen sich in mehrere Bereiche einteilen, wobei die Klassifikation (auch Analyse genannt), die Konstruktion (auch Synthese genannt) und die Simulation die drei wichtigsten Bereiche darstellen [Pup91]. Bei der Klassifikation wird aufgrund der vorhandenen
Eingaben eine Lösung selektiv aus einer bereits vorhandenen Menge von Lösungen bestimmt. Hierunter fallen zum Beispiel die Diagnose, etwa die Diagnose von
Krankheiten auf Basis ihrer Symptome im medizinischen Bereich, und die Steuerung, wie das Steuern eines Reglers ausgehend von gemessenen Sensordaten. Bei
der Simulation wird ausgehend von einem Ausgangszustand und der Eingabe der
Folgezustand bestimmt. Hiermit lassen sich die Auswirkungen von Aktionen in
einem bestimmten Zustand simulieren. Die Konstruktion arbeitet nicht auf Basis bereits bekannter Lösungen, sondern konstruiert neue Lösungen. Unter diesen
Punkt fallen zum Beispiel die Konfigurierung (das Zusammenfügen von Objekten
unter bestimmten Randbedingungen) und auch das Planen einer Folge von Aktionen zum Erreichen eines ausgewählten Ziels, etwa die Produktionsplanung in
einem Industriebetrieb [Pup91]. Außerdem fällt das dieser Arbeit zugrunde liegende Problem der Konstruktion von Information-Extraction-Pipelines in diesen
Bereich.
2.1.2 Architektur von Expertensystemen
Die im Folgenden vorgeschlagene allgemeine Architektur eines Expertensystems
sowie die Erklärung seiner einzelnen Bereiche beziehen sich auf die Ausführungen
in [Pup91]. In Expertensystemen wird zwischen dem vorhandenen Expertenwissen
6
2.1 Expertensysteme
Benutzer
Interviewerkomponente
Experte
Wissenserwerbskomponente
Erklärungskomponente
Fallspezifisches
Wissen
Problemlösungskomponente
Wissensbasis
Domänenspezifisches
Expertenwissen
Steuersystem
Zwischenergebnisse und Problemlösungen
Abbildung 2.1: Architektur eines Expertensystems [Pup91]
und den Problemlösungsstrategien getrennt. Dies spiegelt sich in der grundlegenden Architektur von Expertensystemen wider. Sie setzt sich primär aus den beiden
Bestandteilen Wissensbasis und Steuersystem zusammen. Diese Architektur wird
in Abbildung 2.1 dargestellt und bildet die Basis für die entwickelte Architektur
des in der vorliegenden Arbeit erstellten Expertensystems.
Auch von anderen Autoren wird diese Form der Architektur von Expertensystemen präferiert. So findet sich zum Beispiel in [Hau00] eine ganz ähnliche
Architektur. Die für [Hau00] wesentlichen Komponenten eines Expertensystems
sind hierbei:
• Eine Wissensbasis, welche das Expertenwissen beinhaltet.
• Eine Inferenzkomponente, welche Lösungen zu den an sie gestellten Anfragen
liefert.
• Eine Dialogkomponente, um dem Anwender und Experten eine einfach Kommunikationsmöglichkeit mit dem System zu geben.
• Eine Erklärungskomponente, über die sich die Herleitung der gewählten
Lösung nachvollziehen lässt.
• Eine Wissensaquisitionskomponente, mit der das Wissen des Expertensystems leicht vom Experten bearbeitet werden kann.
Die aufgeführten Komponenten lassen sich direkt in der älteren Architektur von
[Pup91] wiederfinden, deren Elemente in den folgenden Abschnitten näher erläutert
werden sollen.
7
2. Grundlagen
Wissensbasis
In der Wissensbasis wird das gesamte Wissen des Expertensystems gespeichert.
Das Wissen umfasst das Expertenwissen, aber auch das sogenannte fallspezifische
Wissen, welches vom Benutzer mit der Problembeschreibung in das System eingegeben wurde. Außerdem können hier sowohl Zwischenergebnisse als auch vorherige
Gesamtlösungen als neues Wissen gespeichert werden [Pup91]. Das Wissen kann
in vielen verschiedenen Formen, wie zum Beispiel Aussagen- und Prädikatenlogik
oder auch in Form von Wenn-Dann Regeln dargestellt werden. Auf die möglichen
Repräsentationsformen des Wissens wird im Verlauf dieses Kapitels noch genauer
eingegangen.
Steuersystem
Das Steuersystem des Expertensystems enthält die Benutzerschnittstellen für den
Dialog mit dem Benutzer, eine Erklärungskomponente, eine Wissenserwerbskomponente, sowie die Komponente für das Problemlösen.
Interviewerkomponente Mithilfe der Interviewerkomponente (bei [Hau00] auch
Dialogkomponente genannt) gibt der Benutzer sein Problem in das Expertensystem ein. Auf der Grundlage dieser Eingabe versucht das Expertensystem dann,
eine Lösung für das Problem zu erarbeiten. Bei dieser Arbeit kann das Expertensystem über die Interviewerkomponente unter Umständen Rückfragen an den
Benutzer stellen, etwa um mehr Informationen zu einem Teilproblem zu erhalten,
oder um den Benutzer direkt Teillösungen auswählen zu lassen, zwischen denen
das Expertensystem, etwa aufgrund fehlendem Wissens, keine eindeutige Wahl
treffen kann. So könnte das Expertensystem versuchen eine Krankheit zu diagnostizieren, aber für eine endgültige Diagnose sind die Symptome nicht eindeutig.
Hier würde ein Nachfragen des Expertensystems an den Benutzer, etwa nach weiteren Symptomen, die entscheidenden Informationen zur Bestimmung der Lösung
liefern. Das Expertensystem könnte auch gezielt fragen, ob etwa ein bestimmtes
Symptom vorliegt, welches einem der Lösungskandidaten zugeordnet ist. Es kann
auch Fälle geben, in denen das Expertensystem nicht von einem menschlichen Benutzer genutzt wird. Dies ist zum Beispiel der Fall, wenn das Expertensystem für
die Steuerung eines Roboters oder einer Raumsonde eingesetzt wird [MNPW98].
Hier werden automatisch die Sensordaten als Eingabe für das Expertensystem bestimmt und die Ausgabe wird dementsprechend automatisch vom Gesamtsystem
weiterverarbeitet.
Erklärungskomponente Diese Komponente erlaubt es dem Benutzer nachzuvollziehen, warum und in welcher Weise das Expertensystem zu einer Lösung
gekommen ist. Dies ist vor allem immer dann notwendig, wenn das Expertensystem Entscheidungen trifft, die sicherheitskritisch sind oder auch Menschenleben in
Gefahr bringen können. Ein Expertensystem, welches die Medikamentendosis für
8
2.2 Formale Wissensrepräsentation
Patienten bestimmt, sollte zumindest bei stark von der Norm abweichenden Dosen eine genaue Erklärung über seine Entscheidungsfindung geben können. Durch
diese Komponente können vom Experten auch Fehler in der Wissensbasis entdeckt
werden.
Wissenserwerbskomponente Über diese Komponente pflegt der Experte, oder
der Entwickler des Expertensystems, das Expertenwissen in das System ein. Neben
dem manuellen Wissenserwerb kann das Expertensystem allerdings auch automatisch mit geeigneten Lernverfahren Wissen erwerben. Dieses Wissen kann zum
Beispiel aus Falldatenbanken abgeleitet werden [Pup91]. Bei [Hau00] wird dieser
Teil des Expertensystems Wissensakquisitionskomponente genannt.
Problemlösungskomponente Diese Komponente löst das Problem des Benutzers. Dabei greift sie auf das vorhandene Expertenwissen aus der Wissensbasis
zurück. Dieses Schlussfolgern auf Basis des vorhandenen Wissens kann mithilfe vieler verschiedener Techniken durchgeführt werden, die stark abhängig von
der Repräsentation des Wissens sind. Auf einige dieser Inferenzverfahren wird im
späteren Teil dieses Kapitels noch näher eingegangen. Die Problemlösungskomponente wird bei [Hau00] in Problemlösungskomponente und Inferenzverfahren
aufgeteilt. Das Inferenzverfahren ist direkt abhängig von der gewählten Wissensrepräsentation, arbeitet direkt auf der Wissensbasis und ist damit eng an sie gebunden. Hiermit werden Anfragen und Probleme mittels des verfügbaren Wissens
versucht zu lösen. Das Inferenzverfahren ist dabei frei von jeglichen domänenspezifischen Anpassungen, ist also nicht an das jeweilige Problem, welches das Expertensystem versucht zu lösen, angepasst. Die Problemlösungskomponente beinhaltet für [Hau00] demgegenüber sehr wohl speziell an die Domäne angepasste
Problemlösungsstrategien. Die vorliegende Arbeit orientiert sich in diesem Punkt
damit eher an [Hau00], denn es wird im späteren Verlauf der Arbeit ein speziell an
die Domäne Information Extraction angepasster Planer als Problemlösungskomponente entwickelt.
Ein Expertensystem arbeitet auf Basis des in ihm vorhandenen Expertenwissens.
Dieses Wissen ist, wie bereits in Abschnitt 2.1.2 erwähnt, in der Wissensbasis des
Expertensystems gespeichert. Der Repräsentation des Wissens in der Wissensbasis kommt dabei eine entscheidende Bedeutung zu. An eine mögliche Wissensrepräsentation werden daher folgende Anforderungen gestellt [FGH90]:
Automatisierbare Verarbeitbarkeit: Das Wissen muss formal genug repräsentiert
werden, damit der Computer dieses Wissen verarbeiten kann.
Flexibilität: Die Repräsentation soll sowohl unabhängig von der dem jeweiligen
Problem zugrundeliegenden Domäne, als auch unabhängig von dem jeweili-
9
2. Grundlagen
gen Aufgabenbereich (Klassifikation, Konstruktion und Simulation) des Expertensystems, sein.
Modularität: Das Wissen muss einfach erweiterbar und daher modular aufgebaut
sein.
Verständlichkeit: Der Inhalt der Wissensbasis muss sowohl dem Experten als
auch dem Benutzer gegenüber verständlich sein.
Darstellung unsicheren Wissens: Es muss die Möglichkeit geben, unsicheres Wissen, etwa unvollständige Informationen, ausdrücken zu können.
Im Folgenden sollen einige Formen der formalen Wissensrepräsentationen aufgezeigt werden, die die oben genannten Anforderungen erfüllen. Der Bereich der
Ontologien nimmt dabei eine besondere Stellung ein, da die Ontologie als Form
der Wissensbasis für das in dieser Arbeit entwickelte Expertensystem gewählt
worden ist.
2.2.1 Formen der Wissensrepräsentation
Für die Repräsentation des Wissens eines Expertensystems gibt es viele Möglichkeiten. Die Spannbreite reicht hierbei von einfachen Logiken, wie der Aussagenlogik, über regelbasiertes Wissen, bis hin zu Wissen, das in objektorientierter Form
festgehalten ist. Die folgende Auflistung soll daher einen Überblick über die verschiedenen Arten der Wissensrepräsentation in Expertensystemen geben. Dieser
Überblick ist keineswegs vollständig und soll nur einen Einblick in die Möglichkeiten der Repräsentation geben. Aufgrund der Eigenschaften der aufgeführten
Wissensrepräsentationen wird dann in Kapitel 4 begründet, warum in der vorliegenden Arbeit Ontologien als Wissensbasis genutzt werden und keine der aufgeführten Wissensrepräsentationsformen. Weitere nicht im Folgenden beschriebene Formen sind zum Beispiel Constraints-Repräsentationen, probabilistisches,
nicht-monotones und temporales Schließen. Diese können beispielsweise in [Pup91]
nachgeschlagen werden.
Möglichkeiten aus der Logik Die einfachste Form der Wissensrepräsentation
stellt die Aussagenlogik dar. In ihr werden atomare Aussagen, denen ein Wahrheitswert (richtig oder falsch) zugeordnet wird, zusammen mit einer Reihe von
Junktoren (¬, ∧, ∨, →, ↔) zu aussagenlogischen Formeln verknüpft [BKI06]. Die
Prädikatenlogik erster Stufe erweitert die Aussagenlogik um Quantoren (∀, ∃) und
der Möglichkeit, Aussagen auf Objekte zu beziehen und diese in Relation zueinander zu setzten (während in der Aussagenlogik eine Aussage immer pauschal gilt
und nicht auf Objekte bezogen werden kann) [BKI06].
10
Regeln Eine weit verbreitete Form der Wissensrepräsentation in Expertensystemen sind Regeln [BKI06][Pup91]. Diese Regeln bestehen aus einfachen Wenn Dann Sätzen mit einer Vorbedingung (Wenn-Teil) und einer Implikation (DannTeil), welche gilt, wenn die Vorbedingung gilt. Die Implikation kann auch eine
Aktion sein, die ausgeführt werden soll, falls die Vorbedingung gilt. Die Wissensbasis eines Regeln-verwendenden Expertensystems besteht aus der Regelmenge
und einer Datenbasis, die alle verfügbaren Fakten enthält. Eine einfache Regel
wäre zum Beispiel:
R1: WENN AlgorithmusXLöstProblem = Wahr DANN Wähle AlgorithmusX
Gibt es mehrere Regeln, die auch noch die gleichen Fakten in Vorbedingung oder
Implikation betreffen, so müssen unter Umständen Konfliktlösungstrategien angewendet werden, um aus diesen Regeln eine einzige auszuwählen. So kann zum
Beispiel den Regeln eine Priorisierung zugeordnet und dann im Konfliktfall die
höher priorisierte ausgeführt werden.
Fuzzy–Logik Fuzzy-Logik kann für den Umgang mit unscharfem beziehungsweise unsicherem Wissen verwendet werden. Sie basiert auf den sogenannten FuzzySets (unscharfen Mengen), einer Verallgemeinerung der Mengenlehre. In diesen
Mengen kann ein Objekt zu einem Teil enthalten oder nicht enthalten sein, ausgedrückt durch einen Wert zwischen 0 und 1. Die Fuzzy-Logik eignet sich dementsprechend sehr gut für das Festhalten von Alltagswissen in unscharfer Form. Der
große Unterschied zu den vorher beschriebenen Regeln ist die Inferenz von mehreren Regeln in einem Fuzzy-Inferenz-System und die anschließende Defuzzifizierung
der berechneten Ergebnisse [KGK93].
Objektorientierte Repräsentationen Eine weitere Form der Wissensrepräsentation ist das Festhalten von Wissen in Form von sogenannten Frames. Mithilfe
dieser Frames lassen sich Begriffe formalisieren und Beziehungen zwischen Begriffen ausdrücken. Diese Repräsentationsform unterscheidet sich damit deutlich
von logikbasierten Formen, in denen nicht Begriffe im Zentrum stehen, sondern
Aussagen und Sätze über diese Aussagen. Ein Beispiel für das Objekt zum Begriff
Computer“:
”
Computer: Bestandteile: CPU, Speicher, Betriebssystem
Gehäusefarbe: unbekannt (Restriktion: grau, weiß, schwarz)
An dem Beispiel lässt sich erkennen, dass der dargestellte Frame eigentlich eine
Klasse beschreibt. Eine Instanz könnte demnach ein Computer sein, mit einer ganz
bestimmten Konfiguration von CPU, Speicher und Betriebssystem (die von anderen Frames näher beschrieben würden) und der Gehäusefarbe grau. Vererbung
mittels Sub-/Super -Beziehungen sind in Frames ebenfalls möglich [Pup91].
11
2. Grundlagen
2.2.2 Ontologien und Wissensbasen
Ontologien sind eine weitere Form der Wissensrepräsentation. Der Begriff Ontologie kommt aus der Philosophie und bezeichnet die Lehre vom Seienden. Dieser
Teilbereich der Philosophie beschäftigt sich mit Fragen, ob es zum Beispiel universelle Wahrheiten gibt [Hof10]. In der Informatik hat sich eine andere Bedeutung
des Begriffs Ontologie durchgesetzt. Die am weitesten verbreitetste Definition von
Ontologie stammt von Thomas R. Gruber:
An ontology is an explicit specification of a conceptualization. [...] In
such an ontology, definitions associate the names of entities in the
universe of discourse (e.g., classes, relations, functions, or other objects) with human-readable text describing what the names are meant
to denote, and formal axioms that constrain the interpretation and
well-formed use of these terms. [Gru93]
Die Begriffsbildung steht demnach im Mittelpunkt. Die Wirklichkeit wird so in
einem Modell abgebildet, dass dieses Modell sowohl von Menschen verstandenen
werden kann, aber auch formal genug für die Repräsentation im Computer ist.
Dabei werden die Entitäten des Modells untereinander verknüpft und das Aussehen und die Art dieser Verknüpfungen beschrieben. Ontologien sind daher eng
verwandt mit der objektorientierten Wissensrepräsentation aus Abschnitt 2.2.1.
Es existieren eine Reihe von Sprachen, die sich für das Errichten von Ontologien
eignen. Die im Abschnitt 2.2.1 besprochene objektorientierte Wissensrepräsentation mittels Frames zählt zum Beispiel dazu; ebenso, als Weiterentwicklung der
Frames, die F-Logic [KL89]. Eng verwandt mit Frames sind auch die Topic Maps 1 .
Mithilfe dieser Sprache lässt sich eine Karte mit Begriffen und Verknüpfungen
zwischen den einzelnen Begriffen aufbauen. Diese Karten werden dann Topic Map
genannt [Pep00].
Eine weitere Sprache zum Aufbau von Ontologien ist das RDF-Schema (RDFS). Diese Sprache erweitert das Resource Description Framework (RDF) [KC04].
In RDF lassen sich Beziehungen zwischen Objekten in Form von Tripeln (Subjekt Prädikat - Objekt) oder allgemeiner (Ressource - Eigenschaft - Wert) ausdrücken.
Ressource und Eigenschaft sind immer durch einen Unique Resource Identifier
(URI [BLFM05]) beschrieben, während das Objekt auch ein Literal sein kann.
Ein textuelles Beispiel für ein RDF-Tripel wäre:
(http://amiga500.com) - (http://terms.org/hasCPU) - (http://motorola68000.com)
Hierbei sind alle drei Teile des Tripels durch URIs beschrieben und es soll ausgedrückt werden, dass der Computer Amiga500 als Prozessor eine Motorola 68000
CPU hat. Durch das Annotieren des Wortes Amiga“ in einem Fließtext mit der
”
URI http://amiga500.com kann dann ausgedrückt werden, dass es sich hierbei um
den Amiga500-Computer handelt.
1
http://www.isotopicmaps.org/
12
Mit RDF ist es allerdings nicht möglich eine Klassenhierarchie (Taxonomie)
auszudrücken. Hier setzt das RDF-Schema an. Mit ihm lassen sich Klassen und
Vererbung ausdrücken und der Datentyp von Ressourcen einschränken. Mit RDFS ist daher der Aufbau einer Art von Ontologie möglich. Diese Ontologien reichen
allerdings immer noch nicht aus, um alle Regeln und Eigenschaften einer Wissensdomäne festzuhalten. Beispielsweise ist es mit RDF-S nicht möglich auszudrücken,
dass ein bestimmter Computer nur einen einzigen Prozessor besitzt. Oder aber,
dass Motorola 68000“ dasselbe bedeutet, und demnach auch die gleichen Eigen”
schaften hat, wie M68k“. Allerdings lassen sich mit RDF-S bereits einige einfache
”
Ontologien, zum Beispiel Taxonomien, festhalten [McB04].
Ontologiesprache OWL
Die Web Ontology Language (OWL)2 ist eine Standardsprache im Bereich der
Ontologien [Hor08]. Sie wird vorrangig mit dem Semantic Web in Verbindung
gebracht (siehe auch [BHL01] und [SBLH06]) und ist der Nachfolger der Ontologiesprache DAML+OIL [HPSH02]. Mithilfe von OWL lassen sich Kardinalitäten
bei Beziehungen, Mengenoperationen oder aber auch symmetrische und transitive
Beziehungen ausdrücken [AH03].
In OWL sind Klassen, Eigenschaften und Individuen definiert [Wor12]. Jedes
Element in OWL ist hierbei durch einen eindeutigen URI identifiziert. Ein Beispiel
ist eine Klasse Computer. Eine Unterklasse davon kann die Klasse Mobilgerät sein.
Klassen können sich aber auch aus weiteren Klassen mit Restriktionen zusammensetzen. Restriktionen lassen sich angeben, indem bestimmte Eigenschaften durch
Existenz- und Allquantoren sowie Kardinalitäten eingeschränkt werden. Eine Eigenschaft ist eine Beziehung zwischen zwei Klassen. Auch Eigenschaften können
Subeigenschaften von anderen sein. Eine mögliche Klasse mit Restriktionen wäre
die Klasse Mobilgerät als Subklasse von Computer und der Einschränkung, dass
alle Mobilgeräte von einem Menschen leicht tragbar sein müssen. Die Eigenschaft
wäre ist tragbar. Individuen sind konkrete Instanzen von Klassen. Beispielsweise
könnte es ein Individuum eines Mobilgeräts mit dem Bezeichner IPhone geben.
Für das Hinzufügen von neuem Wissen in eine OWL-Ontologie gibt es verschiedene Möglichkeiten. So lassen sich zum Beispiel neue Informationen in Form
von neuen RDF-Tripeln bereit stellen. Eine andere Möglichkeit ist, das Ontologieschema selbst zu erweitern. Darüber hinaus kann auch durch Schlussfolgerungen
auf OWL neues Wissen entdeckt werden. So können transitive oder symmetrische Eigenschaften ausgenutzt werden. Beispielsweise könnte eine ist Nachfolger
von Beziehung transitiv sein. Dann kann aus den beiden Tripeln (Windows7 ist Nachfolger von - WindowsVista) und (WindowsVista - ist Nachfolger von
- WindowsXP ) automatisch das neue Tripel (Windows7 - ist Nachfolger von WindowsXP ) geschlossen werden und somit wird neues Wissen an dieser Stelle
automatisch erzeugt. Mit einer symmetrischen Eigenschaft wie ist Partner von
2
Die Abkürzung ist gewollt, siehe auch http://de.wikipedia.org/wiki/Web_Ontology_
Language#Abk.C3.BCrzung
13
2. Grundlagen
Computer
hatProzessor
1..*
1..*
Prozessor
M68k
hatSpeicher
Speicher
Pentium
RAM
hatEAGerät
hatBetriebssystem
*
*
Betriebssystem
E/A Gerät
Festplatte
Tastatur
Bildschirm
Windows
MacOS
Abbildung 2.2: Beispielontologie der Domäne Computer
kann aus (Foxconn - ist Partner von - Apple) automatisch das Tripel (Apple ist Partner von - Foxconn) erzeugt werden. Eine weitere Form der Schaffung von
neuem Wissen liegt in der Verwendung von Regeln, zum Beispiel in Form von
SWRL [HPSB+ 04]. So kann mit der Regel hatEAGerät(Computer, Tastatur) ∧
hatEAGerät(Computer, Bildschirm) → istTerminal(Computer) ausgedrückt werden, dass ein Computer mit Tastatureingabemöglichkeit und einer Ausgabe auf
einem Bildschirm automatisch als Terminal gekennzeichnet wird.
In Abbildung 2.2 ist eine kleine Beispielontologie für die Domäne Computer
zu sehen. Die grafische Notation orientiert sich an an der grafischen Notation von
UML-Klassendiagrammen, wobei jede Klasse der Ontologie durch eine abgerundetes Rechteck dargestellt ist.3 Die gerichteten Kanten mit ausgefüllter Pfeilspitze,
wie hatProzessor, sind Eigenschaften zwischen den durch die Kante verbundenen
Klassen. Sie sind gerichtet, da jede Eigenschaft eine Domain, einen Grundbereich,
und eine Range, einen Wertebereich, hat. So gibt der Ausgangspunkt der Kante
den Grundbereich, ihr Endpunkt den Wertebereich und die Benennung den Namen
der Eigenschaft an. Die Nummern und Sterne an den Kantenenden geben mögliche Kardinalitäten der Eigenschaften an, wie sie von der UML her bekannt sind.
So hat jeder Computer mindestens einen Prozessor und beliebig viele (also auch
keine) Ein-/Ausgabe-Geräte. Die Ontologie selbst ist zu einem großen Teil eine
Taxonomie. Die vielen Subklassenbeziehungen werden, wie in der UML, durch die
Kanten mit nicht ausgefüllter Pfeilspitze ausgedrückt. Die Klassen Tastatur und
Bildschirm sind beispielsweise Subklassen von E/A Gerät. Die Namen der Elemente der Ontologie stellen ihren URI dar, wobei diese eindeutigen Bezeichner in
dem Beispiel stark vereinfacht dargestellt wurden. Dieses relativ kleine Beispiel
soll nur die Möglichkeiten bei der Bildung von Ontologien illustrieren.
Die Syntax von OWL kann in XML-Form dargestellt werden. Allerdings gibt es
auch Ontologieeditoren, die Ontologien in der in Abbildung 2.2 angegebenen Form
3
UML-Klassendiagramme haben allerdings eine andere Semantik als OWL-Ontologien. Dies ist
bei der Modellierung berücksichtigt worden. So gibt es etwa für die Aggregation aus UML kein
Äquivalent in OWL. Umgekehrt haben zum Beispiel die Eigenschaften in OWL eine andere
Semantik als etwa Assoziationen in UML. Für Abbildungen zwischen beiden Sprachen siehe
[GDDD04].
14
visualisieren. Der sehr verbreitete OWL-Ontologieeditor Protégé 4 bietet etwa eine
ähnliche grafische Visualisierung von Ontologien an.
Beschreibungslogiken und OWL
Die Ontologiesprache OWL fächert sich in drei Untersprachen auf, die sich in ihrer Ausdrucksstärke voneinander unterscheiden: OWL-Lite, OWL-DL und OWLFull. OWL-Full ist die ausdrucksstärkste der drei Sprachen. Sie umfasst sowohl
OWL-DL als auch OWL-Lite (beide sind Teilmengen von OWL-Full: OWL-Lite ⊆
OWL-DL ⊆ OWL-Full). Die Sprache unterstützt den kompletten OWL-Standard
und ist auch die einzige der drei Sprachen, die alle RDF-Schema Sprachelemente
unterstützt (OWL-Full = RDF-Schema ∪ OWL-DL). Die Beinhaltung aller Elemente von RDF-Schema macht OWL-Full zu einer unentscheidbaren Sprache. Aus
diesem Grund existieren weitere OWL-Varianten, die zwar nicht alle Sprachmittel
von OWL-Full unterstützen, dadurch aber entscheidbar bleiben [HKR08]. OWLLite steht gegenüber OWL-Full auf der anderen Seite der Ausdrucksstärke. Diese
Variante bietet nur eingeschränkte Möglichkeiten bei der Darstellung von Wissen.
So lassen sich zum Beispiel keine Kardinalitäten, Aufzählungen und Disjunktheiten ausdrücken. Dadurch ist diese Sprache für die Erstellung von eher einfachen
Taxonomien und Ontologien gedacht. OWL-DL ist die dritte OWL-Variante. Sie
wurde mit dem Ziel, so ausdrucksstark wie möglich, dabei allerdings immer noch
entscheidbar zu sein, entworfen. Daher ist der Sprachumfang vor allem bei den
Sprachelementen aus RDF-Schema eingeschränkt worden. OWL-DL erfährt allerdings in der Praxis am meisten Anwendung [HKR08]. Dies ist auch einer der
Gründe, warum für die Ontologie des von der vorliegenden Arbeit entwickelten Expertensystems OWL-DL als Basis gewählt wurde. Für eine genauere Auflistung,
welche Sprachelemente von welcher OWL Variante unterstützt werden, sei auf
[AH03] verwiesen.
Die Basis für OWL bilden die sogenannten Beschreibungslogiken (engl. Description Logic). Beschreibungslogiken sind Logik-basierte Sprachen zur Wissensrepräsentation und Wissensmodellierung. Sie bilden eine Untermenge der Prädikatenlogik erster Stufe. Daher ist es möglich auf Basis von Beschreibungslogiken Inferenzverfahren zum logischen Schließen auszuführen [BN03]. Das Vokabular von
Beschreibungslogiken besteht aus sogenannten Begriffen (entspricht den OWLKlassen), Rollen (entspricht den OWL-Eigenschaften) und Individuen (entspricht
den OWL-Individuen) [BN03].
Der Ausdruck Betriebssystem(Android) ist ein Begriff, welcher beschreibt, dass
das Individuum Android ein Betriebssystem ist. Hierbei wird der Begriff Android auch als atomare Klasse bezeichnet; sie ist nicht aus weiteren Klassen zusammengesetzt. Mit hatBetriebssystem(MobilePhoneXY, Android) wird die Rolle
(Beziehung) ausgedrückt, dass das Android-Betriebssystem auf dem Mobiltelefon MobilePhoneXY läuft. In Prädikatenlogik abgebildet entsprechen Individuen
4
http://protege.stanford.edu/
15
2. Grundlagen
Konstantensymbolen, Begriffe sind einstellige, Rollen zweistellige Prädikate. Mittels sogenannter Konstruktoren können komplexere Klassen und Rollen gebildet
werden. Ein möglicher Konstruktor ist die Disjunktion. Der folgende Ausdruck
beschreibt, dass alle Betriebssysteme entweder Windows-, Android- oder MacBetriebssysteme sind:
Betriebssystem v W indows t Android t M acOS
Das Zeichen v gibt dabei, wie von der Mengenlehre gewohnt, eine Art Teilmengenbeziehung an. Die Klasse Betriebssystem setzt sich demnach aus Windows, Android und MacOS zusammen. Unterklassen und Äquivalenzen sind daher ebenfalls
möglich. Somit kann man beispielsweise ausdrücken, dass die Klasse Mobiltelefon
eine Unterklasse (eine Teilmenge) von Computer ist:
M obiltelef on v Computer
Abgebildet in Prädikatenlogik ergibt sich:
(∀x)(M obiltelef on(x) → Computer(x))
Auch Quantoren können benutzt werden:
P C v ∀hatBetriebssystem.W indows
wobei Windows ein Begriff und hatBetriebssystem eine Rolle ist. In Prädikatenlogik ausgedrückt:
(∀x)(P C(x) → (∀y)(hatBetriebssystem(x, y) → W indows(y)))
Eine Beschreibungslogik besitzt eine Wissensbasis KB (Knowledge Base), die
sich in die beiden Bereiche TBox und ABox aufteilt [BN03]. Die TBox enthält
das Modell der Wissensdomäne (terminologische Beschreibung, engl. terminology). Die ABox beinhaltet konkrete Daten (Behauptungen, engl. assertions). In
Prädikatenlogik ausgedrückt würden die Formeln in diejenigen aufteilt, die Variablen haben (TBox) und solche, in denen keine Variablen vorkommen (ABox).
Die kleinste, aussagenlogisch abgeschlossene Beschreibungslogik ist ALC [BHS07].
ALC steht für Attributive Language with Complex concept negation. Begriffe können
aus Konstruktoren dieser Sprache zusammengesetzt sein. Hierfür stehen die Konjunktion, Disjunktion und Negation geschrieben als u, t, ¬ bereit. Einschränkungen von Rollen sind mithilfe des Allquantors (∀) und des Existenzquantors (∃)
möglich. Die Klasse, die keine Individuen beinhaltet (leere Klasse), wird mit ⊥,
die Klasse, die alle Individuen enthält mit > bezeichnet.
OWL-Lite entspricht der Beschreibungslogik SHIF(D), OWL-DL entspricht
SHOIN (D). Jeder Buchstabe beschreibt ein bestimmtes Sprachelement, welches
in der jeweiligen Sprache erlaubt ist [BHS07]. So steht das S für die Beinhal-
16
2.3 Schlussfolgerungsverfahren in Expertensystemen
tung von ALC und Transitivität. Das I steht für inverse Rollen. Mit (D) wird
ausgedrückt, dass primitive Datentypen, wie Fließkommazahlen, in der Beschreibungslogik verwendet werden dürfen. Es existiert keine Beschreibungslogik für
OWL-Full. Die komplette Beinhaltung von RDF-Schema lässt die Übersetzung
der Sprache in eine prädikatenlogische Form zudem schwierig werden [HKR08].
Die genaue Abbildung von OWL-Sprachelementen auf Beschreibungslogik kann
in den im Anhang enthaltenen Tabellen A.1 und A.2 nachgeschlagen werden.
Das Schlussfolgern (engl. Reasoning) in einem Expertensystem geschieht in der
Problemlösungskomponente anhand der aktuellen Wissensbasis. Die Repräsentation des Wissens hat dabei maßgeblichen Einfluss auf die Art des zu verwendenden
Schlussfolgerungsmechanismus. So kann auf prädikatenlogischem Wissen das Resolutionskalkül zum Beweisen von Aussagen genutzt werden [Pup91]. Regelwissen
lässt sich mittels Vorwärts- und Rückwärtsverkettung überprüfen [BKI06]. Sprachen, die sich für die objektorientierte Repräsentation eignen sind zum Beispiel
die KL-ONE Sprachen [BS85].
Zwei weitere Schlussfolgerungsformen sind das Schlussfolgern in OWL-Ontologien und das Finden eines Plans (Planen, engl. Planning), um von einer Ausgangssituation zu einem festgelegten Ziel zu gelangen. Das Planen wird von der
vorliegenden Arbeit für die Konstruktion einer IE-Pipeline genutzt. Daher findet es
im Folgenden eine besondere Erwähnung. Allerdings wird in Kapitel 4 auch dargelegt, warum sich gegen das direkte Reasoning auf der verwendeten OWL-Ontologie
entschieden wurde. Aus diesem Grund werden auch Aspekte der Schlussfolgerung
auf OWL-Ontologien im nächsten Unterabschnitt aufgeführt.
2.3.1 Schlussfolgern in OWL-Ontologien
Das Festhalten von Wissen in einer Wissensbasis in Form von Beschreibungslogik, wie es bei OWL-DL und OWL-Lite der Fall ist, eröffnet die Möglichkeit des
automatisierten Schlussfolgerns auf diesem Wissen. Der Computer kann daher
in OWL-verfassten Ontologien explizite Anfragen auf Basis des in der Ontologie
festgehaltenen Wissens beantworten.
OWL basiert auf der sogenannten Open World Assumption [Hor08]. Die Existenz von Wissen ist möglich, solange es nicht explizit ausgeschlossen werden kann.
Kann es weder ausgeschlossen noch bewiesen werden, so wird das Wissen als unbekannt bezeichnet. Das ist der Unterschied zur Closed World Assumption, bei der
alles Wissen, was nicht explizit dargestellt ist, als falsch bezeichnet wird. Die Wissensbasis muss hier demnach schon alles Wissen enthalten, wovon beim Schlussfolgern auch ausgegangen wird. Im Bereich der Datenbanken, aber auch in einigen
wissensbasierten Sprachen wie Prolog, lässt sich oft die Closed World Assumption
antreffen [Bri08].
17
2. Grundlagen
In OWL gilt überdies gegenüber der Datenbankwelt nicht die Unique Name
Assumption [Hor08]. Zwei Individuen mit unterschiedlichen Bezeichnern müssen
daher nicht zwangsläufig unterschiedliche Individuen sein. Zusammen mit der
Open World Assumption wird so in OWL zum Beispiel aus den Rollen hatProzessor(Amiga500, Motorola68000) und hatProzessor(Amiga500, M68k), zusammen
mit der Aussage, dass jeder Amiga höchstens einen Prozessor hat und Amiga500
ein Amiga ist, nicht etwa auf Inkonsistenz der Wissensbasis geschlossen, sondern
darauf, dass Motorola68000 und M68k zwei Bezeichner für dasselbe Individuum
sind. Inkonsistenzen ergeben sich nur, wenn sich die Aussage finden ließe, dass
Motorola68000 und M68k zwei unterschiedliche Individuen sein müssen [Hor08].
Dadurch wird deutlich, dass Anfragen auf OWL sehr viel schwieriger sind, als solche in normalen Datenbanken. In einer Datenbank erfüllen bereits alle Instanzen
das Datenbankschema und sind somit ihm gegenüber korrekt. In OWL muss unter
Umständen die komplette Ontologie in die Abfrage mit einbezogen werden. Das
lässt aber sehr viel mächtigere Abfragen möglich werden. Nicht nur das Abfragen
von Individuen (Ist Amiga500 ein Computer? ), sondern auch die Beantwortung
von Fragen über konzeptionelles Wissen (Sind alle Computer mit einem Prozessor
Amigas? ) wird hiermit durchführbar [Hor08].
Wichtige Anfragen, die an eine OWL Ontologie gestellt werden können, werden
als sogenannte Inferenzprobleme bezeichnet. Für die vorliegende Arbeit wichtige
Inferenzprobleme sind das der Instanzüberprüfung und das der Klasseninstanzen.
Bei der Instanzüberprüfung geht es darum zu beweisen, ob ein Individuum a zu
einer Klasse C gehört, also ob sich die Aussage C(a) logisch aus der Wissensbasis
folgern lässt. Bei der Bestimmung der Klasseninstanzen soll für alle Individuen der
ABox einer Wissensbasis eine Instanzüberprüfung in Bezug auf eine bestimmte
Klasse C durchgeführt werden. Somit werden alle Individuen bestimmt, die der
Klasse C zugerechnet werden können [HKR08].
Neben den aufgeführten Inferenzproblemen gibt es noch weitere, welche aber
für die vorliegende Arbeit eher unwichtig sind. Bei der Klassenäquivalenz soll
überprüft werden, ob zwei Klassen C und D identisch sind, also ob C ≡ D eine
logische Konsequenz aus der Wissensbasis ist. Das Problem der Unterklassenbeziehung (Subsumption) beschäftigt sich mit der Frage, ob sich die Beziehung C v D
logisch schlussfolgern lässt. Die Klassendisjunktheit liegt für zwei Klassen genau
dann vor, wenn C u D ≡ ⊥ eine logische Konsequenz aus der Wissensbasis darstellt. Die Klassenkonsistenz für eine Klasse C ist dann gegeben, wenn die Klasse
C leer ist, also C ≡ ⊥ logisch aus der Wissensbasis geschlossen werden kann. Alle
diese Probleme lassen sich auf den Nachweis der Widerspruchsfreiheit der Wissensbasis zurückführen [HKR08]. Eine Unterklassenbeziehung C v D gilt zum Beispiel genau dann, wenn die zugrunde liegende Wissensbasis KB ∪ (C u ¬D)(a)
unerfüllbar ist, wobei a ein Individuum ist, das noch nicht in der Wissensbasis
vorkommt. Beschreibungslogiken sind eine Teilmenge der Prädikatenlogik, daher
könnte durch eine Abbildung in Prädikatenlogik ein entsprechendes Inferenzverfahren, etwa ein Resolutionsverfahren, für die Beantwortung einer gestellten Anfrage verwendet werden. Die Prädikatenlogik ist allerdings nicht immer entscheidbar
18
[BN03]. Daher gibt es spezielle Verfahren, die direkt auf den Beschreibungslogiken
arbeiten.
Ein solches Verfahren ist beispielsweise das Tableauverfahren. Mit ihm kann die
Unerfüllbarkeit der Wissensbasis einer Beschreibungslogik überprüft und damit
eine Anfrage beantwortet werden [BS00]. Hierbei wird versucht, einen Widerspruch
in der Wissensbasis zu finden. Dazu werden in der Wissensbasis solange logische
Konsequenzen der Form C(a) und ¬C(a) erzeugt, bis man auf einen Widerspruch
stößt. Genauere Informationen über die Funktionsweise von Tableaualgorithmen
finden sich in [BS00] oder auch [DGHP99]. Es gibt noch andere Verfahren für die
Schlussfolgerung auf OWL. Hier sei exemplarisch auf den Ansatz von Kaon2 in
[Mot06] verwiesen.5
Die Worst-Case-Komplexität des Tableauverfahrens für die Beschreibungslogik
ALC hinsichtlich der Inferenz, Erfüllbarkeit oder Widersprüchlichkeit einer Formel oder Wissensbasis liegt in ExpT ime. Auch die Worst-Case-Komplexität von
SHIF(D) (und damit OWL-Lite) liegt in ExpT ime, die von SHOIN (D) und
damit auch von OWL-DL sogar in N ExpT ime [Tob01].6 Die Komplexitätsklasse
ExpT ime bedeutet, dass eine deterministische Turing-Maschine das Problem in
exponentieller Zeit lösen kann. Die Probleme der Klasse N ExpT ime können von
einer nichtdeterministischen Turing-Maschine in exponentieller Zeit gelöst werden. Für eine eingehendere Betrachtung der Komplexitätsklassen sei auf [Tob01]
oder auch [Pap94] verwiesen. Im schlimmsten Fall können die Schlussfolgerungen
auf OWL-Ontologien also sehr lange dauern oder auch nicht mehr in einer akzeptablen Zeit durchgeführt werden. Standard-Schlussfolgerungswerkzeuge, die auf
einem Tableauverfahren basieren, sind Pellet [SPG+ 07] oder FaCT++ [TH06].
2.3.2 Planungsverfahren
Beim Planen wird versucht eine Folge von Aktionen zu bestimmen, um ausgehend
von einem Anfangszustand ein bestimmtes Ziel zu erreichen. Dies wird auch als
Planungsproblem bezeichnet [RN04]. In [NGT04] wird das klassische Planungsproblem P folgendermaßen beschrieben:
P = (Σ, s0 , g)
Σ = (S, A, γ)
Das Symbol Σ bezeichnet hier ein Zustandübergangssystem, wobei S die Zustände
und A die Aktionen beschreibt. Die Funktion γ gibt an, ob in einem Zustand s eine
Aktion a ausgeführt werden kann. Der Anfangszustand für ein Planungsproblem
wird mit s0 angegeben. Durch g werden die Ziele ausgedrückt, die ausgehend
von diesem Zustand unter Berücksichtigung des Zustandübergangssystems erreicht
5
6
http://kaon2.semanticweb.org/
Für einen interaktiven Überblick über die Komplexitätsklassen der einzelnen Beschreibungslogiken (samt Quellenangaben) sei folgender Link empfohlen: http://www.cs.man.ac.uk/
~ezolin/dl/
19
2. Grundlagen
A
B
Abbildung 2.3: Blocksworld im Zustand Zustand0
werden sollen. Bei der Formulierung eines Planungsproblems sind also folgende
Einzelheiten zu beachten:
• Die Repräsentation der Zustände S
• Die Repräsentation der Ziele g
• Die Repräsentation der Aktionen A
Ein Zustand der modellierten Welt wird beschrieben durch die Menge seiner Eigenschaften. Jede Eigenschaft ist eine Aussage in und über der modellierten beziehungsweise die modellierte Welt. Diese Zustände werden als Konjunktion positiver
Literale, die für eben diese Eigenschaften stehen, aufgefasst [RN04].
So kann in einer Welt, die einen Blöcke verschiebenden Greifer modelliert - das
Standardbeispiel Blocksworld -, ein Zustand folgendermaßen aussehen:
Zustand0 = { LiegtAuf (BlockA, BlockB), LiegtAuf T isch(BlockB),
IstF rei(BlockA), Greif erIstLeer() }
Hier wurde mithilfe von Prädikatenlogik ein möglicher Zustand beschrieben.7
Mögliche Prädikate, mit denen die modellierte Welt beschrieben werden kann,
sind in dem Beispiel LiegtAuf(x,y), LiegtAufTisch(x), IstFrei(x) und GreiferIstLeer(). Die angegebenen Konstanten sind die modellierten Objekte der Welt, also
BlockA und BlockB. In Abbildung 2.3 wurde der Anfangszustand Zustand0 in
einer Blocksworld visualisiert.
Ein Ziel in der Blocksworld könnte nun sein, dass nicht BlockA auf BlockB
liegt, sondern umgekehrt BlockB auf BlockA. Ziele können als partiell spezifizierte Zustände bezeichnet werden, welche ebenso wie vollständige Zustände durch
die Konjunktion positiver Literale beschrieben werden [RN04]. Das eben angesprochene Ziel kann daher folgendermaßen beschrieben werden:
ZustandZiel = { LiegtAuf (BlockB, BlockA), LiegtAuf T isch(BlockA) }
Zum Erreichen des Ziels muss der Greifer einige Aktionen durchführen. Er soll
den BlockA hoch heben und auf dem Tisch absetzen. Dann soll er den BlockB
nehmen und ihn auf BlockA ablegen. Damit wäre das Ziel erreicht.
7
Anzumerken ist hier, dass von der Closed World Assumption ausgegangen wird. So beinhaltet
der Zustand implizit: ¬IstFrei(BlockB), ¬LiegtAufTisch(BlockA), usw.
20
Neben den Zuständen und Zielen der modellierten Welt müssen also auch die
in ihr möglichen Aktionen modelliert werden. Jede Aktion ist dabei eine konkrete
Instanz eines abstrakten Operators. Jeder Operator hat eine Reihe von Vorbedingungen, die in einem Zustand erfüllt sein müssen um ihn auszuführen, und eine
Reihe von Effekten, die nach seiner Ausführung im Folgezustand gelten [RN04].
Beispieloperatoren für die Blocksworld sind:
AufnehmenVomTisch(x)
Vorbedingungen: Greif erIstLeer(), LiegtAuf T isch(x), IstF rei(x)
Effekte: ¬Greif erIstLeer(), ¬LiegtAuf T isch(x), ¬IstF rei(x),
Greif erHält(x)
Aufnehmen(x,y)
Vorbedingungen: Greif erIstLeer(), LiegtAuf (x, y), IstF rei(x)
Effekte: ¬Greif erIstLeer(), ¬LiegtAuf (x, y), ¬IstF rei(x),
IstF rei(y), Greif erHält(x)
AblegenAufTisch(x)
Vorbedingungen: Greif erHält(x)
Effekte: LiegtAuf T isch(x), Greif erIstLeer(), IstF rei(x),
¬Greif erHält(x)
Ablegen(x,y)
Vorbedingungen: Greif erHält(x), IstF rei(y)
Effekte: LiegtAuf (x, y), Greif erIstLeer(), IstF rei(x),
¬IstF rei(y), ¬Greif erHält(x)
Durch Substitution der Variablen der Operatoren mithilfe der in der modellierten
Welt vorhandenen Objekten werden konkrete Aktionen angegeben. Die Ausführung
einer Aktion in einem Zustand führt zu einem Folgezustand, in welchem die durch
die Aktion beschriebenen Effekte gelten.8 Wendet man zum Beispiel die Aktion
Aufnehmen(BlockA, BlockB) auf den Anfangszustand Zustand0 an, so erhält man
folgenden Zustand:
Zustand1 = { Greif erHält(BlockA), LiegtAuf T isch(BlockB),
IstF rei(BlockB) }
Ein Plan wird nun beschrieben durch eine Reihe von nacheinander ausgeführten
Aktionen, die von einem Anfangszustand zu einem Zielzustand führen [RN04].
Ein Plan zum Erreichen des Zustandes ZustandZiel ausgehend von Zustand0 ,
welcher bereits sprachlich beschrieben wurde, lässt sich jetzt durch eine Reihe von
Aktionen angeben:
1. Aufnehmen(BlockA, BlockB)
8
Es wird implizit davon ausgegangen, dass alle von der Aktion nicht betroffenen, in dem Ausgangszustand geltenden Eigenschaften in seinem Nachfolgezustand weiterhin gelten. Dies
vermeidet das sogenannte Frame-Problem (das Aufzählen von allen durch die Aktion unveränderten Eigenschaften, siehe auch [MH69])
21
2. Grundlagen
2. AblegenAufTisch(BlockA)
3. AufnehmenVomTisch(BlockB)
4. Ablegen(BlockB, BlockA)
Diese Art der Modellierung ist nur eine von vielen Möglichkeiten. Zum Beispiel könnte der Tisch selbst ein Objekt sein und damit könnten die speziellen
Prädikate und Operatoren, die sich auf den Tisch beziehen, wegfallen. Darüber
hinaus kann man die Abstraktion beliebig erhöhen oder die Modellierung verfeinern. Das Aufnehmen und Ablegen von Blöcken könnte als eine einzige Aktion
Bewege(Wen, LiegtAufWem, Wohin) modelliert werden. Oder man modelliert die
Auf- und Abbewegungen des Greifers, sowie das Zupacken und Loslassen von ihm.
Die Granularität der Modellierung ist dem konkreten Anwendungsfall anzupassen.
Weiterhin ist die Sprache der Modellierung von Bedeutung. In den vorangegangenen Beispielen wurde Prädikatenlogik für das Beschreiben von Eigenschaften in
der modellierten Welt benutzt. Diese Eigenschaften könnten aber auch in Aussagenlogik oder den in Abschnitt 2.2 erwähnten Beschreibungslogiken festgehalten sein. Eine eigene Sprache für Planungsprobleme, die einen Standard in der
Planungsdomäne darstellt, ist die STRIPS (Stanford Research Institute Problem
Solver) Planning Language (im Folgenden nur STRIPS genannt) [FN71].
STRIPS basiert auf der Prädikatenlogik erster Stufe. Alle der in den eingangs
erwähnten Beispielen getroffenen Annahmen gelten auch in STRIPS (Closed World
Assumption, Vermeidung des Frame-Problems). Zudem gilt in STRIPS, dass jede
Konstante für ein anderes Objekt steht (Unique Name Assumption) und das keine
neuen Objekte in der modellierten Welt erzeugt werden können (Domain Closure Assumption). Jeder Zustand in STRIPS wird beschrieben durch eine endliche
Menge von atomaren variablenfreien und nicht negierten Prädikaten. Die Menge
der Prädikate eines Zustandes wird als Konjunktion aufgefasst, das bedeutet in einem konkreten Zustand müssen alle seiner Eigenschaften (Prädikate) erfüllt, also
wahr, sein. Die weiter oben angesprochenen Operatoren und Aktionen entsprechen
genau den Operatoren und Aktionen in STRIPS [FN71].
PDDL (Planning Domain Definition Language [MGH+ 98]) ist eine weitere Standardsprache zur Formulierung von Planungsproblemen. Diese Sprache wird zum
Beispiel für die International Planning Competition 9 von der International Conference on Automated Planning and Scheduling 10 (ICAPS) eingesetzt.
PDDL trennt das Planungsproblem auf in eine Beschreibung der Domäne und
einer Beschreibung des an diese Domäne gerichteten Problems. In der Beschreibung der Domäne werde alle Prädikate und Operatoren der modellierten Welt
aufgelistet. Prädikate entsprechen zum Beispiel den in Abschnitt 2.3.2 erwähnten
LiegtAuf(x,y) aus der Blocksworld. In der Problembeschreibung werden dann die
Objekte, der Anfangszustand und das gewünschte Ziel beschrieben.
9
10
http://ipc.icaps-conference.org/
http://icaps-conference.org/index.php/Main/HomePage
22
PDDL stellt eine Erweiterung von STRIPS dar. In PDDL sind Funktionen definierbar, die dann in den Aktionen als Vorbedingungen oder Effekte genutzt werden
können. Damit einher geht die mögliche Benutzung von numerischen Werten und
nicht nur von Wahrheitswerten. Darüber hinaus ist es möglich, Effekte an Bedingungen zu knüpfen (when(geld > 0) → IstZinskonto(y)). Außerdem dürfen
in PDDL Metriken angegeben werden, um die Qualität eines Plans zu optimieren. Beispielsweise kann jeder Aktion ein Kostenwert zugewiesen werden und als
Planqualitätsmetrik die minimalen Gesamtkosten gesetzt werden. Es wird also
eine Zielfunktion angegeben, auf die dann der Plan hin optimiert wird. Zur weiteren Vertiefung der Eigenschaften von unterschiedlichen PDDL-Versionen sei auf
[MGH+ 98] und [FL03] verwiesen.
Im Folgenden werden nun Algorithmen vorgestellt, die zu einem Planungsproblem eine Lösung (einen Plan) berechnen können. Hierbei steht vor allem der
Partial Order Planner im Fokus, da auf seiner Basis in dieser Arbeit das Problem
der Konstruktion einer IE-Pipeline gelöst wird. Die Beschreibungen der anderen
Planungsverfahren werden für die Begründung der Wahl eines Partial Order Planner in Kapitel 4 benötigt.
Planen als Suche im Zustandsraum
Das Finden einer Lösung für ein Planungsproblem kann als Suche in einem Graph
aufgefasst werden. In diesem Graph existieren Knoten und gerichtete Kanten. Die
Knoten entsprechen den Zuständen, dass heißt ein Knoten steht für einen Zustand in dem bestimmte Eigenschaften gelten. Eine gerichtete Kante von Knoten
a nach Knoten b entspricht einer in dem zu Knoten a entsprechenden Zustand
ausführbaren Aktion, welche nach ihrer Ausführung zu dem Nachfolgezustand des
zu Knoten b gehörenden Zustandes führen würde. Wäre zum Beispiel der im vorherigen Abschnitt beschriebene Zustand0 der entsprechende Zustand von Knoten
a, so gäbe es eine gerichtete Kante mit der Aktion Aufnehmen(BlockA, BlockB)
zu einem Knoten b, der dem Zustand Zustand1 entspricht. Wie im vorherigen
Abschnitt beschrieben ist ein Zielzustand ein Zustand, der alle Eigenschaften des
gewünschten Ziels enthält. Bei der Suche im Zustandsraum gilt es also von einem
Startknoten, der den Anfangszustand beschreibt, zu einem Zielknoten zu kommen,
der einen Zielzustand beschreibt. Der Weg vom Startknoten zu einem Zielknoten,
also die Abfolge der gerichteten Kanten auf diesem Weg, ist der gewünschte Plan.
Der gerichtete Weg beschreibt hierbei die Reihenfolge der Aktionen, die durch die
gerichteten Kanten bestimmt wird [RN04].
In Abbildung 2.4 ist die in Abschnitt 2.3.2 eingeführte sehr einfach gehaltene
Blocksworld als Zustandsraumgraph zu sehen. Sehr leicht zu erkennen ist der Weg
vom Startzustand Zustand0 zum Zielzustand ZustandZiel . Für das Finden eines
solchen Weges gibt es verschiedene Algorithmen, von denen zwei im Folgenden
erklärt werden sollen.
23
2. Grundlagen
Ablegen(BlockA,BlockB)
A
B
Aufnehmen(BlockA,BlockB)
B
A
Zustand0
ZustandZiel
B
A
Aufnehmen
(BlockB,BlockA)
Aufnehmen
VomTisch
(BlockA)
AblegenAuf
Tisch(BlockA)
Ablegen(BlockB,
BlockA)
AblegenAufTisch(BlockB)
B
B A
A
AufnehmenVomTisch(BlockB)
Abbildung 2.4: Zustandsraumgraph für das Blocksworld Beispiel
Vorwärtssuche Unter der Vorwärtssuche im Zustandsraumgraph versteht man
das Finden des Weges ausgehend vom Startknoten vorwärts Richtung Zielknoten.
Den Pseudocode für die Vorwärtssuche zeigt Algorithmus 1. Zeile 7 ist hierbei entscheidend. Der Suchraumgraph kann unter Umständen sehr groß sein. Daher gilt es
in jedem Schritt eine möglichst gute“ Aktion auszuwählen, die einen möglichst
”
nahe an das Ziel heranbringt. Dadurch verringern sich die benötigten Schritte,
um vom Startzustand zu einem Zielzustand zu kommen, und daher steigt die
Ausführungsgeschwindigkeit des Algorithmus. Aber vor allem wird ein kürzerer
Plan erzeugt, was in den meisten Fällen ein besserer Plan bedeutet.
Neben der einfachen Breiten- und Tiefensuche im Suchraumgraph gibt es daher
noch speziellere Formen von Algorithmen, die versuchen, einen möglichst kurzen
Weg zum Ziel zu finden. Als Beispiel sei die Best-First-Search genannt, hier ist
vor allem A∗ bekannt. Diese Algorithmen benutzen in jedem Schritt Heuristiken,
um die nächste Aktion zu bestimmen. Ein weiteres Beispiel ist die Greedy-Search,
welche die zum Zeitpunkt der Auswahl als beste erscheinende Aktion wählen. Zur
weiteren Vertiefung sei auf [Nil98] oder [RN04] verwiesen.
Rückwärtssuche Bei der Rückwärtssuche im Zustandsraumgraph wird von einem Zielzustand ausgehend rückwärts Richtung Startzustand gesucht. Hierbei
werden die Zustände selbst nicht betrachtet, sondern nur die einzelnen zu erreichenden Ziele. Man nimmt die einzelnen Ziele, zum Beispiel LiegtAuf(BlockA,
BlockB), und sucht nach einer Aktion, die dieses Teilziel erfüllt; das bedeutet, die
Aktion enthält das Teilziel in ihrer Liste von Effekten. Die Vorbedingungen dieser Aktion werden dann der Menge an zu erreichenden Zielen hinzugefügt. Dies
wird solange wiederholt, bis alle aktuell vorhandenen Teilziele im Startzustand
24
Algorithmus 1 Pseudocode Vorwärtssuche (vgl. [NGT04])
Eingabe: Aktionen AS, Startzustand ST ART , Ziele Z
Ausgabe: Gefundener Plan P LAN
1: P LAN ← ∅
2: S ← ST ART
3: while S enthält nicht alle Ziele Z do
4:
if Keine Aktion aus AS in S anwendbar then
5:
return Fehlschlag // Suche wird abgebrochen
6:
else
7:
Wähle anwendbare Aktion A aus
8:
P LAN ← P LAN ∪ A // Aktion A ans Ende des Plans stellen
9:
S ← Folgezustand nach Ausführung von A
10:
end if
11: end while
12: return P LAN
enthalten sind. Bei der Rückwärtssuche werden nur partielle Zustände betrachtet. Wichtig ist nur der Teil eines Zustands, aus dem sich unter Anwendung der
ausgewählten Aktion genau die momentanen Zielformeln im Folgezustand wiederfinden [Nil98].
Planen als Suche im Planraum
Ebenso wie bei der Suche im Zustandsraum kann auch die Suche im Planraum
als Suche in einem Graph aufgefasst werden. Im Planraum besteht dieser Graph
aus partiellen Teilplänen. Diese Teilpläne bilden die Knoten des Planraumgraphs.
Die Kanten geben die Erweiterungen an, die nötig sind, um von einem Teilplan zu
einem anderen zu kommen. Ein vollständiger Plan lässt sich aus einem Zielknoten
erzeugen [Nil98].
Ein Teilplan besteht aus partiell initialisierten Operatoren und Constraints. Das
bedeutet in ihm ist beschrieben, welche Aktionen bisher verwendet wurden, welche
Aktion vor welcher anderen auszuführen ist und welche Abhängigkeiten zwischen
den Aktionen bestehen. Die Reihenfolge der Aktionen ist nicht zwingenderweise
vollständig beschrieben, man spricht von einer partiellen Ordnung. So kann es
durchaus sein, dass zwischen mehreren Aktionen keine Reihenfolge festgelegt ist.
Die Abhängigkeiten zwischen den Aktionen beschreiben, welche Vorbedingung
einer Aktion bei welcher anderen benutzten Aktion in den Effekten steht. Diese
Abhängigkeiten nennt man auch kausale Links. Bei der Aufnahme von weiteren
Aktionen in den Teilplan, bei seiner Erweiterung, ist darauf zu achten, dass diese
kausalen Links nicht gefährdet werden.
So kann es drei Aktionen a, b, c geben. Eine Eigenschaft P taucht bei a in
den Effekten auf und bei b in den Vorbedingungen. So ergibt sich der kausale
Link (a, P , b). Daraus ergibt sich auch die Ordnungsrelation a < b; a soll vor
b ausgeführt werden. Die Aktion c hat nun ¬P in ihren Effekten stehen. Diese
25
2. Grundlagen
B
C
A
F
D
A
B
E
C
D
E
F
Abbildung 2.5: Topologische Sortierung eines Beispielgraphen
Aktion gefährdet damit den kausalen Link (a, P , b), denn es kann sein, dass die
Ausführung von c dazu führt, dass b nicht mehr ausgeführt werden kann. Die
Vorbedingung P von b wäre nicht mehr erfüllt. Dies ist genau dann der Fall,
wenn c zwischen der Ausführung von a und b ausgeführt wird. Das bedeutet,
der kausale Link ist sicher, wenn c entweder vor a oder nach b ausgeführt wird,
also wenn die Ordnungsrelationen c < a oder b < c gelten. Eigenschaften, die
als Vorbedingungen einer Aktion auftreten, und die bisher noch nicht in einer
anderen Aktion als Effekte standen, bilden die sogenannte Agenda eines partiellen
Teilplans, welche es abzuarbeiten gilt [RN04].
Ist die Agenda abgearbeitet, kein kausaler Link verletzt und existieren keine
Zyklen in den Ordnungsrelationen, dann befindet man sich in einem Zielknoten des
Planraumgraphs. Der partielle Teilplan ist vollständig. Er lässt sich nun auch allein
durch die Angabe der verwendeten Aktionen und durch die partielle Ordnung
zwischen diesen Aktionen beschreiben. Aus dieser partiellen Ordnung kann dann
mittels topologischer Sortierung ein sequentieller Plan erstellt werden [RN04].
Bei der topologischen Sortierung wird versucht, eine zulässige Reihenfolge der
Knoten eines Abhängigkeitsgraphen (Directed Acyclic Graph, DAG) zu finden. Ein
DAG ist ein gerichteter Graph, der keine Zyklen enthält. Für eine Kante (u, v)
gilt nach der topologischen Sortierung, dass der Knoten u vor dem Knoten v in
der Sortierung erscheint. Für die topologische Sortierung eines DAG kann eine
modifizierte Tiefensuche eingesetzt werden. Immer, wenn in der Tiefensuche ein
Knoten fertig abgearbeitet ist (also alle seine Nachfolger betrachtet wurden), wird
dieser Knoten an den Anfang einer verketteten Liste hinzugefügt. Die Reihenfolge
der Knoten in dieser Liste entspricht nach der Beendigung der Tiefensuche der
topologischen Sortierung des Graphen [CSRL01].
Der partielle Teilplan kann als Abhängigkeitsgraph G = (V, E) gesehen werden. Hierbei entspricht die Knotenmenge V den verwendeten Aktionen. Somit
steht jeder Knoten für genau eine verwendete Aktion. Die Ordnungsrelationen
beschreiben die Kantenmenge E. Eine Relation a < b bedeutet, dass zwischen
den Knoten für die Aktionen a und b eine gerichtete Kante verläuft. Sie ist von a
nach b gerichtet. Die topologische Sortierung des als DAG aufgefassten partiellen
Teilplans wird auch Linearisierung des Teilplans genannt [RN04]. In Abbildung
26
Algorithmus 2 Pseudocode Partial Order Planning (vgl. [Wel94])
Eingabe: T eilplanstart
Ausgabe: T eilplancomplete
1: while Agenda 6= ∅ do
2:
next subgoal ← (P, a) ∈ Agenda
3:
Agenda ← Agenda − (P, a)
4:
Aktion b ← Aktion x, P ∈ x.EF F ECT
5:
AS ← AS ∪ b
6:
OS ← OS ∪ (b < a)
7:
CS ← CS ∪ (b, P, a)
8:
if b gefährdet einen kausalen Link (c, Q, d) ∈ CS then
9:
OS ← (OS ∪ (b < c)) ∨ (OS ∪ (d < b))
10:
end if
11:
if b0 ∈ AS gefährdet den kausalen Link (b, P, a) then
12:
OS ← (OS ∪ (b0 < b)) ∨ (OS ∪ (a < b0 ))
13:
end if
14:
if b ∈
/ AS then
15:
for all Pi ∈ b.P RECON D do
16:
Agenda ← Agenda ∪ (Pi , b)
17:
end for
18:
end if
19: end while
20: return Entstandenen partiellen Plan T eilplancomplete = (AS, OS)
2.5 ist ein Beispiel für die topologische Sortierung eines Graphen abgebildet.
Die Durchführung einer topologische Sortierung ist allerdings kein Muss. Hier
liegt die Besonderheit beim Planen als Suche im Planraum. Anstatt einem sequentiellen Plan kann der entstandene partielle Teilplan genutzt werden, um zum Beispiel einen parallelisierbaren Plan zu entwickeln. Dies ergibt sich aus den partiellen Ordnungsrelationen. Existieren zum Beispiel Aktionen a, b, c, d, sowie die Ordnungsrelationen a < d, a < b, a < c, b < d, c < d, so ergibt sich die Möglichkeit, die
Ausführung von b und c parallel durchzuführen. Denn es ist nur beschrieben, dass
a vor allen anderen und d nach allen anderen Aktionen ausgeführt werden soll.
Diese Informationen würden bei einer Linearisierung verloren gehen. Außerdem
bestünde die Möglichkeit, dass spätere Informationen eine bessere Einschätzung
möglich machen, bezüglich der Reihenfolge der Ausführung von b und c [RN04].
Ein Algorithmus für die Suche im Planraumgraph ist das Partial Order Planning. Mit ihm lässt sich aus den Informationen, was das Ziel ist und welche Ausgangssituation vorliegt, ein vollständiger partieller Plan erzeugen, der dann linearisiert werden kann. Dieser Algorithmus stellt auch die Basis für das in Kapitel 4
beschriebene Verfahren zur Konstruktion einer IE-Pipeline dar.
Der Pseudocode für das Partial Order Planning ist in Algorithmus 2 zu sehen.
Die verwendeten Aktionen werden in der Menge AS gespeichert. Vorbedingungen
einer Aktion x stehen in x.P RECON D, ihre Effekte in x.EF F ECT . Die parti-
27
2. Grundlagen
A
B
Start
LiegtAuf(BlockA,BlockB)
LiegtAufTisch(BlockB)
IstFrei(BlockA)
GreiferIstLeer()
GreiferHält(BlockA)
AblegenAufTisch(BlockA)
¬GreiferHält(BlockA)
IstFrei(BlockA)
GreiferHält(BlockB)
GreiferIstLeer()
LiegtAufTisch(BlockA)
IstFrei(BlockA)
Ablegen(BlockB,BlockA)
LiegtAuf(BlockB,BlockA) GreiferIstLeer()
IstFrei(BlockB)
LiegtAuf(BlockB,BlockA)
¬IstFrei(BlockA) ¬GreiferHält(BlockB)
LiegtAufTisch(BlockA)
Finish
B
A
Abbildung 2.6: Beispiel eines partiellen Teilplans
ellen Ordnungsrelationen zwischen den Aktionen finden in der Menge OS Platz.
In CS stehen die kausalen Links. Die Agenda enthält Teilziele der Form (P, a),
das bedeutet eine Aktion a hat eine Vorbedingung P , welche noch nicht von einer
anderen Aktion erfüllt wurde. Im initialen partiellen Teilplan T eilplanstart existieren zwei Hilfsaktionen start und f inish in AS und die Relation start < f inish
in OS. Die Aktion start hat alle Eigenschaften der Ausgangssituation (entspricht
dem Anfangszustand im Zustandsraum) als Effekte in seiner Effektliste. Die Aktion f inish enthält alle zu erreichenden Teilziele als Vorbedingungen. Diese Vorbedingungen sind demnach auch initialer Bestandteil der Agenda.
Zum Beschreiben eines vollständigen, partiellen Plans reichen bereits die verwendeten Aktionen AS und die partiellen Ordnungsrelationen zwischen den Aktionen in OS aus. Der Algorithmus arbeitet die Agenda schrittweise ab. Dabei
kann es natürlich vorkommen, dass neue Teilziele auf die Agenda kommen (Zeile
16). In Zeile 8-13 werden die gefährdeten Links wieder sicher gemacht. Voraussetzung dafür ist, dass der Algorithmus Aktionen in Zeile 4 so wählt und deren
Anordnung so setzt, dass jeder gefährdete Link gesichert werden kann. An diesen
Stellen verhält sich der Algorithmus nicht-deterministisch [RN04].
In Abbildung 2.6 ist ein partieller Teilplan zu sehen, der als Knoten eines
Planraumgraphs von einem Partial Order Planner erreicht worden ist. Neben
Start und F inish hat dieser bereits zwei Aktionen AblegenAuf T isch(BlockA)
und Ablegen(BlockB, BlockA) zu AS hinzugefügt. In CS existieren drei kausale
Links:
(AblegenAuf T isch(BlockA), IstF rei(BlockA), Ablegen(BlockB, BlockA))
28
(AblegenAuf T isch(BlockA), LiegtAuf T isch(BlockA), F inish)
(Ablegen(BlockB, BlockA), LiegtAuf (BlockB, BlockA), F inish)
In der Ordnungsrelation OS befinden sich bisher folgende Relationen:
Start < F inish
AblegenAuf T isch(BlockA) < Ablegen(BlockB, BlockA)
AblegenAuf T isch(BlockA) < F inish
Ablegen(BlockB, BlockA) < F inish
Auf der Agenda des Planers befinden sich die beiden noch nicht erfüllten Teilziele Greif erHält(BlockA) und Greif erHält(BlockB). Ausgehend von diesem
partiellen Teilplan könnte der Partial Order Planner nun zum Beispiel die Aktion Auf nehmenV omT isch(BlockB) zu AS hinzunehmen und somit den nächsten
Knoten des Planraumgraphs erreichen und dann entsprechend die Mengen OS,
CS und die Agenda anpassen.
Andere Planungsverfahren
Neben den klassischen Planungsverfahren der Suche im Zustandsraum bzw. im
Planraum, existieren noch weitere. Zwei dieser Planungsverfahren sollen im Folgenden kurz vorgestellt werden, da im späteren Konzeptteil eine Begründung,
warum diese nicht für die Konstruktion der IE-Pipeline genutzt wurden, angeführt
wird.
Hierarchical Task Network Planning Beim Hierarchical Task Network Planning (HTN Planning) wird ein Planungsproblem dadurch gelöst, dass dieses hierarchisch zerlegt wird. Das initiale Planungsproblem entspricht einem Plan auf der
höchsten Ebene. Die Pläne werden dann schrittweise durch Aktionszerlegungen
verfeinert. Diese Pläne können solange verfeinert werden, bis man nur noch sogenannte primitive Aktionen im Plan hat, die sich nicht weiter verfeinern lassen.
Das bedeutet, beim Hierarchical Task Network Planning werden bestehende Pläne
weiter konkretisiert, während bei den bereits besprochenen Planungsverfahren der
Plan von Grund auf aufgebaut wird. Um eine Aktion zu zerlegen, muss in einer
sogenannten Planbibliothek eine mögliche Verfeinerung dieser Aktion angegeben
sein. Dies bedeutet aber auch, dass für das HTN Planning eben diese Planbibliothek bereitstehen muss. Diese kann einerseits durch Experten aufgebaut, aber vor
allem auch durch den Einsatz von maschinellen Lernverfahren und Beispielplänen,
mit denen der Computer dann selbst die Planbibliothek konstruieren kann, erreicht
werden [RN04].
29
2. Grundlagen
Planen als Erfüllbarkeitsproblem Das Planungsproblem kann auch als Erfüllbarkeitsproblem angesehen werden. Hierzu wird das Planungsproblem als aussagenlogische Formel in konjunktiver Normalform aufgefasst und umgeformt. Anschließend wird mithilfe eines SAT-Solver (einer Anwendung die zum Lösen des
Erfüllbarkeitsproblems eingesetzt wird) versucht, eine erfüllende Belegung für die
Aktionen zu finden. Aus den Aktionen, die mit wahr belegt wurden, ergibt sich
dann der resultierende Plan.11 Ein großes Problem bei dieser Art des Planens ist
die große Menge an unterschiedlichen Aussagensymbolen. In [RN04] wird allein
die Menge der unterschiedlichen Aktionssymbole folgendermaßen abgeschätzt:
Menge Aktionssymbole := O(T × |Operatoren| × |Objekte|P )
Hierbei ist T die Anzahl an (Zeit-)Schritten des Plans, Operatoren gibt die Anzahl
an Operatoren an, Objekte beschreibt die Anzahl der Objekte in dem Planungsproblem (dies entspräche der Anzahl an Konstanten, wenn zur Beschreibung des
Planungsproblems Prädikatenlogik verwendet werden würde), mit P schließlich
werden die maximalen Argumente der Operatoren ausgedrückt. Die Menge der
Gesamtklauseln ist allerdings erheblich größer und der dadurch benötigte Speicherverbrauch stellt den limitierenden Faktor beim Einsatz dieser Art des Planens
dar [RN04].
2.4 Information Extraction
Nachdem in den vorherigen Abschnitten der Bereich Expertensysteme und die damit verbundenen Aspekte erläutert wurden, soll im Folgenden die Domäne des zu
entwickelnden Expertensystems beleuchtet werden. Diese Domäne ist die Information Extraction. In diesem Bereich gibt es zwei Teilbereiche, die für diese Arbeit
von besonderem Interesse sind. Das sind zum einen die Information-ExtractionPipelines, die es von dem in dieser Arbeit zu entwickelndem Expertensystem zu
konstruieren gilt, und zum anderen mögliche Qualitätsmaße der einzelnen Information Extraction-Verfahren, anhand derer eine Bewertung eben dieser Verfahren
hinsichtlich ihrer Effizienz und Effektivität möglich wird. Dies ist von entscheidender Bedeutung, wenn das Expertensystem vor der Auswahl von geeigneten
Verfahren für eine Information-Extraction-Pipeline steht.
2.4.1 Die Domäne Information Extraction
Die Information Extraction (IE) ist ein Teilbereich der natürlichen Sprachverarbeitung (engl. Natural Language Processing, NLP). Innerhalb der IE liegt die
11
Das Ganze wurde hier etwas vereinfacht dargestellt. Es müssen zum Beispiel verschiedene
Zeitpunkte, wann eine Aktion ausgeführt wird, betrachtet werden, denn diese Ausführungsreihenfolge entspricht ja gerade dem Plan. Die Umformung in eine aussagenlogische Formel
wird dadurch um einiges komplexer.
30
Kernaufgabe darin, spezifische, implizite Informationen aus natürlichsprachigem
Text zu extrahieren [JM08]. Der unstrukturierte, natürlichsprachige Text ist die
Eingabe für die IE. Als Ausgabe werden dann strukturierte und eindeutige Daten
geliefert. Die gefundenen Daten können direkt einem interessierten Nutzer angezeigt werden. Durch die eindeutige und strukturierte Form besteht aber vor allem
auch die Möglichkeit, mit ihnen Datenbanken zu füllen [Cun05].
Das Extrahieren von Marktvorhersagen aus Wirtschaftsnachrichten im World
Wide Web ist ein Beispiel für eine IE-Aufgabe (vgl. [WPS10]). Dabei wird versucht, beispielsweise in Nachrichtenartikeln Marktvorhersagen zu identifizieren
und zu extrahieren. Marktvorhersagen sind Umsatzaussagen von Unternehmen,
die sich auf die Zukunft beziehen. Eine Marktvorhersage ist dabei ein sogenanntes
Ereignis. Es besteht aus mehreren Teilen, sogenannten Named Entities (benannten Entitäten). Eine Entität der Marktvorhersage könnte das Unternehmen sein,
auf das sich die Vorhersage bezieht. Eine weitere Entität könnte eine Zeitinformation sein, die beschreibt auf welchen Zeitraum sich die Vorhersage bezieht. Auch
der prognostizierte Umsatz des Unternehmens in Form einer Geldaussage ist eine
Entität. Die Marktvorhersage lässt sich also als mehrstellige Relation zwischen
Entitäten, etwa (Unternehmen, Zeitaussage, Geldaussage), beschreiben. In dieser Form werden die Informationen, die Daten, aus dem natürlichsprachigen Text
extrahiert und in eine Datenbank geschrieben. Daraufhin können spezielle Abfragen auf die Datenbank erfolgen, um etwa alle Marktvorhersagen bis zu einem
bestimmten Jahr, oder alle zukünftigen Marktvorhersagen, die eine Geldsumme
von mehr als 15 Millionen Euro betreffen auszuwählen. Auf Basis dieser Informationen können dann bestimmte Entschlüsse gefasst werden, zum Beispiel das
An- und Verkaufen von Aktien an der Börse. Das schnelle Extrahieren von Informationen durch Information Extraction kann daher von großer wirtschaftlicher
Bedeutung sein.
Eine Marktvorhersage setzt sich, wie bereits erwähnt, aus verschiedenen Entitäten und den Relationen zwischen ihnen zusammen. Diese einzelnen Entitäten
müssen identifiziert werden damit die Bestimmung der Marktvorhersage möglich
ist. Daher muss es Verfahren geben, die jede dieser Entitäten in einem Text findet
(ein sogenannter Named Entity Recognizer, NER). In der IE spricht man davon,
dass die gefundenen Informationen im Text annotiert werden. Das Wort Microsoft
innerhalb eines Fließtexts könnte demnach von einem bestimmten IE-Verfahren
als Unternehmen gekennzeichnet werden. Damit dies möglich ist, muss zuerst der
Text in Sätze und Tokens zerlegt werden. Tokens sind die kleinsten semantischen
Bedeutungseinheiten eines Textes, zum Beispiel einzelne Wörter. Für die Bestimmung dieser grundlegenden Informationen sind Verfahren des NLP notwendig, die
sogenannte Vorverarbeitung der IE [JM08]. Sind die Entitäten eines Textes identifiziert, kann ein IE-Verfahren entscheiden, ob innerhalb eines Textabschnittes
von einer Marktvorhersage gesprochen wird. Hierfür kann es nötig sein, dass wiederum bereits andere Vorinformationen vorzuliegen haben. Ausgehend von den
Sätzen und Tokens können zum Beispiel von einem anderen Verfahren die Subjekte und Verben eines Satzes bestimmt werden. Dafür sind ebenfalls spezielle
31
2. Grundlagen
Verfahren notwendig. Das Vorhandensein dieser Informationen ermöglicht das InBeziehung-Setzen der Entitäten miteinander, um dann eine Marktvorhersage zu
identifizieren.
Das Beispiel zeigt, dass unterschiedliche IE-Verfahren unterschiedliche Daten,
in Form gemachter Annotationen am Text, liefern. Die meisten Verfahren können
nicht direkt auf der Basis des reinen Fließtextes arbeiten. Manche setzen voraus, dass bereits Sätze identifiziert wurden. Wieder andere benötigen das Vorhandensein von bestimmten Entitäten, damit sie tiefer gehende Informationen, wie
Marktvorhersagen, im Text finden und kennzeichnen können. Die benötigten Annotationen können demnach als Eingaben eines Algorithmus aufgefasst werden.
Die Ausgabe eines Algorithmus sind die von ihm gekennzeichneten Annotationen.
Das bedeutet, die Mehrzahl der Verfahren baut aufeinander auf. Sie erweitern dabei sukzessiv die gefundene Menge an Daten aus einem Text. Die Berücksichtigung
dieser Abhängigkeiten zwischen den Algorithmen ist von zentraler Bedeutung für
das in dieser Arbeit entwickelte Expertensystem.
Jede Art von Information kann von einem anderen Verfahren, einem anderen
Algorithmus, annotiert werden. Ein Algorithmus, welcher Unternehmen in Texten identifiziert, führt dies mit einer bestimmten Effizienz und Effektivität durch,
sobald alle für seine Ausführung benötigten Daten vorhanden sind. Normalerweise ist das Ziel, möglichst gute Ergebnisse zu bekommen. Der angesprochene
Algorithmus sollte also alle Unternehmen im Text finden, auch wenn dies lange
dauert. Es kann aber auch Situationen geben, in denen möglichst schnell Ergebnisse geliefert werden sollen. Dabei ist es egal, ob ein paar Informationen im Text
nicht gefunden werden. Zum Beispiel kann es sein, dass die Marktvorhersagen in
Web-Artikeln möglichst schnell identifiziert werden sollen, damit der Anwender
einen zeitlichen Vorteil auf dem Aktienmarkt bekommt. Aus diesem Grund kann
es mehrere Algorithmen geben, die die gleichen Daten liefern aber eine unterschiedliche Effizienz und Effektivität haben. All dies muss bei der Entwicklung
des Expertensystems berücksichtigt werden. Die Art der Algorithmen kann dabei
vollkommen unterschiedlich sein. So existieren Algorithmen, die auf Basis eines
maschinellen Lernverfahrens arbeiten, aber auch solche, die regelbasiert vorgehen
oder zum Beispiel einfach einen Abgleich mit einem Wörterbuch machen [JM08].
Für genauere Informationen über die Funktionsweise von und Algorithmen für die
einzelnen IE-Aufgaben sei an dieser Stelle auf [JM08] verwiesen.
2.4.2 Information-Extraction-Pipelines
Die einzelnen Algorithmen der IE und NLP liefern unterschiedliche Daten. Dabei brauchen sie größtenteils, wie schon beschrieben, bereits im Text gefundene
Daten für ihre erfolgreiche Ausführung. Sie bauen also aufeinander auf und es bestehen Abhängigkeiten zwischen ihnen für eine erfolgreiche Ausführung. Um diese
Abhängigkeiten zu berücksichtigen, befinden sich die Algorithmen meist in einer
sequentiellen Anordnung. Diese Anordnung wird Information-Extraction-Pipeline
(IE-Pipeline) genannt. Eine IE-Aufgabe, wie das Finden von Marktvorhersagen,
32
wird durch die Ausführung der IE-Pipeline gelöst. Die durch die IE-Aufgabe spezifizierten zu identifizierenden Informationen sind also das Ziel der IE-Pipeline.
Eine solche IE-Aufgabe ist Teil der Eingabe des von dieser Arbeit zu entwickelnden Expertensystems und hat bei der Konstruktion einer IE-Pipeline eine große
Bedeutung. Eine IE-Pipeline soll in den meisten Fällen möglichst effektiv sein. Allerdings soll sie dabei auch immer so effizient wie möglich sein. Aus diesem Grund
gibt es eine Reihe von Paradigmen, die bei der Konstruktion einer IE-Pipeline, und
somit auch von dem in dieser Arbeit entwickelten Expertensystem, berücksichtigt
werden sollen.
Definition von Information-Extraction-Pipelines
In [WSE11] werden IE-Pipelines als Tupel Π hA, πi definiert. Hierbei bezeichnet
π = (A1 , . . . , An ), Ai ∈ A einen Schedule der einzelnen IE-Analyseschritte Ai aus
der Gesamtmenge von IE-Analyseschritten A. Die Menge A = {A1 , . . . , Ak } ordnet jedem Analyseschritt einen konkreten Algorithmus zu, der die diesem Schritt
zugrundeliegende Aufgabe löst und die benötigten Daten bereit stellt.
Ein Analyseschritt kann etwa das Annotieren von Sätzen oder Unternehmensentitäten im Text sein. Es wird also verlangt, dass nach diesem Analyseschritt Sätze
beziehungsweise Unternehmen annotiert sind. Hierfür wird dem Analyseschritt
ein entsprechender Algorithmus zugeordnet, der eben jene Sätze beziehungsweise
Unternehmen annotieren kann. Diese Annotationen stellen also seine Ausgabe dar.
Manche Algorithmen werden ihre Aufgabe nicht erfüllen können, wenn die
benötigten Annotationen nicht vorliegen, bei anderen sinkt hierdurch ihre Effektivität. Aus diesem Grund sollen nur zulässige IE-Pipelines betrachtet werden. Dies
sind solche Pipelines, deren Schedule π alle Eingabeanforderungen erfüllt, die von
der Menge verwendeter Algorithmen A aufgestellt werden. Hierdurch bleibt die Effektivität der einzelnen Algorithmen auch bei verschiedenen Schedules gleich, die
Menge an anwendbaren Schedules wird aber eingeschränkt [WSE11]. Das bedeutet, bei der Ausführung eines Algorithmus der IE-Pipeline ist davon auszugehen,
dass alle seine Eingaben, also die am Text annotierten Daten, bereits vorliegen.
Demnach sind die Algorithmen, die diese Eingaben als Ausgaben haben, hier bereits ausgeführt worden. Das von dieser Arbeit zu entwickelnde Expertensystem
darf nur zulässige IE-Pipelines konstruieren. Darüber hinaus sollen diese Pipelines
aber auch immer so effizient wie möglich sein. Methoden dazu werden im nächsten
Abschnitt beschrieben.
Konstruktion von effizienten Information-Extraction-Pipelines
Ziel dieser Arbeit ist ein Expertensystem, welches automatisiert effiziente IEPipelines konstruieren soll. Eine Methode, um effiziente IE-Pipelines aufzubauen,
wird in [WSE11] vorgestellt. In der vorliegenden Arbeit wird versucht, die Methode
weitestgehend in dem zu entwickelnden Expertensystem umzusetzen. Die Methode
umfasst vier Paradigmen, die im Folgenden vorgestellt werden.
33
2. Grundlagen
Paradigma 1: Maximum Decomposition Damit der gewählte Schedule der einzelnen IE-Analyseschritte zu einer möglichst effizienten IE-Pipeline führt, müssen
diese einzelnen IE-Aufgaben soweit wie möglich in ihre einzelnen Analyseteile zerlegt werden. Dies erfordert auch, dass die Algorithmen, welche einem IEAnalyseschritt zugrunde liegen, in gleicher Weise aufgeteilt werden. Dadurch ist
ein feinerer Schedule möglich, wie ihn die nächsten beiden Paradigmen erfordern.
Weiterhin kann die Effizienz der entstehenden IE-Pipeline dahingehend gesteigert
werden, dass für die IE-Gesamtaufgabe nur noch die IE-Aufgaben behandelt werden, die zum Lösen der Gesamtaufgabe auch wirklich gebraucht werden.
Ein Algorithmus, der Unternehmen und Personen als Entitäten in einem Text
identifiziert, könnte zum Beispiel in zwei Algorithmen zerlegt werden. Jeder der
Algorithmen ist dann entweder für die Annotation von Unternehmen oder Personen zuständig. Braucht man beispielsweise für die Identifizierung von Marktvorhersagen nur das Vorhandensein von Unternehmen in einem Text, so braucht der
Algorithmus, der Personen findet, nicht ausgeführt zu werden. Hiermit wird die
Effizienz der IE-Pipeline gesteigert.
Dieses Paradigma wird von dieser Arbeit nicht weiter behandelt, da es eine
genaue Kenntnis der Implementierung der einzelnen IE-Verfahren und Algorithmenimplementierungen erfordert. Die Verbesserung beziehungsweise Verfeinerung
der IE-Algorithmen liegt allerdings außerhalb des Fokus dieser Arbeit. So setzt
diese Arbeit eine schon durchgeführte Maximum Decomposition der vorhandenen
IE-Aufgaben und Algorithmen voraus.
Paradigma 2: Early Filtering Durch das Einführen von Filtern nach einem IEAlgorithmus der IE-Pipeline kann die Gesamteffizienz der Pipeline erheblich gesteigert werden. Ein Filter entfernt alle Textstellen, in denen die jeweilige Ausgabe des Algorithmus nicht vorkommt. Ein Filter nach der Identifizierung von
Unternehmensentitäten lässt daher für die nachfolgenden Algorithmen nur den
Text durch, der auch eben jene Entitäten enthält. Dies bedeutet, dass spätere
Analyseverfahren nur noch den Text untersuchen müssen, indem die benötigten
Annotationen auch wirklich vorliegen.
Als Filterverfahren werden die Algorithmen bezeichnet, nach denen gefiltert
wird. Gefiltert wird immer dann, wenn ein für die Bewältigung der IE-Pipeline
zugrundeliegenden IE-Aufgabe wichtiger Analyseschritt durchgeführt worden ist.
Besteht die IE-Aufgabe in der Identifizierung von Marktvorhersagen der Form
(Unternehmen, Zeitaussagen, Geldaussagen), so ist jeder Algorithmus, der Teile
dieser Aufgabe löst, ein Filterverfahren. Dies sind bei dem Beispiel die Algorithmen, welche Unternehmen, Zeitaussagen und Geldaussagen im Text identifizieren,
sowie der Algorithmus, der darauf aufbauend Marktvorhersagen erkennt. Filteringstages werden die Teile der Pipeline genannt, welche nach einem Filterverfahren anfangen und sich bis einschließlich dem jeweils nächsten Filterverfahren
zuzüglich seinem Filter erstrecken.
Beim Early Filtering geht es nicht um das Filtern an sich, sondern um das
34
möglichst frühe Filtern. Das bedeutet, die IE-Pipeline wird so umgestellt, dass
die Filterverfahren so früh wie möglich ausgeführt werden. Dadurch arbeitet der
nachfolgende Teil der IE-Pipeline auf einer kleineren Textmenge und somit wird
die Gesamteffizienz der Pipeline erhöht.
Paradigma 3: Lazy Evaluation Durch die Verzögerung der Ausführung der einzelnen Algorithmen ist nach der Beachtung von Paradigma 2 eine weitere Steigerung der Effizienz der IE-Pipeline möglich: Ein Algorithmus wird erst ausgeführt,
wenn seine Ergebnisse auch wirklich benötigt werden. Des Weiteren werden nur
die nach der vorherigen Filterung übrig gebliebenen Textstellen betrachtet. Somit
kann eine Verzögerung eines wenig effizienten Algorithmus die Gesamteffizienz
dahingehend verbessern, dass er bei einer späteren Ausführung nach anderen IEAnalyseschritten weit weniger Text analysieren muss, da ein Großteil eventuell
schon durch vorhergehendes Filtern aussortiert wurde. Dieses Paradigma zeigt
damit auch das Potenzial hinsichtlich der Effizienz, dass in einer maximalen Zerlegung der einzelnen IE-Aufgaben aus Paradigma 1 steckt.
Paradigma 4: Optimized Scheduling Nach Durchführung der ersten drei Paradigmen kann durch die optimale Anordnung der einzelnen Filterverfahren hinsichtlich der Menge an gefilterten Sätzen die Effizienz der IE-Pipeline zusätzlich
erhöht werden. Hierbei wird die Menge an gefiltertem Text im Verhältnis zum Gesamttext, die sogenannte Filterrate, als Basis genommen. Bei zwei Analysephasen
A1 und A2 wird dann diejenige zuerst ausgeführt, die in der gleichen Zeit mehr
Text heraus filtert.
Die von diesem Paradigma benötigte Filterrate des jeweiligen Filterverfahren
ist allerdings stark abhängig von der Art des zu analysierenden Textes. Ist für den
Algorithmus, welcher Unternehmensentitäten bestimmt, bei einer Textmenge eine
hohe Filterrate ermittelt worden, so kann dies nicht direkt auf eine andere Textmenge übertragen werden. Ist die Filterrate bei Wirtschaftsnachrichten noch niedrig, so kann sie bei Boulevardnachrichten sehr hoch sein, da dort eventuell gar keine
Unternehmen vorkommen und somit der komplette Text heraus gefiltert wird. Die
Filterraten müssten demnach dynamisch während der Pipeline-Ausführung ermittelt werden. Aus diesem Grund betrachtet diese Arbeit das Paradigma Optimized
Scheduling in der vorgestellten Form nicht.
2.4.3 Effizienz und Effektivität im Bereich Information
Extraction
Die vom Expertensystem konstruierten IE-Pipelines unterliegen bestimmten Anforderungen hinsichtlich ihrer Qualität. Unterschiedliche Einsatzbereiche für die
zu konstruierende IE-Pipeline können zu unterschiedlichen Pipelines führen, auch
wenn das Ziel dieser Pipelines, die zugrundeliegende IE-Aufgabe, das gleiche ist.
Die Effizienz und die Effektivität als Qualitätsmaße der Pipelines sind hierbei die
35
2. Grundlagen
wesentlichen Unterschiede. Wie schon in einigen Beispielen dargelegt, kann es notwendig sein, eine möglichst effiziente oder effektive IE-Pipeline zu haben. Effizienz
im Arbeiten der Pipeline ist immer dann notwendig, wenn die Informationen, welche die Pipeline liefern soll, schnell und unmittelbar gebraucht werden, wie etwa
Marktvorhersagen für das Agieren am Aktienmarkt.
Die IE-Pipeline besteht aus ihren sequentiell angeordneten Algorithmen. Effizienz und Effektivität der gesamten IE-Pipeline beim Bewältigen einer IE-Aufgabe
sind daher direkt abhängig von der Effizienz und Effektivität der einzelnen Algorithmen. Zwischen Effizienz und Effektivität der Algorithmen besteht aber im
Allgemeinen ein Trade-Off [WSE11]. Ein Algorithmus braucht mehr Zeit für die
Analyse des Textes, wenn er bessere Ergebnisse liefern soll. Umgekehrt kann
er nicht die besten Ergebnisse herausfinden, wenn ihm nicht genügend Zeit zur
Verfügung steht. Daher existieren, wie bereits in Abschnitt 2.4.1 angesprochen,
oft mehrere Algorithmen für die gleiche IE-Aufgabe, wobei die eine Gruppe effizient aber weniger effektiv ist und die andere Gruppe genau umgekehrt. Hinsichtlich
der benötigten Qualität einer IE-Pipeline, gemessen in ihrer Effizienz oder Effektivität, müssen daher die dafür geeignetsten einzelnen Algorithmen ausgewählt
werden.
Hierfür ist es allerdings erforderlich, die benötigte Qualität der Algorithmen
einschätzen zu können. Für die Beurteilung von Effizienz und Effektivität gibt
es verschiedene Qualitätsmaße. Im Bezug auf die Effektivität benutzt [WSE11]
Recall, Precision, F-Measure, Accuracy und den Labeled Attachment Score. Für
die Effizienz bietet [WSE11] die Maße Average Sentence Response Time, Averaged Efficiency und Averaged Efficiency at Effectiveness an. Da die von dem
entwickelten Expertensystem verwendete IE-Algorithmenmenge aus der Arbeit
von [WSE11] stammt, und somit diese Algorithmen auch Werte für die angesprochenen Effizienz- und Effektivitätsmaße besitzen, sollen diese Maße im Folgenden
näher erläutert werden.
Effektivitätsmaße
Die Effektivität eines IE-Algorithmus ist abhängig von den Entscheidungen die
er für einen gegebenen Text trifft, also von den Annotationen, die er dem Text
hinzufügt. Oft wird im Bereich des Information Extraction zum Testen der Effektivität eines Algorithmus ein Text im Vorfeld von Hand annotiert. Das bedeutet
die korrekten erwarteten Ergebnisse werden manuell festgelegt. Der Algorithmus
wird dann auf dem gleichen Text ausgeführt. Anschließend werden die von Hand
angelegten Annotationen mit den vom Algorithmus erzeugten verglichen.
In Tabelle 2.1 ist abgebildet, wie die Ergebnisse des Algorithmus interpretiert
werden. Hat der Algorithmus etwas annotiert, was auch im Vorfeld als korrekte
Annotation bestimmt wurde, so spricht man von einem True Positive. Hat der
Algorithmus etwas annotiert, was nicht annotiert wurde, so spricht man von einem
False Positive. Konnte der Algorithmus eine gesuchte Annotation nicht finden, so
spricht man von einem False Negative. Wurde der nicht annotierte Text auch
36
Manuelle Annotation
JA
NEIN
Algorithmische Annotation
JA
NEIN
True Positive (TP)
False Negative (FN)
False Positive (FP)
True Negative (TN)
Tabelle 2.1: Beziehung zwischen manueller und algorithmischer Annotation [SR02]
manuell nicht annotiert, so handelt es sich um einen True Negative [SR02]. Mit
diesen grundlegenden Begriffen lassen sich nun die Effektivitätsmaße erklären.
Precision, Recall und F-Measure Die Precision P bezeichnet die Menge der
richtigen Ergebnisse in Bezug zu allen erzielten Ergebnissen eines Algorithmus.
Damit ist es ein Maß für die Exaktheit eines Algorithmus, denn es misst, wie
viele der Ergebnisse korrekt sind [SR02]. Der Recall R bezeichnet die Menge der
richtigen Ergebnisse in Bezug zu allen von Hand annotierten Stellen. Damit ist
es ein Maß für die Vollständigkeit eines Algorithmus, denn es misst, wie viele von
den erwarteten Annotationen gefunden wurden.
P =
TP
TP
, R=
TP + FP
TP + FN
Es lässt sich anhand der Formeln leicht feststellen, dass ein Recall von 1, 0 und
damit 100% relativ einfach dadurch erreicht werden kann, indem der Algorithmus
den kompletten Text bzw. alle Wörter annotiert. Damit hat er auf jeden Fall alle
zu findenen Annotationen abgedeckt und ist damit vollständig. Eine hohe Precision lässt sich erreichen, indem nur eine Annotation gemacht wird von dem Textteil,
der mit der höchsten Wahrscheinlichkeit eine gesuchte Annotation ist. Dadurch
steigt die Precision auf 1, 0 bzw. 100% (oder 0% für den Fall, dass der vom Algorithmus annotierte Text doch nicht gesucht wurde). Beide Extremwerte alleine
sagen demnach noch nichts darüber aus, ob ein Algorithmus wirklich effektiv ist.
Daher wird durch den F-Measure versucht ein geeignetes Gesamtmaß für die Effektivität zu finden. Der F-Measure F1 ist dabei das harmonische Mittel zwischen
Precision und Recall [SR02].
F1 = 2 ×
P×R
P+R
Eine effektive IE-Pipeline sollte im Allgemeinen einen hohen F-Measure Wert
besitzen. Das bedeutet konkret, dass die zugrundeliegende IE-Aufgabe, wie das
Identifizieren von Marktvorhersagen, mit hoher Effektivität gelöst wird.
Die einzelnen Werte von Recall, Precision und F-Measure lassen sich weder miteinander verrechnen, noch lassen sie sich einzeln aufsummieren. So kann es zwei
Algorithmen geben, die Entitäten in einem Text mit einem Recall von 50% identifizieren. Ein Algorithmus, der eine Relation zwischen diesen beiden Entitäten
37
2. Grundlagen
finden soll, kann trotzdem einen Recall von über 50% haben. Die wenigen gefundenen Entitäten der erste beiden Algorithmen könnten genau die richtigen sein,
die in den gesuchten Relationen vorkommen. Die gleiche Argumentation gilt für
die beiden anderen Gütemaße. Es gibt außerdem im Allgemeinen einen Trade-Off
zwischen Recall und Precision [BG94]. Dies bedeutet, dass es normalerweise nicht
möglich ist, einen Recall- und Precision-Wert von 100% zu haben.
Accuracy Ein weiteres Gesamtmaß für die Effektivität eines Algorithmus ist die
Accuracy. Die Accuracy A misst den Anteil der korrekten Entscheidungen eines
Algorithmus in Bezug zu allen seinen Entscheidungen [JDH99].
A=
TP + TN
TP + TN + FP + FN
Recall und Precision werden immer dann angewendet werden, wenn ein Algorithmus nur kleine Teile eines Textes, etwa Unternehmensentitäten, annotiert
und damit identifiziert. Sie beziehen sich damit nicht auf alle Möglichkeiten der
Annotation in einem Text. Dies wird vor allem dadurch deutlich, dass die True
Negatives, also alles was weder von Hand noch von einem Algorithmus annotiert
wurde, bei ihnen nicht auftauchen. Demgegenüber lässt sich die Accuracy immer
dann anwenden, wenn ein Algorithmus praktisch alle Teile eines Textes annotiert.
Dies ist zum Beispiel beim Zerlegen eines Textes in Sätze, oder beim Zerlegen der
gefundenen Sätze in einzelne Tokens der Fall. Ebenso wenig wie Recall, Precision
oder F-Measure lässt sich die Accuracy von verschiedenen Algorithmen aufsummieren. Das Argument ist das gleiche wie bei den anderen Effektivitätsmaßen.
Trotz einer hohen Accuracy kann es sein, dass genau die Textstellen nicht richtig
annotiert wurden, die für einen nachfolgenden Algorithmus relevant sind.
Labeled Attachment Score Der Labled Attachment Score wird für eine spezielle
Klasse von Algorithmen genutzt. Diese Algorithmen sind sogenannte Dependency
Parser. Ein Dependency Parser versucht in einem Satz die Beziehungen der einzelnen Wörter untereinander herauszufinden. So werden nicht nur Teile wie Subjekt
oder Objekt markiert, sondern auch die Beziehung der einzelnen Wörter zueinander in einer baumartigen Struktur festgehalten. Das Prädikat des Satzes kann so
zum Beispiel eine Kante in der Baumstruktur zum Subjekt und Objekt des Satzes
haben. Um die Gesamteffektivität eines Dependency Parsers festzustellen, wird
zum Beispiel der Labeled Attachment Score genutzt [NHK+ 07]. Der Wert drückt
aus, wie viele richtige Beziehungen und richtige Markierungen der Parser liefert.
Die Werte lassen sich nicht aufsummieren aus den gleichen Gründen, wie etwa
schon beim Recall.
38
Effizienzmaße
Die Effizienz eines Algorithmus wird üblicherweise in seinem Laufzeitverhalten
bezüglich Geschwindigkeit und Speicherplatzverbrauch ausgedrückt. In [WSE11]
werden dafür die speziellen Maße Average Sentence Response Time, Averaged Efficiency und Averaged Efficiency at Effectiveness für den Bereich Information
Extraction bezüglich der Geschwindigkeit eines Algorithmus vorgeschlagen. Diese
Effizienzmaße gehen nicht von der asymptotischen Laufzeit eines Algorithmus aus.
In der IE arbeiten die meisten Algorithmen satzweise. Daher ist hier vor allem die
durchschnittliche Antwortzeit pro Satz eines Algorithmus von Interesse [WSE11].
Average Sentence Response Time Die Average Sentence Response Time gibt
die durchschnittliche Antwortzeit pro Satz t(A) von einem Algorithmus A auf
einem bestimmten Hard- und Softwaresystem an.
t(A) = TD (A)/n
Hierbei bezeichnet D eine Reihe von Texten mit n Sätzen und TD (A) die Gesamtzeit, die der Algorithmus A für diese Textmenge braucht.
Averaged Efficiency Ein Problem mit der durchschnittlichen Antwortzeit pro
Satz ist, dass dieser Wert sehr stark von dem verwendeten System, den Datenstrukturen usw. abhängt, auf dem der Algorithmus ausgeführt wird. Daher müssen
die Zeiten normalisiert werden. Hierfür hat [WSE11] die durchschnittliche satzbezogene Antwortzeit t(A0 ) eines Algorithmus A0 zur Tokenisierung genommen. Ein
Tokenisierer wird für das Lösen von fast allen IE-Aufgaben benötigt. Deswegen
geht [WSE11] davon aus, dass hierfür ein effizienter Algorithmus zur Verfügung
steht, der für eine Normalisierung der Laufzeiten genutzt werden kann. Die sogenannte Averaged Efficiency tN (A) für einen Algorithmus A kann dann folgendermaßen angegeben werden:
tN (A) =
t(A)
t(A0 )
Damit lässt sich dann für eine gegebene IE-Pipeline Π, die eine IE-Aufgabe mit
einer Effektivität E löst, und einem Algorithmus zur Tokenisierung A0 die sogenannte Averaged Efficiency at Effectiveness folgendermaßen angeben:
F@E =
t(Π)
t(A0 )
39
3 Stand der Technik
In diesem Kapitel soll der aktuelle Forschungsstand in den einzelnen für diese
Arbeit wichtigen Bereichen vorgestellt werden. Orientiert wird sich dabei am Titel der Arbeit: Entwicklung eines Expertensystems zur automatischen Erstellung
effizienter Information-Extraction-Pipelines. Begonnen wird daher mit einer Übersicht über den Bereich Expertensysteme (Abschnitt 3.1). Da in der vorliegenden
Arbeit das Ziel gesetzt wurde, ein Expertensystem zu erstellen, werden hier einige
Vertreter aus den in Abschnitt 2.1.1 aufgezählten Aufgabenbereichen der Expertensysteme aufgeführt. Dabei sollen vor allem die unterschiedlichen Problemfelder
für Expertensysteme aufgezeigt, aber auch sich in dieser Arbeit wiederfindende
Aspekte identifiziert werden. Effiziente Information-Extraction-Pipelines sind das
zweite Thema dieses Kapitels (Abschnitt 3.2). Hier werden Arbeiten vorgestellt,
die sich damit befassen, wie Aufgaben der Information Extraction effizient durchgeführt werden können, was vor allem bei sehr großen Dokumentenmengen, wie
sie zum Beispiel im World Wide Web vorkommen, eine hohe Relevanz hat. Die
Ansätze erfahren dabei auch eine Abgrenzung zu dem in dieser Arbeit gewählten
Weg für effiziente Information-Extraction-Pipelines. Der letzte Teil dieses Kapitels geht dann auf Arbeiten ein, die sich mit der automatischen Konstruktion von
Information-Extraction-Pipelines befassen (Abschnitt 3.3). Dabei wird unterteilt
in Arbeiten aus dem Umfeld der Information Extraction und ähnliche Arbeiten
aus anderen Bereichen, vorwiegend aus dem Bereich der automatischen Zusammensetzung von Web Services. Es werden Gemeinsamkeiten und Unterschiede zwischen den Problemen, den gewählten Lösungen und den in dieser Arbeit verfolgten
Ansätzen dargelegt.
3.1 Übersicht über existierende Expertensysteme
Als eines der ersten Expertensysteme überhaupt gilt das in [BS84] beschriebene
MYCIN. Das originale MYCIN Expertensystem wurde Anfang der 1970er Jahre
entwickelt. Es ist ein System zur Diagnose von Krankheiten. In seiner Anfangszeit bestand es aus einer einfachen, regelbasierten Wissensbasis. In einer FrageAntwort-Sitzung ermittelte das System die benötigten Fakten. Auf Basis dieser
Fakten stellte es eine Diagnose, die es bei Bedarf auch anhand der vorhandenen
Wissensbasis begründen konnte.
Regelbasierte Expertensysteme sind bis in die heutige Zeit sehr häufig anzutreffen. In [CSL+ 03] wird eine Regelbasis für die Spektroskopie benutzt. Bei der
Spektroskopie geht es um die Untersuchung von Strahlung verschiedener Objekte,
41
3. Stand der Technik
um deren chemische Zusammensetzung zu bestimmen. Die Regeln steuern dabei Algorithmen, die spezifische spektrale Merkmale untersuchen und dem System damit bei seiner Diagnose helfen. Ein regelbasiertes Expertensystem mit
dem Einsatzzweck der Klimavorhersage in der Region des Nordatlantik wird in
[RM99] vorgestellt. Die Wissensbasis umfasst 400 empirisch ermittelte und mit
Konfidenzfaktoren versehene klimatische Regeln.
Im Bereich der Vorhersage und Simulation wird des Öfteren eine Fuzzy-Regelbasis verwendet, die es erlaubt, auch vages Wissen, welches eventuell von einem Experten nicht näher formalisiert werden kann, auszudrücken. So benutzt [KPHK95]
ein Fuzzy-Regelsystem zur Vorhersage des Stromverbrauchs eines Stromnetzwerks.
Das Fuzzy-Regelsystem berücksichtigt bei der Stromlastberechnung Faktoren, wie
zum Beispiel die aktuelle Temperatur und auch Informationen über die Schulferienzeit. Ebenfalls ein Fuzzy-Regelsystem wird in [MHF03] für die Vorhersage der
Schmelzwassermenge in einer Bergregion im Frühjahr, wichtig für die Berechnung
der Trinkwasserversorgung in der entsprechenden Region, benutzt. Vorher wurden
die anfallenden Berechnungen manuell von Experten erledigt. Das so vorhandene Expertenwissen war oft ungenau und vage. Daher entschloss man sich beim
Aufbau des Expertensystems auf Fuzzy-Regeln zu setzen.
Neben den Aufgabengebieten der Analyse und Simulation ist die Konstruktion
das für diese Arbeit wichtigste Problemfeld von Expertensystemen (vgl. hierzu
Abschnitt 2.1.1). In [FS84] wird ein Expertensystem für die Konstruktion von
Schedules in der Domäne Job-Scheduling betrachtet. Das System benutzt für
die Wissensrepräsentation Frames. Anhand dieser Wissensbasis wird dann eine
mehrstufige Constraints-basierte Suche durchgeführt, um die Schedules zu erstellen. Hierbei gilt es einen möglichen Schedule zu konstruieren, welcher bestimmte
Randbedingungen wie Resourcenverbrauch, Kostenschranken oder die Verfügbarkeit von Maschinen berücksichtigt.
In der Arbeit von [Law08] wird ebenfalls ein System für die Produktionsplannung und das Maschinenscheduling aufgezeigt. Als erstes wird hier mithilfe eines in
der logischen Programmiersprache PROLOG erstellten Expertensystems, welches
in nicht eigenständig entscheidbaren Situationen Rücksprache mit einem menschlichen Experten hält, ein Produktionsplan für Maschinen entworfen. Anschließend
wird ein genetischen Algorithmus benutzt, um das Scheduling für die im Plan
aufgezeigten Maschinen und eine Reihe von Randbedingungen zu bestimmen. Die
Trennung des Problems in die beiden Bereiche Planung und Scheduling kann als
Parallele zu dieser Arbeit gesehen werden, denn hier wird für die Konstruktion der
IE-Pipeline auch zuerst eine allgemeine Planung der Pipeline gemacht und darauf
aufbauend dann ein optimierter Schedule für diese Pipeline bestimmt. Allerdings
unterscheiden sich nicht nur die dafür eingesetzten Verfahren (in der vorliegenden
Arbeit wird ein Partial Order Planner zur Planung eingesetzt). Auch die Domänen
sind vollkommen verschieden und die Probleme und Lösungen lassen sich so nicht
ohne weiteres aufeinander übertragen.
Die Raumsonde DeepSpaceOne[MNPW98] wurde bereits in Abschnitt 2.1.2
erwähnt. In dieser Sonde werden viele verschiedene Expertensystemen zur Un-
42
3.1 Übersicht über existierende Expertensysteme
terstützung der Planungskomponente des Gesamtsystems verwendet. Die Planungskomponente liefert Pläne für kurzfristige Ziele, zum Beispiel das Fotografieren von Objekten, und langfristige Ziele, zum Beispiel Ziele der Navigation,
der Sonde. Die einzelnen Expertensysteme werden von der Planungskomponente für bestimmte Fragen konsultiert, etwa liefert das Navigationsexpertensystem
Informationen und auch neue in den Plan einzubauende Ziele hinsichtlich des Antriebsschubs der Hauptantriebsmaschine.
Neben der Einordnung des in der vorliegenden Arbeit entwickelten Expertensystems in den Bereich der Konstruktion und der verwendeten Methoden bezüglich
der Planung der IE-Pipeline ist die Wissensbasis in Form einer Ontologie ein
weiteres Merkmal, welches von verschiedenen Expertensystemen in der Literatur
geteilt wird. In [SCS09] wird ein Expertensystem vorgestellt, von dem die finanziellen Jahresabschlüsse in Unternehmen bewertet werden können. Die Wissensbasis
besteht aus einer Ontologie, welche die Elemente der Domäne der Buchhaltung
von Jahresabschlüssen beschreibt. Die Ontologie wird mit dem Ontologiewerkzeug
Protégé entwickelt, welches auch in der vorliegenden Arbeit zum Einsatz kommt.
Eine Regelbasis in JESS (Java based Expert System Shell [FH03]), ein Framework
zur Erstellung von regelbasierten Expertensystemen in Java, benutzt das in der
Ontologie vorhandene Wissen, um die im Unternehmen erstellten Jahresabschlüsse
zu bewerten.
Eine moderne Form von MYCIN wird in [PGJ08] beschrieben. Das System
benutzt als Wissensbasis, genau wie diese Arbeit, eine OWL-Ontologie. Erweitert
wird diese Ontologie mit den in Abschnitt 2.2.2 erwähnten SWRL Regeln. Die
Ontologie selbst besteht vollständig aus Sub- und Superklassenbeziehungen. Sie
ist also eine Taxonomie. Hierdurch versuchen die Autoren das Reasoningproblem
zu vereinfachen.
Auch in [BDGRL09] wird eine OWL-Ontologie als Wissensbasis verwendet. Die
Domäne des dort entwickelten Expertensystems sind die Balanced Scorecards. Dies
ist ein Konzept zur Messung und Steuerung der Aktivitäten und Strategien von
Unternehmen. Als Inferenzmechanismus wird ein Fuzzy-Regelsystem eingesetzt.
Damit ist es möglich in den Berichten auch vages Wissen einzusetzen.
Ein umfangreicheres Expertensystem wird in [CAO+ 08] vorgestellt. Mithilfe dieses Systems können sich Touristen für eine Stadtreise einen Plan erstellen lassen.
Dabei wird zum Beispiel der Benutzerwunsch, ein Museum zu besuchen, berücksichtigt. Außerdem werden mögliche Transportmittel wie Taxis oder öffentliche
Verkehrsmittel, mit denen man sich zwischen den im Plan angegebenen Orten bewegen kann, in den Plan eingefügt. Alle Benutzerdaten und Informationen über
Sehenswürdigkeiten und Verkehrsmittel der Städte stehen dabei in einer Ontologie als Wissensbasis zur Verfügung. Diese Ontologie wird sowohl per Hand mittels
Protégé gepflegt, als auch automatisch mittels sogenannter Wrapper, die Informationen von Web Services oder Webseiten bereitstellen und in die Ontologie
einfügen. Aus ihr wird ein CLIPS (C Language Integrated Production System) 1 Sy1
http://clipsrules.sourceforge.net/
43
stem generiert und mittels der Sprache LISP angesprochen. Anhand der Informationen aus der Ontologie erstellt ein Planer einen Schedule der Sehenswürdigkeiten
und einen Transportplan, wie der Tourist von einer Sehenswürdigkeit zur nächsten
kommen kann. Als Planer werden verschiedene Standard-Planer eingesetzt (FF
[HN01], Metric-FF [Hof03], IPSS [RMBCO07] und SIADEX [CFoGpP06]).
Neben der Verwendung einer Ontologie als Wissensbasis, ist vor allem die Art
des Wissenserwerbs eine Parallele zur vorliegenden Arbeit. So wird auch von der
vorliegenden Arbeit für das manuelle Einpflegen von Wissen Protégé genutzt.
Ebenfalls werden Komponenten eingesetzt, die vorliegende Informationen des verwendeten IE-Frameworks automatisch in die Ontologie übertragen.
Dieser Abschnitt kann keinen vollständigen Überblick über die Vielzahl an
verschiedenen vorhandenen Expertensystemen bieten. Er sollte jedoch Beispiele
aufführen, die in bestimmten Aspekten dem in dieser Arbeit verfolgtem Ansatz
ähneln. Ein direkt vergleichbares Expertensystem, das dem Zweck dient, eine IEPipeline zu konstruieren ist dem Autor allerdings nicht bekannt. Jedoch werden
im noch folgenden Abschnitt 3.3 einige Softwaresysteme vorgestellt, die dieses
oder ein ähnliches Ziel sehr wohl zu erreichen versuchen, von sich selbst aber
nicht behaupten, ein Expertensystem zu sein. Für eine Übersicht über verschiedene Expertensysteme ab Mitte der 1990er Jahre bis zum Jahr 2005 sei auf [Lia05]
verwiesen.
3.2 Effiziente Information-Extraction-Pipelines
In ihrem Überblick über den Bereich und die Forschung in Information Extraction führen [Sar08] unter anderem Aspekte zur Steigerung der Performanz von
IE-Systemen auf. Bei einer großen, nicht abgeschlossenen Dokumentenmenge, wie
sie zum Beispiel in Form des World Wide Web existiert, muss vor der eigentlichen
Untersuchung der Dokumente zuerst eine Filterung der für relevant erachteten
Dokumente erfolgen. Das IE-System soll sich auch innerhalb der Dokumente nur
auf die relevanten Textstellen konzentrieren. Als Beispiel wird ein Zitationssystem genannt, für welches es sinnvoll erscheint, nur den Dokumentkopf und das
Literaturverzeichnis als Textstellen zu untersuchen. Erst als Letztes wird dann
die Optimierung der Extraktion selbst zur Steigerung der Gesamtperformanz in
Erwägung gezogen. Für IE-Systeme, die auf einer offenen, großen Menge an Dokumenten ausgeführt werden sollen, empfehlen die Autoren eine weitere Optimierungsmöglichkeit. In solch einem Fall sollen nicht mehr die kompletten Texte
untersucht werden, sondern nur noch die Teile, welche sich seit der letzten Untersuchung auch wirklich geändert haben.
Auch für die vorliegende Arbeit wird die Methode des Filterns von unrelevanten Textstellen eingesetzt (vgl. Abschnitt 2.4.2). Außerdem wird in dieser Arbeit
eine Constraints-basierte Filterung durchgeführt, dass heißt Einschränkungen von
Benutzerseite (etwa nur Entitäten, die mit G beginnen zurück liefern“) werden
”
direkt in die IE-Pipeline eingebaut und damit auch während des IE-Prozesses
44
3.2 Effiziente Information-Extraction-Pipelines
berücksichtigt. Das Filtern vollständiger Dokumente in großen Dokumentenbasen liegt außerhalb des Aufgabenbereichs dieser Arbeit und ist eher als eine eigenständige IE-Aufgabe zu sehen. Ebenfalls steht das Finden von sich veränderten
Textstellen in sich dynamisch ändernden Dokumentenbasen nicht im Fokus dieser
Arbeit. Es könnte allerdings später als Vorprozess im Expertensystem integriert
werden. Mit dem Optimieren der Effizienz von einzelnen IE-Verfahren beschäftigen sich ebenfalls andere Arbeiten und nicht diese.
Auch in [Agi05] wird als Problem identifiziert, dass IE-Technologien ohne Optimierungen zu langsam sind für das Bearbeiten von großen Dokumentenbeständen.
Selbst bereits gut erforschte und demnach optimierte IE-Aufgaben, wie zum Beispiel das Part of Speech Tagging, könnten mit einer größeren Menge an Text
und einem einzelnen Computer mehrere Jahre beschäftigt sein. Der Autor stellt
vier Ansätze vor, mit denen ein IE-System beschleunigt werden kann. Die erste Möglichkeit besteht darin, die IE-Algorithmen anzupassen und einfachere und
effizientere Regeln bei der Untersuchung der Texte einzusetzen. Die nächste vorgeschlagene Möglichkeit sieht der Autor, wie auch [Sar08], in einer Filterung der
zu analysierenden Texte. Ein erster Ansatz kann hier der Einsatz einer gewöhnlichen Suchmaschine sein, um relevante Texte zu finden und nur diese dann weiter
zu verarbeiten. Eine darüber hinausgehende Möglichkeit bietet der Einsatz von
spezialisierten Suchmaschinen, die einen Spezialindex für die schon in einem Text
gefundenen Annotationen benutzen. Dadurch können die IE-Verfahren auf vorherigen Analysen aufbauen und auch der Zugriff auf diese Informationen wird
beschleunigt. Als letzte Möglichkeit führt der Autor dann noch das verteilte, parallele Verarbeiten der Textmenge an. Gleichzeitig warnt der Autor aber auch vor
der Gefahr, dass Vollständigkeit und Genauigkeit der IE-Verfahren durch die ersten beiden beschriebenen Ansätze gesenkt werden könnten und dass der Rückgriff
auf bereits annotierte Informationen eine Anpassung der IE-Verfahren erfordert.
In der vorliegenden Arbeit wird keines der von [Agi05] vorgeschlagenen Verfahren zur Effizienzsteigerung genutzt. Die direkte Anpassung der einzelnen IEVerfahren liegt, wie schon erwähnt, außerhalb des Fokus dieser Arbeit. Der Einbezug einer Suchmaschine zum Auffinden von relevanten Texten wird ebenfalls
nicht betrachtet. Hier liefert der Benutzer des Expertensystems die zu untersuchende Textmenge. Allerdings könnte solch ein Verfahren relativ einfach als eigener
Vorauswahlprozess in das Expertensystem integriert werden. Diese Arbeit verfolgt
auch nicht die Ziele der Speicherung der generierten Informationen. Daher ist auch
der Aufbau eines speziellen Suchindizes nicht Teil dieser Arbeit. Die Integration
dieses Ansatzes wäre nicht trivial, da dazu auch die verwendeten IE-Verfahren
angepasst werden müssten.
Eine Anwendung der eben vorgestellten Optimierungsmöglichkeiten bei IESystemen bietet [PNLH09]. Dort wird das AliBaba System als ein skalierbares
IE-System für biomedizinische Dokumente vorgestellt. Wie schon von [Sar08] beschrieben, verwendet Alibaba die Suchmaschine PubMed zur Vorauswahl der relevanten Dokumente. Eine weitere Optimierung stellt ein effizienter, auf Mustern
basierter Ansatz zur Bestimmung von Relationen dar. Dieses Verfahren soll schnel-
45
ler sein als vergleichbare Verfahren, die auf maschinellem Lernen basieren.
Auch [WSE11] setzt bei der Effizienzsteigerung des IE-Systems auf das Filtern
von Text, damit nur auf den relevanten Passagen die IE-Verfahren angewendet
werden. Allerdings wird der Text nicht vorgefiltert, sondern die Filterung passiert direkt in der IE-Pipeline hinter jeder einzelnen IE-Analysephase. Es werden
darüber hinaus noch andere Paradigmen eingeführt, die ebenfalls der Effizienzsteigerung dienen, wie bereits in Abschnitt 2.4.2 erläutert. Die vorliegende Arbeit
greift diese Konzepte auf und setzt sie im Expertensystem um. Darüber hinaus
versucht diese Arbeit die Konzepte in einem automatisierten Verfahren unterzubringen und erweitert den Ansatz um das automatische Erstellen von IE-Pipelines
anhand von vom Benutzer spezifizierten, gewünschten Informationen unter Verwendung einer Ontologie.
Einen anderen Ansatz der Erhöhung der Effizienz in IE-Systemen zeigt [KLR+ 09]
auf. Hier wird mit SystemT ein auf Effizienz optimiertes IE-System vorgestellt.
Das regelbasierte Vorgehen anderer Ansätze wird dort durch eine optimierte, deklarative Sprache ersetzt. Ähnlich der SQL aus der Datenbankwelt können in
dieser Sprache Anfragen an das System gestellt und so eine höhere Skalierbarkeit
und Effizienz des IE-Systems erreicht werden. Dabei werden mit dem Einsatz von
auf regulären Ausdrücken und auf Wörterbüchern basierten Verfahren allerdings
keine auf maschinellen Lernen basierenden IE-Verfahren in dieser deklarativen
Sprache unterstützt. Daher ist dieses System so nicht für auf maschinellen Lernen
basierenden IE-Verfahren einsetzbar. Da damit der Einsatz dieses Ansatzes mit
einer Neuimplementierung großer Teile der IE-Verfahren einhergehen würde, kann
er in der vorliegenden Arbeit nicht betrachtet werden.
Ein IE-System mit einer ähnlichen deklarativen Sprache als Ausgangspunkt
ist das in [CGD+ 09] vorgestellte Delex. Die einzelnen existierenden IE-Verfahren
werden als IE Blackboxes aufgefasst, die dann von einer xlog genannten, Datalogähnlichen Sprache zusammengebracht werden.2 Das Delex-System soll vor allem in
dynamischen Dokumentenmengen hohe Effizienzsteigerungen bringen. Dies liegt
in der Verwirklichung von den in [Sar08] und [Agi05] vorgeschlagenen Ansätzen
der Wiederverwendung von bereits gefundenen Informationen, indem man die Untersuchung des Textes auf nur die Textstellen beschränkt, die sich seit der letzten
Untersuchung auch wirklich geändert haben. Die Unterbringung eines solchen Ansatzes in der vorliegenden Arbeit liegt, wie weiter oben bereits ausgeführt, außerhalb des Aufgabenbereichs dieser Arbeit. Der Einsatz einer deklarativen Sprache
wie xlog bietet die Möglichkeit, auch auf maschinellem Lernen basierenden Verfahren einzusetzen. Allerdings sind hierfür trotzdem noch größere Anpassungen
an diesen bereits bestehenden Verfahren durchzuführen, sodass diese Arbeit einen
solchen Ansatz nicht in Betracht ziehen kann. Ähnliche, auf deklarativen Ansätzen
beruhende Ansätze, finden sich außerdem in [CVDN09] und [SDNR07].
In vielen anderen Arbeiten wird vor allem die auch in [Sar08] und [Agi05] besprochene Anpassung und Optimierung der einzelnen IE-Verfahren in den Vor2
Für Informationen über Datalog siehe zum Beispiel [CGT89].
46
dergrund gestellt. So zeigt [BCS+ 07] ein allgemeines Verfahren für die schnelle
Extraktion von Relationen auf, welches allerdings nicht die in Abschnitt 2.4 angesprochenen Ereignisse erkennen kann, und dabei auch das schon besprochene
Speichern und Wiederverwenden von bereits gefundenen Informationen einsetzt.
In [Cur03] wird eine performante Plattform für allgemeine NLP-Verfahren vorgestellt, wobei die hohe Effizienz vor allem in der Neuentwicklung von effizienten,
einzelnen NLP-Verfahren erklärt werden kann. In [HHF+ 10] wird eine IE-Pipeline
zum Identifizieren von ökonomischen Ereignisse in Nachrichtenartikeln vorgestellt.
Die hohe Effizienz der angegebenen Pipeline ist ebenfalls auf die Entwicklung von
speziellen, effizienten IE-Verfahren für die zu lösende IE-Aufgabe zurückzuführen.
Wie bereits oben gesagt, steht allerdings die Neuentwicklung von effizienten IEVerfahren nicht im Fokus der vorliegenden Arbeit. Daher sollen die genannten
Arbeiten nur als Beispiele für eine aktive Forschung in dieser Richtung gesehen
werden.
3.3 Automatische Konstruktion von
In Abschnitt 3.1 wurde schon gesagt, dass dem Autor dieser Arbeit kein Expertensystem bekannt ist, welches mit dem in dieser Arbeit entwickelten System
vergleichbar ist. Dies wurde auch dahingehend eingeschränkt, dass es gleichwohl
Systeme gibt, die einen ähnlichen Aufgabenbereich, wie die automatische Konstruktion von IE-Pipelines haben, sich selbst aber nicht als Expertensysteme bezeichnen. Solche Systeme sollen in den folgenden Abschnitten vorgestellt werden.
Dazu werden als erstes Arbeiten aus dem Umfeld der Information Extraction betrachtet. Im zweiten Abschnitt werden Arbeiten aus anderen Bereichen vorgestellt,
die sich in Teilen auch mit den Ansätzen der vorliegenden Arbeit vergleichen lassen.
3.3.1 Im Umfeld Information Extraction
In [DDM05] beschreiben die Autoren ein System, welches ausgehend von einer
Anfrage an das System automatisch eine IE-Pipeline erstellt, um durch Information Extraction die Arten von Informationen zu finden, die in der Anfrage verlangt
sind. Die IE-Algorithmen werden von den Autoren als Document Analyzer -Module
bezeichnet. Diese Module arbeiten auf einem Austauschformat, den sogenannten
typisierten Views. Views sind spezielle XML-Dokumente, welche eine bestimmte
Sicht auf die gefundenen Informationen besitzen. Die im Laufe der Ausführung
der IE-Pipeline erstellten Views stellen dann die Ausgabe des Systems dar. Die
Konstruktion einer IE-Pipeline wird mit einem eigens dafür entwickelten Partial
Order Planner gelöst.
Die Autoren haben bei der Entwicklung des Planers wichtige Vereinfachungen
erkannt, die der Einsatz in der Domäne Information Extraction mit sich bringt.
47
Die einmal produzierten Views können nicht wieder zerstört werden. Dadurch gibt
es in ihrem Planungsproblem keine negativen Literale. Dies vereinfacht den Partial
Order Planner erheblich, denn damit brauchen bei seiner Implementierung auch
keine kausalen Links beachtet zu werden, da diese nie gefährdet werden können.
Ein Problem in der Domäne IE, welches die Autoren beschreiben, ist, dass es
verschiedene Algorithmen für die gleiche IE-Aufgabe geben kann, die sich aber
unterschiedlich verhalten. Als Lösung wird die nebenläufige Ausführung dieser
Algorithmen präsentiert, wobei ein spezielles Modul für die Zusammenführung
der gelieferten Ergebnisse zuständig ist.
Die Arbeit weist starke Parallelen zu der vorliegenden Arbeit auf. So wird ebenfalls ein Partial Order Planner zum Finden einer IE-Pipeline eingesetzt. Allerdings
gehen die Autoren von [DDM05] nicht auf das Thema Effizienz ein. Außerdem verlangen sie mit ihrem View-basierten System, dass die einzelnen IE-Verfahren in
einer einheitlichen, auf die View setzenden Form vorliegen. Dies bringt erhebliche Anpassungen an den zu Verfügung stehenden IE-Verfahren mit sich. Weiterhin kann die DOM-basierte XML-Struktur der Views negative Auswirkungen auf
die Gesamtperformanz des Systems, vor allem in Speicherhinsicht, haben. Welche
Auswirkungen dies genau haben könnte, wird nicht offen gelegt, da in der Arbeit nur das Konzept, aber keine Implementierung oder Evaluierung, beschrieben
wird. Ebenfalls nicht ersichtlich ist, woher die Informationen über die einzelnen
IE-Verfahren kommen. Die vorliegende Arbeit verwendet hierfür Ontologien. Allerdings lassen sich die vorgeschlagenen Optimierungen des Partial Order Planners
direkt im Konzept und der Umsetzung in der vorliegenden Arbeit finden.
In der Arbeit [ŽKŽL08] werden im Bereich des Data Mining Workflows automatisch vom Computer konstruiert. Die Algorithmen und Aufgaben im Bereich
des Data Mining unterscheiden sich von denen der Information Extraction. Allerdings gibt es bei dem Problem der automatischen Konstruktion von Workflows im
Bereich Data Mining und der automatisierten Erstellung von IE-Pipelines einige
Gemeinsamkeiten. Die Autoren in [ŽKŽL08] nutzen eine Ontologie über Daten
und Algorithmen des Data Mining und einen Planer zum Planen der Workflows.
Zum Beispiel enthält die Ontologie Informationen darüber, welche Art von Wissen
ein Algorithmus produziert und welche Vorinformationen er dafür benötigt. Die
Ontologieform ist eine OWL-DL-Ontologie. Die Gründe dafür seien ausreichende
Ausdrucksmöglichkeiten, Modularität, vorhandene Werkzeugunterstützung, bereits optimierte Schlussfolgerungswerkzeuge für diese Art der Ontologie und eine
große Anzahl an Personen, die sich bereits mit dieser Ontologie beschäftigten.
Die Aufgabe der automatischen Bestimmung eines Workflows ist von den Autoren in drei Teilaufgaben zerlegt worden. Zuerst wird die Aufgabe des Data Mining unter Bezugnahme auf die Elemente der Ontologie in ein Planungsproblem
in PDDL-Form übersetzt. Als zweites wird das kodierte Planungsproblem dann
an einen auf FF-basierenden Planer übergeben. Dieser erstellt daraufhin einen
Plan, der einen abstrakten Workflow beschreibt. Der letzte Schritt ist aus diesem abstrakten Plan einen konkreten Plan zu erstellen (die Autoren nennen dies
Konfigurieren des Plans, ohne auf diesen Schritt näher einzugehen).
48
Dieser Vorgang ist nur als Konzept beschrieben und nicht evaluiert. Auch wird
nicht beschrieben, wie die eigentliche Aufgabe des Data Mining spezifiziert wird,
also wie der Benutzer Eingaben in das System tätigt. Effizienz ist kein Kriterium in
der angesprochenen Arbeit. Der vorgestellte Planungsalgorithmus liefert am Ende
den kürzesten gefundenen Plan zurück. In der Domäne Information Extraction
wäre dies aber nicht ausreichend, da es, wie in der vorliegenden Arbeit gezeigt,
verschieden effiziente und effektive Verfahren für die gleichen IE-Aufgaben gibt
und daher eine kürzeste IE-Pipeline nicht unbedingt einer optimalen (bezüglich
Effizienz und Effektivität) IE-Pipeline entsprechen muss. Die Begründung für die
Verwendung einer OWL-DL-Ontologie wird auch von der vorliegenden Arbeit geteilt. Außerdem lässt sich eine Parallele bei der Betrachtung von abstrakten und
konkreten Workflows finden. So wird auch in der vorliegenden Arbeit zuerst eine
abstrakte IE-Pipeline konstruiert, die dann von einer speziell auf das verwendete
IE-Framework zugeschnittenen Komponente in eine konkrete Pipeline übertragen
und dann ausgeführt wird.
Ihre Arbeit von [ŽKŽL08] führen die Autoren in [ŽKŽL11] fort. Sie verallgemeinern hier die bisherige Aufgabe, indem sie nun eine automatische Zusammenstellung eines Knowledge Discovery Workflows beschreiben. Ein Knowledge Discovery
Workflow wird von ihnen als eine Reihe von Schritten definiert, um aus spezifischen
Daten (wie zum Beispiel Messungen) Muster abzuleiten, die neues Wissen über
die betrachtete Problemdomäne darstellen. Dazu wird Wissen aus einer Ontologie
verwendet und mithilfe eines Planers der Workflow bestimmt.
Das Hauptziel der Arbeit besteht damit darin, zu untersuchen, ob die Workflows
mit der Hilfe einer Ontologie des Knowledge Discovery und eines Planungsalgorithmus erstellt werden können. Der Planer akzeptiert Aufgabenbeschreibungen
in PDDL, die automatisch mit dem Vokabular der Ontologie generiert werden.
Hierfür haben die Autoren zuerst eine Ontologie mit 150 Klassen entwickelt, welche
komplexes Hintergrundwissen und Wissen über die Algorithmen enthält. Außerdem versuchen sie, eine einheitliche Theorie (eine Konzeptualisierung) von Data
Mining und Knowledge Discovery in der Ontologie zu entwickeln. Dazu besteht
die Ontologie aus den Beschreibungen der Algorithmen und den deklarativen, verschiedenen Wissensrepräsentationen.
Für die Planung wird wiederum ein FF-basierter und auf PDDL arbeitender
Planer gezeigt. Der Planungsalgorithmus wird dabei mehrfach gestartet, um mehrere relevante Workflows zu bekommen. Die PDDL Beschreibung wird vor dem
Planen aus der Ontologie erzeugt. Während des Planens wird die Ontologie nicht
gebraucht. Zusätzlich gibt es noch einen anderen Planer, der mögliche nächste
Schritte direkt aus der Ontologie schlussfolgert, mit dem Einsatz des Reasoners
Pellet (vgl. Abschnitt 2.3.1). Dazu werden in jedem Schritt die Vorbedingungen
der möglichen Aktionen mit den gerade erfüllten Bedingungen abgeglichen und
dann die nächste Aktion ausgewählt. In der Evaluierung wird gezeigt, dass der erste, auf FF basierende Planer gut mit der Anzahl an möglichen Aktionen skaliert.
Der zweite Planer, der Reasoning während des Planens einsetzt, skaliert wesentlich
schlechter mit der Größe der verwendeten Ontologie.
49
Im Vergleich mit der vorliegenden Arbeit ergeben sich eine Reihe von Unterschieden. Zuerst natürlich die verschiedenen Domänen Knowledge Discovery und
Information Extraction. In IE wird auf natürlichsprachigem Text gearbeitet. Die
Autoren der genannten Arbeit definieren die Domäne aber als Arbeiten auf spezifischen Daten. Dabei werden bei der Bestimmung des Workflows auch keinerlei
Qualitätsmetriken für die Auswahl der einzelnen Algorithmen benutzt. Der Planer gibt mehr als einen Workflow zurück, allerdings fehlt die Begründung warum
er dies macht. Er ist außerdem ein Standardplaner bei dem kein domänenspezifisches Wissen eingesetzt wird. Die Evaluierungsergebnisse des zweiten eingesetzten
Planers, welcher auf Basis von Pellet Entscheidungen trifft, zeigen, dass ein komplettes Schlussfolgern auf einer komplexen Ontologie zu langsam sein kann. Wie
sich später noch zeigen wird, wird die vorliegende Arbeit nicht den Versuch unternehmen, eine einheitliche Konzeptualisierung der Domäne IE durchzuführen.
Außer der erstgenannten Arbeit sind dem Autor weitere Arbeiten zur automatischen Erstellung von IE-Pipelines nicht bekannt. Während in ähnlichen Bereichen,
wie Data Mining und Knowledge Discovery wie gezeigt Arbeiten existieren, die
die Automatisierung von Workflows zum Ziel haben, lassen sich diese nicht in allen Teilen mit der in der vorliegenden Arbeit gestellten Aufgabe vergleichen. Dies
liegt vor allem daran, dass keine der Arbeiten explizit die Effizienz der entstehenden Lösung im Sinn hat, und auch die Eigenheiten der Domäne wurden für
die Bewältigung der Aufgaben nicht genutzt. Der Einbezug von domänenspezifischem Wissen sowohl bei der Formulierung des Planungsproblems als auch bei
der Lösung dieses Problems ist etwas, was auch von [VB11] gefordert wird. Diese Arbeit bewegt sich in dem Bereich Knowledge Engineering for Planning and
Scheduling (KEPS)3 . In diesem Bereich beschäftigt man sich explizit damit, wie
das Wissen über die Struktur und Eigenarten der Domäne für die Verbesserung
der Modellierung der Planungsprobleme und der Planung selbst genutzt werden
kann.
3.3.2 Ähnliche Arbeiten aus anderen Bereichen
Das automatische Zusammensetzen von Web Services ist ein dem automatischen
Konstruieren von IE-Pipelines verwandtes Problem. So müssen in beiden zum Beispiel die Services beziehungsweise Algorithmen geeignet repräsentiert sein, was vor
allem die Bedingungen für die Ausführung, als auch die Ergebnisse und Auswirkungen dieses Ausführens betrifft. Die Web Services sollen dann, genau wie die
IE-Algorithmen, in einer Art Workflow zusammengesetzt werden, um bestimmte
Ergebnisse zu erhalten. Im Unterschied zur Domäne IE ist bei den Web Services
jedoch die Form der Repräsentation von entscheidender Bedeutung für das Auffinden von Web Services in einer verteilten Umgebung, wie dem Internet. Dies
wird auch in [RS04] gesagt, indem vor allem ein Überblick über die verschiede3
International Competition on Knowledge Engineering for Planning and Scheduling (ICEPS),
http: // icaps11. icaps-conference. org/ workshops/ keps. html
50
nen Methoden zur automatischen Web Service Zusammenstellung gegeben wird.
Ein wichtiger Bereich ist hierbei das Arbeiten mit Planungsverfahren, wie zum
Beispiel die Benutzung von PDDL, regelbasiertes Planen oder auch HTN-Planer.
Noch allgemeiner ist das Bestimmen von Workflows generell. Hier gibt es viele unterschiedliche Ansätze, die allerdings sehr oft auf der Einbindung und Benutzung
von Planern beruhen.
Workflowbestimmung von Web Services
In [SdF03] werden die einzelnen Web Services in einer DAML-S (eine für Web Services gedachte Erweiterung von dem in Abschnitt 2.2.2 erwähnten DAML+OIL)
Ontologieform festgehalten. Aus diesen Ontologiebeschreibungen werden mithilfe
von JESS Operatoren erzeugt, die dann von einem Planer genutzt werden, um
eine Zusammenstellung von Web Services für ein bestimmtes Ziel zu erstellen.
Der Planer stellt eine Eigenentwicklung dar und wird aus technischer Sicht nicht
näher beschrieben. Es lassen sich in der Arbeit wesentliche Unterschiede zu der
vorliegenden Arbeit erkennen. So wird zum Beispiel kein Wert auf die Qualität, sowohl Effektivität als auch Effizienz, der zusammengestellten Web Services gelegt.
Außerdem wird nicht erwähnt, was gemacht werden soll, wenn mehrere Web Service die gleichen Ergebnisse liefern, wie also die Entscheidungsfindung in solchen
Fällen aussieht.
In [Pee04] wird WSPlan konstruiert. Dies ist ein System, welches die in WSDL
formulierten Beschreibungen von Web Services nutzt, um daraus PDDL-Beschreibungen zu generieren. Diese Beschreibungen können dann von einem beliebigen
Standardplaner genutzt werden, um Pläne zu erstellen. Aus diesen Plänen wird
dann ein Workflow von Web Services erzeugt und ausgeführt. In der Arbeit werden
keine Ontologien verwendet, sondern eine WSDL direkt in PDDL übersetzt. Außerdem wird eine etwaige unterschiedliche Qualität der Services und die Qualität
der Gesamtzusammenstellung nicht betrachtet.
Die Arbeit [KG05] beschreibt ebenfalls ein System für die automatische Zusammenstellung von Web Services, welches PDDL benutzt. Die Beschreibungen der
Web Services liegen dabei in einer Ontologie ausgedrückt in OWL-S4 . Der verwendete Planer, XPlan genannt, basiert auf dem FF-Planer. Ein Web Service ist ein
Operator in der Planungsdomäne. Stehen mehr als ein Web Service in einem Planungsschritt als Aktion zur Auswahl, so entscheidet eine nicht näher spezifizierte
Information über die Qualität der Aktionen und die bessere wird dann genommen.
Es werden allerdings immer die kürzesten Pläne gesucht. Was in der Arbeit fehlt,
ist eine Evaluierung wie gut und wie schnell der Planer arbeitet.
In [PMBT05] liegen die Beschreibungen in einer Sprache für Geschäftsprozesse5
vor. Diese Beschreibungen werden in ein internes Wissensmodell überführt. Darauf aufbauend wird ein Planungsproblem konstruiert und mit einem eigens ent4
Spezielle Form von OWL-DL für Web Services, siehe auch http://www.w3.org/Submission/
OWL-S-related/#owl
5
BPEL4WS, http://www.ibm.com/developerworks/library/specification/ws-bpel/
51
wickelten Planungsverfahren gelöst. Dagegen legt [Dur08] sein Hauptaugenmerk
auf die Umwandlung von OWL-S- und OWL-Beschreibungen von Web Services in
PDDL-Beschreibungen, ohne einen eigenen Planer vorzustellen.
Bestimmung allgemeiner Workflows
Ganz allgemein mit dem Planen von Workflows beschäftigen sich die Autoren von
[RL06]. Diese Arbeit stellt ein Verfahren vor, wie Workflows in auf Datenstrombasierten Domänen automatisiert geplant werden können. Dazu wurde die Planungssprache SPPL (Stream Processing Planning Language) benutzt, welche eine
angepasste Form der PDDL ist. In SPPL können die zwei Metriken Kosten und
Qualität bei jeder Aktion angegeben werden. Der eingesetzte Planer beachtet diese Werte im Hinblick auf die möglichen Ziele minimale Kosten, maximale Qualität
oder maximale Qualität bei Beschränkung der Kosten. Die Datenstrom basierte
Sicht kann auch auf die IE-Domäne übertragen werden. Der SPPL-Ansatz eignet
sich für die Lösung der in der vorliegenden Arbeit vorgestellten Probleme allerdings nicht. Die Kosten eines SPPL-Plans, wie auch seine Qualität, wird in der
Arbeit als die Summe der Werte der einzelnen Aktionen definiert. Dies lässt sich so
nicht auf die IE-Domäne übertragen. Das nur ein Maß für Kosten und ein Maß für
Qualität bereitsteht ist ein weiterer Punkt, der sich nicht in die IE-Welt übertragen
lässt, denn hier stehen mit Recall und Precision mindestens zwei Qualitätsmetriken bereit, die nicht einfach aufaddiert werden dürfen, um eine Gesamtqualität
des Plans zu bestimmen (vgl. Abschnitt 2.4.3).
Noch allgemeiner ist der Ansatz der Arbeit [BFL+ 07]. Die Autoren beschreiben
ein domänenunabhängiges, allgemeines Rahmenwerk für Knowledge Engineering
und Planung. Mit diesem Rahmenwerk können Planungsdomänen und -probleme
in OWL aufgebaut werden. Der Planungsprozess wird durch Schlussfolgern auf
Beschreibungslogik (DL-Reasoning) unterstützt. Das Einsetzen von DL-Reasoning
in jedem Planungsschritt kann kritisch für die Performanz sein. Daher wird der
DL-Reasoner offline aufgerufen und übersetzt die Aktionsbeschreibungen in eine
SPPL-Form. In der eigentlichen Planung wird kein DL-Reasoning eingesetzt und
der Planer ermittelt den Plan nur aufgrund der SPPL Beschreibungen. In der
Arbeit ist keine Evaluierung angegeben. So bleibt offen, wie gut das Verfahren
hinsichtlich Laufzeit und Güte der erzeugten Pläne funktioniert. Spezielle Eigenschaften der Domäne werden ebenfalls nicht berücksichtigt.
Viele weitere Arbeiten beschäftigen sich mit dem Bestimmen von Workflows
oder dem Planen anhand von Beschreibungen in Ontologieform. So zeigt [LRR07]
eine Anwendung des in [BFL+ 07] beschriebenen Ansatzes. Eine Besonderheit ist,
dass die Eingabe in das System in einer SPARQL-ähnlichen Form formuliert wird.
Allerdings erfolgt auch hier keine Evaluierung der Arbeit. Einen ähnlichen Ansatz
verfolgt auch [HH08]. Hier wird die Problembeschreibung und Beschreibung der
Domäne direkt in Beschreibungslogik angefertigt. Mit einem Reasoning-Verfahren
wird eine Repräsentation für einen HTN-Planer erzeugt. Der HTN-Planer erzeugt
dann den Plan.
52
4 Konzeptueller Lösungsansatz
In diesem Kapitel wird der Lösungsansatz für die in Kapitel 1 aufgestellte Zielsetzung dieser Arbeit beschrieben. Das primäre Ziel ist die Entwicklung eines
Expertensystems, welches in der Lage ist, IE-Pipelines auf Basis von ganz bestimmten Zielen und Randbedingungen automatisch zu erstellen. Daher lässt sich
das zu entwickelnde Expertensystem in den Aufgabenbereich der Konstruktion
einordnen (vgl. Abschnitt 2.1.1). Die Ziele und Randbedingungen werden dabei
von dem Benutzer des Expertensystems als dessen Eingabe spezifiziert.
Mögliche Architekturen für ein solches Expertensystem wurden in Abschnitt
2.1.2 mit den Expertensystemarchitekturen von [Pup91] und [Hau00] aufgezeigt.
Die in dieser Arbeit benutzte Expertensystemarchitektur orientiert sich an der
Architektur von [Pup91], wobei das Konzept der Problemlösungskomponente an
[Hau00] angelehnt ist. Die Identifizierung von speziell für die Domäne Information
Extraction charakteristischem Wissen, zum Beispiel die in Abschnitt 2.4.2 aufgeführten Paradigmen zur Erstellung von effizienten IE-Pipelines, ist der Grund
für die Orientierung an [Hau00] in diesem Bereich der Architektur. Dieses Wissen
lässt sich direkt für die optimierte Konstruktion einer speziell an das Problem
angepassten Problemlösungskomponente nutzen. Die Architektur aus Abbildung
2.1 in Abschnitt 2.1.2 dient daher als Vorlage für die in dieser Arbeit genutzte Architektur des Expertensystems. Die dort verwendeten, abstrakten Komponenten
sind für die Lösung der Probleme dieser Arbeit konkretisiert und implementiert
worden. Die so instantiierte Architektur des Expertensystems ist in Abbildung
4.1 zu sehen.
Die Lösung des Problems der Berechnung von IE-Pipelines und die hierfür entwickelte Problemlösungskomponente, mit dem dazugehörigen domänenspezifischen
Planer, welcher auf dem in Abschnitt 2.3.2 vorgestellten Partial Order Planning
aufbaut, werden in Abschnitt 4.1 vorgestellt. Dazu gehören auch die Beschreibung der in die IE-Pipelines eingefügten Filter zur Einhaltung der vom Benutzer spezifizierten Randbedingungen (Randbedingungsfilter ), sowie das Ausführen
der berechneten Pipeline zum Erhalt der gewünschten Ergebnisse (IE-PipelineAusführungskomponente).
Das identifizierte Expertenwissen für die Domäne Information Extraction, sowie
zusätzliches, für die Problemlösungskomponente als wichtig identifiziertes Wissen, wird in dem entwickelten Expertensystem in der Wissensbasis in Form einer
OWL-DL-Ontologie festgehalten (vgl. Abschnitt 2.2.2). Auf Basis dieses Wissens
arbeitet die Problemlösungskomponente, daher ist es bei der Pipelineberechnung
von entscheidender Bedeutung. Warum eine solche Form der formalen Wissensrepräsentation gewählt wurde und aus welchen Bestandteilen sich diese Onto-
53
4. Konzeptueller Lösungsansatz
package
[
Architektur des Expertensystems ]
Benutzer
startet Wissenserwerb
Gibt Ziele und Randbedingungen in
Expertensystem ein
Expertensystem
Interviewerkomponente
GUI-Oberflaeche
Wissenserwerbskomponente
zeigt Protokolle an
Erklaerungskomponente
OntologieImporter
gibt Ziele und Randbedingungen an
Problemloesungskomponente
weiter und zeigt die
gefundenen Loesungen an
Problemloesungskomponente
RandbedingungsFilter
IE-PipelineAusfuehrungskomponente
Arbeitsprotokoll
protokolliert Loesungssuche
Domaenenspezifischer
Planer
benutzt durch Datenmodell gespeichertes Wissen
der Ontologie
Datenmodell
extrahiert Wissen aus Ontologie
und sendet Anfragen an Ontologie
Wissensbasis
Ontologie
Abbildung 4.1: Architektur des Expertensystems
Experte
Macht Anpassungen
an Ontologie
Externer
Ontologieeditor
importiert neues,
externes Wissen
automatisch
in Ontologie
aendert
Wissen in
Ontologie
54
4.1 Konstruktion der Information-Extraction-Pipeline
logie zusammensetzt wird in Abschnitt 4.2 vorgestellt. Des Weiteren wird dort
auch die Wissenserwerbskomponente erklärt, die sich durch ihren vollautomatischen Charakter von der Wissenserwerbskomponente von [Pup91] und [Hau00]
unterscheidet, und es wird außerdem dargelegt, warum diese Art des manuellen
Wissenserwerbs durch externe Ontologieeditoren besser erreicht werden kann. Ein
entscheidender Unterschied zu den von [Pup91] und [Hau00] vorgestellten Architekturen ist die Einführung eines Datenmodells als Abstraktionsschicht zur eigentlichen Ontologie. Mit den Vorteilen eines solchen Modells und den Gründen
warum es entwickelt wurde, schließt der Abschnitt über die Wissensbasis des Expertensystems.
Mit der Darlegung der Benutzerschnittstelle, über die der Benutzer seine Anfragen an das Expertensystem stellt und über das er auch die Ergebnisse dieser Anfrage präsentiert bekommt, endet in Abschnitt 4.3 dieses Kapitels. Hierzu werden die
Interviewerkomponente und ihre Aufgaben im Expertensystem, wie zum Beispiel
das Anstoßen der Problemlösungskomponente und des automatischen Wissenserwerbs, beschrieben. Außerdem wird erläutert, wie die Erklärungskomponente in
Form eines Arbeitsprotokolls die Nachvollziehbarkeit der berechneten Ergebnisse
gewährleistet.
4.1 Konstruktion der
Information-Extraction-Pipeline
In vielen älteren Expertensystemen wird ein allgemeines Inferenzverfahren eingesetzt und auf eine an die jeweilige Problemdomäne angepasste Problemlösungskomponente verzichtet. Hierbei liegt die Wissensbasis oft als Regelsystem vor, wie
viele der in Abschnitt 3.1 aufgezählten Expertensysteme zeigen. Diese Expertensysteme lassen sich häufig in die Aufgabenbereiche Klassifikation oder Synthese
einordnen (vgl. Abschnitt 2.1.1). Im Aufgabenbereich der Konstruktion, in den
auch das in dieser Arbeit entwickelte Expertensystem fällt, lassen sich verschiedene Ansätze sehen, die oftmals eine speziell an die Probleme der jeweiligen Domäne
angepasste Problemlösungskomponente besitzen. Ein solcher Ansatz wird auch in
dieser Arbeit verfolgt.
Die Konstruktion der IE-Pipeline ist die zentrale Aufgabe der Problemlösungskomponente und auch des gesamten Expertensystems. Die berechnete Pipeline
muss die vom Benutzer gewünschten Zielvorgaben erfüllen können, wenn sie auf
einer Menge von Texten ausgeführt wird. Das bedeutet zum Beispiel, wenn der
Benutzer als Ziel eine Pipeline haben möchte, die Aussagen zum Umsatz (im
Folgenden Umsatzaussagen genannt) von Unternehmen aus Texten heraus filtert,
dann muss die berechnete Pipeline eben jene Umsatzaussagen aus der Textmenge
extrahieren, sofern diese vorhanden sind. Dementsprechend muss die IE-Pipeline
einen Algorithmus enthalten, der Umsatzaussagen erkennen kann. Jener Algorithmus wird allerdings weitere Vorbedingungen haben, die erfüllt sein müssen, damit
55
er die im Text verborgenen Aussagen sichtbar machen kann (vgl. Abschnitt 2.4.1).
Dies könnten etwa Geld- und Zeitinformationen sein, die bereits im Text annotiert
sein müssen. Für das Herausfinden dieser Informationen sind wiederum Algorithmen in der IE-Pipeline notwendig, die eben jene Informationen finden können
und außerdem vor dem Algorithmus ausgeführt werden müssen, der die Umsatzaussagen findet. Diese Algorithmen haben wiederum Vorbedingungen und somit
müssen auch dafür wieder entsprechende Algorithmen gefunden werden, bis alle
noch offenen Vorbedingungen erfüllt sind. Die zuletzt gefundenen Algorithmen arbeiten demnach auf Klartext. Dadurch, dass die Zielvorgaben des Benutzers durch
die Pipeline erfüllt und es keine offenen Vorbedingungen für die gewählten Algorithmen mehr gibt, erfüllt die berechnete Pipeline die Zielvorgaben. Sie ist also
korrekt im Sinne dieser Vorgaben.
Dies alleine genügt allerdings noch nicht, um alle Anforderungen an die Pipeline
zu erfüllen. Der Benutzer kann weitere Randbedingungen aufstellen, die die Pipeline erfüllen muss. Er könnte zum Beispiel die Einhaltung der Bedingung Nur
”
Umsatzaussagen zwischen den Jahren 1999 und 2008“ fordern. Demnach dürfte die IE-Pipeline nur Umsatzaussagen zurück liefern, die im Zeitraum zwischen
1999 und 2008 aufgetreten sind. Der Benutzer könnte weiterhin festlegen, dass das
Expertensystem möglichst schnell Ergebnisse liefern soll, ohne auf die Güte der
gefundenen Ergebnisse zu achten. Dies wäre eine Anforderung an die Qualität der
IE-Pipeline (vgl. Abschnitt 2.4.1). So kann es sein, dass daraufhin das Expertensystem die schnellsten IE-Algorithmen für eine IE-Pipeline auswählt und dadurch
zwar schnell die Textmenge bearbeitet hat, allerdings zum einen nicht alle Umsatzaussagen gefunden werden und zum anderen in der gefundenen Menge auch
Ergebnisse dabei sind, die gar keine Umsatzaussagen sind und somit falsch bestimmt wurden. Andersherum könnte der Benutzer aber auch auf einer möglichst
hohen Menge an korrekten Ergebnisse bestehen. Damit müsste die IE-Pipeline
aus den IE-Algorithmen bestehen, die eine besonders hohe Effektivität besitzen.
Den bestehenden Kompromiss zwischen Effizienz und Effektivität gilt es daher
vom Expertensystem bei der Berechnung der IE-Pipeline zu berücksichtigen. Die
Randbedingungen lassen sich demnach in die zwei Gruppen Einschränkungen der
Ergebnismenge und Anforderungen an die Qualität der IE-Pipeline einteilen.
Nun soll aber die Pipeline unter allen gegebenen Zielvorgaben und Randbedingungen auch immer möglichst effizient sein. Das bedeutet, wenn der Benutzer eine
effektive IE-Pipeline fordert, so soll diese trotzdem noch so effizient wie möglich
sein. Daher muss das Expertensystem bei der Berechnung der IE-Pipeline die
verfügbaren Methoden zur Bestimmung einer effizienten Pipeline berücksichtigen
(vgl. Abschnitt 2.4.2).
Das Ausgangsproblem der Berechnung einer IE-Pipeline lässt sich so zusammenfassen, dass ein Verfahren gebraucht wird, welches folgende Aufgaben erledigt:
1. Aus den Zielvorgaben des Benutzers wird eine IE-Pipeline berechnet.
2. Die aufgestellten Randbedingungen bezüglich Einschränkungen der Ergebnismenge und Anforderungen an die Qualität der IE-Pipeline werden beim
56
Berechnen der IE-Pipeline beachtet.
3. Die Methoden zur Erstellung von effizienten IE-Pipelines werden bei der
Berechnung der IE-Pipeline angewendet und berücksichtigt.
Das für die Lösung dieses Ausgangsproblems gewählte Verfahren ist ein Planungsansatz, basierend auf einem Partial Order Planner. Das zugrunde liegende
Planungsproblem und der Basisalgorithmus des Planers wird in Unterabschnitt
4.1.2 dargelegt. Vorher werden im Unterabschnitt 4.1.1 die Gründe für den Einsatz eines Planungsverfahrens und gegen den Einsatz eines direkten Schlussfolgerns auf dem Wissen der Ontologie genannt. Die Unterabschnitte 4.1.3 und 4.1.4
erläutern die für den Planer wichtigen Teilaspekte der Auswahl eines Algorithmus
in einer bestimmten Situation, welche vor allem durch die Anforderungen an die
Qualität der Pipeline bestimmt wird, und der Ableitung der Pipeline aus dem am
Ende berechneten Plan. Die Erfüllung der Randbedingungen bezüglich der Einschränkung der Ergebnismenge widmet sich mit der Einführung von zusätzlichen
Filterschritten in die Pipeline der Unterabschnitt 4.1.5. Da die Berechnung der
schlussendlichen Ergebnisse natürlich eine Ausführung der berechneten Pipeline
erfordert, wird dieser Aspekt in Unterabschnitt 4.1.6 behandelt.
4.1.1 Untersuchung von Planning und Reasoning zur
Konstruktion der IE-Pipeline
Für die Konstruktion einer IE-Pipeline ist ein Planungsverfahren gewählt worden, welches in Abschnitt 4.1.2 vorgestellt wird. Allerdings gibt es als Schlussfolgerungsverfahren in einem Expertensystem neben den Planungsmethoden noch
weitere Möglichkeiten, wie in Abschnitt 2.3 bereits beschrieben. Da das entwickelte Expertensystem als Wissensbasis auf eine OWL-DL-Ontologie setzt, hätte sich
vor allem das Schlussfolgern auf dem Wissen in der Ontologie mit der Hilfe eines
OWL Reasoners angeboten, wie es in Abschnitt 2.3.1 beschrieben wurde.
Ebenfalls in dem angesprochenen Abschnitt wird erläutert, dass OWL Reasoning potenziell sehr teuer in Bezug auf die Laufzeit sein kann. In der Literatur finden sich sowohl Arbeiten, die eine praxistaugliche Laufzeit von StandardReasonern, wie Pellet oder FaCT++, erwähnen [LLBN09], als auch solche, die den
bestehenden Standard-Reasonern eine schlechte Leistung sowohl bei der Laufzeit,
und vor allem auch beim Speicherverbrauch bescheinigen [Lie06]. Entscheidend ist
aber, dass in beiden erwähnten Arbeiten die mangelnde Korrektheit der von den
Reasonern gelieferten Ergebnisse kritisiert wird.
In den in Abschnitt 3.3 vorgestellten Arbeiten wurden ebenfalls zum großen
Teil OWL-Ontologien und Planungsalgorithmen zusammen eingesetzt. Die Autoren von [ŽKŽL11] haben gezeigt, dass allein die Auswahl einer Aktion in einem
Planungsschritt, als Anfrage an die Ontologie, schon sehr lange dauern kann. Dazu
wurden die Vorbedingungen der möglichen Aktionen mit den gerade erfüllten Bedingungen abgeglichen und dann die nächste Aktion vom Reasoner ausgewählt.
57
Diese mangelnde Performanz wird auch von [BFL+ 07] beschrieben. Sie führen
daher das Reasoning offline durch und arbeiten dann in der Planungsphase auf
offline erzeugten, PDDL ähnlichen Beschreibungen. Alle anderen Arbeiten setzen
kein Reasoning als Ersatz des Planens ein.
Im späteren Verlauf dieses Kapitels wird beschrieben, welche Eigenschaften
der Domäne IE direkt für die Optimierung des Planungsansatzes genutzt werden können. Die Formalisierung dieser Eigenschaften und generell des gesamten
Expertenwissens, zum Beispiel bezüglich der Konstruktion effizienter IE-Pipelines
in eine ontologische Form, ist eine eigene Herausforderung. Die Ontologie könnte
durch Hinzunahme dieses Wissens sehr komplex werden. Bereitstehende StandardReasoner können nicht auf die Domäne IE optimiert werden. Dies liegt außerhalb
der Machbarkeit dieser Arbeit.
Anstatt Reasoning wird daher zusammengefasst aus folgenden Gründen ein
Planungsverfahren eingesetzt:
1. Gerade bei komplexeren Ontologien gibt es eine potenziell schlechte Laufzeitund Speichereffizienz der zur Verfügung stehenden Standard-Reasoner.
2. Die Standard-Reasoner sind unzuverlässig hinsichtlich der Korrektheit ihrer
Ergebnisse.
3. Andere gefundene, vergleichbare Arbeiten, die OWL-Ontologien einsetzen,
nutzen das durch den Einsatz der Ontologie mögliche Reasoning aus Gründen
der Performanz nicht als Ersatz für das Planen.
4. Die Verbesserung eines Standard-Reasoners oder die Anpassung von OWL
und Standard-Reasoner an die Domäne IE steht außerhalb der Machbarkeit
dieser Arbeit. Ein Planungsverfahren lässt sich aber sehr wohl durch die
Berücksichtigung der Besonderheiten der Domäne IE optimieren.
Das entwickelte Planungsverfahren wird in den folgenden Abschnitten vorgestellt.
4.1.2 Planungsproblem der Konstruktion der IE-Pipeline
Das Problem der Konstruktion der IE-Pipeline wird in dieser Arbeit als ein Planungsproblem aufgefasst und dementsprechend durch einen speziellen Partial Order Planner gelöst. Wie in Abschnitt 2.3.2 beschrieben, besteht ein Planungsproblem maßgeblich aus der Repräsentation der Zustände, der Ziele und der Aktionen.
In Abschnitt 2.4 wurde die Domäne Information Extraction vorgestellt. Die wesentlichen Elemente dieser Domäne sind die vorhandenen Annotationen, das heißt
die gefundenen Informationen, und die Algorithmen, welche diese Annotationen
erzeugen. Eine Annotation hat dabei einen ganz bestimmten Annotationstypen.
So kann zum Beispiel ein gefundenes Unternehmen IBM den Annotationstyp Unternehmen haben. Damit ein einzelner Algorithmus seine Arbeit verrichten kann,
müssen bestimmte Informationen bereits gefunden sein. Das bedeutet, es liegen
58
vor seiner Ausführung bereits Annotationen von bestimmten Annotationstypen
vor. Die erfolgreiche Durchführung eines Algorithmus ist also an bestimmte zu
erfüllende Vorbedingungen geknüpft. Ein IE-Algorithmus kann daher als ein Algorithmus mit einer ganz bestimmten Eingabe, den Informationen mit den benötigten Annotationstyp, und einer ganz bestimmten Ausgabe, den von ihm erzeugten
Annotationen von einem ganz bestimmten Annotationstyp, gesehen werden (vgl.
Abschnitt 2.4.1). Allerdings muss ein Algorithmus auch mit einer leeren Eingabe,
dass heißt mit nicht vorhandenen Annotationen, rechnen. Ein solcher Fall tritt
ein, wenn in einem Text eben jene benötigten Informationen, wie zum Beispiel die
eben genannten Unternehmen, nicht vorhanden sind und daher auch keine oder
nur eingeschränkt aussagekräftige Folgeinformationen erzeugt werden können. Die
zu spezifizierende IE-Aufgabe beschreibt dabei das mit der IE-Pipeline verfolgte
Ziel, also welche Art von Informationen beziehungsweise Annotationstypen schlussendlich gefunden werden sollen.
Planungsproblem als PDDL-Beschreibung
Die Notation des Planungsproblems orientiert sich an der in Abschnitt 2.3.2 beschriebenen PDDL. Das heißt, das Planungsproblem wird definiert durch die Beschreibung der Planungsdomäne und der Beschreibung des an diese Domäne gerichteten Problems. Weiterhin wird zusätzlich spezifiziert, was die Begriffe Zustand, Zielzustand und Plan, ausgehend von den Begriffen der IE-Domäne, bedeuten. Das grundlegende Planungsproblem für die Berechnung einer IE-Pipeline
lässt sich damit folgendermaßen definieren:
Beschreibung der Domäne:
• Typenliste: Eine Typenliste beschreibt PDDL-Typen, welche die möglichen
Annotationstypen spezifizieren.
• Prädikate: Das einzige Prädikat Available Annotation Type(x) beschreibt,
dass Annotationen von einem bestimmten Annotationstyp x vorliegen.
• Zustand: Ein Zustand besteht aus einer Menge von vorliegenden Annotationen von ganz bestimmten Annotationstypen. Er besteht daher aus einer
Menge und -verknüpfter Available Annotation Type(xi : T ype) Prädikate,
wobei das Objekt xi einen ganz bestimmten Annotationstyp darstellt. Dieses
Objekt ist typisiert, es besitzt daher einen Typ T ype, der in der Typenliste
spezifiziert wurde.
• Aktion: Ein IE-Algorithmus: Er benötigt zur Ausführung eine Menge schon
vorliegender Annotationen von ganz bestimmten Annotationstypen im aktuellen Zustand. Er erzeugt dann einen neuen Zustand, indem im alten Zustand nun zusätzlich Annotationen von ganz bestimmten Annotationstypen,
die vorher nicht im Zustand vorgekommen sind, vorhanden sind. Die benötigten Annotationstypen werden durch Available Annotation Type(xi : T ype)
59
beschrieben und sind demnach seine Vorbedingungen (die Eingabe des Algorithmus). Die erzeugten Annotationen werden durch Available Annotation
Type(yi : T ype) beschrieben und sind die Effekte des IE-Algorithmus (die
Ausgabe des Algorithmus). Die Objekte xi und yi haben einen ganz bestimmten Annotationstyp T ype, welcher in der Typenliste der möglichen
Annotationstypen aufgeführt ist. Zusätzlich besitzt jede Aktion ein oder
mehrere Werte für bestimmte Effizienz- und Effektivitätsmaße.
Beschreibung des Problems:
• Objekte: Für jeden möglichen Annotationstypen existiert ein Objekt. Die
Objekte sind durch Typen der Typenliste der Domänenbeschreibung typisiert (beispielsweise Satz:Sentence).
• Anfangszustand: Der Anfangszustand ist der Zustand, in dem noch keine
Objekte vorliegen (nur Klartext vorhanden, noch keine Informationen).
• Ziel: Das Ziel ist eine Menge von vorzuliegenden Annotationen mit ganz bestimmten Annotationstypen beschrieben durch Available Annotation Type(zi ).
• Zielzustand: Ein Zielzustand ist ein partiell spezifizierter Zustand, in dem
das Ziel enthalten ist.
• Randbedingungen: Die Randbedingungen für das Planungsproblem beschreiben, ob eine möglichst effektive oder möglichst effiziente IE-Pipeline konstruiert werden soll.
• Plan: Die IE-Pipeline: Eine total geordnete Menge von IE-Algorithmen, deren nacheinander erfolgte Ausführung beginnend im Anfangszustand zu einem Zielzustand führt und dabei die Randbedingungen einhält.
In den Beschreibungen des Planungsproblems wird die Eigenschaft von PDDL
genutzt, dass Objekte auch einen Typ haben dürfen. Normalerweise wäre es notwendig, für ein Objekt Satz ein entsprechendes Prädikat isSentence(x) zu definieren, damit dann im Anfangszustand isSentence(Satz) gelten kann. Für jeden
möglichen Annotationstyp wäre ein entsprechendes Prädikat zu definieren und im
Anfangszustand dann dieses Prädikat mit dem konkreten Annotationstypobjekt
aufzuführen. Des Weiteren müsste jede Aktion, die eine Vorbedingung Available
Annotation Type(Satz:Sentence) für ein Objekt Satz vom Typ Sentence braucht,
nicht nur die Vorbedingung Available Annotation Type(Satz), sondern auch isSentence(Satz) enthalten. Entsprechendes müsste für alle möglichen Annotationstypen und Aktionen spezifiziert werden. Durch die Typisierung der Objekte kann
diese Art der Modellierung vereinfacht werden. Dadurch, dass es für jeden Annotationstyp nur ein Objekt gibt, welches genau einmal vorkommt, und damit
eine eindeutige Belegung der Vor- und Nachbedingungen der Operatoren möglich
60
ist, entfällt in der Beschreibung die Unterscheidung zwischen Operator und Aktion. Ein Operator könnte in dieser Art der Modellierung nur auf eine einzige Art
instantiiert werden.
Ein Beispiel für eine Aktion kann ein Tokenisierer sein. Er hat als Vorbedingung
das Prädikat Available Annotation Type(Satz:Sentence) und als Effekt Available
Annotation Type(Token:Token). Das bedeutet, die Eingabe des Algorithmus sind
Sätze, in denen er dann die einzelnen Tokens bestimmt.
Eine weitere Vereinfachung ist die Tatsache, dass es keine negativen Effekte
gibt. Dies kommt von der Besonderheit der Domäne IE, dass IE-Algorithmen keine Informationen im eigentlichen Sinne zerstören können (vgl. [DDM05]), sondern
nur neue Informationen erzeugen. Durch eine Filterung der Informationen werden
zwar nur ganz bestimmte Informationen weitergegeben, allerdings sind die nicht
weiter verfolgten Informationen für die Lösung der Gesamtaufgabe ohne Belang
(siehe Abschnitt 2.4.2). Eine weitere Möglichkeit ist, dass ein IE-Algorithmus bereits vorhandene Annotationen löscht, weil eine Überprüfung ergibt, dass diese
falsch gesetzt worden sind. Auch hier ist die Löschung als ein Zugewinn an Information zu sehen. Aus diesen Gründen sind in den Effekten der als IE-Algorithmen
spezifizierten Aktionen nur positive Literale enthalten.
Auf Basis des beschriebenen Planungsproblems lässt sich nun ein Planungsansatz identifizieren, welcher geeignet ist, um eben jenes Problem zu lösen. Dabei gilt
es, nicht nur die Ziele des Benutzers zu beachten, sondern auch die von ihm spezifizierten Randbedingungen, sowie die Methoden zur Konstruktion einer effizienten
IE-Pipeline.
Der domänenspezifische Planer
Gewählt wurde ein Partial Order Planner als Basis für den Planungsalgorithmus.
Dieser Ansatz hat eine Reihe von Vorteilen. Ein entscheidender Vorteil, der die
Implementierung sehr vereinfacht, ist die Tatsache, dass es keine negativen Effekte in der modellierten Welt gibt. Dadurch entfällt die Notwendigkeit, verletzte
oder gefährdete kausale Links zu betrachten, da überhaupt keine kausalen Links
benötigt werden. Ein weiterer Vorteil ergibt sich aus der Arbeitsweise eines Partial Order Planners vom Ziel aus rückwärts zum Anfangszustand. Hiermit wird
automatisch das aus Abschnitt 2.4.2 bekannte Paradigma Lazy Evaluation für
die Konstruktion einer effizienten IE-Pipeline erfüllt. Ausgehend von der benötigten Eingaben eines IE-Algorithmus werden genau die Algorithmen ausgewählt,
die diese benötigten Eingaben als Ausgaben erzeugen. Dadurch ergibt sich, dass
ein IE-Algorithmus so spät wie möglich in der resultierenden IE-Pipeline auftauchen wird. Der Partial Order Planner liefert einen partiellen Teilplan, in dem
die Ordnung zwischen den gewählten Aktionen, und somit den IE-Algorithmen,
nur partiell beschrieben ist. Die partielle Ordnung kann mehrere Möglichkeiten
der Schaffung einer totalen Ordnung erlauben. Somit können aus einem partiellen Plan mehrere verschiedene IE-Pipelines erzeugt werden. Damit ist es möglich,
das in Abschnitt 2.4.2 beschriebene Paradigma Optimized Scheduling für die Kon-
61
Algorithmus 3 Pseudocode für die Berechnung der IE-Pipeline
Eingabe: Actions A, Goals G, Constraints C
Ausgabe: IE P ipeline
1: P artial P lan ← planPipeline(A, G, C)
2: IE P ipeline ← topologicalSort(P artial P lan)
3: return IE P ipeline
Algorithmus 4 planPipeline(Actions A, Goals G, Constraints C)
1: Agenda Ag ← init(A, G)
2: AS ← {start, f inish}
3: OS ← {(start < f inish)}
4: while Ag 6= ∅ do
5:
next subgoal ← (p, a) ∈ Ag
6:
Ag ← Ag − next subgoal
7:
Action b ← selectBestAction(next subgoal, A, C)
8:
AS ← AS ∪ b
9:
OS ← OS ∪ (b < a)
10:
if b ∈
/ AS then
11:
for all Precondition pi ∈ b.P RECON D do
12:
Ag ← Ag ∪ (pi , b)
13:
end for
14:
end if
15: end while
16: return P ipeline P lan = (AS, OS)
struktion effizienter IE-Pipeline zu nutzen (dies wird im späteren Abschnitt 4.1.4
näher ausgeführt).
Der grundlegende Pseudocode für die Berechnung der IE-Pipeline, ist in Algorithmus 3 zu sehen. Benötigt werden die IE-Algorithmen als Menge der Aktionen
A, die zu erreichenden Ziele G in Form von Available Annotation Type(x), sowie die weiteren Randbedingungen C. Es wird dann der partielle Teilplan für die
IE-Pipeline von dem Partial Order Planner, angedeutet durch die Funktion planPipeline bestimmt. Der erzeugte Teilplan wird anschließend mittels einer speziell
angepassten topologischen Sortierung in einen totalen Plan für die zu bestimmende IE-Pipeline überführt. Die topologische Sortierung ist keineswegs trivial. So
darf zum Beispiel das vom Partial Order Planner beachtete Paradigma Lazy Evaluation nicht wieder verletzt werden. Außerdem muss dabei, im Sinne der Effizienz
der Gesamtpipeline, auf das Paradigma Early Filtering geachtet werden. Die genaue Funktionsweise der durch die Funktion topologicalSort angedeuteten
topologischen Sortierung wird daher in Abschnitt 4.1.4 detailliert beschrieben.
Der Pseudocode des angepassten Partial Order Planners ist in Algorithmus 4
dargestellt. Er orientiert sich größtenteils an dem in Abschnitt 2.3.2 vorgestellten
Basisverfahren. Die schon angesprochene Besonderheit ist, dass durch die Domäne
IE die Notwendigkeit für das Berücksichtigen der kausalen Links entfällt. Des
62
Weiteren sind ein paar initiale Vorbereitungen zu treffen, die durch die Funktion
init in Zeile 1 durchgeführt werden.
Alle IE-Algorithmen, die auf Klartext arbeiten, somit keine benötigten Annotationen und dementsprechend auch keine Vorbedingung als Aktion besitzen, bekommen als Vorbedingung availableAnnotationType(plainText:PlainText) zugewiesen.
Das Objekt plainText vom Typ Plaintext wird in der Problembeschreibung definiert und das Literal availableAnnotationType(plainText) ist immer im Anfangszustand vorhanden. Die Funktion init in Zeile 1 erstellt außerdem die in Abschnitt
2.3.2 beschriebenen Aktionen start und f inish. Die Aktion start hat keine Vorbedingungen und als Effekt availableAnnotationType(plainText:PlainText). Somit
wird sichergestellt, dass alle Aktionen, die auf Klartext arbeiten, korrekt vom Partial Order Planner behandelt werden. Der Aktion f inish werden die gegebenen
Ziele als Vorbedingungen hinzugefügt. Außerdem werden diese Vorbedingungen
mit f inish zusammen, als zu erreichende Teilziele, auf die Agenda Ag gesetzt.
Eine wichtige Stellung nimmt in Zeile 7 die Funktion selectBestAction ein.
Im normalen Partial Order Planning würde eine Aktion gewählt, die die Vorbedingung p von Aktion a in ihren Effekten hat. Dies reicht für die Erfüllung der
Ziele diese Arbeit aber nicht aus. Der Benutzer kann Randbedingungen bezüglich
der Anforderungen an die Qualität der IE-Pipeline treffen. Diese Bedingungen
müssen bei der Auswahl der nächsten, passenden Aktion berücksichtigt werden.
So kann der Benutzer zum Beispiel einen hohen Wert auf eine möglichst effektive IE-Pipeline, und damit auf möglichst gute und viele Ergebnisse, legen. Dann
sollte in der Funktion selectBestAction immer die Aktion, welche die höchste
Effektivität verspricht, gewählt werden. Es sind aber auch noch komplexere Randbedingungen möglich. Beispielsweise kann der Benutzer angeben, dass in dem Fall,
wenn nicht ein Algorithmus als der mit der höchsten Effektivität gilt, sondern mehrere, der gewählt wird, der eine höhere Gesamteffizienz für die Gesamtpipeline
verspricht. Es gilt also, sogenannte Tie-Break Entscheidungen treffen zu können.
Die Bestimmung der in einem Planungsschritt besten Aktion ist demnach nicht
einfach. Daher wird das dazu verwendete Verfahren in einem eigenen Abschnitt
4.1.3 erläutert. Die zweiten Randbedingungen in Form von Einschränkungen der
Ergebnismenge mittels zusätzlicher Filter können unabhängig von der eigentlichen
Berechnung der IE-Pipeline erfüllt werden. Auf diesen Aspekt wird Abschnitt 4.1.5
näher eingehen.
In Abbildung 4.2 wird die Berechnung der IE-Pipeline noch einmal bildlich dargestellt. Die Menge der möglichen Aktionen für das Planungsverfahren stellen die
einzelnen IE-Algorithmen dar. Jede Aktion X hat dabei ein Menge von Vorbedingungen XP recond und eine Menge von Effekten XEf f ect . Des Weiteren besitzt jede
Aktion Werte, die die Effizienz (Effizienz X ) oder die Effektivität (Effektivität X )
des der Aktion zugrundeliegenden IE-Algorithmus beschreiben.
Aus dieser Menge von möglichen Aktionen bestimmt der Partial Order Planner
unter Berücksichtigung der spezifizierten Ziele und Randbedingungen einen partiellen Teilplan, der sich mithilfe eines Abhängigkeitsgraphen darstellen lässt (vgl.
Abschnitt 2.3.2). Dieser Abhängigkeitsgraph wird dann durch die topologische
63
APrecond
EffizienzA
A
AEffect
EffektivitätA
BPrecond
EffizienzB
B
BEffect
Partial Order
Planning
A
C
C
EffektivitätB
CPrecond
EffizienzC
C
CEffect
Ziele
+
Randbedingungen
B
A
FA
B
+
Hinzufügen
von Filtern
Randbedingungen
EffektivitätC
Menge der
Aktionen
Topologische
Sortierung
Abhängigkeitsgraph
IE Pipeline
Abbildung 4.2: Berechnung der IE-Pipeline
Sortierung in eine IE-Pipeline überführt. Bei dieser Überführung können die weiteren Randbedingungen hinsichtlich des Filterns von bestimmten Informationen
berücksichtigt werden. Für jeden Algorithmus X, der die zu filternden Informationen liefert, wird daher ein anschließender Filterschritt FX in die IE-Pipeline
eingebaut. Zum Beispiel würde die Bedingung, nur Unternehmen zurückzugeben,
die mit I beginnen, und der Tatsache, dass die Aktion A den Annotationstyp Unternehmen in ihren Effekten hat, bedeuten, dass nach A der Filter FA eingefügt
wird, welcher die eben genannte Bedingung für alle eingehenden Textstellen prüft.
Hierbei filtert der Filter alle Textstellen heraus, die nicht eine mit I beginnendes
Unternehmen enthalten.
Entscheidungsbegründung für einen Partial Order Planner
Die Vorteile des eingesetzten Partial Order Planner wurden bereits aufgezählt. Im
Folgenden soll daher erläutert werden, was die Nachteile von anderen Planungsverfahren, die alle in Abschnitt 2.3.2 beschrieben wurden, sind, die dazu geführt
haben, diese Verfahren nicht einzusetzen.
Alle Planungsverfahren, die die Planung als Suche im Zustandsraum durchführen,
haben den Nachteil, dass sie immer nur eine IE-Pipeline finden. Eine Differenzierung zum Zwecke des Paradigmas Optimized Scheduling, wie es die topologische
Sortierung des Partial Order Planner möglich macht, ist somit nicht möglich. Bei
der Vorwärtssuche besteht außerdem die Gefahr, dass das Paradigma Lazy Evaluation verletzt wird. Das Hierarchical Task Network Planning kann nicht eingesetzt werden, weil das Paradigma Maximum Decomposition, also die größtmögliche
Aufteilung der IE-Algorithmen in ihre Bestandteile, komplett entgegengesetzt zu
der Idee des HTN Planning steht. Dieses versucht in einer Top-Down-Methode,
von dem gröbsten Plan aus durch immer weitere Verfeinerungen des Plans einen
Gesamtplan zu konstruieren. Die Idee des Paradigmas Maximum Decomposition
64
besteht aus einer Bottom-Up-Methode, die also auf der feingranularsten Stufe ansetzt und dadurch schrittweise zu einer Gesamtpipeline kommt. Die Nachteile des
Planens als Erfüllbarkeitsproblem sind ähnlich den in Abschnitt 4.1.1 angeführten
Gründen gegen Reasoning und für Planen insgesamt. Vor allem die mangelnde
Optimierung an die identifizierten Eigenarten der Domäne IE schränkt diese Art
des Planens ein. Außerdem besteht die Gefahr, dass die Menge der Aussagensymbole schnell sehr groß werden kann, wenn etwa das Wissen um die Paradigmen
für eine effiziente Konstruktion von IE-Pipelines mit in das Erfüllbarkeitsproblem
hinein kodiert wird.
Eine weitere Möglichkeit hätte der Einsatz eines schon bestehenden Planers, wie
den bereits in Kapitel 3 erwähnten MetricFF-Planer, sein können. Viele dieser Planer basieren auf PDDL (vgl. Abschnitt 2.3.2). Das grundsätzliche Problem, dass
diese Planer kein Domänenwissen enthalten und daher nicht auf das zugrundeliegende Problem der Berechnung einer IE-Pipeline hin optimiert werden können,
bleibt jedoch bei allen externen Planern bestehen. Ein weiteres Problem ist, dass
zum Beispiel die PDDL-basierten Planer im Normalfall immer den kürzesten zu erreichenden Plan zurück liefern. Dies ist aber für das hier behandelte Problem völlig
unzureichend. Ein kürzester Plan sagt nichts über die zugrundeliegende Qualität
aus, die ein Benutzer beispielsweise als zu erfüllende Randbedingung mit in das
Problem eingibt. So kann nicht garantiert werden, dass eine IE-Pipeline hinsichtlich einer bestmöglichen Effektivität konstruiert wird. Moderne PDDL-Planer wie
MetricFF bieten zwar die Angabe von beliebig vielen numerischen Werten an den
Aktionen und unter Angabe eines Kostenmaßes auch eine Art von zu minimierender oder maximierender Zielfunktion an. Allerdings lassen sich nicht alle Werte der
Domäne IE, wie Precision, Recall oder Average Sentence Response Time beliebig
miteinander verrechnen (vgl. Abschnitt 2.4.3). Nicht einmal die Verrechnung in
einem Gütekriterium wie Recall ist möglich. So bleibt eine Angabe von Zielfunktionen unzureichend für das Problem der Konstruktion von IE-Pipelines.
4.1.3 Lösungsansatz des Algorithmenauswahlproblems
Der Benutzer stellt Randbedingungen hinsichtlich der zu erwartenden Qualität
der IE-Pipeline auf, die bei ihrer Konstruktion berücksichtigt werden müssen.
Dies kann etwa eine möglichst hohe Effektivität der Pipeline sein. In diesem Fall
sollte in jedem Planungsschritt immer jener Algorithmus genommen werden, der
den höchsten Effektivitätswert hat. Dadurch ergibt sich dann eine hohe Gesamteffektivität der IE-Pipeline (vgl. Abschnitt 2.4.2). Hierbei ergeben sich mehrere
Probleme. Zum einen kann es sein, dass der Benutzer eine gleichermaßen effektive wie effiziente IE-Pipeline haben möchte. Effektivität und Effizienz gleichzeitig
zu optimieren ist schwierig, da eine hohe Effizienz meist eine geringe Effektivität
zur Folge hat und umgekehrt, bedingt durch den in Abschnitt 2.4.3 beschriebenen
Trade-Off zwischen Effektivität und Effizienz in der Domäne IE. Somit würden die
entstehenden IE-Pipelines weder eine hohe Effektivität noch eine hohe Effizienz
aufweisen.
65
Ansatz der Mehrzieloptimierung
In der Literatur, zum Beispiel in [MA04] und in [Deb05] gibt es verschiedene
Verfahren, um diese sogenannte Mehrzieloptimierung zu lösen. Zuerst werden die
Pareto-optimalen Punkte bestimmt. Ein einzelner Wert x eines Pareto-optimalen
Punktes p = (x, y) kann nur verbessert werden, indem sein Wert y verschlechtert
wird und umgekehrt. Es besteht also ein Kompromiss zwischen den beiden Werten. Die sogenannte Pareto-Front ist jene Grenze auf der alle Pareto-optimalen
Punkte liegen. Auf dieser Front liegen damit die bestmöglichen Punkte. Von einem Pareto-optimalen Punkt zum nächsten kann eine Verbesserung eines Wertes
nur durch die Verschlechterung eines anderen erreicht werden. Man spricht davon,
dass diese Punkte nicht dominiert werden von anderen Punkten. Ein Punkt, der
nicht Pareto-optimal ist, kann demnach in allen Werten außer einem höchstens
gleich gut sein wie ein Pareto-optimaler Punkt.
Ein Beispiel hierfür wäre, dass der Benutzer eine möglichst effektive und effiziente Pipeline haben möchte. In einem Planungsschritt werden zwei ein Teilziel
erfüllende Algorithmen ausgewählt und die Aufgabe besteht nun darin zu entscheiden, welcher von beiden genommen wird. Diese beiden Algorithmen A und B
haben Effektivitätswerte x und Effizienzwerte y von A = (xA = 0, 1 ; yA = 1, 0)
beziehungsweise B = (xB = 1, 0 ; yB = 0, 1). Jeder Punkt ist in einem Wert
besser als der andere, in seinem anderen Wert aber schlechter (unter der Annahme, dass höhere Zahlenwerte bessere Werte darstellen). Das bedeutet, beide
sind Pareto-optimale Punkte. Das Problem besteht nun darin, eine Entscheidung
darüber zu treffen, welcher Punkt als der einzig beste ausgewählt wird. In [Deb05]
werden dazu zwei grundlegende Verfahren beschrieben. Zum einen kann nach dem
Berechnen der Pareto-optimalen Punkte Metawissen eingesetzt werden, um den
besten Punkt zu bestimmen. So könnte zum Beispiel gesagt werden, dass im Zweifel immer der Effektivitätswert den Vorrang hat, der über 0, 5 liegt. Damit würde
im vorangegangenen Beispiel der Algorithmus B gewählt werden. Ein anderes Verfahren versucht die einzelnen Werte mittels eines Präferenzvektors zu gewichten,
und damit einen Gesamtwert für jeden Punkt zu berechnen. So könnte mit einer
Gewichtung der Effektivität von 0, 3 und der Effizienz von 0, 7 für A und B die
Gesamtwerte A = 0, 1 ∗ 0, 3 + 1, 0 ∗ 0, 7 = 0, 73 und B = 1, 0 ∗ 0, 3 + 0, 1 ∗ 0, 7 = 0, 37
bestimmt werden. Mit dieser Präferenz würde A als bester Punkt ausgewählt werden.
Gewählter Ansatz
In der Domäne IE sind die eben beschriebenen Möglichkeiten der Mehrzieloptimierung nicht ohne weiteres anwendbar. Hier existiert das schon in Abschnitt 2.4.3
beschriebene Problem, dass vor allem die Effektivitätsmaße nicht einfach aufsummiert oder auf irgend eine Art und Weise miteinander verrechnet werden können.
Auch ein Ansatz, einen Effizienzwert, wie Averaged Efficiency und einen Effektivitätswert, wie F-Measure, anteilig zu einem einzigen Wert zu verrechnen und mit
66
diesem neuen Wert eine Aussage zu treffen, konnte vom Autor dieser Arbeit in
der Literatur nicht gefunden werden.
Daher wird in dieser Arbeit ein anderer Ansatz verfolgt. Der Benutzer legt sich
im Vorfeld auf eine Reihenfolge der Betrachtung von verschiedenen Gütekriterien
fest, und damit auf eine Priorisierung bei der Auswahl des in einem Planungsschritt besten Algorithmus. Diese Wahl ist das Aufstellen einer Randbedingung
hinsichtlich der Qualität der zu konstruierenden IE-Pipeline. Eine Priorisierung
1. Effizienz 2. F-Measure 3. Precision bedeutet zum Beispiel, dass in einem Planungsschritt zuerst die Aktionen bestimmt werden, die das gerade gewählte Teilziel lösen können. Aus dieser Menge wird dann für jede Aktion, und somit für
den hinter einer Aktion stehenden IE-Algorithmus, der Effizienzwert berechnet.
Sobald es nur eine einzige, beste Aktion hinsichtlich der Effizienz gibt, wird diese gewählt. Andernfalls werden die F-Measure-Werte der effizientesten Aktionen
miteinander verglichen. Gibt es wieder mehr als eine Aktion mit dem besten FMeasure-Wert, so wird der Precision-Wert dieser besten Aktionen herangezogen.
Sollte es am Ende immer noch mehr als eine beste Aktion geben, so wird, mangels
weiterer Alternativen, der lexographisch erste Name der den Aktionen zugrundeliegenden Algorithmen als Entscheidungskriterium genommen. Die einzelnen
Prioritäten werden also nacheinander durchlaufen.
Die möglichen Priorisierungen können aus den in der Domäne IE zur Verfügung
stehenden Gütekriterien ableitet werden. Die Kriterien lassen sich den Bereichen
Effektivität und Effizienz zuordnen (vgl. Abschnitt 2.4.3). Es wird angenommen,
dass die Effizienz für jeden IE-Algorithmus in einem einheitlichen Kriterium ausgedrückt ist. Dies kann zum Beispiel die Averaged Efficiency sein. Bei der Effektivität
gibt es für die unterschiedlichen Arten von Algorithmen unterschiedliche Effektivitätskriterien. So kann es für ein IE-Verfahren wichtig sein zu erfahren, wie es um
seine Präzision (Kriterium Precision) und/oder um seine Trefferquote (Kriterium
Recall ) steht (vgl. Abschnitt 2.4.3). Um einen Gesamtüberblick über die Effektivität eines IE-Algorithmus zu bekommen, wird häufig das F-Measure benutzt,
wie in Abschnitt 2.4.3 bereits beschrieben. Bei den Algorithmen der Vorverarbeitung sind meistens andere Effektivitätsmaße im Einsatz. So wird die Effektivität
eines Tokenisierers oft in Accuracy angegeben. Ein Dependecy Parser ist in der
Regel dann effektiv, wenn er einen hohen Labeled Attachment Score hat. Wie in
Abschnitt 2.4.3 bereits erwähnt, versuchen F-Measure, Accuracy und Labeled Attachment Score (LAS) einen kombinierten Gesamtwert für die Effektivität eines
Algorithmus anzugeben.
Für eine IE-Aufgabe und damit für die Gesamtbetrachtung der IE-Pipeline, welche diese Aufgabe löst, sind die betrachteten Gütekriterien das F-Measure F1 (Π)
der IE-Pipeline Π, die Precision P (Π) und der Recall R(Π) auf Seiten der Effektivität und die Laufzeit der Pipeline als Effizienzmaß t(Π). Dies liegt daran, dass,
wie in Abschnitt 2.4.1 beschrieben, gerade die Effektivität der IE-Algorithmen,
die eine solche IE-Aufgabe lösen, häufig in F-Measure, Recall und Precision ausgedrückt wird. Der Benutzer kann verschiedene Reihenfolgen dieser vier Kriterien
im Vorfeld der Pipelineberechnung wählen. Abbildung 4.3 zeigt die zwölf für den
67
Effektivität
Effizienz
P(∏ )
Pt
PF1
tP
tF1P
t(∏ )
tF1R
F1tP
F1P
F1(∏ )
F1tR
F1R
tR
Rt
RF1
R(∏ )
Abbildung 4.3: Durch Benutzer wählbare Priorisierungen
Benutzer wählbaren Möglichkeiten der Priorisierung, dargestellt als blaue Punkte. Durch Wahl einer dieser Punkte ist es dem Benutzer möglich, eine Präferenz
hinsichtlich Effizienz und Effektivität, sowie zwischen Recall und Precision der zu
konstruierenden IE-Pipeline anzugeben. Die Wahl eines Punktes tF1 R gibt etwa
an, dass bei der Konstruktion der IE-Pipeline die einzelnen Algorithmen zuerst
aufgrund ihrer Effizienz ausgewählt werden sollen. Erst wenn sich eine Situation ergibt, dass mehrere Algorithmen in einem Planungsschritt sowohl dasselbe
Teilziel erfüllen, als auch die gleiche Effizienz aufweisen, wird als zweites der FMeasure-Wert der Algorithmen verglichen. Nur wenn sich danach immer noch kein
bester Algorithmus bestimmen lässt, wird auch noch der Recall -Wert der Algorithmen betrachtet. Bei erneuter Gleichheit entscheidet dann, wie bereits erwähnt,
die lexographische Ordnung der Algorithmennamen.
Punkte, die in Abbildung 4.3 auf den Kanten des Dreiecks liegen, haben nur
zwei Gütekriterien angegeben. Dies liegt daran, dass sich bei ihnen das dritte
Kriterium implizit ergibt. Sind etwa bei Wahl eines Punktes F1 R sowohl der FMeasure- als auch der Recall -Wert der auszuwählenden Algorithmen gleich, so
müssen danach deren Effizienzwerte untersucht werden. Die Untersuchung der
Precision Werte anstatt der Effizienz kann entfallen, da die Precision bei allen
betrachteten Algorithmen gleich sein muss. Dies ergibt sich aus der in Abschnitt
2.4 vorgestellten Berechnungsweise des F-Measure aus Recall und Precision. Daher
ist es bei einem Punkt Rt egal, ob nach gleichen Effizienzwerten der F-MeasureWert oder der Precision-Wert der verbliebenen Algorithmen betrachtet wird. In
beiden Fällen werden die gleichen Reihenfolgeergebnisse herauskommen.
Die Wahl eines Punktes wie tF1 R zieht nach sich, dass alle betrachteten Algorithmen einen Effizienzwert, einen F-Measure- und einen Recall -Wert besitzen.
Dies ist, wie weiter oben bereits angesprochen, allerdings größtenteils nur bei. den
IE-Algorithmen der Fall. Für zwei Tokenisierer, die nur einen Wert für Accuracy
als Effektivitätswert besitzen, muss die durch den gewählten Punkt ausgedrückte
Präferenz erst Effizienz, dann Effektivität dazu führen, dass anstatt das F-Measure
68
Algorithmus 5 selectBestAction(Subgoal (p, a), Actions A, Constraints C)
1: Actions Af ← getActionsFullfillingSubgoal(A, p)
2: List qualityCriteriaOrder ← getSuitableOrder(Af , C)
3: for all Quality Criterion q ∈ qualityCriteriaOrder do
4:
if |Af | = 1 then
5:
return Element in Af
6:
else
7:
Af ← getBestActions(Af , q)
8:
end if
9: end for
10: return lexographical first element in Af
Algorithmus 6 getBestActions(Actions A, Quality Criterion q)
1: value[|A|]
2: for all Action a ∈ A do
3:
if q can not be added up then
4:
value[a] ← Value of a for q
5:
else
6:
value[a] ← getValue(a, q)
7:
end if
8: end for
9: return Action with best(value)
bei Gleichheit der Effizienz der Wert ihrer Accuracy A den besten Tokenisierer bestimmt. Eine zweite Priorisierung tA wird also bei der Wahl von tF1 R implizit mit
ausgewählt. Die dritte implizite Priorisierung ist schließlich tLAS. So müssen also
für jeden ausgewählten Punkt implizit zwei weitere Priorisierungen ausgewählt
werden, die die Effizienz t sowie entweder A oder LAS betreffen.
Algorithmus des gewählten Ansatzes
Der Auswahlprozess des besten Algorithmus durch die Funktion selectBestAction aus dem Pseudocode des Partial Order Planners in Algorithmus 4 lässt sich
nun formal definieren. Der Pseudocode für die Auswahl der besten Aktion ist in
Algorithmus 5 zu sehen. Durch die Funktion getActionsFullfillingSubgoal in Zeile 1
wird die Menge der Aktionen bestimmt, die das zu erfüllende Teilziel p in ihren Effekten enthalten haben. Danach wird auf Basis dieser gewählten Algorithmen eine
passende Priorisierung durch die Funktion getSuitableOrder in Zeile 2 gewählt. So
wird, wie weiter oben beschrieben, anstatt einer Priorisierung tF1 R eine Priorisierung tA gewählt, wenn zum Beispiel nur Tokenisierer als zu betrachtende Aktionen
zur Auswahl stehen würden. Anschließend werden in einer Schleife von Zeile 3-9
nach und nach die besten Aktionen unter Berücksichtigung des jeweiligen Gütekriteriums bestimmt. Die besten Aktionen für ein Gütekriterium werden durch
die Funktion getBestActions in Zeile 7 berechnet.
69
Algorithmus 7 getValue(Action a, Quality Criterion q)
1: value ← Value of q for a
2: for all Precondition p ∈ a.P RECON D do
3:
bestV alue ← N U LL
4:
for all Action ai ∈ getActionsFullfillingSubgoal(p) do
5:
if ai is Filterprocedure then
6:
bestV alue ← N U LL
7:
break
8:
else
9:
aV alue ← getValue(ai , q)
10:
end if
11:
bestV alue ← max(bestV alue, aV alue)
12:
end for
13:
value ← calc(value, bestV alue)
14: end for
15: return value
Diese Funktion ist in Algorithmus 6 zu sehen. Sie bestimmt für jede Aktion
den jeweiligen Wert des Gütekriteriums. Danach gibt sie alle Aktionen mit dem
besten Wert zurück. Der beste Wert kann dabei der niedrigste sein, beispielsweise bei Effizienzwerten wie Averaged Efficiency, oder aber der höchste, wie den
Effektivitätswerten Recall, Precision und F-Measure.
Lassen sich die Werte des betrachteten Gütekriteriums nicht verrechnen, so wird
in Zeile 4 der Wert des Gütekriteriums für die Aktion direkt genommen. Sollen
beispielsweise die Recall Werte von Aktionen bestimmt werden, dann ist nur der an
der jeweiligen Aktion bestehende Wert für Recall zu nehmen und anschließend der
höchste Wert von allen betrachteten Aktionen zu bestimmen. Bei der Bestimmung
der Werte für ein Laufzeitkriterium wie Averaged Efficiency dürfen aber nicht nur
die Laufzeitkosten der jeweiligen Aktion alleine betrachtet werden, sondern man
muss die Kosten von allen Vorgänger mit einrechnen. Dies passiert durch die
Funktion getValue in Zeile 6. Vorgänger sind eben jene Aktionen, die eine oder
mehrere Vorbedingungen der Aktion als Effekte haben. Für die Berechnung des
Wertes für einen Vorgänger müssen seine Vorbedingungen und die entsprechenden
Vorgänger bestimmt werden.
Die Funktion getValue in Zeile 6 bestimmt für eine Aktion und ein Gütekriterium rekursiv den entsprechenden Wert. Sie ist in Algorithmus 7 zu sehen. Die
Rekursion wird spätestens abgebrochen, wenn eine Aktion keine Vorbedingungen
hat. Dann wird der Wert für das entsprechende Gütekriterium aus Zeile 1 direkt
zurückgegeben und die Schleife in Zeile 2-14 nicht durchlaufen. Für jede Vorbedingung der Aktion (Zeile 2) wird ansonsten der beste Wert rekursiv bestimmt (Zeile
4-12) und zusammengerechnet durch die Funktion calc (Zeile 13). Wird bei dieser Berechnung für eine Vorbedingung ein Filterverfahren als die Vorbedingung
erfüllende Aktion gefunden (Zeile 5), so wird die Berechnung für diese Vorbedingung abgebrochen (Zeile 6 und 7). Die Begründung hierfür wird im nächsten
70
Abschnitt beschrieben. Somit wird am Ende für den Partial Order Planner eine
entsprechende, beste Aktion bestimmt.
Aspekte des gewählten Ansatzes
Der gewählte Ansatz benutzt für die Bestimmung des Wertes eines verrechenbaren Gütekriteriums einer Aktion einen heuristischen Ansatz. Filterverfahren sind
hierbei die wichtigsten Elemente. Ein Filterverfahren schränkt die nachfolgende
Menge an zu untersuchenden Textstellen ein. Dadurch wird zum Beispiel die Gesamteffizienz der IE-Pipeline direkt erhöht, denn weniger zu analysierender Text
bedeutet eine kürzere Gesamtlaufzeit (vgl. 2.4.2). Ein Filterverfahren wird von
dem gewählten Ansatz nur betrachtet, wenn es eine direkte Aktion ist, die ein
Teilziel erfüllen kann. Bei der rekursiven Berechnung der Werte von verrechenbaren Gütekriterien wird die Rekursion nur bis zu einem Filterverfahren zurückgeführt. Das hat den Grund, dass sich die zu verarbeitende Textmenge nach der
Ausführung eines Filterverfahrens ändert. Daher gibt es keine Begründung, die
Werte vor dem Filterverfahren (einschließlich dem Filterverfahren selbst) mit den
Werten nach dem Filterverfahren zu verrechnen.
Ein weiterer Aspekt ist, dass die Werte für alle Vorbedingungen einer Aktion
isoliert voneinander berechnet werden. Dabei kann es sein, dass eine Aktion in
verschiedenen Berechnungspfaden mehrmals vorkommt. In der resultierenden IEPipeline ist jede Aktion allerdings nur einmal enthalten. Daher müssen die Werte
der Aktion auch nur einmal in die Gesamtberechnung einfließen. Dies kann gelöst
werden, indem bei der Bestimmung des Wertes für eine Vorbedingung die gewählten Aktionen gemerkt und diese bei der Bestimmung des Wertes für eine andere
Vorbedingung berücksichtigt werden. Das bedeutet konkret, dass alle schon bei der
Berechnung der ersten Vorbedingung erfüllten“ Teilziele bei der Berechnung der
”
Werte für die anderen Vorbedingungen nicht mehr berücksichtigt werden müssen.
Hierdurch ergibt sich natürlich der Nachteil, dass der zu berechnende Wert auch
davon abhängt, in welcher Reihenfolge die Werte der Vorbedingungen bestimmt
werden.
Dabei darf nicht der Fehler gemacht werden, aus den berechneten Werten und
vor allem deren Berechnungspfaden könne direkt auf eine Reihenfolge in der Pipeline geschlossen werden. Hier wird nur die Berechnung für ein Gütekriterium in
einem speziellen Fall ausgeführt. Wenn dem Benutzer die Effektivität am Wichtigsten ist und er die Effizienz an zweiter Stelle sieht, so können aus der rekursiven
Berechnung der Effizienzwerte keine weiteren Informationen für die Reihenfolge
abgeleitet werden. Die Effizienzwerte würden nur bestimmt werden, wenn als erstes
die Effektivitätswerte von mehreren Aktionen gleich wären. Nach dem Vergleich
der Effizienzwerte hat im nächsten Schritt aber wieder die Effektivität die höchste
Priorität, wodurch sich komplett andere Aktionen, als die auf einem Berechnungspfad zur Berechnung eines Effizienzwertes, ergeben können.
Ein Aspekt ist auch, dass die schon erreichten Teilziele des Partial Order Planners berücksichtigt werden sollten. Diese dürfen bei der rekursiven Bestimmung
71
der Werte für die Vorbedingungen nicht beachtet werden. Ist eine Aktion A schon
Teil des partiellen Plans und tritt ein von A erreichtes Teilziel zum Beispiel bei der
Berechnung der Laufzeitwerte für eine Aktion B auf, so ist diese Vorbedingung
von B schon erfüllt und die Laufzeitkosten von A sowie ein weiteres Verfolgen der
Vorbedingung brauchen nicht betrachtet werden. Eine Aktion C, deren Vorbedingungen keine im Planungsverlauf bereits erreichten Teilziele enthalten, hat diesen
Vorteil nicht. Damit werden eben jene Aktionen bevorzugt, die schon möglichst
viele direkte oder indirekte, von Vorgängern aufgestellte, Vorbedingungen erfüllt
haben. Dies bedeutet auch, dass die berechneten Werte nicht über einen Planungsschritt hinaus zwischengespeichert werden können.
Ein Problem bei diesem Ansatz ist, dass jedes Teilziel des Partial Order Planners und jede Vorbedingung bei der Berechnung der Werte für eine Aktion einzeln
betrachtet werden. Dadurch können keine Aktionen bevorzugt werden, die mehr
als eine Vorbedingung gleichzeitig erfüllen. Wird aber vorausgesetzt, dass das Paradigma Maximum Decomposition im Vorfeld auf allen Algorithmen erfolgreich
angewendet wurde, so können solche Algorithmen nicht auftreten. Bei einer maximalen Zerlegung hätte jeder Algorithmus nur einen einzigen Effekt.
Ein Vorteil des vorgestellten Ansatzes ist seine generische Methode. Die Randbedingungen, welche die Priorisierung der einzelnen Gütekriterien festlegen, werden von außen in die Problemlösungskomponente hinein gegeben. Die möglichen
Priorisierungen der in Abbildung 4.3 dargestellten Punkte müssen daher nicht
innerhalb der Problemlösungskomponente gespeichert werden. Die Komponente
muss auch nicht wissen, was die einzelnen Gütekriterien konkret bedeuten, sondern kann sie einfach, der gewählten Priorisierung nach, abarbeiten.
4.1.4 Topologische Sortierung des vom Planer erzeugten
Abhängigkeitsgraphen
Die Ausgabe des Partial Order Planners ist ein partieller Plan. Wie schon in Abschnitt 2.3.2 erläutert, kann dieser partielle Plan auch als Abhängigkeitsgraph, als
Directed Acyclic Graph (DAG), aufgefasst werden. Aus diesem DAG gilt es, die
IE-Pipeline zu erzeugen. Dies kann, wie ebenfalls in Abschnitt 2.3.2 gezeigt, durch
eine topologische Sortierung erfolgen. Die Herausforderungen bei dieser Umwandlung bestehen in der Beibehaltung des vom Partial Order Planner beachteten
Paradigmas Lazy Evaluation und der Umsetzung des aus Abschnitt 2.4.2 bekannten Paradigmas Early Filtering. Das bedeutet, in einer IE-Pipeline soll so früh wie
möglich eine Filterung des zu untersuchenden Textes durchgeführt werden. Damit
wird erreicht, dass die späteren IE-Algorithmen der Pipeline, das sind im Allgemeinen die laufzeitintensiven Algorithmen der Relationen- und Ereigniserkennung,
auf einer kleineren Menge an Text arbeiten und somit deren Gesamtlaufzeit, und
damit auch die der IE-Pipeline insgesamt, gesenkt wird. Die Filterverfahren einer
IE-Pipeline sind für diese Filterung des Textes verantwortlich. Daher sollen sie in
der späteren IE-Pipeline so früh wie möglich ausgeführt werden, um so früh wie
72
B
C
A
F
D
E
1. :
A
B
D
C
E
F
2.:
A
B
C
D
E
F
Abbildung 4.4: Beispiel DAG mit zwei möglichen topologischen Sortierungen
möglich zu filtern. Außerdem soll weiterhin das Paradigma Optimized Scheduling
bei der topologischen Sortierung in Betracht gezogen werden.
Vorüberlegungen
Abbildung 4.4 zeigt einen Beispiel-DAG, der vom Partial Order Planner geliefert
sein könnte, mit den grau hinterlegten Filterverfahren C, E und F . Weiterhin
sind zwei mögliche topologische Sortierungen dieses Graphen dargestellt. Obwohl
beide Sortierungen korrekt im Sinne einer topologischen Sortierung sind, verletzt
die erste sowohl das Paradigma Lazy Evaluation, als auch das Paradigma Early Filtering. Die Ausführungen von B oder D könnten verzögert werden, da die
Ergebnisse des entsprechenden Algorithmus nicht unmittelbar gebraucht werden.
Dies entspricht also nicht der Lazy Evaluation. Eines der Filterverfahren C beziehungsweise E kann immer an dritter Stelle in der Pipeline ausgeführt werden.
Daher wird in der ersten Sortierung auch das Paradigma Early Filtering verletzt.
Neben der zweiten, korrekten Sortierung, im Sinne der angesprochenen Paradigmen, existiert noch eine weitere Möglichkeit, indem D vor E vor B vor C
ausgeführt wird. Die Wahl, welches Filterverfahren bevorzugt werden sollte, kann
durch Befolgung des Paradigmas Optimized Scheduling geschehen. Wie allerdings
schon in Abschnitt 2.4.2 dargelegt, werden für die Anwendung dieses Paradigmas
die Filterraten der Filterverfahren gebraucht. Diese Filterraten sind allerdings
stark abhängig von der Art der zu untersuchenden Texte und lassen sich daher
nicht im Vorfeld bestimmen, ohne dass die Art der zu untersuchenden Texte bekannt ist. Daher wird im Bezug auf die topologische Sortierung der im Paradigma
Optimized Scheduling vorgestellte optimierte Schedule leicht abgewandelt:
Ein statisch optimierter Schedule liegt dann vor, wenn bei der Auswahl
der Filterverfahren diejenigen bevorzugt werden, welche zusammen mit
ihren notwendigen Vorgängern die beste Laufzeiteffizienz aufweisen.
Die Idee dahinter ist, dass zuerst die schnellsten Filterverfahren genommen werden. Hierbei sind natürlich auch die zum Ausführen des Filterverfahrens notwen-
73
digen Vorgänger und deren Laufzeiten zu berücksichtigen. Mit dieser Strategie ist
schon bevor die langsameren Filterverfahren ausgeführt werden, eine Menge irrelevanter Text herausgefiltert worden. Die langsameren Verfahren werden damit
beschleunigt. Diese Annahme ist vor allem dann zutreffend, wenn alle Filterverfahren zwar unterschiedliche Laufzeiten, aber die gleiche Filterrate besäßen.
Allerdings kann es auch Fälle geben, in denen dieses Verfahren nicht die optimalen Schedules erzeugt. Ist ein Filterverfahren A geringfügig schneller (unter
Berücksichtigung seiner Vorgänger) als ein Filterverfahren B, so kann es trotzdem
sein, dass die Bevorzugung von A nicht den optimalen Schedule liefert. Das Filterverfahren B könnte auf einer bestimmten Textmenge eine viel höhere Filterrate
besitzen und dadurch die geringfügig bessere Laufzeit von A mehr als ausgleichen.
Es wäre hier demnach besser gewesen, B vor A auszuführen.
Konzept der eingesetzten topologischen Sortierung
Ausgangspunkt des Verfahren ist, wie schon erwähnt, der vom Partial Order Planner gelieferte partielle Plan P = (AS, OS). Aus diesem Plan muss zuerst ein
Abhängigkeitsgraph in Form eines DAG erzeugt werden. Davor werden die nicht
benötigten Hilfsaktionen start und f inish aus AS und OS entfernt. Alle verbliebenen Aktionen in AS sind dann Knoten im DAG. Anschließend kann für jede
Ordnungsrelation (a > b) eine gerichtete Kante von dem Knoten a zum Knoten b im DAG hinzugefügt werden. Dadurch wird der Abhängigkeitsgraph, wie in
Abschnitt 2.3.2 beschrieben, gebildet.
Als Nächstes wird für jedes Filterverfahren im DAG die Liste seiner Vorgänger
bestimmt. Dazu werden alle Kanten im DAG umgedreht und daraufhin die sogenannte transitive Hülle berechnet. In der transitiven Hülle ist jeder Knoten
mit jedem von ihm aus erreichbaren Knoten durch eine direkte Kante verbunden.
Dies lässt sich beispielsweise mithilfe des Floyd-Warshall -Algorithmus in O(|V |3 )
durchführen [CSRL01]. Da die Kanten umgedreht wurden lässt sich für einen
Knoten direkt die Liste seiner Vorgänger bestimmen. Dies sind alle Knoten, zu
denen die ausgehenden Kanten führen. Diese Liste der Vorgänger für ein Filterverfahren lässt sich also sofort an der Adjazenzliste seines Knotens ablesen. Eine
weitere Möglichkeit wäre zum Beispiel das Bestimmen der Vorgänger durch eine
Breitensuche von jedem Filterverfahren aus in O(|V | ∗ (|V | + |E|)). Da die Anzahl der Algorithmen in einer IE-Pipeline, und somit die Anzahl der Knoten im
Abhängigkeitsgraph, in der Regel relativ klein ist, etwa in [WSE11] und [HHF+ 10]
jeweils kleiner als 15 Algorithmen, ist die unterschiedliche Laufzeitkomplexität der
unterschiedlichen Möglichkeiten zu vernachlässigen.1
Ausgehend von der Liste der Vorgänger von jedem Filterverfahren kann das beste Filterverfahren gesucht werden. Wie schon in den Vorüberlegungen dargelegt,
soll für die spezielle Art des statisch optimierten Schedules das Filterverfahren
1
Das Graph-Framework mit dem die Implementierung durchgeführt wurde, bietet direkt eine
Funktion zum Bestimmen der transitiven Hülle eines Graphen an. Daher wurde schlussendlich
diese Vorgehensweise gewählt.
74
Algorithmus 8 topologicalSort(Partial Plan partialP lan)
1: DAG graph ← makeDAG(partialP lan)
2: f ilterP rocedures ← getFilterProcedures(partialP lan)
3: predecessorsOf F ilterP roc ← getPredecessorLists(f ilterP rocedures, graph)
4: P ipeline ← ∅
5: while not graph. |V | = 0 do
6:
bestF ilterP roc ← getBestFilterProc(predecessorsOf F ilterP roc)
7:
subGraph ← getSubgraph(predecessorsOf F ilterP roc[bestF ilterP roc])
8:
P ipeline ← P ipeline ∪ stdTopSort(subGraph)
9:
removeAllFor(bestF ilterP rocedure)
10: end while
11: return P ipeline
als bestes gewählt werden, welches den besten Effizienzwert aufweist. Dieser Wert
besteht allerdings nicht aus dem Einzelwert von dem jeweiligen Filterverfahren,
sondern errechnet sich aus der Summe der Werte aller Vorgänger des Filterverfahrens, die zu seiner Ausführung notwendig sind, und dem Einzelwert des Verfahrens
selbst. Somit lässt sich für jedes Filterverfahren ein Wert berechnen. Damit ist die
Auswahl des besten Filterverfahrens als das mit dem geringsten zusammengerechneten Effizienzwert möglich. Existieren mehrere beste Werte, so wird, wie schon
bei der Lösung des Algorithmenauswahlproblems, das Verfahren gewählt, dessen
Name lexographisch am niedrigsten ist.
Mit der Liste der Vorgänger des besten Filterverfahrens kann nun ein Teil der
IE-Pipeline generiert werden. Dazu wird der Teilgraph bestimmt, der sich aus
dem Filterverfahren und seinen Vorgängern im Abhängigkeitsgraph zusammensetzt. Dieser Teilgraph wird durch eine normale topologische Sortierung sortiert
(vgl. Abschnitt 2.3.2). Die Knoten des Teilgraph werden dann der Sortierung entsprechend hintereinander der Pipeline hinzugefügt.
Anschließend müssen das Filterverfahren und seine Vorgänger aus dem Abhängigkeitsgraphen gelöscht werden. Außerdem sind die Listen der Vorgänger aller Filterverfahren zu aktualisieren, indem das ausgewählte Verfahren und seine Vorgänger
aus diesen Listen entfernt werden. Danach wird das Ganze mit der Auswahl des
nun besten Filterverfahrens wiederholt. Dieser Prozess wird solange durchlaufen,
bis alle Knoten des Abhängigkeitsgraphen in die IE-Pipeline eingefügt worden
sind. Das Ergebnis ist die berechnete IE-Pipeline.
Algorithmus der eingesetzten topologischen Sortierung
Der Pseudocode für die eingesetzte topologische Sortierung ist in Algorithmus
8 zu sehen. Hierbei wird vorausgesetzt, dass die Aktionen start und f inish aus
dem partiellen Plan schon entfernt wurden. Ansonsten könnte diese Aktionen auch
leicht durch OS des partiellen Plans bestimmt werden, denn start steht dort immer
auf der linken Seiten eine Ordnungsrelation (start < X) und f inish immer rechts
(X < f inish). Die Funktion makeDAG in Zeile 1 erstellt auf die weiter oben
75
beschriebene Weise aus dem partiellen Plan des Partial Order Planners einen
Abhängigkeitsgraph. Im nächsten Schritt in Zeile 2 werden mit getFilterProcedures
die Filterverfahren bestimmt. Filterverfahren sind diejenigen Algorithmen, welche
direkt ein vom Benutzer gesetztes Ziel erfüllen (vgl. Abschnitt 2.4.1). Diese sind
somit leicht im Vorfeld der Planung zu markieren. Dies bedeutet weiterhin, dass
es mindestens ein Filterverfahren geben muss, denn der Partial Order Planner hat
einen partiellen Plan geliefert, der für ein bestimmtes Ziel erstellt wurde. Damit
existiert mindestens ein Ziel und somit ein Filterverfahren. Es ist auch leicht zu
erkennen, dass jeder Knoten ohne ausgehende Kanten im Abhängigkeitsgraph ein
Filterverfahren sein muss. Hat ein Knoten keine ausgehenden Kanten, so wird kein
Effekt der entsprechenden Aktion von einer anderen Aktion als Vorbedingung
verlangt. Damit muss zumindest ein Effekt der Aktion ein Ziel des Benutzers
gewesen sein. Dieser Effekt war nämlich eine Vorbedingung für die Hilfsaktion
f inish, die alle zu erreichenden Teilziele als Vorbedingungen enthält. Ansonsten
hätte der Partial Order Planner die Aktion nie ausgewählt.
Wurden die Verfahren im Vorfeld markiert, so muss für deren Bestimmung einfach nur die Liste AS der im partiellen Plan vorhandenen Aktionen durchlaufen
und dabei der jeder Aktion entsprechende Algorithmus auf die Markierung hin
überprüft werden. Mit den Filterverfahren können dann deren Vorgänger berechnet werden (Zeile 3). Dies geschieht, wie im Konzept bereits beschrieben, durch
Umdrehung der Kanten im Graph und Bildung seiner transitiven Hülle. Für die
Knoten der Filterverfahren können dann deren Vorgänger direkt aus deren Adjazenzliste abgelesen werden. Der Vorgang passiert in der Funktion getPredecessorLists in Zeile 3.
Sind die Vorgänger ermittelt, kann das beste Filterverfahren bestimmt werden.
Dazu wird in Zeile 6 mit getBestFilterProc für jedes Filterverfahren die Laufzeiteffizienzwerte von ihm und seinen Vorgängern bestimmt und dann das mit
dem geringsten Wert gewählt. Der Teilgraph, der sich über die Knoten des Filterverfahrens und seiner Vorgänger erstreckt, wird von getSubgraph in Zeile 7 identifiziert. Dazu werden im Gesamtgraph alle anderen Knoten entfernt. Der Rest ist
der gesuchte Teilgraph.
Die Knoten sind dann gemäß einer normalen topologischen Sortierung in Zeile 8, durchgeführt durch stdTopSort, der zu bestimmenden IE-Pipeline hinzuzufügen. Anschließend werden in Zeile 9 die Knoten aus dem Gesamtgraph und
den Vorgängerlisten der anderen Filterverfahren entfernt. Ein neues, bestes Filterverfahren kann nun bestimmt werden und das Verfahren von Zeile 5 bis Zeile
10 wird solange wiederholt, bis keine Knoten mehr im Graph vorhanden sind.
Einen Beispieldurchlauf ist in Abbildung 4.5 zu sehen. Ausgangspunkt ist die
angegebene partielle Ordnung OS des partiellen Plans. Die Zahlen an den Knoten
des daraus erstellten Abhängigkeitsgraphen geben die Laufzeiteffizienz der hinter
den Knoten stehenden Algorithmen an. Die Filterverfahren sind grau hinterlegt.
In 3. wird anhand dieser Werte zusätzlich zur Liste der Vorgänger auch schon der
aufsummierte Laufzeitwert des Filterverfahrens und seiner Vorgänger angegeben.
In 5. wird die normale, in Abschnitt 2.3.2 vorgestellte, topologische Sortierung
76
OS des Partieller Plans:
(A < B), (A < D), (B < C),
(D < E), (C < F), (E < F)
B
1. DAGErstellung
C
1
2
A
F
1
1
D
2. Umgedrehte
Kanten und
transitive Hülle
E
2
B
2
C
A
3. Liste der
Vorgänger der
Filterverfahren
F
D
C: A, B = 4
E: A, D = 5
F: A, B, C, D, E = 9
E
(mit Gesamtberechnung
für Laufzeitwerte)
4. Teilgraph für
bestes
Filterverfahren
A
5. Hinzufügen an
Pipeline anhand
toplogischer
Sortierung
B
(ist zufällig schon topologisch
sortiert)
A
6. Löschen der
benutzten
Knoten
C
D
B
2
E: D = 4
F: D, E = 5
C
E
2
F
1
(mit Gesamtberechnung
für Laufzeitwerte)
Abbildung 4.5: Ein Beispieldurchlauf der eingesetzten topologischen Sortierung. Die
Zahlen an den Knoten repräsentieren deren Laufzeitkosten.
77
B
Partieller Plan.OS:
(A < B), (A < D), (B < C),
(D < E), (C < F), (E < F)
2
A
F
1
1
D
Nach der
topologischen
Sortierung
C
1
A
B
C
D
E
2
E
2
F
IE-Pipeline
Abbildung 4.6: Resultierende Pipeline aus gegebenem partiellen Plan
genutzt. Nach 6. würde mit den restlichen Knoten in 4. weitergemacht. Die resultierende IE-Pipeline für dieses Beispiel ist in Abbildung 4.6 abgebildet.
4.1.5 Zusätzliche Filter zur Erfüllung von Randbedingungen
Neben den Zielen gibt der Benutzer auch noch Randbedingungen ein, die bei der
Erstellung der Pipeline und bei der Berechnung der Ergebnisse durch die Pipeline
beachtet werden sollen. Ein Lösungsansatz für die Anforderungen an die Qualität
der IE-Pipeline wurde bereits in Abschnitt 4.1.3 vorgestellt. Noch offen ist ein
Lösungsansatz für das Problem der Einschränkungen der Ergebnismenge. Dazu
soll es dem Benutzer möglich sein Wünsche, wie Nur Umsatzaussagen von Unternehmen, die mit M“ beginnen oder Alle Umsatzaussagen zwischen 1999 und
”
2008 dem Expertensystem mitzuteilen. Diese Wünsche müssen vom Expertensystem formalisiert und bei der Ergebnisbestimmung berücksichtigt werden.
Hierfür gibt es zwei mögliche Herangehensweisen:
• Das Filtern der Ergebnismenge nach Ausführung der IE-Pipeline
• Das Einbauen der Berücksichtigung der Einschränkungen in die IE-Pipeline
Beim Filtern der Ergebnismenge wird zuerst die IE-Pipeline auf der in diesem
Kapitel beschriebenen Art und Weise berechnet. Sie wird anschließend ausgeführt
und die Ergebnisse werden bestimmt. Auf dieser Ergebnismenge sind dann die
vom Benutzer geäußerten Bedingungen, wie das alleinige Berücksichtigen von Informationen in einem bestimmten Zeitraum, anzuwenden. Die auf diese Weise
erhaltene gefilterte Ergebnismenge kann dann dem Benutzer präsentiert werden.
Der Vorgang entspricht einem Ablegen der extrahierten Daten in einer Datenbank
und dem Stellen einer anschließenden Anfrage auf diese Daten.
78
Einen großen Nachteil hat dieses Filtern der Ergebnismenge: es kostet Zeit. Zum
einen kostet es Zeit, nach der Berechnung der Ergebnisse noch einmal durch diese
zu iterieren und sie auf Einhaltung der Bedingungen zu überprüfen. Vor allem
aber wäre es sinnvoller, das Herausfiltern von unwichtigen, beziehungsweise nicht
gewünschten Informationen, direkt in der IE-Pipeline während ihrer Ausführung
durchzuführen. Dadurch würde die Menge an Text, auf denen die nachfolgenden
Algorithmen arbeiten, sehr stark eingeschränkt werden, was eine große Effizienzsteigerung der Gesamtpipeline bedeuten würde.
Genau hier setzt der von dieser Arbeit verfolgte zweite Ansatz an. Es werden
Filter als weitere Filterverfahren in die IE-Pipeline integriert. Jedes neue Filterverfahren dient dem einzigen Zweck, eine ganz bestimmte vom Benutzer gewünschte
Einschränkung auf den gegebenen Textstellen zu überprüfen und die Textstellen
heraus zu filtern, in denen diese Einschränkung nicht erfüllt ist. Die neuen Filter
werden dabei direkt hinter den Algorithmen in der IE-Pipeline platziert, die die
Annotationen erzeugen, welche die vom Filter zu überprüfende Einschränkung betreffen. Die Einschränkung Alle Umsatzaussagen zwischen 1999 und 2008 würde
in einen Filter übersetzt, der für alle Annotationen vom Typ Umsatzaussage überprüft, ob ihr Zeitraum zwischen 1999 und 2008 liegt. Der Filter könnte daher an
zwei Stellen in die IE-Pipeline integriert werden. Die erste Stelle wäre nach dem
Algorithmus, der Umsatzaussagen im Text identifiziert. Hierbei kann allerdings
ein Problem entstehen. Umsatzaussagen könnten unabhängig von einem Zeitraum
identifiziert werden. Der entsprechende Zeitraum würde erst danach in der Pipeline identifiziert und mit der Umsatzaussage verknüpft. Dann wäre der Filter an
der falschen Stelle eingefügt worden und könnte seine Aufgabe nicht erfüllen. Der
Filter müsste daher hinter der Stelle in die Pipeline platziert werden, an der die
Zeiträume identifiziert werden. Nur hier ist sichergestellt, dass er korrekt arbeitet.
Dies ist ein Spezialfall, da das Ereignis Umsatzaussage unabhängig von der Entität
Zeitraum bestimmt werden kann. Ein allgemeinerer Filter zu Nur Unternehmen
beachten, die mit M“ beginnen hat nur die eine Möglichkeit der Ausführung hinter
”
dem Algorithmus, der die Entität Unternehmen identifiziert.
Beim Einfügen eines Filter in die IE-Pipeline müsste also darauf geachtet werden, dass er nach dem Algorithmus eingefügt wird, der den Annotationstyp identifiziert, auf den sich die eigentliche Einschränkung bezieht. Ein Filter, der Umsatzaussagen in einem bestimmten Zeitraum filtern soll, müsste daher eine Platzierung
direkt nach der Bestimmung dieser Zeiträume in einem Text erfahren und nicht
hinter der Stelle, an der die Umsatzaussagen identifiziert werden. Dieser Ansatz
hat allerdings den Nachteil, dass andere IE-Verfahren, die zum Beispiel die identifizierten Zeiträume für etwas anderes als Umsatzaussagen weiter benutzen, nicht
mehr alle Informationen bekommen. Ein Beispiel für dieses Problem wäre ein Ereignis Gerichtsverfahren(Richter, Angeklagter, Anwalt). Ein Filter Nur Gerichtsverfahren, bei denen der Angeklagte Max Mustermann“ heißt und die Tatsache,
”
dass Richter, Angeklagter und Anwalt alles Entitäten vom Annotationstyp Person
sind, zeigt das Problem. Wenn der Filter direkt hinter dem Algorithmus, der Personen erkennt, ausgeführt wird, und dann alle Textstellen heraus filtert, in denen
79
die Person Max Mustermann nicht gefunden wurde, verhält sich der Filter falsch
und die IE-Pipeline wird nicht die gewünschten Ergebnisse liefern. Hierbei würden
nämlich auch die potenziellen Richter und Anwälte mit herausgefiltert werden.
Es ist somit nötig, die Filter an der Stelle in die Pipeline einzufügen, an der alle
von der Einschränkung betroffenen Annotationstypen vorliegen. Allerdings sind
Ereignisse und Relationen normalerweise die Ziele einer IE-Pipeline. Das bedeutet,
ein Filter, der so eine Einschränkung überprüft, würde erst sehr spät oder ganz
am Ende der Pipeline auftreten. Dadurch würde die erhoffte Beschleunigung der
IE-Pipeline durch das Einsetzen der Filter klein bis nicht vorhanden ausfallen.
Das Verfahren ähnelte damit der genannten Filterung der Gesamtergebnismenge.
Demnach ist es dem Benutzer zu überlassen, ob er zum Beispiel alle Zeiträume
filtern möchte, oder nur die Zeiträume von Umsatzaussagen. Die erstgenannte
Möglichkeit bietet zudem noch die Möglichkeit, das Verfahren, welches Zeiträume
identifiziert, im Vorfeld der Planung als Filterverfahren zu markieren. Das in diesem Kapitel beschriebene Planungsverfahren wird diese Information automatisch
dafür einsetzen, eine bessere IE-Pipeline zu konstruieren, indem das Paradigma
Early Filtering während der angepassten topologischen Sortierung beachtet wird.
Bei der zweiten Möglichkeit ist dies nicht möglich, da im Vorfeld nicht bestimmt
werden kann, ob zum Beispiel erst der Algorithmus zur Erkennung von Umsatzaussagen oder der Algorithmus zur Erkennung von Zeiträumen laufen wird. Daher
kann auch nicht gesagt werden, hinter welchem von beiden Algorithmen der Filter in der resultierenden IE-Pipeline ausgeführt wird und demnach nicht, welches
Verfahren dadurch wirklich zu einem Filterverfahren wird.
4.1.6 Ausführung der IE-Pipeline zum Erhalt der Ergebnisse
Die IE-Pipeline wurde vom Planungsverfahren bestimmt, unter Berücksichtigung
der vom Benutzer angegebenen Ziele und Randbedingungen, und dieser Pipeline
sind die Filter, entsprechend den gewünschten Einschränkungen des Benutzers,
hinzugefügt worden. Dann gilt es, diese abstrakte IE-Pipeline in eine konkrete zu
verwandeln, sie auf der vom Benutzer angegebenen Textmenge auszuführen und
die erzielten Ergebnisse wieder an den Benutzer zurückzugeben. Genau diesen
Zweck verfolgt die IE-Pipeline-Ausführungskomponente. Die Überführung der berechneten, abstrakten IE-Pipeline in eine konkrete ist sehr stark davon abhängig,
welches zugrundeliegende IE-Framework benutzt wird. Dieses IE-Framework bestimmt außerdem die Ausführung der Pipeline und die Aggregation der Ergebnisse.
Daher wird die Realisierung dieser Komponente anhand des in dieser Arbeit verwendeten UIMA-IE-Frameworks erst in Kapitel 5 erläutert. Allerdings ist es durch
die Trennung von Berechnung und Ausführung der IE-Pipeline direkt möglich, eine andere Ausführungskomponente für ein anderes Framework einzusetzen, ohne
dafür die Komponente des domänenspezifischen Planers oder die Randbedingungsfilter anpassen zu müssen. Es wäre demnach auch möglich, komplett auf ein IEFramework zu verzichten und das Hintereinanderausführen und Verschalten von
IE-Algorithmen direkt in der Ausführungskomponente durchzuführen.
80
4.2 Die Wissensbasis des Expertensystems
Die Wissensbasis ist ein wesentlicher Bestandteil eines Expertensystems. Auf Basis
des in der Wissensbasis hinterlegten Wissens, kann das Expertensystem die Probleme lösen, für die es konstruiert wurde. Wie in den vorangegangenen Abschnitten
dargelegt, besitzt das in dieser Arbeit entwickelte Expertensystem eine speziell an
das Problem der Konstruktion der IE-Pipeline angepasste Problemlösungskomponente. Obwohl diese Komponente schon Domänen- und demnach auch Expertenwissen in sich trägt, benötigt sie für ihre Arbeit noch weiteres Wissen. Das
betrifft zum Beispiel die Menge an vorhandenen IE- und NLP-Algorithmen, aus
denen sich eine zu berechnende Pipeline zusammensetzen kann. In diesem Zusammenhang ist auch das Wissen um die benötigten und erzeugten Annotationen der
Algorithmen von Bedeutung. Die unterschiedlichen Annotationen haben einen unterschiedlichen Typ. Auch dieses Wissen muss der Problemlösungskomponente zur
Verfügung stehen. Außerdem sind die möglichen Gütekriterien, ob diese miteinander verrechenbar sind oder nicht, oder auch, welche Priorisierungen der Benutzer
angeben kann, ebenfalls Wissen, welches in der Wissensbasis untergebracht werden
muss.
Damit dieses Wissen für die Problemlösungskomponente verfügbar ist, muss es
in einer formalen und für den Computer verarbeitbaren Form in der Wissensbasis vorliegen. Als diese formale Wissensrepräsentation wurde in dieser Arbeit die
Form der Ontologie gewählt. Mit der eigentlichen Ontologie, den in ihr benötigten
Begriffen und Beziehungen, beschäftigt sich der Abschnitt 4.2.1. In Abschnitt 4.2.2
wird auf der Basis dieser Informationen vorgestellt, warum als Wissensrepräsentation der Wissensbasis die Ontologie gewählt wurde. Die Wissenserwerbskomponente ist eng mit der Wissensbasis verbunden. Die in dieser Arbeit verwendete Wissenserwerbskomponente arbeitet vollautomatisch, was ein Unterschied zu den in
Abschnitt 2.1.2 betrachteten Expertensystemen ist. Warum dieser Ansatz gewählt
worden ist und welche Vorteile dies bringt, wird in Abschnitt 4.2.3 dargelegt. Eine Komponente, die in den betrachteten Expertensystemen nicht auftauchte, ist
das Datenmodell. Es wird zusammen mit den Gründen für dessen Einführung in
Abschnitt 4.2.4 vorgestellt.
4.2.1 Konzept der entwickelten Ontologie
Als Ontologieform ist der W3C Standard OWL-DL gewählt worden. Dieser Standard wurde bereits in Abschnitt 2.2.2 vorgestellt. Der Inhalt der entwickelten
Ontologie enthält das Expertenwissen, welches die Problemlösungskomponente
braucht, um ihre Aufgabe, die Konstruktion und anschließende Ausführung einer IE-Pipeline, durchführen zu können. Die Problemlösungskomponente enthält
ihrerseits schon viel Expertenwissen, so zum Beispiel das Wissen um die Paradigmen zum Aufbau effizienter IE-Pipelines. Dieses Wissen braucht daher nicht Bestandteil der Ontologie zu sein. Allerdings kennt die Problemlösungskomponente
weder konkrete Algorithmen und Annotationstypen noch konkrete Gütekriterien
81
0..1
Annotationstyp *
Typensystem
hatAnnotationshatSupertyp
typ
1
1
hatAnnotationstyp
hatAnnotationstyp
hatOrdnung
1..*
*
*
Informations- 1
typ
hatZuhatAktivesFilterndenAttribut
* 1..*
Typ
hatEingabe
hatFiltereigenschaft
Gütekriterium
subKlasseVon
1
Effektivitätskriterium
1
hatKriterium
*
hatGüte
Effizienzkriterium
subKlasseVon
Filter
hatAusgabe
Algorithmus
1
Filtereigenschaft
hatAttribut
Attribut
Ordnung
Priorität
Güte
0..1
hatGütekriterium
hatNachfolger
1
hatPrioritätsreihenfolge
0..*
Priorisierung
impliziert
Abbildung 4.7: Ontologie des Expertensystems
wie Recall oder Precision. Auch die in Abschnitt 4.1.3 vorgestellte Methode zur
Berücksichtigung von Qualitätsanforderungen des Benutzers an die zu konstruierende Pipeline ist eine generische Methode und trägt in sich keine Informationen
über die in Abbildung 4.3 dargestellten, möglichen Priorisierungen. Daher können
diese Priorisierungen in die Ontologie ausgelagert werden und stehen somit einer
einfachen und schnellen Bearbeitung offen.
In Abbildung 4.7 ist die entworfene Ontologie dargestellt. Die grafische Notation
wurde bereits in Abschnitt 2.2.2 eingeführt. Die zentralen Klassen Algorithmus,
Annotationstyp, Filter und Gütekriterium sind, zum einfacheren Wiederfinden,
stärker umrandet als die restlichen Klassen. Im Folgenden wird auf die Einzelheiten der Ontologie eingegangen.
Einzelheiten der Ontologie
Die Annotationstypen sind in einem Typensystem enthalten. Dieses Typensystem
besitzt eine beliebige Menge an Annotationstypen. Annotationstypen sind hierarchisch in einer Klassenhierarchie angeordnet. So kann beispielsweise der konkrete Annotationstyp Person eine Unterklasse von Entität sein. Deshalb ist es
möglich, dass jede Annotation einen Superannotationstyp hat, ausgedrückt mit
der Eigenschaft hatSupertyp. In der Information Extraction und NLP existiert kein
einheitliches, anerkanntes Typensystem. Die vier Arbeiten [HBT+ 07], [KNS+ 08],
82
[EBPL08] und [KDM+ 10] zeigen zum Beispiel vier verschiedene Typensysteme.
Da selbst in der Informationen Extraction und NLP keine einheitliche Vorstellung von einem einzigen Typensystem existiert, versucht diese Arbeit nicht, eine
zusätzliche eigene Lösung dafür anzubieten. Stattdessen wird ein konkretes Typensystem offen gelassen und nur der Rahmen für dessen Anlegung geschaffen. So
kann jeder Annotationstyp in der Ontologie neben einem möglichen Superannotationstyp auch noch eine Reihe von Attributen besitzen. Jedes Attribut hat wieder
einen Annotationstyp. Mit diesem Konstrukt lassen unter anderem Relationen
und Ereignisse leicht abbilden. Eine Relation Eheleute(PersonA, PersonB) wäre
ein Annotationstyp Eheleute mit den zwei Attributen PersonA und PersonB. Die
beiden Attribute könnten wiederum den Annotationstyp Entität haben. Da Ereignisse auch als mehrstellige Relationen aufgefasst werden können (vgl. Abschnitt
2.4), lassen sich diese in der gleichen Art modellieren. Eine konkrete Typenhierarchie wird entweder per Hand von einem Experten vor Gebrauch des Expertensystems angelegt, oder mithilfe der Wissenserwerbskomponente importiert (siehe
Abschnitt 4.2.3). Die bisher aufgezählten Klassen und Eigenschaften der Ontologie orientieren sich an den in Abschnitt 2.4.1 dargelegten Beschreibungen der
Domäne IE und konnten außerdem in verschiedenen IE-Frameworks (UIMA2 und
GATE3 ) in der dargestellten Art identifiziert werden. Die Typensysteme in den
vier erwähnten Arbeiten wiesen ebenfalls eine ähnliche Struktur, wie der vorgestellte Teil der Ontologie, auf.
Einheitliche Vorstellungen über konkrete Algorithmen, insbesondere was deren
benötigte und erzeugte Annotationen betrifft, sind weder in der IE noch in der
NLP zu finden. Dies ergibt sich natürlich auch aus dem Gebrauch von ganz verschiedenen Typensystemen, wie oben bereits erwähnt. Allerdings lassen sich für
die Algorithmen ein paar Grundeigenschaften identifizieren, die sich vor allem aus
den Anforderungen an diese Algorithmen aus dem Konzept des Planungsverfahrens aus Abschnitt 4.1 ergeben. So haben die Algorithmen benötigte Annotationstypen, abgebildet durch hatEingabe, und sie erzeugen neue Annotationen eines
bestimmten Typs, abgebildet durch hatAusgabe. Während ein Algorithmus, der
keine Informationen liefert und somit nichts erzeugt, im Kontext der IE-Pipeline
nicht benötigt wird, kann es sein, dass ein Algorithmus keine am Text annotierten
Informationen für seine Arbeit benötigt, und demnach auch keine Eingabe besitzt.
Die Ein- und Ausgaben der Algorithmen werden durch die Klasse Informationstyp abgebildet. Jedes Individuum von ihr bezieht sich auf einen Annotationstyp
(hatAnnotationstyp) und kann eine Reihe von aktiven Attributen besitzen (hatAktivesAttribut). Durch die Angabe von aktiven Attributen ist es möglich anzugeben,
dass ein Algorithmus nicht alle Attribute eines Annotationstyps benötigt oder erzeugt. So kann für ein Ereignis Treffen(PersonA, PersonB, Ort, Zeitraum) ein
Algorithmus existieren, der nur herausfindet, ob sich in den Textstellen ein Ereignis Treffen befindet, ohne dass er die einzelnen Attribute dafür bestimmt. Hier
2
3
http://docs.oasis-open.org/uima/v1.0/uima-v1.0.html
http://gate.ac.uk/overview.html
83
ist eine Komposition von Annotationstypen und aktiven Attributen gewählt worden, anstatt eine Subklasse von Annotationstyp einzuführen. Dies hat den Grund,
dass jeder Annotationstyp, wie etwa Token, nur einmalig in der Ontologie und
im Typensystem vorkommen soll. Bei einer Modellierung als Vererbung würden
allerdings auch alle Ein- und Ausgaben der Algorithmen, als eigenständige Annotationstypen, mit zu dem Typensystem gehören, was so nicht korrekt ist.
Algorithmen haben, wie bereits schon erwähnt, eine bestimmte Güte, also für
bestimmte Gütekriterien Werte. In der Ontologie ist dies dadurch ausgedrückt,
dass konkrete Algorithmen mit Individuen der Klasse Güte verknüpft sind über
die Eigenschaft hatGüte. Jeder Güte lässt sich dabei einem bestimmten Gütekriterium zuordnen. So kann ein Algorithmus Tokenisierer als Güte den Wert 0, 9
für das Gütekriterium Accuracy besitzen (zum Ausdrücken des konkreten Wertes
wird im nächsten Abschnitt eine neue Eigenschaft eingeführt). Über ein Individuum von Güte werden also ein Gütekriterium und seine konkrete Ausprägung für
einen Algorithmus mit eben diesem Algorithmus verknüpft. Jedes in der Ontologie
vorliegende Gütekriterium liegt einmalig als Individuum der Klasse Gütekriterium, beziehungsweise einer der Subklassen von Gütekriterium, vor. Dies hat den
Vorteil, dass nicht viele verschiedene Individuen von beispielsweise einer Klasse
Recall behandelt werden müssen. Dadurch ist es aber notwendig, das Gütekriterium nicht direkt mit einem Algorithmus und einem Wert zu verknüpfen. So
würden ansonsten eine Menge an Algorithmen auf das Individuum Recall verweisen und Recall selbst mit verschiedenen konkreten Werten verknüpft sein. Dann
ist aber keine eindeutige Zuordnung der Werte zu den einzelnen Algorithmen mehr
möglich.4
Die Gütekriterien teilen sich auf in die beiden Klassen Effizienzkriterium und
Effektivitätskriterium. Dabei hat jedes Gütekriterium eine Ordnung. Diese Ordnung gibt an, ob niedrigere Werte oder höhere Werte besser oder schlechter sind.
So ist der Recall umso besser, je höher sein Wert ist. Bei der Laufzeiteffizienz ist
es allerdings genau umgekehrt. Hier sind diejenigen Werte besser, die niedriger als
alle anderen sind. Die Randbedingungen für die Anforderungen an die Qualität der
zu konstruierenden IE-Pipeline aus Abschnitt 4.1.3 sind ebenfalls in der Ontologie
berücksichtigt. So kann mithilfe der Klasse Priorisierung eine Prioritätsreihenfolge zwischen Gütekriterien angeben werden. Jede Priorisierung hat eine Prioritätsreihenfolge (hatPrioritätsreihenfolge). Eine Prioritätsreihenfolge besteht aus
einer Priorität, die für ein ganz bestimmtes Gütekriterium steht (hatKriterium).
Außerdem kann jede Priorität einen Nachfolger haben (hatNachfolger ), wodurch
es möglich ist, eine Prioritätsreihenfolge aufzubauen. So zeigt eine Priorisierung
auf den Kopf einer Prioritätsreihenfolge, von wo aus diese Reihenfolge durchlaufen
werden kann. Damit lässt sich zum Beispiel die Priorisierung F1 Rt ausdrücken,
wenn man sich bei der Laufzeiteffizienz auf ein Effizienzkriterium festlegt. Es kann
allerdings sein, dass F-Measure und Recall bei den untersuchten Algorithmen nicht
4
Eine Begründung, wann es sinnvoller ist Individuen anstatt Subklassen einzusetzen, ist hier
zu finden: http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DesignForUse
84
Eigenschaft
Grundbereich
Wertebereich
hatKonkretenWert
istVerrechenbar
hatImplementierungsKlasse
hatName
hatDatentyp
Güte
Gütekriterium
Algorithmus und Filter
Thing
FilterEigenschaft
string
boolean
string
string
string
Tabelle 4.1: Datatype Properties der Ontologie
vorhanden sind. Mithilfe der Eigenschaft impliziert kann der Priorisierung eine andere Priorisierung zugeordnet werden, die vom Expertensystem in einem solchen
Fall genommen wird. Dies könnte die Priorisierung tA sein, mit der Effizienz vor
Accuracy ausgedrückt werden soll.
Der Benutzer gibt an, welche Einschränkungen er auf der Ergebnismenge haben
möchte. Wie in Abschnitt 4.1.5 bereits beschrieben, wird dies in dieser Arbeit mit
der Hilfe von in die IE-Pipeline einzufügender Filter gemacht. Diese Filter finden
sich auch in der Ontologie wieder. Damit weiß das Expertensystem, auf welche
Filter zurückgegriffen werden kann. Jeder Filter hat einen Annotationstyp, den er
filtert (hatZuFilterndenTyp). Da es möglich sein soll, dass der Filter nur bestimmte
Attribute einer Annotation betrachtet, etwa nur die Person A von einem Ereignis
Treffen, ist dies dadurch gelöst, dass er nicht den Annotationstypen direkt, sondern
indirekt über ein Informationstyp Objekt erhält. Außerdem hat ein Filter eine
Menge von Filtereigenschaften. Dies kann für einen Filter, der Zeiträume filtert,
das Anfangs- und Enddatum für den zu filternden Zeitraum sein.
Weitere Aspekte der Ontologie
Neben den vorgestellten Klassen und den Beziehungen zwischen diesen Klassen
gibt es in der Ontologie noch Eigenschaften der Klassen, die nicht in Abbildung
4.7 zu sehen sind. Diese Eigenschaften beziehen sich in ihrem Wertebereich nicht
auf Individuen, sondern auf primitive, in OWL-DL eingebaute Datentypen, wie
String oder Boolean. Daher nennt man diese Eigenschaften in OWL-DL auch
DatatypeProperties. Diese Eigenschaften sind in Tabelle 4.1 abgebildet.
Jede Güte eines Algorithmus hat, neben einem konkreten Gütekriterium, einen
konkreten Wert vom Typ String. Im Allgemeinen, wie etwa bei Recall -Werten,
ist dieser Wert eine Fließkommazahl, allerdings ist es durch die Verwendung von
String möglich, den Text falls benötigt in eine Zahl umzuwandeln. Außerdem sind
hiermit zum Beispiel auch Werte groß, mittel, klein möglich, falls keine Zahlenwerte genommen werden können. Die Eigenschaft istVerrechenbar eines Gütekriteriums wird von der in Abschnitt 4.1.3 beschriebenen Lösung des Algorithmenauswahlproblems gebraucht. Recall -Werte können zum Beispiel nicht miteinander
verrechnet werden, die Werte eines Effizienzkriteriums wie Averaged Efficiency
dagegen schon (siehe Abschnitt 2.4.3). Mithilfe dieser Eigenschaft kann dies für
85
ein beliebiges Gütekriterium ausgedrückt werden.
Die Algorithmen innerhalb der Planung sind als Aktionen dargestellt. Nach der
Planung muss die konstruierte IE-Pipeline allerdings ausgeführt werden. Dafür
wird die konkrete Implementierungsklasse benötigt, die jeder Algorithmus der Ontologie mit der Eigenschaft hatImplementierungsKlasse besitzt. Etwas universelles
haben alle Elemente der Ontologie gemein: Sie alle können benannt werden. Dies
geschieht durch die Eigenschaft hatName, die für die Klasse Thing definiert ist.
Diese Klasse Thing ist die Basisklasse für alle Klassen der Ontologie, alle anderen Klassen sind automatisch von ihr abgeleitet (ähnlich der Object-Klasse in der
Programmiersprache Java). Damit ist es möglich, allen Individuen die Eigenschaft
hatName zuzuweisen. Die Eigenschaft hatDatentyp weist jeder Filtereigenschaft
einen Datentyp zu. Somit kann die Eigenschaft vonDatum eines Datumsfilters
den Datentyp String haben. Es ist nicht sinnvoll, alle möglichen Filter in der Ontologie abzubilden. Daher werden die genannten Ontologieeigenschaften der Filter
genutzt, um in der grafischen Oberfläche nicht nur die zu Verfügung stehenden
Filter aufzuzeigen, sondern auch die vom Benutzer für diese Filter benötigten
Eingaben dynamisch bestimmen zu können.
Die endgültige Ontologie enthält ferner eine Reihe von Individuen. Die meisten
dieser Individuen sind abhängig von dem verwendeten IE-Framework, wie etwa
konkrete IE-Algorithmen. Eine umfassende Darlegung der in der endgültigen Ontologie vorhandenen Individuen wird daher erst im folgenden Kapitel 5 gegeben.
4.2.2 Begründung für eine Ontologie als Wissensbasis
Mit den aus dem vorherigen Abschnitt identifizierten, notwendigen Informationen,
die in der Wissensbasis des Expertensystems vorhanden sein müssen, lässt sich
nun die Wahl einer Ontologie für die formale Wissensrepräsentation begründen.
In Abschnitt 2.2.1 wurden verschiedene Möglichkeiten vorgestellt, wie Wissen in
einem Expertensystem repräsentiert werden kann. In den reinen Formen der Logik,
wie zum Beispiel Aussagenlogik oder Prädikatenlogik, kann es kompliziert sein,
umfangreiches Wissen auszudrücken. Außerdem ist das Wissen in diese Art der
Repräsentation schwierig zu warten. Da aber die Verständlichkeit der Wissensbasis
eine Anforderung an deren Repräsentationsform ist, sind diese Formen der Logik
nicht genutzt worden.
Viele Expertensysteme setzen auf Regelsysteme als Wissensbasis. Das Wissen ist
in den Wenn-Dann-Regeln gespeichert und es reicht ein allgemeiner Inferenzmechanismus, um Schlussfolgerungen auf Basis der Regeln zu ziehen. Regelsysteme
eignen sich vor allem für die Klassifikation oder Synthese als Aufgabenbereich
des jeweiligen Expertensystems, wie die in Kapitel 3 betrachteten Expertensysteme aus diesen Bereichen zeigen. Das Expertensystem dieser Arbeit fällt aber, wie
schon gesagt, in den Bereich der Konstruktion. In diesem Bereich lässt sich keine
eindeutige Präferenz von einer bestimmten Wissensrepräsentationsform erkennen.
Das im letzten Abschnitt identifizierte Wissen benötigt allerdings keine Regelform.
Ein Großteil des Wissens um die Konstruktion einer IE-Pipeline ist in der spe-
86
ziell an die Domäne angepasste Problemlösungskomponente zu finden. Weiterhin
wird kein vages oder unsicheres Wissen verwendet. Etwaiges vages Wissen, wie
es zum Beispiel Laufzeitwerte eines Algorithmus in Form eines Average Sentence
Response Time-Wertes sein können, wird innerhalb des Expertensystems als sicheres Wissen angesehen. Aus diesem Grund scheidet auch die Fuzzy-Logik als
Repräsentationsform des Wissens aus.
Die Ontologie als Form der Wissensrepräsentation gehört zu den vorgestellten
objektorientierten Formen. Als Ontologieform wurde die in Abschnitt 2.2.2 vorgestellte Web Ontology Language (OWL-DL) gewählt. Sie bietet eine Reihe von
Vorteilen gegenüber den gerade erwähnten, anderen Formen:
• Werkzeugunterstützung: Es existieren für OWL Werkzeuge, die das Erstellen
und Editieren von in OWL verfassten Ontologien stark vereinfachen, wie das
von dieser Arbeit für den Ontologieentwurf genutzte Protégé. Dadurch wird
eine einfache Verständlich- und Erweiterbarkeit der Ontologie unterstützt.
• Hohe Verbreitung: Es existieren viele Arbeiten, die schon erfolgreich OWLOntologien eingesetzt haben, siehe auch Kapitel 3.
• Existierende Reasoner : Für OWL existieren schon eine Vielzahl von Schlussfolgerungswerkzeugen, wie die in Abschnitt 2.3.1 erwähnten Pellet und FaCT++.
• Ontologie Standard : OWL ist ein Standard unter den Ontologien und eine
Empfehlung des W3C (vgl. Abschnitt 2.2.2).
Der Nachteil von OWL ist der schon beschriebene, möglicherweise hohe Aufwand für das Schlussfolgern. Die erstellte Ontologie ist allerdings relativ einfach
gehalten worden. Dies kommt einem geringen Aufwand beim Schlussfolgern entgegen, da keine komplizierten Konstrukte von OWL genutzt werden. Aus diesem
Grund kann auch auf die Evaluierung eines für die gewählte Ontologie besten
Reasoners verzichtet werden, denn selbst der Standard-Reasoner5 des eingesetzten Ontologie-Framework ist für die an die Ontologie herangetragenen Probleme
bestens geeignet. Aufgrund der einfachen Ontologie sind hauptsächlich die in Abschnitt 2.3.1 vorgestellten Inferenzprobleme der Instanzüberprüfung und das der
Klasseninstanzen interessant. Dies hängt auch damit zusammen, dass die Wissenserwerbskomponente des Expertensystems keine neuen Klassen in die Ontologie
einfügt, sondern nur neue Individuen bereits bestehender Klassen.
4.2.3 Hinzufügen von neuem Wissen in die Ontologie
Im Allgemeinen ist die Wissenserwerbskomponente eine Schnittstelle für Experten oder Entwickler, um manuell das Wissen des Expertensystems zu bearbeiten
(vgl. Abschnitt 2.1.2). Für [Pup91] kann das Expertensystem aber auch Wissen
5
Zum Einsatz kam das Framework Jena: http://incubator.apache.org/jena/
87
automatisch aus Falldaten ableiten. Etwas ähnliches wird in dieser Arbeit mithilfe
der Wissenserwerbskomponente gemacht.
Die in Abschnitt 4.2.1 vorgestellte Ontologie ist vollständig, was ihre Klassen
und Eigenschaften angeht. Allerdings sind noch keine Individuen der Klassen in
der Ontologie vorhanden. Vor allem fehlen die vom Expertensystem zu berücksichtigen konkreten Algorithmen, sowie die möglichen Annotationstypen in Form
eines Typensystems. Die zur Verfügung stehenden Algorithmen und die von ihnen
gebrauchten Annotationstypen können nicht universell für die Domäne Information Extraction identifiziert werden. Innerhalb der Information Extraction lässt
sich zum Beispiel noch kein einheitliches Übereinkommen identifizieren, welche
Arten von Algorithmen es geben muss und vor allem, welche Art von Algorithmus
welche benötigten und erzeugten Annotationstypen hat. Darüber hinaus gibt es,
wie schon in Abschnitt 4.2.1 angesprochen, keinen Konsens über eine einheitliche
Typenhierarchie. Aus diesem Grund ist es die Aufgabe der Wissenserwerbskomponente, diese fehlenden und für jedes genutzte IE-Framework eventuell unterschiedlichen Informationen über externe Quellen in die Ontologie zu übertragen.
Die Art, in der diese Informationen vorliegen, kann sehr unterschiedlich sein. So
liegen sie bei dem eingesetzten IE-Framework UIMA in Form von XML-Dateien
vor, die die zur Verfügung stehenden Algorithmen und die zu verwendende Annotationstypenhierarchie beschreiben.
Der manuelle Wissenserwerb ist allerdings nicht unmöglich. Das Wissen der Ontologie kann mithilfe von frei verfügbaren Werkzeugen, wie dem schon erwähnten
Ontologieeditor Protégé, manuell verändert und erweitert werden. So können sich
auf einfache Art und Weise alle bestehenden Klassen, Eigenschaften und Individuen einer Ontologie, sowie deren Abhängigkeiten angesehen werden. Ein weiterer
Aspekt ist das Nutzen von Reasonern, wie Pellet oder FaCT++, um etwa schon
im Editor die Konsistenz, also die Widerspruchsfreiheit, der Ontologie feststellen
zu lassen. Dieses sehr mächtige Werkzeug nachzubilden, liegt außerhalb des Fokus
dieser Arbeit. Daher wird der manuelle Wissenserwerb durch das Expertensystem
nicht direkt unterstützt. Es wird empfohlen, hierfür einen externen Ontologieeditor zu verwenden, wobei sich Protégé im Rahmen dieser Arbeit als für diese
Aufgabe besonders geeignet herausgestellt hat.
Die konkreten Algorithmen und eine konkrete Typenhierarchie sind abhängig
von dem verwendeten IE-Framework. Daher wird auf diesen Aspekt und die genaue Übertragung dieser Informationen in die Ontologie erst in Abschnitt 5.2
eingegangen.
4.2.4 Kapselung der Ontologie durch ein Datenmodell
Die Einführung eines Datenmodells ist in einer normalen Expertensystemarchitektur, wie sie [Pup91] oder [Hau00] empfehlen, nicht vorgesehen. Sie bietet jedoch
in dem von dieser Arbeit entwickelten System einige Vorteile, die im Folgenden
beschrieben werden sollen.
Als Datenmodell wird in dieser Arbeit eine Abstraktionsschicht zwischen Pro-
88
4.3 Anfragen an das Expertensystem
blemlösungskomponente und Wissensbasis bezeichnet. Diese Schicht erfüllt vor
allem den Zweck, die Zugriffe auf die Wissensbasis zu kapseln und das in ihr
verfügbare Wissen für die anderen Komponenten des Expertensystems verfügbar
zu machen. Für diesen Zweck existieren für die wichtigsten Elemente der Ontologie
(wie zum Beispiel Annotationstyp oder Algorithmus) Datenklassen, die aus der
Ontologie extrahiertes Wissen speichern und es damit etwa der Problemlösungskomponente schnell zur Verfügung stellen können. Zudem existieren für diese Datenklassen verschiedene Helferklassen, welche die benötigten Informationen, etwa
über die verschiedenen Algorithmen, aus der Ontologie extrahieren und somit
Funktionalitäten des Datenmodells für die anderen Komponenten des Expertensystems anbieten. Die einzelnen Komponenten des Expertensystems können daher
nicht direkt auf das Wissen der Ontologie zugreifen, sondern sind auf die angebotenen Funktionen des Datenmodells angewiesen (genauere Informationen über
das Datenmodell finden sich im späteren Abschnitt 6.1.2).
Dieses Vorgehen ist nur deshalb praktikabel, weil innerhalb der Problemlösungskomponente bereits viel Expertenwissen fest eingebaut ist. Daher sind die benötigten Informationen aus der Wissensbasis leicht identifizierbar. Somit können die bekannten Anfragen von der Problemlösungskomponente wie Gib mir alle verfügbaren Algorithmen oder Ist das Attribut M von Annotation A ein Attribut eines
Supertyps von A? über das Datenmodell beantwortet werden. Das Datenmodell
kann dabei bereits gewonnenen Erkenntnisse zwischenspeichern und nur bei Bedarf
die Anfrage an die Wissensbasis weiterleiten. Dies stellt einen großen Vorteil des
Datenmodells dar. Wie in Abschnitt 2.3.1 und in manchen Arbeiten aus Kapitel
3 bereits dargelegt, kann das Ziehen von Schlussfolgerungen in OWL Ontologien sehr lange dauern. Durch einen Zwischenspeicher im Datenmodell kann daher
ein Effizienzvorteil erzielt werden. Dieses Zwischenspeichern ist auch deswegen
möglich, weil die Ontologie selbst relativ einfach ist. Sie verändert sich während
der Ausführung des Expertensystems nicht. Der einzige Fall, indem sich die Ontologie ändern kann, ist, wenn der Benutzer mithilfe der Wissenserwerbskomponente
neues Wissen einliest. Dann muss auch der Zwischenspeicher gelöscht werden.
Ein weiterer, vielleicht noch wichtigerer Vorteil ergibt sich durch die Kapselung
der Wissensbasis. Hiermit wird es möglich, bei Bedarf die Form der Wissensrepräsentation der Wissensbasis auszuwechseln. Hierfür müssen nur Anpassungen
im Datenmodell gemacht werden. Die hierfür zu treffenden Änderungen bleiben
somit im Expertensystem lokal begrenzt.
Nachdem in den vorherigen Abschnitten vor allem die Problemlösungskomponente
und die Wissensbasis im Vordergrund standen, sollen in diesem Abschnitt mit der
Interviewerkomponente und der Erklärungskomponente die Benutzerschnittstellen
des Expertensystems vorgestellt werden. Bei der Vorstellung der Interviewerkomponente geht es vor allem darum, noch einmal zusammenzufassen, welche Informa-
89
tionen vom Benutzer in welcher Form in das Expertensystem übertragen werden
müssen, damit dieses korrekt arbeiten kann. Auf den Benutzerschnittstellen des
Expertensystems lag nicht der Fokus dieser Arbeit. Allerdings wird in späteren
Kapiteln (vgl. Kapitel 6) dargestellt, dass die Benutzerschnittstellen als sehr einfach austauschbar konzipiert sind. Somit kann das Expertensystem leicht an neue
Umgebungen, etwa den Einsatz innerhalb eines Webservices, angepasst werden.
4.3.1 Eingaben in das Expertensystem
Der Benutzer muss in irgendeiner Art und Weise das Expertensystem steuern und
das zu lösende Problem hinsichtlich der Konstruktion der IE-Pipeline eingeben
können. Das betrifft vor allem die in Abschnitt 4.1 erwähnten Ziele, die die IEPipeline finden soll und die Randbedingungen, wie Filter und Priorisierungen, die
die IE-Pipeline dabei einhalten muss. Das in dem Abschnitt erläuterte Verfahren
zur Konstruktion einer IE-Pipeline ist, nachdem das Problem in das Expertensystem eingegeben wurde, nicht mehr auf die Mitarbeit des Benutzers angewiesen. Dies ist beispielsweise in einigen vorgestellten Expertensystemen aus Kapitel
3 der Fall, bei denen das System Rückfragen an den Benutzer stellt. Das Fehlen solcher Rückfragen, also die autonome Lösung eines Problems, nennt [Pup91]
Batch-Verarbeitung. Solch eine Verarbeitung liegt demnach für das zu entwickelnde Expertensystem vor.
Die Interviewerkomponente stellt für den Benutzer des Expertensystems eine
grafische Benutzerschnittstelle dar, um die benötigten Informationen für die Problemlösungskomponente zu sammeln, diese daraufhin anzustoßen und die gefundenen Lösungen anzuzeigen. Das Anstoßen der in Abschnitt 4.2.3 vorgestellten
Wissenserwerbskomponente ist dem Benutzer ebenfalls möglich.
Der Benutzer muss die Informationen für ein Problem in das Expertensystem
eingeben können. In der Interviewerkomponente ist hierfür eine Eingabe in Formularform vorgesehen. In dieses Formular gibt der Benutzer alle benötigten Eingaben (das Problem) ein und stößt dann das Expertensystem an. Der Benutzer
muss demnach folgende Eingaben treffen, um eine Problem für die Konstruktion
einer IE-Pipeline an das Expertensystem zu übergeben:
• Die Ziele der IE-Pipeline, also die von der Pipeline zu findenden Informationen in Form der zu findenden Annotationstypen und Attribute.
• Eine Priorisierung von Effizienz und Effektivität in der in Abschnitt 4.1.3
vorgestellten Art.
• Unter Umständen einen oder mehrere der in Abschnitt 4.1.5 vorgestellten
Filter.
• Ein Verweis auf die zu untersuchenden Texte.
90
4.3.2 Erklärungen von Seiten des Expertensystems
Die Erklärungskomponente dient in einem Expertensystem dazu, den Lösungsweg
für den Benutzer transparent zu machen (vgl. Abschnitt 2.1.2). Daher muss durch
diese Komponente für dieses Expertensystem vor allem der Weg der Berechnung
der IE-Pipeline erkennbar werden. In [Pup91] wird die Aufgabe einer Erklärungskomponente in Expertensystemen, die als Aufgabenbereich die Konstruktion haben, vorrangig als Protokollierung der gemachten Planungsschritte, die zu einer
Lösung geführt haben, gesehen. Anders als zum Beispiel in Diagnosesystemen
werden während des Arbeitens des Expertensystems keinerlei Rückfragen an den
Benutzer gestellt, die einer weiteren Erklärung bedürfen.
Das von dieser Arbeit entwickelte Expertensystem fällt, wie zu Anfang des Abschnitts 4.1 beschrieben, in den Aufgabenbereich der Konstruktion. Aus diesem
Grund ist in dem zu entwickelnden Expertensystem die Erklärungskomponente in
Form eines Arbeitsprotokolls konzipiert worden. Hierzu ist in der Problemlösungskomponente eine umfassende Protokollierung der Planung der IE-Pipeline eingebaut worden. Die Protokollierung der Erklärungskomponente wird der Interviewerkomponente mitgeteilt, die diese Protokollierung dem Benutzer anzeigen kann.
Hiermit ist es dem Benutzer möglich, die Lösung des Expertensystems nachzuvollziehen, aber auch einem Experten mögliche Fehler in der Wissensbasis zu entdecken. Dies können Algorithmen sein, bei denen die falschen Ein- und Ausgaben
gesetzt sind, oder bei denen die Werte der Gütekriterien falsch angegeben wurden und sie deshalb vom Planungsverfahren eventuell nicht korrekt berücksichtigt
werden.
91
5 Realisierung
Das in Kapitel 4 erarbeitete Konzept ist unabhängig von dem verwendeten Information-Extraction-Framework (IE-Framework), mit dem die konstruierte IEPipeline ausgeführt und somit die Ergebnisse für den Benutzer berechnet werden. Allerdings müssen die Eigenheiten des verwendeten IE-Frameworks bei der
Umsetzung dieses Konzepts berücksichtigt werden. So sind zum Beispiel beim
Ausführen der berechneten IE-Pipeline die real vorhandenen Algorithmen zu nutzen. Die meisten Bereiche des Expertensystems konnten allerdings so gestaltet
werden, dass sie völlig unabhängig von dem verwendeten IE-Framework sind. Etwa ist die Konstruktion der IE-Pipeline allein auf Basis des Wissens der Ontologie
möglich. Dieses Kapitel beschäftigt sich daher mit den notwendigen Berücksichtigungen der Eigenschaften des IE-Frameworks und den dadurch identifizierten
neuen Herausforderungen, die es zu lösen gilt.
Das Kapitel beginnt in Abschnitt 5.1 mit der Vorstellung des Apache Unstructured Information Management Architecture-Framework1 (im Folgenden UIMA),
welches das benutzte IE-Framework dieser Arbeit darstellt. Die dort verwendeten
Konzepte sollen dabei auch eine Abbildung auf die in dieser Arbeit verwendeten
Begriffe erfahren.
In Abschnitt 5.2 kann dann dargelegt werden, wie die zur Verfügung stehenden
Informationen über Algorithmen und Typenhierarchie aus UIMA in Wissen der
Ontologie umgewandelt werden können. Dazu wird die konkrete Wissenserwerbskomponente (vgl. Abschnitt 4.2.3) vorgestellt. Mittels dieser Komponente wird
dann die Wissensbasis des Expertensystems mit Wissen gefüllt. Alle zusätzlich in
die Ontologie eingefügten Elemente werden in Abschnitt 5.3 vorgestellt.
Die notwendigen Anpassungen der Problemlösungskomponente an UIMA und
dabei auftretende Herausforderungen sind in Abschnitt 5.4 beschrieben. So muss
zum Beispiel das in Abschnitt 4.1.3 beschriebene Problem gelöst werden, dass das
Paradigma Maximum Decomposition nicht komplett für alle Algorithmen durchgeführt wurde. Außerdem wird die Realisierung der Ausführungskomponente vorgestellt, sowie die Einbindung der Randbedingungsfilter in das vorhandene Framework gezeigt.
5.1 Vorstellung des eingesetzten IE-Frameworks
UIMA wird in dieser Arbeit als Basis für die Ausführung der IE-Pipeline benutzt.
Die in einer Pipeline verwendbaren Algorithmen, auf die das Expertensystem bei
1
http://uima.apache.org/
93
5. Realisierung
UIMA Begriff
Erklärung
Analysis Engine
Aggregate Analysis Engine
Analysis Engine Descriptor
IE- oder NLP-Algorithmus
IE-Pipeline
XML-Beschreibung eines IE- oder NLPAlgorithmus
Beschreiben benötigte und erzeugte Annotationen eines Algorithmus
Annotationstyp
Attribut eines Annotationstyps
Datenstruktur für die Aufnahme der gefundenen Annotationen
Liest ganz bestimmte Textarten ein
XML-Beschreibung der Typenhierarchie
Basistyp für alle weiteren Annotationstypen
Capabilities
Type
Feature
Common Analysis Structure(CAS)
Collection Reader
Type System Descriptor
Annotation
Tabelle 5.1: Erklärung der UIMA-Begriffe
seiner Arbeit zurückgreift, sind größtenteils unter Benutzung von UIMA am s-lab 2
der Universität Paderborn in Zusammenarbeit mit der Webis 3 - Arbeitsgruppe
der Universität Weimar entstanden (siehe [WPS10] und [WSE11]). Daneben werden Algorithmen aus [Sch94] (TreeTagger-Algorithmen), [BBHN10] und [Boh10]
(MateTools-Algorithmen) und [FGM05] (StanfordNER-Algorithmen) eingesetzt.
In Tabelle 5.1 sind die für diese Arbeit wesentlichen UIMA-Begriffe aufgezählt.
Sie lassen sich größtenteils auf schon bekannte Begriffe aus Kapitel 4 abbilden (vgl.
vor allem Abschnitt 4.2). Eine Analysis Engine (AE) stellt einen Algorithmus in
UIMA dar. Eine Aggregate Analysis Engine (AAE) besteht aus einer oder mehreren AEs, die in einer bestimmten Reihenfolge nacheinander ausgeführt werden.
Sie stellt damit eine IE-Pipeline dar. Die Eigenschaften der AEs, wie auch die der
AAE, werden in Form von XML-Dateien beschrieben, den sogenannten Analysis
Engine Descriptors (im Folgenden Deskriptor genannt). Für eine AAE enthält ein
solcher Deskriptor zum Beispiel die einzelnen Algorithmen und ihre Reihenfolge
in der entsprechenden IE-Pipeline. Im Deskriptor einer AE sind die sogenannten
Capabilities wichtig. Hiermit werden die benötigten Annotationstypen (bezeichnet
als Eingabe der AE) und die erzeugten Annotationstypen (bezeichnet als Ausgabe
der AE) angegeben. Die Annotationstypen selbst sind die Types, deren Attribute
heißen Feature. Die von den Algorithmen gefundenen Annotationen werden in einer speziellen Datenstruktur gespeichert, der Common Analysis Structure (CAS),
welche automatisch durch UIMA von einem Algorithmus zum nächsten in der
IE-Pipeline weitergereicht wird. Somit befinden sich nach der Ausführung der IEPipeline alle gefundenen Informationen am CAS.
Unterschiedliche Texte können ein unterschiedliches Format besitzen. Damit die
2
3
http://s-lab.uni-paderborn.de/
http://www.webis.de/
94
5.2 Importieren der Informationen des eingesetzten IE-Frameworks
Algorithmen auf den Texten in einer einheitlichen Art arbeiten können, müssen
diese für sie aufbereitet werden. So soll es beispielsweise für einen Algorithmus
egal sein, ob der ursprüngliche Text aus einer Webseite oder einer normalen Textdatei stammt. Um die unterschiedlichen Formate einzulesen und somit die Texte
den AEs bereitzustellen, können in UIMA daher sogenannte Collection Reader
definiert und implementiert werden.
Alle möglichen Annotationstypen sind in einer Typenhierarchie aufgeführt, die
in einer eigenen XML-Beschreibungsdatei, dem Type System Descriptor, beschrieben ist. Der Basisannotationstyp, welchen alle anderen Typen als direkten oder
indirekten Supertyp haben, ist Annotation. Bei der Vererbung von Types werden
alle Features der Supertypen an ihre Subtypen weiter vererbt.
5.2 Importieren der Informationen des eingesetzten
IE-Frameworks
In Abschnitt 4.2.3 wurde dargelegt, dass die Wissenserwerbskomponente dieses
Expertensystems automatisch die Informationen über verfügbare Algorithmen und
Annotationstypen in die Ontologie übertragen soll. Diese Informationen liegen für
UIMA in Form von XML-Dateien, den Deskriptoren, vor. Um auf diese Informationen zurückzugreifen, bedarf es allerdings nicht eines eigens zu entwickelnden
XML-Parsers, sondern es können die Funktionen von UIMA zum Erhalt des Inhalts der Deskriptoren genutzt werden.
Da in UIMA die benötigten Informationen zum einen in Form des Deskriptors der Typenhierarchie, zum anderen in Form der Deskriptoren der AEs vorliegen, teilt sich die Wissenserwerbskomponente in die beiden Komponenten Type
Importer und Analysis Engine Importer auf. Der Type Importer importiert die
Typenhierarchie, der Analysis Engine Importer die Informationen über die Algorithmen. Von beiden Komponenten werden die entsprechenden Informationen aus
den Deskriptoren mithilfe von UIMA ausgelesen und in die Ontologie überführt.
Die Komponenten, und damit die Wissenserwerbskomponente selbst, greifen
direkt auf die Ontologie zu, ohne das Datenmodell zu benutzen. Dies ist notwendig,
da sie Elemente der Ontologie erstellen und das Datenmodell nur für das Abgreifen
und Verfügbarmachen der Informationen der Ontologie zuständig ist.
Die UIMA-Types und ihre Features, sowie die Vererbungshierarchie können sehr
leicht auf die Konzepte Annotationstyp und Attribut der Ontologie übertragen
werden. Bei den Algorithmen werden aus den Capabilities die Informationen über
die in der Ontologie gebrauchten Informationstypen extrahiert. Eine Besonderheit
stellen die Gütewerte der Algorithmen dar. In den UIMA-Deskriptoren der AEs
kann ein Beschreibungstext angegeben werden. Per Einhaltung einer Konvention
können dort die einzelnen Werte für die Gütekriterien eingefügt werden. Diese Informationen werden vom Analysis Engine Importer automatisch erfasst und in die
Ontologie, für den entsprechenden Algorithmus, mit aufgenommen. Eine weitere
95
5. Realisierung
Ereignis
: Annotationstyp
Ereignis
Umsatzaussage
-unternehmen : Unternehmen
-geld : Geldinformation
-zeitraum : Zeitraum
hatSupertyp
Unternehmen
: Annotationstyp
Umsatzaussage
: Annotationstyp
hatAnnotationstyp
Unternehmen
Zeitraum
Geldinformation
: Annotationstyp
Zeitraum
: Annotationstyp
hatAnnotationstyp
hatAnnotationstyp
Geldinformation
hatAttrribut
unternehmen
: Attrribut
hatAttrribut
hatAttrribut
geld
: Attrribut
zeitraum
: Attrribut
Abbildung 5.1: Übersetzung einer fiktiven UIMA-Typenhierarchie in Ontologieform
Besonderheit hat mit den Deskriptoren selbst zu tun. Eine AAE enthält Verweise
auf die Deskriptoren der einzelnen, in der IE-Pipeline vorkommenden AEs. Das
bedeutet, die in Abschnitt 4.2 erwähnte Eigenschaft hatImplementierungsKlasse
eines Algorithmus in der Ontologie zeigt nicht etwa auf das jeweilige Programm
des Algorithmus, sondern auf den Pfad zur XML-Beschreibungsdatei der entsprechenden AE. Die Implementierungsklasse selbst ist innerhalb des Deskriptors der
AE angegeben.
In Abbildung 5.1 ist zur Veranschaulichung die Übersetzung einer fiktiven in
einem Type System Descriptor vorliegenden Typenhierarchie in Ontologieform
zu sehen. Auf der linken Seite sind die im Deskriptor beschriebenen Types als
UML-Klassendiagramm abgebildet. Attribute der Klassen sind die Features des
entsprechenden Type. Die Vererbung der Klassen gibt die Vererbung zwischen
den Types an. Der rechte Teil der Abbildung zeigt den aus diesen Informationen
generierten Ausschnitt der Ontologie (vgl. hierzu Abschnitt 4.2.1). Dabei sind
die Individuen der Ontologieklassen als Rechtecke dargestellt, wobei die Notation
Bezeichner : Klasse ist. Die konkreten Eigenschaften der Individuen werden durch
die Pfeile zwischen den Ellipsen ausgedrückt.
In Abbildung 5.2 ist ein Ausschnitt der Ontologie für einen importierten fiktiven
Algorithmus Umsatzaussagenklassifizierer dargestellt. Die Notation ist die gleiche,
wie in Abbildung 5.1. Die verwendeten Klassen entstammen der in Abschnitt 4.2.1
vorgestellten Ontologie. Die Ellipsen geben primitive Werte (Literale) an, die nicht
Individuen einer Klasse der Ontologie sind.
Der Beispielalgorithmus benötigt als Eingabe die Annotationstypen Unternehmen, Geldinformation und Zeitraum jeweils ohne Attribute. Die Annotationstypen
sind über die Informationstypen UnternehmenEingabe, GeldEingabe und ZeitraumEingabe mit dem Algorithmus verknüpft. Der Algorithmus erzeugt Annotationen
vom Typ Umsatzaussage. Dies wird durch den Informationstypen UmsatzaussageAusgabe dargestellt, welcher den Annotationstyp Umsatzaussage besitzt. Für
jede gefundene Umsatzaussage setzt der Algorithmus auch die Werte für dessen Attribute Zeitraum, Geld und Unternehmen. Daher ist der Informationstyp
96
5.3 Zusätzliche Elemente der Wissensbasis
hatImplementierungsklasse
Umsatzaussagenklassifizierer
: Algorithmus
Klassifizierer.xml
hatEingabe
hatGüte
hatAusgabe
UnternehmenEingabe
: Informationsyp
GeldEingabe
: Informationsyp
ZeitraumEingabe
: Informationsyp
UmsatzaussageAusgabe
: Informationsyp
hatAktivesAttribut
hatAnnotationstyp
Unternehmen
: Annotationstyp
hatAnnotationstyp
Geldinformation
: Annotationstyp
hatAnnotationstyp
Zeitraum
: Annotationstyp
Zeitraum
: Attribut
Geld
: Attribut
Unternehmen
: Attribut
AccuracyGüte
: Effektivitätskriterium
hatAnnotationstyp
hatGütekriterium
Umsatzaussage
: Annotationstyp
Accuracy
: Gütekriterium
hatKonkretenWert
0,97
hatAnnotationstyp
hatAnnotationstyp
hatAnnotationstyp
Abbildung 5.2: Ein fiktiver Algorithmus Umsatzaussagenklassifizierer in Ontologieform
als Ausgabe des Algorithmus über die Eigenschaft hatAktivesAttribut mit diesen
Attributen verbunden (vgl. Abschnitt 4.2.1). Die Güte des Algorithmus für das
Gütekriteriums Accuracy wird über das Individuum AccuracyGüte ausgedrückt
und mit dem Wert 0, 97 verknüpft. Der Pfad zum Deskriptor des Algorithmus
wird über die Eigenschaft hatImplementierungsklasse beschrieben.
Manche Bezeichner sind vereinfacht dargestellt worden. So müsste etwa der
Bezeichner UmsatzaussageAusgabe vom Typ Informationstyp eine eindeutige ID
haben, da unterschiedliche Algorithmen Umsatzaussagen mit unterschiedlichen
aktiven Attributen erzeugen können und damit eine eindeutige Zuordnung der
Informationstypen zu ihren Algorithmen nicht mehr sichergestellt wäre (vgl. Abschnitt 4.2). Das gleiche gilt für die Bezeichner der Informationstypen der Eingaben und AccuracyGüte.
5.3 Zusätzliche Elemente der Wissensbasis
Im Folgenden sollen die noch nicht in Abschnitt 4.2.1 vorgestellten Individuen der
Ontologie aufgezählt werden. Diese Elemente der Wissensbasis sind stark abhängig
von den verwendeten Algorithmen, aus denen sich eine IE-Pipeline zusammensetzen kann. Die durch die beiden in Abschnitt 5.2 beschriebenen Importer der Ontologie hinzugefügten Elemente der konkreten Typenhierarchie und der konkreten
Algorithmen sind allerdings aus Platzgründen nicht aufgeführt. Die schlussendlich vom Expertensystem genutzten IE- und NLP-Algorithmen sind in Tabelle
A.3 in Anhang A beschrieben. Die importierte Typenhierarchie ist in Abbildung
B.1 in Anhang B zu finden. Sie wurden anhand des in Abschnitt 5.2 dargestellten
Verfahrens aus den XML-Deskriptoren in Ontologieform überführt.4
4
Sowohl die Algorithmen, als auch die Typenhierarchie wurden im Rahmen der Arbeiten
[WPS10] und [WSE11] entwickelt und sind teilweise für diese Arbeit erweitert und ange-
97
5. Realisierung
Name
Klasse
Ordnung
ist Verrechenbar
Accuracy
F-Measure
Labeled Attachment Score
Precision
Recall
Average Sentence Response Time
Averaged Efficiency
E
E
E
E
E
F
F
Größer
Größer
Größer
Größer
Größer
Kleiner
Kleiner
nein
nein
nein
nein
nein
ja
ja
Tabelle 5.2: Gütekriterien in der Ontologie. Klasse: E=Effektivitätskriterium,
F=Effizienzkriterium. Ordnung: Größer=GrößererWerIstBesser, Kleiner=KleinererWertIstBesser
Für die Klasse Ordnung der Ontologie existieren die beiden Individuen GrößererWertIstBesser und KleinererWertIstBesser. Sie drücken aus, ob ein kleinerer
Wert eines Gütekriteriums besser ist oder ein großer. Diese Semantik wird schlussendlich in der Implementierung aufgrund eben jener Eigenschaft eines Gütekriteriums umgesetzt. In Tabelle 5.2 sind die in der Ontologie als Individuen verwendeten Gütekriterien mit ihren gesetzten Eigenschaften eingetragen (vgl. Ontologie in
Abschnitt 4.2.1). Die Kriterien ergeben sich aus den in der verwendeten Algorithmenmenge genutzten Gütekriterien und sind alle in Abschnitt 2.4.3 beschrieben.
Die in Abbildung 4.3 aus Abschnitt 4.1.3 dargestellten Priorisierungen müssen
ebenfalls in die Ontologie übertragen werden. Dies wird mittels der durch die Algorithmenmenge identifizierten, konkreten Gütekriterien durchgeführt. Die Umwandlung in Ontologieform ist nach folgendem Schema realisiert worden:
1. Alle Priorisierungen mit zwei Elementen werden um das implizite, dritte
Element erweitert in der Ontologie abgelegt (dies erleichtert die Implementierung). Zum Beispiel wird F1 R in der Ontologie als F1 Rt abgelegt. Die
so um das Effizienzmaß erweiterten Priorisierungen sind: F1 Rt, RF1 t, F1 P t,
P F1 t. Für die Punkte tP , P t beziehungsweise tR, Rt werden jeweils als drittes der Recall R beziehungsweise die Precision P festgesetzt. Somit ergeben
sich die Punkte: tP R, P tR, tRP , RtP .
2. Die Priorisierungen tA, At, tLAS und LASt werden aufgenommen. Dabei
steht A für die Accuracy und LAS für den Labeled Attachment Score.
3. Für eine Priorisierung F1 Rt werden ein Individuum der Klasse Priorisierung
und drei Individuen der Klasse Priorität gebildet. Jede Priorität wird über
die Eigenschaft hatKriterium mit dem entsprechenden Gütekriterium verknüpft. Die Prioritäten werden dann mittels der hatNachfolger -Eigenschaft
in der gewünschten Reihe angeordnet. So hat etwa die Priorität für den FMeasure in F1 Rt als Nachfolger die Priorität für den Recall. Die Priorisierung
passt worden.
98
verweist dann mittels der hatPrioritätsreihenfolge auf das erste Element der
Prioritätsreihenfolge, in diesem Fall die Priorität des F-Measure.
4. Für die aus Abbildung 4.3 bekannten Punkte werden die impliziert-Eigenschaften wie folgt gesetzt:
a) Beginnt die Priorisierung mit einem Effektivitätsmaß (F1 , P , R), so
wird die Eigenschaft impliziert jeweils mit At und LASt gesetzt.
b) Beginnt die Priorisierung mit dem Effizienzmaß (t), so wird die Eigenschaft impliziert jeweils mit tA und tLAS gesetzt.
5. Für das Effizienzmaß t wird die Average Sentence Response Time gewählt.
Dies ersetzt t in den Priorisierungen und damit in den Einträgen der Ontologie.
5.4 Anpassungen an der Berechnung und
Ausführung der IE-Pipeline
Die Einbindung von UIMA führt zu einigen Anpassungen des Expertensystems.
Dies betrifft vor allem die IE-Pipeline-Ausführungskomponente, da diese Komponente im hohen Maße abhängig von dem verwendeten IE-Framework ist. Hier wird
aus einer vorher abstrakt im Expertensystem vorhandenen IE-Pipeline eine UIMAIE-Pipeline konstruiert, die dann mittels UIMA ausgeführt wird. Allerdings gibt
es, bedingt durch die verwendeten IE- und NLP-Algorithmen und der verwendeten
Typenhierarchie, noch weitere Anpassungen an Teilen der Problemlösungskomponente, die in den folgenden Abschnitten erläutert werden.
5.4.1 Realisierungsaspekte der Berechnung der IE-Pipeline
Die Berechnung der Pipeline ist nach den in Abschnitten 4.1.2, 4.1.3 und 4.1.4
vorgestellten Konzepten realisiert worden. An den Konzepten sind allerdings einige Anpassungen vorgenommen worden. So ergab die Analyse der für eine IEPipeline zur Verfügung stehenden Algorithmen (vgl. Tabelle A.3 in Anhang A),
dass diese nicht komplett nach dem Paradigma Maximum Decompostion in die
kleinstmöglichen Teile zerlegt sind. Daher kann nicht von vornherein davon ausgegangen werden, dass die in Abschnitt 4.1.3 erläuterte Methode für alle Fälle
optimale Ergebnisse liefert.
Die Analyse der verwendeten Typenhierarchie (vgl. Abbildung B.1 in Anhang
B) zeigt außerdem, dass die Vererbungshierarchie der Annotationstypen und vor
allem die dadurch vererbten Attribute, stark ausgeprägt ist. Im entwickelten Partial Order Planner müssen deswegen nicht die genauen erzeugten Annotationstypen und Attribute der Algorithmen betrachtet werden, sondern alle möglichen
99
5. Realisierung
von diesem Algorithmus erzeugbaren. So ist zum Beispiel Forecast ein Annotationstyp, dessen Supertyp RevenueStatement ist. Ein Algorithmus, der Forecast-Annotationen erzeugt, erzeugt daher gleichzeitig auch RevenueStatementAnnotationen, sowie alle weiteren Supertypen von RevenueStatement. Dies wird
dann bei der Bestimmung der für ein gegebenes Teilziel bestmöglichen Aktion,
und damit des bestmöglichen Algorithmus, berücksichtigt.
Normalisierung der Ziele des Planers
Ein weiteres Problem, welches sich aus der Verwendung von UIMA ergibt, ist die
Tatsache, dass von Algorithmen bereits verfügbare Annotationen als Attribute
von neuen Annotationen hinzugefügt werden können, ohne dass dies als Ausgabe
des jeweiligen Algorithmus beschrieben ist. Ein vom Benutzer verlangtes Ziel,
wie Forecast.author, wobei Forecast ein Annotationstyp und author ein Attribut
vom Typ Author ist, kann so von der gegeben Algorithmenmenge nicht erfüllt
werden. Es gibt keinen Algorithmus, der dieses Ziel direkt erfüllt (vgl. Tabelle
A.3 in Anhang A). Das bedeutet, der Planer könnte für ein solches Teilziel keine
geeignete Aktion finden. Die Planung würde fehlschlagen.
Daher muss ein Ziel wie Forecast.author anders behandelt werden. Der ForecastClassifier erzeugt Annotationen vom Typ Forecast. Der Annotationstyp Author
ist die Ausgabe des Algorithmus StatementAuthorFinder. Weiterhin erzeugt dieser
RevenueStatement.author Annotationen. In der Typenhierarchie (vgl. Abbildung
B.1 in Anhang B) ist RevenueStatement der Supertyp von Forecast. Das heißt,
das Attribut author wird von RevenueStatement an Forecast vererbt.
Die wesentliche Eigenschaft der verwendeten Algorithmen ist, dass diese bei der
Bestimmung eines konkreten Annotationstyps (entspricht einem Annotationstyp,
der tiefer in der Typenhierarchie liegt) alle bestehenden Attribute von den schon
vorhandenen Supertypen an die neu erstellten Annotationen anhängen und diese
dann durch die konkreten Annotationen der Subtypen ersetzen. Das bedeutet zum
Beispiel, dass der ForecastClassifier vorhandene RevenueStatement-Annotationen
durch Forecast-Annotationen ersetzt, wenn er meint, das entsprechende RevenueStatement sei ein Forecast. Die dabei schon am RevenueStatement hinzugefügten, konkreten Attribute werden auf die neue Forecast-Annotation übertragen. Damit kann der StatementAuthorFinder die RenvenueStatment.author Annotationen erstellen und der ForecastClassifier kann dann diese Annotationen zu
Forecast.author umwandeln. Somit ist hierdurch das initiale Problemziel Forecast.author zu erreichen.
Es kann noch eine zweite Situation geben. Hierbei findet der ForecastClassifier zuerst Forecast-Annotationen, denen dann der StatementAuthorFinder das
Attribut author hinzufügt. Dies ist zulässig, da Forecast eine Subklasse von RevenueStatement ist, und der StatementAuthorFinder diese Annotationen damit als
RevenueStatement behandeln kann. Damit steht auch in dieser Algorithmenreihenfolge am Ende das Ziel Forecast.author zur Verfügung.
Um diesen Umständen Rechnung zu tragen, werden die Ziele, die der Benutzer
100
in das Expertensystem eingibt, in der folgenden Art und Weise modifiziert: Für
ein Ziel A.x, A Annotationstyp, x ein Attribut von A:
1. Bestimme den Supertypen S von A, von dem das Attribut x vererbt wurde.
2. Ersetze das Ziel A.x durch S.x und A, A ohne Attribut.
3. Bei mehreren als Ziel gesetzten Attributen (z.B. A.x, A.y) kann jedes Attribut einzeln entsprechend 1. und 2. in die neuen Zielformeln überführt
werden. Das Ergebnis ist eine Zielmenge. In dieser kommt jedes Element
nur einmal vor.
Für das Beispielziel Forecast.author ergeben sich dadurch die neuen Ziele Forecast
und RevenueStatement.author. Diese Ziele können direkt von Algorithmen der
verwendeten Algorithmenmenge erzeugt werden. Außerdem sind hiermit beide
weiter oben beschriebene Reihenfolgen der Algorithmen ForecastClassifier und
StatementAuthorFinder möglich.
Die Beweisidee hierfür:
1. Annotationstypen ohne Attribute in der Zielmenge werden von allen Algorithmen erzeugt, die diesen Annotationstypen mit beliebigem Attribut (also
auch ohne) erzeugen.
2. Wenn eine bereits vorhandene Annotation A von einem Supertyp X durch
die neue Annotation B des Subtyps Y ersetzt wird, so werden die bereits
bestehenden Attribute von A auf die neue Annotation B übertragen.
3. Da jeder Algorithmus, der als Eingabe einen Supertyp X von Y als Eingabe
braucht, auch Annotationen vom Typ Y selbst (also von allen Subtypen des
Supertyps) akzeptiert, kann er die von A auf B übertragenden Attribute
ebenfalls nutzen.
ODER-verknüpfte Ziele
Die Ziele, die der Planer und damit auch das Expertensystem betrachtet, sind
immer UND-verknüpft. Damit wird ausgedrückt, dass eine Pipeline immer alle
Textstellen mit den als Zielen angegebenen Annotationstypen finden soll. Vor
allem darf nur unter dieser Bedingung ein Herausfiltern von Textteilen, die diese
Annotationen nicht enthalten, unmittelbar nach dem Algorithmus, welcher eine
der gesuchten Annotationen finden kann, gemacht werden.
Bei ODER-verknüpften Zielen muss demgegenüber bei der Filterung darauf
geachtet werden, dass nicht auch Textstellen entfallen, die schon eine der gesuchten Annotationen enthalten. Hier ist es nicht wichtig, dass Textstellen gefunden
werden, die alle als Ziele angegebenen Annotationstypen enthalten, sondern mindestens einen dieser Typen.
Das von dieser Arbeit erstellte Expertensystem bietet nur die Möglichkeit der
UND-verknüpften Ziele an. Die Ergebnisse von ODER-verknüpften Zielen können
101
5. Realisierung
allerdings leicht simuliert werden. Dafür muss das Expertensystem nur mehrfach
mit jeweils einem der Ziele gestartet und die Ergebnisse am Ende wieder zusammengebracht werden. Hierbei wird für jedes ODER-verknüpfte Ziel eine eigene
IE-Pipeline konstruiert und ausgeführt. Die Integration dieser einzelnen Pipelines
in eine einzige, und somit die Vermeidung von redundanten Ausführungen der
einzelnen Algorithmen ist erstrebenswert. Allerdings liegt die Betrachtung einer
Lösung dieses Problems und etwaiger dadurch neu entstehender Probleme, außerhalb des Fokus dieser Arbeit und bleibt damit Ausgangspunkt für zukünftige
Arbeiten.
Problem der nicht vollständigen Maximum Decomposition
Ein weiteres Problem betrifft das aus Abschnitt 2.4 bekannte Paradigma Maximum
Decomposition. In der verwendeten Algorithmenmenge ist dieses Prinzip nicht
vollständig eingehalten worden. Das bedeutet es gibt Algorithmen, die mehr als
einen Annotationstyp finden. Für das Planungsproblem ergibt sich daraus, dass
Aktionen existieren, die mehr als einen Effekt haben.
Die Einschränkung, dass die komplette Algorithmenmenge nach dem Paradigma Maximum Decomposition zerlegt wurde, ist allerdings eine Voraussetzung des
in Abschnitt 4.1.3 beschriebenen Verfahrens zur Bestimmung des besten Algorithmus. Somit ist nicht immer die Optimalität der Ergebnisse sichergestellt.
Es ergibt sich noch ein weiteres Problem: Von einem Algorithmus bereits gefundene Annotationen und Attribute können von einem nachfolgenden, der die
gleichen Annotationstypen und Attribute erzeugt, überschrieben werden. Wenn
jeder Algorithmus nur eine Ausgabe hätte, so könnte dieser Fall nicht vorkommen, da in der berechneten Pipeline dann keine zwei Algorithmen, die beide das
selbe Teilziel erfüllen, auftreten können. Ein konkretes Beispiel für dieses Problem
sind der TTChunker und der MTPOSTagger (siehe Tabelle A.3, Anhang A). Der
TTChunker erzeugt wie der MTPOSTagger für Token das Attribut pos. Dabei ist
der MTPOSTagger effektiver aber ineffizienter. Der TTChunker ist allerdings der
einzige Algorithmus, der Token.chunks finden kann. Das bedeutet einen potenziellen Konflikt, wenn die Gesamtpipeline eine hohe Effektivität haben soll und
innerhalb dieser Pipeline sowohl Token.pos als auch Token.chunks gebraucht werden. Wird der TTChunker in der Pipeline nach dem MTPOSTagger ausgeführt,
so überschreibt er die bereits erstellten Token.pos Attribute. Da der TTChunker
allerdings dabei nicht so effektiv ist, wie der MTPOSTagger, kann die Effektivität
der Gesamtpipeline davon beeinträchtigt werden. Dieses Problem ergibt sich aus
der Implementierung der verwendeten IE- und NLP-Algorithmen. Somit kann es
von dieser Arbeit nicht gelöst werden.
Außerdem kann es vorkommen, dass nach der topologischen Sortierung eine IEPipeline entsteht, in der ein Algorithmus einen nachfolgenden Algorithmus dominiert. Ein Algorithmus dominiert einen anderen, wenn er alle möglichen Ausgaben
des dominierten Algorithmus umfasst und hinsichtlich der vom Benutzer gewählten Priorisierung mindestens so gut ist, wie der dominierte Algorithmus. Hierbei
102
müssen zur Berechnung der Werte der akkumulativen Gütekriterien nicht mehr
alle möglichen Algorithmen betrachtet, sondern nur die in der Pipeline vor dem
entsprechenden Algorithmus befindlichen.
Dies ist zum Beispiel dann der Fall, wenn der TTChunker vor dem TTPOSLemmatizer ausgeführt werden soll. Der erstere erzeugt alle Ausgaben des letzteren
und er hat die gleiche Effektivität. Der TTPOSLemmatizer ist dagegen effizienter.
Dieser Effizienzvorteil ist allerdings nicht gegeben, wenn er hinter dem TTChunker
ausgeführt wird. Das Problem resultiert daraus, dass hier die gleiche Implementierung verwendet wird, die im Falle des TTChunker nur zusätzlich Token.chunks
erkennt.
Das Problem der nicht vollständigen Einhaltung der Maximum Decomposition
kann von dieser Arbeit nicht vollständig gelöst werden. Allerdings kann mittels
einer Optimierung nach der Bestimmung der IE-Pipeline dem Problem der Dominanz von Algorithmen begegnet werden. So muss für eine berechnete IE-Pipeline
überprüft werden, ob es Algorithmen gibt, die nachfolgende Algorithmen dominieren. Die dominierten Algorithmen werden dann aus aus der Pipeline entfernt.
Ein TTChunker, der vor dem TTPOSLemmatizer in einer Pipeline ausgeführt
werden soll, dominiert den hinteren. Er umfasst mit Token.lemma und Token.pos
dessen Ausgaben und ist von seiner Effektivität in Form von Accuracy genauso
gut wie der hintere. Allerdings ist sein Effizienzwert in Form der Average Sentence Response Time schlechter. Da bei der Berechnung der akkumulativen Werte
in diesem Fall aber nur die vor einem Algorithmus befindlichen anderen Algorithmen der Pipeline berücksichtigt werden, sind diese Laufzeitwerte bei denen des
TTPOSLemmatizer ebenfalls enthalten. Daher ist der TTChunker auch bezüglich
der akkumulativen Effizienz besser als der TTPOSLemmatizer und dominiert damit diesen. Der TTPOSLemmatizer wird daraufhin aus der Pipeline entfernt.
5.4.2 Realisierungsaspekte der Ausführung der IE-Pipeline
Bei der Ausführung der IE-Pipeline muss das verwendete IE-Framework in Form
von UIMA benutzt werden. Auch die Randbedingungsfilter (vgl. Abschnitt 4.1.5)
müssen implementiert und in dieses Framework mit integriert werden. Die IEPipeline-Ausführungskomponente ist damit die einzige Stelle im Expertensystem,
an der UIMA, und somit das IE-Framework, direkt benutzt wird.
Mögliche Randbedingungsfilter
Nachdem in Abschnitt 4.1.5 erläutert wurde wann und wo ein Filter in eine IEPipeline einzubauen ist, wird im Folgenden beschrieben, wie eine solche Filterung
durchgeführt werden kann. Hierbei werden von dieser Arbeit drei verschiedene
Filter festgelegt:
• Zahlenfilter: Ein Filter, der für eine Eingabe entscheidet, ob sie eine Zahl ist
und ob ihr Wert in festgelegten Grenzen liegt.
103
5. Realisierung
• Datumsfilter: Ein Filter, der für eine Eingabe entscheidet, ob sie ein Datum
darstellt und ob dieses Datum in einem bestimmten Zeitraum liegt.
• Textfilter: Ein Filter, der für eine beliebige Texteingabe entscheidet, ob sie
einem bestimmten regulären Ausdruck entspricht.
Die Eingabe eines Filters stellt den Text einer Annotation oder eines Attributs
dieser Annotation dar. Der Filter prüft, ob dieser Text den eben angegebenen,
jeweiligen Kriterien entspricht. Ist dies nicht der Fall, so wird die Textstelle der
Annotation heraus gefiltert und muss nicht mehr von nachfolgenden Algorithmen
der IE-Pipeline untersucht werden.
Prinzipiell ist es möglich, sowohl Zahlen als auch Zeiträume mithilfe eines regulären Ausdrucks zu prüfen. Daher könnte auch der Textfilter alleine genutzt
werden. Allerdings können die regulären Ausdrücke etwa für das Prüfen, ob eine
Eingabe in einem bestimmten Zeitraum liegt, sehr lang werden. Aus diesem Grund
sind sowohl Zahlen- als auch Datumsfilter zusätzlich zum Textfilter innerhalb des
Expertensystems verfügbar.
Diese Informationen werden, neben der eigentlichen Implementierung, auch in
der Ontologie festgehalten. So wird für jeden der drei Filter eine Instanz der
Ontologieklasse Filter gebildet. Die Eigenschaften der Filter werden durch Instanzen der Klasse FilterEigenschaft festgehalten. Der Zahlenfilter hat die Eigenschaften vonZahl, bisZahl. Der Datumsfilter bekommt die Eigenschaften von,
bis, sowie ein Format, in dem das Datum ausgedrückt wird. Der Textfilter besitzt die Eigenschaft regulärerAusdruck. Außerdem bekommen alle drei Filter mit
der hatImplementierungsKlasse-Eigenschaft einen Verweis auf ihre jeweilige JavaImplementierungsklasse, damit das Expertensystem sie in seinem Betrieb instantiieren kann. Durch die Angabe der Filtereigenschaften kann die grafische Oberfläche
des Expertensystems automatisch die zur Verfügung stehenden Filter und die für
diese Filter benötigten Eingaben aus der Ontologie ableiten und anzeigen.
Integration der Randbedingungsfilter in UIMA
Die Randbedingungsfilter müssen in UIMA integriert werden. Dazu wird jeder
Filter als eigenständige AE gesehen. Das Filtern selbst ist in den vom s-lab entwickelten UIMA-Strukturen bereits vorgesehen. Dazu sind alle verwendbaren IEund NLP-Algorithmen von einer abstrakten Basisklasse abgeleitet.
Eben diese Basisklasse ist damit auch die Basisklasse der entwickelten UIMAFilter. Die Filter enthalten dabei eine Instanz der eben aufgeführten Datums-,
Zahlen- oder Textfilter. Daneben muss jeder Filter wissen, welchen Annotationstyp und welches Attribut er filtern soll. Hier ergibt sich eine Schwierigkeit,
denn diese Parameter müssen auf eine persistente Art und Weise in den Filtern
verfügbar sein. Die einzige Möglichkeit, die Informationen den Filtern in UIMA
direkt zugänglich zu machen, besteht in der Unterbringung dieser Informationen in den XML-Deskriptoren. Innerhalb der Strukturen des Deskriptors können
104
sogenannte Konfigurationsparameter hinterlegt werden. Daher werden die XMLDeskriptoren der als AE betrachteten Filter dynamisch vor der Ausführung der
Pipeline erzeugt.
Die Konfigurationsparameter umfassen sowohl den zu filternden Annotationstyp, als auch die Informationen, welche von dem jeweiligen Filter selbst benötigt
werden. Dies sind die vom Benutzer gesetzten Eigenschaften des Filters bezüglich
des zu filternden Zeitraums und des Datumsformat für den Datumsfilter, Zahlenbereiche für den Zahlenfilter oder der reguläre Ausdruck für den Textfilter. In einer
von UIMA im Vorfeld der Ausführung der Pipeline aufgerufenen Methode der Filterimplementierungen werden diese Parameter an die Filter übergeben. Während
der Ausführung der Pipeline sucht ein Filter dann alle von ihm zu filternden Annotationen am CAS -Objekt zusammen und filtert jedes einzeln, entsprechend dem
eingesetzten Datums-, Zahlen- oder Textfilter.
Die konkreten Filter sind damit stark vom eingesetzten IE-Framework UIMA
abhängig. Da diese Abhängigkeit der Ausführung einer Pipeline in UIMA geschuldet ist, sind sie Teil der IE-Pipeline-Ausführungskomponente geworden, wobei die
allgemeinen Implementierungen von Datums-, Zahlen- und Textfilter Teil des Datenmodells sind.
Aufbau und Ausführung einer Aggregate Analysis Engine
Wie in Abschnitt 5.1 beschrieben, entspricht eine AAE aus UIMA einer IEPipeline. Sie wird beschrieben durch ihre XML-Deskriptor Datei. Diese Datei wird
von UIMA zum Aufbau der Instanz einer IE-Pipeline benutzt. Dazu steht in der
Datei vor allem, welche einzelnen AEs, und damit Algorithmen, die Pipeline umfasst (ausgedrückt durch die Angabe des Pfades zu der entsprechenden Datei des
Deskriptors der AE). Insbesondere ist auch beschrieben, in welcher Reihenfolge
diese Algorithmen ausgeführt werden sollen.
Aus der berechneten IE-Pipeline muss also ein AAE-Deskriptor erzeugt und die
entsprechende AAE dann ausgeführt werden. Hierzu werden eine Reihe von XMLVorlagen dynamisch mit den Informationen aus den einzelnen Algorithmen gefüllt.
Dies betrifft vor allem, welcher AE-Deskriptor für den jeweiligen Algorithmus zu
verwenden ist, aber auch die Reihenfolge der Algorithmen in der Pipeline. Da,
wie in Abschnitt 5.2 erwähnt, die Eigenschaft hatImplementierungsklasse eines
Algorithmus den Pfad zu seinem Deskriptor beinhaltet, können aus der berechneten abstrakten Pipeline sehr einfach und schnell die benötigten Informationen
gewonnen werden. Weil die Filter, wie weiter oben bereits beschrieben, ebenfalls
Bestandteile der Pipeline sind, werden auch diese als AE aufgefasst und an den
entsprechenden Positionen im AAE-Deskriptor vermerkt. Ein Filter, der etwas
filtert, das nicht von einem Algorithmus erzeugt wird, wird an das Ende der entstehenden IE-Pipeline verschoben. Dies hat mit dem schon beschriebenen Aspekt
zu tun, dass manche Algorithmen bereits vorhandene Annotationen implizit und
von außen nicht sichtbar als ihre Attribute setzen können.
Eine Textmenge wird den Algorithmen in UIMA durch einen Collection Reader
105
5. Realisierung
Normalisieren der Ziele
Erzeugen des UIMA-Deskriptors
aus der abstrakten Pipeline
Planen der abstrakten Pipeline
Erzeugen der Aggregate Analysis Engine
Optimieren der abstrakten Pipeline
Ausführen der Aggregate Analysis Engine
Präsentieren der Ergebnisse
der Pipelineausführung
Abbildung 5.3: Aktivitätendiagramm des internen Arbeitsablaufs des Expertensystems
verfügbar gemacht. Hierfür stehen bereits vom s-lab entwickelte Komponenten
bereit. Der entsprechende Collection Reader wird anhand des Dateityps der vom
Benutzer spezifizierten Texte gewählt. Die drei vorhandenen Collection Reader
können HTML-, reine Text- sowie spezielle UIMA-XMI-Dateien, welche zum Beispiel schon manuell angebrachte Annotationen enthalten können, einlesen und den
Algorithmen zur Verfügung stellen.
Anschließend wird die AAE aus dem aufgebauten Deskriptor von UIMA erzeugt und auf jedem der vom entsprechenden Collection Reader gelieferten Texte
ausgeführt. Die Ergebnisse werden gesammelt und der grafischen Benutzerschnittstelle (in Form der Interviewerkomponente) zurückgegeben. Der gesamte Vorgang
der Konstruktion und Ausführung der IE-Pipeline ist noch einmal in Abbildung
5.3 dargestellt.
106
6 Implementierung
Dieses Kapitel stellt Teile der Implementierung vor, um die einfache Erweiterbarkeit und Anpassbarkeit der entwickelten Expertensystemarchitektur und ihrer
Komponenten zu zeigen. Diese Erweiter- und Anpassbarkeit sind aus der Zielsetzung in Kapitel 1 bekannte Ziele dieser Arbeit. In Abschnitt 6.1 wird eine
Verfeinerung der in Kapitel 4 vorgestellten Architektur des Expertensystems aufgezeigt. Einige Details der Implementierung von einzelnen Komponenten werden
vorgestellt, damit der Leser einen Überblick über die Ansatzpunkte bei einer etwaigen Anpassung oder Erweiterung des Expertensystems bekommt. In Abschnitt
6.2 werden dann direkte Möglichkeiten der Anpassbarkeit und der Erweiterung des
Gesamtsystems vorgestellt. Dabei wird vor allem gezeigt, dass das Expertensystem durch neue Elemente der Ontologie so erweitert werden kann, dass dafür keine
bis wenig Quellcodeanpassungen vorzunehmen sind.
Der Einblick in die Implementierung ist nicht vollständig. Er soll allerdings
deutlich machen, dass die hinsichtlich der Implementierung zu leistenden Ziele
erfolgreich von dieser Arbeit bearbeitet worden sind.
6.1 Implementierung der Expertensystemarchitektur
Bei der Implementierung und Entwicklung der Architektur des Expertensystems
und seiner einzelnen Komponenten stellt die in Abbildung 4.1 aus Kapitel 4 bekannte Konzeption der Expertensystemarchitektur die Basis dar. Weiterhin sind
die in Kapitel 4 und 5 aufgezählten Eigenheiten, wie die Berücksichtigung von
UIMA, in die Implementierung mit eingeflossen. Die Implementierung selbst ist
in der Programmiersprache Java erfolgt.
Abbildung 6.1 zeigt eine Übersicht über die entstandene Architektur des Expertensystems. Dieses wurde in zwei grundlegende Komponenten aufgeteilt. Das
ExpertSystemFrontend beinhaltet die grafische Oberfläche des Expertensystems.
Sie enthält die Funktionalitäten der Interviewer- und Erklärungskomponente, die
in einer eigenständigen Form im Expertensystem nicht vorkommen. Die Protokollierung wird mithilfe der Apache Log4J API 1 durchgeführt. Die Logeinträge
werden mit einer GUI angezeigt.2 Die Komponente ExpertSystemCore enthält die
Funktionalität der Problemlösungskomponente (ProblemSolver ) und der Wissenserwerbskomponente (OntologyImporter ). Das Datenmodell (Datamodel ) und die
1
2
http://logging.apache.org/log4j/
Die GUI ist mithilfe der Swing API von Java erstellt worden: http://docs.oracle.com/
javase/6/docs/technotes/guides/swing/
107
6. Implementierung
package Data[
Architekturuebersicht ExpertSystem ]
«component»
ExpertSystemFrontend
Zum Loesen des Problems und
Bezieht Daten fuer die GUI
zum Importieren von neuen Ontologieinformationen
ExpertSystemCore
«component»
ExpertSystemCore
«component»
ProblemSolver
«component»
OntologyImporter
«component»
GoalNormalizer
«component»
PartialOrderPlanner
«component»
Linearization
«component»
AlgorithmSelector
«component»
PipelineOptimizer
«component»
PipelineExecutor
«use»
«component»
Datamodel
Ontology
Baut Ontologie mit neuen Informationen auf
«component»
Ontology
Abbildung 6.1: Architekturübersicht des Expertensystems
108
package Data[
Schnittstelle ExpertSystemCore ]
ExpertSystemCore
+List<TextType> calculateResults( Problem problem )
+void importOntology( ImportJob importJob )
Problem
-List<Type> goals
-List<Filter> filter
-QualityCriteriaOrder qualityCriteriaOrder
-URI textFilesUri
-QualityCriterion linearizationQualityCriterion
-String pipelineName
ImportJob
TextType
-File instancesFile
-Model baseModel
-String coveredText
-Map<Feature - String> featureText
Abbildung 6.2: Schnittstelle des Expertensystems
Wissensbasis (Ontology) sind separate Komponenten. Sowohl ExpertSystemCore,
als auch das ExpertSystemFrontend greifen auf die Informationen der Ontologie
über das Datamodel zu. Das ExpertSystemFrontend benötigt dabei die Informationen zum Anzeigen der Einstell- und Auswahlmöglichkeiten für den Benutzer in
der grafischen Oberfläche.
Die Schnittstelle von ExpertSystemCore ist in Abbildung 6.2 dargestellt. Es werden zwei Methoden bereitgestellt. Die erste Methode berechnet für ein gegebenes
Problem eine Lösung (calculateResults). Konkret bedeutet dies, dass aus den vom
Benutzer in der Eingabemaske der grafischen Oberfläche vorgenommenen Einstellungen eine Instanz der Problem-Klasse erstellt und dann dem ExpertSystemCore
übergeben wird. Die entsprechenden Attribute der Problem-Klasse entsprechen
den aus Abschnitt 4.3 bekannten, notwendigen Eingaben des Benutzers. Die meisten dieser Attribute haben einen Typ des entwickelten Datenmodells (sie werden
im noch folgenden Abschnitt 6.1.2 erklärt). Durch die Angabe des Dateipfades zu
den zu untersuchenden Texten als URI ist es prinzipiell möglich, auch Webadressen
anzugeben, bei denen diese Texte liegen. Dazu ist nur ein spezieller CollectionReader notwendig (siehe Abschnitt 5.4.2). Die Methode calculateResults gibt eine
Liste von TextType zurück. Diese Liste enthält die gefundenen Annotationen für
die vom Benutzer eingestellten Ziele.
Die zweite Methode importOntology veranlasst ExpertSystemCore, seine Ontologie um neue Informationen zu erweitern. Hierzu wird ein ImportJob-Objekt
übergeben, das einen Verweis auf eine zu importierende Datei enthält. Außerdem
kann ein schon existierendes Ontologiemodell als Basis genutzt werden. Durch die
Benutzung von UIMA wurde eine Spezialisierung von ImportJob eingeführt, der
UimaImportJob. Diese Klasse erweitert ImportJob um die Attribute typeSystemsDescriptor, wodurch ein Verweis auf das zu verwendende Typensystem möglich
ist, und analysisEngineDescriptorDirectory, mit dessen Hilfe das Basisverzeichnis
für die Deskriptoren angegeben werden kann.
Der große Vorteil von der Trennung zwischen der grafischen Benutzeroberfläche
einerseits und den Kernfunktionalitäten des Expertensystems andererseits liegt
109
6. Implementierung
getPropertyValue(subjectUri : Str, propertyUri : Str) : Object
addProperty(subjectUri : Str, propertyUri : Str, objectUri : Str) : void
createIndividual(uri : Str, ontologyClass : Str) : void
getIndividualsOfClass(ontologyClassUri : Str) : Set<Str>
getIndividuals(ontologyClassUri : Str, propertyUri : Str, value : Str) : Set<Str>
Tabelle 6.1: Beispielmethoden der Ontologieschnittstelle. Str steht für String.
in der dadurch einfachen Anpass- und Erweiterbarkeit an neue Umgebungen. So
kann das Expertensystem zum Beispiel sehr einfach in einen Webservice integriert werden. In diesem Fall ist eine grafische Benutzeroberfläche nicht notwendig. Die ExpertSystemFrontend Komponente könnte demnach durch Funktionen
des Webservices ersetzt werden, die dann das Expertensystem steuern.
6.1.1 Implementierungsdetails der Ontologie
Die Wissensbasis des Expertensystems besteht aus der in Abschnitt 4.2 vorgestellten OWL-Ontologie. Für die Arbeit mit dieser Art von Ontologie wird das Jena 3
Ontologie-Framework eingesetzt. Jena bietet einfache Möglichkeiten im Umgang
mit OWL-Ontologien, sowohl was das Erstellen neuer, als auch das Abfragen von
bestehenden Ontologieelementen betrifft. Für das Abfragen der Ontologie wird
das in Jena integrierte Standard-Schlussfolgerungswerkzeug (vgl. Abschnitt 2.3.1)
genommen, was, wie bereits in Abschnitt 4.2.2 erwähnt, für die genutzte, einfache
Ontologie vollkommen ausreicht. Allerdings bietet Jena Möglichkeiten, um den
gewählten Reasoner schnell und einfach bei Bedarf austauschen zu können, falls
die Ontologie erweitert wird und damit eine höhere Komplexität erreicht.
Für den Zugriff von außen ist die Ontologie durch eine Schnittstelle gekapselt. Dies bietet den großen Vorteil, dass bei Bedarf die komplette Ontologie ausgetauscht werden kann. Dabei könnte die bestehende OWL-Ontologie zum Beispiel durch eine Ontologie mit weniger oder mehr Ausdrucksmöglichkeiten ersetzt
werden. Die Kapselung macht auch den kompletten Verzicht auf eine Ontologie
möglich. So ist als Datenspeicher etwa auch eine relationale Datenbank vorstellbar,
falls sich dies in Zukunft als notwendig herausstellen sollte (etwa weil die Menge
an Informationen in der Ontologie zu groß oder die Arbeit mit ihr zu langsam
wird). Das Expertensystem ist an dieser Stelle also einfach änderbar.
Einige Methoden der Ontologieschnittstelle sind in Tabelle 6.1 exemplarisch aufgeführt. Alle Elemente der Ontologie sind durch einen URI benannt. Somit kann
mittels der Methode getPropertyValue für ein durch subjectUri identifiziertes Element der Ontologie der Wert einer zugehörigen und durch objectUri identifizierten Eigenschaft bestimmt werden. Eine Verknüpfung zwischen zwei Elementen der
Ontologie über eine Eigenschaft, etwa die in Abschnitt 4.2.1 aufgeführte hatAnnotationstyp-Eigenschaft, kann mittels der Methode addProperty angelegt werden.
3
http://incubator.apache.org/jena/
110
Ein neues Individuum einer Klasse wird mit der Methode createIndividual erstellt.
Alle Individuen einer bestimmten Klasse können über die Methode getIndividualsOfClass bezogen werden. Dagegen lassen sich mit getIndividuals Individuen herausfinden, die eine Eigenschaft haben, welche einen mit value bezeichneten Wert
besitzt. Die Aufzählung der Schnittstellenmethoden ist nicht vollständig und soll
nur die wesentlichen Konzepte, allen voran das der Identifizierung der Ontologieelemente über URIs, aufzeigen. Weitere Details zur Ontologie-Komponente sind
als UML-Klassendiagramm in Abbildung C.5 in Anhang C dargestellt.
6.1.2 Implementierungsdetails des Datenmodells
Das Datenmodell kapselt die Zugriffe der Problemlösungskomponente und des ExpertSystemFrontend auf die Wissensbasis und macht das in der Ontologie gehaltene Wissen für die Berechnung und Ausführung der IE-Pipeline verfügbar (vgl.
Abschnitt 4.2.4). Folgende Datenklassen existieren im Datenmodell:
• Algorithm: Enthält Informationen über ein bestimmtes Individuum der Klasse Algorithmus aus der Ontologie.
• Type: Enthält Informationen über ein bestimmtes Individuum der Klasse
Annotationstyp der Ontologie.
• Feature: Enthält Informationen über ein bestimmtes Individuum der Klasse
Attribut der Ontologie.
• QualityCriterion: Enthält Informationen über ein bestimmtes Individuum
der Klasse Gütekriterium der Ontologie.
• QualityCriteriaOrder : Mit dieser Klasse werden die Priorisierungen aus der
Ontologie abgebildet.
• QualityCriterionValue: Stellt einen Wert für ein Gütekriterium für einen
bestimmten Algorithm bereit.4
• FilterInformation: Enthält Informationen über einen Filter, wie die konkrete
Filterklasse und Eigenschaften des Filters.
Die Datenklassen werden im gesamten Expertensystem verwendet. Damit ist es
möglich, das Schlussfolgern in und Arbeiten mit der Ontologie auf ein Minimum
zu reduzieren und somit eine potenzielle Ausbremsung des Systems durch langsame Ontologiezugriffe zu vermeiden. Aufgebaut werden die Datenklassen von
Helferklassen. Die einzelnen Instanzen der Algorithm-Klasse werden von einem
4
An dieser Stelle unterscheidet sich die Implementierung im Datenmodell von der eingesetzten
Ontologie aus Abschnitt 4.2.1. Wird die Verknüpfung von Wert und Gütekriterium in der
Ontologie über die Klasse Güte modelliert, so wird dies in der Implementierung über eine
Abbildung QualityCriterion auf QualityCriterionValue innerhalb eines Algorithm-Objektes
implementiert.
111
6. Implementierung
AlgorithmHelper mittels der Informationen der Ontologie aufgebaut. Ein TypeHelper ist für das Aufbauen der Typenhierarchie, bestehend aus Type- und Feature-Instanzen, zuständig. Er bietet außerdem noch Hilfe im Umgang mit den
Type- und Feature-Instanzen an, zum Beispiel, ob ein bestimmtes Attribut von
einem Supertyp vererbt wurde. Ein QualityCriterionHelper baut die einzelnen
Gütekriterien in Form von QualityCriterion mit den Informationen der Ontologie
auf. Über die Helferklasse FilterHelper können die in der Ontologie hinterlegten
Informationen über die Filter abgerufen werden.
Es werden alle zum Aufbau der Eingabemaske der grafischen Oberfläche notwendigen Informationen von der Komponente ExpertSystemFrontend mithilfe der
Helferklassen des Datenmodells ermittelt. Der FilterHelper liefert beispielsweise
die notwendigen Informationen über die im Expertensystem verfügbaren Filter
und deren Eigenschaften, wie etwa den regulären Ausdruck eines Textfilters.
Die vier Helferklassen AlgorithmHelper, FilterHelper, QualityCriterionHelper
und TypeHelper sind als Singletons implementiert. Dies bedeutet, es gibt im gesamten System jeweils nur eine Instanz von ihnen, die über eine statische Methode
an der entsprechenden Klasse bezogen werden kann. Der Konstruktor dieser Klassen ist dementsprechend von außen nicht direkt aufruf- oder sichtbar. Dies bietet
den Vorteil, dass die Schnittstellen der einzelnen Komponenten einfacher gehalten werden können, da nicht immer die einzelnen Helferinstanzen durchgereicht
werden müssen. Die Nachteile sind die statischen Abhängigkeiten zwischen den
einzelnen Komponenten und den Singletons. Außerdem müssen die Singletons vor
Verwendung die Ontologie übergeben bekommen. Dazu ist eine eigene, statische
Methode implementiert. Das Initialisieren der Singletons übernimmt eine statische
Klasse Datamodel deren Methode initDatamodel die verwendete Ontologieinstanz
übergeben bekommt und damit die Singletons initialisiert.5
Auf alle Einzelheiten der Helferklassen einzugehen, würde den Rahmen dieser Arbeit übersteigen. Auf einige Besonderheiten wird allerdings in Abschnitt
6.2 noch näher eingegangen. Im Anhang sind in den Abbildungen C.1, C.2, C.3
und C.4 Details zu den einzelnen Klassen des Datenmodells in Form von UMLKlassendiagrammen dargestellt.
6.1.3 Implementierungsdetails der Berechnung und
Ausführung der IE-Pipeline
Die Komponente ProblemSolver stellt die Problemlösungskomponente des Expertensystems dar. Für die Umsetzung der topologischen Sortierung wurde das
Graph-Framework JGraphT 6 benutzt. Es bietet einfache Möglichkeiten für das
Erstellen von Graphen, das Umkehren der Kanten in Graphen und die Berechnung der transitiven Hülle.
Innerhalb der Komponente ProblemSolver befinden sich die Komponenten, die
5
6
Für mehr Informationen über Singletons siehe zum Beispiel [ES07].
http://www.jgrapht.org/
112
package Data[
ArchitekturdetailsProblemSolver ]
«component»
ExpertSystemCore
Zum Loesen des Problems
ProblemSolver
Zum Normalisieren der Ziele
«component»
ProblemSolver
Zum Optimieren der IE-Pipeline
Zum Berechnen der IE-Pipeline
GoalNormalizer
«component»
GoalNormalizer
Planner
PipelineOptimizer
«component»
PartialOrderPlanner
Zum Linearisieren des partiellen
Plans
Linearization
«component»
Linearization
Zum Ausfuehren der IE-Pipeline und zum Erhalt der Resultate
«component»
PipelineOptimizer
PipelineExecutor
«component»
PipelineExecutor
Zum Auswaehlen der besten Algorithmen waehrend des Planens
AlgorithmSelector
«component»
AlgorithmSelector
Abbildung 6.3: Die Komponenten des ProblemSolver
die in Abschnitt 4.1 und 5.4 vorgestellten Verfahren umsetzen. Dies betrifft vor
allem den angepassten Partial Order Planner, aber auch Komponenten für die
Ausführung der durch den Planer erstellen Pipeline (PipelineExecutor ). Die in Abschnitt 5.4.1 angesprochenen Aspekte der Zielanpassung im Vorfeld der Planung
und der Entfernung von dominierten Algorithmen aus der berechneten Pipeline
sind in der Komponente GoalNormalizer beziehungsweise PipelineOptimizer implementiert worden.
Die Notwendigkeit des GoalNormalizer und des PipelineOptimizer ergibt sich
aus dem in Abschnitt 5.4.1 angesprochenen Problem der nicht vollständigen Umsetzung des Paradigmas Maximum Decomposition bei den zur Verfügung stehenden Algorithmen. Andere Algorithmen, und auch andere IE-Frameworks, können
andere Optimierungen benötigen. Durch die eingesetzte Modularisierung sind diese Optimierungen sehr einfach in das bestehende Expertensystem einzufügen.
Der Partial Order Planner nutzt seinerseits die Funktionen der Komponenten Linearization und AlgorithmSelector. Während die erste Komponente das in
Abschnitt 4.1.4 besprochene Verfahren der angepassten topologischen Sortierung
eines partiellen Plans enthält, verwirklicht letztere das in Abschnitt 4.1.3 besprochene Auswahlverfahren des besten Algorithmus in einem Planungsschritt des Partial Order Planner. Durch den modularen Aufbau des Planers lassen sich sowohl
die eingesetzte topologische Sortierung, als auch die Auswahl eines besten Algorithmus einfach und unabhängig vom Planer selbst anpassen. So könnte es zum
Beispiel sein, dass eine Komponente entwickelt wird, die die Filterrate der einzelnen Algorithmen im Vorfeld bestimmen kann. Wie in Abschnitt 4.1.4 vorgestellt,
wird in dieser Arbeit nicht die eigentliche Definition eines optimierten Schedu-
113
6. Implementierung
les genutzt, weil eben jene Filterraten nicht von diesem Expertensystem bestimmt
werden können. Dementsprechend kann durch den modularen Aufbau sehr einfach
das Verfahren der topologischen Sortierung angepasst oder ausgetauscht werden,
wenn diese Informationen in Zukunft zur Verfügung stehen.
Eine Abbildung der Abhängigkeiten zwischen den Komponenten des ProblemSolver ist in Abbildung 6.3 dargestellt. Die internen Details des ProblemSolver
sind im Anhang in Abbildung C.7 in Form eines UML-Klassendiagramms zu finden. Außerdem ist im Anhang in Abbildung C.8 ein Sequenzdiagramm zu finden,
das einen exemplarischen Durchlauf durch den ProblemSolver beim Anstoßen des
Expertensystems zeigt. Die Aspekte des OntologyImporter wurden bereits in Abschnitt 5.2 vorgestellt. Im Anhang sind die Details dieser Komponente als UMLKlassendiagramm in Abbildung C.6 dargestellt.
6.2 Möglichkeiten zur Erweiterung des
Gesamtsystems
Neben den bereits in den vorherigen Abschnitten und Kapiteln aufgeführten Möglichkeiten zur Erweiterung des Expertensystems, sollen im Folgenden noch exemplarisch einige weitere Besonderheiten des Expertensystem aufgeführt werden, die
mit seiner Anpassbarkeit und Erweiterbarkeit in Verbindung stehen.
6.2.1 Wechseln des IE-Frameworks
Die Komponente ProblemSolver ist für die gesamte Berechnung der IE-Pipeline
und der Ergebnisse ihrer Ausführung zuständig. Von außen ist dabei nicht ersichtlich, und auch unwichtig, mit welchem Verfahren die Pipeline bestimmt oder
welches IE-Framework eingesetzt wird. Dies bietet den Vorteil, dass das Verfahren
oder das Framework ausgetauscht werden kann. Diese einfache Anpassbarkeit ist
nur durch die durchgeführte Trennung von Pipelineberechnung und -ausführung
möglich. Somit kann zum Beispiel ein anderes IE-Framework eingesetzt werden,
ohne das Planungsverfahren anpassen zu müssen. Hierzu sind nur die für das
Framework verwendeten Informationen in die Ontologie hinein zu kodieren. Das
bedeutet, die Informationen werden mithilfe der Elemente der Ontologie ausgedrückt. Dafür kann etwa ein neuer OntologyImporter entwickelt werden, der genau
an das einzusetzende Framework angepasst ist. Außerdem muss dann die PipelineExecution-Komponente neu geschrieben werden. Diese Komponente wandelt
eine abstrakte Pipeline, die eine Liste von Algorithm-Objekten darstellt, in eine
konkrete Pipeline des verwendeten Frameworks um. Die Pipeline wird von dem
Framework ausgeführt und die Ergebnisse müssen wieder zurück an das Expertensystem geleitet werden. Das Planungsverfahren selbst kann dabei unberührt
bleiben. Aufgrund der Eigenheiten des in dieser Arbeit verwendeten Frameworks
wurden die Komponenten PipelineOptimizer und GoalNormalizer entwickelt. Daher kann nicht ausgeschlossen werden, dass mit einem neuen Frameworks auch
114
6.2 Möglichkeiten zur Erweiterung des Gesamtsystems
neue Anpassungen dieser beiden Komponenten erforderlich werden könnten.
6.2.2 Erweiterung der Ontologie
Neben der Entwicklung von neuen Komponenten oder der Anpassung bestehender Komponenten, kann das Expertensystem außerdem noch durch Erweitern der
Ontologie angepasst werden. Hierbei sind nicht die zum Beispiel von einem OntologyImporter hinzugefügten Informationen um Typenhierarchie und verfügbare
Algorithmen gemeint, sondern die Basisontologie selbst. Hierzu werden die in Abschnitt 4.2.1 und 5.3 vorgestellten Elemente der Ontologie benutzt. Ausgenutzt
wird hierbei vor allem, dass die Helferklassen des Datenmodells dynamisch die
Informationen aus der Ontologie extrahieren, also diese Informationen nicht fest
implementiert sind.
So können auf einfache Art und Weise neue Gütekriterien in der Ontologie definiert werden, die dann automatisch vom Expertensystem benutzt werden. Hierzu
wird ein neues Individuum der Klasse Effektivitätskriterium oder Effizienzkriterium, welche beide Subklassen von Gütekriterium sind, angelegt. Zum Beispiel lässt
sich ein Individuum Speicherplatzbedarf der Klasse Effizienzkriterium anlegen. Anschließend wird diesem Individuum die Eigenschaft hatOrdnung mit dem Objekt
KleinererWertIstBesser zugewiesen. Damit ist bei der Verwendung der Werte dieses neuen Gütekriteriums sichergestellt, dass ein kleinerer Speicherplatzbedarf bevorzugt wird, wenn etwa der Speicherplatzbedarf von zwei Algorithmen verglichen
wird. Die Eigenschaft hatName des neuen Individuums wird auf Speicherplatzbedarf gesetzt. Außerdem wird durch das Verknüpfen mit der Eigenschaft istVerrechenbar und dem Wert wahr ausgedrückt, dass bei der Bestimmung des besten
Algorithmus oder des besten Filterverfahrens durch die AlgorithmSelector - beziehungsweise Linearization-Komponente die einzelnen Speicherplatzbedarfswerte
der Algorithmen aufaddiert werden, um den besten Wert zu bestimmen.
Damit ist das neue Gütekriterium vollständig in die Ontologie eingefügt worden und kann nun verwendet werden. Hierzu wird einem beliebigen Algorithmus
eine neue Güte über die Eigenschaft hatGüte zugewiesen. Diese Güte bekommt
als Eigenschaft hatGütekriterium das neue Gütekriterium Speicherplatzbedarf zugewiesen. Außerdem kann mittels der Eigenschaft hatKonkretenWert ein Wert für
die Güte festgelegt werden. Das Expertensystem wird das neue Gütekriterium direkt berücksichtigen. Weitere Anpassungen, etwa am Quellcode selbst, sind nicht
vorzunehmen.
Damit das Gütekriterium für die Bestimmung eines besten Algorithmus während
des Planens Berücksichtigung findet, muss mindestens eine neue Priorisierung
erstellt werden. So muss zum Beispiel für die gewünschte Priorisierung 1. Speicherplatzbedarf 2. Average Sentence Response Time 3. Accuracy ein Individuums
der Klasse Priorisierung erstellt werden. Für jede Priorität wird dann eine eigenes Individuum der Klasse Priorität folgendermaßen angelegt: SpeicherplatzbedarfPriorität verweist mittels einer Eigenschaft hatNachfolger auf AverageSentenceResponseTimePriorität und diese auf AccuracyPriorität. Jede der Prioritäten
115
6. Implementierung
bekommt durch die Eigenschaft hatKriterium das entsprechende Gütekriterium
zugewiesen. Bei SpeicherplatzbedarfPriorität ist dies das eben angelegte Speicherplatzbedarf Gütekriterium. Das Priorisierungindividuum kann dann mittels der
Eigenschaft hatPrioritätsreihenfolge mit dem ersten Element der Prioritätsreihenfolge, SpeicherplatzbedarfPriorität, verbunden werden. Als Letztes muss die neue
Priorisierung einer der in Abschnitt 4.1.3 vorgestellten Priorisierungen mittels der
impliziert-Eigenschaft zugewiesen werden. Das kann zum Beispiel die Priorisierung
1. Average Sentence Response Time 2. F-Measure 3. Recall (AFR-Priorisierung)
sein. Damit ist eine neue Priorisierung dem Expertensystem hinzugefügt worden.
Bei Wahl der AFR-Priorisierung in der grafischen Oberfläche wird, bei entsprechend mit dem neuen Gütekriterium versehenen Algorithmen, der Speicherplatzbedarf bei der Auswahl des besten Algorithmus berücksichtigt. Weiterhin ist es
auch noch möglich das verwendete Effizienzkriterium Average Sentence Response
Time in den Hauptpriorisierungen durch das neue Speicherplatzbedarf Kriterium
zu ersetzen.
116
7 Evaluierung
Die in diesem Kapitel durchgeführte Evaluierung soll zeigen, wie gut die umgesetzten Konzepte dieser Arbeit in der Praxis funktionieren. Dazu wird in Abschnitt 7.1 zuerst dargelegt, dass die entwickelten Verfahren grundsätzlich richtige
Ergebnisse, im Sinne des vom Benutzer spezifizierten Problems, liefern. Neben
der allgemeinen Darstellung der Funktionalität wird dabei auf die Evaluierung
des Algorithmenauswahlproblems, der topologischen Sortierung und des Filteransatzes aus den Abschnitten 4.1.3, 4.1.4 und 4.1.5, sowie die in Abschnitt 5.4.1
vorgestellten Lösungen für die Normalisierung der Eingangsziele hinsichtlich der
verwendeten Typenhierarchie und die Beseitigung von dominierten Algorithmen
eingegangen. Auf das in Teilen durch die Beseitigung von dominierten Algorithmen gelöste Problem der nicht vollständigen Zerlegung der Algorithmen wird in
Abschnitt 7.2 dann noch einmal gesondert eingegangen.
Die komplette Evaluierung in dieser Arbeit wurde auf folgender Hard- und Softwarekonfiguration durchgeführt:
• Betriebssystem: Windows 7
• Prozessor : AMD Phenom II X4 955 3,20 GHz
• Arbeitsspeicher : 4 Gigabyte
• Java Version: JDK 1.7.0 02
In die Ontologie des Expertensystems sind die Informationen aus der im Anhang in
Abbildung B.1 abgebildeten Typenhierarchie und der in Tabelle A.3 aufgezählten
Algorithmen für die Evaluierung importiert und bereits vorhanden.
7.1 Evaluierung der Funktionalität des entwickelten
Expertensystems
Bei der Evaluierung der Funktionalität geht es darum zu zeigen, dass das Expertensystem eine korrekte IE-Pipeline für die Eingaben des Benutzers berechnet
und ausführt. Die Korrektheit bezieht sich auf bestimmte Eigenschaften der berechneten Pipeline. Diese soll aus den Zielvorgaben des Benutzers berechnet worden sein. Weiterhin müssen bei der Berechnung die aufgestellten Randbedingungen bezüglich Einschränkungen der Ergebnismenge (durch Filter, vgl. Abschnitt
4.1.5) und Anforderungen an die Qualität der IE-Pipeline (durch die Einhaltung
117
7. Evaluierung
Algorithmus
Eingabe
Ausgabe
Güte
WhitespaceTokenizer
PlainText
Sentence, Token,
Filtered
ASRT
0, 04
TimeRecognizer
Token, Sentence
TimeExpression
ASRT
F1
R
P
0, 36
0, 94
0, 97
0, 91
TTPOSLemmatizer
Token
Token(lemma; pos)
ASRT
Acc
0, 30
0, 97
ForecastClassifier
Filtered,
TimeExpression,
Token(lemma; pos)
Forecast
ASRT
Acc
0, 29
0, 93
MoneyRecognizer
Token, Sentence
MonetaryExpression
(types)
ASRT
F1
R
P
0, 64
0, 97
0, 95
0, 99
MTFastDepedencyParser
Token(lemma; pos),
Sentence
Token(dependency;
parent)
ASRT 54, 61
LAS
0, 87
TimeMoneyRERB
Token(dependency;
lemma; parent; pos),
MonetaryExpression,
TimeExpression,
Filtered, Sentence
FinancialStatement
(timeExpression;
monetaryExpression)
ASRT
F1
R
P
0, 02
0, 77
0, 88
0, 69
Tabelle 7.1: Die in der Pipeline Πeval vorkommenden IE- und NLP-Algorithmen. In
der Spalte Güte sind Gütekriterium und Wert der Güte zusammengefasst
dargestellt. ASRT = Average Sentence Response Time; Acc = Accuracy;
F1 = F-Measure; R = Recall; P = Precision; LAS = Labeled Attachement
Score
der angegeben Prioritätsreihenfolge, vgl. Abschnitt 4.1.3) beachtet sein. Die Methoden zur Erstellung von effizienten IE-Pipelines bei der Berechnung der IEPipeline sollen ebenfalls angewendet und berücksichtigt sein. Bei der Berechnung
und Ausführung sind also die in Kapitel 4 und 5 vorgestellten Verfahren und
Lösungsansätze zu berücksichtigen. Daher wird auf die Evaluierung des Lösungsansatzes für die Auswahl eines Algorithmus in einem Planungsschritt(Abschnitt
7.1.2) und der Erfüllung der Randbedingungen durch Filter (Abschnitt 7.1.3) genauer eingegangen. Begonnen wird mit der Vorstellung einer berechneten Pipeline
Πeval , die dann eingehender analysiert wird. Die in dieser Pipeline befindlichen Algorithmen sind mit ihren benötigten Ein- und erzeugten Ausgaben, sowie ihren
Effektivitäts- und Effizienzgütekriteriumswerten in Tabelle 7.1 aufgezählt.
118
7.1 Evaluierung der Funktionalität des entwickelten Expertensystems
7.1.1 Analyse einer berechneten IE-Pipeline
Im Folgenden soll ein Beispiel von der Angabe der durch den Benutzer spezifizierten Eingaben, über die Berechnung des Abhängigkeitsgraphen und der resultierenden IE-Pipeline Πeval , bis zu den nach der Ausführung dieser IE-Pipeline
vorhandenen Ergebnissen gezeigt und analysiert werden.
In der grafischen Oberfläche des Expertensystems sind dazu folgende Eingaben
gemacht worden:
• Als Priorisierung für die Auswahl der Algorithmen wurde gewählt: 1. Average Sentence Response Time 2. F-Measure 3. Recall. Dies entspricht dem
Punkt tF1 R aus Abbildung 4.3 in Abschnitt 4.1.3.
• Für die topologische Sortierung wurde festgelegt, dass die Average Sentence
Response Time der Filterverfahren für die Bestimmung des besten Filterverfahrens genutzt wird (vgl. Abschnitt 4.1.4).1
• Das Ziel, welches die zu berechnende Pipeline erfüllen soll, ist es, Zeitaussagen von Marktvorhersagen zu bestimmen. Dementsprechend wurde Forecast
als Annotationstyp und sein Attribut timeExpression als Ziel ausgewählt.
• Die Textmenge, in welcher die berechnete Pipeline nach Marktvorhersagen
suchen soll, ist die Testmenge des Revenue Korpus, welcher zur Evaluierung der in [WPS10] erstellten IE-Pipeline diente, und aus 188 Dokumenten
besteht.
Auf diesen Eingaben ist das Expertensystem gestartet worden. Die Ausführung der
berechneten Pipeline auf dem angegebenen Teil-Korpus liefert 213 Ergebnisse. Ein
Ergebnis hat dabei die Form: Text für Forecast, Text für Attribut timeExpression.
Ein Beispiel für ein Ergebnis ist:
Text für Forecast: 2010 rechnet iSuppli aber wieder mit einem Wachs”
tum von 4,7 Prozent.“
Text für Attribut timeExpression: 2010
Normalisierung der Ziele
Der erste Schritt des Expertensystems ist die Normalisierung der Ziele für den
Partial Order Planner, wie in Abschnitt 5.4.1 vorgestellt. Im Beispiel wird daher
das eingegebene Ziel Forecast.timeExpression vom Expertensystem in die Zielmenge {FinancialStatement.timeExpression, Forecast} umgewandelt. Dies ist korrekt,
denn es gibt keinen Algorithmus in der vorhandenen Algorithmenmenge, der Forecast mit dem Attribut timeExpression direkt erzeugt. Daher versucht das Expertensystem einen Algorithmus zu identifizieren, der einen Supertypen von Forecast
mit dem Attribut timeExpression als Ausgabe hat.
1
Hiermit ist gemeint, dass der Benutzer das Kriterium, anhand dessen die topologische Sortierung ausgeführt werden soll, frei bestimmen kann.
119
7. Evaluierung
Aus der verwendeten Typenhierarchie ist ersichtlich, dass RevenueStatement
der direkte Supertyp von Forecast ist. Allerdings existiert auch kein Algorithmus,
der RevenueStatement mit dem Attribut timeExpression direkt erzeugt. Aus diesem Grund muss das Expertensystem in der Typenhierarchie den nächst höheren
Supertypen von RenvenueStatement identifizieren. Dies ist FinancialStatement.
Gleichzeitig weiß das Expertensystem auch, dass dies der letztmögliche Annotationstyp sein kann, für den es einen Algorithmus gibt, der diesen Typ als Ausgabe
hat. Der Grund hierfür ist das erstmalige Auftauchen des Attributs timeExpression an diesem Typ. Es existiert demnach kein Supertyp von FinancialStatement,
welcher dieses Attribut besitzt. Das Expertensystem würde mit einem Fehler abbrechen, wenn es nicht mit TimeMoneyRE oder TimeMoneyRERB zumindest
einen Algorithmus gibt, der FinancialStatement mit dem Attribut timeExpression erzeugen kann.
Als zweites Ziel der Zielmenge bleibt dann noch Forecast ohne ein Attribut
übrig. Somit wurde die Zielnormalisierung korrekt durchgeführt. Daraufhin werden
alle Algorithmen, welche die Ziele der Zielmenge direkt oder das Attribut eines
Zielannotationstyps erfüllen, als Filterverfahren markiert. Dies sind insbesondere
die Algorithmen TimeRecognizer, TimeMoneyRERB und ForecastClassifier.
Berechnung des Abhängigkeitsgraphen
Mit den normalisierten Zielen kann der Partial Order Planner des Expertensystems versuchen, einen partiellen Plan für die zu bestimmende Pipeline zu berechnen (vgl. Abschnitt 4.1.2). Der berechnete partielle Plan ist in Abbildung 7.1 als
Abhängigkeitsgraph dargestellt. Hierbei wurde der Übersicht halber auf alle redundanten Abhängigkeiten verzichtet. So hat der TimeMoneyRERB Algorithmus
zum Beispiel die benötigte Eingabe Sentence, welche vom WhitespaceTokenizer
erzeugt wird. Allerdings hat mit MoneyRecognizer mindestens ein Vorgänger von
TimeMoneyRERB dieselbe benötigte Eingabe. Damit muss diese schon vorliegen,
wenn TimeMoneyRERB ausgeführt werden soll und wird demnach in der Abbildung nicht dargestellt. An jedem Knoten ist weiterhin der Wert für die Average
Sentence Response Time des jeweiligen Algorithmus angegeben.
Der Planer beginnt mit dem Teilziel FinancialStatement.timeExpression. Dieses Ziel ist in der Ausgabe der beiden Algorithmen TimeMoneyRE und TimeMoneyRERB enthalten. Nun wird aufgrund der eingestellten Priorisierung der
beste Algorithmus bestimmt. Bei der gewählten Priorisierung hat die Effizienz
in Form von Average Sentence Response Time die höchste Priorität. Da beide
betrachteten Algorithmen die gleichen Eingaben benötigen, und damit die gleichen besten Vorgänger haben, ist der direkte Wert für das Gütekriterium Average
Sentence Response Time entscheidend. Hiermit begründet sich die Wahl für TimeMoneyRERB, welches den niedrigeren und somit besseren Wert besitzt. Das
Expertensystem greift hier auf die Information der Ontologie zurück, das kleinere
Werte bei dem Gütekriterium Average Sentence Response Time bessere Werte
bedeuten. Die benötigten Eingaben von TimeMoneyRERB werden als neue Teil-
120
WhiteSpaceTokenizer
0,04
MoneyRecognizer
TimeRecognizer
TTPOSLemmatizer
0,64
0,36
0,3
MTFastDependencyParser 54,61
TimeMoneyRERB
ForecastClassifier
0,02
0,29
Abbildung 7.1: Abhängigkeitsgraph nach Planung mit Average Sentence Resonse TimeWert für jeden Algorithmus. Grau hinterlegt die Filterverfahren.
ziele auf die Agenda des Planers gesetzt. Der Planer versucht nun für das nächste
offene Teilziel einen besten Algorithmus zu finden, bis die Agenda leer ist und es
somit keine offenen Ziele mehr gibt. So fällt zum Beispiel bei der Entscheidung für
einen Algorithmus für das Teilziel Token.parent auf MTFastDepedencyParser, da
sich für diesen Algorithmus ein besserer Effizienzwert ergibt, als für den ebenfalls
betrachteten MTBestDepedencyParser.
Die Bestimmung des jeweils besten Algorithmus für ein Teilziel wird für das Beispiel immer durch die bessere Effizienz in Form der niedrigeren, aufsummierten
Average Sentence Response Time entschieden. Hierbei gibt es mit dem ForecastClassifier eine Ausnahme. Der Algorithmus liegt in drei Varianten vor, wobei
die zwei Forecast Annotationen erzeugenden Algorithmen hier die wichtigen sind.
Die eine Variante erzeugt nur Forecast Annotationen. Die andere erzeugt Forecast
und Declaration Annotationen. Allerdings besitzen beide die gleichen Werte für
die jeweiligen Gütekriterien. Damit ist es einerseits für den Planer egal, welchen
von beiden er auswählt. Andererseits müssen für diese Entscheidung die Werte
hinsichtlich der gewählten Priorisierung verglichen werden. Da keiner von beiden
F-Measure oder Recall Werte besitzt, wird als Priorisierung die implizite Priorisierung 1. Average Sentence Response Time 2. Accuracy zum Vergleich gewählt.
Jeder dieser Werte ist bei beiden Algorithmen gleich, daher entscheidet der lexographische Vergleich, und damit in diesem Fall die Reihenfolge der Betrachtung,
welcher Algorithmus gewählt wird.
Bei der Berechnung des Abhängigkeitsgraphen durch den Planer wurden immer
die effizientesten (hinsichtlich ihrer aufsummierten Laufzeitkosten) Algorithmen
gewählt. Der Abhängigkeitsgraph ist demnach korrekt berechnet worden.
121
7. Evaluierung
WhiteSpace
Tokenizer
Time
Recognizer
TTPOS
Lemmatizer
Forecast
Classifier
Money
Recognizer
MTFast
Dependency
Parser
TimeMoney
RERB
Abbildung 7.2: Berechnete Pipelines Πeval . Grau hinterlegt die Filterverfahren.
Pipeline nach topologischer Sortierung
Die topologische Sortierung führt das Expertensystem nach dem in Abschnitt 4.1.4
beschriebenen Verfahren aus. Die in Abbildung 7.1 als Zahl an den Knoten dargestellte Average Sentence Response Time wird als Kriterium für die Bestimmung
eines besten Filterverfahrens genutzt. Die daraus entstehende Pipeline Πeval ist in
Abbildung 7.2 zu sehen.
Filterverfahren im Abhängigkeitsgraphen sind ForecastClassifier, TimeMoneyRERB und TimeRecognizer. Die Vorgänger von ForecastClassifier sind TTPOSLemmatizer, TimeRecognizer und WhitespaceTokenizer. Die Vorgänger von TimeMoneyRERB sind MTFastDepedencyParser, MoneyRecognizer, TTPOSLemmatizer, TimeRecognizer und WhitespaceTokenizer. Der einzige Vorgänger von TimeRecognizer ist der WhitespaceTokenizer. Auf Basis der Vorgänger wird die akkumulierte Average Sentence Response Time für jedes Filterverfahren bestimmt.
Dazu werden die einzelnen Werte der Vorgänger zusammen mit dem Wert des
Filterverfahrens aufaddiert (siehe Abbildung 7.1 für die Einzelwerte der Algorithmen). Damit ergibt sich für ForecastClassifier ein Wert von 0, 99, für TimeMoneyRERB ein Wert von 55, 97 und für die TimeRecognizer ein Wert von 0, 39. Damit
wird der TimeRecognizer als bestes Filterverfahren gewählt. Der schlechte Wert
von TimeMoneyRERB ergibt sich vor allem aus dem Wert 54, 61 für den MTFastDepedencyParser. Nachdem der TimeRecognizer und sein Vorgänger anhand ihrer
topologischen Sortierung der IE-Pipeline hinzugefügt wurden, werden die Werte
für die beiden übrig gebliebenen Filterverfahren aktualisiert und wiederum das
beste ausgewählt. Diesmal wird der ForecastClassifier mit einem Wert von 0, 59
dem TimeMoneyRERB mit einem Wert von 55, 57 vorgezogen und mit seinem
noch nicht in die IE-Pipeline hinzugefügten Vorgänger TTPOSLemmatizer topologisch sortiert und der IE-Pipeline hinzugefügt. Anschließend werden das noch
einzig übrig gebliebene Filterverfahren TimeMoneyRERB und seine noch nicht
sortierten Vorgänger MTFastDepedencyParser und MoneyRecognizer topologisch
sortiert und der IE-Pipeline angehängt.
Diese Sortierung ist korrekt hinsichtlich der in Abschnitt 4.1.4 beschriebenen
Definition eines statisch optimierten Schedules. Außerdem wird die vom Planer berücksichtigte Ordnung hinsichtlich des Paradigmas Lazy Evaluation nicht
verändert und sie bleibt somit bestehen. Durch die Betrachtung der Filterverfahren zur topologischen Sortierung wird gewährleistet, dass diese so früh wie möglich
ausgeführt werden, unter Berücksichtigung ihrer jeweiligen Vorgänger. Damit findet auch das Paradigma Early Filtering Berücksichtigung.
Die entstandene abstrakte IE-Pipeline wird dann, wie in Abschnitt 4.1.6 und
122
Planen
Topologische Sortierung
Optimierung
Aufbau der UIMA-Pipeline
Ausführung der UMIA Pipeline
Mittelwert1
σ1
Mittelwert2
σ2
36
5
7
3.505
85.109
6
4
7
70
1.043
57
6
7
20.712
87.682
8
3
3
1.132
1.132
Tabelle 7.2: Laufzeitwerte für Teile des Expertensystems in Millisekunden (Nachkommastellen gerundet).
5.4.2 beschrieben, in eine UIMA-IE-Pipeline umgewandelt und von UIMA ausgeführt. Nach der Ausführung entstehen die eingangs erwähnten Resultate bezüglich
der gefundenen Forecast.timeExpression Annotationen.
Evaluierung der Laufzeit
Für die Evaluierung der Laufzeit vom Starten des Expertensystems auf der Eingabe, bis zur Präsentation der Ergebnisse, wurden im Kalt- und im Warmstart
zehn Durchläufe durchgeführt. Kaltstart bedeutet, das System wurde vor jedem
Durchlauf komplett neu gestartet. Beim Warmstart sind die zehn Durchläufe nach
einem ersten Initialisierungsdurchlauf gemessen worden. Dadurch wird zum Beispiel der Unterschied zwischen Durchläufen mit und ohne Initialisierungskosten
sichtbar. Die Ergebnisse sind in Tabelle 7.2 zu sehen.
In der Tabelle sind die Laufzeitwerte für unterschiedliche Bereiche des Expertensystems in Millisekunden eingetragen. Die Zeit für das Planen ist die Dauer
vom Starten der Planung bis zur Berechnung des Abhängigkeitsgraphen durch
den Planer. In der folgenden Zeile stehen die Zeiten für die Durchführung der
verwendeten topologischen Sortierung. Eine Zeile weiter stehen die Zeiten für die
Optimierung in Form des Findens und Beseitigens von dominierten Algorithmen.
Die vorletzte Zeile gibt die Zeiten für die Konstruktion einer konkreten UIMAAggregate Analysis Engine aus der abstrakten, berechneten Pipeline an. Die Dauer
der Ausführung dieser UIMA-Pipeline auf den 188 Dokumenten ist in der letzten
Zeile zu sehen. In der zweiten Spalte der Tabelle stehen die berechneten Mittelwerte. Ihnen folgt die Standardabweichung σ1 von diesen Mittelwerten. Diese beiden
Spalten geben Mittelwert und Standardabweichung für die zehn Durchläufe bei einem einzigen Programmstart und nach einem ersten Initialisierungsdurchlauf an.
Die letzten beiden Spalten zeigen den Mittelwert und die Standardabweichung
für zehn Durchläufe mit Initialisierungskosten. Hier ist vor jedem Durchlauf das
Expertensystem neu gestartet worden.
Die Daten zeigen, dass die Berechnung der abstrakten Pipeline durch das Expertensystem um das 100- bis 2.000-fache schneller ist im Vergleich zum Aufbau der
Strukturen des verwendeten IE-Frameworks und der letztendlichen Ausführung
der konkreten Pipeline auf den Dokumenten. Eine Berechnung der abstrakten Pi-
123
7. Evaluierung
Sentence
Splitter
Tokenizer
Time
Recognizer
MT
Lemmatizer
MT
POSTagger
Forecast
Classifier
Money
Recognizer
MTBest
Dependency
Parser
TimeMoney
RE
Abbildung 7.3: Berechnete Evaluierungspipeline Πeval2 mit Fokus auf Effektivität. Grau
hinterlegt die Filterverfahren.
peline dauert im Mittel circa 36 − 57 Millisekunden. Die Laufzeiten sind geringer,
wenn das Expertensystem schon einige Durchläufe berechnet hat. Dies erklärt
sich mit dem Einsatz von Caching-Strukturen innerhalb der Komponenten des
Expertensystems. Die Berechnung der abstrakten Pipeline ist zu vernachlässigen
im Vergleich zu den circa 90.000 − 100.000 ms, die Konstruktion und Ausführung
der UIMA-Pipeline benötigen. Die hohen Werte für die Konstruktion der UIMAPipeline liegen vor allem in der Initialisierung der einzelnen Analysis Engines.
Hier müssen zum Teil sehr große Modelle geladen und initialisiert werden. Dieser
Vorgang wiederholt sich bei dem Aufbau von vielen Aggregate Analysis Engines
von neuem. Eine Ausnahme sind zum Beispiel die Komponenten des TreeTagger,
welche beispielsweise beim TTPOSLemmatizer zum Einsatz kommen. Sie werden
nur einmal initialisiert und gestartet und sind dann die komplette Programmzeit
über aktiv. Damit erklärt sich auch der hohe Mittelwert bei der Konstruktion der
UIMA-Pipeline von über 20 Sekunden, wenn das Expertensystem immer neu gestartet wird. Schwankungen aufgrund von anderen im PC laufenden Hintergrundprozessen werden erst bei einer längeren Laufzeit sichtbar. Daher lässt sich die
Standardabweichung von circa einer Sekunde für die Ausführung der IE-Pipeline
erklären. Dies könnte vor allem an I/O-Operationen liegen, wie dem Zugriff auf
die Modelle oder die Dokumente auf der Festplatte. Ähnliche Effekte scheinen für
die hohen Standardabweichungen bei den Werten für die Berechnung der abstrakten Pipeline verantwortlich zu sein. Allerdings bleibt diese kleine Zeitspanne im
Vergleich zu den mehreren Sekunden bei der Aufstellung der UIMA-Pipeline von
relativ geringer Bedeutung.
7.1.2 Evaluierung des Lösungsansatzes des
Algorithmenauswahlproblems
Im Folgenden wird die Lösung des Algorithmenauswahlproblems durch die in Abschnitt 4.1.3 vorgestellten Priorisierungen analysiert. Dafür soll das bisher betrachtete Beispiel mit einer anderen Priorisierung betrachtet werden. Für die Beispielpipeline Πeval in Abschnitt 7.1.1 wurde die Priorisierung 1. Average Sentence Response Time 2. F-Measure 3.Recall gewählt. Hierdurch wird versucht,
eine möglichst effiziente Pipeline zu konstruieren, da das Effizienzmaß bei der
Auswahl eines geeigneten Algorithmus zuerst betrachtet wird. Eine Priorisierung,
die demgegenüber auf eine möglichst effektive IE-Pipeline abzielt, ist zum Beispiel
1. F-Measure 2. Recall 3. Average Sentence Response Time.
Genau diese Priorisierung ist gewählt worden, unter Beibehaltung aller anderen
124
in Abschnitt 7.1.1 beschriebenen Eingaben. Das Expertensystem hat daraufhin
die in Abbildung 7.3 abgebildete Pipeline konstruiert. Die in dieser Pipeline verwendeten Algorithmen unterscheiden sich, bis auf drei Algorithmen, deutlich von
denen aus Pipeline Πeval . Mit Blick auf die Effektivitäts- und Effizienzwerte der
einzelnen Algorithmen der Algorithmenmenge in Tabelle A.3 lassen sich die Unterschiede zwischen den Pipelines allerdings leicht erklären. In der Pipeline Πeval2
wurden die für ein Teilziel effektivsten Algorithmen gewählt. Die beiden Algorithmen SentenceSplitter und Tokenizer ersetzen daher in dieser Pipeline den WhitespaceTokenizer. Beide besitzen Werte für das Effektivitätsmaß Accuracy und
werden damit dem WhitespaceTokenizer vorgezogen. Die während der Planung
zu erreichenden Teilziele Token.pos und Token.lemma werden in dieser Pipeline nicht mehr vom TTPOSLemmatizer erzeugt, sondern von den Algorithmen
MTLemmatizer und MTPOSTagger, da beide einen höheren Wert für das Effektivitätsgütekriterium Accuracy haben. Genauso verhält es sich bei den restlichen
geänderten Positionen in der Pipeline. Immer sind diejenigen Algorithmen für ein
zu erreichendes Teilziel während der Planung gewählt worden, die eine höhere Effektivität aufweisen. Daher ist die berechnete IE-Pipeline Πeval2 auch korrekt, im
Sinne der vom Benutzer getroffenen Eingaben, berechnet worden.
Eine Analyse der vom Expertensystem verwendeten Algorithmenmenge zeigt,
dass es in den allermeisten Fällen einen schnellen, aber weniger effektiven, und
einen effektiveren, aber langsameren, Algorithmus für eine bestimmte Ausgabe gibt. Dadurch wird bei der Berücksichtigung der Priorisierung meist schon
beim Vergleich der Werte für die erste Priorität in Form eines Gütekriterium der
Priorisierung ein bester Algorithmus bestimmt. Der ForecastClassifier bildet eine
Ausnahme. Neben diesem Algorithmus gibt es noch den ForecastClassiferAll, der
ebenfalls Forecast erzeugt. Allerdings haben beide Algorithmen dieselbe Implementierung und demnach auch die gleichen Werte für Effektivität und Effizienz.
Der einzige Unterschied ist, dass beim ForecastClassifier das Erzeugen von Declaration Annotationen abgeschaltet ist.
Mit den unterschiedlichen Algorithmen des StanfordNER, etwa der StanfordOrganizationNER zum Finden von Organization-Annotationen, liegt ein ebensolcher
Fall, wie beim ForecastClassifier vor. Auch hier sind die Werte der Algorithmen
gleich, weil hinter allen dieselbe Implementierung arbeitet. Eine weitere Besonderheit der StanfordNER-Algorithmen ist, dass diese nur einen Effektivitätswert in
Form des F-Measure aufweisen. Die anderen Algorithmen, die die gleiche Ausgabe wie die einzelnen StandfordNER besitzen, zum Beispiel der OrganizationNER,
haben ebenfalls nur einen Effektivitätswert, allerdings in Form des Recalls. Wird
jetzt eine Priorisierung gewählt, in der die Effektivität im Vordergrund steht,
so entscheidet die Reihenfolge von F-Measure und Recall in dieser Priorisierung,
welche Algorithmen genommen werden. Steht zum Beispiel der F-Measure in der
Reihenfolge vor dem Recall, wie in 1. F-Measure 2. Recall 3. Average Sentence
Response Time, so wird immer ein StanfordNER genommen.
Insgesamt lässt sich festhalten, dass die Lösung des Algorithmenauswahlproblems die vom Benutzer festgelegten Randbedingungen einhält. Der Wunsch nach
125
7. Evaluierung
WhiteSpace
Tokenizer
Time
Recognizer
TextFilter
TTPOS
Lemmatizer
Forecast
Classifier
Money
Recognizer
MTFast
Dependency
Parser
TimeMoney
RERB
Abbildung 7.4: Berechnete Evaluierungspipeline Πeval3 mit Textfilter. Grau hinterlegt
die Filterverfahren. Textfilter hervorgehoben.
einer möglichst effizienten oder effektiven Pipeline wird berücksichtigt, wie die
beiden Pipelines Πeval (effizient) und Πeval2 (effektiv) zeigen.
7.1.3 Evaluierung des Filteransatzes
Die Berücksichtigung von Randbedingungen bezüglich der Einschränkung der Ergebnismenge ist, wie in Abschnitt 4.1.5 beschrieben, durch Einfügung von Filtern
in die IE-Pipeline gelöst worden. Um diesen Ansatz zu evaluieren, wird die Eingabe von Abschnitt 7.1.1 um einen Filter erweitert.
Es sollen als Ergebnis der IE-Pipeline nur die Marktvorhersagen (Forecast)
Annotationen zurückgegeben werden, deren Zeitraum (TimeExpression) im Jahr
2010 liegt. Der gewählte Filter ist ein Textfilter. Da aus Gründen der Vergleichbarkeit die Pipeline Πeval aus Abschnitt 7.1.1 als Basis genommen wird, kann
der Datumsfilter nicht benutzt werden. Der Zeitraum müsste für ihn normalisiert
vorliegen. Für diese Normalisierung wird in der Pipeline der Algorithmus TimeResolver benötigt. Damit wären die Pipelines allerdings nicht mehr vergleichbar.
Aus diesem Grund wird ein Textfilter zur Filterung eingesetzt. Hiermit werden
zwar nicht alle Vorhersagen aus dem Jahr 2010 gefunden und damit gefiltert, zur
Veranschaulichung der Ergebnisse reicht der Filter allerdings aus. Als zu filternder
Annotationstyp ist TimeExpression eingestellt worden. Die Annotation mit dem
Text im Jahre 2010“ wird also durch den Filter hindurch gelangen.
”
Das mit diesen Eingaben gestartete Expertensystem berechnet die in Abbildung
7.4 dargestellte Pipeline Πeval3 . Der Filter ist korrekterweise nach dem TimeRecognizer in der Pipeline platziert worden, da TimeRecognizer der Algorithmus ist,
welcher mit TimeExpression den zu filternden Annotationstyp als Ausgabe hat.
Die Pipeline Πeval3 wird zehn mal auf derselben Textmenge ausgeführt, wie zuvor die Pipeline Πeval . Die Ausführung der konkreten mit dem Filter versehene
UIMA-IE-Pipeline benötigt auf der gegebenen Textmenge im Mittel 5235 Millisekunden, bei einer Standardabweichung von σ = 223 Millisekunden. Durch die
frühe Filterung des Textfilters ist die entstandene Pipeline demnach mehr als fünfzehn mal so schnell, als die Pipeline ohne diesen Filter. Die Ergebnismenge umfasst
21 Forecast-Annotationen, die ein TimeExpression-Attribut besitzen. Jeder Text
der gefundenen Annotationen enthält korrekterweise den Text 2010“.
”
Das Ergebnis zeigt, dass durch das Hinzufügen eines Spezialfilters direkt in
die Pipeline, sehr viel Zeit bei der Gesamtlaufzeit dieser Pipeline eingespart werden kann. Leicht ersichtlich ist demnach, dass eine nachträgliche Filterung der
Ergebnismenge eine weitaus schlechtere Gesamtlaufzeit zur Folge hat. Eine Ein-
126
7.2 Evaluierung des Problems der nicht vollständigen Maximum Decomposition
schränkung betrifft allerdings Filter, die nicht auf einzelnen Entitäten, wie Zeitaussagen, sondern zum Beispiel auf den Attributen von Relationen oder Ereignissen
filtern. Im Allgemeinen werden Relationen oder Ereignisse erst sehr spät in der
Pipeline bestimmt. Dadurch verringert sich der positive Effekt auf die Gesamtlaufzeit der Pipeline durch einen solchen Filter entsprechend. Kann das Expertensystem keinen Algorithmus identifizieren, der innerhalb der Pipeline den zu
filternden Annotationstypen des Filters erzeugt, so wird der Filter am Ende der
Pipeline eingefügt. Dadurch hat der Filter keinen positiven Effekt mehr auf die
Gesamtlaufzeit der Pipeline. Es ist dem Benutzer überlassen, ob erst nach der
Bestimmung der Relationen oder Ereignisse das Attribut der jeweiligen Relation oder des Ereignisses gefiltert werden soll, oder schon nach der Erzeugung der
hinter dem Attribut stehenden Annotationen (vgl. Abschnitt 4.1.5). So kann der
Benutzer zum Beispiel selber wählen, ob der Filter sich auf TimeExpression oder
aber auf Forecast.timeExpression beziehen soll. Das Beispiel in Abschnitt 4.1.5
zeigt allerdings, dass diese Wahl nicht in jedem Fall möglich ist und in solchen
Fällen auch die positiven Effekte von Filtern innerhalb der Pipeline auf deren
Laufzeit gering ausfallen würden.
7.2 Evaluierung des Problems der nicht
vollständigen Maximum Decomposition
Ein in Abschnitt 5.4.1 angesprochenes Problem ist die nicht komplett durchgeführte Zerlegung der Algorithmen nach dem Paradigma Maximum Decomposition. Ein
Teilproblem hiervon zeigt sich in dem Vorhandensein von dominierten Algorithmen innerhalb einer berechneten Pipeline. Als Lösung wurde ein Verfahren vorgeschlagen, welches diese dominierten Algorithmen aus einer berechneten Pipeline
entfernen kann (siehe ebenfalls Abschnitt 5.4.1).
Nach der Analyse der dem Expertensystem zur Verfügung stehenden Algorithmenmenge lässt sich nur ein Fall identifizieren, in dem ein Algorithmus einen anderen dominieren kann. Dies ist der Fall, wenn der TTChunker in einer Pipeline vor
dem TTPOSLemmatizer ausgeführt werden soll. Der TTChunker erweitert den
TTPOSLemmatizer nur um das Finden von Token.chunk. Die Implementierung
für alle anderen Ausgaben ist bei beiden gleich. Daher sind auch die Effektivitätswerte der beiden Algorithmen gleich. Aus diesem Grund dominiert der TTChunker
immer den TTPOSLemmatizer, sobald er in der Pipeline als erster von beiden ausgeführt wird. Dies ist nur dann der Fall, wenn die beiden Teilziele Token.lemma
und Token.chunk während des Planens betrachtet werden müssen. Aufgrund der
gleichen Effektivität wird für das erste Teilziel immer der TTPOSLemmatizer
gewählt werden. Da Token.chunk allerdings nur vom TTChunker erzeugt wird,
wird er für die Erfüllung dieses Teilziels herangezogen.
In allen anderen Fällen, in denen eine gleiche Ausgabe von Algorithmen vorhanden ist, sind entweder die Effektivitätsmaße verschieden und daher kann keiner der
127
7. Evaluierung
Algorithmen einen anderen mit gleicher Ausgabe dominieren. Oder aber es handelt sich um sich gegenseitig ausschließende Algorithmen, die nie zusammen in
einer Pipeline auftreten. Ein Beispiel für den ersten Fall ist der ForecastClassifier
und der StatementOnRevenueIdentifier. Beide haben als Ausgabe explizit oder
implizit RevenueStatement. Dennoch haben sie mit F-Measure beziehungsweise
Accuracy unterschiedliche Effektivitätskriterien. Der zweite Fall wurde bereits in
Abschnitt 7.1.2 angesprochen. So wird immer der effektivere oder der effizientere
Algorithmus für eine bestimmte Ausgabe in der Pipeline vorkommen, aber nie
beide zusammen (entweder TTPOSLemmatizer oder aber MTLemmatizer ).
Daher kann geschlossen werden, dass zumindest für die vorliegende und benutzte Algorithmenmenge das Problem der nicht komplett durchgeführten Zerlegung
nach dem Maximum Decomposition Paradigma keine negativen Auswirkungen auf
die vom Expertensystem erzielten Ergebnisse hat. Hiervon ausgenommen ist der
in Abschnitt 5.4 angesprochene Fall, dass der TTChunker bereits bestehende Annotationen überschreibt, die eventuell von einem bereits ausgeführten und effektiveren MTLemmatizer gemacht wurden. Zur Lösung müsste die Implementierung
des TTChunker so angepasst werden, dass bereits bestehende Annotationen bei
Bedarf nicht überschrieben werden. Bei der Nutzung einer anderen Algorithmenmenge kann allerdings nicht ausgeschlossen werden, dass eine dort fehlende Zerlegung der Algorithmen nach dem Maximum Decomposition Paradigma nicht doch
Probleme für das Expertensystem und seine Ergebnisse verursacht.
128
8 Zusammenfassung und Ausblick
In dieser Arbeit wurde ein Expertensystem für die Konstruktion und Ausführung
von Information-Extraction-Pipelines entwickelt. Durch dieses Expertensystem
lässt sich der zeitaufwändige, und damit teure, manuelle Prozess der Erstellung
einer IE-Pipeline automatisieren.
Für die Konstruktion von IE-Pipelines wurde ein speziell auf die Domäne Information Extraction angepasster Partial Order Planner entwickelt. Mittels dieses
Planers und der beteiligten Komponenten, in Gestalt der Problemlösungskomponente, war es möglich, IE-Pipelines zu konstruieren, die nicht nur eine ganz bestimmte Art von Informationen in Texten identifizieren können, sondern auch Anforderungen an die Qualität, hinsichtlich Effizienz und Effektivität, einhalten. Dazu wurde auch das Planungsproblem definiert, welches von diesem Planer und damit dem Expertensystem gelöst werden musste. Außerdem berücksichtigt der Planer die vorhandenen Paradigmen für die Konstruktion von effizienten IE-Pipelines.
Für die Ausführung der berechneten IE-Pipelines sind weiterhin die Besonderheiten des verwendeten IE-Frameworks UIMA berücksichtigt worden. Hierbei wurden
auch Probleme durch die Algorithmenmenge, aus der sich eine IE-Pipeline zusammen setzen kann, identifiziert und für diese Menge gelöst. Die Funktionalität des
Expertensystems konnte ebenfalls erfolgreich evaluiert werden. Die Berücksichtigung von Einschränkungen der Ergebnismenge durch das Hinzufügen von zusätzlichen Filtern in die IE-Pipeline wurde ebenfalls umgesetzt. Außerdem konnte
gezeigt werden, dass damit eine große Effizienzsteigerung möglich wird, was vor
allem bei dynamischen und großen Textmengen, wie sie zum Beispiel im World
Wide Web vorliegen, ein Vorteil sein kann.
Die Grundlage für die Arbeit der Problemlösungskomponente bildet die Wissensbasis in Form einer OWL-Ontologie. Bei der Entwicklung dieser Wissensbasis
wurde das vom Planer benötigte Wissen identifiziert und formalisiert. Außerdem
wurde mit der Wissenserwerbskomponente ein Importer entwickelt, der die vorliegenden Daten des verwendeten IE-Frameworks UIMA automatisiert in die Ontologie einfügen kann und somit zukünftige Erweiterungen, zum Beispiel hinsichtlich
der verwendeten Algorithmenmenge, sehr einfach möglich macht.
Der modulare Aufbau des entwickelten Expertensystems erleichtert dessen Anpassbarkeit und Erweiterbarkeit. Einige mögliche Punkte zur Erweiterung wurden
genannt. Hierbei spielt das Hinzufügen von neuem Wissen, zum Beispiel in Form
neuer IE-Algorithmen oder Gütekriterien, in die verwendete Ontologie eine zentrale Rolle. Es wurde gezeigt, dass dieses neu in die Ontologie eingefügte Wissen
ohne Anpassungen am Quellcode direkt genutzt werden kann. Durch den modularen Aufbau konnten außerdem die Komponenten, welche abhängig von dem ver-
129
8. Zusammenfassung und Ausblick
wendeten IE-Framework UIMA sind, vom Rest des Expertensystems entkoppelt
werden. Somit sind die Quellcodeänderungen beim Wechsel des IE-Frameworks lokal begrenzt. Auch durch die Verwendung des Datenmodells wurde, mit der damit
erfolgten Kapselung der Wissensbasis, eine zukünftige Änderung und Erweiterung
des Expertensystems vereinfacht.
Ausblick
Das verwendete Expertensystem bietet eine Reihe von Möglichkeiten für zukünftige Arbeiten, die in dieser Arbeit nicht mehr behandelt werden konnten oder gegen
die sich bewusst entschieden wurde. Diese Möglichkeiten sollen nun im Folgenden
aufgeführt werden.
Die Trennung von Frontend und eigentlichem Expertensystem bietet, wie schon
in dieser Arbeit angesprochen, Vorteile. Ein solcher Vorteil ist die einfache Einbettung des Expertensystems in zum Beispiel einen Webservice. So wurde bereits
eine Pipeline zum Erkennen von Marktvorhersagen als Browserplugin und Webservice von der Universität Paderborn bereitgestellt.1 Auf Basis eines solchen Plugins
könnte der Anwender sich für eine bestimmte zu suchende Informationsart vom
Expertensystem eine IE-Pipeline generieren lassen, die die gerade geöffnete Webseite analysiert und dann die Ergebnisse dem Anwender präsentiert. Vor allem
das Einfügen von zusätzlichen Filtern in die IE-Pipeline bietet hier großes Potenzial hinsichtlich der Performanz der Analyse, wie bereits in der Evaluierung
gezeigt. Dadurch könnte die Laufzeit der IE-Pipeline auf ein Echtzeitniveau gesteigert werden, vorausgesetzt die Filter stehen weit vorne in der Pipeline und die
zu analysierenden Texte sind genügend klein.
In dieser Arbeit wurde sich für das Verwenden von viel Expertenwissen in der
Problemlösungskomponente des Expertensystem und damit außerhalb der Wissensbasis entschieden (vgl. Abschnitt 4.1.2). Die Ablehnung der direkten Schlussfolgerung auf dem Wissen der Ontologie zur Konstruktion einer IE-Pipeline wurde
in Abschnitt 4.1.1 vor allem damit begründet, dass dieser Vorgang zu lange dauern kann. Allerdings bietet der vollkommene Verzicht auf Domänenwissen in der
Problemlösungskomponente und der Einsatz eines allgemeinen Inferenzverfahrens,
wie die in Abschnitt 2.3.1 erwähnten Tableaureasoner, den Vorteil einer noch einfacheren Erweiter- und Anpassbarkeit des Expertensystems. Es wäre dann nicht
nötig für Erweiterungen den Quellcode selbst anpassen zu müssen. Somit könnte
zum Beispiel ein Experte direkt das Wissen, und damit die Verfahrensvorschriften
zur Konstruktion einer IE-Pipeline, in der Ontologie ändern, ohne dass er ein Softwareentwickler sein muss oder den Quellcode des Expertensystems kennt. Hierzu
ist es allerdings notwendig, eine Formalisierung für das in der Problemlösungskomponente implizit verwendete Expertenwissen, zum Beispiel die Paradigmen
zur Konstruktion einer effizienten IE-Pipeline, zu finden.
1
http://infexba.uni-paderborn.de/ergebnisse.html#c31991
130
In Abschnitt 4.1.2 wurde dargelegt, warum kein externer PDDL-Planer für das
Durchführen der Planung genutzt wurde. Dies lag vor allem in den mangelnden
Möglichkeiten hinsichtlich der Zielfunktionen, auf die hin der Planer den Plan
optimieren soll. Zukünftige PDDL-Versionen und PDDL-Planer könnten die Umsetzung des in dieser Arbeit vorgestellten Ansatzes mit einem PDDL-Planer dennoch möglich werden lassen. Eine Anbindung an externe PDDL-Planer, wie zum
Beispiel den schon angesprochenen Metric-FF, ist dazu schon experimentell im
Expertensystem implementiert worden.
Ein grundlegendes Problem bei der Entwicklung des Expertensystems war die
nicht vollständig nach dem Maximum Decomposition zerlegte Algorithmenmenge.
Um diesem Problem zu begegnen wurden spezielle Optimierungen eingeführt, wie
die Eliminierung dominierter Algorithmen. Die Evaluierung zeigte, dass diese Optimierungen für die verwendete Menge an Algorithmen ausgereicht haben. Allerdings lässt sich diese Aussage nicht verallgemeinern. Andere Algorithmenmengen,
und vor allem auch andere IE-Frameworks, können andere Arten der Optimierung benötigen. Eventuell ist es sogar notwendig, das verwendete Verfahren zur
Bestimmung eines besten Algorithmus in einem Planungsschritt anzupassen oder
zu ersetzen. Genau für solche Fälle wurde das Verfahren in einer eigenen Komponente gekapselt und damit einfach anpassbar und austauschbar gemacht. Das
Testen mit anderen UIMA-Typenhierarchien und -Algorithmen ist demnach eine
weitere Möglichkeit für zukünftige Arbeiten.
Bei der in dieser Arbeit verfolgten topologische Sortierung des vom Planer gelieferten partiellen Teilplans aufgrund der Effizienzwerte der Filterverfahren kann
es sein, dass nicht immer die effizientesten Pipelines in Bezug auf das Paradigma
Optimized Scheduling erzeugt werden (vgl. Abschnitt 4.1.4). Durch die Integration der dynamischen Filterraten, etwa als neues, eigenständiges Gütekriterium der
Algorithmen, dessen Werte vor der Konstruktion der IE-Pipeline anhand der zu
untersuchenden Texte bestimmt werden, kann das Paradigma in Zukunft vollkommen berücksichtigt werden. Hierfür ist es bereits vorgesehen, dass der Benutzer
das Gütekriterium auswählen kann, anhand dessen die topologische Sortierung
durchgeführt wird. Eine weitere Möglichkeit kann die Generierung aller für ein
Problem möglichen IE-Pipelines, im Bezug auf die unterschiedlichen möglichen
topologischen Sortierungen, sein. Dies könnte es dem IE-Experten ermöglichen,
die davon effizienteste manuell zu identifizieren. Hierfür ist schon eine Funktion
im Expertensystem vorgesehen, die die Generierung von verschiedenen, möglichen
IE-Pipelines ohne deren Ausführung ermöglicht.
Des Weiteren könnte es sein, dass bestimmte Annotationen schon an den zu
analysierenden Texten vorliegen, weil sie etwa per Hand annotiert wurden. Dann
muss der Planer nur noch für die restlichen, benötigten Annotationen eine Pipeline berechnen. Dies ist indirekt schon vorgesehen vom Expertensystem. Der Planer
erhält für das Planen eine Menge von schon existierenden Annotationen. Momentan ist dies immer nur Plaintext. Der Startaktion wird diese Annotation als in den
Effekten vorliegend hinzugefügt. Damit werden alle Algorithmen, die ohne bereits
vorhandene Annotationen auf Text arbeiten können, korrekt vom Planer behan-
131
8. Zusammenfassung und Ausblick
delt. Die Implementierung müsste also so angepasst werden, dass bereits im Text
vorhandenen Annotationen in die Menge der schon existierenden Annotationen
für den Planer hinzugefügt werden.
Die in Abschnitt 3.2 gefundenen Arbeiten zeigen, dass die Benutzung einer
Anfragesprache, wie etwa einer SQL-ähnlichen Sprache, zur Formulierung von
IE-Aufgaben immer mehr Beachtung findet. Für eine vollständige Implementierung einer solchen Anfragesprache müssten die Algorithmen neu entwickelt werden. Allerdings könnten die in einer solchen Sprache formulierten Anfragen in ein
vom Expertensystem verarbeitbare Problembeschreibung umgeformt werden. Die
Trennung von Frontend und Expertensystem macht dies möglich. Dabei bleibt zu
prüfen, ob die Formulierung in einer Anfragesprache wirkliche Vorteile gegenüber
der existierenden Formular-basierten Art der Problembeschreibung hat.
Eine denkbare Erweiterung betrifft die zu wählenden Priorisierungen nicht für
die gesamte IE-Pipeline vorzuschreiben, sondern für einzelne Annotationstypen.
So könnte der Benutzer festlegen, dass für das Zerlegen des Textes in Tokens
ein möglichst effektiver Tokenisierer benutzt wird, für den Rest der Pipeline aber
möglichst effiziente Verfahren gewählt werden. Ein Tokenisierer wird typischerweise relativ früh in der IE-Pipeline ausgeführt (vgl. [WSE11]). Viele andere Algorithmen der IE-Pipeline bauen auf seinen Ergebnissen auf. Eine Verschlechterung
dieser Ergebnisse zieht also eine Verschlechterung der Effektivität der gesamten
IE-Pipeline nach sich, daher sollte ein möglichst effektiver Tokenisierer gewählt
werden. Die Priorisierungen müssten nicht komplett spezifiziert werden. Es reicht,
für die Gesamtpipeline eine Priorisierung festzulegen und für einzelne Annotationstypen eine andere. Die Gesamtpriorisierung wird immer dann genutzt, wenn für
ein vom Planer zu erreichendes Teilziel, dies entspricht einem bestimmten Annotationstyp, keine Einzelpriorisierung festgelegt wurde. Dafür müssten aber auch die
zu bewältigenden Probleme identifiziert und gelöst werden. So kann der Benutzer
im Allgemeinen nicht im Vorfeld wissen, welche Annotationstypen und Algorithmen innerhalb der zu konstruierenden Pipeline vorkommen werden. Würde er die
Pipeline selbst konstruieren, so wüsste er dies natürlich, allerdings ist der Vorteil
der Automatisierung der Konstruktion durch das Expertensystem dann verloren.
Ein Punkt, den diese Arbeit ebenfalls offen gelassen hat, ist der Einbezug von
zusätzlichem Wissen über die verwendeten Gütekriterien. Als Beispiel betrachtet
der Planer für ein Teilziel zwei in Frage kommende Aktionen. Die erste Aktion
hat als Effektivitätswert einen F-Measure von 0, 8. Die zweite Aktion hat einen
Recall von 0, 5. Soll jetzt in der Priorisierung zuerst der Recall berücksichtigt werden, dann würde die zweite Aktion gewählt. Allerdings bedeutet ein F-MeasureWert von 0, 8, dass der Recall hier auf jeden Fall über 0, 5 liegen muss. Dies
ergibt sich aus der Formel mit der sich der F-Measure berechnet (vgl. Abschnitt
2.4.3). Mit dieser Information sollte das Expertensystem daher die erste Aktion
auswählen, denn ihr Recall-Wert ist höher. Das Problem ist, dass die Gütekriterien unabhängig voneinander in der Ontologie stehen. Für die Berücksichtigung
solcher Verflechtungen, sollen sie nicht direkt im Quellcode stehen, muss die Ontologie und auch das Expertensystem selbst dahingehend erweitert werden.
132
Anhang A
Tabellen
135
A. Tabellen
OWL
DL
Beispiel
intersectionOf
unionOf
complementOf
oneOf
allValuesFrom
someValuesFrom
hasValue
minCardinality
maxCardinality
inverseOf
C1 u ... u Cn
C1 t ... t Cn
¬C
{x1 , ..., xn }
∀P.C
∃r.C
∃r.{x}
(≥ nr)
(≤ nr)
r−
Computer u Mobilgerät
PC t Mobilgerät
¬ Mobilgerät
{ Microsoft, Apple }
∀ istPartnerVon.Firma
∃ istPartnerVon.Firma
∃ hatEAGerät.{IPad}
(≥ 2 hatProzessor)
(≤ 1 hatEAGerät)
istTragbar−
Tabelle A.1: OWL-Konstruktoren in Beschreibungslogik (DL) [BHS07]
OWL Axiom
DL
Beispiel
subClassOf
equivalentClass
subPropertyOf
equivalentProperty
disjointWith
sameAs
differentFrom
TransitiveProperty
FunctionalProperty
InverseFunctionalProperty
SymmetricProperty
C1 v C2
C1 ≡ C2
P1 v P2
P1 ≡ P2
C1 v ¬C2
x1 ≡ x2
x1 v ¬x2
P1+ v P2
> v (≤ 1P )
> v (≤ 1P − )
P ≡ P−
PC v Computer
Mobiltelefon ≡ Mobilgerät u Telefon
hatTastatur v hatEAGerät
hatProzessor ≡ hatCPU
Mensch v ¬ Computer
Motorolo68000 ≡ M68k
M68k v ¬ Pentium4
istNachfolgerVon+ v istNachfolgerVon
> v (≤ 1hatProzessor)
> v (≤ 1istProzessorVon− )
istPartnerVon ≡ istPartnerVon−
Tabelle A.2: OWL-Axiome in Beschreibungslogik (DL) [BHS07]
136
Algorithmus
Eingabe
Ausgabe
Güte
TimeExpression,
Token(lemma, pos), Filtered
Declaration, Forecast
ASRT 0, 29
AvgF 0, 49
Acc
0, 93
StanfordOrganizationNER
Token(lemma; chunk; pos),
Sentence
Organization
ASRT 2, 52
AvgF 3, 94
F1
0, 78
Tokenizer
Sentence
Token
ASRT 0, 60
AvgF 1, 00
Acc
0, 98
SentenceSplitter
PlainText
Sentence, Filtered
ASRT 0, 47
AvgF 0, 77
Acc
0, 95
MarketNER
Token, Sentence
Market
ASRT 0, 09
AvgF 0, 14
R
0, 32
ForecastClassifieDecr
TimeExpression, Filtered,
Token(lemma; pos)
Declaration
ASRT 0, 29
AvgF 0, 49
Acc
0, 93
StanfordPersonNER
Sentence
Person
ASRT 2, 52
AvgF 3, 94
F1
0, 78
TimeRecognizer
Token, Sentence
TimeExpression
ASRT
AvgF
F1
R
P
MTBestDepedencyParser
Sentence,
pos)
Token(dependency; parent)
ASRT 166, 14
AvgF 276, 90
LAS
0, 88
ForecastClassifier
Filtered, TimeExpression,
Token(lemma; pos)
Forecast
ASRT 0, 29
AvgF 0, 49
Acc
0, 93
TTPOSLemmatizer
Token
Token(lemma; pos)
ASRT 0, 30
AvgF 0, 49
Acc
0, 97
StanfordMiscNER
Sentence
Misc
ASRT 2, 52
AvgF 3, 94
F1
0, 78
StatementOnRevenueIdentifier
Token, Sentence, TimeExpression, MonetaryExpression
RevenueStatement
ASRT
AvgF
F1
R
P
OrgnaizationNER
Sentence, Token
Organization
ASRT 0, 08
AvgF 0, 13
R
0, 42
ForecastClassifierAll
Token(lemma;
0, 36
0, 59
0, 94
0, 97
0, 91
3, 95
6, 37
0, 90
0, 93
0, 87
Tabelle A.3: Die vom Expertensystem verwendeten IE- und NLP-Algorithmen. In der
Spalte Güte sind Gütekriterium und Wert der Güte zusammengefasst dargestellt. ASRT = Average Sentence Response Time; Acc = Accuracy; AvgF
= Averaged Efficiency; F1 = F-Measure; R = Recall; P = Precision; LAS
= Labeled Attachement Score. TTX = TreeTagger-, MTX = MateTools-,
StanfordX NER = StanfordNER-Algorithmen
137
A. Tabellen
Algorithmus
Eingabe
Ausgabe
Güte
MTLemmatizer
Sentence, Token
Token(lemma)
ASRT 11, 12
AvgF 17, 94
Acc
0, 98
StanfordLocationNER
Sentence,
chunk; pos)
Location
ASRT 2, 52
AvgF 3, 94
F1
0, 78
MoneyRecognizer
Token, Sentence
MonetaryExpression(types)
ASRT
AvgF
F1
R
P
ScopeFinder
Sentence,
RevenueStatement,
Token(lemma),
Organization
Sentence
RevenueStatement(scope),
Scope(lemma)
ASRT 0, 03
AvgF 0, 05
Organization
ASRT 2, 52
AvgF 3, 94
F1
0, 78
Matter,Token,
RevenueStatement, Sentence
RevenueStatement(matter)
ASRT 0, 03
AvgF 0, 05
StatementOnRevenueIdentifierRB Token, Sentence
RevenueStatement
ASRT
AvgF
F1
R
P
StatementTimeFinder
Token, RevenueStatement,
TimeExpression
ReferencePoint,
RevenueStatement(referencePoint)
ASRT 0, 39
AvgF 0, 67
TTChunker
Token
Token(lemma; chunk; pos)
ASRT 0, 59
AvgF 0, 92
Acc
0, 97
MTPOSTagger
Token(lemma), Sentence
Token(pos)
ASRT 10, 75
AvgF 17, 34
Acc
0, 98
TimeMoneyRERB
Token(dependency; lemma;
parent; pos), MonetaryExpression, TimeExpression,
Filtered, Sentence
FinancialStatement(timeExpression;
monetaryExpression)
ASRT
AvgF
F1
R
P
StatementAuthorFinder
Sentence, Person, RevenueStatement, Token
Author,
RevenueStatement(author)
ASRT 0, 04
AvgF 0, 07
TimeResolver
Sentence, TimeExpression,
Filtered
TimeExpression(normalizedStart; normalizedEnd)
ASRT 2, 15
AvgF 3, 64
Acc
0, 95
LanguageFunctionAnalyzer
TimeExpression,
Token(pos), MonetaryExpression(types), Sentence
Genre(genreClass)
ASRT 3, 70
AvgF 6, 00
Acc
0, 82
WhitespaceTokenizer
PlainText
Sentence, Token, Filtered
ASRT 0, 04
AvgF 1, 00
StanfordMatterNER
SubjectFinder
Token(lemma;
0, 64
1, 09
0, 97
0, 95
0, 99
0, 03
0, 05
0, 89
0, 93
0, 86
0, 02
0, 03
0, 77
0, 88
0, 69
138
Algorithmus
Eingabe
Ausgabe
Güte
MTFastDepedencyParser
Token(lemma;
tence
Token(dependency; parent)
ASRT 54, 61
AvgF 91, 02
LAS
0, 87
StanfordNER
Sentence
Misc, Person, Location, Organization
ASRT 2, 52
AvgF 3, 94
F1
0, 78
TimeMoneyRE
MonetaryExpression,
Token(dependency;
lemma;
parent;
pos),
Filtered,
TimeExpression, Sentence
FinancialStatement(timeExpression;
monetaryExpression)
ASRT
AvgF
F1
R
P
MTMorphologicalTagger
Sentence, Token(lemma)
Token(morph)
ASRT 67, 16
AvgF 88, 37
pos),
Sen-
10, 41
13, 34
0, 81
0, 88
0, 75
139
Anhang B
Abbildungen
141
B. Abbildungen
Genre
-isRelevant : Boolean
Relevance
Category
-genreClass : String
Opinion
-polarity : String
Location
Author
Market
Matter
Person
Scope
Guid
-uri : String
Annotation
-begin : String
-end : String
Trend
ReferencePoint
MonetaryExpression
-normalizedStart : String -types : Boolean
-normalizedEnd : String
TimeExpression
-lemma : String
Entity
Misc
Organization
Filtered
Relation
FinancialStatement
Metadata
-genre : Genre
-timeExpression : TimeExpression
-monetaryExpression : MonetaryExpression
RevenueStatement
Forecast
-author : Author
-matter : Matter
-referencePoint : ReferencePoint
-trend : Trend
-scope : Scope
Declaration
Sentence
Token
-pos : String
-lemma : String
-chunk : String
-parent : Token
-dependency : String
-morph : String
Abbildung B.1: Im Expertensystem benutzte Annotationstypenhierarchie als Klassendiagramm. Jede Klasse steht für einen Annotationstyp. Jedes Attribut des Annotationstypen ist ein Attribut der jeweiligen Klasse. Dabei sind auch immer die
Typen der Attribute benannt. String und Boolean sind in UIMA eingebaute primitive Typen, die keine eigenständigen
Annotationstypen darstellen. Die Vererbung gibt die Hierarchie an, wobei Annotation der Basistyp für alle anderen
ist.
142
Abbildung B.2: Bildschirmoberfläche der Interviewerkomponente (1). Ganz oben befindet sich das Eingabefeld für das Verzeichnis, indem sich die zu untersuchenden Texte befinden (zusätzlich eine Kontrollbox, bei dessen Aktivierung nur die IE-Pipelines berechnet werden, ohne sie auszuführen).
Als Zweites ist eine alphabetisch sortierte Liste mit den zur Verfügung
stehenden Prioritätsreihenfolgen zu sehen, von denen eine ausgewählt
werden muss. An dritter Stellte befindet sich die Auswahl des Gütekriteriums, das für die topologische Sortierung der Filterverfahren des
Abhängigkeitsgraphen genutzt wird. Als Letztes kann in einem Eingabefeld der Name der resultierenden Pipeline eingegeben werden. Dieser
wird auch für die Serialisierung der XML-Deskriptoren benutzt.
143
B. Abbildungen
Abbildung B.3: Bildschirmoberfläche der Interviewerkomponente (2). Als Erstes ist eine Liste von Annotationstypen, die als mögliche Ziele der IE-Pipeline
ausgewählt werden können, zu sehen. Nach der Auswahl eines Annotationstyps können einzelne seiner Attribute mithilfe der dargestellten Kontrollboxen als Ziele ausgewählt werden. In der nächsten Liste können
der zu konstruierenden IE-Pipeline Filter hinzugefügt werden. Hierzu
ist der zu filternde Annotationstyp auszuwählen. Hat dieser Attribute
werden sie in einer zweiten Liste angezeigt und es lässt sich hier ein
zu filterndes Attribut auswählen. Dann kann der Filtertyp aus einer
Liste ausgewählt werden. Für jeden Filter lassen sich dann noch seine
Filtereigenschaften festlegen (zum Beispiel der reguläre Ausdruck eines Textfilters). Der Button Start XPS startet die Konstruktion und
Ausführung der IE-Pipeline mit den gemachten Eingaben. Der Button
Import new ontology information öffnet einen Dialog zum Importieren
des UIMA-Type System-Deskriptors und der UIMA-Analysis EngineDeskriptoren.
144
Abbildung B.4: Bildschirmoberfläche der Erklärungskomponente. Dieses Fenster wird
beim Start des Expertensystems geöffnet und zeigt das Arbeitsprotokoll
seit dem Programmstart des Expertensystems.
145
B. Abbildungen
Abbildung B.5: Bildschirmoberfläche der gefundenen Ergebnisse. Dieses Fenster wird
geöffnet, wenn das Expertensystem eine IE-Pipeline berechnen soll.
Nach der Berechnung wird die IE-Pipeline ausgeführt und die Ergebnisse werden in einer Listenstruktur in diesem Fenster angezeigt.
146
Anhang C
UML-Diagramme
147
C. UML-Diagramme
package Data[
Datamodel Type ]
«Singleton»
TypeHelper
*
*
Type
+clone()
...
-String uri
-String name
-String typeClass
subTypes
de.upb.mrose.xps.datamodel
type
provides
provides
TextType
0..1
*
*
annotationBaseType
activeFeature
allFeature
superType
OntologyMember
-String coveredText
-Map<Feature - String> featureText
de.upb.mrose.xps.knowledgebase
+TypeHelper getInstance()
+void reset()
+void setOntology( Ontology anOntology )
+Type getType( String typeUri )
+String getPathToTypeSystem()
+Feature getSuitableFeature( String featureName )
+boolean isSubTypeOf( Type possibleSubType, Type possibleSuperType )
+boolean isSuperTypeOf( Type possibleSuperType, Type possibleSubType )
+boolean hasFeatureConsiderSuperTypes( Type type, Feature feature )
+List<Type> getAllSubTypes( Type type )
+Type getHighestSuperTypeWithFeature( Type type, Feature feature )
+List<Type> getAllSuperTypeWithFeature( Type type, Feature feature )
+Set<Type> getAllTypes()
+Set<Type> getAllTypesWithAllPossibleFeatures()
+Collection<Feature> getAllFeaturesOfSuperTypes( Type type )
+boolean hasNoFeaturesConsiderBlackList( Type type, Collection<Feature> blackList )
Ontology
JenaOntology
Feature
-String uri
-String name
*
Abbildung C.1: Klassendiagramm des Datenmodells für das Package type. Die Klasse Type steht, wie in Abschnitt 6.1.2 beschrieben,
für einen bestimmten Annotationstyp aus der Ontologie. Er hat vor allem ein Attribut typeClass, welches die JavaKlasse angibt, die von UIMA für diesen Annotationstyp verwendet wird. Des Weiteren kann jeder Type einen Supertyp
haben und eine Reihe von Subtypen. Attribute eines Annotationstyps werden mit der Klasse Feature beschrieben.
Sie haben ihrerseits einen Basisannotationstyp. Ein Type hat eine Menge an möglichen Features und eine Menge von
aktiven Features. Hierdurch ist es möglich Types für Ein- und Ausgaben der Algorithmen zu nutzen. Ein TextType
ist ein spezieller Type, der für eine bestimmte Annotation eines Types steht. Hiermit kann der Text der Annotation
und der Text jedes einzelnen Features ausgedrückt werden. Type und Feature haben ein entsprechendes Element in
der Ontologie und sind daher OntologyMember. Der TypeHelper extrahiert alle möglichen Types und Features aus der
Ontologie und stellt sie dem Rest des Expertensystems zur Verfügung. Außerdem stellt er Helfermethoden bereit, um
zum Beispiel zu prüfen, ob ein Feature zu einem Type oder einem seiner Supertypen gehört.
148
149
Algorithm
Datamodel Algorithm]
Pipeline
JenaOntology
Ontology
provides
-String name
...
+AlgorithmHelper getInstance()
+void reset()
«Singleton»
AlgorithmHelper
Abbildung C.2: Klassendiagramm des Datenmodells für das Package algorithm. Die Klasse Algorithm steht, wie in Abschnitt 6.1.2
beschrieben, für einen bestimmten Algorithmus aus der Ontologie. Sie hat vor allem als Attribute die Listen der
Eingabe- und Ausgabeannotationstypen (input und output) und die Werte der Gütekriterien (qualityCriteriaValues).
Außerdem enthält sie den Pfad zur entsprechenden Datei des UIMA Analysis Engine Descriptor (pathToAlgorithm).
Eine Pipeline besteht aus einer geordneten Menge von Algorithmen. Die Helferklasse AlgorithmHelper extrahiert alle
möglichen Algorithmen aus der Ontologie und stellt sie als Algorithm-Objekte dem restlichen Expertensystem zur
Verfügung.
OntologyMember
algorithm
-String uri
1..*
-String name
-String pathToAlgorithm
-Map<QualityCriterion - QualityCriterionValue> qualityCriteriaValues
-List<Type> input
*
-List<Type> output
-boolean isFilterProcedure
package Data[
C. UML-Diagramme
package Data[
Datamodel QualityCriterion]
«Singleton»
QualityCriterionHelper
...
QualityCriterion
qualitycriterion
-String kind
-String metricName
-boolean isAccumulative
*
java.util.Comparator
«ordered»
baseOrder
+int compare( QualityCriterionValue arg0, QualityCriterionValue arg1 )
+int compare( Algorithm arg0, Algorithm arg1 )
*
QualityCriterionValueComputer
SimpleDoubleComputer
+QualityCriterionValue sum( QualityCriterionValue v1, QualityCriterionValue v2 )
+QualityCriterionValue sub( QualityCriterionValue v1, QualityCriterionValue v2 )
+QualityCriterionValue add( QualityCriterionValue v1, QualityCriterionValue v2 )
provides
provides
+QualityCriterionHelper getInstance()
provides
+void reset()
*
provides
*
QualityCriterionValue
+double toDouble()
+QualityCriterionValue getZeroValue()
+QualityCriterionValue clone()
NumericQualityCriterionValue
-double value
OntologyMember
Ontology
JenaOntology
has
*
«enumeration»
ComparsionFactor
BiggerIsBetter
SmallerIsBetter
*
QualityCriteriaOrder
implies
Abbildung C.3: Klassendiagramm des Datenmodells für das Package qualityCriterion. Die Klasse QualityCriterion steht, wie in Abschnitt 6.1.2 beschrieben, für ein bestimmtes Gütekriterium aus der Ontologie. Sie hat als Ordnung einen ComparsionFactor, der aus einer Enumeration gewählt wird, entsprechend den in der Ontologie hinterlegten Informationen.
Durch die Implementierung der Schnittstelle Comparator kann ein QualityCriterion zwei Algorithmen vergleichen.
Hierzu werden die entsprechenden Werte des Gütekriteriums für jeden Algorithmus bestimmt und dann entsprechend des eingestellten ComparsionFactor verglichen. Dabei werden die Fließkommawerte der mit QualityCriterionValue bezeichneten Werte betrachtet. Hierzu hat jedes QualityCriterionValue-Objekt eine toDouble()-Methode. Im
Expertensystem wird das NumericQualityCriterionValue benutzt, welches einen numerischen Wert darstellt. Zum
Verrechnen der QualityCriterionValue-Objekte existiert die Schnittstelle QualityCriterionValueComputer mit der Implementierung SimpleDoubleComputer für Fließkommazahlen. Mit QualityCriteriaOrder werden die Priorisierungen
aus der Ontologie abgebildet. Dazu besteht jede dieser Priorisierungen aus eine geordneten Menge von QualityCriterion Objekten sowie eine Menge von impliziten QualityCriteriaOrder Objekten. Die Helferklasse QualityCriterionHelper
extrahiert die Informationen aus der Ontologie und stellt alle vom Expertensystem benötigten Objekte bereit.
150
151
Filter
Datamodel Filter]
NumberFilter
StandardFilter
OntologyMember
JenaOntology
Ontology
StandardNumberFilter
StandardTextFilter
+void setRegexToMatch( String regexToMatch )
+String getRegexToMatch()
TextFilter
«Singleton»
FilterInformation
FilterHelper
-String uri
provides
-String filterImplementationClass
+FilterHelper getInstance()
*
-String filterName
+void reset()
-Map<String - String> filterPropertyNameToDatatype
...
-Map<String - Object> filterPropertyNameToValue
+void setLowerValueConstraint( Double valueConstraintLow )
+void setUpperValueConstraint( Double valueConstraintHigh )
+Double getLowerValueConstraint()
+Double getUpperValueConstraint()
creates
filter
Abbildung C.4: Klassendiagramm des Datenmodells für das Package filter. Ein Filter hat einen Annotationstyp, den er filtern soll, und
eine Methode filter zum Filtern. Die drei Schnittstellen DateFilter, NumberFilter, TextFilter sowie die dazugehörigen
Standardimplementierungen StandardDataFilter, -NumberFilter und -TextFilter wurden in Abschnitt 5.4.2 vorgestellt.
Die abstrakte Basisklasse StandardFilter implementiert für alle Implementierungen notwendige Basisfunktionalitäten,
wie das Setzen des zu filternden Annotationstyps. Objekte der Klasse FilterInformation enthalten die Informationen
über einen Filter, erstellt mit Informationen der Ontologie und konkreter Werte für die Eigenschaften des Filters
durch die Eingaben aus der grafischen Benutzeroberfläche. Aus diesen Informationen kann ein FilterInformationObjekt mittels der Java-Reflection API einen Filter instantiieren und konfigurieren. Die Helferklasse FilterHelper
extrahiert aus der Ontologie die Filterinformationen und stellt sie dem Rest des Expertensystems zur Verfügung.
StandardDateFilter
+void setFrom( String from )
+String getFrom()
+void setTo( String to )
+String getTo()
+void setFormat( String format )
+String getFormat()
DateFilter
+Object filter( Object input )
+Type getTypeToFilter()
+setTypeToFilter( Type typeToFilter )
+String getName()
package Data[
C. UML-Diagramme
package Data[
KnowledgeBase ]
OntologyTypeSystem
OntologyMember
Ontology
-List<String> typeSystemOntologyElements
+String getUri()
JenaOntology
OntologyAlgorithm
-List<String>algorithmOntologyElements
Abbildung C.5: Klassendiagramm der Wissensbasis. Die Schnittstelle Ontology und die
Implementierung JenaOntology wurden bereits in Abschnitt 6.1.1 vorgestellt. Die beiden abstrakten Klassen OntologyTypeSystem und OntologyAlgorithm enthalten die Referenzen auf die URIs der einzelnen
Elemente der Ontologie. Ein OntologyMember hat einen Entsprechung
in der Ontologie und dementsprechend einen URI.
152
package Data[
OntologyImporter ]
de.upb.mrose.xps.knowledgeimport
ImportJob
OntologyImporter
-File instancesFile
-Model baseModel
+Ontology importInstances( ImportJob importJob )
UimaImportJob
needs
uima
UimaOntologyImporter
buildsUp
-File typeSystemDeskriptor
-File analysisEngineDirectory
AnalysisEngineImporter
TypeSystemImporter
Ontology
JenaOntology
Abbildung C.6: Klassendiagramm der OntologyImporter -Komponente. Die Implementierung UimaOntologyImporter besteht aus zwei Teilen. Der AnalysisEngineImporter importiert die Informationen aus den Deskriptoren der
Analysis Engines. Der TypeSystemImporter importiert die Informationen aus dem Deskriptor des Type System. Damit diese Importer arbeiten können, wird ein UimaImportJob benötigt. In diesem sind die
Verweise auf die jeweiligen Deskriptoren gespeichert.
153
C. UML-Diagramme
package Data[
Plan
ProblemSolver ]
produces
ProblemSolver
UimaNumberFilter
for goal normalizing
GoalNormalizer
uima
UimaTextFilter
for pipeline execution
PipelineExecutor
UimaAggragateEngineExecutor
to transform filter to UimaFilter UimaPipelineConstructor
to create UIMA descriptor files
UimaGoalNormalizer
UimaDateFilter
UimaFilter
*
creates
UimaFilterFactory
DominatedAlgorithmEliminator
PipelineOptimizer
for pipeline optimization
de.upb.mrose.xps.problemsolver
DefaultAlgorithmSelector
AlgorithmSelector
algorithmselector
to select best algorithm for given goal
for pipeline computation
PlannerProblemSolver
planner
+List<TextType> solveProblem( Problem problem )
Planner
pop
SpecializedTopSort
...
SpecializedPartialOrderPlanner
PartialOrderPlanner
produces
+getOrderedAlgorithms()
PartialPlan
to linearize DAG
linearization
uses
Linearization
StandardTopologicalSort
Abbildung C.7: Klassendiagramm der ProblemSolver -Komponente. Die Beziehungen zwischen den einzelnen Komponenten wurden
bereits in Abschnitt 6.1.3 vorgestellt. Eine Besonderheit stellt der Partial Plan dar. Er ist eine Spezialisierung der
Plan-Klasse. Die topologische Sortierung des intern gehaltenen DAG ist ein Teil von ihm. Sie wird immer dann durchgeführt, wenn die Methode getOrderedAlgorithms aufgerufen wird. Die SpecializedTopSort genannte Implementierung
der Linearization benötigt selbst eine Standard-topologische Sortierung, welche in StandardTopologicalSort implementiert ist. Für die Erstellung der UIMA-Pipeline braucht die Klasse UimaAggregateEngineExecutor die Hilfe einer
Instanz von UimaPipelineConstructor. Mit ihrer Hilfe werden die Deskriptoren dynamisch erzeugt (siehe Abschnitt
5.4.2). Für die Umwandlung eines Filters in einen UimaFilter wird das Singleton UimaFilterFactory benutzt.
154
155
ProblemSolver ]
12: textTypes
1: calculateResults(Problem problem)
: DominatedAlgorithmEliminator
10: textTypes
9: executePipeline(optimizedPipeline, problem.filter, problem.goals, inputTexts)
8: optimizedPipeline
7: optimizePipeline(pipelineForPartialPlan, qualityCriteriaOrder)
6: partialPlan
5: buildPlan(allAlgorithms, normalizedGoals, problem.qualityCriteriaOrder)
4: normalizedGoals
: SpecializedPartialOrderPlanner
Abbildung C.8: Sequenzdiagramm mit Beispielablauf in der Problemlösungskomponente
11: textTypes
: UimaGoalNormalizer
3: normalizeGoals(problem.goals)
: PlannerProblemSolver
2: solveProblem(Problem problem)
: ExpertSystemWithPlanner
interaction ProblemSolver[
: UimaAggragateEngineExecutor
Anhang D
Inhalte der beigefügten DVD
Auf der dieser Arbeit beigefügten DVD befindet sich sowohl die Implementierung
des fertigen Expertensystems, als auch diese Arbeit in digitaler Form im PDFFormat. Folgende Inhalte sind auf der DVD zu finden:
• /MRoseMA.pdf ist die digitale Version der vorliegenden Arbeit.
• /Implementierung/ExpertSystemUsage.txt bietet eine Anleitung zum
Starten und Verwenden des implementierten Expertensystems.
• /Implementierung/EfXTools/ enthält die vom Expertensystem verwendeten UIMA-Algorithmen (/src/ ) sowie deren Deskriptoren (/desc/ ), das
Typensystem (/desc/uimaTypeSystem.xml ) und die für die Evaluierung verwendete Textmenge (/data/RevenueCorpus/xmi/test/ ).
• /Implementierung/XPS/ enthält die gesamte Implementierung des Expertensystems.
• /Implementierung/XPS/src/ enthält den Quellcode des Expertensystems.
• /Implementierung/XPS/model/ enthält die Ontologie. Die Grundontologie ist zur einfacheren Wartung in die beiden Teile typeSystem.owl und
algorithm.owl aufgeteilt. Beide Ontologien enthalten noch keine Informationen über konkrete Algorithmen und Annotationstypen. Diese Informationen
werden von den beiden Importern der Ontologie hinzugefügt. Die endgültige
Ontologie mit allen Algorithmen und Annotationstypen ist in populatedOntology.owl zu finden. Diese Ontologie wird auch automatisch beim Start des
Expertensystems benutzt.
157
Literatur
[Agi05]
Agichtein, Eugene: Scaling Information Extraction to Large Document Collections. In: IEEE Data Engineering Bulletin, 2005
[AH03]
Antoniou, Grigoris; Harmelen, Frank V.: Web Ontology Language: OWL. In: Handbook on Ontologies in Information Systems,
Springer, 2003, S. 67–92
[BBHN10]
Björkelund, Anders; Bohnet, Bernd; Hafdell, Love; Nugues,
Pierre: A high-performance syntactic and semantic dependency parser. In: Proceedings of the 23rd International Conference on Computational Linguistics: Demonstrations. Stroudsburg, PA, USA : Association for Computational Linguistics, 2010 (COLING ’10), S. 33–36
[BCS+ 07]
Banko, Michele; Cafarella, Michael J.; Soderl, Stephen;
Broadhead, Matt; Etzioni, Oren: Open information extraction
from the web. In: In IJCAI, 2007, S. 2670–2676
[BDGRL09] Bobillo, Fernando; Delgado, Miguel; Gómez-Romero, Juan;
López, Enrique: A semantic fuzzy expert system for a fuzzy balanced scorecard. In: Expert Syst. Appl. 36 (2009), Januar, Nr. 1, S.
423–433. – ISSN 0957–4174
[BFL+ 07]
Bouillet, Eric; Feblowitz, Mark; Liu, Zhen; Ranganathan,
Anand; Riabov, Anton: A Knowledge Engineering and Planning
Framework based on OWL Ontologies. In: Proceedings of the Second
International Competition on Knowledge Engineering., 2007
[BG94]
Buckland, Michael; Gey, Fredric: The relationship between recall
and precision. In: J. Am. Soc. Inf. Sci. 45 (1994), Januar, Nr. 1, S.
12–19. – ISSN 0002–8231
[BHL01]
Berners-Lee, Tim; Hendler, James; Lassila, Ora: The Semantic Web. In: Scientific American 284 (2001), Nr. 5, S. 34–43
[BHS07]
Baader, Franz; Horrocks, Ian; Sattler, Ulrike: Description
Logics. In: van Harmelen, Frank (Hrsg.); Lifschitz, Vladimir
(Hrsg.); Porter, Bruce (Hrsg.): Handbook of Knowledge Representation. Elsevier, 2007
159
Literatur
[BKI06]
Beierle, Christoph; Kern-Isberner, Gabriele: Methoden wissensbasierter Systeme. Grundlagen – Algorithmen – Anwendungen. 3.
Wiesbaden : Vieweg, 2006
[BLFM05]
Berners-Lee, T.; Fielding, R.; Masinter, L.: Uniform Resource
Identifier (URI): Generic Syntax, Januar 2005. – Internet RFC 3986
[BN03]
Baader, Franz; Nutt, Werner ; Baader, Franz (Hrsg.); Calvanese, Diego (Hrsg.); McGuinness, Deborah L. (Hrsg.); Nardi,
Daniele (Hrsg.); Patel-Schneider, Peter F. (Hrsg.): The description logic handbook: theory, implementation, and applications. New
York, NY, USA : Cambridge University Press, 2003. – ISBN 0–521–
78176–0
[Boh10]
Bohnet, Bernd: Very high accuracy and fast dependency parsing is
not a contradiction. In: Proceedings of the 23rd International Conference on Computational Linguistics. Stroudsburg, PA, USA : Association for Computational Linguistics, 2010 (COLING ’10), S. 89–97
[Bri08]
Briggs, Tom: Constraint Generation and Reasoning in OWL, University of Maryland, Baltimore County, Dissertation, November 2008
[BS84]
Buchanan, Bruce G.; Shortliffe, Edward H.: Rule Based Expert
Systems: The Mycin Experiments of the Stanford Heuristic Programming Project (The Addison-Wesley series in artificial intelligence).
Boston, MA, USA : Addison-Wesley Longman Publishing Co., Inc.,
1984. – ISBN 0201101726
[BS85]
Brachman, Ronald J.; Schmolze, James G.: An Overview of the
KL-ONE Knowledge Representation System. In: Cognitive Science:
A Multidisciplinary Journal 9 (1985), Nr. 2, S. 171–216
[BS00]
Baader, Franz; Sattler, Ulrike: An Overview of Tableau Algorithms for Description Logics. In: Studia Logica 69 (2000), S. 2001
[CAO+ 08]
Castillo, Luis A.; Armengol, Eva; Onaindia, Eva; Sebastiá, Laura; González-Boticario, Jesús; Rodrı́guez, Antonio;
Fernández, Susana; Arias, Juan D.; Borrajo, Daniel: samap:
An user-oriented adaptive system for planning tourist visits. In:
Expert Syst. Appl. 34 (2008), Nr. 2, S. 1318–1332
[CFoGpP06] Castillo, Luis; Fdez-olivares, Juan; Óscar Garcı́a-pérez;
Palao, Francisco: Efficiently handling temporal knowledge in an
HTN planner. In: In Sixteenth International Conference on Automated Planning and Scheduling, ICAPS, AAAI, 2006, S. 63–72
160
Literatur
[CGD+ 09]
Chen, Fei; Gao, Byron J.; Doan, AnHai; Yang, Jun; Ramakrishnan, Raghu: Optimizing complex extraction programs over evolving text data. In: Proceedings of the 35th SIGMOD international
conference on Management of data. New York, NY, USA : ACM,
2009 (SIGMOD ’09). – ISBN 978–1–60558–551–2, S. 321–334
[CGT89]
Ceri, S.; Gottlob, G.; Tanca, L.: What You Always Wanted to
Know About Datalog (And Never Dared to Ask). In: IEEE Trans.
on Knowl. and Data Eng. 1 (1989), March, S. 146–166. – ISSN
1041–4347
[CSL+ 03]
Clark, R. N.; Swayze, G. A.; Livo, K. E.; Kokaly, R. F.; Sutley, S. J.; Dalton, J. B.; McDougal, R. R.; Gent, C. A.: Imaging spectroscopy: Earth and planetary remote sensing with the USGS Tetracorder and expert systems. In: Journal of Geophysical Research 108 (2003), dec, S. 1–44
[CSRL01]
Cormen, Thomas H.; Stein, Clifford; Rivest, Ronald L.; Leiserson, Charles E.: Introduction to Algorithms. 2nd. McGraw-Hill
Higher Education, 2001. – ISBN 0070131511
[Cun05]
Cunningham, H.: Information Extraction, Automatic. In: Encyclopedia of Language and Linguistics, 2nd Edition (2005)
[Cur03]
Curran, James R.: Blueprint for a high performance NLP infrastructure. In: SEALTS ’03: Proceedings of the HLT-NAACL 2003
workshop on Software engineering and architecture of language technology systems. Morristown, NJ, USA : Association for Computational Linguistics, 2003, S. 39–44
[CVDN09]
Chai, Xiaoyong; Vuong, Ba-Quy; Doan, AnHai; Naughton,
Jeffrey F.: Efficiently incorporating user feedback into information extraction and integration programs. In: Proceedings of the 35th
SIGMOD international conference on Management of data. New
York, NY, USA : ACM, 2009 (SIGMOD ’09). – ISBN 978–1–60558–
551–2, S. 87–100
[DDM05]
Dezsényi, Csaba; Dobrowiecki, Tadeusz; Mészáros, Tamás: Information Extraction with AI Planning. In: Proceedings of 6th International Symposium of Hungarian Researchers on Computational
Intelligence, 2005
[Deb05]
Deb, Kalyanmoy: Multiobjective Optimization. In: Search Methodologies 79 (2005), Nr. 4, S. 273–316
161
Literatur
[DGHP99]
D’Agostino, Marcello (Hrsg.); Gabbay, Dov M. (Hrsg.); Hähnle,
Reiner (Hrsg.); Posegga, Joachim (Hrsg.): Handbook of Tableau
Methods. Springer, 1999. – ISBN 978–0–7923–5627–1
[Dur08]
Durcı́k, Zoltán: Automated web service composition with knowledge approach. In: Information Sciences and Technologies Bulletin
of the ACM Slovakia 2 (2008), December, Nr. 2, S. 30–38
[EBPL08]
Ekaterina Buyko, Christian C.; Pareja-Lora, Antonio:
Ontology-Based Interface Specifications for a NLP Pipeline Architecture. In: Nicoletta Calzolari (Conference Chair),
Bente Maegaard Joseph Mariani Jan Odjik Stelios Piperidis Daniel T. (Hrsg.): Proceedings of the Sixth International Conference on
Language Resources and Evaluation (LREC’08). Marrakech, Morocco : European Language Resources Association (ELRA), may
2008. – http://www.lrec-conf.org/proceedings/lrec2008/. – ISBN
2–9517408–4–0
[ES07]
Eilebrecht, Karl; Starke, Gernot: Patterns kompakt - Entwurfsmuster für effektive Software-Entwicklung (2. Aufl.). Spektrum Akademischer Verlag, 2007. – I–VI, 1–158 S. – ISBN 978–3–8274–1591–2
[FGH90]
Frühwirth, Thom; Gottlob, Georg; Horn, Werner: Expertensysteme. Springer, B., 1990. – ISBN 3211822216
[FGM05]
Finkel, Jenny R.; Grenager, Trond; Manning, Christopher: Incorporating non-local information into information extraction systems by Gibbs sampling. In: Proceedings of the 43rd Annual Meeting on Association for Computational Linguistics. Stroudsburg, PA,
USA : Association for Computational Linguistics, 2005 (ACL ’05),
S. 363–370
[FH03]
Friedman-Hill, E.: Jess in Action: Rule-Based Systems in Java.
Manning Publications Co., 2003
[FL03]
Fox, Maria; Long, Derek: PDDL2.1: An extension to PDDL for
expressing temporal planning domains. In: Journal of Artificial Intelligence Research 20 (2003), S. 2003
[FN71]
Fikes, Richard E.; Nilsson, Nils J.: Strips: A new approach to
the application of theorem proving to problem solving. In: Artificial
Intelligence 2 (1971), Nr. 3-4, S. 189–208
[FS84]
Fox, M. S.; Smith, S. F.: ISIS: a knowledge-based system for factory
scheduling. In: Expert Systems 1 (1984), Juli, Nr. 1, S. 25–49
162
Literatur
[GDDD04]
Gasevic, Dragan; Djuric, Dragan; Devedzic, Vladan; Damjanovi, Violeta: Converting UML to OWL ontologies. In: Proceedings
of the 13th international World Wide Web conference on Alternate
track papers & posters. New York, NY, USA : ACM, 2004 (WWW
Alt. ’04). – ISBN 1–58113–912–8, S. 488–489
[Gru93]
Gruber, Thomas R.: A translation approach to portable ontology
specifications. In: KNOWLEDGE ACQUISITION 5 (1993), S. 199–
220
[Hau00]
Haun, M.:
Wissensbasierte Systeme.: Eine praxisorientierte
Einführung. Expert-Verl., 2000 (Edition expertsoft). – ISBN
9783816916772
[HBT+ 07]
Hahn, Udo; Buyko, Ekaterina; Tomanek, Katrin; Piao, Scott;
McNaught, John; Tsuruoka, Yoshimasa; Ananiadou, Sophia:
An Annotation Type System for a Data-Driven NLP Pipeline. In:
Proceedings of the Linguistic Annotation Workshop, Association for
Computational Linguistics, 2007, S. 33–40
[HFM+ 05]
Hanisch, Daniel; Fundel, Katrin; Mevissen, Heinz-Theodor;
Zimmer, Ralf; Fluck, Juliane: ProMiner: rule-based protein and
gene entity recognition. In: BMC Bioinformatics 6 (2005), Nr. Suppl
1, S. S14. – ISSN 1471–2105
[HH08]
Hartanto, Ronny; Hertzberg, Joachim: Fusing DL Reasoning
with HTN Planning. In: Proceedings of the 31st annual German
conference on Advances in Artificial Intelligence. Berlin, Heidelberg
: Springer-Verlag, 2008 (KI ’08). – ISBN 978–3–540–85844–7, S.
62–69
[HHF+ 10]
Hogenboom, Frederik; Hogenboom, Alexander; Frasincar, Flavius; Kaymak, Uzay; van der Meer, Otto; Schouten, Kim;
Vandic, Damir: SPEED: A Semantics-Based Pipeline for Economic
Event Detection. In: Jeffrey Parsons (Hrsg.); Motoshi Saeki
(Hrsg.); Peretz Shoval (Hrsg.); Carson C. Woo (Hrsg.); Yair
Wand (Hrsg.): Conceptual Modeling - ER 2010, 29th International
Conference on Conceptual Modeling, Vancouver, BC, Canada, November 1-4, 2010. Proceedings Bd. 6412, Springer, 2010. – ISBN
978–3–642–16372–2, S. 452–457
[HKR08]
Hitzler, Pascal; Krötzsch, Markus; Rudolph, Sebastian: Semantic web : Grundlagen. Berlin [u.a.] : Springer, 2008. – ISBN
3–540–33993–9
163
Literatur
[HN01]
Hoffmann, Jörg; Nebel, Bernhard: The FF Planning System: Fast
Plan Generation Through Heuristic Search. In: Journal of Artificial
Intelligence Research 14 (2001), S. 253–302
[Hof03]
Hoffmann, Jörg: The Metric-FF Planning System: Translating
Ignoring Delete Lists“ to Numeric State Variables. In: Journal of
”
Artificial Intelligence Research. Special issue on the 3rd International
Planning Competition (2003)
[Hof10]
Hofweber, Thomas: Logic and Ontology. In: Zalta, Edward N.
(Hrsg.): The Stanford Encyclopedia of Philosophy. Fall 2010. 2010
[Hor08]
Horrocks, Ian: Ontologies and the Semantic Web. In: Communications of the ACM 51 (2008), Nr. 12, S. 58–67. – ISSN 0001–0782
[HPSB+ 04] Horrocks, Ian; Patel-Schneider, Peter F.; Boley, Harold; Tabet, Said; Grosof, Benjamin; Dean, Mike: SWRL: A Semantic
Web Rule Language Combining OWL and RuleML / World Wide
Web Consortium. 2004. – W3C Member Submission
[HPSH02]
Horrocks, Ian; Patel-Schneider, Peter F.; van Harmelen,
Frank: Reviewing the Design of DAML+OIL: An Ontology Language for the Semantic Web. In: IN PROC. OF THE 18TH NAT.
CONF. ON ARTIFICIAL INTELLIGENCE (AAAI 2002, AAAI
Press, 2002, S. 792–797
[JDH99]
Junker, Markus; Dengel, Andreas; Hoch, Rainer: On the Evaluation of Document Analysis Components by Recall, Precision, and
Accuracy. In: Proceedings of the Fifth International Conference on
Document Analysis and Recognition. Washington, DC, USA : IEEE
Computer Society, 1999 (ICDAR ’99). – ISBN 0–7695–0318–7, S.
713–
[JM08]
Jurafsky, Daniel; Martin, James H.: Speech and Language Processing (2nd Edition) (Prentice Hall Series in Artificial Intelligence).
2. Prentice Hall, 2008. – ISBN 0131873210
[KC04]
Klyne, Graham; Carroll, Jeremy J.: Resource Description Framework (RDF): Concepts and Abstract Syntax. In: Structure 10
(2004), Nr. February, S. 1–20
[KDM+ 10]
Kano, Y.; Dorado, R.; McCrochon, L.; Ananiadou, S.; Tsujii,
J.: U-Compare: An integrated language resource evaluation platform
including a comprehensive UIMA resource library. In: Proceedings
of the Seventh International Conference on Language Resources and
Evaluation (LREC 2010), 2010, S. 428–434
164
Literatur
[KG05]
Klusch, Matthias; Gerber, Andreas: Semantic web service composition planning with OWLS-XPlan. In: In Proceedings of the 1st
Int. AAAI Fall Symposium on Agents and the Semantic Web, 2005,
S. 55–62
[KGK93]
Kruse, R.; Gebhardt, J.; Klawonn, F.: Fuzzy-Systeme. Teubner,
1993. – ISBN 9783519021308
[KL89]
Kifer, Michael; Lausen, Georg: F-logic: a higher-order language
for reasoning about objects, inheritance, and scheme. In: Proceedings
of the 1989 ACM SIGMOD international conference on Management
of data. New York, NY, USA : ACM, 1989 (SIGMOD ’89). – ISBN
0–89791–317–5, S. 134–146
[KLR+ 09]
Krishnamurthy, Rajasekar; Li, Yunyao; Raghavan, Sriram;
Reiss, Frederick; Vaithyanathan, Shivakumar; Zhu, Huaiyu: SystemT: a system for declarative information extraction. In: SIGMOD
Rec. 37 (2009), March, S. 7–13. – ISSN 0163–5808
[KNS+ 08]
Kano, Yoshinobu; Nguyen, Ngan; Saetre, Rune; Yoshida, Kazuhiro; Miyao, Yusuke; Tsuruoka, Yoshimasa; Matsubayashi,
Yuichiro; Ananiadou, Sophia; Tsujii, Jun’ichi: Filling the Gaps
Between Tools and Users: A Tool Comparator, Using ProteinProtein Interactions as an Example. In: Proceedings of the Pacific
Symposium on Biocomputing (PSB), Pacific Symposium on Biocomputing, 2008, S. 616–627
[KPHK95]
Kim, K.H.; Park, J.K.; Hwang, K.J.; Kim, S.H.: Implementation
of hybrid short-term load forecasting system using artificial neural
networks and fuzzy expert systems. In: IEEE Transactions on Power
Systems 10 (1995), Nr. 3, S. 1534–1539
[Law08]
Lawrynowicz, A.: Integration of production planning and scheduling using an expert system and a genetic algorithm. In: Journal of
the Operational Research Society 59 (2008), Nr. 4, S. 1318–1332
[Lia05]
Liao, Shu-Hsien: Expert System Methodologies and Applications
– A Decade Review from 1995 to 2004. In: Expert Systems with
Applications 28 (2005), Nr. 1, S. 93–103
[Lie06]
Liebig, Thorsten: Reasoning with OWL – System Support and
Insights – / Ulm University. Ulm, Germany, September 2006 (
TR-2006-04). – Forschungsbericht
[LLBN09]
Luther, Marko; Liebig, Thorsten; Böhm, Sebastian; Noppens,
Olaf: Who the Heck Is the Father of Bob? In: Proceedings of the
165
Literatur
6th European Semantic Web Conference on The Semantic Web: Research and Applications. Berlin, Heidelberg : Springer-Verlag, 2009
(ESWC 2009 Heraklion). – ISBN 978–3–642–02120–6, S. 66–80
[LRR07]
Liu, Zhen; Ranganathan, Anand; Riabov, Anton: Use of OWL
for Describing Stream Processing Components to Enable Automatic
Composition. In: Christine Golbreich (Hrsg.); Aditya Kalyanpur (Hrsg.); Bijan Parsia (Hrsg.): Proceedings of the OWLED 2007 Workshop on OWL: Experiences and Directions, Innsbruck, Austria, June 6-7, 2007 Bd. 258, CEUR-WS.org, 2007
[MA04]
Marler, R. T.; Arora, J. S.: Survey of multi-objective optimization methods for engineering. In: Structural and Multidisciplinary
Optimization 26 (2004), April, Nr. 6, S. 369–395. – ISSN 1615–147X
[McB04]
McBride, Brian: The Resource Description Framework (RDF) and
its Vocabulary Description Language RDFS. In: In Handbook on
Ontologies, 2004, S. 51–66
[MGH+ 98]
Mcdermott, D.; Ghallab, M.; Howe, A.; Knoblock, C.; Ram,
A.; Veloso, M.; Weld, D.; Wilkins, D.: PDDL - The Planning
Domain Definition Language / Yale Center for Computational Vision and Control,. 1998 ( TR-98-003). – Forschungsbericht
[MH69]
McCarthy, John; Hayes, Patrick J.: Some Philosophical Problems from the Standpoint of Artificial Intelligence. In: Meltzer,
B. (Hrsg.); Michie, D. (Hrsg.): Machine Intelligence 4. Edinburgh
University Press, 1969. – reprinted in McC90, S. 463–502
[MHF03]
Mahabir, C.; Hicks, F. E.; Fayek, A. R.: Application of fuzzy logic
to forecast seasonal runoff. In: Hydrological Processes 17 (2003), Nr.
18, S. 3749–3762. – ISSN 1099–1085
[MNPW98] Muscettola, Nicola; Nayak, Pandurang P.; Pell, Barney; Williams, Brian C.: Remote Agent: To Boldly Go Where No AI System
Has Gone Before. In: Artificial Intelligence 103 (1998), Nr. 1–2, S.
5–47
[Mot06]
Motik, Boris: Reasoning in Description Logics using Resolution
and Deductive Databases, Universitaet Karlsruhe (TH), Karlsruhe,
Germany, Dissertation, January 2006
[NGT04]
Nau, Dana; Ghallab, Malik; Traverso, Paolo: Automated Planning: Theory & Practice. San Francisco, CA, USA : Morgan Kaufmann Publishers Inc., 2004. – ISBN 1558608567
166
Literatur
[NHK+ 07]
Nivre, Joakim; Hall, Johan; Kübler, Sandra; Mcdonald, Ryan;
Nilsson, Jens; Riedel, Sebastian; Yuret, Deniz: The CoNLL 2007
Shared Task on Dependency Parsing. In: Proceedings of the CoNLL
Shared Task Session of EMNLP-CoNLL 2007. Prague, Czech Republic : Association for Computational Linguistics, Juni 2007, S.
915–932
[Nil98]
Nilsson, Nils J.: Artificial Intelligence: A New Synthesis. 1st. San
Francisco, CA, USA : Morgan Kaufmann Publishers Inc., 1998. –
ISBN 1558605355
[Pap94]
Papadimitriou, Christosv H.: Computational complexity. AddisonWesley Reading, MA, 1994
[Pee04]
Peer, Joachim: A PDDL Based Tool for Automatic Web Service Composition. In: In Proceedings of the Second Intl Workshop
on Principles and Practice of Semantic Web Reasoning (PPSWR,
Springer Verlag, 2004, S. 149–163
[Pep00]
Pepper, S.: The TAO of Topic Maps. In: Proceedings of XML
Europe, 2000
[PGJ08]
Prcela, Marin; Gamberger, Dragan; Jovic, Alan: Semantic Web
Ontology Utilization for Heart Failure Expert System Design. In:
Andersen, Stig K. (Hrsg.); Klein, Gunnar O. (Hrsg.); Schulz,
Stefan (Hrsg.); Aarts, Jos (Hrsg.): MIE Bd. 136, IOS Press, 2008.
– ISBN 978–1–58603–864–9, S. 851–856
[PMBT05]
Pistore, M.; Marconi, A.; Bertoli, P.; Traverso, P.: Automated composition of web services by planning at the knowledge level.
In: Proceedings of the 19th international joint conference on Artificial intelligence, Morgan Kaufmann Publishers Inc, 2005 (IJCAI’05),
S. 1252–1259
[PNLH09]
Palaga, Peter; Nguyen, Long; Leser, Ulf; Hakenberg, Jörg:
High-performance information extraction with AliBaba. In: Proceedings of the 12th International Conference on Extending Database
Technology: Advances in Database Technology. New York, NY, USA
: ACM, 2009 (EDBT ’09). – ISBN 978–1–60558–422–5, S. 1140–1143
[Pup91]
Puppe, Frank: Einführung in Expertensysteme. Springer Verlag,
1991. – Studienreihe Informatik, 2. Auflage
[RL06]
Riabov, Anton; Liu, Zhen: Scalable Planning for Distributed
Stream Processing Systems. In: Derek Long (Hrsg.); Stephen
F. Smith (Hrsg.); Daniel Borrajo (Hrsg.); Lee McCluskey
(Hrsg.): Proceedings of the Sixteenth International Conference on
167
Literatur
Automated Planning and Scheduling, ICAPS 2006, Cumbria, UK,
June 6-10, 2006, AAAI, 2006. – ISBN 978–1–57735–270–9, S. 31–41
[RM99]
Rodionov, S. N.; Martin, J. H.: An Expert System-Based Approach to Prediction of Year-to-Year Climatic Variations in the
North Atlantic Region. In: International Journal of Climatology 19
(1999), Nr. 9, S. 951–974
[RMBCO07] R-Moreno, Marı́a D.; Borrajo, Daniel; Cesta, Amedeo; Oddi,
Angelo: Integrating planning and scheduling in workflow domains.
In: Expert Syst. Appl. 33 (2007), August, S. 389–406. – ISSN 0957–
4174
[RN04]
Russell, Stuart; Norvig, Peter: Künstliche Intelligenz. Ein moderner Ansatz. Bd. 2,. Pearson Studium, 2004. – ISBN 3–8273–7089–2
[RS04]
Rao, Jinghai; Su, Xiaomeng: A Survey of Automated Web Service
Composition Methods. In: In Proceedings of the First International
Workshop on Semantic Web Services and Web Process Composition,
SWSWPC 2004, 2004, S. 43–54
[Sar08]
Sarawagi, Sunita: Information Extraction. In: Foundations and
Trends in Databases 1 (2008), Nr. 3, S. 261–377
[SBLH06]
Shadbolt, Nigel; Berners-Lee, Tim; Hall, Wendy: The Semantic Web Revisited. In: IEEE Intelligent Systems 21 (2006), July, Nr.
3, S. 96–101
[Sch94]
Schmid, Helmut: Probabilistic Part-of-Speech Tagging Using Decision Trees. In: Proceedings of the International Conference on New
Methods in Language Processing. Manchester, UK, 1994
[SCS09]
Shue, Li-Yen; Chen, Ching-Wen; Shiue, Weissor: The development
of an ontology-based expert system for corporate financial rating. In:
Expert Syst. Appl. 36 (2009), March, S. 2130–2142. – ISSN 0957–
4174
[SdF03]
Sheshagiri, Mithun; desJardins, Marie; Finin, Timothy: A Planner for Composing Services Described in DAML-S. In: Proceedings
of the AAMAS Workshop on Web Services and Agent-based Engineering, 2003
[SDNR07]
Shen, Warren; Doan, AnHai; Naughton, Jeffrey F.; Ramakrishnan, Raghu: Declarative information extraction using datalog with
embedded extraction predicates. In: Proceedings of the 33rd international conference on Very large data bases, VLDB Endowment, 2007
(VLDB ’07). – ISBN 978–1–59593–649–3, S. 1033–1044
168
Literatur
[SMGW05]
Stein, Benno; Meyer zu Eissen, Sven; Gräfe, Gernot; Wissbrock, Frank: Automating Market Forecast Summarization from
Internet Data. In: Isaı́as, Pedro (Hrsg.); Nunes, Miguel B. (Hrsg.):
Fourth International Conference on WWW/Internet, Lisbon, Portugal, IADIS Press, Oktober 2005, S. 395–402
[SPG+ 07]
Sirin, E; Parsia, B; Grau, BC; Kalyanpur, A; Katz, Y: Pellet:
A practical OWL-DL reasoner. In: Journal of Web Semantics 5
(2007), June, Nr. 2, S. 51–53. – ISSN 1570–8268
[SR02]
Sebastiani, Fabrizio; Ricerche, Consiglio Nazionale D.: Machine
Learning in Automated Text Categorization. In: ACM Computing
Surveys 34 (2002), S. 1–47
[TH06]
Tsarkov, D.; Horrocks, I.: FaCT++ Description Logic Reasoner:
System Description. In: Proc. of the Int. Joint Conf. on Automated
Reasoning (IJCAR 2006) Bd. 4130, Springer, 2006, S. 292–297
[Tob01]
Tobies, Stephan: Complexity Results and Practical Algorithms for
Logics in Knowledge Representation, Rheinisch-Westfaelischen Technischen Hochschule, Aachen, Germany, Dissertation, May 2001
[VB11]
Vaquero, Tiago S.; Beck, Jose Reinaldo Silva C.: A Brief Review
of Tools and Methods for Knowledge Engineering for Planning &
Scheduling. In: KEPS 2011: ICAPS Workshop on Knowledge Engineering for Planning and Scheduling, 2011, S. 7–14
[Wel94]
Weld, Daniel S.: An Introduction to Least Commitment Planning.
In: AI Magazine (1994)
[Wor12]
World Wide Web Consortium (W3C). OWL Web Ontology
Language Overview. http://www.w3.org/TR/owl-features/. Zugriffsdatum: 21. April. 2012
[WPS10]
Wachsmuth, Henning; Prettenhofer, Peter; Stein, Benno: Efficient Statement Identification for Automatic Market Forecasting.
In: Proceedings of the 23rd International Conference on Computational Linguistics, ACM, 2010, S. 1128–1136
[WSE11]
Wachsmuth, Henning; Stein, Benno; Engels, Gregor: Constructing efficient information extraction pipelines. In: Proceedings of the
20th ACM international conference on Information and knowledge
management. New York, NY, USA : ACM, 2011 (CIKM ’11). –
ISBN 978–1–4503–0717–8, S. 2237–2240
169
Literatur
[ŽKŽL08]
Žáková, Monika; Křemen, Petr; Železný, Filip; Lavrač, Nada:
Using Ontological Reasoning and Planning for Data Mining Workflow Composition. In: SoKD: ECML/PKDD 2008 workshop on Third
Generation Data Mining: Towards Service-oriented Knowledge Discovery, 2008
[ŽKŽL11]
Žáková, Monika; Křemen, Petr; Železný, Filip; Lavrač, Nada: Automatic Knowledge Discovery Workflow Composition through
Ontology-Based Planning. In: IEEE Transactions on Automation
Science and Engineering 8 (2011), Nr. 2, S. 253–264
170

Entwicklung eines Expertensystems zur automatischen Erstellung

Transcription

Similar documents

uniforme Kostensuche - UniversitÃ¤t Basel

MAVI 2.0 – Konzept und Möglichkeiten

Technologien zur Wiederverwendung von Texten aus dem Web

Navigation mit Schnappschussen

Pressemitteilung

Ronald Dworkins Religion ohne Gott

Volume S-09(2010) - Mathematical Journals

Enigma Handbuch

f - bei DuEPublico - an der Universität Duisburg