DIPLOMARBEIT - eWorks · 1.3 Problemstellung: ... Klassen detailliert vorgestellt. Besondere...

Hochschule Fulda

University of Applied Sciences

Fachbereich Angewandte Informatik

DIPLOMARBEITzur Erlangung des akademischen Grades Diplom-Informatiker (FH)

Automatisierte Klassifizierung strukturierter und semistrukturierter

Kontaktanfragen

eingereicht von: Michael Gerhardt

am: 31. März 2008

Studienschwerpunkt: Medieninformatik

Referent: Prof. Dr. Hans-Theo Meinholz

Koreferent: Dipl.-Inf. Fabian Wleklinski

ErklärungGemäß § 26, Abs. 2 der Prüfungsordnung vom 14. Januar 1998 des Fachbereichs

Angewandte Informatik der Hochschule Fulda erkläre ich, dass ich die vorliegende

Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und

Hilfsmittel verwendet habe.

(Ort, Datum, Unterschrift)

Inhaltsverzeichnis

Abstract 1

1 Einleitung 3 1.1 Aufbau der Diplomarbeit.....................................................................................3

1.2 Arbeitsumgebung................................................................................................4

1.2.1 Hardware.....................................................................................................5

1.2.2 Software.......................................................................................................5

1.2.3 Weitere Werkzeuge.....................................................................................6

1.3 Problemstellung: Information Garbage...............................................................6

1.4 Ziele der Diplomarbeit.......................................................................................11

1.5 Namensgebung: PEACE...................................................................................13

2 Aktuelle Theorien und Algorithmen 15 2.1 Einführung.........................................................................................................15

2.2 Information Retrieval.........................................................................................16

2.2.1 Was ist Information Retrieval?...................................................................16

2.2.2 Data Retrieval............................................................................................17

2.2.3 Ablauf eines Information Retrieval Prozesses...........................................18

2.2.4 Evaluierung von Information Retrieval Systemen.....................................20

2.3 Natural Language Processing...........................................................................26

2.3.1 Was ist Natural Language Processing?....................................................26

2.3.2 Linguistische Werkzeuge...........................................................................27

2.3.3 Anwendungsbeispiele................................................................................30

2.4 Informationsextraktion.......................................................................................31

2.4.1 Was ist Informationsextraktion?................................................................31

2.4.2 Message Understanding Conference........................................................32

2.4.3 Reguläre Ausdrücke und endliche Automaten..........................................33

2.4.4 Kellerautomaten und kontextfreie Grammatiken.......................................36

2.4.5 Grenzen aktueller Technologien und zukünftige Forschung.....................37

2.5 Textkategorisierung...........................................................................................38

2.5.1 Was ist Textkategorisierung?....................................................................38

Inhaltsverzeichnis I

2.5.2 Methoden basierend auf handgefertigten Regeln.....................................39

2.5.3 Klassifikationsverfahren mit maschinellem Lernen...................................40

2.6 Data Mining.......................................................................................................53

2.7 Text Mining........................................................................................................55

2.8 Semantic Web...................................................................................................56

2.9 Zusammenfassung aktueller Technologien......................................................57

3 Aktuelle Softwareprodukte 61 3.1 Thematisch verwandte Softwareprodukte........................................................61

3.1.1 Weka..........................................................................................................61

3.1.2 RapidMiner.................................................................................................64

3.1.3 GATE.........................................................................................................66

3.1.4 UIMA..........................................................................................................67

3.1.5 OpenNLP...................................................................................................68

3.1.6 RIPROCON-CHECK..................................................................................68

3.2 In PEACE integrierte Softwareprodukte...........................................................70

3.2.1 JDOM.........................................................................................................70

3.2.2 Xerces Java Parser...................................................................................70

4 PEACE - Konzeption und Implementierung 73 4.1 Allgemeines.......................................................................................................73

4.2 Architektur des Frameworks.............................................................................75

4.2.1 Einstiegspunkte..........................................................................................75

4.2.2 Verarbeitung der Konfigurationsdatei........................................................78

4.2.3 Verarbeitung der Inputdateien...................................................................79

4.3 Beschreibung einzelner Pakete und Klassen...................................................80

4.3.1 Das Paket eworks.peace...........................................................................80

4.3.2 Das Paket eworks.peace.exceptions.........................................................83

4.3.3 Das Paket eworks.peace.rules..................................................................86

4.3.4 Das Paket eworks.peace.rules.core..........................................................87

4.3.5 Das Paket eworks.peace.rules.params.....................................................93

4.3.6 Das Paket eworks.peace.utils....................................................................96

4.3.7 Das Paket eworks.peace.workflows..........................................................96

4.4 XML-Schema-Dateien.......................................................................................97

II Inhaltsverzeichnis

4.4.1 Die Datei peace_config.xsd.......................................................................97

4.4.2 Die Datei peace_input.xsd.......................................................................106

4.4.3 Die Datei peace_output.xsd.....................................................................107

4.5 Integrierte Regeln............................................................................................109

4.5.1 Parameter................................................................................................109

4.5.2 Die Regelklasse WorkTimeRule..............................................................110

4.5.3 Die Regelklasse EmailNameRule............................................................113

4.5.4 Die Regelklasse MailDomainRule...........................................................114

4.5.5 Die Regelklasse TextLengthRule............................................................115

4.5.6 Die Regelklasse TextSearchRule............................................................116

4.5.7 Die Regelklasse RequestDateRule.........................................................117

4.5.8 Die Regelklasse UrgencyRule.................................................................118

4.5.9 Die Regelklasse PolitenessRule..............................................................119

4.5.10 Die Regelklasse GeographicalNearnessRule.......................................119

5 PEACE - Anwendungen des Frameworks 121 5.1 Erweiterung des Frameworks um neue Regeln..............................................121

5.1.1 Generelle Vorgehensweise......................................................................121

5.1.2 Überschriebene und implementierte Methoden......................................122

5.2 Erstellen eigener Anwendungen.....................................................................125

5.2.1 Integration in Java-Programme...............................................................125

5.2.2 Integration in Programme anderer Programmiersprachen......................129

5.3 Beispielanwendung.........................................................................................131

5.3.1 Beschreibung der Anwendung................................................................131

5.3.2 Testdaten.................................................................................................137

5.3.3 Konfigurationsdatei..................................................................................139

5.3.4 Auswertung..............................................................................................147

5.4 Anwendungsszenarien....................................................................................148

6 Ausblick und Fazit 151 6.1 Ausblick...........................................................................................................151

6.1.1 Erweiterungen des Frameworks..............................................................151

6.1.2 Neue Regeln und Ergänzungen zu bestehenden Regeln.......................152

6.2 Fazit.................................................................................................................152

Inhaltsverzeichnis III

7 Anhang 157 7.1 Verzeichnisstruktur der CD.............................................................................157

7.2 Referenzen......................................................................................................158

7.2.1 Literatur....................................................................................................158

7.2.2 Spezifikationen.........................................................................................160

7.2.3 Firmen und Organisationen.....................................................................160

7.2.4 Software...................................................................................................160

7.3 Abbildungsverzeichnis....................................................................................161

7.4 Tabellenverzeichnis........................................................................................163

7.5 API-Dokumentation der Klassen.....................................................................163

IV Inhaltsverzeichnis

Abstract

Abstract

Diese Arbeit behandelt das Thema der automatisierten Klassifikation strukturierter und se-

mistrukturierter Kontaktanfragen. Sie stellt bereits bestehende Algorithmen, Theorien und

Produkte vor und unterbreitet mit dem im Rahmen der Arbeit entstandenen Framework

PEACE einen eigenen Lösungsvorschlag.

This paper examines the topic of automated classification of structured and semi-struc-

tured contact requests. It introduces existing algorithms, theories and products and sub-

mits an own draft proposal, the framework PEACE, that was developed during the work-

ings on this paper.

1

1 Einleitung

1 Einleitung

1.1 Aufbau der Diplomarbeit

Dieses Dokument stellt eine Diplomarbeit zur Erlangung des akademischen Grades

Diplom-Informatiker (FH) dar. Die Diplomarbeit umfasst die Analyse, die Konzeption,

die Entwicklung sowie den Test einer Software zur automatisierten Klassifizierung

strukturierter und semistrukturierter Kontaktanfragen, wie z. B. Bewerbungs-, Sup-

port- oder Projektanfragen (Akquise).

In diesem, ersten Kapitel wird die Struktur der Diplomarbeit erklärt, sowie die Pro-

blemstellung und der Lösungsansatz beschrieben. Des Weiteren findet sich hier eine

Beschreibung der Ziele der Diplomarbeit, sowie die Vorstellung der Arbeitsumge-

bung.

Das zweite Kapitel enthält Beschreibungen verschiedener Theorien und Algorithmen,

die thematisch mit dem Fokus der zu erstellenden Software verwandt sind oder an

diese angrenzen. Dieses Kapitel gibt einen Überblick über bereits bestehende Ver-

fahren. Am Ende des Kapitels findet sich eine kurze Zusammenfassung aller Theori -

en mit einer Auflistung verschiedener Vor- und Nachteile und einer Sammlung von

Anwendungsideen, also der Überlegung von welchem Nutzen die entsprechende

Theorie für die zu entwickelnde Software sein könnte.

Die zu entwickelnde Software ist zwar in ihrer Form neuartig, sie fußt jedoch techno-

logisch auf bereits vorhandenen Algorithmen, indem sie diese miteinander kombi-

niert. Im dritten Kapitel werden deshalb verschiedene Software-Produkte vorgestellt,

die einige der im zweiten Kapitel beschriebenen Theorien umsetzen oder in anderer

Weise mit dem Thema verwandt sind. Es wird weiterhin evaluiert, ob und zu wel-

chem Zweck die beschriebenen Produkte in die zu entwickelnde Software integriert

werden können.

Die Konzeption und die Implementierung der Software werden im vierten Kapitel be-

schrieben. Dabei wird die Struktur der Software beschrieben sowie einzelne wichtige

3

Kapitel 1: Einleitung

Klassen detailliert vorgestellt. Besondere Aufmerksamkeit wird dabei auf jene Klas-

sen gelegt, die später noch erweitert werden sollen, sowie auf die Schnittstelle, über

welche die Software anzusteuern ist.

Bei der zu entwickelnden Software handelt es sich um ein „Framework“, das heißt

die Software kann nicht ausgeführt werden, sondern ist vielmehr eine wieder verwert-

bare und erweiterbare Sammlung von Funktionen, die für die Entwicklung von aus-

führbaren Programmen herangezogen werden kann. Deshalb wird im fünften Kapitel

ein Beispielprogramm vorgestellt, um die Funktionsweise zu demonstrieren. Dabei

wird das erzielte Ergebnis auch evaluiert. Des Weiteren enthält dieses Kapitel eine

Beschreibung, wie die Bibliothek zu erweitern ist und wie man sie in andere Anwen-

dungen integrieren kann.

Im sechsten Kapitel befindet sich ein Resümee über aufgetretene Probleme während

der Entwicklungsphase der Software. Des Weiteren werden hier mögliche Erweite-

rungen und Funktionen vorgestellt, die im zeitlich begrenzten Rahmen der Diplomar-

beit nicht umgesetzt werden konnten.

Im siebenten Kapitel befindet sich der Anhang mit zusätzlichen Informationen, wie

dem Literaturverzeichnis.

1.2 Arbeitsumgebung

Die Diplomarbeit wurde in Zusammenarbeit mit der Firma eWorks GmbH1, ehemals

eWorks GbR, konzeptioniert und erstellt.

Die benutzten Rechnerumgebungen entsprechen heutiger Standard-Hardware bzw.

Software, es ist also keine spezielle Ausstattung für die Benutzung der Software not-

wendig.

1 vgl. eWorks

4

1.2 Arbeitsumgebung

1.2.1 Hardware

Während der Ausarbeitung der Diplomarbeit wurde an unterschiedlichen Rechnerys-

temen gearbeitet. Einerseits waren diese Besitz der Firma eWorks, andererseits han-

delte es sich um private Geräte.

Privater Desktop

● Prozessor: Intel Celeron 3.06 Ghz

● Arbeitsspeicher: 1 GB

● Betriebssystem: Microsoft Windows XP Professional SP 2

Privater Laptop

● Prozessor: 1.4 GHz

● Arbeitsspeicher: 768 MB

● Betriebssystem: Microsoft Windows XP Professional SP2 / Xubuntu 7.04

Firmen-Desktop

● Prozessor: 2.8 Ghz (DualCore)

● Arbeitsspeicher: 3 GB

● Betriebssystem: Microsoft Windows Vista Business

1.2.2 Software

Für die Entwicklung der Diplomarbeit und des Frameworks PEACE wurden folgende

Software-Produkte benutzt.

● Open Office 2.3.0

● eclipse 3.2.2

● TortoiseCVS 1.8.31

5


1.2.3 Weitere Werkzeuge

Die Firma eWorks stellte ein CVS-System bereit, sodass die Dateien auf den unter-

schiedlichen Systemen synchron gehalten und die Versionen verwaltet werden konn-

ten. Des Weiteren wurde von eWorks ein Bugtracker zur Verfügung gestellt, so konn-

te die Diplomarbeit in einzelne Teilaufgaben gegliedert werden und deren Bearbei-

tungsstand kontrolliert und nachvollzogen werden.

1.3 Problemstellung: Information Garbage

Um die Kontaktaufnahme einfacher und automatisierter zu gestalten, bieten viele Fir-

men die Möglichkeit zur Kontaktaufnahme auf ihrer Internetseite an, indem sie ihre

E-Mailadresse dort bekannt machen. Durch die öffentliche Bekanntmachung der

Kontaktdaten sehen sie sich einer Flut von E-Mails ausgesetzt. Bei vielen dieser An-

fragen handelt es sich um Spam, also um unerwünschte Werbung, teilweise sogar

Betrugsversuche (z. B. Phishing) oder um E-Mails mit schadhaften Inhalten (Viren

oder Würmer).

Zur Bekämpfung von E-Mail-Spam hält der Markt eine Reihe von Programmen be-

reit, die eine recht zuverlässige Filterung bieten. Jedoch bleibt das Problem insofern

bestehen, als dass man sich nicht zu 100 Prozent auf diese automatischen Filter ver-

lassen kann und möchte. Schließlich könnten bei der ungesehenen Löschung der E-

Mails, die das Programm als Spam eingestuft hat, wichtige Informationen verloren

gehen, falls das Programm einen Fehler gemacht hat. So bleibt es die Aufgabe des

Benutzers, die endgültige Entscheidung zu treffen, wobei ein großer Teil der wichti -

gen und knappen Ressource Zeit verbraucht wird. In der Praxis kann das z. B. so

aussehen, dass ein Anti-Spam-Programm alle als Spam klassifizierten E-Mails in

einen speziellen "Spam"-Ordner verschiebt, letztlich der Anwender aber zumindest

einmal pro Woche dort hineinsieht, um die enthaltenen E-Mails entweder zu löschen,

oder im Falle von Fehlentscheidungen in den Posteingang zurückzubewegen.

6


Eine weitere Möglichkeit, um den Anteil von Spam-E-Mails wesentlich zu verringern,

ist es, die E-Mailadresse nicht explizit auf der Internetseite anzugeben, sondern ein

Kontaktformular bereitzustellen. Somit ist eine schnelle Kontaktaufnahme immer

noch gewährleistet, während die E-Mailadresse von so genannten Spammern (also

Autoren von Spam-E-Mails) nicht mehr ausgelesen werden kann. Dies war rückbli-

ckend betrachtet „die nächste Stufe der Evolution“. Letztlich verschicken die meisten

Kontaktformulare jedoch auch nur E-Mails an einen vorgegebenen Empfänger, meis-

7

Abbildung 1.1: Spam-Ordner von Google-Mail


tens eine gesonderte E-Mailadresse um die E-Mails des Kontaktformulars nicht mit

normaler Korrespondenz zu vermischen.

Jedoch entwickelten auch die Spammer neue Technologien und so entstand bald

das Problem der so genannten Bots oder Robots. Dies sind Programme die das In-

ternet automatisch nach bestimmten Inhalten durchsuchen, beispielsweise nach

Kontaktformularen. Diese Formulare werden dann vom Bot mit Spam-Inhalten aus-

gefüllt und abgeschickt, wodurch der Betreiber der Internetseite wieder einer großen

Menge unerwünschten Anfragen ausgesetzt wird. Dies ist von gewöhnlichem E-Mail-

Spam überhaupt nicht zu unterscheiden – im E-Mail-Posteingang des Unternehmens

sammeln sich dann Spam-E-Mails gemeinsam mit Spam-Kontaktformular-Anfragen.

Existiert ein Kontaktformular, so hat man die Möglichkeit, ein so genanntes Captcha

(„Completely Automated Public Turing-test to tell Computers and Humans Apart“)

einzubinden, also ein Programm, das entscheiden kann, ob das Formular von einem

Menschen oder von einem Computer ausgefüllt wurde.

8


Im theoretischen Idealzustand erhält ein Empfänger also keinerlei Spam und es wer-

den keine „echten“ E-Mails fälschlicherweise als Spam markiert. Dieser Zustand

könnte erreicht werden, indem er reguläre E-Mails nur von seinen bekannten Kontak-

ten entgegen nimmt, und auf einer Website nur ein Kontaktformular mit CAPTCHA

zur Kontaktaufnahme anbietet. Dieser Idealzustand ist aber deswegen nur theore-

tisch erreichbar, weil es sich in der Praxis nicht völlig vermeiden lässt, auch die E-

Mail-Adresse bei der ein oder anderen Gelegenheit zu veröffentlichen.

Jedoch gibt es auch unter den „echten“ Kontaktanfragen eine große Menge von An-

fragen, die für die Firma nicht wertvoll oder sogar nachteilig sind. Es kann beispiels-

weise eine Vielzahl nicht lohnenswerter oder sogar unseriöser Projektanfragen ge-

sendet werden. Es kostet viel Zeit und Mühe, aus der Masse aller Anfragen diejeni-

gen herauszusuchen, die von einem großen Wert für die Firma sind. Im schlimmsten

9

Abbildung 1.2: Kontaktformular mit CAPTCHA

(Quelle: http://formhandler.eworks-online.de)


Fall wird die Anfragenflut so unübersichtlich, dass beispielsweise relevante und wich-

tige Aufträge aus Versehen gelöscht werden. Derartige Fehler geschehen zwar nur

selten, sie können aber beliebig teuer werden – Grund genug eine technische Lö-

sung oder zumindest eine technische Unterstützung zu suchen.

Die Pyramide in Abbildung 1.3 zeigt die Verteilung der Kontaktanfragen, unterteilt in

unerwünschte Anfragen (Spam), Anfragen mit wenig bis gar keinem Informationsge-

halt (Information Garbage) und wertvolle Anfragen (Information Nuggets). Wie groß

die jeweiligen Anteile wirklich sind ist unbekannt. Die Angaben über den Prozentsatz

von Spam-E-Mails schwanken sehr stark und der Anteil von Information Garbage

bzw. Information Nuggets ist nur schwer objektiv zu messen und schwankt von Un-

ternehmen zu Unternehmen. Es ist allerdings durch Erfahrung davon auszugehen,

dass die jeweiligen Anteile in einem exponentiellen Verhältnis zueinander stehen,

also der Anteil der Spam-E-Mails sehr viel größer ist als der Anteil von Information

Garbage, welcher wiederum sehr viel größer ist als der Anteil von Information

Nuggets (beispielsweise 1000 : 10 : 1).

Den Akualitäts- und Realitätsbezug der Thematik verdeutlicht eine im November

2007 veröffentlichte Studie der Henley Business Schooll2. Laut dieser Studie vergeu-

den Führungskräfte pro Stunde Arbeitszeit rund drei Minuten, also immerhin 5%, mit

irrelevanten E-Mails und Handy-Telefonaten. Hochgerechnet verwenden Führungs-

2 vgl. Henley

10

Abbildung 1.3: Pyramide der Kontaktanfragen

Spam

InformationGarbage

InformationNuggets


kräfte also insgesamt dreieinhalb Jahre ihres Lebens auf diese überflüssigen Arbei-

ten.3

Wie erwähnt existiert eine Reihe von Produkten die Spam mehr oder weniger zuver-

lässig filtern. Dieser Bereich ist also abgedeckt, der Mensch erhält also mit hoher

Wahrscheinlichkeit keinen Spam mehr im Posteingang, sondern lediglich noch

Information Garbage und eben die wertvollen Information Nuggets. Im Optimalfall

sollte sich der menschliche Bearbeiter jedoch nur mit den Information Nuggets be-

schäftigen. Allerdings liegt es zur Zeit auch noch an ihm, die Unterscheidung zwi-

schen Information Nuggets und Information Garbage zu fällen. An dieser Stelle soll

das im Rahmen dieser Diplomarbeit zu entwickelnde Programm ansetzen. Dessen

Aufgabe ist es, zwischen Information Nuggets und Information Garbage zu unter-

scheiden, so dass sich der menschliche Bearbeiter nur noch mit der Spitze der Pyra-

mide, also den wirklich relevanten Informationen, befassen muss. Dadurch ließe sich

die Arbeitseffizienz im Optimalfall also um bis zu 5% erhöhen (s. o.).

1.4 Ziele der Diplomarbeit

Ziel der Diplomarbeit ist nicht, ein neues Verfahren zur Textklassifizierung zu entwi-

ckeln. Wie man Kapitel 2 entnehmen kann, existieren bereits viele Verfahren zur

Analyse und Kategorisierung von Texten, sowie zur Informationsgewinnung. Ein wei-

teres, „besseres“ Verfahren kann nach Meinung des Autors im zeitlich begrenzten

Rahmen der Diplomarbeit nicht entworfen werden. Die Ziele der Diplomarbeit lauten

wie folgt:

● Schaffung eines Rahmens für eine Reihe von Anwendungsfällen

● Möglichkeit zur Kombination bereits vorhandener Methoden

● Möglichkeit zur Erstellung neuer Regeln bzw. Methoden

● Kontaktanfragen stehen im Fokus der Anwendung

● Klassifizierung geschieht in Echtzeit

3 vgl. heise071122

11


● Schaffung von Vorteilen für den menschlichen Bearbeiter

– die knappe Ressource Zeit wird geschont

– wichtige Chancen werden schneller erkannt und nicht verpasst

– Vermeidung von Verärgerung beim Bearbeiter und dessen Kontaktpartner

Die zu entwickelnde Software ist ein Framework. Es handelt sich also nicht um ein

komplettes Programm, sondern um ein Hilfsmittel, das bei der Entwicklung von An-

wendungen herangezogen werden kann. Im Vordergrund stehen dabei verschiedene

Regeln, die beliebig kombiniert werden können und deren Auswertung die entspre-

chende Kategorie der Anfrage indiziert. Anwendungen, die auf dem hier entwickelten

Framework basieren, könnten beispielsweise sein:

● Kontaktformulare für Projektanfragen, Bewerbungen oder sonstige Kon-

taktanfragen

● Web-Umfragen für öffentliche Umfragen (Internet) oder auch firmeninterne

(Intranet)

● Email-Client-Plugins für die Klassifizierung jeglicher Arten von Kontaktanfra-

gen

● Windows-Anwendungen, wie beispielsweise Anwendungen, die einen Tele-

fon-Support-Mitarbeiter beim Kundenkontakt leiten

● Support-Formulare

● Zusatzmodule für CRM-Systeme (Customer Relationship Management),

welche eingehende Korrespondenz automatisch klassifizieren

Des Weiteren ist das Framework ein Expertensystem, das heißt der Mensch wird als

wichtiger Teil des Kategorisierungsprozesses berücksichtigt. Diese Arbeitsweise

kennt man beispielsweise von Anti-Viren-Programmen oder Firewalls. In einem Fall,

in dem nicht hundertprozentig sicher ist, ob es sich um einen Virus handelt oder nicht

bzw. ob eine bestimmte Verbindung blockiert werden soll oder nicht, fragt das Anti-

Viren-Programm bzw. die Firewall den Benutzer, wie in der jeweiligen Situation zu

verfahren ist. Der Mensch kann also zum einen als „Experte“ herangezogen werden,

12

1.4 Ziele der Diplomarbeit

die Auswertung einzelner Regeln kann also von der Beurteilung eines menschlichen

Bearbeiters abhängen. Und natürlich lernt das System dabei auch vom Menschen,

indem es seine Einschätzung der vorliegenden Fakten speichert und in zukünftigen,

identischen Situationen wieder heranzieht, um eine erneute Rückfrage zu vermeiden.

Zum anderen soll der Mensch auch mit Hilfe der Software lernen können, bestimmte

Anfragen schneller zu kategorisieren. Dies wird dadurch erreicht, dass er die Mög-

lichkeit hat, die Begründung für eine vom System getroffene Entscheidung zu sich-

ten. Dadurch wird er eventuell für die wichtigen Merkmale einer Kontaktanfrage sen-

sibilisiert und er kann diese Erkenntnisse beim zukünftigen Bearbeiten von Anfragen

anwenden, um so den Kategorisierungsprozess zu beschleunigen. Es findet also ein

wechselseitiger Wissensaustausch zwischen der Software und dem Menschen statt.

1.5 Namensgebung: PEACE

Als Name für das Framework wurde „PEACE“ ausgewählt. Dies steht für

„Professional Environment for Accelerated Contact-Establishing“. Zum einen fiel die

Entscheidung für dieses Akronym, da es recht präzise beschreibt, was die Aufgaben

des Frameworks sind. Zum anderen ist „peace“ das englische Wort für Frieden oder

Ruhe. Nach Meinung des Autors ist dies eine treffende Beschreibung für das eigentli-

che Ziel der Software, Verärgerung oder Aufregung bei den Benutzern des Frame-

works zu vermeiden.

13

2 Aktuelle Theorien und Algorithmen

2 Aktuelle Theorien und Algorithmen

2.1 Einführung

In diesem Kapitel werden verschiedene Theorien vorgestellt, die thematisch mit dem

Fokus der zu entwickelnden Software verwandt sind. Es handelt sich dabei teilweise

um etablierte, teilweise aber auch um neuere Verfahren, die zum Teil noch als „Visi-

on“ bezeichnet werden könnten.

Grundsätzlich könnte man alle hier vorgestellten Theorien als Alternative zu dem im

Rahmen der Diplomarbeit entwickelten Programm ansehen. Es hat sich jedoch ge-

zeigt, dass die hier vorgestellten Verfahren gewisse Schwächen besitzen. Teils er-

schwert die große Komplexität den Einsatz für das beschriebene Anwendungsgebiet,

teils sind die Theorien nicht ausgereift bzw. umfassend genug, um das gewünschte

Ziel zu erreichen. Aus diesem Grund besteht die Möglichkeit, alle oder einige der be-

schriebenen Verfahren in die zu entwickelnde Software zu integrieren und zu kombi-

nieren, um eine größere Effektivität des Frameworks zu erreichen.

Am Ende des Kapitels befindet sich eine Tabelle, die alle vorgestellten Verfahren

noch einmal kurz zusammenfasst und deren Vor- und Nachteile auflistet. Des Weite-

ren wird hier das mögliche Anwendungsgebiet der jeweiligen Theorie innerhalb des

Frameworks beschrieben.

Es handelt sich bei den in diesem Kapitel beschriebenen Verfahren lediglich um

theoretische Konzepte. In Kapitel 3 werden Softwareprodukte beschrieben, die diese

Konzepte umsetzen. Auch diese Produkte können wieder aus zwei Sichtweisen be-

trachtet werden: zum einen als Alternative zu dem zu entwickelnden Framework,

zum anderen als Komponente, die in das Framework integriert werden könnte.

15

Kapitel 2: Aktuelle Theorien und Algorithmen

2.2 Information Retrieval

2.2.1 Was ist Information Retrieval?

Information Retrieval (IR) behandelt die Repräsentation, Speicherung und Organisa-

tion von Informationen und den Zugang zu diesen. Die Informationen werden in einer

solchen Art und Weise organisiert und repräsentiert, dass sich dem Benutzer der Zu-

gang zu der für ihn interessanten Information möglichst einfach gestaltet. Die

Schwierigkeit liegt darin, das Informationsbedürfnis des Benutzers zu identifizieren.

Die Beschreibung dieses Bedürfnisses würde der Benutzer wahrscheinlich in einer

natürlichen Sprache verfassen, welche aber von heutigen Systemen nicht oder zu-

mindest i. d. R. nicht direkt verarbeitet werden kann. Es gibt durchaus Ansätze, na-

türlichsprachliche Suchanfragen zu verarbeiten, wie z. B. beim Microsoft Office-

Suchassistenten, jedoch offensichtlich nur bedingt mit Erfolg. Die Aufgabe es Benut-

zers ist es daher zunächst, diese Beschreibung in eine maschinell verarbeitbare Ab-

fragesprache zu transformieren, während die Aufgabe des Systems darin liegt, die

für die entsprechende Abfrage relevanten Dokumente zu finden und dem Benutzer

zu präsentieren. In den meisten Fällen besteht diese Abfrage aus einzelnen Schlüs-

selwörtern, die die Beschreibung des Informationsbedürfnisses zusammenfassen.

Der Vorgang der Transformation der Abfrage von einer natürlichen Sprache in eine

maschinell verarbeitbare Sprache ist durch die Benutzung von Internet-Suchmaschi-

nen, die eine Form von IR-Systemen darstellen, bekannt. Ist der Benutzer beispiels-

weise auf der Suche nach einer Definition von Information Retrieval, so würde er die-

ses Informationsbedürfnis in einer natürlichen Sprache wahrscheinlich wie folgt for-

mulieren: „Was ist die Definition von Information Retrieval?“ oder „Wie ist Information

Retrieval definiert?“ Diese in einer natürlichen Sprache verfasste Abfrage wird vor

der Benutzung der Suchmaschine transformiert, beispielsweise in „Information

Retrieval Definition“. Die Eingabe dieser drei Schlüsselwörter führt erwartungsgemäß

zu dem gewünschten Ergebnis. Diese nicht intuitive Transformation geschieht bei er-

16


fahrenen Internet-Benutzern häufig unterbewusst, während Internet-Neulinge diese

Art von Abfragesprache zunächst erlernen müssen.1

2.2.2 Data Retrieval

Im Gegensatz zu Information Retrieval bezeichnet Data Retrieval (DR) das präzise

Auffinden aller Objekte, die einer bestimmten, klar definierten Bedingung entspre-

chen. Solche Bedingungen werden in einer entsprechenden Abfragesprache defi-

niert. Eine solche präzise Abfragesprache wäre schon dann unzureichend, wenn ein

einziges, der Anfrage nicht entsprechendes Objekt in der Menge der Antwortobjekte

vorhanden ist oder wenn ein einziges relevantes Objekt nicht gefunden wird. Beispie-

le für DR-Systeme sind Datenbank-Abfragesprachen (z. B. SQL) und reguläre Aus-

drücke.

Die Ergebnismenge eines DR-Systems ist wesentlich „schärfer“ als bei einem IR-

System. Es kann nicht vorkommen, dass irrelevante Dokumente gefunden werden

oder relevante Dokumente nicht gefunden werden, ohne dass dies die Unbrauchbar-

keit des Systems bedeuten würde. Eine „unscharfe“ oder „nicht genau nachvollzieh-

bare“ Interpretation von SQL oder von regulären Ausdrücken ist undenkbar, diese

würden den Nutzen der Technologie insgesamt in Frage stellen, wenn nicht gar ne-

gieren. Eine „unscharfe“ oder „nicht genau nachvollziehbare“ Interpretation von na-

türlichen Suchanfragen bei der Internetsuchmaschine Google hingegen ist völlig ak-

zeptabel und nützlich, weil es sich um Information Retrieval, und eben nicht um Data

Retrieval handelt.

Eine weitere Abgrenzung des DR zum IR ist die Tatsache, dass beim DR die Rele-

vanz eines Dokumentes nicht von der Interpretation des Benutzers abhängig ist – an-

ders als beim IR. Ein IR-System hat zum Ziel, alle für eine Benutzerabfrage relevan-

ten Dokumente zu finden und dabei möglichst wenig irrelevante Dokumente zu lie-

fern.

Ein weiterer Unterschied ist, dass bei einem DR-System der Suchvorgang direkt auf

den entsprechenden Daten abläuft, während bei einem IR-System die Dokumente

1 vgl. Bae1999, S. 1

17


zunächst syntaktisch und semantisch untersucht, transformiert und organisiert wer-

den müssen.2

2.2.3 Ablauf eines Information Retrieval Prozesses

Bevor ein Benutzer mit einem IR-System arbeiten kann, muss dieses zunächst auf-

gebaut werden. Es ist nötig, eine Text-Datenbank zu definieren. Dazu müssen die

folgenden Punkte spezifiziert werden:

1. Welche Dokumente werden benutzt? Die Dokumente könnten beispielswei-

se manuell zusammengestellt werden oder von einem Webcrawler (speziell

bei Suchmaschinen) zusammengesucht werden. Am Ende dieses Schrittes

steht die Menge von Dokumenten bereit, die über das IR-System zugänglich

sind.

2. Welche Operationen werden auf den Texten ausgeführt? In diesem Schritt

kann beispielsweise das Entfernen von Stoppwörtern (u.a. Artikel und Hilfsver-

ben) oder das so genannte Stemming geschehen.

3. Wie sieht die Struktur der Texte aus und welche Informationselemente können bereitgestellt werden? In diesem Schritt wird entschieden, wie ein

Dokument repräsentiert (z. B. als Dokumentvektor) und wie diese Repräsenta-

tion gespeichert wird (z. B. in einer relationalen Datenbank).

Die Operationen, die auf den Texten ausgeführt werden, wandeln die Originaldoku-

mente um und erstellen eine logische Sicht auf diese. Nachdem die logische Sicht

definiert ist, wird ein Index über alle Texte erstellt. Dabei existieren mehrere Arten

von Indizes, die gebräuchlichste ist die invertierte Liste, bei der beispielsweise einem

Stichwort mehrere Dokumente zugeordnet werden und nicht einem Dokument meh-

rere Stichworte. Dies erhöht die Geschwindigkeit des Suchvorgangs.

2 vgl. Bae1999, S. 1 f.

18


Nachdem die Dokumente indiziert worden sind können Suchabfragen gestartet wer-

den. Der Benutzer beschreibt sein Informationsbedürfnis in der entsprechenden Ab-

fragesprache und teilt dies dem IR-System mit. Das System sucht alle relevanten

Dokumente, ordnet diese nach dem Grad ihrer Relevanz und stellt dem Benutzer

eine Liste dieser Dokumente bereit.3

3 vgl. Bae1999, S. 9 f.

19

Abbildung 2.1: Ablauf eines Information Retrieval Prozesses

TextDB

Text Operationen Indizierung IndexText

LogischeSicht

InvertierteListe

Benutzer

Formulierungin Abfragesprache Suchvorgang

Informations-bedürfnis Abfrage

Sortierungnach Relevanz

GefundeneDokumente

SortierteDokumente


2.2.4 Evaluierung von Information Retrieval Systemen

Um die Genauigkeit von IR-Systemen zu evaluieren, existieren mehrere Messgrö-

ßen. Die gebräuchlichsten sind Precision und Recall. Diese sind vor allem deshalb

interessant, da sie auch auf andere Bereiche, beispielsweise der Evaluierung von

Textkategorisierungssystemen, übertragen worden sind und dort in leicht abgeänder-

ter Form Anwendung finden.4

4 vgl. Bae1999, S. 73 f., Jac2007, S.46

20

Abbildung 2.2: Google-Ergebnisse für "Information Retrieval Definition", sortiert nach Relevanz


Recall und Precision

Sei I ein Beispiel für eine Abfrage und R sei die Menge der für I relevanten Doku-

mente. Weiterhin sei |R| die Anzahl der Dokumente in dieser Menge. Das zu evaluie-

rende IR-System liefere eine Antwortmenge A zurück, deren Größe |A| sei. Des Wei-

teren sei |Ra| die Größe der Schnittmenge von R und A, das heißt die Anzahl der re-

levanten, gefundenen Dokumente.

Dann sind Recall und Precision wie folgt definiert:

● Recall (dt. „Auffund“) ist der Teil der relevanten Dokumente, die tatsächlich

gefunden wurden, also

Recall=∣Ra∣∣R∣

● Precision (dt. „Präzision“) ist der Teil der gefundenen Dokumente, die rele-

vant sind, also

21

Abbildung 2.3: Precision und Recall

Relevante Dokumente in der Menge aller Antworten

|Ra|

Relevante Dokumente|R|

Menge der gefundenen Antworten

|A|

Erfasste Dokumente


Precision=∣Ra∣∣A∣

Bei der Definition von Recall und Precision wird davon ausgegangen, dass alle ge-

fundenen Dokumente auf ihre Relevanz hin untersucht wurden, sowie alle relevanten

Dokumente bekannt sind.5

Beispiel: Angenommen es gäbe für eine Anfrage 1000 relevante Dokumente ( |R| =

1000) und es werden 900 Dokumente gefunden (|A| = 900). Von den gefundenen

Dokumenten seien 700 tatsächlich relevant (|Ra| = 700).

Dann ist Recall: ∣Ra∣∣R∣

= 7001000

=0,7 oder 70 %

Precision wäre: ∣Ra∣∣A∣

=700900

=0,7778 oder 77,78 %

Einen zu niedrigen Recall merkt man als Suchmaschinen-Benutzer in der Regel

nicht, weil einem schlichtweg relevante Dokumente „vorenthalten“ werden. Man er-

hält nicht alle relevanten Dokumente zurück, bemerkt das aber nicht, weil man die

Gesamtmenge nicht kennt. Eine zu niedrige Precision wiederum bemerkt man direkt

unangenehm, weil der Eindruck entsteht, dass man von der Suchmaschine nicht

„verstanden“ wurde – man erhält größtenteils Dokumente zurückgemeldet, die mit

dem Informationsbedürfnis nichts oder nicht viel zu tun haben.

Harmonisches Mittel

Da weder Recall noch Precision für sich alleine genommen eine konkrete Aussage

über die Genauigkeit des IR-Systems machen können, wäre es interessant ein Maß

zu finden, was diese beiden Größen vereint. Ein solches Maß ist das harmonische

Mittel F von Recall und Precision. Dieses wird berechnet durch:

F= 21

Recall 1

Precision

5 vgl. Bae1999, S. 75 ff.

22


F wird dabei 1 wenn sowohl Precision als auch Recall bei 100% liegen. Je kleiner

Precision und Recall werden, desto mehr nähert sich F an dem Wert 0 an.6

Beispiel: Angenommen es gelten die gleichen Zahlen wie im Beispiel für Recall und

Precision.

Harmonisches Mittel wäre: 21

Recall 1

Precision

= 210,7

10,7778

≈0,7368 oder 73,68 %

Das E-Maß

Das E-Maß ist ein weiteres Maß, das Precision und Recall kombiniert. Die Idee ist,

es dem Benutzer zu überlassen, ob Precision oder Recall höher bewertet werden

soll. Das E-Maß ist wie folgt definiert:

E=1− 1b2

b2

Recall 1

Precision

Dabei ist b eine benutzerdefinierte Größe, die die relative Wichtigkeit von Recall und

Precision festlegt. Bei b = 1 entspricht das E-Maß dem harmonischen Mittel. Je grö-

ßer b gewählt wird, desto wichtiger wird Precision. Werte für b kleiner 1 zeigen, dass

der Benutzer sich mehr für Recall interessiert. Die Größe b darf dabei nicht negativ

werden. Es ist zu beachten, dass beim E-Maß ein kleiner Wert (also ein Wert der

sich 0 annähert) das System positiver bewertet als ein großer (also ein Wert der sich

1 annähert).7

Beispiel: Angenommen es gelten die gleichen Zahlen wie im Beispiel für Recall und

Precision. Des Weiteren sei b = 2, das heißt, Precision ist stärker zu bewerten.

Das E-Maß wäre: 1− 1b2

b2

Recall 1

Precision

=1− 540,7

10,7778

≈0,2857 oder 28,57 %

6 vgl. Bae1999, S. 82

7 vgl. Bae1999, S. 82

23


Benutzerorientierte Maßeinheiten

Precision und Recall basieren auf der Annahme, dass unabhängig vom Benutzer die

Menge der relevanten Dokumente für eine Anfrage immer dieselbe bleibt. Unter-

schiedliche Benutzer können aber unterschiedliche Vorstellungen davon haben, was

für sie ein relevantes Dokument ist. Um dieses Problem zu lösen sind benutzerorien-

tierte Maßeinheiten eingeführt worden.

Dem zu bewertenden IR-System wird die Anfrage I gestellt. Sei R die Menge der für I

relevanten Dokumente und A die vom System gelieferte Antwortmenge. Des Weite-

ren sei U eine Teilmenge von R, die dem Benutzer bekannt ist. Die Anzahl der Doku-

mente in U ist |U|. Die Schnittmenge von A und U beinhaltet die Dokumente, von de-

nen der Benutzer weiß, dass sie relevant sind und die gefunden wurden. |Rk| sei die

Größe dieser Menge. Weiterhin sei |Ru| die Anzahl der gefundenen, relevanten Do-

kumente, die dem Benutzer bisher unbekannt waren.

24

Abbildung 2.4: Coverage und Novelty

Relevante Dokumente,dem Benutzer bekannt

|U|

Relevante Dokumente|R|

Antwortmenge|A|

Relevante Dokumente,dem Benutzer bekannt,vom System gefunden

|Rk|

Relevante Dokumente,bisher unbekannt,

vom System gefunden|Ru|


Es werden die Größen Coverage und Novelty neu eingeführt und wie folgt definiert:

● Coverage (dt. „Abdeckung“) ist der Teil der dem Benutzer als relevant be-

kannten Dokumente, der tatsächlich gefunden wurde, also

Coverage=∣Rk∣∣U∣

● Novelty (dt. „Neuheit“) ist der Teil der gefundenen, relevanten Dokumente,

der dem Benutzer bisher unbekannt war, also

Novelty= ∣Ru∣∣Ru∣∣Rk∣

Ein hoher Wert für Coverage zeigt an, dass das System die meisten der relevanten

Dokumente gefunden hat, die der Benutzer erwartet hatte. Ein hoher Wert für

Novelty weist darauf hin, dass das System dem Benutzer eine große Menge relevan-

ter Dokumente offenbart, die bisher unbekannt waren.8

Beispiel: Angenommen es gäbe für eine Anfrage 1000 relevante Dokumente ( |R| =

1000 und es werden 900 Dokumente gefunden (|A| = 900), 700 der gefundenen Do-

kumente seien tatsächlich relevant (|Ra| = 700). Dem Benutzer seien 300 relevante

Dokumente bekannt (|U| = 300), von diesen seien 250 tatsächlich in der Antwortmen-

ge enthalten (|Rk| = 250). Daraus ergibt sich, dass dem Benutzer 450 der relevanten,

gefundenen Dokumente bisher unbekannt waren (|Ru| = |Ra| - |Rk| = 450).

Coverage wäre: ∣Rk∣∣U∣

=250300

≈0,8333 oder 83,33 %

Novelty wäre: ∣Ru∣

∣Ru∣∣Rk∣=450700

≈0,6429 oder 64,29 %

Daraus folgt 83,33 % der dem Benutzer bekannten, relevanten Dokumente wurden

gefunden und 64,29 % der relevanten, gefundenen Dokumente waren dem Benutzer

bisher unbekannt.

8 vgl. Bae1999, S. 83 f.

25


2.3 Natural Language Processing

2.3.1 Was ist Natural Language Processing?

Natural Language Processing (NLP) oder zu deutsch Verarbeitung natürlicher

Sprache bezeichnet die Analyse und Synthetisierung gesprochener oder geschriebe-

ner Sprache mit Hilfe von Software- oder Hardware-Komponenten. Der Term natural

bzw. natürlich wird benutzt um hervorzuheben, dass es sich um menschliche Schrift

oder Sprache handelt, und nicht um formale Sprachen wie mathematische oder logi -

sche Notationen oder Programmier- bzw. Auszeichnungssprachen wie Java, C++

oder XML.

Probleme:

● Homonyme: Eine der großen Problematiken der NLP ist die häufige Mehr-

deutigkeit mancher Begriffe. So kann mit dem deutschen Wort „Golf“ bei-

spielsweise eine Kraftfahrzeug, ein Gewässer oder ein Sport gemeint sein.

Dem Menschen wird die Begrifflichkeit aus dem Satzzusammenhang sehr

schnell klar, die maschinelle Verarbeitung wird hier schon vor größere Proble-

me gestellt. Weitere populäre Beispiele sind „Java“ (Programmiersprache, In-

sel, Kaffee) oder „Jaguar“ (Auto, Tier, Fahrrad).

● Fehlender Bezug: Häufig treten in der natürlichen Sprache auch Gebilde auf,

die Komponenten enthalten, deren Bezug zunächst nicht eindeutig ist. Die

beiden folgenden Sätze verdeutlichen dies:

„Sie bestieg ein Flugzeug mit zwei Koffern.“

„Sie bestieg ein Flugzeug mit zwei Triebwerken.“

Für den Menschen ist es offensichtlich, dass die Koffer im ersten Satz der

Frau („Sie“) gehören, während die Triebwerke im zweiten Satz dem Flugzeug

zuzuordnen sind. Für einen Computer ist dieser Zusammenhang viel schwe-

rer herzustellen, vor allem da beide Sätze genau gleich strukturiert sind. Im

Prinzip kann auch der Mensch keine der Interpretationsmöglichkeiten von vor-

26


neherein ausschließen. Die natürliche Sprache ist schlichtweg per se un-

scharf und Menschen treffen Annahmen, die Computern nicht treffen kön-

nen.9

2.3.2 Linguistische Werkzeuge

Um einen natürlichen Text maschinell zu verarbeiten, greift NLP auf verschiedene

Methoden und Algorithmen aus der Linguistik (Sprachwissenschaft) zurück. Die lin-

guistische Analyse von Texten wird typischerweise in mehreren Schritten durchge-

führt. Dokumente werden zunächst in Sätze und Sätze in einzelne Wörter unterteilt.

Die Wörter werden dann auf Grund ihrer Funktion innerhalb des Satzes markiert, sie

werden also verschiedenen grammatischen Kategorien zugeordnet (z. B. Subjekt,

Verb, Objekt, Adverb, Adjektiv etc.).10

Die einzelnen linguistischen Schritte werden im folgenden beschrieben.

Satzabgrenzung und Tokenisierung

Um die Sätze eines Dokuments grammatikalisch bestimmen zu können, muss zu-

nächst der Gültigkeitsbereich dieser Sätze erkannt und deren Komponenten identifi-

ziert werden.

Die Abgrenzung einzelner Sätze ist kein so einfaches Verfahren, wie es auf den ers-

ten Blick scheint. Der Punkt als Satzzeichen ist vieldeutig, zwar markiert er tatsäch-

lich oft das Ende eines Satzes, er kann jedoch auch andere Bedeutungen haben, so

wird er häufig auch bei Abkürzungen benutzt („Dr.“, „bzw.“), dient bei Zahlen im deut-

schen Sprachgebrauch als Tausender-Trennzeichen („1.500.000“) und bei der engli-

schen Notation von Zahlen als Dezimal-Trennzeichen („1,234.56“). Um dieser Pro-

blematik zu begegnen, gibt es verschiedene Verfahren. Einige verlassen sich auf

Reguläre Ausdrücke oder Ausnahmeregeln. Andere benutzen empirische Techniken,

sie werden anhand eines manuell segmentierten Korpus11 trainiert.

9 vgl. Jac2007, S.1 ff.

10 vgl. Jac2007, S.11

11 Ein Korpus, auch Textkorpus, ist eine Sammlung von Texten.

27


Bei der Tokenisierung wird eine Folge von Buchstaben in sinnvolle Einheiten, so ge-

nannte Tokens, unterteilt. Auch hier zeigen sich anfänglich nicht zu erahnende

Schwierigkeiten. Das Leerzeichen als einfaches Trennzeichen zwischen einzelnen

Tokens zu benutzen, erscheint zunächst sinnvoll, birgt aber auch einige Probleme.

Während das französische „pomme de terre“ (dt. „Kartoffel“) semantisch eher als ein

Token anzusehen ist, könnte man das deutsche Wort

„Lebensversicherungsgesellschaft“ sinngemäß auch in drei Tokens unterteilen. Toke-

nisierungsmechanismen verwenden zur Lösung dieser Problematik eine Kombination

aus Regeln, endlichen Automaten, statistischen Modellen und Lexika.12

Stammbildung und Markierung

Das grammatische Bestimmen von Satzteilen setzt zunächst eine lexikalische Analy-

se voraus, um die Stammformen verschiedener Wortvorkommen zu bestimmen.

Bei der Stammbildung, auch Stemming genannt, werden morphologische Analysie-

rungsmechanismen eingesetzt, die verschiedene Varianten eines Terms mit deren

Stammform assoziieren. So würden die Ausdrücke „gehen“, „gehe“, „gehst“,

„gegangen“ und „ging“ alle der Stammform „gehen“ zugeordnet. Bei der Stammbil-

dung wird der Zusammenhang, in dem ein Wort steht, nicht berücksichtigt. Daher

kann ein morphologischer Analysierungsmechanismus mehr als eine Stammform lie-

fern. Das deutsche Wort „weiß“ kann beispielsweise dem Verb „wissen“ sowie auch

der Farbe „Weiß“ zugeordnet werden. Neben der Stammbildung, die sich auf Lexika

stützt, gibt es auch heuristische Verfahren. So entfernt der Porter-Stemmer-

Algorithmus13 beispielsweise bei englischen Wörtern die Suffixe „-ed“, „-ing“, „-ation“

oder „-ational“ um die Stammform des Wortes zu bestimmen. Stemming geht letztlich

davon aus, dass der Informationssuchende nicht an Details interessiert ist, die sich

nur in der Beugung der Wörter niederschlägt – ihn also z. B. nicht interessiert, ob ein

Text in der Gegenwart oder in der Vergangenheit verfasst ist.

12 vgl. Jac2007, S. 11 f.

13 vgl. Porter

28


Markierungsmechanismen versehen schließlich jedes Wort mit einer Markierung. Da-

bei kann zwischen regelbasierten und stochastischen Verfahren unterschieden wer-

den. Regelbasierte Verfahren versuchen unbekannte Wörter, z. B. anhand ihrer Stel-

lung im Satz zu bestimmen. „Wenn ein unbestimmter Term zwischen einem Artikel

und einem Nomen steht, handelt es sich wahrscheinlich um ein Adjektiv“. Außerdem

werden auch morphologische Informationen mit einbezogen. In der englischen Spra-

che sind beispielsweise unbekannte Wörter mit der Endung „-ing“, die auf eine Form

von „to be“ folgen, meistens Verben („I am dancing.“). Stochastische Verfahren ba-

sieren auf einem Satz von Trainingsdaten. Die einfachste Art dieses Verfahrens

weist einem Wort diejenige Kategorie zu, der es mit der größten Wahrscheinlichkeit

angehört. Diese Wahrscheinlichkeiten werden vorher aus den Trainingsdaten be-

rechnet.14

Nomenphrasierung und Namenserkennung

In einigen Fällen kann es wichtig sein, nicht nur einzelne Wörter mit Markierungen zu

versehen, sondern auch Sequenzen von Worten (z. B. „das alte Haus“) als

Nomenphrasen zu erkennen. Hierzu werden regelbasierte Verfahren angewendet.

So beginnen viele Nomenphrasen mit einem Artikel („das“, „ein“ oder „dieses“) und

enden direkt vor einem Verb.

Bei der Namenserkennung geht es darum zusammengesetzte Namen von Persön-

lichkeiten oder Unternehmen herauszufinden. Auch hier gibt es unterschiedliche Ver-

fahren: regelbasierte Systeme, Systeme die trainiert werden und Systeme die mit

statistischen Modellen arbeiten. Die Mehrheit der kommerziell erhältlichen Werkzeu-

ge arbeitet mit Regelsystemen.

Die Nomenphrasierung und Namenserkennung ist beispielsweise wichtig, wenn man

aus einem Newsfeed interessante Wirtschaftsnachrichten extrahieren möchte. So ist

es notwendig, zu wissen, dass sich die Begriffe „Microsoft“, „Microsoft Corporation“,

„das große Softwareunternehmen“ und „die Redmonder Firma“15, falls diese zusam-

men in einem Text auftreten, alle auf ein Unternehmen beziehen. Ist man nun inter-

14 vgl. Jac2007, S. 13 ff.

29


essiert an Wirtschaftsnachrichten über dieses spezielle Unternehmen, so muss das

NLP-System über dieses Wissen verfügen.16

Parser und Grammatiken

Generell wird das Parsen (engl. to parse: analysieren, grammatikalisch bestimmen)

eines Textes auf Basis einer Grammatik durchgeführt. Diese bestimmt, welche Kom-

binationen von welchen Teilen der Sprache wohlgeformte Konstrukte bilden. Der

Satz „Farblose grüne Ideen schlafen wütend“ ist beispielsweise syntaktisch korrekt,

da Adjektiv + Adjektiv + Nomen eine valide Nomenphrase, Verb + Adverb eine valide

Verbphrase und Nomenphrase + Verbphrase einen validen Satz bilden.17

2.3.3 Anwendungsbeispiele

Das Erstellen eines linguistischen Systems mit grammatikalischen Regeln ist sehr

zeit- und arbeitsaufwändig, und obwohl schon einige dieser Systeme für die engli-

sche Sprache existieren, deckt keines davon alle Konstrukte, die in beliebig ausge-

wählten Texten vorkommen können, zu 100% ab.

Dennoch existiert bereits eine Menge von Anwendungsbeispielen für NLP-Systeme,

auch im deutschsprachigen Bereich. Einige davon werden sogar beinahe täglich be-

nutzt und funktionieren recht gut, andere sind noch im Teststadium. Anwendungsbei-

spiele sind:

● Fehlerkorrektur bei Textverarbeitungsprogrammen während der Eingabe,

z. B. Korrektur von Buchstabendrehern („dei“ wird zu „die“), beispielsweise

bei Microsoft Word oder OpenOffice.org Writer

● Rechtschreibprüfung und Grammatikprüfung bei Textverarbeitungspro-

grammen

15 Derartige Textpassagen kommen in Pressetexten sehr häufig und auch nicht rein zufällig vor, son-

dern sind ein beliebtes Stilmittel, vgl. SpiegelOnlineSynonyme.

16 vgl. Jac2007, S. 16 f.

17 vgl. Jac2007, S. 17 f.

30


● Hilfe beim Finden des richtigen Ausdrucks beim Verfassen von Dokumenten

mit Textverarbeitungsprogrammen („Thesaurus“)

● Spracherkennung bei telefonischen Diensten, z. B. Kinokartenreservierung

oder Auskunft, oder auch bei Spracherkennungssoftware

● Übersetzungsdienste für ganze Texte (z. B. Babelfish)

● Automatisches Zusammenfassen von Dokumenten bei Microsoft Word

● Automatische Erkennung der Sprache eines Textes anhand der Wörter bei

Microsoft Word

2.4 Informationsextraktion

2.4.1 Was ist Informationsextraktion?

Informationsextraktion (IE, engl. Information Extraction) bezeichnet die Suche inner-

halb eines oder mehrerer Dokumente mit dem Zweck, nützliche Informationen aus

den vorhandenen Daten zu extrahieren. Es geht also nicht darum, diese Texte oder

die enthaltenen Informationen zu verstehen, sondern nur darum, die Informationen

zu extrahieren. Typischerweise werden elektronische Dokumente (z. B. aus einem

Newsfeed) nach bestimmten Begriffen durchsucht, um passende Datensätze einer

näheren Analyse zu unterziehen18. Beispielsweise werden viele Kommunikations-

kanäle seit den 1970er Jahren von Geheimdiensten untersucht, und Dokumente

bzw. Kommunikationsprotokolle, die entsprechende Schlüsselwörter, wie „Terrorist“

oder „Bombe“ enthalten, zur näheren Untersuchung an Analysten weitergeleitet. Mo-

derne Extraktionsprogramme haben jedoch höhere Ansprüche, um das Identifizieren

und Auswerten von interessanten Inhalten zu beschleunigen.

Im Gegensatz zu vielen anderen NLP-Anwendungen betrachten Extraktionssysteme

nur einen gewissen Teil der zu untersuchenden Texte, wobei bestimmte Wörter als

18 Eine ähnliche Funktionsweise bieten viele Feedreader mit der so genannten „Alarmfunktion“ an,

dabei wird der Benutzer beispielsweise durch ein akustisches Signal auf das Vorhandensein eines

bestimmten Wortes in einem Newsfeed hingewiesen.

31


Auslöser (engl. trigger) genutzt werden. Textteile, die diese Trigger-Wörter beinhal-

ten, werden analysiert, und es wird versucht die enthaltene Information in eine vorher

definierte Form zu pressen. Dies ist vergleichbar mit dem Lesen einer Zeitung, die in

einer Sprache verfasst ist, die man nicht beherrscht. Trotz mangelnder Sprachkennt-

nisse wird man bestimmte Informationen (z. B. Fußballergebnisse) finden und verste-

hen können.

Mögliche Anwendungsfälle könnten das Generieren von Metadaten für Internetseiten

oder das Zusammenfassen mehrerer Dokumente in Bezug auf ein bestimmtes The-

ma sein. Dieses Verfahren ist beispielsweise von der Suchmaschine Google be-

kannt. Hier wird zu jedem Suchergebnis eine kurze Zusammenfassung geliefert (sie-

he Abbildung 2.2).19

2.4.2 Message Understanding Conference

Für Entstehung und Weiterentwicklung einiger IE-Systeme waren die Message

Understanding Conferences (MUC) ein wichtiger Meilenstein. Die Message

Understanding Conferences waren eine Reihe von Konferenzen die in den späten

1980er und frühen 1990er Jahren von der Defense Advanced Research Projects

Agency (DARPA20), einer Agentur des US-Amerikanischen Außenministeriums (die

unter anderem auch das Darpanet bzw. Arpanet entwickelte, den Vorgänger des

heutigen Internets), initiiert wurden. Auf diesen Konferenzen wurden Teams gebildet,

die sich mit der Extraktion bestimmter Informationen aus freiem, also unstrukturier-

tem Text beschäftigten. Um teilzunehmen mussten die Teams ein System erstellen,

das eine bestimmte Aufgabe lösen konnte. Die Leistung des Systems musste mess-

bar und mit anderen Systemen vergleichbar sein. Teilnehmer waren sowohl Unter-

nehmen als auch Universitäten.

Aufgabenstellung der 3. MUC (MUC-3), die 1991 stattfand, war es, Informationen,

die terroristische Aktivitäten beschreiben, aus Nachrichtenartikeln herauszufiltern und

19 vgl. Jac2007, S. 69 f.

20 vgl. DARPA

32


in eine Antwortenschablone zu übertragen. Diese Schablone bestand beispielsweise

aus folgenden Feldern:

● Id der Nachricht

● Datum der Aktivität

● Art der Aktivität

● Täter

● physisches Ziel

● menschliches Ziel

● Instrument

● Ort der Aktivität

Die besten Systeme der MUC-3 erzielten einen Recall von 50% und eine Precision

von 60%. Auf der MUC-6 (1995), also vier Jahre später, wurde bereits ein Recall von

75% und eine Precision von ebenfalls 75% von den besten Systemen erzielt.21

2.4.3 Reguläre Ausdrücke und endliche Automaten

Reguläre Ausdrücke

Reguläre Ausdrücke (engl. regular expression, kurz: regex) stellen Hilfsmittel zur

Spezifizierung oder Definition von regulären Sprachen bereit. Im einfachsten Fall re-

präsentiert ein regulärer Ausdruck einen regulären Satz von Zeichenketten unter Zu-

hilfenahme von drei einfachen Operationen: Aneinanderreihung, Wiederholung und

Alternative. Der reguläre Ausdruck a(b|c)*a repräsentiert beispielsweise die unendli-

che Sprache oder den Satz von Zeichenketten: L = {aa, aba, aca, abba, abca, acba,

acca, ...} Dabei bedeutet der Ausdruck (b|c) „b oder c“ und das Sternchen „*“ steht für

keine, eine oder mehrere Wiederholungen.

Im Natural Language Processing setzen reguläre Ausdrücke üblicherweise nach dem

Tokenisieren und dem grammatischen Bestimmen der einzelnen Wörter ein. In die-

21 vgl. Jac2007, S. 70 ff.

33


sem Fall besteht bei den regulären Ausdrücken schon ein bestimmter semantischer

Bezug. Man wird bei unterschiedlichen Themengebieten unterschiedliche reguläre

Ausdrücke vorfinden.22

Endliche Automaten und reguläre Sprachen

Ein endlicher Automat (engl. Finite State Machine, kurz: FSM) ist ein idealisiertes

Verhaltensmodell, in dem es eine beliebig große, jedoch klar definierte Anzahl von

Zuständen gibt. Die internen Zustände werden durch Zustandsübergänge gewech-

selt. Ein Zustandsübergang geschieht – dem theoretischen Modell nach – ohne Ver-

zögerung. Diese Automaten werden „endlich“ genannt, da die Menge der Zustände,

die sie annehmen können, endlich ist. Man kann sie daher auch aufzählen oder auf-

zeichnen. Ein endlicher Automat speichert keine Informationen über vergangene Zu-

stände und Zustandsänderungen.

Endliche Automaten beherrschen die Bearbeitung gewisser formaler Sprachen. Da-

bei können sie nicht alle Arten von formalen Sprachen bearbeiten sondern nur einige

Sprachen, die man demnach reguläre Sprachen nennt. Charakteristisch für diese

Sprachen ist, dass sie reguläre Ausdrücke enthalten. Reguläre Sprachen sind Spra-

22 vgl. Jac2007, S. 73 ff.

34

Abbildung 2.5: Ein endlicher Automat als Diagramm für a(b|c)*a

s1 s2 s3

a a

b,cÜbergänge

Zustände


chen, in denen die Position eines Symbols innerhalb einer Zeichenkette nur von ei-

ner begrenzten Anzahl vorangegangener Positionen abhängt. Diese linguistische

Vorgabe beschreibt noch einmal die Endlichkeit des Automaten, also dass es nur

eine endliche Anzahl von Zuständen gibt. Ein alltägliches Beispiel für eine nicht regu-

läre Sprache ist XML, denn ein XML-Dokument beinhaltet auch rekursive Strukturen.

Endliche Automaten können sowohl als Zustandsübergangsdiagramme als auch als

Übergangstabellen dargestellt werden. Dabei gibt es immer einen Startzustand und

einen Endzustand des Automaten, also einen Zustand, in dem begonnen wird, wenn

das System betreten wird und einen Zustand, der Voraussetzung für das Verlassen

des Systems ist.23

Überganga b c

Zustands1 s2

s2 s3 s2 s2

s3

Tabelle 2.1: Ein endlicher Automat als Tabelle für a(b|c)*a

Endliche Automaten als Parser

Der Linguist Noam Chomsky hat gezeigt, dass natürliche Sprachen keine regulären

Sprachen (wie z. B. Programmiersprachen) sind, da sie eingebettete oder sich über-

kreuzende Strukturen enthalten. Dennoch können endliche Automaten zu Extrakti-

onszwecken genutzt werden, da komplexere grammatische Strukturen häufig igno-

riert werden können (für formale Sprachen wäre diese „unscharfe“ Herangehenswei-

se nicht akzeptabel). Dazu werden Zeichenketten analysiert, um zu überprüfen, ob

sie den Regeln einer vorgegebenen Sprache entsprechen. In der Phase der

regulären Ausdrücke prüfen endliche Automaten, ob spezielle Nomen- und Verb-

gruppen in den Sätzen enthalten sind. In der daran anschließenden Phase des Scha-

23 vgl. Jac2007, S. 75 ff.

35


blonenausfüllens werden zuvor erkannte Muster in ein Formular geschrieben. So

sollten die Sätze

„Terrorists attacked the mayor‘s home in Bogota.“

„The mayor‘s Bogota home was attacked by terrorists.“

„The home of the mayor of Bogota suffered a terrorist attack.“

der Theorie nach die selbe Information in ein vordefiniertes Formular schreiben.

Endliche Automaten benutzen zur Erkennung und Extraktion wichtiger Informationen

Lexika, in denen verschiedene Wörter verschiedenen Wortgruppen zugeteilt werden.

Des Weiteren werden Muster wie das folgende benutzt:

PERP attacked HUMANTARGET‘s PHYSICALTARGET in LOCATION on DATE

with DEVICE

Ein Satz, der diesem Muster entspräche, wäre „Terrorists attacked the Mayor‘s home

in Bogota on Tuesday with grenades“, wobei in dem korrespondierenden Lexikon

das Wort „Terrorists“ der Wortgruppe PERP, die Wörter „the Mayor“ der Wortgruppe

HUMANTARGET usw. zugeordnet sein müssten. Um eine hohe Trefferquote zu er-

möglichen, muss dem System eine große Menge dieser Muster bekannt sein. Eben-

so sollte ein möglichst umfangreiches Lexikon zur Verfügung stehen.

Sätze wie „Heute Abend sprenge ich die Bank“ mit der Bedeutung „Heute Abend

gewinne ich im Casino“ können jedoch bei einer solchen Vorgehensweise falsch in-

terpretiert werden, was zeigt, dass diese Systeme recht fehleranfällig sind.24

2.4.4 Kellerautomaten und kontextfreie Grammatiken

Um ein stabileres Verfahren zum Parsen von Texten zu erreichen werden so ge-

nannte Kellerautomaten (engl. pushdown automaton, PDA) verwendet. Ein

Kellerautomat, auch Stackautomat oder Stackmaschine genannt, ist einem endlichen

Automat sehr ähnlich. Zusätzlich enthält er aber einen Speicher, der als Stack ver-

wendet wird. Dieser Speicher wird in der Theorie als unendlich betrachtet. Dies er-

24 vgl. Jac2007, S. 78 ff.

36


möglicht das Analysieren von kontextfreien Grammatiken, also Grammatiken die ein-

gebettete Strukturen enthalten. Kontextfreie Grammatiken können rekursiv definierte

Strukturen beinhalten, also Strukturen, die bei ihrer Definition auf die eigene Struktur

verweisen. Durch den zusätzlichen Speicher sind Stackautomaten im Gegensatz zu

endlichen Automaten in der Lage, rekursive Sprachen wie XML zu parsen. Eine No-

mengruppe könnte also definiert sein als Artikel + Nomen sowie als Nomengruppe +

Präposition + Nomengruppe. Demnach wären also korrekterweise alle folgenden

englischen Ausdrücke Nomengruppen: „the fiddler“, „the roof“ und „the fiddler on the

roof“25

2.4.5 Grenzen aktueller Technologien und zukünftige Forschung

So robust aktuelle Extraktsionssysteme sein mögen, gibt es dennoch einige Proble-

me, die sich bis heute nur schwer lösen lassen. So können viele unstrukturierte Tex-

te zwar syntaktisch korrekt analysiert werden, die Systeme wissen jedoch nichts von

der Bedeutung der Informationen, weder von der gesuchten noch von der tatsächlich

im Text enthaltenen. Aus diesem Grund können auch semantisch unsinnige Sätze

vom System als wichtig gedeutet werden. Ein Lösungsansatz hierfür sind semanti-

sche Grammatiken, die neben syntaktischer Regeln auch Untersuchungen semanti-

scher Strukturen durchführen.

Weiterhin wird es für Extraktionssysteme schwierig, sobald die nötige Information

nicht explizit vorliegt, sondern nur implizit gegeben ist. In einigen Texten werden

Schlussfolgerungen absichtlich nicht ausdrücklich formuliert, sondern dieser Schritt

wird dem Leser überlassen. Teilweise werden Fakten sogar bewusst vom Autor ver-

schleiert.

Auch die Weiterentwicklung einer Sprache, also das Entstehen neuer Wörter, ist für

IE-Systeme problematisch, da sie an sich nicht lernfähig sind.

Außerdem stellt man die Systeme vor größere Hürden, wenn Koreferenzen im Text

auftauchen. Also der Satz, der wichtige Informationen beinhaltet, enthält eine Refe-

25 vgl. Jac2007, S. 92 ff.

37


renz wie „die Firma“ oder „er“, während der eigentliche Name nur im vorangegange-

nen Satz auftaucht26.

Zusätzlich zu Systemen, die mit handgeschriebenen Regeln arbeiten, gibt es immer

mehr Verfahren, die sich auf lernfähige Algorithmen verlassen. Hierbei wird dem Sys-

tem ein annotierter Textkorpus bekannt gemacht. Anhand dieser Informationen wird

das System trainiert, welches versucht die Muster eigenständig zu generieren.27

2.5 Textkategorisierung

2.5.1 Was ist Textkategorisierung?

Textkategorisierungs-Systeme beschäftigen sich mit dem Einordnen von Dokumen-

ten in mehrere Kategorien. Oftmals wird unterschieden zwischen

Textkategorisierung, die das Sortieren von Dokumenten anhand des Inhalts be-

schreibt, und Textklassifizierung als breiteres Anwendungsgebiet, das jede Art von

Zuweisung von Dokumenten zu bestimmten Klassen beinhaltet, beispielsweise auch

anhand des Autors, des Herausgebers oder der Sprache des Dokuments. Im folgen-

den wird diese Unterscheidung nicht gemacht, die Begriffe werden synonym benutzt.

Es gibt verschiedene Kategorisierungs-Anwendungen, wobei sich zwei extreme Ver-

fahren gegenüber stehen. Auf der einen Seite gibt es ein ausschließlich manuelles

Verfahren, in dem eine oder mehrere Personen die zu klassifizierenden Texte sich-

ten und verschiedenen Kategorien zuordnen. Auf der anderen Seite steht ein kom-

plett automatisiertes System, welches die Dokumente ohne menschliches Zutun

gruppiert, die Gruppen benennt und in einem System von Kategorien arrangiert. In

der Realität wird man das zweite Extrem wahrscheinlich nie antreffen. Die meisten

Kategorisierungssysteme werden sicherlich an einem dazwischenliegenden Punkt

einzuordnen sein, wobei das erste Extrem (vollständig manuelle Klassifikation) auch

recht häufig anzutreffen ist.

26 vgl. SpiegelOnlineSynonyme

27 vgl. Jac2007, S. 104 ff.

38


Bei der Klassifizierung von Dokumenten gibt es unterschiedliche Schwierigkeitsgra-

de, sowohl für menschliche Bearbeiter als auch für automatisierte Systeme. Es gibt

einige signifikante Punkte, an denen man die Schwierigkeit der Kategorisierung an-

hand der Eigenschaften der zu kategorisierenden Daten festmachen kann.

● Granularität: Wie viele Kategorien gibt es und wie fein ist der Unterschied

zwischen den einzelnen Kategorien?

● Dimensionalität: Wie viele Merkmale werden zur Klassifizierung benutzt?

● Exklusivität: Gehört ein Dokument immer nur zu einer, zu einigen wenigen

oder zu sehr vielen Kategorien?

● Thematik: Behandelt ein Dokument typischerweise nur ein Thema oder meh-

rere?

Generell kann man sagen, dass der Schwierigkeitsgrad für ein technisches System

ansteigt, wenn er dies auch für den menschlichen Bearbeiter tut. Diese Problematik

dürfte denjenigen bekannt sein, die schon einmal versucht haben, ihre Bücher oder

DVDs nach Genres zu sortieren.

Bei der Evaluierung vorhandener Klassifizierungssysteme gibt es einige Punkte zu

beachten. Viele Systeme benötigen beispielsweise eine große Menge von bereits ka-

tegorisierten Trainingsdaten, die eventuell nicht zur Verfügung stehen könnte. Ande-

re Systeme könnten zum Beispiel gut mit einer Anzahl von 100 Klassen arbeiten,

während sie für 1.000 oder mehr Klassen nicht mehr geeignet sind. Dies könnte zum

einen daran liegen, dass die Rechenzeit zu hoch wird, oder aber auch daran, dass

der vom System verwendete Algorithmus bei einer so großen Anzahl von Kategorien

fehlerhaft arbeitet.28

2.5.2 Methoden basierend auf handgefertigten Regeln

Eine der einfachsten Methoden zur Klassifizierung von Dokumenten ist das manuelle

Erstellen eines Regelwerks. Dieses Regelwerk enthält Regeln nach dem Muster:

„Wenn der Text das Wort A oder das Wort B enthält, aber nicht das Wort C, dann

28 vgl. Jac2007, S. 113 ff.

39


ordne es in die Kategorie k ein.“ Mit einem sorgfältig erstellten, robusten Regelwerk

funktioniert diese Methode für eine kleine Anzahl disjunkter Kategorien sehr gut. Bei

einer größeren Menge von Daten ist das manuelle Erstellen eines solchen Regel-

werks jedoch nicht praktikabel, da vor allem die Pflege eines solchen Regelsystems

sehr aufwändig ist.29

Ein Beispiel für ein handgefertigtes Regelsystem in der Praxis sind Regeln, die man

für eingehende E-Mails bei Mailclients konfigurieren kann.

2.5.3 Klassifikationsverfahren mit maschinellem Lernen

Die Hauptalternative zu dem manuellen Verfassen von Regeln ist das Verwenden

unterschiedlicher Techniken des maschinellen Lernens, auch algorithmisches Lernen

genannt. Der gebräuchlichste Ansatz ist dabei ein so genanntes Programm des

29 vgl. Jac2007, S. 120 ff.

40

Abbildung 2.6: Outlook-Regeln


induktiven Lernens, das heißt, dass das Programm an sich kein Klassifikator ist, son-

dern fähig ist, Klassifikationsregeln vom Menschen anhand von Beispielen zu „ler-

nen“.

Es gibt einige Voraussetzungen für das Benutzen eines Maschinellen-Lern-

Verfahrens:

● Die Klassen, in welche die Dokumente eingeordnet werden, müssen vor der

Trainingsphase spezifiziert werden. Kommt zu einem späteren Zeitpunkt eine

Klasse hinzu, so muss das gesamte System neu trainiert werden.

● Im einfachsten Fall sollten diese Klassen disjunkt sein, dies entspricht jedoch

nicht immer den vorliegenden Verhältnissen, und führt unter Umständen zu

einer Nicht-Einsetzbarkeit dieses Verfahrens.

● Können die Klassen nicht disjunkt definiert werden, kann das Problem des

Klassifizierens in n Kategorien aufgeteilt werden in n Teilprobleme. Jedes

Teilproblem besteht darin, herauszufinden, ob ein Dokument der im jeweiligen

Teilproblem fokussierten Kategorie zuzuordnen ist oder nicht. Es wird also in

jedem Teilproblem eine binäre Entscheidungssituation geschaffen. Hierdurch

können jedoch Perfomanceprobleme auftreten, da 2n atomare Klassifikations-

vorgänge durchzuführen sind. Je nach Ausmaß von n kann das auch zu einer

praktisch überhaupt nicht berechenbaren Komplexität führen.

Lernprogramme arbeiten nicht mit den eigentlichen Texten, sondern, wie Information

Retrieval Systeme auch, mit Stellvertretern, zum Beispiel Vektoren, die die Merkmale

der Dokumente repräsentieren. Diese Vektoren sind häufig sehr hoch dimensioniert,

da es sich beispielsweise um die Häufigkeit des Auftretens eines Wortes handeln

kann, wobei jedes einzelne in allen Dokumenten auftretende Wort durch eine Dimen-

sion dargestellt wird.

Das Problem des maschinellen Lernens kann mit einem Problem aus der Analysis

verglichen werden. Dort gibt es Techniken, die aus einem vorgegebenen Satz von

Punkten x i und deren entsprechenden Werten y i versuchen, die mathematische

Funktion herzuleiten, welche die Relation ∮ x i , y am besten interpoliert. Sind die

41


Ergebniswerte endlich und diskret, so kann man das Problem auch als „Klassifikati-

on“ bezeichnen.30

Im folgenden werden einige der wichtigsten Techniken des maschinellen Lernens

vorgestellt.

Entscheidungsbäume

Die Idee der Entscheidungsbäume beruht auf einem einfachen Prinzip: das Merkmal,

das die größte Anzahl von Trainingsbeispielen unterscheidet, soll als erstes berück-

sichtigt werden. Die allgemeine Vorgehensweise zur Erstellung eines Entscheidungs-

baums sieht wie folgt aus:

1. Beginne beim Wurzelknoten

2. Finde das Attribut mit dem höchsten Informationsgewinn, das noch nicht in ei-

nem Vorfahrenknoten benutzt wurde

3. Füge für jeden möglichen Wert dieses Attributs einen Kindknoten ein

4. Ordne jedes Trainingsdokument dem Kindknoten zu, der den gleichen Attri-

butwert hat wie das Dokument

5. Wenn alle Trainingsdokumente eines Knotens einheitlich zu einer Kategorie

gehören, ordne diesem Knoten die entsprechende Kategorie zu und markiere

ihn als einen Blattknoten

6. Andernfalls gehe zurück zu Schritt zwei, falls noch mindestens ein nicht be-

nutztes Attribut existiert; wenn kein unbenutztes Attribut mehr existiert, ordne

dem Knoten die Kategorie zu, der die meisten der zugeordneten Beispiele an-

gehören

Der im zweiten Schritt verwendete Informationsgewinn wird berechnet, indem für je-

des Merkmal untersucht wird, wie viel Information für die Unterscheidung zwischen

verschiedenen Klassen gewonnen oder verloren wird, wenn dieses Merkmal nicht

berücksichtigt würde. Dazu wird zunächst der Informationswert der gesamten Menge

30 vgl. Jac2007, S. 122 f., Bas2005, S. 13 ff.

42


berechnet. Von dieser Größe wird dann der Informationswert der jeweiligen Teilmen-

gen subtrahiert, um den Informationsgewinn des berücksichtigten Attributs ai zu be-

rechnen.

Sei S die Menge aller Beispieldokumente, ai sei ein Attribut, das n Werte annehmen

kann und S1, ..., Sn seien die Teilmengen, in denen alle Dokumente die jeweilige Aus-

prägung (1..n) für das Attribut ai aufweisen. Der Informationsgewinn (gain) des Attri-

buts ai wird wie folgt berechnet:

gain a i=infoS −infoS1 ,... , S n

Zur Berechnung des Informationswerts (info) einer Menge wird der Logarithmus zur

Basis 2 (logarithmus dualis, ld) benutzt. Dabei wird die Anzahl der Dokumente, die zu

einer Kategorie gehören berücksichtigt. Sei |Cn| die Anzahl der zur Kategorie Cn ge-

hörenden Dokumente und |S| die Anzahl aller Dokumente in der Menge S, so wird

der Informationswert wie folgt berechnet:

infoS =−∣C1∣∣S∣

∗ld ∣C1∣∣S∣

...−∣Cn∣∣S∣

∗ld ∣Cn∣∣S∣

Den Informationswert mehrerer Mengen berechnet man durch eine gewichtete Addi-

tion.

infoS1 ,... , S n=∣S 1∣∗info S 1...∣Sn∣∗info S n

∣S1∣...∣S n∣

Nachdem nun für alle in Frage kommenden Attribute der Informationsgewinn berech-

net wurde, fällt die Entscheidung für das Attribut mit dem höchsten

Informationsgewinn. Dieses Attribut entspricht also dem Wurzelknoten, die Ausprä-

gungen, die das Attribut annehmen kann, den vom Wurzelknoten ausgehenden

Zweigen. Danach werden die Berechnungen für alle entstehenden Teilmengen und

deren mögliche Unterteilmengen wiederholt.

43


Beispiel:

Gegeben sei die folgende Tabelle, die Wetterdaten beinhaltet. In Abhängigkeit dieser

Daten wird entschieden, ob das Wetter geeignet ist, ein nicht näher spezifiziertes

Spiel zu spielen.

Aussicht Temperatur Luftfeuchtigkeit Wind Spielensonnig heiß hoch nein neinsonnig heiß hoch ja neinbewölkt heiß hoch nein ja

regnerisch mild hoch nein jaregnerisch kalt normal nein jaregnerisch kalt normal ja nein

bewölkt kalt normal ja jasonnig mild hoch nein neinsonnig kalt normal nein ja

regnerisch mild normal nein jasonnig mild normal ja jabewölkt mild hoch ja jabewölkt heiß normal nein ja

regnerisch mild hoch ja nein

Tabelle 2.2: Wetterdaten

Es wird nun der Informationsgewinn mittels der einzelnen Informationswerte für jedes

Attribut berechnet.

gain Aussicht =info[9,5]−info[2,3] ,[4,0] ,[3,2]=0,247

gain Temperatur =info [9,5]−info[2,2] ,[4,2] ,[3,1]=0,029

gain Luftfeuchtigkeit =info[9,5]−info[3,4] ,[6,1]=0,152

gain Wind =info [9,5]−info[6,2 ] , [3,3]=0,048

Die in den eckigen Klammern stehenden Zahlen stehen für die Anzahl der ja- bzw.

nein-Entscheidungen in der jeweilig betrachteten Menge. In der gesamten Menge

gibt es 9 ja- und 5 nein-Entscheidungen, ist die Aussicht sonnig, so gibt es 2 ja- und

3 nein-Entscheidungen usw.

44


Es wird also Aussicht als Entscheidungskriterium am Wurzelknoten gewählt.

Soll nun ein Dokument klassifiziert werden, wird zunächst der Wurzelknoten des

Entscheidungsbaums betrachtet. Jeder Knoten stellt einen Entscheidungspunkt dar,

an dem das Dokument auf ein Merkmal getestet wird und der Zweig ausgewählt wird,

der dem Wert des Merkmals entspricht. An einem Blattknoten angekommen, wird

das Dokument der Kategorie zugeordnet, die dem Blatt entspricht. Dabei kann es

mehrere Blätter geben, die einer Kategorie entsprechen, aber jedem Blatt ist exakt

eine Kategorie zugeordnet.31

Naive Bayes

Der Naive-Bayes-Algorithmus versucht Dokumente anhand verschiedener bedingter

Wahrscheinlichkeiten zu klassifizieren. Sei E ein Beispieldokument und {C1, ..., Cm}

sei eine Reihe von Kategorien, in die das Dokument eingeordnet werden soll. Beim

Naive-Bayes-Verfahren wird die Wahrscheinlichkeit berechnet, dass das Dokument

E zur Klasse Ci gehört, also P(Ci|E). Dazu wird die Formel

P C i∣E =∏k=1

n P f k∣C i∗P C iP f k

benutzt, wobei P(fk|Ci) die Wahrscheinlichkeit ist, dass ein Dokument der Klasse Ci

das Merkmal fk aufweist, P(Ci) die einfache Wahrscheinlichkeit ist, dass ein neu zu

klassifizierendes Dokument der Klasse Ci angehört und {f1, ..., fn} die Summe aller 31 vgl. Wit2001, S. 95 ff., Jac2007, S. 136 ff.

45

Abbildung 2.7: Baum für Aussicht

Aussicht

jaja

neinneinnein ja

jajaja

jajaja

neinnein

sonnig

bewölkt

regnerisch


Merkmale ist. P(fk) ist die allgemeine Wahrscheinlichkeit für das Merkmal fk und ist

weder vom Dokument E noch von der Kategorie Ci abhängig. Deshalb kann es aus

Gründen der Übersichtlichkeit bei der Berechnung ignoriert werden, wodurch sich die

vereinfachte Formel

P C i∣E =∏k=1

n

P f k∣C i∗P C i

ergibt, welche auch bei den unten stehenden Beispielberechnungen benutzt wird.

Zur Berechnung dieser Wahrscheinlichkeiten wird vorausgesetzt, dass dem System

bereits Trainingsdokumente und deren Kategorien bekannt gemacht wurden. P(Ci)

berechnet sich, indem man die Anzahl der Trainingsdokumente, die als Ci kategori-

siert wurden durch die Anzahl aller Trainingsdokumente teilt. Man kann P(fk|Ci) da-

durch berechnen, dass man die Anzahl der Dokumente der Kategorie Ci, die das

Merkmal fk enthalten, also nik, durch die Anzahl aller Dokumente der Kategorie Ci

teilt, also

P f k∣C i=nik

∣C i∣

Die Wahrscheinlichkeit P(Ci|E) wird für alle Kategorien {C1, ..., Cm} berechnet und das

Dokument wird letztendlich der Kategorie zugeordnet, bei der diese Wahrscheinlich-

keit am größten ist.

Als ein Beispiel für die Klassifikation mittels Naive Bayes wird angenommen, dass

Menschen anhand ihrer gesundheitlichen Verfassung in die Kategorien Allergie, Er-

kältung und Gesund eingeordnet werden. Die Merkmale, die betrachtet werden, sei-

en f1 = Schnupfen, f2 = Husten und f3 = Fieber. Zusätzlich werde angenommen, dass

die Wahrscheinlichkeiten in der folgenden Tabelle aus einer Datenbank abgeleitet

wurden, in der zu jedem Patienten die Merkmale f1, f2 und f3 annotiert wurden.

46


KategorieWahrscheinlichkeit Allergie Erkältung Gesund

P(Ci) 0,05 0,05 0,9

P(Schnupfen|Ci) 0,9 0,9 0,1

P(Husten|Ci) 0,7 0,8 0,1

P(Fieber|Ci) 0,4 0,7 0,01

Tabelle 2.3: Beispiel für eine Wahrscheinlichkeitsverteilung bei Naive Bayes

Ein Patient E leide nun unter Schnupfen und Husten aber nicht an Fieber. Somit kön-

nen folgende Berechnungen durchgeführt werden:

P Allergie∣E =0,05∗0,9∗0,7∗0,6=0,019

P Erkältung∣E =0,05∗0,9∗0,8∗0,3=0,01

P Gesund∣E =0,9∗0,1∗0,1∗0,99=0,0089

Der Patient sollte der Wahrscheinlichkeit nach also an einer Allergie leiden.

Ein Sonderfall kann auftreten, falls ein Merkmal fk in keinem Trainingsdokument der

Kategorie Ci vorhanden ist. Somit würde die Wahrscheinlichkeit P(fk|Ci) 0 sein. Dies

würde bedeuten, dass jedes Produkt, das mittels der Formel für P(E|Ci) berechnet

wird, 0 ist, sobald das Merkmal fk auftaucht, unabhängig davon wie groß die anderen

Wahrscheinlichkeiten sind. Man spricht in diesem Fall vom missing data problem.

Um dieses Problem zu lösen gibt es verschiedene Techniken. Die einfachste be-

zeichnet man als Laplace Smoothing. Die Idee dahinter ist, dass 0-Wahrscheinlich-

keiten durch sehr kleine Werte ersetzt werden, während alle anderen Wahrschein-

lichkeiten geringfügig reduziert werden.

Das oben genannte missing data problem kann beispielsweise auch dann auftreten,

wenn zum Trainieren des System ein Merkmal schlecht gewählt wurde. Das heißt

das System wurde anhand eines Merkmals trainiert, das in keiner Relation zur resul-

tierenden Klasse steht. Dieser Sachverhalt verdeutlicht die Problematik des sorgfälti-

gen Auswählens der zu berücksichtigen Merkmale. Würde beispielsweise in der

oben stehenden Tabelle noch das Merkmal f4 = wohlhabend aufgezeichnet, so würde

der gesamte Trainingserfolg gefährdet werden; denn offensichtlich hat die Tatsache,

47


dass ein Patient wohlhabend ist, nichts mit seinem Gesundheitszustand zu tun. Im

schlimmsten Fall befände sich in den Trainingsdaten kein wohlhabender Patient, wo-

durch die oben erwähnten 0-Wahrscheinlichkeiten auftreten würden.

Es gibt mehrere Varianten des Naive-Bayes-Algorithmus. Die oben genannten Bei-

spiele entsprechen dem so genannten Multivariate Model, in dem nur das Vorhan-

densein bzw. das Nichtvorhandensein einzelner Wörter berücksichtigt wird. Eine an-

dere Variante, das so genannte Multinomial Model, berücksichtigt hingegen auch die

Häufigkeit mit der diese Wörter auftreten.32

Nearest-Neighbor-Algorithmus

Während der Trainingsphase bei Entscheidungsbäumen und Naive Bayes werden

hauptsächlich Statistiken über die einzelnen Kategorien erzeugt. Das Nearest-

Neighbor-Verfahren verfolgt einen anderen Ansatz. Hier „merkt“ sich das System

während des Trainierens alle Trainingsdokumente und deren Merkmale. Wenn spä-

ter ein Dokument klassifiziert werden soll, werden die k Dokumente aus dem Trai-

ningsdatensatz selektiert, die dem zu klassifizierenden Dokument am „nächsten“

sind. Beim Nearest-Neighbor-Algorithmus stehen also nicht die Kategorien, sondern

die Dokumente im Fokus.

Um einen k-NN33 Klassifikator zu definieren, muss zunächst festgelegt werden, wel-

che Maßeinheit zur Messung des Abstandes zwischen den einzelnen Dokumenten

benutzt werden soll. Werden die Dokumente beispielsweise als multidimensionale

Vektoren gespeichert, wobei jedes Merkmal einer Dimension entspricht, so ist es

möglich, den Euklidischen Abstand zu benutzen. Beim Nearest-Neighbor-Verfahren

wird also die Kategorisierungsentscheidung nicht aufgrund einer stochastischen Aus-

wertung, sondern beispielsweise auf Basis einer geometrischen Distanz getroffen.

32 vgl. Bas2005, S. 17 ff., Jac2007, S. 123 ff.

33 k nearest neighbors, dt. k nächste Nachbarn

48


Um die Kategorie eines Dokumentes zu bestimmen, wird für jede Kategorie, die in-

nerhalb der k nächsten Nachbarn auftritt, ein Wert berechnet. Das Dokument wird

der Kategorie zugeordnet, deren Wert am größten ist. Die Berechnung geschieht bei-

spielsweise mittels der Formel:

ScC j , D = ∑Di∈Tr k D

similarity D , Di∗a

similarity(D, Di) ist das Ähnlichkeitsmaß zwischen den Dokumenten. Hier ist zu be-

achten, dass dieser Wert größer wird je ähnlicher sich die Dokumente sind. Gehört

das aktuell betrachtete Dokument Di der Klasse Cj an, so wird der Faktor a mit 1 ein-

gerechnet, andernfalls mit 0. Durch die Benutzung des Ähnlichkeitsmaßes wird nicht

nur berücksichtigt, wie viele der k nächsten Dokumente einer bestimmten Kategorie

angehören, sondern auch wie ähnlich sie dem zu klassifizierenden Dokument sind.

49

Abbildung 2.8: Beispiel für einen zweidimensionalen k-NN Klassifikator

Merkmal 1

Merkmal 2

Zu klassifizierendesDokument

Dokumente der Kategorie „blau“

Dokumente derKategorie „grün“

Dokumente derKategorie „gelb“


Die Größe von k wird hauptsächlich durch Erfahrungswerte bestimmt, sie hängt je-

doch im allgemeinen von den folgenden zwei Punkten ab:

● Wie nahe sind sich die unterschiedlichen Klassen innerhalb des Merkmals-

raums? Je näher sie sich sind, desto kleiner sollte k gewählt werden.

● Wie typisch sind die Trainingsdokumente für eine bestimmte Klasse? Falls es

sich um sehr heterogene Dokumente handelt, sollte k relativ groß gewählt

werden, damit die Auswahl repräsentativ ist.

Die Sensibilität der Größe von k wird durch Abbildung 2.8 verdeutlicht. Hier hängt die

resultierende Kategorie von der Größe von k ab (bei k = 2 wäre die resultierende Ka-

tegorie „grün“, bei k = 7 jedoch „gelb“).34

Support-Vector-Maschinen

Ist das Ziel des maschinellen Lernens das Herleiten einer binären Klassifizierungs-

funktion, so kann es sinnvoll sein mit Hyperebenen zu arbeiten. Einer der Vorteile

dieser mathematischen Objekte ist ihre Einfachheit, die es erlaubt, effiziente Lernal-

gorithmen zu definieren.

Bei Support-Vector-Maschinen werden die Trainingsdokumente anhand von n Merk-

malen als Punkte in einem n-dimensionalen Vektorraum abgebildet. Jedes Merkmal

entspricht dabei einer Dimension35. Es wird versucht eine (n-1)-dimensionale lineare

Funktion zu finden, also eine Hyperebene (beispielsweise eine Gerade oder eine

Ebene), die alle diese Punkte in zwei Gruppen unterteilt, wobei innerhalb einer Grup-

pe immer nur eine Kategorie vorhanden sein darf.

Um die Funktionsweise an einem Beispiel zu erläutern, wird angenommen, dass

zwei Merkmale berücksichtigt werden, es sich also um einen zweidimensionalen

Vektorraum handelt. Die Trainingsdokumente seien wie folgt im Vektorraum verteilt.

34 vgl. Jac2007, S. 144 ff.

35 Vergleichbar mit dem Nearest-Neighbor-Verfahren

50


Da es sich um einen binären Klassifikationsalgorithmus handelt, gibt es nur zwei Ka-

tegorien. Die Dokumente der ersten Kategorie werden in der Zeichnung als weiße

Punkte dargestellt, die Dokumente der zweiten Kategorie als schwarze Punkte. In

der Abbildung ist zu erkennen, dass es recht simpel ist, eine Gerade zu finden, die

die Dokumente der beiden Kategorien separiert.

Im nächsten Beispiel tritt jedoch ein Problem auf.

51

Abbildung 2.9: Linear trennbare Dokumentenvertei-

lung

Merkmal 2

Merkmal 1

Abbildung 2.10: Nicht linear trennbare Dokumen-

tenverteilung

Merkmal 2

Merkmal 1


Die Dokumente sind hier auf eine solche Weise im Vektorraum verteilt, dass sich kei-

ne lineare Funktion finden lässt, die als Seperator fungieren könnte.

In diesem Fall ist es möglich, ein neues Merkmal in den Klassifizierungsvorgang ein-

zubeziehen. Dadurch wird der Vektorraum dreidimensional und es könnte möglich

werden, die Dokumente mittels einer zweidimensionalen Ebene zu separieren.

Die Methode der Support-Vector-Maschinen stützt sich auf die Beobachtung, dass

das menschliche Gehirn mit einer ähnlichen Technik, den Neuronen, arbeitet. Dort

leiten Synapsen ein aufgenommenes Signal an das so genannte Soma weiter. Dabei

können sie es verstärken oder abschwächen. Wenn das Gesamtsignal, bestehend

aus mehreren Einzelsignalen von verschiedenen Synapsen, einen Schwellwert über-

steigt, leitet das Soma das Signal weiter.

Die künstliche Version eines Neurons wird oftmals als Perzeptron bezeichnet. Ein Si-

gnal x1 wird mit einer Gewichtung w1 belegt. Mehrere Produkte aus Gewichtungen

und Signalen werden zusammen addiert und wenn diese Summe größer ist als ein

Schwellwert b, so wird das Ergebnis y 1 sein, andernfalls wird es 0 sein.

Das Ergebnis eines solchen Neurons oder Perzeptrons kann durch eine Hyperebene

dargestellt werden, die der Gleichung

y=w1∗x1...wn∗xnb=w⋅xb=0

entspricht. Die endgültige Klassifikationsfunktion des Perzeptrons erhält man durch

Anwenden der Signum-Funktion auf y:

f x =sgn w⋅xb

Die Signum-Funktion bewirkt, dass die Punkte in zwei Gruppen aufgeteilt werden,

Punkte die über und Punkte die unter der Hyperebene liegen. Die Ergebniswerte der

Funktion sind dabei +1 bzw. -1.

Die Aufgabe des Lernalgorithmus ist es nun, den Vektor w und das Skalar b herzu-

leiten. Dabei werden die geometrischen Operationen Rotation und Translation be-

nutzt, wobei eine initiale Hyperebene solange angepasst wird, bis keine Fehler mehr

52


vorhanden sind, das heißt alle Dokumente einer Kategorie liegen auf der entspre-

chenden Seite der Ebene.36

2.6 Data Mining

In der heutigen Zeit werden Informationen immer wichtiger. Nicht umsonst sagt man,

wir leben in einer Informationsgesellschaft. Verschiedene Mitglieder dieser Gesell-

schaft – Personen, Firmen, Organisationen etc. – brauchen Informationen in großer

Menge. Leider sind diese Informationen häufig nicht explizit vorhanden, sondern nur

in ihrer Rohform als Daten. Bezeichnet man Daten als aufgezeichnete Fakten, so

kann man Informationen als die Menge von Mustern oder Erwartungen definieren,

die hinter diesen Daten stecken. Aufgabe des Data Mining ist es, diese Muster aus

den Daten zu extrahieren, also Informationen, die bis jetzt implizit in den Daten ver-

steckt waren, sichtbar zu machen.

Im Bereich des Data Mining werden Computerprogramme entwickelt, die Datenban-

ken nach Regelmäßigkeiten und Mustern durchforsten. Einige starke Muster werden

sich durchsetzen, andere werden sich als unwichtig oder sogar falsch herausstellen.

Falsche Muster können beispielsweise entstehen, wenn zufällige Koinzidenzen in der

aktuellen Datenmenge existieren, die keine wirkliche Regelmäßigkeit repräsentieren.

Haben sich einige Muster etabliert, so können sie eingesetzt werden, um Vorhersa-

gen über zukünftige Daten zu treffen. Bei den zu durchforstenden Daten handelt es

sich z. B. um Logdateien, Zahlenkolonnen aus Simulationen, Berechnungen oder

Messungen, und vieles mehr.

Technologisch stützt sich Data Mining, wie Textkategorisierung auch, auf Algorith-

men des maschinellen Lernens (siehe Kapitel 2.5.3). Anders als bei der Textkategori-

sierung müssen beim Data Mining jedoch keine Merkmale mehr aus einem natürli-

chen Text extrahiert werden. Zwar müssen beim Data Mining die Daten auch noch

zur weiteren Verarbeitung aufbereitet werden, dies ist allerdings nicht so aufwändig

wie der Vorgang der Merkmalsextraktion bei der Textklassifizierung. Es gilt lediglich,

die Daten in eine für das System verarbeitbare Form umzuwandeln und gegebenen-

36 vgl. Bas2005, S. 30 ff.

53


falls fehlende bzw. unendliche Werte zu ersetzen oder überflüssige Merkmale zu lö-

schen. Ein weiterer Unterschied ist, dass es beim Data Mining eine größere Menge

an Arten des Lernens gibt als bei der Textkategorisierung. Dies zeigt die folgende

Tabelle.

Art des Lernens BeschreibungKlassifizierendes Lernen Ein Lernverfahren nimmt eine Menge bereits klassifizierter Bei-

spiele entgegen, aus denen es lernen soll, unbekannte Bei-

spiele zu klassifizieren. Diese Art des Lernens existiert auch

bei der Textkategorisierung.

Assoziierendes Lernen Es werden alle Assoziationen zwischen den Attributen berück-

sichtigt, also auch jene zwischen den verschiedenen Inputva-

riablen und nicht nur diejenigen, die einen bestimmten Klas-

senwert voraussagen.

Clustering Es werden Gruppen von zusammengehörigen Beispielen ge-

sucht.

Numerische Vorhersage Das vorhergesagte Ergebnis ist keine diskrete Klasse, sondern

eine numerische Größe.

Tabelle 2.4: Arten des Lernens bei Data Mining

Wie schon erwähnt gilt es beim Data Mining zunächst die vorhandenen Daten aufzu-

bereiten. Dazu gehört die Ersetzung von fehlenden oder unendlichen Werten, die Eli-

minierung von überflüssigen Merkmalen, die Normalisierung der Daten und das

Überführen der Daten in eine vom jeweiligen System verarbeitbare Form (z. B. das

ARFF-Format37). Danach wird die Art des Lernens und das zu verwendende Verfah-

ren gewählt. Als Ergebnis erhält man eine Repräsentation des gelernten Wissens,

die Art dieser Repräsentation ist abhängig vom gewählten Lernverfahren. Es kann

sich beispielsweise um einen Entscheidungsbaum oder auch um einen durch ein

Diagramm dargestellten Cluster handeln. Unabhängig von der Art der Repräsenation

kann diese verwendet werden, um Aussagen über neue, unbekannte Daten zu tref-

fen.38

37 vgl. ARFF

38 vgl. Wit2001, S. XII ff., S. 1 ff.

54

2.7 Text Mining

2.7 Text Mining

Im Gegensatz zu Data Mining beschäftigt sich das Text Mining nicht mit strukturier-

ten Daten, wie sie beispielsweise in einer Datenbank vorliegen, sondern mit unstruk-

turierten Daten in Form von Texten. Im Zeitalter des Internets liegt ein Großteil der

Informationen in ebensolchen unstrukturierten Texten vor. Text Mining bezeichnet

computergestützte Verfahren für die semantische Analyse von Texten, welche die

automatische bzw. semi-automatische Strukturierung von Texten unterstützen. Data

Mining und Text Mining haben also eine ähnliche, wenn nicht sogar identische Ziel-

setzung. Lediglich die Ausgangssituation ist unterschiedlich. Während beim Data

Mining davon ausgegangen wird, dass die Informationen bereits strukturiert sind,

muss der Vorgang des Strukturierens beim Text Mining erst noch durchgeführt wer-

den. Dazu werden unterschiedliche Arten von Texten (beispielsweise Freitexte,

HTML-Dateien oder XML-Dateien) in eine Textdatenbank eingespeist und dann sta-

tistisch und linguistisch analysiert.39

39 vgl. Hey2006, S.1 ff.

55

Abbildung 2.11: Ablaufschema des Text Mining

Text

HTML

ASCII

XML

...

TextDB

StatistischeAnalyse

LinguistischeAnalyse

Text-eingabe

Speicher-ebene

Statistische &Linguistische Analyse Anwendungen

Clustering

Klassifikation

Indizierung

Termextraktion

Visualisierung


2.8 Semantic Web

Das Internet ist die größte, frei zugängliche Informationsquelle der heutigen Zeit. Der

menschliche Benutzer ist jedoch noch zum größten Teil selbst für die Informations-

aufbereitung, Analyse und Interpretation zuständig. Deshalb können auch schon klei-

nere Recherchen eine große Zeitdauer beanspruchen. Die Problematik ist, dass das

die Daten speichernde Medium diese nicht interpretieren kann. Es kann ihnen keine

Bedeutung beimessen.

Es entstand nun die Idee40, die Inhalte des Internet semantisch anzureichern, sodass

sie nicht nur für den Menschen verständlich sind, sondern auch bis zu einem gewis-

sen Grad41 von Maschinen erfasst werden können. Diese Anreicherung soll durch

Metadaten realisiert werden. Im Semantic Web werden die Metadaten häufig mittels

RDF42 organisiert und strukturiert. Somit ist die Basis für den Einsatz von

Domänenontologien geschaffen. Das Konzept der Ontologien wurde entwickelt, um

das Wissen einer Domäne formal repräsentieren zu können. Ontologien beschreiben

Konzepte und ihre Beziehungen untereinander im Bereich einer Wissensdomäne.

Eine detailliertere Beschreibung der Konzepte des Semantic Web kann aufgrund des

beschränkten Rahmens der Diplomarbeit an dieser Stelle nicht erfolgen. Für den Fo-

kus dieser Arbeit ist es jedoch wichtig zu wissen, dass das Semantic Web größten-

teils noch eine Vision ist. Zwar existieren schon einige Konzepte, die aber nur in eini -

gen wenigen Fällen schon in die Realität umgesetzt wurden. Außerdem beschreiben

diese Konzepte zum größten Teil die Art der Informationsrepräsentation im Internet

und weniger die Repräsentationsart von Informationen in Kontaktaufnahmen, bei-

spielsweise E-Mails. Es ist nicht davon auszugehen, dass es in näherer Zukunft sol-

che Konzepte für Kontaktaufnahmen geben wird und dass jeder Kontaktpartner diese

Konzepte kennt und umsetzt.43

40 Tim Berners Lee, der als Erfinder des Internet gilt, hat einen großen Teil zur Entstehung dieser

Idee beigetragen.

41 Der Grad ist beliebig und hängt nur von der Energie ab, die man bereit ist zu investieren.

42 vgl. RDF

43 vgl. Pel2006, S. 1 f., S.11 ff.

56

2.9 Zusammenfassung aktueller Technologien


Technologie Vorgehensweise Vor- / Nachteile AnwendungsideenInformation Retrie-valAuffinden von Doku-

menten, die für eine

gestellte Anfrage re-

levant sind

• Erstellen einer logi-

schen Sicht auf alle

Dokumente

• Indizieren der Do-

kumente

• Bei Anfragen Such-

vorgang über Index

+ Sehr etablierte und er-

forschte Technologie

- Benutzer muss Abfrage-

sprache erlernen

- Relevanz kann benut-

zerabhängig sein

• Meßgrößen wie

Precision und Re-

call können zur

Evaluierung des

Systems benutzt

werden

Natural Language ProcessingMaschinelle Verar-

beitung natürlicher

Texte mit verschiede-

nen Zielen: z. B. In-

formationsgewinnung

und Kategorisierung

• Satzabgrenzung

und Tokenisierung

• Stammbildung und

Markierung

• Nomenphrasierung

und Namenserken-

nung

+ Automatisierte Verarbei-

tung von Freitexten

+ Es existieren bereits

viele Frameworks oder

Toolkits

- Erstellen von Systemen

ist zeit- und arbeitsauf-

wändig

- Trotz langjähriger Ent-

wicklung und Forschung

existiert kein System,

das zu 100% korrekt ar-

beitet

- Systeme arbeiten häufig

nur mit einer Sprache

(meistens englisch)

• Verarbeitung von

Freitextfeldern in

Formularen oder

Emailtexten

Information Extrac-tionExtrahieren von In-

formationen, die eine

vorgegebene Thema-

tik behandeln, aus

natürlichen Texten

Es gibt unterschiedliche

Ansätze: Endliche Auto-

maten, Reguläre Aus-

drücke, Kellerautomaten

+ Recht einfache Methode

um Freitexte automa-

tisch zu verarbeiten

- Systeme können Texte

nicht semantisch verste-

hen

- Informationen können

implizit vorliegen

• Verarbeitung von

Freitextfeldern in

Formularen oder

Emailtexten

TextkategorisierungEinordnen von Doku-

menten in Kategorien

Die einzelnen Vorge-

hensweisen werden im

folgenden zusammen-

+ Arbeitsintensiver Vor-

gang des Kategorisie-

rens wird stark automa-

• Kategorisierung

von Freitexten

• Auswertung der

57


Technologie Vorgehensweise Vor- / Nachteile Anwendungsideenanhand des Inhalts gefasst tisiert

- Kategorisierung teilwei-

se sogar für den Men-

schen schwierig

- Qualität eines Systems

kann auch von der An-

zahl der zu kategorisie-

renden Dokumenten ab-

hängen

einzelnen Regeln

und Erstellung der

endgültigen Kate-

gorisierung

Handgefertigte Re-

geln

Regeln werden von

Hand erstellt

+ Erstellung recht simpel

- Nicht praktikabel für

größere Datenmengen

• Kategorisierung

von Freitexten

• Auswertung der

einzelnen Regeln

und Erstellung der

endgültigen Kate-

gorisierung

Entscheidungsbäu-

me

• Erstellen eines

Baumes

• An der Wurzel steht

das Merkmal, das

die Trainingsbei-

spiele am besten

unterscheidet

• Nach unten hin

werden Merkmale

immer „unwichtiger“

• Blattknoten reprä-

sentieren Kategori-

en

+ Erstellen des Baumes

relativ einfacher Algo-

rithmus

- Nicht sehr präzise

• Kategorisierung

von Freitexten

• Auswertung der

einzelnen Regeln

und Erstellung der

endgültigen Kate-

gorisierung

Naive Bayes • Berechnung ver-

schiedener Wahr-

scheinlich-keiten

• Zuordnung des Do-

kuments zu der Ka-

tegorie, zu der es

+ Relativ einfacher Algo-

rithmus

- Benötigt relativ große

Menge von Trainigsda-

ten

- Relativ hohe Fehlerquo-

• Kategorisierung

von Freitexten

• Auswertung der

einzelnen Regeln

und Erstellung der

endgültigen Kate-

58


Technologie Vorgehensweise Vor- / Nachteile Anwendungsideenmit der größten

Wahrscheinlichkeit

gehört

te

- Auswahl der zu berück-

sichtigen Merkmale ist

kritisch

gorisierung

Nächste-Nach-

barn-Algorithmus

• Merkmale werden

im Vektorraum re-

präsentiert

• Zuordnung des Do-

kuments zu der

Klasse, der die

meisten der k

nächsten Nachbarn

angehören

+ Relativ präzise Klassifi-

zierung

- Benötigt relativ große

Menge von Trainingsda-

ten

- Festlegung der Größe

von k ist entscheidend

• Kategorisierung

von Freitexten

• Auswertung der

einzelnen Regeln

und Erstellung der

endgültigen Kate-

gorisierung

Support-Vector-Ma-

schinen

Suche einer linearen

Funktion, die die im

Vektorraum verteilten

Dokumente in zwei Ka-

tegorien teilt

+ Relativ präzise Klassifi-

zierung

- Nur binäre Klassifizie-

rung

- Dimensionalität des

Vektorraums muss aus-

reichend sein um Doku-

mente trennen zu kön-

nen

• Kategorisierung

von Freitexten

• Auswertung der

einzelnen Regeln

und Erstellung der

endgültigen Kate-

gorisierung

Data MiningImplizite Informatio-

nen aus Daten extra-

hieren

• Aufbereitung der

Daten

• Anwendung ver-

schiedener Lernal-

gorithmen

+ Sehr vielfältige Anwen-

dungsgebiete

+ Es existiert eine Vielzahl

von Bibliotheken, Fra-

meworks oder Toolkits

- Qualität des Ergebnis-

ses hängt von der Qua-

lität des Lernalgorith-

mus ab

• Sichtbar machen

von bislang nicht

wahrgenommenen

Zusammenhängen

Text MiningImplizite Informatio-

nen aus Texten ex-

trahieren

Kombination aus Natu-

ral Language Proces-

sing und Data Mining

Verfahren

+ Sehr vielfältige Anwen-

dungsgebiete

+ Sehr umfassende Tech-

nik

• Extraktion von In-

formationen aus

Freitexten

59


Technologie Vorgehensweise Vor- / Nachteile Anwendungsideen- Hohe Komplexität

- Schwierigkeiten bei

Mehrsprachigkeit

Semantic WebSemantische Anrei-

cherung der Inhalte

des Internets

Annotation der Daten

mittels RDF

+ Sehr weitreichender,

durchdachter Ansatz

+ Computer lernen die

Bedeutung von Wörtern

- Bis jetzt nur Vision

- Bis jetzt nur für Daten

des Internets, nicht für

E-Mail-Kommunikation

-

Tabelle 2.5: Zusammenfassung aktueller Technologien

60

3 Aktuelle Softwareprodukte

3 Aktuelle Softwareprodukte

In diesem Kapitel werden verschiedene Softwareprodukte vorgestellt.

Im ersten Unterkapitel werden Softwareprodukte beschrieben, die die gleiche oder

eine ähnliche Aufgabenstellung haben wie PEACE, oder die eine von PEACE zu be-

arbeitende Teilaufgabe lösen.

Softwareprodukte, die eine untergeordnete Aufgabe lösen, also beispielsweise be-

stimmte Bibliotheken, die in PEACE integriert wurden, werden im zweiten Unterkapi-

tel beschrieben.

3.1 Thematisch verwandte Softwareprodukte

In diesem Kapitel werden einige Softwareprodukte aus den Bereichen Natural

Language Processing, Data Mining oder angrenzenden Gebieten vorgestellt.

Grundsätzlich könnten diese Programme als Alternative zu PEACE angesehen wer-

den. Sie lösen jedoch nur Teilaufgaben, während PEACE eine umfassendere Aufga-

benstellung in Bezug auf die Thematik der Klassifikation von Kontaktanfragen hat.

Deshalb wäre es auch möglich, diese Produkte in eine spätere Version von PEACE

zu integrieren, um die jeweilige Aufgabe an das Produkt zu delegieren.

Viele der hier beschriebenen Produkte sind bereits sehr ausgereift, jedoch haben sie

auch größtenteils einige Schwachstellen. Aus diesem Grund wurde auch zunächst

darauf verzichtet, sie in PEACE zu integrieren, da vor der Integration eine detaillierte-

re Evaluierung hätte stattfinden müssen, die im zeitlich begrenzten Rahmen der Di-

plomarbeit nicht möglich war.

3.1.1 Weka

Weka1 („Waikato Environment for Knowledge Analysis“) ist eine Sammlung verschie-

dener maschineller Lernalgorithmen in Java, die zu Data Mining-Zwecken genutzt

werden können. Dabei gibt es zwei Möglichkeiten, die Algorithmen anzuwenden.

1 vgl. Weka

61

Kapitel 3: Aktuelle Softwareprodukte

Zum einen können sie direkt auf bestimmte Daten angewendet werden. Dazu wird

die grafische Oberfläche (z. B. die Explorer-GUI) von Weka verwendet. Hier können

Daten unterschiedlichen Formats ausgewertet werden. Mögliche Formate sind

ARFF2 (bzw. XRFF, eine XML-basierte Erweiterung von ARFF), CSV oder auch Da-

ten aus einer Datenbank. Zum anderen können die Algorithmen aus eigenem Java-

Code heraus aufgerufen werden.

Weka umfasst Werkzeuge zur Datenvorbereitung, zur Klassifizierung und Regressi-

onsanalyse3, zur Clusteranalyse4, zur Auswahl von Merkmalen und zur Visualisie-

2 vgl. ARFF

3 Regressionsanalyse ist ein statistisches Analyseverfahren, bei dem versucht wird, Beziehungen

zwischen Variablen herzustellen.

4 Clusteranalyse ist ein Analyseverfahren, bei dem versucht wird Gruppen von Objekten mit ähnli-

chen Eigenschaften zu ermitteln.

62

Abbildung 3.1: Die Explorer-GUI von Weka


rung. Des Weiteren kann Weka genutzt werden, um neue maschinelle Lernverfahren

zu entwickeln.

Die ursprüngliche Version von Weka, deren Entwicklung 1993 an der Universität

Waikato in Neuseeland begann, wurde in Tcl/Tk und C programmiert und sollte ei-

gentlich zur Analyse von Daten aus dem landwirtschaftlichen Bereich dienen. 1997

wurde die Entscheidung getroffen, Weka in Java neu zu programmieren. Im Jahr

2005 erhielt Weka den „SIGKDD Award“ („Special Interest Group Knowledge

Discovery and Data Mining").5

Bei WEKA handelt es sich um eine sehr komplexe Software, die nicht speziell für die

automatisierte Klassifizierung von Kontaktanfragen erstellt wurde. Aus diesem Grund

eignet sie sich nicht sehr gut für diesen Zweck. Die Bedienung ist gerade für ungeüb-

te Benutzer recht schwer zu erlernen; ein Kriterium, was eine Software zur automati-

5 vgl. WekaDoc

63

Abbildung 3.2: Visualisierung der aus Kapitel bekannten Wetterdaten


sierten Klassifizierung nach Meinung des Autors unbedingt erfüllen sollte, denn die

Bearbeitung von Kontaktanfragen ist eine sehr allgemeine Aufgabenstellung, die

nicht nur von Benutzern mit bestimmten Kenntnissen durchgeführt wird.

3.1.2 RapidMiner

RapidMiner6 ist eine Software aus den Bereichen maschinelles Lernen und Data

Mining. Dabei können aus einer großen Anzahl von Operatoren einige heraus ge-

sucht, kombiniert und auf Daten angewendet werden. Diese Kombination von Opera-

toren geschieht über eine grafische Oberfläche, die interne Speicherstruktur ist XML,

sodass ein standardisiertes Datenaustauschformat für Data Mining Prozesse gesi-

chert ist. Wie Weka kann auch RapidMiner sowohl als eigenständige Anwendung

laufen, als auch mittels einer API in eigene Programme integriert werden.

RapidMiner wurde 2001 unter dem Namen YALE („Yet Another Learning

Environment“) vom Lehrstuhl für künstliche Intelligenz der Universität Dortmund ent-

wickelt. Das Projekt wurde 2004 in RapidMiner umbenannt und wird zur Zeit von der

Firma Rapid-I7 betreut.

RapidMiner wird unter verschiedenen Lizenzen veröffentlicht, unter anderem auch

unter einer GPL („General Public License“).

Die Operatoren, die in RapidMiner nahezu beliebig kombinierbar sind, decken folgen-

de Bereiche ab:

● Ein- und Ausgabe: Die Daten können in unterschiedlichen Formaten (z. B.

ARFF8, CSV, Excel-Tabellen, Datenbanken, etc.) eingelesen und ausgege-

ben werden.

● Modellierung: In RapidMiner existieren verschiedene Verfahren für Regressi-

on, Klassifikation und unüberwachtes Lernen, unter anderem auch Support-

Vector-Maschinen, Entscheidungsbäume und verschiedene Bayes'sche Algo-

rithmen.

6 vgl. RapidMiner

7 vgl. Rapid-I

8 vgl. ARFF

64


● Weka Operatoren: Sämtliche Lernverfahren aus Weka sind in RapidMiner in-

tegriert.

● Vorverarbeitung: RapidMiner gibt die Möglichkeit, die Daten vor der eigentli-

chen Verarbeitung zu manipulieren. Dazu existieren verschiedene Verfahren

wie z. B. das Normalisieren, das Ersetzen fehlender oder unendlicher Werte

oder das Löschen überflüssiger Merkmale.

● Merkmalsoperatoren: RapidMiner hält mehrere Operatoren zur Bearbeitung

von Merkmalen bereit, beispielsweise die Merkmalsauswahl und die Merk-

malsgewichtung.

● Evaluation: Die Data Mining-Prozesse können in RapidMiner auch evaluiert

werden. Mögliche Merkmale sind z. B. Precision und Recall.

65

Abbildung 3.3: Beispiel einer Visualisierung in RapidMiner


● Meta-Operatoren: Zusätzlich existieren Operatoren die den Data Mining-Pro-

zess selbst optimieren.

● Visualisierung: RapidMiner bietet ebenfalls die Möglichkeit die Ergebnisse

grafisch zu präsentieren.9

RapidMiner ist, ebenso wie WEKA, eine sehr komplexe Software und nicht speziell

für den Zweck des Themas dieser Arbeit geschaffen worden. Deshalb bietet es sich

nicht für die Klassifizierung von Kontaktanfragen an. Zudem richten RapidMiner und

WEKA den Fokus auf Data Mining, was ja nur einen Teil des Prozesses der automa-

tisierten Klassifizierung von Kontaktanfragen darstellt.

3.1.3 GATE

GATE10 („General Architecture for Text Engineering“) ist ein Textanalyse-Framework,

das an der University of Sheffield entwickelt wurde. GATE kann als eigenständiges

Programm laufen, das eine grafische Oberfläche enthält, in der man verschiedene

Wort-Annotatoren testen kann. Daneben beinhaltet es auch ein Java-Framework, so-

dass man es in eigene Projekte integrieren kann. GATE unterliegt der General Public

License.

GATE ist aus mehreren Teilsystemen aufgebaut, die größtenteils in zwei Arten von

Komponenten unterteilt werden können: die Language Resources (LRs) und die

Processing Resorces (PRs).

LRs repräsentieren ein sprachliches Hintergrundwissen des Programms. Hier sind

verschieden Lexika und Dokumentkorpora enthalten.

PRs stellen die Algorithmik bei der Verarbeitung der natürlichen Sprache dar, es han-

delt sich hierbei also um Tokenizer oder um Satzabgrenzer und um ähnliche Kompo-

nenten.

9 vgl. RapicMinerDoc

10 vgl. GATE

66


GATE ist so aufgebaut, dass LRs und PRs unabhängig von einander eingesetzt und

kombiniert werden können, dazu müssen die implementierten Klassen lediglich die

Konformität zu den in der GATE-API spezifizierten Interfaces sicher stellen.11

GATE ist speziell für den Zweck der Textanalyse, die nur einen Teil des Prozesses

zur automatisierten Klassifizierung von Kontaktanfragen darstellt, geschaffen. Die

Qualität des Frameworks PEACE könnte durch eine Integration dieser Software ver-

bessert werden, als Standalone-Programm würde GATE jedoch nicht den gewünsch-

ten Zweck erfüllen.

3.1.4 UIMA

UIMA12 („Unstructered Information Management Architecture“) wurde von der Firma

IBM13 („International Business Machines Corporation“) entwickelt. Es handelt sich da-

bei um ein Java-Framework, das zur Analyse unstrukturierter Texte eingesetzt wer-

den kann.

Von der Architektur her ist UIMA der oben genannten Software GATE sehr ähnlich.

Auch hier gibt es mehrere Teilkomponenten aus zwei verschiedenen Bereichen. Zum

einen gibt es Text Analysis Engines (TAEs), die in etwa den PRs von GATE entspre-

chen. Es handelt sich also um Module, die sich mit der Verarbeitung natürlicher

Sprache befassen. Diese zunächst atomaren TAEs können aggregiert werden, so-

dass höherwertige TAEs entstehen.

Die LRs von GATE entsprechen bei UIMA in etwa den Common Analysis Systems

(CASs). Sie stellen das sprachliche Hintergrundwissen des Systems in Form von Le-

xika oder ähnlicher Datenstrukturen dar.

Das UIMA-Framework unterstützt neben Java auch C++. Es ist kostenlos erhältlich,

wobei ein Teil der TAEs käuflich erworben werden muss.14

11 vgl. ix0709132

12 vgl. UIMA

13 vgl. IBM

14 vgl. ix0709132

67


Ebenso wie GATE erfüllt auch UIMA nur einen Teil des in dieser Arbeit fokussierten

Zwecks.

3.1.5 OpenNLP

OpenNLP15 ist eine als Open Source erhältliche Kollektion verschiedener Komponen-

ten zur Textanalyse. Dabei ist OpenNLP kein zusammenhängendes Framework son-

dern eine lose Ansammlung mehrerer Werkzeuge. Alle Werkzeuge basieren auf sta-

tistisch gelernten Modellen, die für die englische und teilweise auch für die spanische

Sprache vorliegen. Um eine Unterstützung für die deutsche Sprache zu erreichen,

müsste ein neues Modell erstellt werden. Dies kann erreicht werden, indem man

einen annotierten Dokumentenkorpus erzeugt, d. h. Textdokumente, die mit Annota-

tionen versehen sind, die die einzelnen grammatischen Einheiten identifizieren, und

diesen den Systemen zum Lernen zur Verfügung stellt.

Neben den eigentlichen OpenNLP-Projekten wird auf der Homepage von OpenNLP

auch noch auf andere Open Source Projekte, die sich mit der Verarbeitung natürli -

cher Sprache beschäftigen, verwiesen. Darunter ist beispielsweise auch WEKA zu

finden.16

Wie schon weiter oben erwähnt, ist die Textanalyse nur ein Teil der gewünschten

Funktionalität der im Rahmen dieser Arbeit entwickelten Software. Die in OpenNLP

gesammelten Softwarekomponenten eignen sich daher nur als in PEACE zu integrie-

rende Module, nicht jedoch als Gesamtlösung der Aufgabenstellung.

3.1.6 RIPROCON-CHECK

RIPROCON-CHECK17 („Risikoorientiertes Projekt-Controlling“) ist ein Softwaresys-

tem, das kleine und mittelständische Unternehmen mit einer auftragsorientierten Fer-

tigung bei der Risikobewertung von Aufträgen, also bei der betrieblichen Risikosteue-

rung, unterstützt.

15 vgl. OpenNLP

16 vgl. ix0709132, OpenNLP

17 vgl. RIPROCON

68


Es unterscheidet sich von den anderen hier vorgestellten Softwareprodukten haupt-

sächlich dadurch, dass es den betriebswirtschaftlichen Aspekt von Aufträgen, vor al-

lem das Auftragsrisiko, bewertet. Es ist speziell auf diesen Anwendungsfall zuge-

schnitten. Eine automatische Klassifizierung von Aufträgen findet nicht statt, vielmehr

müssen die Kennzahlen per Hand in eine Maske eingetragen werden. Diese werden

ausgewertet und das Auftragsrisiko wird durch eine Ampel symbolisch dargestellt.

69

Abbildung 3.4: RIPROCON: Kennzahlen und Ampel

Abbildung 3.5: RIPROCON: Eingabe von Risikoänderungen


Der zu bewertende Auftrag muss im System zunächst angelegt werden. Diesem Auf-

trag werden eine Standardkostenstruktur und Risikofaktoren zugeordnet. Es können

Standard-Schemata angelegt werden, um den Erfassungsaufwand von Neuaufträgen

zu reduzieren. Das individuelle Auftragsrisiko wird errechnet, indem der Benutzer die

Risikoänderungen des jeweiligen Auftrags zu einem Standardauftrag angibt. Dies ge-

schieht mittels einer speziellen Maske, die die einzelnen Risikoklassen faktorenweise

durchläuft.

RIPROCON-CHECK ist also eine wesentlich speziellere Software als alle anderen

hier vorgestellten. Sie ist auf den Anwendungsfall der betrieblichen Risikosteuerung

zugeschnitten. Damit deckt sie auch einen der Anwendungsfälle von PEACE ab, wo-

bei sich die Herangehensweise sehr von der von PEACE unterscheidet und weniger

automatisiert ist.18

3.2 In PEACE integrierte Softwareprodukte

Die hier vorgestellten Softwareprodukte sind Bibliotheken, die untergeordnete Aufga-

ben übernehmen, d. h. atomare Aufgaben, die auf einem technischen Niveau stattfin-

den und keinen fachlichen Bezug haben.

3.2.1 JDOM

JDOM19 ist eine Bibliothek, die das Parsen und Validieren von XML-Dokumenten in

Java erlaubt. Intern werden XML-Dokumente mittels des Document Object Models

(DOM) repräsentiert, von dem sich auch der Name ableitet.

3.2.2 Xerces Java Parser

Der Xerces Java Parser20 erweitert JDOM um die Funktionalität des Validierens ge-

gen XML-Schemata. JDOM selbst kann nur gegen DTDs (Document Type Definition)

validieren. XML-Schemata bieten jedoch die Möglichkeit, die Struktur von XML-Doku-

18 vgl. RIPROCONDoc

19 vgl. JDOM

20 vgl. Xerces

70

3.2 In PEACE integrierte Softwareprodukte

menten sehr viel präziser vorzugeben, beispielsweise kann ein konkreter Typ (Zei-

chenkette, Ganzzahl, Fließkommazahl, etc.) für bestimmte Inhalte festgelegt werden.

Aus diesem Grund wurde neben JDOM auch der Xerces Java Parser in PEACE inte-

griert.

71

4 PEACE - Konzeption und Implementierung

4 PEACE - Konzeption und Implementierung

In diesem Kapitel wird das Konzept und die Implementierung des Frameworks be-

schrieben. Der erste Abschnitt beinhaltet einige grundsätzliche Erläuterungen. Im

zweiten Teil wird die Architektur der Software anhand eines beispielhaften Pro-

grammdurchlaufs dargestellt und erläutert. Im dritten Teil folgt eine detailliertere Be-

schreibung der Paket- bzw. Klassenstruktur. Der vierte Teil behandelt die XML-Sche-

ma-Dateien. Im fünften und letzten Teil dieses Kapitels werden die bereits in das Fra-

mework integrierten Regeln beschrieben.

4.1 Allgemeines

In diesem Abschnitt werden zunächst einige Fachbegriffe sowie der grobe Pro-

grammablauf erläutert, um dem Leser ein Grundwissen zu vermitteln, das das Ver-

ständnis dieses technischen Kapitels erleichtern soll.

Bei PEACE existieren drei unterschiedliche Arten von Daten: Konfigurationsdaten,

Eingabe- bzw. Inputdaten, sowie Ausgabe- bzw. Outputdaten. Sie alle sind XML-ba-

siert und müssen dem jeweiligen XML-Schema (peace_config.xsd, peace_input.xsd,

peace_output.xsd) entsprechen.

Die Konfigurationsdaten werden vom Benutzer in Form einer XML-Datei erstellt. Hier

werden die vom System zur Verfügung gestellten Regeln miteinander kombiniert. Da

eine Regel Parameter erwarten kann, muss hier spezifiziert werden, aus welcher

Quelle die erwarteten Parameter stammen. Dabei kann es sich um einfache (skalare)

Parameter, als auch um Dictionaries handeln. Dictionaries sind Listen die Na-

me-Wert-Paare beinhalten. Bei der Quelle eines Parameters kann es sich um einen

lokalen konstanten Wert, einen globalen konstanten Wert, einen von einer in der

Hierarchie höher liegenden Regel weitergeleiteten Wert, sowie um den Wert eines

Feldes der Inputdatei handeln. Dictionaries können generell aus den gleichen Quel-

len stammen, jedoch nicht aus einer Inputdatei.

73

Kapitel 4: PEACE - Konzeption und Implementierung

Eine kombinierte Regel verknüpft verschiedene andere Regeln, bei denen es sich

wiederum um kombinierte Regeln, als auch um atomare (d. h. vom System bereit ge-

stellte) Regeln handeln kann. Dies geschieht, indem sie die zu kombinierenden Re-

geln aufruft und dabei spezifiziert, aus welcher Quelle die von der jeweiligen Regel

erwarteten Parameter oder Dictionaries stammen. Es ist zu beachten, dass der

Rückgabewert einer Regel bei einem solchen Aufruf auf den Wertebereich 0 bis 1

normalisiert wird. Dies betrifft nur numerische Regeln, also Regeln mit einem numeri-

schen Rückgabetyp. Der Vorgang der Verknüpfung ist vergleichbar mit dem Aufruf

von Untermethoden aus Methoden in der prozeduralen oder objektorientierten Pro-

grammierung und dient der Modularisierung.

Weiterhin werden in der Konfigurationsdatei die so genannten Workflows spezifiziert.

Bei einem Workflow handelt es sich um die Repräsentation eines bei einer Kon-

taktanfrage zu beachtenden Aspekts, beispielsweise der Professionalität der Anfra-

ge. Ein Workflow besteht aus einem eindeutigen Namen und einer Einstiegsregel.

Das Auswertungsergebnis dieser Einstiegsregel stellt gleichzeitig das Ergebnis des

Workflows dar. Eine solche Regel darf keine Parameter oder Dictionaries erwarten,

da diese Werte nicht von einem Workflow übergeben werden können. In der unten

vorgestellten Beispielanwendung (siehe Kapitel 5.3) existieren beispielsweise die

Workflows „Professionality“ (Professionalität der Kontaktanfrage),

„CommunicationSkill“ (Kommunikationsfähigkeit des Kontaktpartners), „Success“ (Er-

folgswahrscheinlichkeit), „Morality“ (moralische Aspekte) und „Urgency“ (Dringlich-

keit).

Wird einer Regel ein erwarteter Parameter bzw. ein erwartetes Dictionary nicht über-

geben, so liefert das Framework eine Fehlermeldung und die Auswertung einer Kon-

taktanfrage wird abgebrochen. Die erwarteten Parameter und Dictionaries werden

von dem Programmierer einer Regel spezifiziert, denn es ist nötig, dass diese Werte

während der Laufzeit des Programms zur Verfügung stehen. Das entspricht in etwa

der Deklaration einer Variablen in einer statischen, typsicheren Programmiersprache

wie Java oder C.

74

4.1 Allgemeines

Die Inputdaten werden vom Benutzer ebenfalls in Form von XML-Dateien erstellt. Bei

einer Inputdatei handelt es sich um die Repräsentation einer Kontaktanfrage. Diese

wird in verschiedene Felder aufgeteilt (z. B. Name, Vorname, E-Mailadresse etc.),

welche die entsprechenden Werte enthalten.

Die Outputdaten werden vom Framework automatisch erstellt und stellen die Aus-

wertung einer Kontaktanfrage dar.

In einem realen Anwendungsszenario (siehe Kapitel 5.4) werden die Input- und Out-

putdateien erwartungsgemäß nicht vom Anwender direkt erstellt bzw. gelesen. Wird

das Framework beispielsweise auf einem Mailserver eingesetzt, so ist dieser Server

verantwortlich für das Erzeugen der Inputdateien und das Interpretieren der Output-

dateien. Die Input- und Outputdateien stellen also nur die Schnittstelle des Systems

dar und nicht die Art und Weise, wie der Anwender in der Realität auf dieses zugreift.

4.2 Architektur des Frameworks

Durch die recht große Anzahl von Klassen ist es nicht praktikabel, ein Klassendia-

gramm darzustellen, welches die gesamte Architektur des Frameworks beinhaltet.

Aus diesem Grund werden an dieser Stelle verschiedene kleinere Klassendiagram-

me aufgeführt, anhand derer die Architektur beschrieben wird. Die Diagramme sind

dabei nach funktionalen Aufgaben unterteilt und es wird anhand eines beispielhaften

Programmdurchlaufs die Funktionsweise des Frameworks erläutert.

4.2.1 Einstiegspunkte

Es existieren mehrere Möglichkeiten, auf die Funktionalität von PEACE zuzugreifen.

Diese Möglichkeiten werden durch die verschiedenen öffentlichen Methoden der

Klasse eworks.peace.PEACE realisiert.

Die möglichen Methoden lauten:

● public static void main(String[] args)

● public static void setConfigFile(String fileName) in Kombination mit

75


○ public static void evaluate(String inputFileName) oder

○ public static void evaluate(String inputFileName, Writer writer) oder

○ public static Document evaluateAndGetDocument(String inputFileName)

Die genaue Funktionsweise der einzelnen Methoden ist dem Kapitel zu entnehmen.

Unabhängig von der gewählten Methode muss der Benutzer zunächst eine Konfigu-

rationsdatei spezifizieren. Diese wird validiert und geparst. Für das Parsen erstellt

das Programm eine Instanz der Klasse ConfigManager. Diese erzeugt zunächst alle

globalen Parameter und Dictionaries. Danach werden alle Regeln erzeugt, wobei

verschiedene Kriterien überprüft werden, beispielsweise, ob einer Regel alle benötig-

76

Abbildung 4.1: Klassendiagramm: Einstiegspunkte


ten Parameter und Dictionaries übergeben werden. Die erzeugte Regel-Struktur wird

in einer Hashtable gespeichert. Ist die Erstellung aller Regeln erfolgreich abgeschlos-

sen, werden die Workflows erstellt. Auch hier werden bestimmte Voraussetzungen

geprüft. Die Workflows werden nach erfolgreicher Erstellung ebenfalls in einer

Hashtable gespeichert.

Traten während der Verarbeitung der Konfigurationsdatei Fehler auf, so wird das

Programm an dieser Stelle abgebrochen und eine entsprechende Fehlermeldung

wird ausgegeben. Konnte die Konfigurationsdatei vollständig verarbeitet werden, so

wird mit der Abarbeitung der Inputdateien begonnen.

Eine Inputdatei wird mittels einer Instanz der Klasse InputManager geparst. Für jede

Inputdatei wird das Attribut outputManager der Klasse PEACE mit einer neuen In-

stanz der Klasse OutputManager initialisiert. Nach der Verarbeitung einer Inputdatei

gibt es verschiedene Möglichkeiten, wie der Output an den Benutzer bzw. das umlie-

gende Programm weitergeleitet wird. Die Art der Weitergabe wird durch die gewählte

Einstiegsmethode spezifiziert.

4.2.2 Verarbeitung der Konfigurationsdatei

77


Dem ConfigManager wird beim Initialisieren der Dateipfad einer Konfigurationsdatei

mitgegeben. Diese Datei wird geparst und anhand der in der Datei gemachten Anga-

ben wird die Regelstruktur erstellt.

Zunächst werden die in der Datei deklarierten globalen Parameter und Dictionaries

erstellt und in einer Hashtable gespeichert.

Danach werden die Regeln gemäß der XML-Struktur instantiiert. Die Regeln werden

ebenfalls in einer Hashtable gespeichert. Es wird jedoch nur die jeweilige Top-Level-

Rule abgespeichert. Innerhalb der Konfigurationsdatei erkennt man diese Regeln an

dem Tag „Rule“. Es sind die einzigen Regeln die einen Namen spezifizieren. Die dar-

unter liegenden Regeln werden über eine Baumstruktur referenziert. Dazu wird die

Klasse RuleContainer und davon abgeleitete Klassen benutzt. Ein Instanz von

RuleContainer stellt einen Container dar, der eine oder mehrere Regeln umschließt.

Es kann sich dabei beispielsweise um die konkrete Klasse RuleAddition handeln, die

78

Abbildung 4.2: Klassendiagramm: Konfigurationsverarbeitung


mehrere numerische Regeln kombiniert, indem sie deren Ergebnisse addiert. Ein

weiteres Beispiel für einen solchen Container ist die Klasse RuleApplied, bzw. deren

konkrete Unterklassen RuleAppliedNumeric, RuleAppliedBoolean und

RuleAppliedString. Eine Instanz von RuleApplied wendet eine konkrete Regel an und

verwaltet deren Parameter. Bei der Regel kann es sich entweder um eine per XML

deklarierte Top-Level-Rule handeln oder aber um eine der Java-Klassen, in der eine

konkrete Regellogik implementiert wurde. Da die RuleApplied-Klassen die einzigen

Klassen sind, die Parameter verwalten können, sind diese beiden Arten von Regeln

(Top-Level-Rules und Java-Klassen) die einzigen, die Parameter deklarieren, also

von der aufrufenden Instanz verlangen dürfen. Weitere Beispiele für RuleContainer

sind RuleMultiplication, RuleConcatenation, RuleConjunction, RuleDisjunction,

RuleNumericComparison und RuleStringComparison.

Beim Aufbau der Regel-Struktur werden einige Kriterien überprüft. So müssen aufge-

rufene Regeln, unabhängig davon ob es sich um Top-Level-Rules oder Java-Klassen

handelt, verfügbar sein. Alle von einer aufgerufenen Regel als benötigt deklarierten

Parameter müssen übergeben werden. Sind alle Kriterien erfüllt und wurde der ge-

samte Regel-Teil der Konfigurationsdatei erfolgreich verarbeitet, so beginnt die Ver-

arbeitung der Workflows.

Die Verarbeitung der Workflows ist wesentlich simpler als die der Regeln. Ein

Workflow spezifiziert lediglich einen Namen und einen Einstiegspunkt ins Regelwerk.

Dieser Einstiegspunkt ist eine Top-Level-Rule, die keine Parameter erwarten darf. Ist

die Verarbeitung der Workflows ebenfalls erfolgreich abgeschlossen, so ist das Par-

sen der Konfigurationsdatei beendet und die Auswertung einer Inputdatei kann be-

ginnen.

4.2.3 Verarbeitung der Inputdateien

Die Daten einer Inputdatei werden von einer Instanz der Klasse InputManager ver-

waltet. Durch eine Abwandlung des Singleton-Musters ist sichergestellt, das zu je-

dem Zeitpunkt nur genau eine Instanz dieser Klasse existiert. Diese Instanz ist global

verfügbar, d. h. auf die Daten kann aus jeder beliebigen Klasse heraus zugegriffen

79


werden. Dies vereinfacht den Vorgang der Regelauswertung, so dass nur zwei

Schritte notwendig sind, um das Verarbeiten einer neuen Inputdatei zu veranlassen:

1. Die Klasse InputManager wird mit einer neuen Inputdatei1 instantiiert.

2. Die Methode processWorkflows() eines Objekts der Klasse ConfigManager

wird aufgerufen. Dieser Methode muss zusätzlich noch ein neu instantiiertes

Objekt der Klasse OutputManager übergeben werden. In diesem werden die

Ergebnisse gespeichert und es kann nach der Regelauswertung weiter verar-

beitet werden2.

Diese Schritte geschehen in der Klasse eworks.peace.PEACE. Nach der Verarbei-

tung der letzten Inputdatei ist der Programmablauf beendet.

4.3 Beschreibung einzelner Pakete und Klassen

4.3.1 Das Paket eworks.peace

Dieses Paket stellt den Einstiegspunkt in das Framework dar und enthält einige Klas-

sen, die das Parsen der Input- bzw. Konfigurationsdateien übernehmen.

1 Repräsentiert durch ein JDOM-Document.

2 Im einfachsten Fall wird das Ergebnis in die Standardausgabe geschrieben.

80


Die Klasse PEACE

Diese Klasse stellt den Einstiegspunkt ins Framework dar. Hier befindet sich die

main-Methode des Programms, also jene Methode, die aufgerufen wird, wenn das

Framework über die Kommandozeile ausgeführt wird.

Eine weitere Möglichkeit, das Framework anzusprechen, ist, es in ein anderes Java-

Projekt zu importieren. In diesem Fall bietet diese Klasse einige weitere Methoden

zur komfortableren Steuerung der Abläufe.

In jedem Fall muss dem Framework aber zumindest eine Konfigurationsdatei mitge-

geben werden, egal ob es über die Kommandozeile oder per Methodenaufruf ange-

steuert wird. Es wäre hier denkbar, zukünftig noch weitere Methoden anzubieten, um

beispielsweise die Konfiguration aus einer Datenbank zu lesen.

Die möglichen Einstiegsmethoden sind die folgenden:

● public static void main(String[] args)

Dies ist die Methode, die ausgeführt wird, wenn das Framework über die

Kommandozeile aufgerufen wird. Es muss mindestens ein Argument überge-

81

Abbildung 4.3: Klassenhierarchie eworks.peace


ben werden. Dieses spezifiziert die Konfigurationsdatei (bzw. deren Namen).

Alle anderen Argumente werden als Inputdateien (bzw. deren Namen) inter-

pretiert und der Reihe nach ausgewertet (d. h. wenn kein weiteres Argument

angegeben ist, findet keine Auswertung statt). Die Ausgabe erfolgt auf der

Standardausgabe.

● public static void setConfigFile(String fileName)

Wird das Framework in ein anderes Java-Projekt importiert, so kann diese

Methode aufgerufen werden, um dem Framework die aktuelle Konfigurations-

datei mitzuteilen. Diese Methode muss mindestens einmal erfolgreich aufge-

rufen worden sein, bevor eine der drei folgenden Methoden aufgerufen wer-

den kann.

● public static void evaluate(String inputFileName)

Diese Methode wertet die übergebene Inputdatei anhand der aktuellen Konfi-

gurationsdatei (muss mittels setConfigFile() gesetzt worden sein) aus. Die

Ausgabe erfolgt auf der Kommandozeile.

● public static void evaluate(String inputFileName, Writer writer)


gurationsdatei (muss mittels setConfigFile() gesetzt worden sein) aus. Die

Ausgabe wird in den übergebenen Writer geschrieben, der vom aufrufenden

Programm beliebig weiter verarbeitet werden kann.

● public static Document evaluateAndGetDocument(String

inputFileName)


gurationsdatei (muss mittels setConfigFile() gesetzt worden sein) aus. Das

zurückgegebene Document (aus dem Paket org.jdom der JDOM-Bibliothek)

enthält die gesamte Ausgabe als XML-Dokument.

82


Die Klasse ConfigManager

Diese Klasse parst die Konfigurationsdatei und prüft sie auf XML-Validität und einige

weitere, PEACE-spezifische Kriterien. Auf Programmebene ist die Klasse

ConfigManager die Repräsentation der Konfigurationsdatei und dient dazu, die in der

Datei definierten Regeln auf einen Input anzuwenden.

Die Klasse InputManager

Diese Klasse parst die Inputdatei und prüft sie auf Validität. Sie repräsentiert diese

Datei und wird einer Instanz des ConfigManager übergeben, damit dessen Regeln

auf die Daten der Inputdatei angewendet werden.

Die Klasse OutputManager

Diese Klasse wird benutzt um die Ausgabe als XML aufzubauen. Dabei wird auf

JDOM zurückgegriffen. Je nach Konfiguration können die XML-Daten auf der Stan-

dardausgabe ausgegeben, in eine Datei geschrieben oder als Rückgabewert für eine

Methode benutzt werden.

4.3.2 Das Paket eworks.peace.exceptions

Dieses Paket stellt spezielle Fehlerklassen bereit. Die Fehler, die behandelt werden,

sind spezifisch für PEACE und können beispielsweise beim Parsen von XML-Dateien

oder bei der Verarbeitung auftreten. Alle hier genannten Fehlerklassen leiten von

java.lang.Exception ab.

Die Klasse ConfigManagerNotInstantiatedException

Diese Exception wird geworfen, wenn versucht wird auf eine Instanz des

ConfigManagers zuzugreifen, diese Klasse aber noch nicht instanziiert wurde.

83


Die Klasse DictionaryHasWrongTypeException

Diese Exception wird geworfen, wenn einer Regel ein Dictionary übergeben wird,

dessen Typ nicht mit dem zugesicherten Typ übereinstimmt.

Die Klasse DictionaryIsNullException

Diese Exception wird geworfen, wenn einer Regel ein Dictionary übergeben wird, das

null ist.

Die Klasse DictionaryNotFoundException

Diese Exception wird geworfen, wenn versucht wird auf ein Dictionary zuzugreifen,

das nicht gefunden werden kann.

Die Klasse DictionaryPointerReferredToNullException

Diese Exception wird geworfen, wenn ein DictionaryPointer erzeugt wird und die re-

ferenzierte Regel null ist.

Die Klasse DictionaryTypeNotAssertedException

Diese Exception wird geworfen, wenn versucht wird, auf ein Dictionary mit einem be-

stimmten Typ zuzugreifen, dem Dictionary aber ein anderer bzw. kein Typ zugesi-

chert wurde.

Die Klasse InputFieldNotFoundException

Diese Exception wird geworfen, wenn ein Parameter ein bestimmtes Inputfeld refe-

renziert, dieses aber im aktuellen Input nicht gefunden werden kann.

Die Klasse InputManagerNotInstantiatedException

Diese Exception wird geworfen, wenn versucht wird, auf eine Instanz des

InputManagers zuzugreifen, diese Klasse aber noch nicht instanziiert wurde.

84


Die Klasse MissingParamsException

Diese Exception wird geworfen, wenn Parameter an eine Regel übergeben werden

und festgestellt wird, dass diese Regel weitere, nicht in den übergebenen Parame-

tern enthaltene benötigt.

Die Klasse OperatorNotDefinedException

Diese Exception wird geworfen, wenn versucht wird, einen nicht definierten Ver-

gleichsoperator einer Vergleichsregel zu übergeben.

Die Klasse ParamIsNullException

Diese Exception wird geworfen, wenn ein Parameter an eine Regel übergeben wird,

dieser aber null ist.

Die Klasse ParamHasWrongTypeException

Diese Exception wird geworfen, wenn einer Regel ein Parameter übergeben wird,

dessen Typ nicht mit dem zugesicherten Typ übereinstimmt.

Die Klasse ParamNotFoundException

Diese Exception wird geworfen, wenn versucht wird, auf einen nicht zugewiesenen

Parameter zuzugreifen.

Die Klasse ParamPointerReferredToNullException

ParamPointer sind Parameter, die an sich keinen Wert haben. Sie verweisen auf

einen Parameter einer ihnen übergebenen anderen Regel. Diese Exception wird ge-

worfen, wenn dem ParameterPointer „null" anstatt einer Regel übergeben wird.

85


Die Klasse ParamsNotSettedException

Diese Exception wird geworfen, wenn versucht wird, eine Regel auszuwerten, ob-

wohl die Parameter dieser Regel noch nicht gesetzt wurden. Jeder Regel müssen

Parameter übergeben werden, bevor deren Auswertung erfolgen kann.

Die Klasse ParamTypeNotAssertedException

Diese Exception wird geworfen, wenn versucht wird auf einen Parameter mit einem

bestimmten Typ zuzugreifen, dem Parameter aber ein anderer bzw. kein Typ zugesi-

chert wurde.

Die Klasse WorkflowCouldNotFindRuleException

Diese Exception wird geworfen, wenn die einem Workflow als Einstiegspunkt überge-

bene Regel nicht gefunden werden kann.

Die Klasse XMLSchemaNotFoundException

Diese Exception wird geworfen, wenn versucht wird eine XML-Datei zu validieren,

die zugehörige Schemadatei aber nicht gefunden wird.

4.3.3 Das Paket eworks.peace.rules

Dieses Paket enthält die eigentlichen Regelklassen. Diese Klassen werden dyna-

misch erzeugt, der Name der Klasse wird aus der Konfigurationsdatei ausgelesen

und mittels Class.forName(NameDerKlasse).newInstance() eine neue Instanz er-

stellt. Eventuell sollte man zukünftig noch Sicherheitsvorkehrungen einbauen, damit

hier nicht jede beliebige Klasse instanziiert werden kann.

Jede hier erstellte Klasse leitet von der Basisklasse eworks.peace.rules.core.Rule ab

und implementiert genau eines der Interfaces, die den Rückgabetyp spezifizieren

(z. B. eworks.peace.rules.core.IRuleNumeric).

Die Beschreibung dieser Regelklassen ist sehr speziell und wird deshalb in einem ei-

genen Kapitel (Kapitel 4.5) durchgeführt.

86


4.3.4 Das Paket eworks.peace.rules.core

In diesem Paket befindet sich die gesamte von PEACE bereitgestellte Logik zur

Kombination, Verschachtelung und Auswertung von Regeln. Des Weiteren existieren

hier die Basisklasse für alle Regeln sowie Interfaces, die von neu erstellten Regeln

implementiert werden müssen.

87

Abbildung 4.4: Klassenhierarchie eworks.peace.rules.core


Das Interface IRuleBoolean

Eine Regelklasse, die dieses Interface implementiert, zeigt an, dass sie bei der Aus-

wertung einen Rückgabewert vom Typ Boolean hat.

Das Interface IRuleNumeric


wertung einen Rückgabewert vom Typ Number hat.

Das Interface IRuleString


wertung einen Rückgabewert vom Typ String hat.

Die Klasse Rule

Dies ist die Basisklasse für alle Regeln. Sie verwaltet die Parameter und prüft vor der

Auswertung ob diese vollständig sind.

Die Methode zur Auswertung heißt proceed. Diese prüft zunächst welches der den

Rückgabetyp spezifizierenden Interfaces implementiert wurde und ruft dann die ent-

sprechende Methode auf. Es darf dabei derzeit jeweils nur ein Interface implemen-

tiert sein. Es ist jedoch denkbar, dass eine Regel zukünftig mehrere Rückgabetypen

besitzt, wobei der jeweils aktuell benötigte von der aufrufenden Instanz spezifiziert

werden kann.

Die Klasse RuleContainer

Abgeleitet von Rule

Dies ist eine Basisklasse für alle Regeln, die keine eigene Fachlogik beinhalten, son-

dern andere Regel-Ergebnisse arithmetisch oder kombinatorisch verrechnen. Diese

Regeln sind daher domänenunabhängig.

88


Die Klasse RuleContainerBoolean

Abgeleitet von RuleContainer, implementiert IRuleBoolean

Diese Klasse beinhaltet eine andere Regel, die den Rückgabetyp Boolean hat und

leitet deren Ergebnis bei der Auswertung weiter.

Des Weiteren kann sie abgeleitet werden um mehrere Regeln zu kombinieren, wobei

der Rückgabetyp der kombinierten Regeln irrelevant ist, solange die Container-Regel

einen Wert vom Typ Boolean zurück gibt.

Die Klasse RuleContainerNumeric

Abgeleitet von RuleContainer, implementiert IRuleNumeric

Diese Klasse beinhaltet eine andere Regel, die den Rückgabetyp Number hat und

leitet deren Ergebnis bei der Auswertung weiter.



einen Wert vom Typ Number zurück gibt.

Die Klasse RuleContainerString

Abgeleitet von RuleContainer, implementiert IRuleString

Diese Klasse beinhaltet eine andere Regel, die den Rückgabetyp String hat und leitet

deren Ergebnis bei der Auswertung weiter.



einen Wert vom Typ String zurück gibt.

Die Klasse RuleConjunction

Abgeleitet von RuleContainerBoolean

Diese Klasse beinhaltet mehrere andere Regeln mit dem Rückgabetyp Boolean und

kombiniert deren Auswertungsergebnis mit dem booleschen Operator UND.

89


Die Klasse RuleDisjunction

Abgeleitet von RuleContainerBoolean

Diese Klasse beinhaltet mehrere andere Regeln mit dem Rückgabetyp Boolean und

kombiniert deren Auswertungsergebnis mit dem booleschen Operator ODER.

Die Klasse RuleComparison

Abgeleitet von RuleContainer, implementiert IRuleBoolean

Dies ist eine Basisklasse für Vergleiche zwischen zwei oder mehreren Werten. Der

Rückgabetyp ist Boolean.

Die Klasse RuleNumericComparison

Abgeleitet von RuleComparison

Diese Klasse vergleicht zwei numerische Werte mittels verschiedener Operatoren,

beispielsweise „größer“, „größer gleich“, „kleiner“ etc.

Die Klasse RuleStringComparison

Abgeleitet von RuleComparison

Diese Klasse vergleicht zwei Zeichenketten mittels verschiedener Operatoren, bei-

spielsweise „gleich“ oder „ungleich“.

Die Klasse RuleAddition

Abgeleitet von RuleContainerNumeric

Diese Klasse addiert mehrere numerische Werte.

Die Klasse RuleMultiplication

Abgeleitet von RuleContainerNumeric

Diese Klasse multipliziert mehrere numerische Werte.

90


Die Klasse RuleApplied

Abgeleitet von RuleContainer

Diese Klasse verwaltet eine konkrete Regel und deren Parameter und führt diese

Regel zur gegebenen Zeit aus. Es wird überprüft, ob alle von der verwalteten Regel

erwarteten Parameter verfügbar sind. Vor dem Ausführen werden diese Parameter

der Regel übergeben. Es handelt sich um eine abstrakte Klasse, es muss also eine

der drei folgenden von dieser Klasse ableitenden Klassen instanziiert werden.

Die Klasse RuleAppliedBoolean

Abgeleitet von RuleApplied, implementiert IRuleBoolean

Diese Klasse wertet eine boolesche Regel aus.

Die Klasse RuleAppliedNumeric

Abgeleitet von RuleApplied, implementiert IRuleNumeric

Diese Klasse wertet eine numerische Regel aus und führt evtl. weitere anstehende

Berechnungen durch. So kann zu dem Auswertungsergebnis ein Wert addiert, multi -

pliziert oder das Ergebnis mit einem Exponent potenziert werden. Dabei wird immer

die mathematisch schwächere Operation zuerst ausgeführt, also zuerst die Addition,

danach die Multiplikation und zuletzt die Potenz. Bevor weitere Verrechnungen

durchgeführt werden, wird das Ergebnis zunächst auf den Wertebereich 0 bis 1 nor-

malisiert.

Die Klasse RuleAppliedString

Abgeleitet von RuleApplied, implementiert IRuleString

Diese Klasse wertet eine Zeichenketten-Regel aus.

91


Die Klasse RuleConcatenation

Abgeleitet von RuleContainerString

Diese Klasse verkettet zwei oder mehr Zeichenketten. Optional kann ein Bindeglied

angegeben werden, welches jeweils zwischen den unterschiedlichen Zeichenketten

eingefügt wird.

Die Klasse Constant

Abgeleitet von Rule

Dies ist die Basisklasse für alle konstanten Werte.

Die Klasse ConstantBoolean

Abgeleitet von Constant, implementiert IRuleBoolean

Diese Klasse beinhaltet einen konstanten booleschen Wert. Bei der Auswertung wird

dieser zurückgegeben.

Die Klasse ConstantNumeric

Abgeleitet von Constant, implementiert IRuleNumeric

Diese Klasse beinhaltet einen konstanten numerischen Wert. Bei der Auswertung

wird dieser zurückgegeben.

Die Klasse ConstantString

Abgeleitet von Constant, implementiert IRuleString

Diese Klasse beinhaltet eine konstante Zeichenkette. Bei der Auswertung wird diese

zurückgegeben.

Beispiel einer Regel-Objekthierarchie

Gegeben sei eine Konfigurationsdatei, die das folgende XML-Fragment enthalte. Zur

näheren Erläuterung der XML-Struktur siehe Kapitel 4.4.

92


<RuleAddition><apply-rule-numeric

type="java" source="eworks.peace.rules.DummyRule"/><RuleMultiplication>

<apply-rule-numeric type="xml" source="XMLRule" factor="5" /><ConstantNumeric>3</ConstantNumeric>

</RuleMultiplication></RuleAddition>

Daraus entstünde eine Objekthierarchie, die wie folgt aussähe.

4.3.5 Das Paket eworks.peace.rules.params

In diesem Paket befinden sich einige Klassen, die die Parameter der einzelnen Re-

geln darstellen. Es gibt verschiedene Arten von Parametern, wobei der Hauptunter-

schied die Art bzw. die Herkunft des Parameterwertes ist. Aus diesem Grund werden

die Parameter unterschiedlich erzeugt.

93

Abbildung 4.5: Beispielhafte Regel-Objekthierarchie


Die Klasse ParamHandler

Diese Klasse kapselt den Zugriff auf die Parameter einer Regel. Es werden keine

NullPointerExceptions, sondern speziellere, aussagekräftigere Exceptions (siehe Ka-

pitel 4.3.2) geworfen.

Die Klasse Param

Dies ist die Basisklasse für alle Parametertypen.

Die Klasse ParamConstant

Abgeleitet von Param

Diese Klasse stellt einen Parameter mit einem konstanten Wert dar.

94

Abbildung 4.6: Klassenhierarchie eworks.peace.params


Die Klasse ParamField


Diese Klasse stellt einen Parameter dar, dessen Wert durch ein Feld der Inputdatei

spezifiziert wird. Letztlich entspricht das z. B. dem Wert, der in ein Feld des Kontakt-

formulars geschrieben wurde.

Die Klasse ParamGlobal


Diese Klasse stellt einen Parameter dar, dessen Wert einem globalen Parameter aus

der Konfigurationsdatei entspricht.

Die Klasse ParamPointer


Diese Klasse stellt einen Parameter dar, dessen Wert durch einen Parameter einer

anderen Regel definiert wird.

Die Klasse Dictionary

Dies ist die Basisklasse für alle Dictionary-Typen.

Die Klasse DictionaryConstant

Abgeleitet von Dictionary

Diese Klasse stellt ein Dictionary dar, dessen Einträge konstant sind.

Die Klasse DictionaryGlobal


Diese Klasse stellt ein Dictionary dar, dessen Einträge einem in der Konfigurations-

datei global definierten Dictionary entsprechen.

95


Die Klasse DictionaryPointer


Diese Klasse stellt ein Dictionary dar, dessen Einträge durch ein Dictionary einer an-

deren Regel definiert werden.

Die Klasse DictionaryType

Diese Klasse stellt den Typ eines Dictionary dar, kombiniert also Schlüssel- und

Werttyp.

4.3.6 Das Paket eworks.peace.utils

Dieses Paket stellt einige Hilfsklassen bereit.

Die Klasse RuleConstants

Diese Klasse enthält einige konstante Zeichenketten bereit, die für die Verarbeitung

der XML-Dateien oder andere Aufgaben benötigt werden, bei denen auf eine be-

stimmte Zeichenkette geprüft werden muss.

Die Klasse RuleUtils

Diese Klasse stellt einige Methoden bereit, die das Verarbeiten der Regeln vereinfa-

chen.

Die Klasse XMLUtils

Diese Klasse stellt einige Methoden bereit, die das Verarbeiten der XML-Dateien

bzw. deren JDOM-Repräsentation vereinfachen.

4.3.7 Das Paket eworks.peace.workflows

Dieses Paket enthält Klassen zur Darstellung von Workflows, die mittels der Konfigu-

rationsdatei definiert wurden. Ein Workflow spezifiziert einen Namen und einen Ein-

96


stiegspunkt in das Regelsystem. Pro Workflow existiert im Output-Dokument ein Er-

gebniswert, der unter dem jeweiligen Namen zu finden ist.

Zukünftig könnten Workflows auch dazu benutzt werden um je nach Ergebniswert

bestimmte Aktionen auszulösen. So könnten „schlechte“ Kontaktanfragen beispiels-

weise automatisch gelöscht werden und „gute“ an eine bestimmte E-Mailadresse

weitergeleitet werden.

Die Klasse Workflow

Diese Klasse stellt einen Workflow dar. Ein Workflow besteht im einfachsten Fall aus

einem Einstiegspunkt (einer Regel) und einem Namen. Das Ergebnis der Einstiegs-

regel wird auf den Wertebereich 0 bis 1 normalisiert.

4.4 XML-Schema-Dateien

Das Framework PEACE enthält drei XML-Schema-Dateien, die das Format der Kon-

figurationsdatei, der Inputdatei sowie der Outputdatei spezifizieren.

4.4.1 Die Datei peace_config.xsd

Diese Schema-Datei gibt die Struktur der Konfigurationsdateien vor.

Das Wurzelelement einer Konfigurationsdatei heißt „config“. Es hat ein Kindelement

mit dem Namen „Rules“ und ein Kindelement mit dem Namen „Workflows“.

Das „Rules“-Element besitzt beliebig viele Kindelemente mit den Namen „global-

param“, „global-param-dictionary“ und „Rule“.

„global-param“ stellt einen globalen Parameter dar, auf den von überall aus dem Re-

gelsystem heraus zugegriffen werden kann. Er hat einen Namen (repräsentiert durch

das Attribut „name“) und einen Wert (repräsentiert durch das Attribut „value“).

„global-param-dictionary“ hingegen stellt ein globales Dictionary dar. Es hat ebenfalls

einen Namen, der durch das „name“-Attribut repräsentiert wird. Des Weiteren besitzt

es beliebig viele Kindelemente mit dem Namen „dictionary-element“, welche ihrer-

97


seits wiederum einen Schlüssel und einen Wert besitzen (repräsentiert durch die At-

tribute „key“ und „value“).

Ein „Rule“-Element hat einen Namen, der durch das Attribut „name“ spezifiziert wird.

Dieser Name stellt den Schlüssel „RuleKey“ dar und muss eindeutig sein. Weiterhin

hat ein „Rule“-Element beliebig viele Kindelemente mit den Namen „param“ und

„param-dictionary“, durch welche Parameter bzw. Dictionaries deklariert werden, die

dieser Regel beim Aufruf übergeben werden müssen. Ein „param“-Element spezifi-

ziert mittels der Attribute „name“ und „type“ einen Namen und einen Typ, während

ein „param-dictionary“-Element einen Namen, einen Schlüsseltyp und einen Werttyp

spezifiziert (Attribute „name“, „key-type“ und „value-type“).

Des Weiteren besitzt ein „Rule“-Element eines der Elemente „apply-rule-numeric“,

„RuleAddition“, „RuleMultiplication“, „apply-rule-boolean“, „RuleConjunction“,

„RuleDisjunction“, „RuleNumericComparison“, „RuleStringComparison“, „apply-rule-

string“ oder „RuleConcatenation“. Die „apply-rule“-Elemente rufen eine andere Regel

auf, dabei kann es sich um eine andere in dieser Konfigurationsdatei erstellte Regel

handeln oder um eine Java-Klasse. Sie übergeben mittels der Kindelemente „with-

param“ oder „with-param-dictionary“ die benötigten Parameter bzw. Dictionaries.

„RuleAddition“, „RuleMultiplication“ und „RuleNumericComparison“ kombinieren nu-

merische Regeln, d. h. sie können als Kindelemente die Elemente „apply-rule-

numeric“, „RuleAddition“ und „RuleMultiplication“ besitzen. „RuleConjunction“ und

„RuleDisjunction“ kombinieren boolesche Regeln, d. h. sie können als Kindelemente

die Elemente „apply-rule-boolean“, „RuleConjunction“, „RuleDisjunction“,

„RuleNumericComparison“ und „RuleStringComparison“ enthalten.

„RuleConcatenation“ kombiniert Zeichenkettenregeln, d. h. es kann als Kindelemente

die Elemente „apply-rule-string“ und „RuleConcatenation“ enthalten.

Das „Workflows“-Element hat beliebig viele Kindelemente mit dem Namen

„Workflow“. Diese besitzen das Attribut „display-name“, das den Namen eines

Workflows spezifiziert und das Attribut „entry-point“, das die Regel festlegt, die als

Einstiegspunkt benutzt wird. Diese Regel darf keine Parameter erwarten. Weiterhin

ist „entry-point“ eine Referenz auf den Schlüssel „RuleKey“, also auf das Attribut

98


„name“ eines „Rule“-Elements, welches Kindelement von „Rules“ ist. Ist der referen-

zierte Schlüssel nicht vorhanden, schlägt das Validieren fehl.

Der Quelltext von peace_config.xsd

<?xml version="1.0" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="config"><xsd:complexType>

<xsd:sequence><xsd:element ref="Rules" /><xsd:element ref="Workflows" />

</xsd:sequence></xsd:complexType><xsd:keyref name="RuleKeyRef" refer="RuleKey">

<xsd:selector xpath="Workflows/Workflow" /><xsd:field xpath="@entry-point" />

</xsd:keyref><xsd:key name="RuleKey">

<xsd:selector xpath="Rules/Rule" /><xsd:field xpath="@name" />

</xsd:key></xsd:element>

<xsd:element name="Rules"><xsd:complexType>

<xsd:sequence><xsd:element

ref="global-param"minOccurs="0"maxOccurs="unbounded" />

<xsd:elementref="global-param-dictionary"minOccurs="0"maxOccurs="unbounded" />

<xsd:elementref="Rule"minOccurs="0"maxOccurs="unbounded" />

</xsd:sequence></xsd:complexType>

</xsd:element>

<xsd:element name="global-param"><xsd:complexType>

<xsd:attributename="name"type="xsd:string"use="required" />

<xsd:attributename="value"

99


type="xsd:string"use="required" />

</xsd:complexType></xsd:element>

<xsd:element name="global-param-dictionary"><xsd:complexType>


ref="dictionary-element"minOccurs="0"maxOccurs="unbounded" />

</xsd:sequence><xsd:attribute

name="name"type="xsd:string"use="required" />


<xsd:element name="dictionary-element"><xsd:complexType>

<xsd:attributename="key"type="xsd:string"use="required" />

<xsd:attributename="value"type="xsd:string"use="required" />


<xsd:element name="Rule"><xsd:complexType>


ref="param"minOccurs="0"maxOccurs="unbounded" />

<xsd:elementref="param-dictionary"minOccurs="0"maxOccurs="unbounded" />

<xsd:choice><xsd:element

name="apply-rule-numeric"type="ApplyNumericElement" />

<xsd:elementname="RuleAddition"type="RuleNumericContainer" />

<xsd:elementname="RuleMultiplication"type="RuleNumericContainer" />

<xsd:element

100


name="apply-rule-boolean"type="ApplyElement" />

<xsd:elementname="RuleConjunction"type="RuleBooleanContainer" />

<xsd:elementname="RuleDisjunction"type="RuleBooleanContainer" />

<xsd:elementref="RuleNumericComparison" />

<xsd:elementref="RuleStringComparison" />

<xsd:elementname="apply-rule-string"type="ApplyElement" />

<xsd:elementname="RuleConcatenation"type="RuleStringContainer" />

</xsd:choice></xsd:sequence><xsd:attribute



<xsd:element name="param"><xsd:complexType>


<xsd:attributename="type"type="ParamTypes"use="required" />


<xsd:element name="param-dictionary"><xsd:complexType>


<xsd:attributename="key-type"type="ParamTypes"use="required" />

<xsd:attributename="value-type"type="ParamTypes"use="required" />

</xsd:complexType>

101


</xsd:element>

<xsd:simpleType name="ParamTypes"><xsd:restriction base="xsd:string">

<xsd:enumeration value="String" /><xsd:enumeration value="Date" /><xsd:enumeration value="DateTime" /><xsd:enumeration value="Time" /><xsd:enumeration value="Integer" /><xsd:enumeration value="Double" /><xsd:enumeration value="Boolean" />

</xsd:restriction></xsd:simpleType>

<xsd:complexType name="RuleNumericContainer"><xsd:sequence>

<xsd:groupref="NumericElements"maxOccurs="unbounded" />


<xsd:element name="RuleNumericComparison"><xsd:complexType>

<xsd:sequence><xsd:group

ref="NumericElements"minOccurs="2" maxOccurs="2" />


name="operator"type="NumericComparisonOperator"use="required" />


<xsd:simpleType name="NumericComparisonOperator"><xsd:restriction base="xsd:string">

<xsd:enumeration value="eq" /><xsd:enumeration value="ne" /><xsd:enumeration value="gt" /><xsd:enumeration value="ge" /><xsd:enumeration value="lt" /><xsd:enumeration value="le" />


<xsd:element name="RuleStringComparison"><xsd:complexType>

<xsd:sequence><xsd:group

ref="StringElements"minOccurs="2" maxOccurs="2" />


name="operator"

102


type="StringComparisonOperator"use="required" />


<xsd:simpleType name="StringComparisonOperator"><xsd:restriction base="xsd:string">

<xsd:enumeration value="eq" /><xsd:enumeration value="ne" />


<xsd:complexType name="RuleBooleanContainer"><xsd:sequence>

<xsd:groupref="BooleanElements"maxOccurs="unbounded" />


<xsd:complexType name="RuleStringContainer"><xsd:sequence>

<xsd:groupref="StringElements"maxOccurs="unbounded" />


<xsd:group name="NumericElements"><xsd:choice>

<xsd:elementname="apply-rule-numeric"type="ApplyNumericElement" />

<xsd:elementname="ConstantNumeric"type="xsd:double" />

<xsd:elementname="RuleAddition"type="RuleNumericContainer" />

<xsd:elementname="RuleMultiplication"type="RuleNumericContainer" />

</xsd:choice>

</xsd:group>

<xsd:group name="BooleanElements"><xsd:choice>

<xsd:elementname="apply-rule-boolean"type="ApplyElement" />

<xsd:elementname="ConstantBoolean"type="xsd:boolean" />

<xsd:elementname="RuleConjunction"

103


type="RuleBooleanContainer" /><xsd:element

name="RuleDisjunction"type="RuleBooleanContainer" />

<xsd:element ref="RuleNumericComparison" /><xsd:element ref="RuleStringComparison" />

</xsd:choice></xsd:group>

<xsd:group name="StringElements"><xsd:choice>

<xsd:elementname="apply-rule-string"type="ApplyElement" />

<xsd:elementname="ConstantString"type="xsd:string" />

<xsd:elementname="RuleConcatenation"type="RuleStringContainer" />

</xsd:choice></xsd:group>

<xsd:complexType name="ApplyNumericElement"><xsd:complexContent>

<xsd:extension base="ApplyElement"><xsd:attribute

name="factor" type="xsd:double" /><xsd:attribute

name="summand" type="xsd:double" /><xsd:attribute

name="exponent" type="xsd:double" /></xsd:extension>

</xsd:complexContent></xsd:complexType>

<xsd:complexType name="ApplyElement"><xsd:sequence>

<xsd:elementref="with-param"minOccurs="0" maxOccurs="unbounded" />

<xsd:elementref="with-param-dictionary"minOccurs="0" maxOccurs="unbounded" />


name="type"type="ApplyTypeEnum"use="required" />

<xsd:attributename="source"type="xsd:string"use="required" />

</xsd:complexType>

104


<xsd:element name="with-param"><xsd:complexType>


<xsd:attributename="source"type="ParamTypeEnum"use="required" />

<xsd:attributename="value"type="xsd:string"use="required" />


<xsd:element name="with-param-dictionary"><xsd:complexType>


ref="dictionary-element"minOccurs="0" maxOccurs="unbounded" />



<xsd:attributename="source"type="ParamDictionaryTypeEnum"use="required" />

<xsd:attributename="value"type="xsd:string" />


<xsd:simpleType name="ParamTypeEnum"><xsd:restriction base="xsd:string">

<xsd:enumeration value="const" /><xsd:enumeration value="param" /><xsd:enumeration value="global" /><xsd:enumeration value="field" />


<xsd:simpleType name="ParamDictionaryTypeEnum"><xsd:restriction base="xsd:string">

<xsd:enumeration value="const" /><xsd:enumeration value="param" /><xsd:enumeration value="global" />


<xsd:simpleType name="ApplyTypeEnum">

105


<xsd:restriction base="xsd:string"><xsd:enumeration value="java" /><xsd:enumeration value="xml" />


<xsd:element name="Workflows"><xsd:complexType>


ref="Workflow"minOccurs="0" maxOccurs="unbounded" />


</xsd:element>

<xsd:element name="Workflow"><xsd:complexType>

<xsd:attributename="display-name"type="xsd:string" use="required" />

<xsd:attributename="entry-point"type="xsd:string" use="required" />


</xsd:schema>

4.4.2 Die Datei peace_input.xsd

Diese Schema-Datei gibt die Struktur von Inputdateien vor.

Das Wurzelelement einer Inputdatei heißt „input“. Dieses Element hat beliebig viele

Kindelemente mit dem Namen „field“. Jedes dieser „field“-Elemente hat das Attribut

„name“, das den Namen des Feldes spezifiziert. Außerdem hat es textuellen Inhalt,

der den Wert des Feldes darstellt.

Der Quelltext von peace_input.xsd



<xsd:element name="input"><xsd:complexType>


ref="field"

106


minOccurs="0"maxOccurs="unbounded" />


</xsd:element>

<xsd:element name="field"><xsd:complexType>

<xsd:simpleContent><xsd:extension base="xsd:string">


</xsd:extension></xsd:simpleContent>


</xsd:schema>

4.4.3 Die Datei peace_output.xsd

Diese Schema-Datei gibt die Struktur von Outputdateien vor.

Das Wurzelelement einer Outputdatei heißt „output“. Dieses Element hat kein oder

ein Kindelement mit dem Namen „Workflows“ und kein oder ein Kindelement mit dem

Namen „Errors“.

Das „Workflows“-Element hat beliebig viele Kindelemente mit dem Namen

„Workflow“. Jedes dieser „Workflow“-Elemente hat das Attribut „display-name“, das

den Namen des Workflows spezifiziert. Weiterhin hat es textuellen Inhalt, welcher

den Auswertungswert des Workflows darstellt.

Das „Errors“-Element hat beliebig viele Kindelemente mit dem Namen „Error“. Jedes

dieser „Error“-Elemente hat das Attribut „type“, das den Exception-Typ, also den Na-

men der Exception-Klasse spezifiziert. Außerdem hat es textuellen Inhalt, der die je-

weilige Fehlermeldung darstellt.

Der Quelltext von peace_output.xsd



<xsd:element name="output">

107


<xsd:complexType><xsd:sequence>

<xsd:element ref="Workflows" minOccurs="0" />

<xsd:element ref="Errors" minOccurs="0" /></xsd:sequence>


<xsd:element name="Errors"><xsd:complexType>


<xsd:attributename="type"type="xsd:string"use="required" />



<xsd:element name="Workflows"><xsd:complexType>


ref="Workflow"minOccurs="0"maxOccurs="unbounded" />


</xsd:element>

<xsd:element name="Workflow"><xsd:complexType>


<xsd:attributename="display-name"type="xsd:string"use="required" />



</xsd:schema>

108

4.5 Integrierte Regeln


4.5.1 Parameter

Grundsätzlich gibt es zwei verschiedene Arten von Parametern: skalare Parameter

und Dictionaries. Skalare Parameter bestehen aus einem Namen und einem Wert,

dem ein bestimmter Typ zugeordnet ist. Dictionaries haben ebenfalls einen Namen,

bestehen aber aus mehreren Einträgen, die jeweils ein Name-Wert-Paar beinhalten.

Dem Namen (oder Schlüssel) sowie dem Wert eines Eintrags ist auch jeweils ein be-

stimmter Typ zugeordnet. In einem Dictionary gilt der Schlüsseltyp für alle Schlüssel

und der Werttyp für alle Werte. Durch dieses Konstrukt lassen sich auch komplexere

Eingabestrukturen realisieren.

In der init()-Methode einer Regel können bestimmte Parameter und Dictionaries zu-

gesichert werden (mittels der Methode assertParam() bzw. assertDictionary()). Dabei

muss auch der erwartete Typ eines Parameters bzw. der erwartete Schlüssel- und

Werttyp eines Dictionary angegeben werden. PEACE übernimmt in diesem Fall die

Zusicherung der Parameter bzw. Dictionaries und warnt den Benutzer falls ein Para-

meter oder ein Dictionary fehlen sollte. Das Typsystem ist also nicht statisch sondern

dynamisch. Typfehler werden erst während der Laufzeit erkannt.

Die möglichen Typen sind in allen drei Fällen (Parametertyp, Schlüsseltyp, Werttyp)

die folgenden:

● String: eine Zeichenkette

● Boolean: eine boolescher Wert, true oder false

● Double: eine Kommazahl

● Integer: eine Ganzzahl

● Date: ein Datum (ohne Uhrzeit)

● Time: eine Uhrzeit (ohne Datum)

● DateTime: ein Datum mit Uhrzeit

109


Weiterhin können Parameter mit Default-Werten belegt werden. In diesem Fall sind

die Parameter optional, das heißt sie müssen beim Aufruf der Regel nicht zwingend

übergeben werden, sondern nur dann, wenn der Standardwert überschrieben wer-

den soll.

Die folgenden Kapitel über die integrierten Regelklassen enthalten auch eine Über-

sicht über die von der jeweiligen Regel erwarteten Parameter und Dictionaries, so-

fern vorhanden. Dabei werden Parameter mit der folgenden Schreibweise beschrie-

ben:

● Parametername (Parametertyp)

Kurze Beschreibung der Bedeutung bzw. Funktionsweise des Parameters.

Dictionaries werden mit einer ähnlichen Schreibweise beschrieben:

● Dictionaryname (Schlüsseltyp : Werttyp)

Kurze Beschreibung der Bedeutung bzw. Funktionsweise des Parameters.

4.5.2 Die Regelklasse WorkTimeRule

Diese Regel wertet das Datum und die Uhrzeit einer Anfrage aus. Dabei werden für

jeden Tag der Woche Arbeitszeiten eingestellt (voreingestellt ist Montag bis Freitag

von 8 bis 18 Uhr). Liegt das Anfragedatum und die Uhrzeit innerhalb einer dieser de-

finierten Zeitspannen, so wird die Regel mit 0 ausgewertet. Ist der Zeitpunkt der An-

frage außerhalb der Zeitspanne, so wird ein Wert berechnet, der größer wird, je wei-

ter der Zeitpunkt nach dem vorherigen Ende der Arbeitszeit und vor dem Anfang der

nächsten Arbeitszeit liegt. Der maximale Wert ist 1. Er wird erreicht, wenn der Zeit -

punkt genau in der Mitte zwischen dem Ende der vorherigen Arbeitszeit und dem An-

fang der folgenden Arbeitszeit liegt.

Wird für einen Tag dieselbe Uhrzeit für Arbeitsbeginn und Arbeitsende eingestellt, so

wird dieser Tag als Nicht-Arbeitstag gezählt und es wird mit dem Maximalwert be-

straft, falls die Anfrage an diesem Tag stattfand. Liegt eine Anfrage nach dem Ende

eines Arbeitstages und vor einem Nicht-Arbeitstag, so wird der Wert in diesem Fall

110


ein wenig anders berechnet. Die letzte Minute der Arbeitszeit wird mit 0 gewertet und

die erste Minute des Nicht-Arbeitstages mit 1. Werte die dazwischen liegen werden

mit einer linearen Funktion berechnet. Es wird also nicht die Mitte zwischen dem Ar-

beitsende und dem Arbeitsbeginn des nächsten Tages als Fixpunkt benutzt, sondern

die erste Minute des Nicht-Arbeitstages. Somit wird vermieden, dass Unstetigkeiten

entstehen. Das gleiche gilt für den Fall, dass ein Anfragezeitpunkt nach einem Nicht-

Arbeitstag, aber vor der Arbeitszeit des nächsten Tages liegt.

Beispiel:

Es werden die vordefinierten Arbeitszeiten (Montag – Freitag, 8 Uhr – 18 Uhr) be-

nutzt. Eine Anfrage käme nach dem Arbeitsende am Montag (18 Uhr) und vor dem

Beginn der Arbeitszeit am Dienstag (8 Uhr). Den maximalen Wert den diese Anfrage

bei dieser Regel erzielen kann, erreicht sie, wenn sie am Dienstag morgen um 1 Uhr

abgeschickt wird. Denn diese Uhrzeit liegt genau zwischen dem Ende der Arbeitszeit

am Montag und dem Beginn der Arbeitszeit am Dienstag. Je näher der Zeitpunkt an

das Ende der Arbeitszeit am Montag bzw. den Beginn der Arbeitszeit am Dienstag

rückt, desto kleiner wird ihr Wert.

Der Wert für eine Anfrage, die am Montag um 18 Uhr abgeschickt würde, wäre also

0. Für jeden Zeitpunkt nach 18 Uhr steigt der Wert linear, bis er bei Dienstag um 1

Uhr mit 1 seinen Höchstwert erreicht. Um 21 Uhr 30 wäre der Wert also 0,5. Nach 1

Uhr sinkt der Wert wieder linear, bis er bei Dienstag um 8 Uhr wieder 0 erreicht. Um

4 Uhr 30 wäre der Wert also ebenfalls 0,5.

Parameter

● monday-start (Time)

Die Uhrzeit, die den Arbeitsbeginn an Montagen repräsentiert. Optionaler Pa-

rameter, voreingestellt ist 8:00.

● monday-end (Time)

Die Uhrzeit, die das Arbeitsende an Montagen repräsentiert. Optionaler Para-

meter, voreingestellt ist 18:00.

111


● tuesday-start (Time)

Die Uhrzeit, die den Arbeitsbeginn an Dienstagen repräsentiert. Optionaler

Parameter, voreingestellt ist 8:00.

● tuesday-end (Time)

Die Uhrzeit, die das Arbeitsende an Dienstagen repräsentiert. Optionaler Pa-


● wednesday-start (Time)

Die Uhrzeit, die den Arbeitsbeginn mittwochs repräsentiert. Optionaler Para-


● wednesday-end (Time)

Die Uhrzeit, die das Arbeitsende mittwochs repräsentiert. Optionaler Parame-

ter, voreingestellt ist 18:00.

● thursday-start (Time)

Die Uhrzeit, die den Arbeitsbeginn an Donnerstagen repräsentiert. Optionaler


● thursday-end (Time)

Die Uhrzeit, die das Arbeitsende an Donnerstagen repräsentiert. Optionaler


● friday-start (Time)

Die Uhrzeit, die den Arbeitsbeginn an Freitagen repräsentiert. Optionaler Pa-


● friday-end (Time)

Die Uhrzeit, die das Arbeitsende an Freitagen repräsentiert. Optionaler Para-


112


● saturday-start (Time)

Die Uhrzeit, die den Arbeitsbeginn an Samstagen repräsentiert. Optionaler


● saturday-end (Time)

Die Uhrzeit, die das Arbeitsende an Samstagen repräsentiert. Optionaler Pa-

rameter, voreingestellt ist 8:00, also der gleiche Zeitpunkt des Arbeitsbeginns

an Samstagen, was impliziert, dass es sich hier um einen Nicht-Arbeitstag

handelt.

● sunday-start (Time)

Die Uhrzeit, die den Arbeitsbeginn an Sonntagen repräsentiert. Optionaler Pa-


● sunday-end (Time)

Die Uhrzeit, die das Arbeitsende an Sonntagen repräsentiert. Optionaler Para-

meter, voreingestellt ist 8:00, also der gleiche Zeitpunkt des Arbeitsbeginns an

Sonntagen, was impliziert, dass es sich hier um einen Nicht-Arbeitstag han-

delt.

● date (DateTime)

Dies ist der Zeitpunkt der Anfrage. Obligatorischer Parameter.

4.5.3 Die Regelklasse EmailNameRule

Bei dieser Regel wird ausgewertet, ob der Name des Anfragenden im ersten Teil

seiner E-Mailadresse vorkommt. Wenn dort Vor- und Nachname vorhanden sind, gibt

die Regel den Wert 3 zurück, ist nur der Nachname vorhanden, gibt sie den Wert 2

zurück, ist nur der Vorname vorhanden, gibt sie den Wert 1 zurück und ist weder der

Vorname noch der Nachname im ersten Teil der E-Mailadresse vorhanden, so gibt

die Regeln den Wert 0 zurück.

Beispiel:

113


Diese Regel kann dazu eingesetzt werden, um die Seriosität einer E-Mailadresse zu

bewerten. Angenommen eine Person mit dem Namen „Wilhelm Weber“ schickt eine

Kontaktanfrage. Die E-Mailadresse dieser Person würde den höchsten Wert (3) er-

zielen, wenn sowohl Vor- als auch Nachname darin vorkommen, also beispielsweise

„[email protected]“ oder „[email protected]“. Der zweit höchste

Wert (2) würde erzielt, wenn die Adresse z. B. „[email protected]“ oder

„[email protected]“ lauten würde. „[email protected]“ würde den zweit nied-

rigsten Wert (1) erzielen. Der niedrigste Wert würde erzielt, hieße die E-Mailadresse

beispielsweise „[email protected]“ oder „[email protected]“.

Parameter

● email (String)

Die E-Mailadresse der kontaktierenden Person. Obligatorischer Parameter.

● firstname (String)

Der Vorname der kontaktierenden Person. Obligatorischer Parameter.

● lastname (String)

Der Nachname der kontaktierenden Person. Obligatorischer Parameter.

4.5.4 Die Regelklasse MailDomainRule

Diese Regel dient dazu, die Domain einer E-Mailadresse zu bewerten. Als Basis der

Bewertung dient eine in der Konfigurationsdatei vorgegebene Liste, deren Einträge

jeweils aus dem Namen der Domain sowie einem Wert bestehen. Befindet sich die

Domain der aktuell zu bewertenden E-Mailadresse in dieser Liste, wird der vorgege-

bene Wert zurückgegeben. Handelt es sich um eine Domain, die nicht in der Liste

vorkommt, wird dies mit dem Wert 0 bewertet.

114


Parameter

● email (String)

Die zu bewertende E-Mailadresse. Obligatorischer Parameter.

Dictionaries

● list (String : Integer)

Die Liste, die der Bewertung zugrunde liegt. Obligatorisches Dictionary.

4.5.5 Die Regelklasse TextLengthRule

Diese Regel wertet die Länge einer Zeichenkette aus. Es wird eine Länge (expected-

length) definiert, bei welcher der Maximalwert von 1 erreicht wird.

Weiterhin gibt es einen Parameter (binary), der angibt, wie zu verfahren ist, falls die

Zeichenkette eine andere Länge als die in expected-length angegebene hat. Wird er

auf true gesetzt, so werden alle anderen Längen mit dem Wert 0 bewertet.

Ist der Parameter boolean auf false gesetzt, so wird der Rückgabewert mittels zweier

linearer Funktionen berechnet. Die erste Funktion hat für die Länge 0 den Wert 0 und

steigt dann linear bis sie bei der Länge expected-length den Wert 1 annimmt. Hier

beginnt die zweite Funktion, die mit der negierten Steigung der ersten Funktion wie-

der abnimmt bis sie bei der doppelten Länge von expected-length und allen größeren

Längen den Wert 0 annimmt.

Im Sonderfall, dass expected-length 0 sein sollte werden die Werte wie folgt berech-

net: Hat die Zeichenkette die Länge 0, so gibt die Regel den Wert 1 zurück. Für jedes

weitere Zeichen wird ein Hundertstel von 1 abgezogen. Hat die Zeichenkette die Län-

ge 100 oder größer, so wird die Regel mit dem Wert 0 bewertet.

Parameter

● content (String)

Die zu bewertende Zeichenkette. Obligatorischer Parameter.

115


● expected-length (Integer)

Die Länge der Zeichenkette, bei der 1 zurückgegeben wird. Obligatorischer

Parameter.

● binary (Boolean)

Dieser Parameter gibt an, ob alle Zeichenketten, die nicht die Länge

expected-length haben, mit 0 bewertet werden (true) oder ob Zwischenwerte

berechnet werden sollen (false). Optionaler Parameter, voreingestellt ist false.

4.5.6 Die Regelklasse TextSearchRule

Diese Regel sucht in einem gegebenen Text nach bestimmten Wörtern. Diese Wör-

ter werden mittels eines Dictionary übergeben. Ist das entsprechende Wort im Text

enthalten, so wird der dem im Dictionary zugeordnete Wert zum Endwert dazu ad-

diert.

Der optionale boolesche Parameter „multi“ gibt an, ob der Wert eines Wortes mit der

Anzahl der Vorkommen des Wortes multipliziert werden soll.

Der optionale boolesche Parameter „case-sensitive“ gibt an, ob bei der Suche nach

den im Dictionary enthaltenen Wörtern auf Groß- und Kleinschreibung geachtet wer-

den soll.

Der optionale boolesche Parameter „whole-word“ gibt an, ob das Wort als ganzes

gesucht werden soll, oder ob es auch als Teil in einem anderen Wort enthalten sein

darf.

Parameter

● input (String)

Dies ist der Text in dem nach den Wörtern gesucht wird. Obligatorischer Para-

meter.

116


● multi (Boolean)

Dieser Parameter gibt an, ob die Werte mit der Anzahl der Vorkommen eines

Wortes multipliziert werden (true) oder ob jeder Wert nur maximal einmal in

den Endwert mit eingerechnet werden kann (false). Optionaler Parameter, vor-

eingestellt ist false.

● case-sensitive (Boolean)

Dieser Parameter gibt an, ob bei der Suche nach einem Wort auf Groß- und

Kleinschreibung geachtet werden soll (true) oder nicht (false). Optionaler Pa-

rameter, voreingestellt ist false.

● whole-word (Boolean)

Dieser Parameter gibt an, ob das Wort als ganzes gesucht werden soll ( true)

oder ob es auch als Teil in anderen Wörtern enthalten sein darf (false). Optio-

naler Parameter, voreingestellt ist false.

Dictionaries

● words (String : Double)

Dieses Dictionary enthält die Wörter nach denen im Text gesucht werden soll.

Die zu suchenden Wörter sind dabei der Schlüssel, während der Wert eines

Wortes der jeweilig zugeordnete Wert ist.

4.5.7 Die Regelklasse RequestDateRule

Diese Regel wertet den Monat einer Anfrage aus. Erfahrungsgemäß ist eine Kon-

taktanfrage je nach Monat unterschiedlich zu bewerten. Wie ein Monat zu bewerten

ist, kann jedoch vom Benutzer mittels eines Dictionary eingestellt werden.

117


Parameter

● date (DateTime)

Dieser Parameter repräsentiert das Datum der Anfrage. Obligatorischer Para-

meter.

Dictionaries

● evaluations (Date : Double)

Dieses Dictionary ordnet einem Monat einen bestimmten Wert zu. Der Monat

wird dabei durch ein Objekt vom Typ Date repräsentiert. Ist der Monat der An-

frage nicht im Dictionary enthalten, wird der Wert 0 zurückgegeben.

4.5.8 Die Regelklasse UrgencyRule

Diese Regel wertet die Dringlichkeit einer Anfrage aus. Dabei wird auf Daten hinter

Schlüsselwörtern wie z. B. „bis zum“ oder „am“ geachtet. Es werden auch Ausdrücke

wie beispielsweise „schnellstmöglich“ ausgewertet. Die Regel gibt den Wert 1 zurück,

falls es sich um eine sehr dringliche Anfrage handelt. Der Rückgabewert wird kleiner

und nähert sich 0 an, je größer der Bearbeitungszeitraum wird. Liegt ein genannter

Termin noch ein Jahr oder weiter in der Zukunft, so gibt die Regel den Wert 0 zurück.

Kann kein Datum gefunden werden, wird ebenfalls 0 zurückgegeben.

Parameter

● input (String)

Dies ist der Text der nach den oben genannten Schlüsselwörtern durchsucht

wird. Obligatorischer Parameter.

● date (DateTime)

Dies ist das Datum der Anfrage, das als Vergleichsdatum herangezogen wird.

Obligatorischer Parameter.

118


4.5.9 Die Regelklasse PolitenessRule

Diese Regel überprüft die Anrede und die Grußformel einer Nachricht. Die jeweiligen

Textbausteine und ihre Bewertung kann der Benutzer mittels eines Dictionary vorge-

ben. Die Anrede wird dabei am Anfang des übergebenen Textes, während die Gruß-

formel im letzten Drittel gesucht wird.

Parameter

● message (String)

Dies ist die Nachricht, in der die Grußformel und die Anrede gesucht wird. Ob-

ligatorischer Parameter.

Dictionaries

● greetings (String : Double)

Dies sind die Anreden und ihre jeweilige Bewertung.

● leavetakings (String : Double)

Dies sind die Grußformeln und ihre jeweilige Bewertung.

4.5.10 Die Regelklasse GeographicalNearnessRule

Diese Regel wertet die Entfernung einer möglicherweise in der Nachricht angegebe-

nen Postleitzahl aus. Dabei entspricht der Wert 1 einer sehr kurzen Distanz, während

der Wert 0 einer sehr großen Distanz entspricht. Die Berechnung des Wertes ge-

schieht durch eine einfache Subtraktion der gefundenen Postleitzahl und der überge-

benen Referenz-Postleitzahl.

Wird keine Postleitzahl im Text identifiziert, so wird der Wert 0,5 zurückgegeben.

Bei dieser Regel handelt es sich um einen Prototypen. Die einfache Subtraktion

zweier Postleitzahlen zur Bestimmung eines geographischen Abstands ist sehr unge-

nau und kann auch nur für Entfernungen innerhalb Deutschlands verwendet werden.

119


Man könnte die Genauigkeit dieser Regel verbessern, indem man die Berechnung

der Entfernung beispielsweise durch den Zugriff auf einen Web-Service durchführt.

Parameter

● text (String)

Dies ist die Nachricht. Die Postleitzahl wird im letzten Drittel vermutet. Obliga-

torischer Parameter.

● reference-zip (Double)

Dies ist die Referenz-Postleitzahl, also die Postleitzahl des Unternehmens.

Obligatorischer Parameter.

120

5 PEACE - Anwendungen des Frameworks

5 PEACE - Anwendungen des Frameworks

Dieses Kapitel beschreibt, wie PEACE in der Praxis eingesetzt werden kann. Dies

umfasst zunächst eine Beschreibung der Vorgehensweise zur Erstellung neuer Re-

geln. Anschließend wird erläutert, wie das Framework in eigene Anwendungen inte-

griert werden kann. Der dritte Teil dieses Kapitels stellt eine vom Autor dieser Arbeit

realisierte Beispielanwendung für PEACE dar. Eine Übersicht über die möglichen

Einsatzgebiete findet sich am Ende des Kapitels.

5.1 Erweiterung des Frameworks um neue Regeln

In diesem Abschnitt wird detailliert beschrieben, wie man vorzugehen hat, wenn das

Framework PEACE um neue Regeln erweitert werden soll.

Dies beinhaltet sowohl die Erstellung neuer Java-Klassen, als auch die Beachtung

der Vorgaben, die einzuhalten sind, soll das Framework die Regeln ordnungsgemäß

verarbeiten können.

5.1.1 Generelle Vorgehensweise

Um das PEACE-Framework um neue Regeln zu erweitern, muss zunächst eine neue

Java-Klasse erstellt werden. Diese Java-Klasse muss die folgenden beiden Voraus-

setzungen erfüllen, um vom Framework verarbeitet werden zu können.

1. Sie muss die Basisklasse eworks.peace.rules.core.Rule erweitern. Dies ist nö-

tig, damit die Regel vom Framework als solche erkannt und verarbeitet wer-

den kann.

2. Sie muss entweder das Interface eworks.peace.rules.core.IRuleBoolean, das

Interface eworks.peace.rules.core.IRuleNumeric oder das Interface

eworks.peace.rules.core.IRuleString implementieren. Dies spezifiziert den

Rückgabetyp der Regel und ist nötig, um später verschiedene Regeln des sel-

ben Rückgabetyps zu kombinieren, z. B. numerische Werte per Addition.

Die Klassendeklaration der neuen Regel könnte also wie folgt aussehen:

121

Kapitel 5: PEACE - Anwendungen des Frameworks

public class SampleRule extends Rule implements IRuleNumeric {...}

In diesem Fall wird vorausgesetzt, dass die entsprechenden Klassen bzw. Pakete

importiert wurden, beispielsweise mittels

import eworks.peace.rules.core.Rule;import eworks.peace.rules.core.IRuleNumeric;

5.1.2 Überschriebene und implementierte Methoden

Das Erweitern der Klasse eworks.peace.rules.core.Rule und das Implementieren des

jeweiligen Interfaces verlangt, dass spezielle Methoden überschrieben bzw. imple-

mentiert werden müssen.

Zu überschreibende Methoden von eworks.peace.rules.core.Rule

Wird die Klasse Rule erweitert, so muss die abstrakte Methode protected abstract

void init() überschrieben werden. Diese Methode dient dazu, um eventuelle Initia-

lisierungsaufgaben zu übernehmen und sie kann dazu benutzt werden, um obligatori-

sche Parameter zu definieren und optionale Parameter mit Defaultwerten zu bele-

gen. Das Framework PEACE gibt schon während des Parsens der Konfigurationsda-

tei eine Warnung aus, sollte ein als obligatorisch definierter Parameter fehlen. Es

wird also sichergestellt, dass zum Zeitpunkt des Auswertens der Regel alle benötig-

ten Parameter vorhanden sind.

Es gibt mehrere Methoden, um Parameter als obligatorisch bzw. optional zu definie-

ren. Diese sind in der Basisklasse Rule definiert, weshalb auf sie aus jeder von Rule

ableitenden Klasse zugegriffen werden kann.

● protected void assertParam(String name, String type)

Diese Methode stellt sicher, dass der Parameter mit dem Namen „name“ und

dem Typ „type“ vorhanden ist. Da dem Parameter kein Defaultwert übergeben

wurde, ist er obligatorisch, d. h. in der Konfigurationsdatei muss der Regel die-

ser Parameter beim Aufruf mitgegeben werden.

122


● protected void assertParam(String name, String type, String defaultValue)

Diese Methode stellt sicher, dass der Parameter mit dem Namen „name“ und

dem Typ „type“ vorhanden ist und weist ihm den Defaultwert „defaultValue“

zu. Wegen des Defaultwerts ist der Parameter obligatorisch, der Wert kann je-

doch mittels einer entsprechenden Angabe in der Konfigurationsdatei über-

schrieben werden.

● protected void assertDictionary(String name, String keyType, String

valueType)

Diese Methode stellt sicher, dass das Dictionary mit dem Namen „name“, dem

Schlüsseltyp „keyType“ und dem Werttyp „valueType“ vorhanden ist.

Dictionaries sind immer obligatorisch, es gibt jedoch keine Vorgabe über die

Anzahl der Einträge eines Dictionary. Ein obligatorisches Dictionary kann also

auch 0 Einträge enthalten. Was genau der Unterschied zwischen Dictionaries

und Parametern ist, kann dem Kapitel 4.5.1 entnommen werden.

Zur Definition von Typen für Parameter sowie für Schlüssel und Werte von

Dictionaries sollte auf die statischen Felder der Klasse

eworks.peace.rules.params.ParamHandler zurückgegriffen werden, da nur auf diese

dort definierten Enumerationswerte geprüft wird. Die verfügbaren Typen lauten:

● ParamHandler.TYPE_BOOLEAN

● ParamHandler.TYPE_DOUBLE

● ParamHandler.TYPE_INTEGER

● ParamHandler.TYPE_STRING

● ParamHandler.TYPE_DATE

● ParamHandler.TYPE_TIME

● ParamHandler.TYPE_DATETIME

Beispiel :

assertParam("foo", ParamHandler.TYPE_BOOLEAN);

123


Dieser Aufruf stellt sicher, dass der Parameter „foo“ vom Typ Boolean zur Laufzeit

zur Verfügung steht.

assertDictionary("bar", ParamHandler.TYPE_INTEGER, ParamHandler.TYPE_STRING);

Dieser Aufruf stellt sicher, dass das Dictionary „bar“ mit dem Schlüsseltyp Integer

und dem Werttyp String zur Laufzeit zur Verfügung steht.

Zu implementierende Methoden von eworks.peace.rules.core.IRuleBoolean

Wird das Interface IRuleBoolean implementiert, so muss die Methode public

Boolean evaluateBoolean() implementiert werden. Hier geschehen die eigentlichen

Berechnungen der Regel. Der Rückgabewert stellt die Auswertung der Regel dar.

Zu implementierende Methoden von eworks.peace.rules.core.IRuleNumeric

Wird das Interface IRuleNumeric implementiert, so müssen die folgenden Methoden

implementiert werden:

● public Number evaluateNumber()

Hier geschehen die eigentlichen Berechnungen der Regel. Der Rückgabewert

stellt die Auswertung der Regel dar.

● public Number getMaxValue()

Hier muss der maximale Wert der Regel zurückgegeben werden. Dies ist nö-

tig, da alle Werte während der Auswertung der Regeln auf einen Wert zwi -

schen 0 und 1 normalisiert werden.

● public Number getMinValue()

Hier muss der minimale Wert der Regel zurückgegeben werden. Dies ist nötig,

da alle Werte während der Auswertung der Regeln auf einen Wert zwischen 0

und 1 normalisiert werden.

124


Zu implementierende Methoden von eworks.peace.rules.core.IRuleString

Wird das Interface IRuleString implementiert, so muss die Methode public String

evaluateString() implementiert werden. Hier geschehen die eigentlichen Berech-

nungen der Regel. Der Rückgabewert stellt die Auswertung der Regel dar.

5.2 Erstellen eigener Anwendungen

Es handelt sich bei PEACE um ein Framework, d. h. PEACE kann nicht einfach wie

andere Programme ausgeführt werden. Vielmehr ist PEACE für die Integration in ein

„umgebendes Programm“ konzipiert. Aus diesem Programm heraus kann nun auf die

Funktionen des Frameworks zugegriffen werden.

Da PEACE in Java implementiert wurde, ist die Integration in ein weiteres Java-Pro-

gramm sehr komfortabel. Jedoch ist die Menge der Anwendungen, in denen PEACE

benutzt werden kann, nicht auf Java-Anwendungen beschränkt. Durch die flexiblen

Schnittstellen von PEACE (XML, Plattformunabhängigkeit von Java, Möglichkeit zur

Steuerung des Programms mittels Kommandozeilenparameter) kann aus nahezu je-

der Programmiersprache heraus auf das Framework zugegriffen werden.

5.2.1 Integration in Java-Programme

Das Erstellen eines Java-Programms, welches PEACE benutzt, wird hier unter der

Benutzung der Java-IDE Eclipse1 exemplarisch dargestellt. Es kann natürlich auch

jede andere Java-IDE verwendet werden. Eclipse ist jedoch eine weit verbreitete

IDE. Auch bei der Verwendung einer anderen IDE, sollten die im folgenden beschrie-

benen Schritte ohne größere Abweichung nachvollziehbar sein.

Um PEACE in ein Java-Projekt zu integrieren, muss Java in der Version 5.0 oder hö-

her installiert sein.

1. Erstellen eines neuen Projektes

Starten Sie Eclipse und legen Sie ein neues Projekt an. Es gibt mehrere Ver-

fahren, dies zu tun, benutzen Sie beispielsweise die Einträge der Menüleiste

1 vgl. Eclipse

125


(File -> New -> Project...). Wählen Sie in dem sich öffnenden Fenster Java

Project als Art des Projektes aus. Sie können PEACE auch in anderen Pro-

jektarten (z. B. in Plug-in Projekten) benutzen, in diesem Fall kann die weitere

Vorgehensweise jedoch von der hier beschriebenen abweichen. Klicken Sie

auf Next, geben Sie einen Namen für das Projekt ein und klicken Sie auf

Finish.

2. Integration von PEACE

Klicken Sie das soeben erstellte Projekt mit der rechten Maustaste an und

wählen Sie New -> Folder, um einen Ordner zu erstellen, in den externe JAR-

Dateien importiert werden können. Geben Sie dem Ordner einen Namen, bei-

spielsweise „lib“ und klicken Sie auf Finish.

126

Abbildung 5.1: Eclipse: Erstellen eines Projekts


Klicken Sie den soeben erstellten Ordner mit der rechten Maustaste an und

wählen Sie Import. In dem sich öffnenden Fenster wählen Sie File System

und klicken auf Next. Im nächsten Fenster klicken Sie auf Browse und durch-

suchen ihre Festplatte nach dem Ordner, in dem sich die Datei PEACE.jar be-

findet. Markieren Sie die Checkbox der Datei PEACE.jar mit einem Häkchen

und klicken Sie auf Finish.

Klicken Sie erneut mit der rechten Maustaste auf das Projekt und wählen Sie

Properties. Im Abschnitt Java Build Path wählen Sie den Reiter Libraries. Kli-

cken Sie auf Add JARs... und wählen Sie die Datei PEACE.jar in dem von Ih-

nen erstellten Ordner des von Ihnen erstellten Projekts. Klicken Sie zweimal

auf OK um zum Hauptfenster von Eclipse zurückzugelangen.

127

Abbildung 5.2: Eclipse: PEACE.jar importieren


PEACE ist nun in ihrem Projekt integriert und Sie können auf die Funktionen

des Frameworks zugreifen.

3. Zugriff auf das Framework

Greifen Sie auf die Funktionen des Frameworks über die statischen Methoden

der Klasse eworks.peace.PEACE zu. Wie dies genau funktioniert entnehmen

Sie bitte Kapitel .

Führen Sie Ihr Programm zum ersten Mal aus, so werden Sie feststellen, dass

eine Exception vom Typ XMLSchemaNotFoundException geworfen wird. Dies

liegt daran, dass das System die benötigten XML-Schema-Dateien nicht an

der angenommenen Stelle finden kann. Kopieren Sie diese Dateien

(peace_config.xsd, peace_input.xsd, peace_output.xsd) in den in der Meldung

der Exception angegebenen Ordner und starten Sie das Programm erneut.

128

Abbildung 5.3: Eclipse: PEACE verfügbar ma-

chen


5.2.2 Integration in Programme anderer Programmiersprachen

Die meisten Programmiersprachen bieten eine Möglichkeit um externe Programme

auszuführen. Nutzen Sie diese Möglichkeit, um aus anderen Programmiersprachen

heraus auf PEACE zuzugreifen. Um die Funktionen des Frameworks nutzen zu kön-

nen, muss Java in der Version 5.0 oder höher installiert sein.

Die Art und Weise, wie ein externes Programm ausgeführt werden kann, unterschei-

det sich von Programmiersprache zu Programmiersprache. Entnehmen Sie dies bitte

der jeweiligen Dokumentation. Grundsätzlich muss jedoch der Befehl java -jar

PEACE.jar {Konfigurationsdatei} {Inputdateien} ausgeführt werden. Dabei ist zu

beachten, dass evtl. der gesamte Pfad zur JAR-Datei angegeben werden muss und

die Konfigurationsdatei bzw. die Inputdateien den jeweiligen XML-Schemata entspre-

chen. Der gesamte Befehl könnte also lauten:

java -jar C:\Programme\PEACE.jar D:\Daten\Peace\config.xml D:\Daten\Peace\input1.xml D:\Daten\Peace\input2.xml

Dabei wird vorausgesetzt, dass die Datei D:\Daten\Peace\config.xml dem XML-Sche-

ma peace_config.xsd entspricht und dass die Dateien D:\Daten\Peace\input1.xml

und D:\Daten\Peace\input2.xml dem XML-Schema peace_input.xsd entsprechen.

Um die Funktionsweise der Integration von PEACE in ein Programm einer anderen

Programmiersprache zu demonstrieren, wird im folgenden die Entwicklung eines klei-

nen Programms am Beispiel des Microsoft .NET-Frameworks und der Programmier-

sprache C# beschrieben. Je nach gewählter Programmiersprache und Entwicklungs-

umgebung kann die Integration von PEACE in ein Programm mehr oder weniger

stark von der hier beschriebenen Vorgehensweise abweichen.

1. Öffnen Sie Microsoft Visual Studio und erstellen Sie ein neues C# Projekt, bei-

spielsweise eine Konsolenanwendung.

2. Erzeugen Sie an einer beliebigen Stelle im Programm eine neue Instanz der

Klasse System.Diagnostics.Process, beispielsweise mit dem Befehl Process

process = new Process(); wobei Sie in diesem Fall den Namespace

System.Diagnostics mittels using System.Diagnostics; importieren müssen.

129


3. Setzen Sie die folgenden Eigenschaften des Prozesses, um zu erreichen,

dass die Ausgabe, die Fehlermeldungen und die Eingabe von PEACE umge-

leitet werden kann:

process.StartInfo.RedirectStandardError = true;process.StartInfo.RedirectStandardInput = true;process.StartInfo.RedirectStandardOutput = true;process.StartInfo.UseShellExecute = false;

4. Legen Sie das Programm fest, welches aufgerufen werden soll. Dabei handelt

es sich um Java, da PEACE selbst von Java aufgerufen wird.

process.StartInfo.FileName = "java";

5. Legen Sie die Argumente fest, mit denen das Programm aufgerufen werden

soll. Hier müssen Sie den Pfad von PEACE angeben sowie die Argumente,

die an PEACE übergeben werden sollen.

process.StartInfo.Arguments = "-jar C:\\Programme\\PEACE.jar D:\\Daten\\Peace\config.xml D:\\Daten\\Peace\\input1.xml D:\\Daten\\Peace\\input2.xml";

6. Starten Sie das externe Programm mittels process.Start();

7. Geben Sie an, was mit dem Ouput des Programms geschehen soll. Sie kön-

nen Ihn beispielsweise einfach auf der Kommandozeile ausgeben lassen.

Console.WriteLine(process.StandardOutput.ReadToEnd());Console.WriteLine(process.StandardError.ReadToEnd());

8. Beim ersten Starten des Programms werden Sie feststellen, dass eine

Exception vom Typ XMLSchemaNotFoundException geworfen wird.

Kopieren Sie die XML-Schema-Dateien von PEACE in den Ordner, der in der

Fehlermeldung angegeben ist, und starten Sie das Programm erneut.

130

Abbildung 5.4: Visual Studio: Fehlermeldung bei fehlender XML-Schema-Datei


5.3 Beispielanwendung

Im Folgenden wird ein Java-Programm beschrieben, das ebenfalls im Rahmen die-

ser Diplomarbeit entstanden ist. Es handelt sich dabei um ein Programm zu Testzwe-

cken. Es soll demonstrieren, wie PEACE dazu eingesetzt werden kann, um Kon-

taktanfragen nach verschiedenen Kriterien zu klassifizieren.

5.3.1 Beschreibung der Anwendung

An dieser Stelle soll nicht wiederholt werden, wie man ein Java-Programm erstellt

und in dieses PEACE integriert. Vielmehr sollen die Funktionen des Programms und

die Bedienung der Anwendung erläutert werden.

Die Beispielanwendung wurde mittels der Java-IDE Eclipse erstellt. Es handelt sich

dabei um ein Eclipse Plug-in bzw. um eine Eclipse RCP2 Application. Um die Bei-

spielanwendung auszuführen, muss lediglich Java in der Version 5.0 oder höher in-

stalliert sein, eine Installation von Eclipse ist nicht erforderlich. Die Beispielanwen-

dung kann derzeit leider nur auf Windows Betriebssystemen ausgeführt werden, dies

betrifft allerdings nur die Beispielanwendung, das Framework PEACE an sich ist

plattformunabhängig.

Die Anwendung enthält eine grafische Oberfläche, die die Haupt-Schnittstelle zum

Programm darstellt.

2 Rich Client Platform, vgl. EclipsepediaRCP

131

Abbildung 5.5: Visual Studio: Erfolgreicher Aufruf von PEACE


Das Hauptfenster kann grob in drei Bereiche aufgeteilt werden. Im oberen Bereich

können die Konfigurationsdatei und die Inputdateien ausgewählt werden.

Im linken Bereich findet sich die Auswertung der Inputdateien in Tabellenform. Dabei

wird für jede Datei die Professionalität (P), die Kommunikationsfähigkeit (C), die Er-

folgswahrscheinlichkeit (S), die Moral (M) und die Dringlichkeit (U) berechnet. Ist das

jeweilige Kriterium besonders positiv zu bewerten, so erscheint ein „+“ in der entspre-

chenden Spalte. Ist es besonders negativ zu bewerten, erscheint ein „-“. Handelt es

sich um einen mittleren Wert, so erscheint nichts in der entsprechenden Spalte. Wei-

terhin befindet sich im unteren Bereich ein Button, mit dem es möglich ist, die Liste

der aktuell ausgewerteten Inputdateien zu löschen.

Im rechten Bereich existieren zwei Reiter. Der erste Reiter („Source“) zeigt den Inhalt

der in der linken Tabelle markierten Inputdatei an. Der zweite Reiter ( „Evaluation“)

zeigt die Auswertung der in der linken Tabelle markierten Inputdatei als XML an.

132

Abbildung 5.6: Beispielanwendung: Hauptfenster


Um mit der Auswertung von Regeln zu beginnen, muss zunächst eine Konfigurati-

onsdatei gewählt werden. Dies geschieht über den ersten der beiden Buttons. Falls

die gewählte Datei nicht dem XML-Schema entspricht oder ein anderer Fehler auf-

tritt, erscheint eine Messagebox, die auf den Fehler und seine Ursache hinweist.

Kann die Konfigurationsdatei erfolgreich validiert und das entsprechende Datenmo-

dell erstellt werden, so wird der Name und der Pfad der aktuellen Konfigurationsdatei

hinter Config File: angegeben.

Nun können eine oder mehrere Inputdateien gewählt werden. Dies geschieht über

den zweiten Button. Es werden alle gewählten Dateien gegen das XML-Schema

peace_input.xsd validiert. Falls alle korrekt sind, wird mit der Auswertung begonnen.

Es können später auch noch weitere Dateien zur Auswertung hinzugefügt werden.

Hinter Input File: wird die Anzahl aller evaluierten Dateien angezeigt.

Sollte versucht werden, eine oder mehrere Inputdateien auszuwählen, ohne dass

vorher eine valide Konfigurationsdatei spezifiziert wurde, so erscheint statt des

Öffnen-Dialogs eine Messagebox, die darauf hinweist, dass zunächst eine valide

Konfigurationsdatei ausgewählt werden muss.

133

Abbildung 5.7: Beispielanwendung: Fehler in der Konfigurationsdatei

Abbildung 5.8: Beispielanwendung: Konfigurationsdatei erfolgreich validiert und geparst


Wird eine Inputdatei gewählt, die nicht dem XML-Schema entspricht oder wird keine

Datei ausgewählt, so werden alle bisherigen Auswertungen zurückgesetzt, auch

jene, die schon in früheren Schritten hinzugefügt wurden. In diesem Fall wird eben-

falls eine Messagebox mit einer entsprechenden Meldung erscheinen.

Sind alle gewählten Dateien valide, so beginnt die Auswertung der Regeln. Ist die

Auswertung für alle Inputdateien abgeschlossen, so werden die Namen aller gewähl-

ten Dateien mit einer kurzen Zusammenfassung der Ergebnisse in der Tabelle im lin-

ken Bereich angezeigt. Die Zusammenfassung beschränkt sich in diesem Fall ledig-

lich auf ein „+“ bzw. ein „-“ für das jeweilige Kriterium. Zusätzlich werden besser be-

wertete Inputdateien durch eine fette Schrift hervorgehoben, während schlechter be-

wertete mittels einer verblassten grauen Schriftfarbe dargestellt werden. Mittlere Er-

gebnisse werden mit normalen Schrifteigenschaften angezeigt.

134

Abbildung 5.9: Beispielanwendung: Keine Konfigurationsdatei ausgewählt

Abbildung 5.10: Beispielanwendung: Fehler in einer Inputdatei


Markiert man eine Inputdatei, so werden im rechten Bereich nähere Informationen zu

dieser angezeigt. Unter dem Reiter Source befindet sich der Inhalt der Inputdatei.

An dieser Stelle sei noch einmal darauf hingewiesen, dass es sich hierbei um eine

Beispielanwendung mit exemplarischen Regeln und Workflows handelt. Die gesamte

Anwendung, insbesondere die graphische Oberfläche, stellt nur ein Muster für einen

spezifischen Anwendungsfall dar. Sie kann und sollte für den jeweiligen Zweck belie-

big geändert bzw. selbst implementiert werden.

135

Abbildung 5.11: Beispielanwendung: Übersicht über Inputdateien


Zusätzlich dazu findet man unter dem Reiter Evaluation die Auswertung der jeweilig

markierten Inputdatei.

136

Abbildung 5.12: Beispielanwendung: Inhalt der Inputdatei

Abbildung 5.13: Beispielanwendung: Auswertung einer Inputdatei


5.3.2 Testdaten

Bei den Testdaten handelt es sich um echte Kontaktanfragen, die in dem Zeitraum

von August bis Dezember 2007 an die Firma eWorks gestellt wurden. Diese Daten

wurden anonymisiert, sodass gegen keine eventuellen Datenschutzgesetze versto-

ßen wird. Die Anonymisierung betraf vor allem Namen, E-Mailadressen, postalische

Adressen und URLs von Webseiten. Es wurde darauf geachtet, dass die Struktur der

Daten erhalten blieb. Wenn vor der Anonymisierung beispielsweise in einer E-Mail -

adresse der Vor- und Nachname des Kontaktpartners in der E-Mailadresse erhalten

war, so enthält die anonymisierte E-Mailadresse ebenfalls den (fiktiven) Vor- und

Nachnamen.

Die Kontaktanfragen gingen per E-Mail bei eWorks ein. Dabei gab es zwei Quellen:

Zum einen handelt es sich um E-Mails, die von einem Kontaktformular auf einer der

Internetseiten des Unternehmens verschickt wurden, zum anderen sind es normale

E-Mails, also E-Mails, die von dem jeweiligen Kontaktpartner mittels eines E-Mailpro-

gramms erstellt und versendet wurden. Die Struktur von E-Mails dieser beiden Quel-

len ist sich jedoch so ähnlich, dass alle Anfragen durch kleine Anpassungen in die

gleiche Inputstruktur überführt werden konnten. Die Struktur enthält die folgenden

Felder:

● „firstname“

Dies ist der Vorname des Kontakpartners. Im Kontaktformular existiert ein ent-

sprechendes optionales Feld. Aus E-Mails, die nicht von einem Kontaktformu-

lar versendet wurden, wurde der Vorname aus der Grußformel am Ende der

Nachricht kopiert. Dabei wurde angenommen, dass der Kontaktpartner das

Feld „Vorname“ des Formulars ausgefüllt hätte, falls er seinen Vornamen in

der Grußformel angegeben hat. War der Vorname in der Grußformel bzw. in

dem entsprechenden Feld im Formular nicht angegeben, so wurde dieses

Feld leer gelassen.

137


● „lastname“

Dies ist der Nachname des Kontaktpartners. Im Kontaktformular existiert ein

entsprechendes optionales Feld. Aus E-Mails, die nicht von einem Kontaktfor-

mular versendet wurden, wurde der Nachname aus der Grußformel am Ende

der Nachricht kopiert. Dabei wurde angenommen, dass der Kontaktpartner

das Feld „Nachname“ des Formulars ausgefüllt hätte, falls er seinen Nachna-

me in der Grußformel angegen hat. War der Nachname in der Grußformel

bzw. in dem entsprechenden Feld im Formular nicht angegeben, so wurde

dieses Feld leer gelassen.

● „from“

Bei diesem Feld handelt es sich um die Absenderadresse der E-Mail bzw. um

die im entsprechenden Feld des Formulars angegebene E-Mailadresse.

● „to“

Dieses Feld beinhaltet die Empfängeradresse der E-Mail, unabhängig davon,

ob es sich um eine manuell oder von einem Formular versendete E-Mail han-

delt.

● „date“

Hierbei handelt es sich um Sendedatum der E-Mail bzw. um den Zeitpunkt, zu

dem die Inhalte des Formulars abgeschickt wurden.

● „subject“

Dies ist der Betreff der E-Mail, unabhängig davon, ob es sich um eine manuell

oder von einem Formular versendete E-Mail handelt.

● „content“

Bei diesem Feld handelt es sich um die eigentliche Nachricht. Bei einer manu-

ell versendeten E-Mail entspricht dies dem Textkörper. Bei einer von einem

Kontaktformular versendeten E-Mail handelt es sich um den Inhalt eines ent-

sprechenden Formularfeldes.

138


5.3.3 Konfigurationsdatei

Dieser Abschnitt beschreibt die exemplarische Konfigurationsdatei der Beispielan-

wendung. Sie kann an den jeweiligen Anwendungszweck bzw. die fachliche Domäne

angepasst oder gar neu erstellt werden.

Die Konfigurationsdatei umfasst insgesamt fünf Workflows.

● Professionality bewertet die Professionalität einer Kontaktanfrage. Die Ein-

stiegsregel ist ProfessionalityRule.

● CommunicationSkill bewertet die Kommunikationsfähigkeiten eines Kontakt-

partners. Die Einstiegsregel ist CommunicationSkillRule.

● Success bewertet die Erfolgswahrscheinlichkeit eines Auftrags. Die Einstiegs-

regel ist SuccessRule.

● Morality bewertet moralische Aspekte einer Kontaktanfrage. Die Einstiegsre-

gel ist MoralityRule.

● Urgency bewertet die Dringlichkeit einer Anfrage. Die Einstiegsregel ist

UrgencyRule.

Entsprechend der fünf Workflows existieren fünf Regeln, die als Einstiegspunkte die-

nen.

● ProfessionalityRule kombiniert die folgenden Regeln:

○ FreeMailerRule wertet aus, ob der Absender eine Freemailer-Adresse be-

nutzt.

○ EmailNameRule wertet aus, ob der Vor- oder der Nachname oder beide in

der E-Mailadresse vorkommen.

○ DomainCountryRule wertet das Länderkürzel der E-Maildomain aus.

○ LegalFormRule wertet die Rechtsform des kontaktierenden Unternehmens

aus.

● CommunicationSkillRule kombiniert die folgenden Regeln:

139


○ SalutationsRule wertet aus ob die Anrede und die Grußformel bestimmten

Regeln entsprechen.

○ WorkTimeRule wertet das Datum und die Uhrzeit der Anfrage aus.

○ EmptySubjectRule wertet aus, ob der Betreff leer ist.

○ EmptyFirstnameRule wertet aus, ob das Feld „firstname“ leer ist.

○ EmptyLastnameRule wertet aus, ob das Feld „lastname“ leer ist.

● SuccessRule kombiniert die folgenden Regeln:

○ DateInYearRule wertet aus, zu welchem Zeitpunkt im Jahr die Anfrage ge-

stellt wurde.

○ ReceiverRule wertet aus, an welche E-Mailadresse die Anfrage geschickt

wurde, bzw. von welchem Formular aus die Anfrage geschickt wurde.

○ NearnessRule bewertet die räumliche Nähe zum Kontaktpartner.

○ SuccessKeywordRule sucht nach bestimmten Schlüsselwörtern in der

Nachricht.

● MoralityRule besteht aus der Regel XXXKeywordRule, die auswertet, ob in

der Nachricht bestimmte Schlüsselwörter enthalten sind, die darauf hinweisen,

dass es sich um moralisch fragliche Inhalte handelt.

● UrgencyRule durchsucht die Nachricht nach bestimmten Schlüsselwörtern,

die auf eine hohe Dringlichkeit hinweisen.

Quelltext der Konfigurationsdatei


<config>

<Rules>

<Rule name="WorkTimeRule"><apply-rule-numeric

type="java"source="eworks.peace.rules.WorkTimeRule"><with-param

name="date" source="field" value="date" />

140


</apply-rule-numeric></Rule>

<Rule name="FreeMailerRule"><apply-rule-numeric

type="java"source="eworks.peace.rules.MailDomainRule"><with-param

name="email" source="field" value="from" /><with-param-dictionary name="list" source="const">

<dictionary-element key="web.de" value="1" /><dictionary-element key="gmx.de" value="1" /><dictionary-element

key="arcor.de" value="0.5" /><dictionary-element

key="t-online.de" value="0.5" /><dictionary-element

key="aon.at" value="0.5" /></with-param-dictionary>


<Rule name="EmptyFieldRule"><param name="input" type="String" /><apply-rule-numeric

type="java"source="eworks.peace.rules.TextLengthRule"><with-param

name="content" source="param" value="input" /><with-param

name="boolean" source="const" value="true" /><with-param

name="expected-length"source="const" value="0" />


<Rule name="EmptySubjectRule"><apply-rule-numeric

type="xml" source="EmptyFieldRule"><with-param

name="input" source="field" value="subject" /></apply-rule-numeric>

</Rule>

<Rule name="EmptyFirstnameRule"><apply-rule-numeric


name="input"source="field" value="firstname" />


<Rule name="EmptyLastnameRule"><apply-rule-numeric

141



name="input"source="field" value="lastname" />


<Rule name="EmailNameRule"><apply-rule-numeric

type="java"source="eworks.peace.rules.EmailNameRule"><with-param

name="email" source="field" value="from" /><with-param

name="firstname"source="field" value="firstname" />

<with-paramname="lastname"source="field" value="lastname" />


<Rule name="SuccessKeywordRule"><apply-rule-numeric

type="java"source="eworks.peace.rules.TextSearchRule"><with-param

name="input" source="field" value="content" /><with-param

name="whole-word"source="const" value="true" />

<with-param-dictionaryname="words" source="const"><dictionary-element

key="Ausschreibung" value="-1" /><dictionary-element

key="Videothek" value="-0.25" /><dictionary-element

key="Partnerprogramm" value="-1" /><dictionary-element

key="empfohlen worden von" value="1" /><dictionary-element

key="Telefonat" value="1" /></with-param-dictionary>


<Rule name="XXXKeywordRule"><apply-rule-numeric


name="input" source="field" value="content" /><with-param-dictionary

name="words" source="const"><dictionary-element key="EEEEEE" value="1" />

142


<dictionary-element key="SSS" value="1" /><dictionary-element key="FSK18" value="1" />

</with-param-dictionary></apply-rule-numeric>

</Rule>

<Rule name="DateInYearRule"><apply-rule-numeric

type="java"source="eworks.peace.rules.RequestDateRule"><with-param

name="date" source="field" value="date" /><with-param-dictionary

name="evaluations" source="const"><dictionary-element key="Januar" value="2" /><dictionary-element key="Februar" value="1" /><dictionary-element key="März" value="0" /><dictionary-element key="April" value="-1" /><dictionary-element key="Mai" value="-2" /><dictionary-element key="Juni" value="-3" /><dictionary-element key="Juli" value="-2" /><dictionary-element key="August" value="-1" /><dictionary-element

key="September" value="0" /><dictionary-element key="Oktober" value="1" /><dictionary-element

key="November" value="2" /><dictionary-element

key="Dezember" value="3" /></with-param-dictionary>


<Rule name="ReceiverRule"><apply-rule-numeric


name="input" source="field" value="to" /><with-param-dictionary

name="words" source="const"><dictionary-element

key="[email protected]" value="5" /><dictionary-element

key="[email protected]" value="4" /><dictionary-element

key="[email protected]"value="4" />

<dictionary-elementkey="[email protected]"value="3" />

<dictionary-elementkey="[email protected]" value="3" />

<dictionary-elementkey="[email protected]" value="1" />

</with-param-dictionary>

143



<Rule name="DomainCountryRule"><apply-rule-numeric

type="java"source="eworks.peace.rules.MailDomainRule"><with-param

name="email" source="field" value="from" /><with-param-dictionary

name="list" source="const"><dictionary-element

key="*.de.ru" value="-2" /><dictionary-element

key="*.de.am" value="-2" /><dictionary-element

key="*.de.cx" value="-2" /><dictionary-element

key="*.de.tt" value="-2" /><dictionary-element

key="*.de.vu" value="-2" /><dictionary-element

key="*.tv" value="-1" /></with-param-dictionary>


<Rule name="SalutationsRule"><apply-rule-numeric

type="java"source="eworks.peace.rules.PolitenessRule"><with-param

name="message"source="field" value="content" />

<with-param-dictionaryname="greetings" source="const"><dictionary-element

key="hallo" value="0.3" /><dictionary-element

key="sehr geehrte damen und herren"value="0.8" />

<dictionary-elementkey="lieber" value="0.35" />

<dictionary-elementkey="guten tag" value="0.65" />

<dictionary-elementkey="sehr geehrter herr" value="1" />

</with-param-dictionary><with-param-dictionary

name="leavetakings" source="const"><dictionary-element

key="mit freundlichen grüßen"value="1" />

<dictionary-elementkey="grüße" value="0.4" />

<dictionary-element

144


key="gruß" value="0.4" /><dictionary-element

key="mit besten grüßen" value="0.75" /><dictionary-element key="mfg" value="0.35" />


</Rule>

<Rule name="LegalFormRule"><apply-rule-numeric



name="case-sensitive"source="const" value="true" />

<with-paramname="whole-word"source="const" value="true" />

<with-param-dictionaryname="words" source="const"><dictionary-element key="AG" value="1" /><dictionary-element key="GmbH" value="1" /><dictionary-element key="OHG" value="0.7" /><dictionary-element key="oHG" value="0.7" /><dictionary-element key="GbR" value="0.5" /><dictionary-element key="Ltd" value="0.3" /><dictionary-element

key="Limited" value="0.3" /><dictionary-element key="INC" value="0.2" />


</Rule>

<Rule name="NearnessRule"><apply-rule-numeric

type="java"source=

"eworks.peace.rules.GeographicalNearnessRule"><with-param

name="text" source="field" value="content" /><with-param

name="reference-zip"source="const" value="60318" />


<Rule name="ProfessionalityRule"><RuleAddition>

<apply-rule-numerictype="xml"source="FreeMailerRule" factor="-1" />

<apply-rule-numerictype="xml"source="EmailNameRule" factor="0.75" />

145


<apply-rule-numerictype="xml" source="DomainCountryRule" />

<apply-rule-numerictype="xml" source="LegalFormRule" />

</RuleAddition></Rule>

<Rule name="MoralityRule"><apply-rule-numeric

type="xml" source="XXXKeywordRule" factor="-1" /></Rule>

<Rule name="UrgencyRule"><apply-rule-numeric

type="java"source="eworks.peace.rules.UrgencyRule"><with-param


name="date" source="field" value="date" /></apply-rule-numeric>

</Rule>

<Rule name="SuccessRule"><RuleAddition>

<apply-rule-numerictype="xml"source="DateInYearRule" factor="0.25" />

<apply-rule-numerictype="xml"source="ReceiverRule" factor="1.5" />

<apply-rule-numerictype="xml" source="NearnessRule" />

<apply-rule-numerictype="xml" source="SuccessKeywordRule" />


<Rule name="CommunicationSkillRule"><RuleAddition>

<apply-rule-numerictype="xml" source="SalutationsRule" />

<apply-rule-numerictype="xml" source="WorkTimeRule" factor="-1"/>

<apply-rule-numerictype="xml"source="EmptySubjectRule" factor="-1" />

<apply-rule-numerictype="xml"source="EmptyFirstnameRule" factor="-1" />

<apply-rule-numerictype="xml"source="EmptyLastnameRule" factor="-1" />


146


</Rules>

<Workflows><Workflow

display-name="Professionality"entry-point="ProfessionalityRule" />

<Workflowdisplay-name="CommunicationSkill"entry-point="CommunicationSkillRule" />

<Workflowdisplay-name="Success"entry-point="SuccessRule" />

<Workflowdisplay-name="Morality"entry-point="MoralityRule" />

<Workflowdisplay-name="Urgency"entry-point="UrgencyRule" />

</Workflows></config>

Trotz der relativ geringen Anzahl der Basisregeln ist eine recht komplexe Konfigurati -

on für die Bewertung von Kontaktanfragen entstanden. Diese könnte natürlich noch

um eine beliebige Anzahl weiterer Regeln erweitert werden, um noch bessere Ergeb-

nisse zu erzielen. Auch im aktuellen Stadium erleichtert die Software dem Empfänger

der Kontaktanfragen die Entscheidungsfindung schon erheblich, denn ohne sie

müsste er alle Regeln objektiv und ohne Hilfsmittel überprüfen, was bei einer größe-

ren Menge von Anfragen kaum realistisch ist. Das System ist also trotz seiner Unvoll-

ständigkeit und des „Prototyp“-Status schon recht leistungsfähig.

5.3.4 Auswertung

Aufgrund des zeitlich begrenzten Rahmens der Diplomarbeit war es möglich, nur

eine relativ geringe Anzahl von Regeln zu implementieren. Auch die Komplexität der

einzelnen Regeln ist eher niedrig. Trotzdem ist es gelungen eine kleine Menge von

Testdokumenten zufriedenstellend zu klassifizieren. Die Bandbreite der einzelnen

Kategorien (repräsentiert durch die Workflows) wurde dabei sehr gut ausgenutzt, das

heißt, es existierte für jede Kategorie jeweils mindestens eine Kontaktanfrage, die

einen sehr hohen Wert, eine, die einen sehr niedrigen Wert, sowie eine, die einen

mittleren Wert erzielte.

147


Die Beispielanwendung hat gezeigt, dass die Grundfunktionalität des Systems gege-

ben ist. Des Weiteren existieren Erweiterungsmöglichkeiten, die genutzt werden

müssten, um das Framework in zukünftigen Versionen, zum einen durch Hinzufügen

neuer Regeln und zum anderen durch Erweitern der bestehenden Regeln, zu einem

universellen Klassifizierungstool für Kontaktanfragen zu entwickeln.

Weiterhin ist festzustellen, dass die Oberfläche der Beispielanwendung sehr schlicht

und funktional gehalten ist, daher ist die Bedienung des Programms recht einfach zu

erlernen.

5.4 Anwendungsszenarien

Die folgende Tabelle verdeutlicht die Einsatzmöglichkeiten von PEACE.

148

5.4 Anwendungsszenarien

Fachliches EinsatzgebietAkquise Bewerbung Support

Mögliche Kriterien

Erfolgswahrscheinlich-

keit, Seriosität, Dringlich-

keit, etc.

„Soft Skills“, „Hard

Skills“, Qualifikation, etc.

Kenntnisse des Nutzers,

Schwere des Fehlers,

etc.

Eing

eset

zte

Tech

nolo

gie

Web-

Kontakt-Formular

Projektanfragen werden

über ein Kontaktformular

gestellt und von PEACE

klassifiziert (siehe Bei-

spielanwendung, Kapitel

5.3).

Bewerbungen werden



klassifiziert.

Supportanfragen werden



klassifiziert.

Web-

Umfrage-Formular

- Bewerber benotet seine

Fähigkeiten. Evtl. kann

bei bestimmten Antwor-

ten nachgefragt werden.

Ergebnisse werden von

PEACE ausgewertet.

In Abhängigkeit von der

jeweils vorangegange-

nen Antwort werden be-

stimmte Fragen gestellt,

um das Problem einzu-

grenzen.

E-Mail-

Client-Plugin

Projektanfragen, die per

E-Mail kommen, werden

von PEACE klassifiziert

(siehe Beispielanwen-

dung, Kapitel 5.3).

Bewerbungen, die per E-

Mail kommen, werden

von PEACE klassifiziert.

Supportanfragen, die per

E-Mail kommen, werden

von PEACE klassifiziert.

Win-

dows-An-wendung

fürCallcenter

- - Anrufer beantwortet nach

und nach bestimmte Fra-

gen, die von PEACE vor-

geschlagen werden. Pro-

blem wird somit immer

weiter eingegrenzt.

Web-

Crawler

Verschiedene Web-Por-

tale bzw. Foren, in denen

Projektaufträge ausge-

schrieben werden, wer-

den nach bestimmten

Kriterien durchsucht.

Verschiedene Web-Por-

tale bzw. Foren, die Per-

sonen- oder Bewer-

bungsdaten enthalten,

werden nach bestimmten

Kriterien durchsucht.

-

Tabelle 5.1: PEACE - Anwendungsszenarien

149

6 Ausblick und Fazit

6 Ausblick und Fazit

6.1 Ausblick

Aufgrund des begrenzten zeitlichen Rahmens der Diplomarbeit konnten nicht alle

denkbaren Funktionen der Software umgesetzt werden. Im Folgenden befindet sich

eine Aufzählung der Ergänzungen, die in zukünftigen Versionen des Frameworks

umgesetzt werden könnten.

6.1.1 Erweiterungen des Frameworks

● Zur Zeit werden die Werte der Inputfelder unverändert an die jeweiligen Re-

geln weitergegeben. Hier soll in Zukunft eine Möglichkeit geschaffen werden,

die Werte zunächst zu manipulieren, bevor sie ausgewertet werden.

Es wäre beispielsweise denkbar, den Text eines Feldes nicht komplett mit ei-

ner Regel auszuwerten, sondern nur einen gewissen Teil. Dies wäre z. B. für

die Regel „PolitenessRule“ (siehe Kapitel 4.5.9) von Vorteil, da dieser Regel

dann nur noch die entsprechenden Abschnitte der Nachricht (Anrede und

Grußformel) übergeben werden könnten.

Es ließen sich jedoch auch Funktionen anderer Art entwickeln, beispielsweise

mathematische oder logische.

● Bislang werden alle Ausgaben der Software (Fehlermeldungen etc.) in engli-

scher Sprache getätigt. Die Meldungen sind zu internationalisieren.

● Alle bisher umgesetzten Regeln laufen von selbst ab und benötigen keine wei-

tere Eingaben des Benutzers. Das Framework soll dahingehend erweitert wer-

den, dass interaktive bzw. asynchrone Regeln realisierbar sind. Hier ist ein

Konzept zu entwickeln, das es ermöglicht, dass ein Regelwerk nur zum Teil

ausgewertet wird, diese Teilauswertung zwischengespeichert wird und die ge-

samte Auswertung erst erfolgt, sobald die nötige Eingabe getätigt ist.

151

Kapitel 6: Ausblick und Fazit

Dieser Mechanismus kann auch benutzt werden, um beispielsweise Regeln

einzusetzen, die auf Internet-Dienste angewiesen sind. Sollte der Dienst nicht

verfügbar sein, so wird die Teilauswertung zwischengespeichert und erst ver-

vollständigt, sobald die Nutzung des Dienstes erfolgreich war.

6.1.2 Neue Regeln und Ergänzungen zu bestehenden Regeln

● Die Regel „SpellCheckRule“ könnte neu eingeführt werden. Sie wird dazu be-

nutzt um die Rechtschreibung einer Nachricht zu überprüfen. Leider konnte

eine entsprechende Funktionsbibliothek oder ein Webservice nicht gefunden

werden. Bei dieser Regel ist zu beachten, dass die Sprache einer Nachricht in

vielen Fällen nicht im Vorfeld festgelegt werden kann.

● Zwecks einer erweiterten Nutzung der „WorkTimeRule“ (siehe Kapitel 4.5.2)

könnte ein Kalender (z. B. im iCalendar-Format1) importiert, und somit die Be-

wertung auf Feiertage ausgeweitet werden.

● Die Regel „GegraphicalNearnessRule“ (siehe Kapitel 4.5.10) berechnet aus

einer hinterlegten Postleitzahl und einer weiteren, durch eine Heuristik aus der

Nachricht extrahierten Postleitzahl, die ungefähre Entfernung des Anfragestel-

lers. Dies geschieht zur Zeit noch durch die einfache Subtraktion beider Wer-

te. Hier empfiehlt es sich eine andere Möglichkeit zu wählen, beispielsweise

die Nutzung eines entsprechenden Webservice, der die Entfernung in Kilome-

tern berechnen kann.

6.2 Fazit

Als Inhaber einer E-Mailadresse sieht man sich heutzutage einer Flut von uner-

wünschten Kontaktaufnahmen ausgesetzt. Nach wie vor handelt es sich dabei zum

großen Teil um Spam. Die Bekämpfung von Spam ist jedoch nicht der Fokus dieser

Arbeit. Es existieren hierfür schon eine Reihe von Lösungen, wobei die Versender

von Spam immer ausgefeiltere Techniken verwenden. Dadurch entsteht ein Wettlauf

zwischen Spammern und Entwicklern von Anti-Spam-Tools. Zur Zeit ist es so, dass 1 vgl. iCalendar

152

6.2 Fazit

die Software-Lösungen recht stabil arbeiten, der menschliche Bearbeiter jedoch nicht

um einen Blick in den Spam-Ordner seines E-Mailpostfachs herum kommt, da es im-

mer wieder normale E-Mails gibt, die fälschlicherweise als Spam klassifiziert werden.

Umgekehrt landen auch einige Spam-E-Mails im normalen Posteingang. Hinzu

kommt, dass es auch bei den E-Mails, die nicht als Spam bezeichnet werden kön-

nen, eine große Anzahl unerwünschter Nachrichten gibt.

Wie in Kapitel 1.3 erläutert wurde, ist die Anzahl der wirklich wertvollen E-Mails

(Information Nuggets) im Verhältnis zu allen anderen E-Mails (also Information

Garbage und Spam) sehr gering. Ziel ist es also, den menschlichen Bearbeiter zu-

mindest bei der Unterscheidung zwischen Information Nuggets und Information

Garbage zu unterstützen.

Bei Kontaktanfragen handelt es sich um unstrukturierte bzw. semi-strukturierte Texte.

Für die Erfassung, Organisation, Analyse und Klassifikation strukturierter Daten exis-

tieren gegenwärtig schon einige robuste Theorien und Algorithmen. Jedoch ist die

Verarbeitung unstrukturierter Daten, beispielsweise natürlich-sprachlicher Texte, we-

sentlich komplexer und momentan unausgereifter. Die große Problematik liegt hier in

der Erfassung der Semantik. Gerade Homonyme oder Synonyme stellen die aktuel-

len Systeme vor eine große Hürde, wie in Kapitel 2.3 verdeutlicht wurde.

Die im Rahmen der Diplomarbeit untersuchten Softwareprodukte (siehe Kapitel 3.1)

sind zum größten Teil Data Mining-Werkzeuge, also Werkzeuge für die Verarbeitung

strukturierter Daten. Auch aus dem Bereich Natural Language Processing sind einige

Programme vorhanden. Die Problematik hierbei ist, dass in den meisten Fällen die

natürlich-sprachlichen Texte englisch sein müssen, um von diesen Systemen verar-

beitet werden zu können. Die meisten der Softwareprodukte sind zudem sehr kom-

plex und nicht speziell für die Klassifizierung von Kontaktanfragen entwickelt. Sollte

ein solches Produkt also für diesen Zweck zum Einsatz kommen, so hat der Benut-

zer zunächst eine relativ aufwändige Einarbeitungsphase zu absolvieren, bevor sich

die Vorteile des Produkts bezahlt machten.

153

Kapitel 6: Ausblick und Fazit

Wie in Kapitel 4 geschildert, verfolgt das Framework PEACE einen anderen Ansatz

als die vorgestellten Softwareprodukte. Es basiert auf einem Regelsystem, das ge-

genwärtig noch vom Benutzer zu erstellen ist. In zukünftigen Versionen könnten ma-

schinelle Lernverfahren integriert werden, sodass das Regelsystem automatisch er-

stellt bzw. erweitert wird. Dabei könnten Methoden des algorithmischen Lernens in

PEACE auf zweierlei Arten zum Einsatz kommen:

● Der einfachere Fall wäre das „Lernen innerhalb einer Regel“. Es könnte bei-

spielsweise eine Regel existieren, die das Geschlecht des Kontaktpartners an-

hand des Vor- und Nachnamens ermittelt. Bei einem Irrtum der Regel könnte

der Anwender korrigierend eingreifen, wodurch die Regel „lernen“ würde.

● Der komplexere Fall wäre das „Workflow-weite Lernen“. Bei diesem Fall wür-

de das Framework selbst um eine Lernfunktionalität erweitert. Hier würden

sich die Workflows im Laufe der Zeit ändern. Es könnte sich beispielsweise

herausstellen, dass die Absenderdomains der E-Mails bezogen auf den Work-

flow „Professionality“ nicht so wichtig ist, wie ursprünglich angenommen, oder

dass eine ganz andere Regel relevant für diesen Workflow ist, die zuvor gar

nicht berücksichtigt wurde.

Das Framework benutzt zur Klassifizierung von Kontaktanfragen verschiedene Re-

geln, die beliebig miteinander kombiniert werden können, wodurch neue, komplexere

Regeln entstehen. Weiterhin existieren Workflows, die ein bestimmtes Kriterium der

Kontaktanfrage (beispielsweise die Professionalität) repräsentieren. Auch hier be-

steht in zukünftigen Versionen Erweiterungspotenzial. Beispielsweise könnte für

einen Wertebereich eines Workflows eine bestimmte Aktion festgelegt werden (z. B.

Löschen der Kontaktanfrage, Weiterleiten der Kontaktanfrage, Bestimmung der Prio-

rität der Anfrage, etc.), die unmittelbar nach der Auswertung ausgeführt wird.

Trotz der Unvollständigkeit des Frameworks PEACE und der geringen Anzahl von

(Basis-)Regeln hat die Beispielanwendung aus Kapitel 5.3 gezeigt, dass es bereits

mit der aktuellen Version möglich ist, ein System zu erstellen, dass dem menschli -

chen Bearbeiter die Bearbeitung von Kontaktanfragen erheblich erleichtert. Nach

154

6.2 Fazit

Meinung des Autors ist damit die Basis für die Erstellung eines mächtigen Tools zur

Klassifizierung von Kontaktanfragen geschaffen worden, vor allem durch die flexiblen

Schnittstellen des Frameworks und die einfache Erweiterbarkeit um neue Regeln.

Bis zu einem „Out-of-the-box“-Produkt ist es natürlich noch ein langer Weg. Das Ziel

eines Prototypen, nämlich die prinzipielle Machbarkeit zu demonstrieren, wurde aber

erreicht. Die geplante Anwendung erscheint machbar und das Grundgerüst dafür

existiert nun sogar bereits.

155

7 Anhang

7 Anhang

7.1 Verzeichnisstruktur der CD

Der Diplomarbeit liegt eine CD bei, deren Struktur im folgenden beschrieben wird.

● Dokumente/

Diese Verzeichnis enthält die Diplomarbeit (dieses Dokument) als PDF, sowie

die Quellcode-Dokumentation (JavaDoc) als HTML- sowie als PDF-Version.

● Onlinequellen/

Dieses Verzeichnis enthält Screenshots aller Onlinequellen zum Zeitpunkt der

Referenzierung.

● Software/

○ Beispielanwendung/

Dieses Verzeichnis enthält die Beispielanwendung als ausführbare Datei

(PEACETest.exe).

○ Binär/

Dieses Verzeichnis enthält das Framework PEACE als ausführbares Java-

Archiv (JAR).

○ Quellcode/

Dieses Verzeichnis enthält die Quellcode-Dateien des Frameworks

PEACE.

○ XML-Schemata/

Dieses Verzeichnis enthält die von PEACE benötigten XML-Schema-Datei-

en.

● Testdaten/

In diesem Verzeichnis befinden sich einige exemplarische Kontaktanfragen.

157

Kapitel 7: Anhang

7.2 Referenzen

7.2.1 Literatur

● Bae1999 Ricardo Baeza-Yates & Berthier Ribeiro-NetoModern Information RetrievalACM Press, New York, 1999

● Bas2005 Robert Basili & Alessandro MoschittiAutomatic Text Categorization – From Information Retrieval to Support Vector LearningARACNE editrice S.r.l., Rom, 2005

● Darpa DARPADefense Advanced Research Projects Agency (DARPA)http://www.darpa.mil/ (aufgerufen am: 19.12.2007)

● EclipsepediaRCP Eclipse FoundationEclipsepedia – Rich Client Platformhttp://wiki.eclipse.org/index.php/Rich_Client_Platform (aufgerufen am: 22.2.2008)

● heise071122 Jürgen KuriFührungskräfte vergeuden viel Zeit mit überflüssigen E-Mailshttp://www.heise.de/newsticker/meldung/99388/from/rss09 (aufgerufen am 7.1.2008)

● Hey2006 Gerhard Heyer, Uwe Quasthoff, Thomas WittigText Mining: Wissensrohstoff Text – Konzepte, Algorithmen, ErgebnisseW3L GmbH, Bochum / Herdecke, 2006

● ix0709132 Dr. Cai ZieglerWissen aus Wörternix, Ausgabe September 2007, S. 132 ff.

158

7.2 Referenzen

● Jac2007 Peter Jackson and Isabelle MoulinierNatural Language Processing for Online Applications – Text Retrieval, Extraction and Categorization (Second revised edition)John Benjamins Publishing Company, Amsterdam / Philadelphia, 2007

● Pel2006 Tassilo Pellegrini, Andreas BlumauerSemantic Web – Wege zur vernetzten WissensgesellschaftSpringer Verlag, Berlin / Heidelberg, 2006

● Porter Martin PorterPorter-Stemmer-Algorithmushttp://tartarus.org/~martin/PorterStemmer/def.txt (aufgerufen am: 2.11.2007)

● RapidMinerDoc Rapid-IRapidMiner Einführunghttp://rapid-i.com/content/blogcategory/10/21/lang,de/ (aufgerufen am: 19.12.2007)

● RIPROCONDoc Universität Hohenheim – Lehrstuhl ControllingInformationen zum Softwaresystem RIPROCON-CHECKhttp://www.control.uni-hohenheim.de/riprocon/index.php (aufgerufen am: 8.1.2008)

● SpiegelOnlineSynonyme Bastian SickDie Sucht nach Synonymenhttp://www.spiegel.de/kultur/zwiebelfisch/0,1518,263913,00.html (aufgerufen am: 8.3.2008)

● WekaDoc Universitiy of WaikatoWekaDochttp://weka.sourceforge.net/wekadoc/index.php/Main_Page (aufgerufen am: 19.12.2007)

● Wit2001 Ian H. Witten & Eibe FrankData Mining – Praktische Werkzeuge und Techniken für das maschinelle LernenCarl Hanser Verlag, München u. Wien, 2001

159

Kapitel 7: Anhang

7.2.2 Spezifikationen

● ARFF Attribute-Relation File Formathttp://www.cs.waikato.ac.nz/~ml/weka/arff.html

● iCalendar Internet Calendaring and Scheduling Core Object Specificationhttp://tools.ietf.org/html/rfc2445

● RDF Resource Description Frameworkhttp://www.w3.org/RDF/

7.2.3 Firmen und Organisationen

● eWorks eWorks GmbHHebelstraße 11, 60318 Frankfurt am Mainhttp://www.eworks.de

● Henley Business School – Henley Management CollegeGreenlands, Henley-on-Thames, Oxfordshire, RG9 3AU, Englandhttp://www.henleymc.ac.uk

● IBM IBM Corporation1 New Orchard Road, Armonk, New York, United States of Americahttp://www.ibm.com

● Rapid-I Rapid-I: Mierswa & Klinkenberg GbRIn der Oeverscheidt 18, 44149 Dortmundhttp://rapid-i.com

7.2.4 Software

● Eclipse Eclipse – an open developement platformhttp://www.eclipse.org

● GATE GATE – A General Architecture for Text Engineeringhttp://gate.ac.uk/

160

7.2 Referenzen

● JDOM JDOMhttp://www.jdom.org/

● OpenNLP OpenNLPhttp://opennlp.sourceforge.net/

● RapidMiner RapidMinerhttp://rapid-i.com/content/view/26/82/

● RIPROCON Risikoorientiertes Projekt-Controllinghttp://www.control.uni-hohenheim.de/riprocon/index.php

● UIMA Unstructured Information Management Architecturehttp://www.alphaworks.ibm.com/tech/uima

● Weka Weka 3: Data Mining Software in Javahttp://www.cs.waikato.ac.nz/~ml/weka/

● Xerces Xerces Java Parserhttp://xerces.apache.org/xerces-j/

7.3 Abbildungsverzeichnis

Abbildung 1.1: Spam-Ordner von Google-Mail.............................................................7

Abbildung 1.2: Kontaktformular mit CAPTCHA (Quelle: http://formhandler.eworks-on-

line.de)...........................................................................................................................9

Abbildung 1.3: Pyramide der Kontaktanfragen...........................................................10

Abbildung 2.1: Ablauf eines Information Retrieval Prozesses....................................19

Abbildung 2.2: Google-Ergebnisse für "Information Retrieval Definition", sortiert nach

Relevanz......................................................................................................................20

Abbildung 2.3: Precision und Recall...........................................................................21

Abbildung 2.4: Coverage und Novelty.........................................................................24

Abbildung 2.5: Ein endlicher Automat als Diagramm für a(b|c)*a...............................34

Abbildung 2.6: Outlook-Regeln...................................................................................40

Abbildung 2.7: Baum für Aussicht...............................................................................45

161

Kapitel 7: Anhang

Abbildung 2.8: Beispiel für einen zweidimensionalen k-NN Klassifikator...................49

Abbildung 2.9: Linear trennbare Dokumentenverteilung.............................................51

Abbildung 2.10: Nicht linear trennbare Dokumentenverteilung..................................51

Abbildung 2.11: Ablaufschema des Text Mining.........................................................55

Abbildung 3.1: Die Explorer-GUI von Weka................................................................62

Abbildung 3.2: Visualisierung der aus Kapitel bekannten Wetterdaten.....................63

Abbildung 3.3: Beispiel einer Visualisierung in RapidMiner........................................65

Abbildung 3.4: RIPROCON: Kennzahlen und Ampel.................................................69

Abbildung 3.5: RIPROCON: Eingabe von Risikoänderungen....................................69

Abbildung 4.1: Klassendiagramm: Einstiegspunkte....................................................76

Abbildung 4.2: Klassendiagramm: Konfigurationsverarbeitung..................................78

Abbildung 4.3: Klassenhierarchie eworks.peace........................................................81

Abbildung 4.4: Klassenhierarchie eworks.peace.rules.core.......................................87

Abbildung 4.5: Beispielhafte Regel-Objekthierarchie..................................................93

Abbildung 4.6: Klassenhierarchie eworks.peace.params...........................................94

Abbildung 5.1: Eclipse: Erstellen eines Projekts.......................................................126

Abbildung 5.2: Eclipse: PEACE.jar importieren........................................................127

Abbildung 5.3: Eclipse: PEACE verfügbar machen..................................................128

Abbildung 5.4: Visual Studio: Fehlermeldung bei fehlender XML-Schema-Datei....130

Abbildung 5.5: Visual Studio: Erfolgreicher Aufruf von PEACE................................131

Abbildung 5.6: Beispielanwendung: Hauptfenster....................................................132

Abbildung 5.7: Beispielanwendung: Fehler in der Konfigurationsdatei....................133

Abbildung 5.8: Beispielanwendung: Konfigurationsdatei erfolgreich validiert und ge-

parst...........................................................................................................................133

Abbildung 5.9: Beispielanwendung: Keine Konfigurationsdatei ausgewählt............134

Abbildung 5.10: Beispielanwendung: Fehler in einer Inputdatei...............................134

Abbildung 5.11: Beispielanwendung: Übersicht über Inputdateien..........................135

Abbildung 5.12: Beispielanwendung: Inhalt der Inputdatei.......................................136

Abbildung 5.13: Beispielanwendung: Auswertung einer Inputdatei..........................136

162

7.4 Tabellenverzeichnis

7.4 Tabellenverzeichnis

Tabelle 2.1: Ein endlicher Automat als Tabelle für a(b|c)*a........................................35

Tabelle 2.2: Wetterdaten.............................................................................................44

Tabelle 2.3: Beispiel für eine Wahrscheinlichkeitsverteilung bei Naive Bayes...........47

Tabelle 2.4: Arten des Lernens bei Data Mining.........................................................54

Tabelle 2.5: Zusammenfassung aktueller Technologien............................................60

Tabelle 5.1: PEACE - Anwendungsszenarien...........................................................149

7.5 API-Dokumentation der Klassen

Die folgende API-Dokumentation stammt ursprünglich aus einem anderen PDF-Do-

kument und beginnt deshalb mit einer neuen Seitennummerierung.

163

DIPLOMARBEIT - eWorks · 1.3 Problemstellung: ... Klassen detailliert vorgestellt. Besondere...

Documents

Transcript of DIPLOMARBEIT - eWorks · 1.3 Problemstellung: ... Klassen detailliert vorgestellt. Besondere...