Technische Universit¨at Dresden Daimler AG
Fakult¨at Informatik Global Services & Parts
Institut f¨ur Systemarchitektur Operations Support Services
Professur f¨ur Rechnernetze Diagnose- und Flash-Technologien
Prof. Dr. rer. net. habil. Dr. h. c. Alexander Schill Diagnose Antriebsstrang / Aggregate
Semantische F¨oderation heterogener
Informationsquellen in der
Fahrzeugdiagnose
Diplomarbeit zur Erlangung des akademischen Grades
Dipl.-Medieninf.
Benjamin S¨ollner
geb. am 02. November 1986 in Plauen, Deutschland
benjamin.soellner@mail.inf.tu-dresden.de
23. Juli 2010
Betreut von
Dr.-Ing. Daniel Schuster
daniel.schuster@tu-dresden.de
Bj¨orn Schwennicke
bjoern.schwennicke@daimler.com

Fakultät Informatik, Institut für Systemarchitektur, Professur Rechnernetze
AUFGABENSTELLUNG FÜR DIE DIPLOMARBEIT
Name, Vorname: Söllner, Benjamin
Studiengang: Medieninformatik Matr.-Nr.: 3253635
Thema: Semantische Föderation heterogener Informationsquellen in der
Fahrzeugdiagnose
ZIELSTELLUNG
Informationsaustausch zwischen Werkstätten und Fahrzeugherstellern geschieht heute meist
über viele verschiedene Kanäle und sehr heterogene Systeme. Neben E-Mail und telefonischer
Kommunikation werden auch Datenbanken mit häufig auftretenden Problemen und Lösungen,
Datenbanken für Betriebsanleitungen und statische Dokumente sowie viele weitere Tools mit
unterschiedlichem Inhalt und sehr heterogenen Datenformaten eingesetzt. Die Quellen sind
dabei meist semi-strukturiert, das heißt Informationen sind vorstrukturiert, die eigentlichen
Fakten verbergen sich jedoch meist im Fließtext. Somit ist es heute nur schwer möglich ein
umfassendes Produktbild, gezielte Problemlösungen sowie geeignete Ansprechpartner in der
Fahrzeugdiagnose zu ermitteln.
In der Arbeit soll am Beispiel der Fahrzeugdiagnose bei der Daimler AG untersucht werden,
inwieweit sich diese verschiedenen sehr heterogenen Datenquellen zusammenführen lassen
und eine semantische (facettierte) Suche über den gesamten Datenbestand realisiert werden
kann. Dabei sollen die Datenquellen hinsichtlich ihrer Struktur verglichen und ein Interface
spezifiziert werden, anhand dessen die Daten von einem übergreifenden System föderiert
werden können. Diese Föderation soll auf der Basis einer übergeordneten Ontologie
(semantisch) erfolgen. Des Weiteren sollen Techniken der Informationsextraktion zum Einsatz
kommen, um Fakten aus den Datenbeständen zu extrahieren und semantisch zu verlinken. Es
soll dazu ein Prototyp erstellt werden, anhand dessen sich die Eignung des Konzeptes
nachweisen lässt.
SCHWERPUNKTE
- Grundlagen: SOA, Semantic Computing / Semantic Web, Search Basics, Federated
Search, Informationsextraktion
- Anforderungsanalyse und Analyse der Datenquellen
- Entwurf eines Konzeptes für semantische Föderation
- Prototypische Implementierung und Validierung des Konzeptes
Betreuer: Dr.-Ing. Daniel Schuster
Externer Betreuer: Björn Schwennicke, Daimler AG
Betreuender
Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill
Beginn am: 01.02.2010
Einzureichen am: 31.07.2010
__________________________________________
Unterschrift des betreuenden Hochschullehrers

Selbstst¨andigkeitserkl¨arung
Hiermit erkl¨are ich, die vorliegende Diplomarbeit zum Thema
Semantische F¨oderation heterogener Informationsquellen in der Fahrzeugdiagnose
selbstst¨andig und ausschließlich unter Verwendung der im Quellenverzeichnis aufgef¨uhr-
ten Literatur- und sonstigen Informationsquellen verfasst zu haben.
Dresden, den 15. Juli 2010
Unterschrift
Sperrvermerk
Die vorliegende Diplomarbeit beinhaltet unternehmensinterne, vertrauliche Informationen
der Daimler AG. Zum Schutz dieser Informationen unterliegt sie daher einem Sperrver-
merk. Ohne Genehmigung des Verfassers oder der Daimler AG darf diese Arbeit bis zum
31.07.2012 daher weder als Ganzes, noch in Teilen eingesehen oder vervielf¨altigt werden.
v

”
Information ist nicht Wissen, Wissen ist nicht Weisheit,
Weisheit ist nicht Wahrheit, Wahrheit ist nicht Sch¨onheit,
Sch¨onheit ist nicht Liebe, Liebe ist nicht Musik,
Musik ist das Beste.”
— Frank Zappa, Packard Goose, Album: Joe’s Garage Act III
Danksagungen
Mein Dank geht an die beiden Betreuer meiner Diplomarbeit: an
Bj¨orn Schwennicke von der Daimler AG f¨ur seine anhaltende und
ansteckende Begeisterungsf¨ahigkeit f¨ur das vorliegende Thema und
f¨ur sein Talent, mir genau die F¨uhrung zu geben und den Freiraum
zu lassen, die ich zum kreativen Forschen f¨ur diese Arbeit ben¨otig-
te, sowie an Daniel Schuster vom Lehrstuhl Rechnernetze der TU
Dresden f¨ur die kontinuierliche F¨orderung meiner wissenschaftlichen
Interessen, f¨ur die ungezwungenen fachlichen Diskussionen und f¨ur
Rat und Kritik bez¨uglich meiner ersten Gehversuche bei wissen-
schaftlichen Abhandlungen.
Ebenfalls danken m¨ochte ich meinen Kollegen Ralph Ricker, Daniel
Meidlinger und Dr. Tim Schl¨usener, ohne die ich selbst im Infor-
mationsdschungel der Daimler AG verloren gewesen w¨are und die
mich kompetent in die unvertraute Dom¨ane der Fahrzeugdiagnose
einf¨uhrten. Bei meinem Vorgesetzten Dr. Harald Nauerz m¨ochte ich
mich f¨ur das in mich gesetzte Vertrauen und den mehrfachen Aus-
druck der Wertsch¨atzung meiner Arbeit bedanken. Ein Dank geht
auch an die Text Mining-Experten der Daimler AG: Dr. J¨urgen
Franke, Jan Werrmann, Mathias Bank und Christian H¨anig. Dan-
ke f¨ur die Offenheit, den fachlichen Rat, und die Bereitstellung der
InfexNG-Komponenten und -Literatur.
Einen besonderen Dank schulde ich meiner Familie. Insbesondere
meinen Eltern, ohne deren lebenslange Unterst¨utzung und Vertrau-
en ich es mit Sicherheit nicht bis zur Abgabe und Verteidigung einer
Diplomarbeit gebracht h¨atte.
vii

Kurzfassung
Die Informationsflut der heutigen Informationsgesellschaft erstreckt sich l¨angst nicht mehr
nur auf Medien des Alltagsgebrauches, sondern wird vor allem in Unternehmen, in denen
technische Entwicklungen rasant voranschreiten, bemerkbar. Das
”
lebenslange Lernen“
repr¨asentiert zuweilen eine Jagd nach zielf¨uhrenden Informationen zur L¨osung von Pro-
blemen, die besonders in Dom¨anen mit Kundenkontakt fehlerfrei und effizient durchge-
f¨uhrt werden muss. Zu dieser Dom¨ane geh¨ort die Fahrzeugdiagnose, deren Aufgabe es ist,
Strategien zu beschreiben, um Fehler am Fahrzeug zu lokalisieren und zu beheben. Durch
die Vielfalt an Baureihen und Baumustern und der Vielzahl der am Fahrzeugbau mitwir-
kenden Personen werden unz¨ahlige Informationen in verschiedenen Informationsquellen
abgelegt. Die Herausforderung ist, bei einer konkreten Kundenbeanstandung die korrek-
ten Informationen in den Informationsquellen zu finden, die zur Behebung der Fehlers am
Fahrzeug beitragen.
Diese Arbeit f¨uhrt zun¨achst in informationstechnische Grundlagen zur Extraktion von In-
formationen aus Daten und Fakten mit Hilfe von Natural Language Processing Technolo-
gien ein, sie stellt Methoden zur Speicherung von Informationen zum Zweck der effizienten
Suche (dem sogenannten Information Retrieval) vor und beschreibt, wie Informationen
weiter verkn¨upft werden k¨onnen, um Wissen zu repr¨asentieren. Außerdem werden die
Informationsquellen in der Fahrzeugdiagnose am Beispiel der durch die Daimler AG
verwendeten Systeme erl¨autert.
Darauf aufbauend wird ein Konzept erarbeitet, mit dem die Informationsquellen auf eine
einheitliche Datenstruktur abgebildet und unternehmensweit auf Basis einer Serviceorien-
tierten Architektur verf¨ugbar gemacht werden k¨onnen. Danach wird beschrieben, wie aus
den vereinheitlichten Daten Informationen extrahiert werden und wie diese Informationen
in eine verkn¨upfte Wissensbasis oder ein Information Retrieval System geschrieben wer-
den k¨onnen, um diese durchsuchbar zu machen. Das Information Retrieval System wird
daraufhin mit der Technologie der Query Expansion erweitert, um die Suchergebnisse zu
verbessern.
Die Arbeit geht auf implementationsspezifische Details des entwickelten Prototypen ein:
verwendet wurden unter Anderem die Frameworks UIMA [4], Apache Lucene [2] und
Semantic Media Wiki [27]. Der Prototyp wurde einem Last- und Genauigkeitstest unter-
zogen, dessen Ergebnisse in dieser Arbeit enthalten sind. Abschließend wird ein Ausblick
f¨ur die Nutzung des Konzeptes in ¨ahnlichen Anwendungsf¨allen und Dom¨anen und dessen
Erweiterung bis hin zu einer Semantic Middleware beschrieben.
Stichworte Fahrzeugdiagnose, Entscheidungsunterst¨utzungssystem, Informationsextrak-
tion, Text Mining, Natural Language Processing, Named Entity Recognition, Semantische
F¨oderation, Semantische Suche, Query Expansion, Information Retrieval, Lucene, Seman-
tic Media Wiki, UIMA, Document Provider, Document Tree Model
ix

Abstract
Information flood, a phenomenon of todays information society, stopped being restricted
to the everyday media long ago but became recognizable especially in companies, in which
technical progress advances fastly. “Lifelong learning” occasionally represents a hunt for
effective information to solve a problem in the shortest time possible. This is most relevant
in contexts, when customer contact puts additional urgency and priority to the problem.
Automotive diagnosis is one of those contexts. The task of this domain is to develop
strategies to localize and resolve faults in vehicles. The large number of models and variants
as well as the high number of people being involved in the construction process results in
an enormous amount of information stored to different information sources. The challenge
is to find the effective information in the right information source for a concrete customer
claim.
This thesis first gives an introduction to the foundations of information extraction from
data and facts using natural language processing technologies. It then introduces methods
for storing information efficiently for search operations carried out later (a discipline called
information retrieval) and describes, how information may be linked further to represent
knowledge. Furthermore, the information sources of Daimler’s automotive diagnosis are
examined.
On top of that, a concept is elaborated which allows mapping of the presented informa-
tion sources onto a common data structure. It is shown how this data structure can be
made available to the whole company using service oriented architectures. Afterwards, the
process of extracting information from the normalized data structure and saving the ex-
tracted information to a knowledge base or information retrieval system for future search
operations is explained. The information retrieval system is later extended by a query
expansion functionality with the aim to improve the search results.
This thesis addresses implementational issued of the developed prototype as well: for
example, the frameworks UIMA [4], Apache Lucene [2] and Semantic Media Wiki [27]
are used and their integration is explained. A performance test and an accuracy test was
carried out. Their results are also presented. Finally, a prospect is given concerning the
use of the prototype for similar use cases and domains and its extensibility to the point
of a semantic middleware is outlined.
Keywords Automotive Diagnosis, Decision Support System, Information Extraction,
Text Mining, Natural Language Processing, Named Entity Recognition, Semantic Fe-
deration, Semantic Search, Query Expansion, Information Retrieval, Lucene, Semantic
Media Wiki, UIMA, Document Provider, Document Tree Model
xi

Inhaltsverzeichnis
1. Einleitung 1
1.1. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Projektkontext und Ansatz dieser Arbeit . . . . . . . . . . . . . . . . . . . 3
1.3. Struktur dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Technologien 5
2.1. Daten vs. Informationen vs. Wissen . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Information Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Benennung f¨oderierter Ressourcen . . . . . . . . . . . . . . . . . . . 8
2.2.2. Verarbeitung semistrukturierter f¨oderierter Ressourcen in XML . . 9
2.2.3. Information Extraction aus Klartext durch Natural Language Pro-
cessing (NLP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4. Unstructured Information Management Architecture (UIMA) und
InfexNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Information Retrival . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1. Extraktion und Gewichtung der Indexterme . . . . . . . . . . . . . 16
2.3.2. Bewertung von Retrieval-Systemen . . . . . . . . . . . . . . . . . . 17
2.4. Wissensrepr¨asentation und Semantic Web . . . . . . . . . . . . . . . . . . 18
2.4.1. Vom Glossar ¨uber Taxonomien zu Ontologien . . . . . . . . . . . . 18
2.4.2. Das Resource Description Framework (RDF) und die RDF-Abfragesprache
SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3. Semantic Media Wiki als kollaborative semantische Dokumenten-
platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5. Service Oriented Architectures (SOA) . . . . . . . . . . . . . . . . . . . . . 24
2.5.1. Die Web Service Description Language (WSDL) . . . . . . . . . . . 25
2.5.2. SOAP als Protokoll zur Nachrichten¨ubermittlung . . . . . . . . . . 26
2.5.3. Bew¨ahrte Konzepte bei der Realisierung Entwurf von Webservices . 27
2.5.4. Webservice-Technologien f¨ur Java . . . . . . . . . . . . . . . . . . . 27
2.6. Abgrenzung gegen verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . 28
2.7. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3. Anforderungen 31
3.1. An der Diagnose beteiligte Systeme und Prozesse . . . . . . . . . . . . . . 31
3.1.1. Recherchesysteme (Informationssysteme) . . . . . . . . . . . . . . . 32
3.1.2. Diagnosesysteme (Expertensysteme in der Diagnose) . . . . . . . . 32
3.1.3. Feedbacksysteme und -prozesse . . . . . . . . . . . . . . . . . . . . 34
xiii

Inhaltsverzeichnis
3.1.4. Auftragssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2. Herleitung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1. Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2. Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . 38
3.2.3. Menschliche Faktoren . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4. Systementwurf 43
4.1. Systemgrenzen und Subsysteme . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.1. Interaktion der Subsysteme . . . . . . . . . . . . . . . . . . . . . . 45
4.1.2. Information Retrieval: Query Expansion vs. Semantische Indizierung 47
4.2. Der Document Provider Service . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1. Das Document Tree Model . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.2. Schnittstelle des Document Provider Webservice . . . . . . . . . . . 53
4.2.3. Adaption des Document Provider Webservice ¨uber Document Connec-
tors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3. Der Backend Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.1. Zwei Pipelines: eine zur Informationsextraktion, eine zur Query Ex-
pansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.2. Repr¨asentation des Document Tree Models im Backend Service . . 57
4.3.3. Verarbeitungsschritte der Informationsextraktion . . . . . . . . . . 59
4.3.4. Verarbeitungsschritte der Query Expansion . . . . . . . . . . . . . . 66
4.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5. Implementierung 69
5.1. Der Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1.1. ¨Uberblick des Gesamtsystems . . . . . . . . . . . . . . . . . . . . . 72
5.1.2. UIMA-Typsysteme des Backend Service . . . . . . . . . . . . . . . 78
5.1.3. Die InfexNG-Taxonomie des Backend Service . . . . . . . . . . . . 79
5.2. Ausgew¨ahlte Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2.1. Die konkrete XSL-Transformation f¨ur die Informationsquelle Case-
Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2.2. Entwurf einer Ordnungsrelation f¨ur Traverser Events . . . . . . . . 87
5.2.3. Integration von Axis und UIMA ¨uber Interprozesskommunikation . 92
5.2.4. Integration von Query Expansion in ein MediaWiki . . . . . . . . . 97
5.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6. Bewertung 101
6.1. Qualitative Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.2. Quantitative Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2.1. Performance der Informationsextraktion . . . . . . . . . . . . . . . 107
6.2.2. Performance des Information Retrieval Systems . . . . . . . . . . . 110
6.2.3. Precision, Recall und F-Measure . . . . . . . . . . . . . . . . . . . . 112
6.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
xiv

Inhaltsverzeichnis
7. Ergebnisse und Ausblick 119
7.1. Beitrag dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.2. Wieder- und Weiterverwendung des Prototypen . . . . . . . . . . . . . . . 120
7.3. Ein Blick in die Zukunft . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
A. Anhang 125
A.1. Quellcodeausz¨uge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
A.1.1. Das XML-Datenmodell zum Document Tree Model . . . . . . . . . 125
A.1.2. Eine XSL-Transformation ins Document Tree Model . . . . . . . . 127
A.1.3. Der Document Provider Webservice . . . . . . . . . . . . . . . . . . 131
A.2. Ausf¨uhrliche Darstellung des Lasttestes . . . . . . . . . . . . . . . . . . . . 135
Abk¨urzungsverzeichnis 139
Literaturverzeichnis 148
Abbildungsverzeichnis 150
Tabellenverzeichnis 151
Listings 154
xv

1. Einleitung
Die F¨ulle an Informationen, die t¨aglich entsteht und menschlich wahrgenommen und ver-
standen werden muss, steigt in der aktuellen Informationsgesellschaft weiter stetig
an [82]. Insbesondere im Gesch¨aftsumfeld m¨ussen immer schneller neue Informationen
zu unbekannten Problemstellungen recherchiert und erarbeitet werden – die korrekten
Informationen zur richtigen Zeit sind ein großer finanzieller Vorteil, da sie Arbeitsprozes-
se verk¨urzen und somit Zeit und Kosten einsparen. Nach einer Erhebung der Living-e
AG unter 300 deutschen F¨uhrungskr¨aften sehen 37 Prozent der Befragten die Gefahr, im
beruflichen Informationsdschungel die Orientierung zu verlieren. Beinahe 50 Prozent der
Unternehmen sch¨atzen den Anteil der Informationssuche an der Gesamtarbeitszeit auf 15
Prozent, 24 Prozent sogar auf mehr als ein F¨unftel [52].
Dieses Problem ist auch f¨ur die Fahrzeugdiagnose bei der Daimler AG relevant. Unter
Fahrzeugdiagnose bezeichnet man das Auffinden und Beheben von Fehlern am Fahrzeug
in der Werkstatt auf Grundlage eines wahrnehmbaren Symptoms. In den letzten Jahren
ist die Ausstattung und Architektur eines Fahrzeuges komplizierter geworden. Vor allem
spielen immer mehr elektronische Komponenten, sogenannte Steuerger¨ate eine Rolle. Die-
se Komponenten steuern oder ¨uberwachen Funktionen von Sicherheitsausstattungen, wie
die automatische Reifenluftdruckmessung, oder Komfortausstattungen, wie Multimedia-
ger¨ate im Fahrzeug, die vor einiger Zeit noch nicht denkbar waren. Neben der h¨oheren
Komplexit¨at stellt die h¨ohere Flexibilit¨at eine Herausforderung dar: Varianten sind nicht
nur hinsichtlich Marke, Klasse, Baureihe und Baumuster modifiziert – durch modernisier-
te Produktionsprozesse kann mittlerweile jeder Kunde die Ausstattung seines Fahrzeuges
individuell buchen.
Die Zeiten, in denen ein Werkstattmitarbeiter sich die Eigenheiten und Probleme eines
Modells im Detail vollst¨andig aneignen konnte, sind damit vorbei. Er muss von Fahrzeu-
gentwicklern und spezialisierten Diagnosebedatern aus dem Konzern kontinuierlich mit
m¨oglichst aktuellen Informationen versorgt werden.
1.1. Problemstellung
Um dieses Informationsbed¨urfnis zu erf¨ullen, werden dem Werkstattmitarbeiter ver-
schiedene Informationsquellen angeboten. Außerdem stehen ihm Feedbacksysteme zur
Verf¨ugung, ¨uber die er mit Spezialisten aus dem Konzern, sogenannten Produktbetreu-
ern, Kontakt aufnehmen kann. Schließlich existieren Diagnosesysteme, die am Fahrzeug
automatisierte Pr¨ufungen durchf¨uhren und ¨uber den Vergleich des Fahrzeugzustandes mit
1

1. Einleitung
definierten Soll-Werten auf einen Fehler schließen. Die Daten in diesen Systemen werden
redaktionell gepflegt. Allerdings werden die korrekten Werkstattinformationen von Werk-
stattmitarbeitern – entsprechend der oben vorgestellten Statistik – wegen ihrer schieren
F¨ulle nicht ausreichend schnell gefunden. Dies kann unter Anderem folgende Ursachen
haben:
1. F¨ur ein- und denselben Anwendungsfall existieren mehrere unterschiedliche Sys-
teme. Zur Bestellung von Bauteilen muss beispielsweise ein anderes System verwen-
det werden als zur Bestellung von technischen Dokumentationen, wie Bedienungs-
anleitungen.
2. Eine Verlinkung zwischen den Systemen fehlt h¨aufig. Es ist zum Beispiel nicht
m¨oglich, bei der Ansicht der Pr¨ufanweisung eines Bauteils direkt auf dessen Bauplan
zuzugreifen oder es, falls es defekt war, per Knopfdruck zu bestellen. F¨ur die drei
Anwendungsf¨alle werden drei unterschiedliche Systeme genutzt. In einigen F¨allen
ist zumindest eine Referenznummer angegeben, unter welcher der Gegenstand des
Interesses im jeweils anderen System zu finden ist. Diese Refernznummer muss dann
jedoch manuell ins andere System ¨ubertragen werden.
3. Es existiert keine ¨ubergeordnete, kundenorientierte Sicht auf den Service-
auftrag. Die kleinste abzuarbeitende Einheit aus Sicht des Werkstattmitarbeiters
ist das Fahrzeug mit allen ¨uber das Fahrzeug vorhandenen Daten sowie der Auf-
trag des Kunden – in einem Reperaturfall das
”
Kundensymptom“, der sogenannte
”
O-Ton Kunde“. Im praktischen Werkstattgeschehen werden all diese Daten h¨aufig
in einer Auftragsmappe zusammengefasst, die w¨ahrend des Auftrages mit Bl¨attern
gef¨ullt wird und das Fahrzeug begleitet. Sie erlaubt jedem Werkstattmitarbeiter die
Sicht auf die gesammelten Daten. In den bisherigen Systemen m¨ussen diese Daten –
beginnend mit der Fahrzeugidentifkationsnummer (FIN), aus der sich zum Beispiel
Hersteller, Baureihe und Baumuster schließen lassen – f¨ur jeden neuen Auftrag oder
beim Wechsel zwischen zwei Auftr¨agen erneut eigegeben werden.
4. In den Systemen existiert keine hinreichend pr¨azise, tolerante Suche. Kennt
der Nutzer die Identifikationsnummer eines Teiles oder Dokumentes, das f¨ur sein
Informationsbed¨urfnis relevant ist, nicht, steht ihm h¨aufig die M¨oglichkeit offen, die-
ses Dokument ¨uber redaktionell verwaltete baumstrukturierte Inhaltsverzeichnisse
zu suchen. In einigen Systemen ist eine Volltext-Datenbanksuche implementiert, die
aber nur exakte, w¨ortliche Treffer findet und entsprechend langsam ist.
5. Feedback der Werkstattmitarbeiter wird h¨aufig unstrukturiert, aber immer
nicht-¨offentlich abgelegt. Das gewonnene Fallwissen anderen Werkst¨atten zur Ver-
f¨ugung zu stellen, ist damit schwierig. Teilweise erfolgt die Kommunikation mit der
Werkstatt per Email oder Hotline. Im ersten Fall ist der Aufwand zur redaktionel-
len Aufarbeitung jedes Feedbacks f¨ur die Ver¨offentlichung sehr hoch, im zweiten Fall
ist die Ver¨offentlichung wegen der fehlenden Protokollierung quasi unm¨oglich. Aber
auch in moderner gestalteten Ticketsystemen werden Anfragen stets nicht-¨offentlich
behandelt, was bedeutet, dass ¨ahnliche Anfragen mehrfach recherchiert und beant-
wortet werden m¨ussen. Die Ver¨offentlichung ist jedoch teilweise aus Gr¨unden der
2

1.2. Projektkontext und Ansatz dieser Arbeit
Produkthaftung und des Datenschutzes von Kundendaten gar nicht erw¨unscht.
Ein Problem bei der Umstellung der Systemlandschaft zur Behebung oben genannter
Probleme ist die große Menge an Altdaten, die in den derzeitigen Systemen vorhanden sind
und f¨ur die Werkstatt weiterhin relevant sind. Eine L¨osung muss deswegen die Altdaten
korrekt integrieren.
1.2. Projektkontext und Ansatz dieser Arbeit
Im Rahmen das Projektes Strategy for Integration of AfterSales Process & Sys-
tems in Retail (SAR) versucht man bei General Services & Parts der Daimler AG,
die Systemlandschaft f¨ur alle AfterSales-Kundenbeziehungen zu vereinheitlichen – mit
dem Ziel, eine einheitliche kundenorientierte Ober߬ache zu erhalten, die den gesamten
Auftragsprozess von der Annahme bis zur Rechnungslegung unterst¨utzt und Auftragsda-
ten f¨ur alle abh¨angigen Systeme zur Verf¨ugung stellt. Diese Zielsetzung adressiert die in
Abschnitt 1.1 beschriebenen Probleme Nummer (1.) und (3.).
Das SAR-Projekt plant unter Anderem auch die Entwicklung eines Entscheidungs-
unterst¨utzungssystems (Decision Support System, DSS). Dieses soll ausgehend von
Fahrzeug- und Auftragsdaten sowie eventuell vom Werkstattmitarbeiter eingegeben Such-
kriterien die relevanten Dokumente, Bauteile und Arbeitsschritte zur L¨osung des Auftrages
finden und daraus bestenfalls Daten bez¨uglich Kosten und Zeitaufwand extrahieren und
dem Werkstattmitarbeiter pr¨asentieren.
Diese Arbeit soll einen Beitrag zur Entwicklung des Decision Support Systems leisten:
Sie soll eine f¨oderierte Suche ¨uber den unterschiedlichen, heterogenen Informationsquellen
realisieren. Diese Suche soll semantisch funktionieren, das heißt, die Suchanfrage soll inter-
pretiert und eventuell umgeschrieben werden, um das Informationsbed¨urfnis des Nutzers
ad¨aquater zu repr¨asentieren und Suchanfragen zu erlauben, die ¨uber eine reine Volltext-
Suche hinaus gehen. Diese Zielsetzung adressiert Punkt (4.) aus der in Abschnitt 1.1
beschriebenen Problemstellung. Weiterhin soll mit dieser Arbeit eine automatische Ver-
linkung der Alt-Dokumente erfolgen, sodass es m¨oglich ist, f¨ur bestimmte Stichw¨orter in
einem Dokument direkt zu relevanten Dokumenten zu gelangen, die diese Stichw¨orter be-
schreiben. Dieser Teil der Aufgabenstellung geht auf Punkt (2.) ein und beachtet dabei
die oben beschriebene besondere Relevanz der Altdaten.
In der Forschung & Entwicklung der Daimler AG besch¨aftigt man sich zudem damit,
wie neue Technologien des World Wide Web im Diagnoseprozess genutzt werden k¨onnen.
Dies zun¨achst, um die betriebswirtschaftliche Einsetzbarkeit von community-basierten Re-
daktionsprozessen, wie sie f¨ur das Web 2.0 typisch sind, zu testen. Die Hoffnung ist, mit
solchen Prozessen Feedbackdaten und Erfahrungswissen aus der Werkstatt besser nutz-
bar zu machen, was der L¨osung von Punkt (5.) entspricht. Als Prototyp wird in diesem
Projekt ein Werkstattwiki aufgesetzt und ausgew¨ahlten Werkst¨atten als kollaborati-
ves Informationssystem zu Testzwecken f¨ur einen beschr¨ankten Zeitraum pr¨asentiert. Da
ein DSS- bzw. SAR-Frontend im Konzern noch nicht existiert, ist das Werkstattwiki ein
3

1. Einleitung
m¨ogliches Zielsystem f¨ur das in dieser Arbeit zu entwickelnde System zur semantischen,
f¨oderierten Suche ¨uber heterogenen Informationsquellen der Fahrzeugdiagnose.
1.3. Struktur dieser Arbeit
Diese Arbeit gliedert sich wie folgt: in Kapitel 2 werden informationstechnische Grund-
lagen gelegt, um die theoretische Machbarkeit des zu realisierenden Systems gem¨aß des
aktuellen Standes der Forschung auf dem Gebiet des Information Retrieval (f¨ur den An-
wendungsfall der Suche) und der Informationsextraktion durch Named Entity Recognition
und Natural Language Processing (f¨ur den Anwendungsfall der semantischen Suche und
automatischen semantischen Verlinkung) abzusch¨atzen. Kapitel 3 detailliert die in die-
sem Kapitel vorgestellten fahrzeugtechnischen Problemstellungen und leitet daraus die
konkreten Anforderungen an das zu realisierende System.
In Kapitel 4 wird ein Konzept zur L¨osung des Problems aufgezeigt und in Kapitel 5
implementierungsspezifische Details und einzelne Herausforderungen bei der Realisierung
beschrieben. Kapitel 6 bewertet das realisierte System anhand der Anforderungen ge-
m¨aß qualitativen und quantitativen Testergebnissen. Kapitel 7 fasst die Ergebnisse dieser
Arbeit zusammen und diskutiert deren Anwendung gegen¨uber ausgew¨ahlten verwandten
Aufgabenstellungen. Dabei werden Grenzen bez¨uglich der Erweiter- und ¨Ubertragbarkeit
aufgezeigt und m¨ogliche Weiterentwicklungen zur Beseitigung dieser Grenzen vorgeschla-
gen. Außerdem wird ein langfristiger Blick in die Zukunft gewagt.
4

2. Technologien zur Extraktion und
zum Retrieval von Wissen aus
f¨orderierten Dokumenten
In diesem Kapitel soll auf die informationstechnischen Grundlagen eingegangen werden,
die n¨otig sind, um ein kollaboratives System zu entwickeln, welches die f¨oderierte semanti-
sche Suche ¨uber heterogenen Informationsquellen unterst¨utzt. Ziel dieses Systems ist, die
in der Einleitung beschriebenen Herausforderungen zu bew¨altigen. Die in diesem Kapitel
gelegten Grundlagen helfen bei der sp¨ateren Anforderungsanalyse, die informationstech-
nische Machbarkeit abzusch¨atzen. Eine ¨Ubersicht der gestreiften Disziplinen dieser Arbeit
wird durch Abbildung 2.1 gegeben.
Um diese Arbeit im Kontext eines Konzerns wie der Daimler AG betrachten zu k¨onnen,
f¨uhrt Abschnitt 2.1 zun¨achst auf dem betriebswirtschaftlichen Gebiet des Wissensmana-
gements in die Terminologie dieser Arbeit ein: Was sind Daten? Was Informationen? Und
was ist Wissen? Dann werden die Grundlagen zur Bearbeitung der Kernthemen gelegt: In
Abschnitt 2.2 wird zun¨achst darauf eingegangen, wie semistrukturierte Daten benannt und
einheitlich repr¨asentiert werden k¨onnen und wie aus ihnen dann mit Hilfe von Methoden
des Natural Language Processings und des Text Minings Informationen extrahiert
werden k¨onnen. Abschnitt 2.3 besch¨aftigt sich mit der Disziplin des Information Retrie-
val – der m¨oglichst effizienten Ablage von Informationen zum sp¨ateren Wiederauffinden
hinsichtlich einer m¨oglicherweise vage formulierten Problemstellung. Abschnitt 2.4 be-
fasst sich mit der Einbindung von Informationen in hochverkn¨upfte Wissensbasen und
Such‐/Ranking‐/
SOA
Webservices
WSDL+SOAP
Information
Retrieval
Text Mining
&
Natural Text‐Cleaning
Such‐/Ranking‐/
Indexstrategien
Lucene
Axis+Castor
XML‐Dokumente & URIs
Natural
Language
Processing
Text‐Cleaning
Named Entity Recognition
Relation Extraction
UIMA & InfexNG
MediaWiki
LuceneSearch
Semantic
Web
Know‐
Ledge
M t
Ontologien
RDF & SPARQL
UIMA & InfexNG
Auto‐
motive
Diagnosis eColla‐ Semantic
MediaMgmt RDF & SPARQL
Triple Stores
Diagnosis
boration Media
Wiki+
Abbildung 2.1.: Gestreifte Disziplinen dieser Arbeit
5

2. Technologien
Entscheiden
WissenSynthese
Zusammenfassung
InformationenAnalyse
Ordnen
(Roh‐)Daten
Ordnen
Sammeln
Abbildung 2.2.: Die
”
Wissenspyramide“ mit Daten, Informationen und Wissen als Grund-
lage f¨ur Entscheidungen (aus [93] modifiziert nach [28])
mit verwandten Web-Technologien, die im Rahmen des Semantic Web aufgekommen
sind. Abschließend wird in Abschnitt 2.5 kurz auf den Ansatz der Serviceorientierten
Architekturen eingegangen, die im Unternehmenseinsatz ein erstrebenswertes Architek-
turmuster darstellen und f¨ur den Entwurf des Prototypen Leitbild sein sollen. Abschnitt
2.6 stellt die in den Kernthemen bereits pr¨asentierten verwandten Arbeiten vor und grenzt
diese Arbeit dagegen ab. Abschnitt 2.7 fasst das Kapitel zusammen.
2.1. Daten vs. Informationen vs. Wissen
Unter Daten versteht man ¨ublicherweise isolierte, uninterpretierte und eindeutige Fak-
ten aus der realen Welt – man spricht in diesem Zusammenhang auch von Rohdaten.
Assoziation und Verkn¨upfung, d.h. Zuordnung von Daten/Fakten zueinander sowie Inter-
pretation dieser Daten hinsichtlich ihrer Bedeutung (Semantik) in einem Themengebiet
(einer Dom¨ane) macht aus Daten Informationen. Werden diese wahrgenommen, ver-
arbeitet und formell mit Bedeutung versehen, entsteht daraus Wissen (vgl. [100]). Der
¨Ubergang zwischen Daten, Informationen und Wissen ist in der Praxis allerdings bisweilen
unscharf. Ihre Relation zueinander ist in Abb. 2.2 dargestellt.
Wissen kann in explizites und implizites Wissen eingeteilt werden (vgl. [92]). Expli-
zites Wissen l¨asst sich bewusst wahrnehmen und durch nat¨urliche Sprache artikulieren,
w¨ahrend implizites Wissen sich durch unbewusste Annahmen oder Handlungen in einem
bestimmten Kontext ¨außert, und eher durch Erfahrung gewonnen wird.
Die Informationsverarbeitung besch¨aftigt sich damit, von Menschen verst¨andliche Da-
ten und Fakten in eine maschinenlesbare Form zu bringen und diese mithilfe von Informa-
tionssystemen zu verarbeiten. Ergebnisse der Verarbeitung sollen wieder als Informationen
oder Daten in menschenlesbarer Form zug¨anglich gemacht werden. Zus¨atzlich dazu soll
die Wissensverarbeitung auch Wissen in rechnergest¨utzten Systemen repr¨asentieren
und verarbeitbar machen. Hier kommen vorwiegend Methoden aus der K¨unstlichen In-
6

2.2. Information Extraction
telligenz zum Einsatz. Ein Anwendungsfall entsprechender Methoden ist das Semantic
Web, dessen Technologien in Abschnitt 2.4 eingef¨uhrt werden.
Wissen stellt h¨aufig die Grundlage f¨ur das Entscheiden und Handeln im Kontext eines
Problems dar. Ein Problem muss zun¨achst als solches erkannt und das Problem selbst
auf (m¨oglichst formelle) Weise beschrieben oder in Worte gefasst werden. Daraufhin kann
man ein Probleml¨osungsverfahren w¨ahlen, um das Problem zu beseitigen. Es existieren
analytische Probleml¨osungsverfahren, bei der alle notwendigen Informationen zu Beginn
vorhanden sind und ¨uber Schlussfolgern schrittweise eine L¨osung entwickelt wird. Dem ge-
gen¨uber stehen Methoden, bei denen mit begrenztem Wissen in kurzer Zeit m¨oglichst gute
L¨osungen gefunden werden sollen. Diese Methoden werden als Heuristiken bezeichnet.
Ein prominentes Beispiel f¨ur Heuristiken sind mathematische Suchalgorithmen. Das
Problem, welches durch den Nutzer formuliert wird, ist durch die Suchanfrage gegeben.
Hier stellt sich f¨ur den Nutzer die Herausforderung, sein Problem m¨oglichst klar durch
eine entsprechende Suchanfrage zu repr¨asentieren. Die L¨osung des Problems, also das Su-
chergebnis, ist genau dann zielf¨uhrend, wenn ein Dokument gefunden wird, welches genau
die Informationen enth¨alt, die den Informationsbedarf des Nutzers deckt. Interpretiert der
Nutzer die Information und versieht sie mit Bedeutung, repr¨asentiert sie f¨ur ihn Wissen,
dass zur L¨osung seines Problems hilfreich ist. Die Qualit¨at eines Suchalgorithmus wird
nach der Definition einer Heuristik daran gemessen, ob der Nutzer mit begrenztem Wis-
sen (m¨oglicherweise mehrdeutige Suchanfrage) in kurzer Zeit (Performance des Suchalgo-
rithmus) eine gute L¨osung (Fund des zielf¨uhrenden Dokumentes) findet. Weiterf¨uhrende
Informationen zu Suchalgorithmen werden in Abschnitt 2.3 gegeben.
Ein h¨aufiger Anwendungsfall f¨ur Heuristiken ist im Allgemeinen die Fehlersuche in großen
Systemen. Im Speziellen wird dies in dieser Arbeit anhand der Fahrzeugdiagnose erl¨au-
tert. Vor allem hier liegt unvollst¨andiges Wissen ¨uber den Zustand des fehlerhaften System
vor. Unmittelbar ¨außert sich der Fehler nur im sogenannten Symptom, welches allerdings
durch eine Ursache bedingt ist, die es erst zu finden gilt, bevor eine Abhilfe den Fehler
beheben kann. Zwischen Symptom, Ursache und Abhilfe k¨onnen beliebige Beziehungen be-
stehen, die ¨uber Heuristiken erst erschlossen werden m¨ussen. Auch hier ist nur begrenztes
Wissen, in diesem Fall ¨uber den Zustand des Fahrzeuges, vorhanden. Das Interesse einer
schnellen, exakten L¨osung ist hier bei allen Beteiligten gegeben: f¨ur die Daimler AG ist
jede Reparatur, wenn auf Garantie oder Kulanz durchgef¨uhrt, teuer, f¨ur den Kunden der
Verzicht auf das Fahrzeug unbequem und f¨ur die Werkstatt eine aufw¨andige, m¨oglicher-
weise nicht zielf¨uhrende Diagnose, bei welcher der Kunde auf sein Fahrzeug warten muss,
schlecht f¨ur die Reputation.
2.2. Von Daten zu Informationen durch Information
Extraction
Wie k¨onnen Daten aus heterogenen Quellen vereinheitlicht, gefiltert und verkn¨upft wer-
den, sodass Informationen abgeleitet werden k¨onnen? Diese Fragen stellte man sich zu-
7

2. Technologien
n¨achst mit dem Blick auf die immer gr¨oßer werdende Informationsdichte im World Wide
Web. Auch Firmen wie die Daimler AG hatten ein berechtigtes Interesse, verl¨assliche
Aussagen, zum Beispiel ¨uber die Kundenakzeptanz ihrer Produkte, in den endlosen Weiten
des Webs zu finden. Das Projekt AIM (Automotive Internet Mining) [77] besch¨aftigt sich
daher mit dem Crawling (systematischen Downloaden) von Internetforen aus der Dom¨ane
des Automobilbaus und der Extraktion von Kundenmeinungen aus den Forenbeitr¨agen.
Ein ¨ahnliches Ziel verfolgt das Aletheia-Projekt [47] der TU Dresden, das Technologien
zur f¨oderierten Produktsuche im Internet entwickelt.
L¨angst ist jedoch die Datenflut so groß, dass Methoden des Information Extraction
auch innerhalb eines Unternehmens angewendet werden sollten. Beispielsweise wurde im
Rahmen von [80] bei der Daimler AG ein Framework entwickelt, mit dem aus Werk-
stattberichten Statistiken erstellt werden k¨onnen, die Aufschluss ¨uber h¨aufig aufgetretene
Symptome oder defekte Teile geben.
In den folgenden Unterabschnitten werden die n¨otigen Technologien eingef¨uhrt. Zun¨achst
werden Dokumente (oder Ressourcen), welche die Daten enthalten, eindeutig benannt
(2.2.1). Dann werden diese semistrukturierten, f¨oderierten Ressourcen in eine einheitli-
che Repr¨asentation ¨uberf¨uhrt (2.2.2). ¨Uber Methoden des Natural Language Processings
(NLP) werden aus diesen semistrukturierten Ressourcen schließlich Informationen gewon-
nen (2.2.3). UIMA und das bei Daimler entwickeltem Framework InfexNG k¨onnen zur
Realisierung von NLP-Systemen verwendet werden (2.2.4).
2.2.1. Benennung f¨oderierter Ressourcen
Um Aussagen ¨uber ein Dokument aus einer Informationsquelle oder ein im Dokument be-
schriebenes Konzept aus der realen Welt zu t¨atigen, ist es n¨otig, diese zu benennen. Zur
Benennung dieser sogenannten Ressourcen wurde durch die IETF (Internet Engineering
Task Force) der Begriff der URI, URL und URN definiert. URI (Uniform Resource Iden-
tifier) ist der Oberbegriff von URL und URN und identifiziert eine Ressource eindeutig.
Ein URL (Uniform Resource Locator) verweist auf eine Adresse, die an einem physi-
schen Ort (Location) durch ein Netzwerkprotokoll erreichbar ist. Zum Beispiel ist http:
//www.daimler.com/ ein URL, da es auf die Ressource www.daimler.com (das Dokument-
Wurzelverzeichnis des Webservers www der Domain daimler unterhalb der Top-Level-
Domain com) verweist, die ¨uber HTTP erreichbar ist.
Ein URN (Uniform Resource Name) bezeichnet einen allgemeinen und global eindeutigen
Identifikator f¨ur ein Konzept, welches nicht notwendigerweise ¨uber das Netzwerk abruf-
bar sein muss. URNs haben die Form urn:Namespace :GUID , wobei der Namespace den
Adressraum der URNs in Namensr¨aume unterteilen. Einige dieser Namensr¨aume werden
durch die IANA (Internet Assigned Numbers Authority) vergeben1
. Da URNs unabh¨angig
vom Ort ihrer Ressource sind, k¨onnen sie ¨uber die gesamten Lebenszeit der Ressource,
die sie identifizieren, unver¨andert bleiben.
1
Liste der derzeit standardisierten Namensr¨aume s. [46]
8

2.2. Information Extraction
2.2.2. Verarbeitung semistrukturierter f¨oderierter Ressourcen in
XML
Als semistrukturierte Daten bezeichnet man in der Datenbanktechnologie Daten, wel-
che keiner fest definierten Struktur unterliegen – ein Datenbankmodell fehlt hier. Aller-
dings tragen semistrukturierte Daten oft Strukturmerkmale in sich. Unter Interpretation
einer Grammatik und Lexik k¨onnen semistrukturierten Daten so in strukturierte Daten
¨uberf¨uhrt werden: Das Ergebnis sind eine oder mehrere Folgen von Objekten, wobei dies
entweder komplexe Objekte sind, die in weitere Objekte zerlegt werden k¨onnen oder
atomare Objekte, die Werte eines bekannten, elementaren Datentyps enthalten (vgl.
[50]). Semistrukturierte Daten, zerlegt in komplexe und schließlich atomare Objekte, k¨on-
nen demnach als Baumstruktur repr¨asentiert werden.
XML (Extensible Markup Language) ist eine vom W3C standardisierte erweiterbare Aus-
zeichnungssprache [60] zur Beschreibung von baumstrukturierten Dokumenten, die aus
Elementen mit Unterelementen, Textknoten und Attributen bestehen. Mit XSD (XML
Schema Definition) [34] oder DTD (Document Type Definition) lassen sich Grammatiken
definieren, die weitere Einschr¨ankungen bez¨uglich der erlaubten Elemente, Unterelemente
usw. machen. Dabei werden die definierten Elemente einem Namensraum (Namespace)
zugeordnet, welcher im konkreten Dokument angegeben wird und eindeutig auf die typi-
sierende Grammatik verweist. Ein XML-Dokument, welches auf diese Art eine Grammatik
referenziert und die dort festgelegten Regeln einh¨alt, gilt als valide.
In Anhang A.1.1 sind beispielhaft ein XSD-Dokument (Listing A.1) und ein XML-Dokument
(Listing A.2) dargestellt. Das Schema und dessen Instanz entsprechen dem Document
Tree Model, einem einheitlichen Datenmodell zur Repr¨asentation von f¨oderierten Doku-
menten, welches in Unterabschnitt 4.2.1 erkl¨art wird. Das XSD-Dokument geh¨ort dem
Schema http://www.w3.org/2001/XMLSchema an, das im Quellcodebeispiel an den Pr¨a-
fix xsd gebunden ist. In der XSD-Grammatik werden neue Elementtypen (Node, Node-
Info usw.) definiert und an den targetNamespace http://sar.gsp.rd.daimler.com/
documenttree/xsd gebunden, der ¨uber das Pr¨afix dt referenziert wird. Jeder definierte
Typ wird dann als Inhalt eines XML-Elementes (node, nodeInfo usw.) verwendet. Im
XML-Dokument wird die Instanziierung dieser Elemente beispielhaft verdeutlicht.
XML-Technologien
Zur Verarbeitung von XML im Programmcode gibt es verschiedene Ans¨atze, die sich hin-
sichtlich des Zugriffs (sequenziell oder wahlfrei), der Ablaufkontrolle des XML-Prozessors
(
”
Push“ oder
”
Pull“) und des Baumstrukturmanagements (hierarchisch oder verschach-
telt) unterscheiden. Zwei De-Facto-Standards, die APIs f¨ur den XML-Zugriff spezifizieren,
sind DOM (Document Object Model) [75] und im Kontext von Java SAX (Simple API
for XML) [83]. DOM erlaubt einen wahlfreien Zugriff auf Elemente des XML-Baumes
und dar¨uber hinaus auch das Manipulieren und Zur¨uckschreiben der Baumstruktur in
ein XML-Dokument. Bei SAX wird das XML-Dokument als Datenstrom betrachtet, der
9

2. Technologien
sequenziell eingelesen wird. F¨ur wohldefinierte Ereignisse, wie das Auftreten eines Start-
/Endtags wird ein Ereignis ausgel¨ost und der Anwendungsprogrammcode (z.B. mittels
Observer-Pattern [70]) benachrichtigt.
¨Ublicherweise greift Anwendungsprogrammcode allerdings nicht direkt auf die Parser-
API zu: stattdessen werden Regeln definiert, wie Instanzen von Programmlogikklassen
bzw. -datenstrukturen ¨uber eine Parser-API in XML-Dokumente geschrieben (Marshal-
ling bzw. Serialisierung) oder aus ihnen gelesen werden k¨onnen (Unmarshalling bzw.
Deserialisierung). Beispiele f¨ur solche Data Binding Frameworks sind JAXB [18] (Ja-
va Architexture for XML Binding) oder Castor [29]. Mit beiden Frameworks ist es zum
Beispiel m¨oglich, direkt aus XSD-Dateien Java-Klassen zu generieren (Binding), welche
zur Laufzeit die deserialisierten XML-Daten repr¨asentieren, oder aber Serialisierungsre-
geln f¨ur bestehende Klassen zu definieren (Mapping).
XML-Transformationen mit Hilfe von XSLT und XPath
Ein XML-(Quell-)Dokument kann in ein anderes XML-(Ziel-)Dokument transformiert
werden. Eine Beschreibung dieser Transformationen ist durch die Sprache XSLT (Ex-
tensible Stylesheet Language Transformation) [78] m¨oglich. Eine XSL-Transformation be-
schreibt das
”
Ger¨ust“ des Zieldokuments, enth¨alt aber an variablen Stellen XML-Elemente
aus dem XSLT-Namensraum, welche durch einen XSLT-Prozessor verarbeitet werden
und dabei bestimmte Knoten, ggf. transformiert, aus dem Quelldokument ins Zieldoku-
ment kopieren bzw. Schleifen, Verzweigungen oder Template-Definitionen und -Aufrufe
beschreiben. Eine besondere Bedeutung kommt hier dem Standard XPath [56] zu, ¨uber
den bestimmte Knoten im Quelldokument f¨ur die weitere Verarbeitung selektiert werden
k¨onnen. XPath erlaubt mit Hilfe von Funktionen und if-then-else-Konstrukten auch die
einfache Analyse und Transformation von Knoteninhalten. Dar¨uber hinaus lassen sich
auch benutzerdefinierte XPath-Funktionen transformieren.
XSL-Transformationen sind ein m¨achtiges Werkzeug zur Verarbeitung f¨oderierter Daten:
Sind semistrukturierte Daten zun¨achst, abh¨angig von ihrer Informationsquelle, auf un-
terschiedliche Weise in XML repr¨asentiert, k¨onnen Daten der Informationsquelle in eine
einheitliche Repr¨asentation ¨uberf¨uhrt werden, indem sie der f¨ur ihre Informationsquelle
speziell angelegten XSL-Transformation unterworfen werden. Im Rahmen dieser Arbeit
werden XSL-Transformationen zur ¨Uberf¨uhrung von f¨oderierten Dokumenten in das Do-
cument Tree Model verwendet. Eine solche XSL-Transformation ist in Anhang A.1.2,
Listing A.3, dargestellt.
Ein XSLT-Prozessor auf Java-Basis ist zum Beispiel Saxon [32]. Der Saxon-XSLT-
Prozessor zeichnet sich vor allem dadurch aus, dass es die Version 2.0 des XPath-Standards
unterst¨utzt, welcher u.A. Selektionsbedingungen mit regul¨are Ausdr¨ucke erlaubt. Saxon
steht in einer kostenlosen Home Edition zur Verf¨ugung, diese kann Quell- und Zieldoku-
mente allerdings nicht gegen ein XML-Schema validieren.
10

2.2. Information Extraction
2.2.3. Information Extraction aus Klartext durch Natural Language
Processing (NLP)
Die Strukturiertheit, in der die semistrukturierten Originaldaten vorliegen, reicht h¨aufig
nicht aus, um alle n¨otigen Informationen aus diesen Daten maschinenlesbar darzustellen.
Dies ist insbesondere der Fall bei Dokumenten, die von verschiedenen Personen manuell
erstellt wurden: hier liegt oft Klartext vor. Dieser Klartext l¨asst sich in Abs¨atze, S¨atze,
W¨orter und sogenannte Morpheme als kleinste bedeutungstragende Einheiten zerlegen.
Methoden f¨ur die Zerlegung und Identifizierung dieser Einheiten zu entwickeln ist Aufgabe
der Disziplin des Natural Language Processing, welche sich auf linguistische oder
statistische Methoden st¨utzt. Dabei kommen entweder regelbasierte oder selbstlernende
Algorithmen (Algorithmen der K¨unstlichen Intelligenz) zum Einsatz. Das Fachgebiet der
Informationsextraktion aus Klartext wird als Text Mining (
”
Textsch¨urfen“) bezeichnet.
Dieser Prozess analysiert den zugrundeliegenden Text in mehreren Schritten [97], welche
im Folgenden erl¨autert werden.
Text Cleaning
Hier werden St¨orungen aus Textdaten entfernt sowie Strukturerkennungen und Format-
vereinheitlichungen durchgef¨uhrt, um die Qualit¨at der Daten zu steigern.
Sprachidentifizierung Die Sprache kann durch h¨aufig auftretende Muster im Text er-
kannt werden. Diese Muster k¨onnen entweder besonders h¨aufig vorkommende W¨or-
ter (Stoppw¨orter), zum Beispiel Artikel, Pr¨apositionen oder Pronomen, sein, nach
denen im Text gezielt gesucht wird. Es ist auch die Zerlegung des Textes in Buchsta-
bengruppen von jeweils 3, 4 oder allgemein n Buchstaben (Trigramme, Quadgramme
bzw. n-Gramme) m¨oglich. F¨ur eine bestimmte Sprache sind auch hier besonders h¨au-
fig vorkommende Buchstabenkombinationen charakteristisch. Die Vorkommnisse der
entsprechenden Muster einer Sprache werden gegeneinander gewichtet und schließ-
lich wird der Text mit der die Sprache mit maximaler Gewichtung klassifiziert. Da
die folgenden Verarbeitungsschritte zum Teil sprachabh¨angig sind, verbessert die
Sprachidentifizierung die Qualit¨at dieser erheblich.
Tokenisierung (auch lexikalische Analyse) Aufgabe dieses Vorverarbeitungsschrittes ist
es, den Text in kleinste, bedeutungstragende Einheiten zu zerlegen, wie zum Beispiel
W¨orter und Satzzeichen. Sogenannte Tokenizer arbeiten dabei h¨aufig mit regul¨aren
Ausdr¨ucken – dabei deckt ein regul¨arer Ausdruck genau ein Token ab. Durch ei-
ne Liste von regul¨aren Ausdr¨ucken k¨onnen verschiedene Tokentypen identifiziert
werden, z.B. W¨orter oder Satzzeichen, aber auch Seriennummern, wie Teilenum-
mern oder Dokumentennummern. Da sich die G¨ultigkeit verschiedener regul¨arer
Ausdr¨ucke ¨uberschneiden kann, m¨ussen diese Liste priorisiert werden.
Stemming Dieser Schritt reduziert Tokens, im speziellen W¨orter, auf ihre Grundform.
Die Schwierigkeit dieses Verarbeitungsschrittes ist von der Sprache abh¨angig: so
existieren zum Beispiel im Englischen nur wenige Flexive (z.B.
”
-s“,
”
-ed“,
”
-ing“),
11

2. Technologien
w¨ahrend es im Deutschen weitaus mehr sind. Zus¨atzlich kommt hier das Problem der
Allomorphie (Um- und Ablautung) hinzu. Außerdem k¨onnen Flexionen durchaus
bedeutungstragend sein: das englische Genitiv-Suffix
”
’s“ zum Beispiel stellt eine
besitzanzeigende Beziehung zwischen dem Wort und dem darauffolgenden her. In
diesem Zusammenhang ist das Problem des Overstemming und des Understemming
bekannt, bei denen W¨orter entweder zu weit reduziert werden, sodass Informationen
verloren gehen, oder nicht weit genug reduziert werden, sodass sie z.B. ¨uber ein
W¨orterbuch korrekt erkannt werden k¨onnen.
Rechtschreibkorrektur Rechtschreib- oder Tippfehler treten vor allem im Werkstattsze-
nario dieser Arbeit h¨aufig auf. Sie f¨uhren zu W¨ortern, die in der Zielsprache nicht
vorhanden sind oder zwar vorhanden sind, aber in einem falschen Kontext stehen.
Diese zu erkennen ist die Aufgabe einer Rechtschreibkorrektur. In NLP-Systemen
ist diese im Gegensatz zu Textverarbeitungsprogrammen voll-automatisch realisiert,
d.h. f¨ur ein fehlerhaftes Wort wird automatisch das korrekte Wort ausgew¨ahlt.
Dazu werden zun¨achst Worttoken darauf ¨uberpr¨uft, ob sie im Lexikon der Text-
sprache vorkommen. Ist dies nicht der Fall, werden Distanzmetriken verwendet, um
aus dem Lexikon W¨orter zu finden, die dem fehlerhaften Wort m¨oglichst ¨ahnlich
sind. Hier kann die Editierdistanz (auch Levensthein-Distanz) [81] zu Rate gezogen
werden, die beschreibt, wie viele Buchstaben entfernt, hinzugef¨ugt oder vertauscht
werden m¨ussen, um ein Wort in das andere zu ¨uberf¨uhren. Eine andere oder zus¨atzli-
che M¨oglichkeit ist das Messen der phonetischen Distanz [101], d.h. des Gleichklangs
der W¨orter.
Auf diese Weise werden die W¨orter mit minimaler Distanz als potentielle Korrek-
turen ermittelt. Diese k¨onnen noch weiter gewichtet werden: hierzu eignen sich Fre-
quenzlisten (Wie h¨aufig tritt das Wort ¨ublicherweise in einem Text auf?) oder Kook-
kurenzinformationen (Welche Worte treten h¨aufig zusammen auf?). Insbesondere die
letzten beiden Informationen lassen sich aus gen¨ugend großen Textkorpora automa-
tisch mit Hilfe eines selbstlernenden Systems antrainieren. Ein freies, Java-basiertes
Framework zur Rechtschreibkorrektur ist z.B. ASpell [53].
Sentence Boundary Detection Dieser Verarbeitungsschritt markiert die Satzgrenzen in-
nerhalb des Textes. Besondere Herausforderung hier ist, dass nicht jedes vom To-
kenizer erkannte Satzzeichen auch eine Satzgrenze beschreiben muss: Abk¨urzungen,
direkte Rede oder Nachl¨assigkeit des Verfassers bei der Interpunktion stellen hier
eine Herausforderung dar. Eine naheliegende L¨osung ist, Abk¨urzungen ¨uber Aus-
nahmelisten zu eliminieren. Eine ausgereiftere und zuverl¨assigere L¨osung bietet zum
Beispiel das SATZ-System [89, 90]: hier wird ein Tokenfenster der L¨ange sieben
um das Satzzeichen gelegt und f¨ur jedes Token ein Vektor berechnet, der die Wahr-
scheinlichkeiten der m¨oglichen PoS-Tags (siehe unten) berechnet. Diese Merkmals-
vektoren werden einer Support Vector Machine [61] ¨ubergeben, welche anhand der
konkatenierten Merkmalsvektoren das Satzzeichen als Satzgrenze klassifiziert oder
nicht. Die Support Vector Machine ist selbstlernend und muss auf einem annotierten
Anfangskorpus trainiert werden.
12

2.2. Information Extraction
Part-of-Speech Tagging Schließlich wird f¨ur jedes Wort ein PoS-Tag, das die gramma-
tikalische Wortart beschreibt, bestimmt. Hier k¨onnen regelbasierte oder statistische
Verfahren angewendet werden. Regelbasierte Verfahren st¨utzen sich auf formalisier-
tes Wissen aus der Linguistik.
Ein Beispiel f¨ur ein statistische Verfahren ist der Baseline-Tagger, der auf dem
Hidden-Markov-Modell [94] basiert. In einem Hidden-Markov-Modell werden Be-
obachtungen mit gewissen Wahrscheinlichkeiten von Zust¨anden generiert. Zwischen
zwei Zust¨anden existieren ¨Uberg¨ange, die ebenfalls mit einer bestimmten Wahr-
scheinlichkeit durchlaufen werden, wobei die Wahrscheinlichkeit f¨ur einen Folge-
zustand nur vom aktuellen Zustand abh¨angt (Markov-Eigenschaft). Als Beobach-
tungen werden in diesem Fall die Menge der W¨orter des Lexikons verstanden, die
Zust¨ande entsprechen den m¨oglichen PoS-Tags. Die Wahrscheinlichkeit, dass ein
Zustand eine Beobachtung ausl¨ost entspricht dann der Wahrscheinlichkeit, dass ein
Wort einem bestimmten PoS-Tag angeh¨ort und die Zustands¨ubergangswahrschein-
lichkeit entspricht der Wahrscheinlichkeit, dass ein bestimmtes PoS-Tag auf ein an-
deres folgt. Die Wahrscheinlichkeiten k¨onnen ¨uber einen annotierten Referenzkor-
pus stochastisch ausgez¨ahlt werden. Mehr Informationen zu PoS-Tagging nach dem
Hidden-Markov-Model k¨onnen in [43] nachgelesen werden.
Information Extraction
Aus den Daten k¨onnen nun Informationen extrahiert werden. Ziel ist die strukturierte
Speicherung von Informationen, wie die Erw¨ahnung von bestimmten Entit¨aten (Konzep-
ten) und Relationen zwischen diesen Konzepten in einem Klartext.
Named Entity Recognition Mithilfe von Named Entity Recognition werden atomare
Konzepte aus der
”
realen Welt“ in einem Text identifiziert. Die textuelle Repr¨asen-
tation dieser Konzepte kann zum Beispiel in einer Wissensbasis (s. Abschnitt 2.4.1)
abgelegt sein, sodass ¨uber eine einfache Hashing-Tabelle ein Wort, und gegebenen-
falls Ergebnisse der vorherigen Analyseschritte, einem Konzept effizient zugeordnet
werden kann. Hier k¨onnen alle im vorherigen Schritt gewonnenen Informationen
(Wortstamm, PoS-Tags etc.) zu Rate gezogen werden. Dabei kann auch der Kon-
text, in dem das Wort steht, betrachtet werden. Als Kontext kann man zum Beispiel
auffassen, ob ein kontextbeschreibendes Wort oder dessen ¨Uber- bzw. Unterbegriffe
in der N¨ahe des analysierten Wortes auftauchen [77]. Neben diesem regelbasierten
Ansatz, bei dem eine Wissensbasis die Grundlage bildet, existieren selbstlernende
Methoden wie der iterative Bootstrapping-Algorithmus [74].
Relation Extraction Beziehungen zwischen Konzepten k¨onnen ebenfalls mit Hilfe einer
Wissensbasis extrahiert werden: Der Relationsname kann ebenfalls in einer Wissens-
basis als Entit¨at definiert sein. Nimmt man an, dass eine Relation sowie die betei-
ligten Konzepte in einem Dokument gemeinsam erw¨ahnt werden, kann man f¨ur jede
Relation, die im Schritt der Named Entity Recognition erkannt wurde, nach an der
Relation beteiligten Entit¨aten in deren unmittelbarer Umgebung suchen. Die gefun-
13

2. Technologien
denen Relationen k¨onnen der Wissensbasis hinzugef¨ugt werden. Zu diesem Thema
wurde im Daimler-Projekt
”
Automotive Internet Mining“ (AIM) bereits umfangrei-
che Forschung betrieben [77]. Diese Arbeit soll auf Relation Extraction nicht weiter
eingehen und sich mit der M¨oglichkeit der sp¨ateren Erweiterung auf Named Entity
Recognition beschr¨anken.
2.2.4. Unstructured Information Management Architecture (UIMA)
und InfexNG
UIMA [4] (Unstructured Information Management Architecture) ist ein von der Firma
IBM entwickeltes und zur Zeit durch die Apache Foundation betreutes Framework zur
Verarbeitung gr¨oßerer Mengen von unstrukturierten Informationen, die in Form von Bil-
dern, Audio-Daten oder Texten vorliegen. Es eignet sich daher besonders zur Realisierung
von NLP-Anwendungen. UIMA ist Java-basiert und unterst¨utzt insbesondere die Par-
allelisierung der Verarbeitungsschritte in unterschiedlichen Threads sowie die Verteilung
von dieser auf unterschiedlichen Rechnern nach dem Paradigma der Serviceorientierten
Architekturen (s. Abschnitt 2.5). Auf diese Weise wird eine optimierte, skalierbare Last-
verteilung f¨ur große Datenmengen gew¨ahrleistet.
In UIMA sind unterschiedliche Verarbeitungsschritte in einem Workflow, einer Art Pi-
peline, realisiert, deren Quelle ein Collection Reader ist, welcher Ressourcen (in diesem
Fall Dokumente) sukzessive einliest. Dem schließen sich Analysis Engines an, welche die
Daten verarbeiten. Abschließend schreibt ein Consumer das Ergebnis der Verarbeitung
in eine Senke. Das Dokument und alle assoziierten Metadaten werden in der sogenann-
ten CAS (Common Analysis Structure) verwaltet, welche von einem Analyseschritt zur
n¨achsten ¨ubergeben wird. Sie enth¨alt die Rohdaten (im Falle von Textdaten also den Klar-
text) sowie beliebig viele assoziierte Objekte, sogenannte Features. Die Featureklassen
werden durch den Entwickler vorher in einem Typsystem definiert. Sie sind serialisierbar
und deserialisierbar um den Transport der Objekte zwischen den Analyseschritten auch
in verteilten Systemen zu erm¨oglichen.
Die Aufgabe einer einzelnen Analysis Engine ist es, aus einem CAS-Objekt unter der
Verwendung aller dort abgelegten Daten neue Daten extrahieren. Dabei k¨onnen alle im
vorherigen Schritt gewonnenen Daten, insbesondere der Klartext, zu Rate gezogen werden.
Sie – insbesondere der Klartext – d¨urfen jedoch nicht modifiziert werden. Eine Analysis
Engine f¨ugt der CAS lediglich neue Features hinzu und l¨asst die CAS sonst unangetas-
tet. Spezielle Features sind Annotations. Sie markieren einen bestimmten Bereich im
Klartext ¨uber einen Start- und Endindex und beschreiben diesen Bereich ggf. mit Hilfe
von weiteren assoziierten Objekten. ¨Uber Annotationen ist die Darstellung der Analyse-
ergebnisse aller im Abschnitt 2.2.3 besprochenen Verarbeitungsschritte m¨oglich: Tokens
k¨onnen ¨uber Tokens repr¨asentiert werden, PoS-Tags ¨uber PoSTagAnnotations usw.
Sowohl das CAS-Typsystem als auch alle einzelnen UIMA-Komponenten, deren verwende-
tes Typsystem und die Komposition der UIMA-Komponenten zu einem Workflow werden
in sogenannten Deskriptoren beschrieben. Dies sind XML-Dateien, die von UIMA einge-
14

2.3. Information Retrival
lesen werden. Aus den XML-Dateien des Typsystems kann mithilfe eines Eclipse-Plugins
direkt der Java-Quellcode f¨ur die Featureklassen des Typsystems generiert werden. Bei
Deskriptoren von UIMA-Komponenten wird auf Java-Klassen verwiesen, in denen der
Entwickler noch die Programmlogik der UIMA-Komponente implementieren muss. Der
Workflow selbst wird durch die sogenannte Collection Processing Engine gesteuert,
welcher durch den Collection Processing Manager aufgerufen wird.
Viele der in Unterabschnitt 2.2.3 vorgestellten NLP-Verarbeitungsschritte wurden bei
der Daimler AG bereits im Rahmen des AIM-Projektes als UIMA Analysis Engines
implementiert. Sie werden im firmeninternen Framework InfexNG (Information Ex-
traction Next Generation) bereitgestellt und sind in [80] eingehend beschrieben. Ande-
re NLP-Frameworks sind die frei verf¨ugbaren Frameworks OpenNLP [31], GATE [13]
oder das kommerzielle Framework LingPipe [20]. Diese Frameworks sind allerdings auf
die englische Zeitungssprache optimiert und nicht, wie die InfexNG-Komponenten, spra-
chunabh¨angig oder in der Dom¨ane des Automobilbaus einsetzbar. Allerdings lassen sich
diese Frameworks f¨ur ihren Anwendungsfall vergleichsweise einfach in UIMA integrieren
[33, 44, 45].
2.3. Informationen wiederfinden mittels Information
Retrieval
Das Fachgebiet Information Retrieval besch¨aftigt sich mit dem gezielten, effizienten
Auffinden von Dokumenten, die f¨ur ein Informationsbed¨urfnis eines Nutzers relevant sind.
Zun¨achst muss der Anwendungsfall des Retrievals gegen den des Browsing abgegrenzt
werden: Im Falle von Browsing ist die konkrete Problemstellung h¨aufig nicht klar formu-
lierbar und der Nutzer bewegt sich zum Beispiel mit Hilfe von Hyperlinks von Dokument
zu Dokument, von Information zu Information.
Information Retrieval Systeme bezeichnet man umgangssprachlich auch als
”
Suchmaschi-
nen“. Im Gegensatz zu Suchanfragen an Datenbanksystem, sogenannte Data Retrie-
val Systeme, werden jedoch keine punktgenauen Anfragen und Informationen erm¨oglicht,
sondern es ist stets mit einer gewisse Vagheit der Anfrage und Unsicherheit der r¨uck-
gegebenen Information zu rechnen. Dieses Ph¨anomen ist auch dadurch bedingt, dass ein
Nutzer sein Informationsbed¨urfnis einerseits h¨aufig nicht konkret maschinenlesbar formu-
lieren kann und andererseits die in Dokumenten abgelegten Informationen h¨aufig nicht
exakt maschinell interpretiert werden k¨onnen. Der Nutzer muss die Informationen daher
weiter bewerten und m¨oglicherweise mit anderen Informationen verkn¨upfen um sicheres
Wissen zu erlangen, das f¨ur eine Entscheidung zielf¨uhrend ist.
¨Ublicherweise wirken zwei Akteure auf ein Information Retrieval System ein: Autoren und
Anwender. Autoren schreiben Dokumente, welche zun¨achst in eine passende Dokumenten-
repr¨asentation ¨uberf¨uhrt (indiziert) werden m¨ussen. Anwender haben hinsichtlich eines
Problemes einen Informationsbedarf und formulieren darauf basierend eine Anfrage. Die
Repr¨asentation der Dokumente und der Suchanfrage h¨angen eng zusammen und bilden
15

2. Technologien
das Repr¨asentationsmodell (auch IR-Modell. Ausgehend von diesem Modell kann er-
mittelt werden, welches Dokument f¨ur eine Anfrage relevant ist (Filterung) wonach die
gefundenen Dokumente schließlich nach Relevanz sortiert werden (Ranking). Die Ergeb-
nisliste kann den Nutzer dazu veranlassen, ¨Anderungen an der Suchanfrage vorzunehmen
oder, falls m¨oglich, den Suchindex zu modifizieren.
Wurde ein Modell gew¨ahlt, muss eine konkrete Implementation des Suchindex entwickelt
werden. Prominent ist hier die Realisierung als Inverted Index [58]. Es wird eine Lis-
te von Indextermen – am Besten effizient in einem Suchbaum – gespeichert. F¨ur jeden
Indexterm wird eine Liste von Dokumenten gehalten, in denen der Indexterm auftaucht.
Gegebenenfalls wird neben dem Verweis auf das Dokument die Gewichtung des Indexter-
mes gespeichert.
Ein frei verf¨ugbares, java-basiertes Information Retrieval Framework ist Lucene [2] von
der Apache Foundation. F¨ur den Unternehmenseinsatz existieren weitere, zum Teil kom-
merzielle Systeme, wie Microsoft Fast Search [11] oder Google Search Applian-
ce [15].
2.3.1. Extraktion und Gewichtung der Indexterme
Alle IR-Modelle haben gemeinsam, dass zur Indizierung erst bestimmte Indexterme aus
dem Text extrahiert und diese gewichtet werden m¨ussen. Als Indexterme k¨onnen die im
Klartextes des Dokumentes vorkommenden W¨orter verstanden werden. Zur Extraktion
dieser werden Algorithmen des Natural Language Processings verwendet, die bereits in
Unterabschnitt 2.2.3 vorgestellt wurden. Durch die zus¨atzlichen NLP-Verarbeitungsschritte
werden Rechtschreibfehler im Klartext korrigiert (Rechtschreibkorrektur) sowie, unter
Nutzung einer Wissensbasis (siehe Abschnitt 2.4) synonymunabh¨angig auf ihre Konzep-
te abgebildet (Named Entity Recognition). Indem sowohl Suchanfrage und Dokumente
derselben NLP-Verarbeitung unterzogen werden, ist die Verarbeitung unter demselben
Repr¨asentationsmodell gew¨ahrleistet. Das Vorverarbeiten der Suchanfrage wird dabei
auch als Query Expansion bezeichnet.
Die Gewichtung der Indexterme f¨ur ein Dokument, kann zum Beispiel mittels des
”
Term
Frequency – Inverse Document Frequency“-Maßes bestimmt werden.
Die Term Frequency tfi,j trifft eine Aussage dar¨uber, mit welcher Frequenz ein Term ti
im Dokument dj auftritt (ni,j dr¨uckt aus, wie oft Term ti in Dokument dj vorkommt):
tfi,j =
ni,j
k nk,j
Die Inverse Document Frequency idfi beschreibt, wie wichtig der Term in einem Textkor-
pus allgemein ist, indem die Anzahl der Dokumente (|D|) und die Anzahl der Dokumente,
welche den Indexterm enthalten (|{dj ∈ D : ni,j = 0}|), verglichen werden
idfi = log
|D|
|{dj ∈ D : ni,j = 0}|
16

2.3. Information Retrival
Das Maß
”
Term Frequency – Inverse Document Frequency“ wird durch Multiplikation der
beiden Terme bestimmt:
tfidfi,j = tfi,j · idfi
Eine hohe Gewichtung kann erzielt werden, indem eine hohe Termfrequenz im Dokument
(hohe tfi,j) bei gleichzeitig geringer Dokumentenfrequenz des Terms ¨uber den gesamten
Korpus (hohe idfi) erreicht wird. Die Gewichtung eliminiert demnach besonders h¨aufig
vorkommende W¨orter.
2.3.2. Bewertung von Retrieval-Systemen
Um die G¨ute eines Information Retrieval Systems beurteilen zu k¨onnen existieren die
objektiven Maße Recall, Precision und Fallout, welche Werte zwischen Null und Eins
annehmen k¨onnen und voneinander abh¨angen.
Die Trefferquote (Recall) beschreibt, mit welcher Wahrscheinlichkeit ein relevantes Do-
kument gefunden wird:
Recall =
|{dj ∈ D : dj relevant} ∩ {dj ∈ D : dj gefunden}|
|{dj ∈ D : dj relevant}|
Die Genauigkeit (Precision) beschreibt, mit welcher Wahrscheinlichkeit ein gefundenes
Dokument relevant ist:
Precision =
|{dj ∈ D : dj relevant} ∩ {dj ∈ D : dj gefunden}|
|{dj ∈ D : dj gefunden}|
Die Ausfallquote (Fallout) beschreibt, mit welcher Wahrscheinlichkeit ein irrelevantes
Dokument gefunden wird:
Fallout =
|{dj ∈ D : dj irrelevant} ∩ {dj ∈ D : dj gefunden}|
|{dj ∈ D : dj irrelevant}|
Precision, Recall und Fallout werden anhand des Goldstandards [54] bestimmt: hier sind
eine Reihe von Informationsbed¨urfnissen (¨ubersetzbar in Suchanfragen) gegeben und f¨ur
dieses Informationsbed¨urfnis die jeweilige Relevanz jedes Dokuments (relevant oder irrele-
vant). Die Suchergebnisse des Information Retrieval Systems hinsichtlich der Suchanfrage
werden dann mit den erwarteten Ergebnissen verglichen und die Bewertungsgr¨oßen Pre-
cision, Recall und Fallout wie oben berechnet. Es ist zu beachten, dass
”
relevant“ und
”
irrelevant“ sich auf das Informationsbed¨urfnis, nicht auf die Suchanfrage beziehen – es
reicht also zum Beispiel nicht aus, dass ein Dokument nur die durch die Suchanfrage
beschriebenen Schl¨usselw¨orter enth¨alt.
17

2. Technologien
Semantische Reichhaltigkeit, Formalisierungsgrad,
Aussagekraft, Komplexität
Topic Map
Ontologie
Taxonomie
Thesaurus
Glossar
Abbildung 2.3.: Vom Glossar ¨uber Taxonomien zu Ontologien
2.4. Von Informationen zu Wissen –
Wissensrepr¨asentation und Semantic Web
Aus Daten extrahierte Informationen repr¨asentieren, in einen Kontext eingeordnet und
mit semantischer Bedeutung versehen, Wissen. Die Bedeutung und der Kontext lassen
sich durch eine Wissensbasis beschreiben und das extrahierte Wissen kann die Wissens-
basis weiter anreichern. Bei der Daimler AG existieren Bestrebungen, in der Fahrzeug-
diagnose eine solche Wissensbasis zu etablieren, um mithilfe eines Decision Support
System (Entscheidungsunterst¨utzungssystem) auf Problemstellungen m¨oglichst punkt-
genaues, probleml¨osendes Wissen zu liefern.
Dieser Abschnitt stellt Methoden zur Repr¨asentation von Wissen vor und gibt Beispiele
f¨ur technische Realisierungen von Wissensbasen. Zun¨achst wird eine Einf¨uhrung in ver-
schiedene Modelle der Wissensrepr¨asentation gegeben (2.4.1). Daraufhin wird RDF als
konkrete Technologie zur Realisierung einer Wissensbasis sowie die Sprache SPARQL zur
Abfrage von Wissensbasen eingef¨uhrt (2.4.2). Schließlich wird das Semantic Media Wiki
vorgestellt, eine System, in dem Dokumente abgelegt und mit einer Wissensbasis
”
¨uber-
lagert“ werden k¨onnen und das neben der Ausgabe von RDF auch viele kollaborative
Funktionen, wie Diskussionen oder gemeinsames Arbeiten an Dokumenten, unterst¨utzt
(2.4.2).
2.4.1. Vom Glossar ¨uber Taxonomien zu Ontologien
Um Wissen maschinenlesbar zu repr¨asentieren, m¨ussen isolierte Konzepte und Rela-
tionen zwischen diesen Konzepten formalisiert werden. Dies kann in unterschiedlich aus-
gepr¨agter Komplexit¨at und Formalisierungsgrad geschehen. Abbildung 2.3 illustriert die
entsprechende Terminologie, die im folgenden erl¨autert wird:
Glossare stellen den niedrigsten Formalsierungsgrad dar und sind eine eher informell
gehaltene Liste von Konzepten mit dazugeh¨origen Erkl¨arungen.
Taxonomien definieren eine Anzahl von Konzepten und zu diesen Begriffen eine Hypo-
18

2.4. Wissensrepr¨asentation und Semantic Web
nym- (Unterbegriff-) und dual Hyperonym- (Oberbegriff-) Relation (Subsumption).
Diese Relation kann auch Meronym- (Teil-von-) bzw. dual Holonym (Ganzes-von-)
Beziehungen aufgefasst werden. Ein Graph mit den Konzepten der Taxonomie als
Knoten- und der entsprechenden Hyponym-/Hyperonym-Relation als Kantenmenge
ist gerichtet und azyklisch, macht man zus¨atzlich die Einschr¨ankung, dass ein Kon-
zept nur genau einem ¨ubergeordneten Konzept zugeordnet sein darf, erh¨alt man
sogar eine Baumstruktur.
Thesauri erweitern Taxonomien um eine Synonymrelation und weitere, beliebige (¨Ahn-
lichkeits-) Relationen. Im Rahmen des Wordnet-Projektes [84] wurde zum Beispiel
ein Thesaurus der englischen Sprache entwickelt.
Topic Maps sind eine gem¨aß ISO-Standard 13250-2 [71] in XML definierte Repr¨asen-
tationsform von Wissen. Eine Topic Map definiert abstrakte Begriffe (sg. Topics),
m¨ogliche Relationen zwischen ihnen und G¨ultigkeitsbereiche f¨ur sie (sg. Scopes) so-
wie zugeordnete Dokumente außerhalb der Topic Map (sg. Occurences). Bei der
Daimler AG wurden im Rahmen des Projekt AIM (Automotive Internet Mining)
bereits Arbeiten erstellt, die Topic Maps zur Repr¨asentation von Wissen in pro-
duktnahen Internetforenbeitr¨agen und zum Information Retrieval einsetzen (siehe
[99]).
Ontologien sind die m¨achtigsten (d.h. komplexesten und formellsten) Wissensrepr¨asenta-
tionsformen. Sie gehen in folgenden Aspekten ¨uber eine Taxonomie hinaus: [72, 87]
1. Zwischen Konzepten lassen sich beliebige Relationen definieren, die ihrerseits
Konzepte sind.
2. F¨ur Konzepte lassen sich Attribute definieren – Variablen f¨ur Zeichenketten,
die hinsichtlich eines definierten atomaren Datentyps interpretiert werden k¨on-
nen.
3. Es lassen sich Axiome definieren. Dies sind pr¨adikatenlogischen Regeln, die es
erlauben, mittels Deduktion von vorhandenen Relationen oder Attributen auf
neue Relationen zu schließen bzw. die Integrit¨at von Relationen und Attributen
zu ¨uberpr¨ufen.
4. Man kann formell zwischen Ontologieschema und Ontologieinstanz unterschei-
den. In einer Ontologieinstanz sind konkrete Instanzen f¨ur Konzepte mit kon-
kreten Belegungen f¨ur Relationen und Attribute vorhanden. Das Prinzip der
Instanziierung l¨asst sich jedoch auch ¨uber eine Instanziierungsrelation zwi-
schen zwei Konzepten realisieren, sodass diese getypten Ontologien nicht aus-
drucksst¨arker sind als ungetypte.
Ein Framework zur Verarbeitung und zum logischen Schließen auf Ontologien ist
OntoBroker [25] von der Firma OntoPrise. Dieses Framework bietet unter
anderem einen Webservice an, ¨uber den mittels der Sprache F-Logic [76], einer
Prolog-¨ahnlichen Sprache, Anfragen an die Ontologie gestellt werden k¨onnen. Im
Rahmen der Arbeit von [93] wurde und wird zur Zeit von der Firma Gigatronic
der Versuch unternommen, eine Ontologie f¨ur die Fahrzeugdiagnose der Daimler
19

2. Technologien
AG aufzustellen.
Wissensbasen erm¨oglichen eine ¨ubergreifende, abstrahierende Sicht auf heterogene In-
formationsquellen. In strukturierten Informationsquellen (z.B. relationalen Datenbanken)
k¨onnen Beziehungen zwischen den Originaldaten und deren Attribute direkt isomorph auf
Konzepte und deren Relationen abgebildet werden. Auf semistrukturierten Daten, speziell
Textdokumenten, k¨onnen Verfahren des Text Minings, speziell des Named Entity Re-
cognition dazu genutzt werden, einzelne Instanzen von Konzepten im Text zu erkennen
und durch Relation Extraction dann erw¨ahnte Beziehungen zwischen diesen Instan-
zen zu etablieren (s. Abschnitt 2.2). Firmen, die sich ausschließlich mit der Extraktion
von neuem Wissen aus Dokumenten auf Basis von Wissensbasen besch¨aftigen sind zum
Beispiel Attensity [16] oder Gnowsis [1].
2.4.2. Das Resource Description Framework (RDF) und die
RDF-Abfragesprache SPARQL
Das RDF (Resource Description Framework) bezeichnet eine Reihe von durch das W3C
entwickelte Standards [51] um Metainformation ¨uber Ressourcen, die sich durch einen
URI repr¨asentieren lassen, abzulegen. Durch RDF sollen Heterogenit¨at, Offenheit und
Verkn¨upfung, d.h. Eigenschaften, die dem World Wide Web zum Erfolg verholfen haben,
auf allgemeine Daten ¨ubertragen werden.
RDF basiert auf einem einfachen, aber wohldefinierten Datenmodell (RDF-Modell). Daten
in RDF sind wahre Aussagen ¨uber Ressourcen, die als Tripel formuliert werden. Ein Tripel
besteht aus einem Subjekt, einem Pr¨adikat und einem Objekt und stellt somit eine
bin¨are, gerichtete Relation zwischen Subjekt und Objekt her. Die Menge der Tripel bildet
einen gerichteten Graph.
Das Subjekt ist eine URI und bezeichnet die Ressource, ¨uber welche die Aussage gemacht
wird. Das Objekt kann entweder eine URI oder ein Literal (eine m¨oglicherweise getypte
Zeichenkette) sein. Das Pr¨adikat wird ebenfalls in Form einer URI angegeben um die
Beziehung eindeutig zu benennen. Damit ist es auch m¨oglich, das Pr¨adikat in weiteren
Aussagen als Subjekt oder Objekt zu verwenden.
Die Bedeutung der URIs ist von der Dom¨ane abh¨angig. Es existieren verschiedene Be-
m¨uhungen, diese Semantic Vocabularies zu standardisieren (z.B. DOAP, Description-
of-a-Project zur Beschreibung von Softwareprojekten [9]). Auf diese Weise lassen sich
komplexe Relationsnetzwerke modellieren, ¨uber denen mithilfe eines Inferenzsystems lo-
gische Schl¨usse gezogen werden k¨onnen. RDF eignet sich also zur Ontologie-Spezifikation
gem¨aß den in Unterabschnitt 2.4.1 eingef¨uhrten Begriffen: Objekte entsprechen Konzep-
ten, Pr¨adikate entsprechen Relationen und Literale Attributen. Neben RDF existiert die
weit komplexere Sprache OWL (Web Ontology Language) [98], mit der sich dar¨uber hin-
aus Axiome modellieren lassen, die allerdings in dieser Arbeit nicht vorgestellt werden
soll.
Ein RDF-Modell kann auf verschiedene Art und Weise repr¨asentiert werden. Die men-
20

2.4. Wissensrepr¨asentation und Semantic Web
schenlesbare XML-Repr¨asentation ist RDF/XML [55]. Eine k¨urzere Variante ist N3,
die von Tim Berners-Lee entworfene Notation 3 [57]. Tats¨achlich werden RDF-Modelle
jedoch in weitaus effizienteren Datenstrukturen (sogenannten Triple Stores) abgelegt.
Eine ¨Ubersicht zu Triple Stores, die auch auf Skalierbarkeit und Performance eingeht, wur-
de durch das W3C erarbeitet (siehe [42]). Beispiele f¨ur offene, Java-basierte RDF-Stores
und -Frameworks sind Sesame, entwickelt von OpenRDF [26] und Jena [30].
SPARQL (SPARQL Protocol and RDF Query Language) ist graph-basierte Anfrage-
sprachen, mit denen Daten aus RDF-Modelle abgefragt werden k¨onnen. Sie wurde von
der RDF Data Access Working Group (DAWG) des World Wide Web Consortium (W3C)
entwickelt und 2008 als Recommendation standardisiert. Es existieren mehrere Frame-
works, die mit RDF umgehen k¨onnen, so z.B. ARQ, eine Abfrage-Engine f¨ur das oben
bereits vorgestellte Framework Jena.
Listings 2.1 und 2.2 zeigen eine Mini-Ontologie aus der Dom¨ane der Fahrzeugdiagnose
in RDF/XML- bzw. N3-Schreibweise. Der Graph dieser Mini-Ontologie ist in Abbildung
2.4 dargestellt. In ihr wird ausgedr¨uckt, dass im Falle des Symptoms symptom_x der
Fehlercode dtc_y1 und dtc_y2 gesetzt sind. Listing 2.3 zeigt eine SPARQL-Anfrage, die
alle Symptome zur¨uckgibt, f¨ur die der Fehlercode dtc_y1 als gesetzt beschrieben ist.
1 <?xml version="1.0"?>
2 <rdf:RDF
3 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4 xmlns:diag="http://example.org/automotive/diagnosis/">
5 <rdf:Description rdf:about="http://example.org/automotive/diagnosis/symptoms/
symptom_x">
6 <diag:dtcSet>http://example.org/automotive/diagnosis/dtcs/dtc_y1</
diag:dtcSet>
7 <diag:dtcSet>http://example.org/automotive/diagnosis/dtcs/dtc_y2</
diag:dtcSet>
8 </rdf:Description>
9 </rdf:RDF>
Listing 2.1: Darstellung einer Mini-RDF-Ontologie mit RDF/XML
1 <http://example.org/automotive/diagnosis/symptoms/symptom_x> has <http://
example.org/automotive/diagnosis/dtcSet> <http://example.org/automotive/
dtcs/dtc_y1>
2 <http://example.org/automotive/diagnosis/symptoms/symptom_x> has <http://
example.org/automotive/diagnosis/dtcSet> <http://example.org/automotive/
dtcs/dtc_y2>
Listing 2.2: Darstellung einer Mini-RDF-Ontologie mit N3
1 PREFIX diag: http://example.org/automotive/diagnosis/
2 SELECT ?symptom
3 WHERE {
4 ?symptom diag:dtcSet diag:dtcs/dtc_y1
5 }
21

2. Technologien
http://example.org/automotive/diagnosis/symptoms/symptom_x
htt // l / t ti htt // l / t tihttp://example.org/automotive
/diagnosis/dtcSet
http://example.org/automotive
/diagnosis/dtcSet
http://example.org/automotive/dtcs/dtc_y1 http://example.org/automotive/dtcs/dtc_y2
Abbildung 2.4.: Mini-Ontologie der Diagnose aus Listing 2.1 und 2.2
Listing 2.3: SPARQL-Abfrage der Mini-Ontologie aus Listings 2.2 bzw. 2.1.
Im Gegensatz zu Suchalgorithmen des Information Retrieval erm¨oglicht SPARQL nur
punktgenaue Fakten-Anfragen ¨uber den Triple Stores (¨ahnlich wie SQL ¨uber relationalen
Datenbanken) und unterscheidet sich daher von Suchalgorithmen, die in Abschnitt 2.3
vorgestellt wurden. Es existieren L¨osungen, beide Suchparadigma zu kombinieren, so z.B.
das Framework LuceneSAIL [21], welches das Suchframework Lucene als SAIL (Stora-
ge and Inference Layer Objects) in den Triple-Store Sesame integriert. Dadurch werden
die Literale eines RDF-Modells mit Methoden des Information Retrieval durchsuchbar ge-
macht. Das dazugeh¨orige Paper [85] beschreibt verschiedene Strategien, wie RDF-Tripel
oder -Konzepte auf Lucene-Dokumente abgebildet werden k¨onnen (Ressource-basiert –
ein Dokument pro Konzept – oder Tripel-basiert – ein Dokument pro Tripel). F¨ur die
indizierten Tripeln stellt der SAIL virtuelle Pr¨adikate wie matches zur Verf¨ugung, mit
denen IR-Suchanfragen direkt in SPARQL formulierbar sind.
2.4.3. Semantic Media Wiki als kollaborative semantische
Dokumentenplatform
Um Dokumente, oder dar¨uber hinaus, enthaltenes Wissen dem Nutzer zu pr¨asentie-
ren, muss ein passendes Frontend ausgew¨ahlt werden. Ein Wiki ist eine kollaborative
Hypertext-Plattform, auf der jeder Benutzer die gespeicherten Dokumente nicht nur le-
sen, sondern auch im Browser mittels einer einfach zu erlernenden Auszeichnungssprache
bearbeiten, sowie ¨uber die Dokumente diskutieren kann. Ein Wiki als System zur Do-
kumentenablage bietet einem Unternehmen so den Vorteil, dass ¨Anderungen am Doku-
mentenbestandes schnell und in Echtzeit durch alle Beteiligten online verf¨ugbar gemacht
werden k¨onnen (Cloud Computing) und das zus¨atzlich ein ¨offentlicher Diskussionska-
nal angeboten wird, der protokolliert wird und sp¨ater als zus¨atzliche Wissensquelle dienen
kann. Es existieren verschiedene Wiki-Systeme, das bekannteste ist die Software Media
Wiki [22], welche von der Online-Enzyklop¨adie Wikipedia [38] benutzt wird. Inner-
halb der Wikipedia-Community hat sich ein Quasi-Standard etabliert, der festlegt, wie
ein Wiki-Artikel einheitlich zu formatieren ist (
”
Wikifizierung“) [39]. Bei der ¨Uberf¨uhrung
von f¨oderierten Dokumenten in ein Wiki sollten diese Grunds¨atze beachtet werden.
22

2.4. Wissensrepr¨asentation und Semantic Web
Semantic Media Wiki [27] ist eine Erweiterung der Media Wiki Software, welche die
semantische Auszeichnung von in einem Dokument beschriebenen Konzepten nach der
Idee des Semantic Web erm¨oglicht. Beispielsweise kann in einem Dokument, welches un-
ter dem Titel (Lemma)
”
Symptom X“ abgelegt ist, der Fehlercode
”
DCT Y“ als
”
gesetzt“
beschrieben sein. Dieser Fehlercode kann nun nach Wiki-Syntax verlinkt werden – durch
Einschließen in doppelt eckige Klammern: [[DCT Y]]. Dadurch wird er als eigenst¨andiges
Konzept identifiziert, f¨ur den ein eigenes Dokument (Lemma) angelegt werden kann. In ei-
nem Semantic Media Wiki ist nun zus¨atzlich die Typisierung des Links m¨oglich: Schreibt
man [[Fehlercode gesetzt::DCT Y]], etabliert man damit die Relation
”
Symptom X“
hat
”
Fehlercode gesetzt“
”
DCT Y“, ein Subjekt-Pr¨adikat-Objekt-Faktum im Sinne einer
Ontologie direkt auf dem Dokumentenkorpus.
Auch hier k¨onnen Pr¨adikate als Subjekte oder Objekte in komplexeren Aussagen wieder-
verwendet werden. Hierzu lassen sich Lemmata im speziellen Property-Namensraum de-
finieren. Hat man zum Beispiel ein Dokument, in dem eine Ist-Spannungswert von 230V
beschrieben ist, kann man diesen Wert mit [[Ist-Wert::230]]V auszeichnen und im
Seite Property:Ist-Wert die Eigenschaft [[has type::number]] angeben. Diese Aus-
zeichnung typisiert das angegebene Pr¨adikat als Zahl-Literal im Sinne einer Ontologie.
Semantic Media Wiki interpretiert den Typ des Pr¨adikates bei der Darstellung des kon-
kreten Wertes
”
230“ und stellt diesen im Frontend nicht als Link, sondern als normalen
Text dar.
Die explizite Auszeichnung von Fakten im Dokumenttext bringt den Vorteil, dass diese
Informationen maschinell abgefragt oder durchsuchbar gemacht werden k¨onnen. ¨Uber Me-
thoden des Natural Language Processing lassen sich diese semantischen Auszeichnungen
automatisch generieren. Der Wiki-Text selbst wird durch eine Wissensbasis
”
¨uberlagert“,
sodass das Wissen sp¨ater in eine Ontologie integriert und ¨uber Abfragesprachen gezielt
abgefragt werden kann. Im obigen Beispiel w¨are eine Abfrage der Liste aller Symptome f¨ur
einen bestimmten Fehlercode denkbar. Diese Abfrage k¨onnte entweder vom Nutzer ad-hoc
formuliert oder deren Ergebnisse in einem anderen Wikidokument dynamisch dargestellt
werden. Semantic Media Wiki bietet sprachliche Konstrukte und eine Abfrage-Engine,
die SPARQL-¨ahnliche Abfragen erlauben. Außerdem ist der Export des aufgespannten
Relationengraphes als RDF m¨oglich.
Die hinterlegten Fakten sind in einer einfachen relationalen Datenbank, in einer Tabel-
le mit Subjekt-Pr¨adikat-Objekt-Spalten gespeichert. Es existieren jedoch Triple Store
Konnektoren [49], die Wissensbasen wie das Jena-Framework oder Inferenzmaschinen
wie OntoBroker anbinden [49]. Eine Anbindung des Triple Stores Sesame, welche die
Verwendung von Sesame LuceneSAIL zur kombinierten semantischen und IR-Suche
erm¨oglichen w¨urde (siehe Unterabschnitt 2.4.2), ist zum Zeitpunkt dieser Arbeit jedoch
noch nicht vorhanden.
F¨ur die Software Media Wiki existiert weiterhin eine Erweiterung, welche das Suchfra-
mework Lucene als Information Retrieval L¨osung einbindet: die Media Wiki Lucene
Search Erweiterung [12]. Sie besteht aus zwei Einheiten: der eigentlichen Erweiterung,
die in PHP implementiert ist und sich in ein Media Wiki integrieren l¨asst. Innerhalb dieser
23

2. Technologien
Erweiterung wird die Klasse SearchEngine durch die Klasse LuceneSearch ¨uberschrie-
ben: diese stellt die Suchanfrage des Nutzers ¨uber das HTTP-Protokoll an einen Search
Daemon, der den zweiten Teil der Erweiterung darstellt. Der Search Daemon ist ein Java-
Programm, dass auf einem Netzwerkport nach eingehenden Suchanfragen lauscht. F¨ur
jede Suchanfrage wird ¨uber das Lucene-Framework ein Suchindex des Wikis abgefragt
und das Ergebnis zur¨uckgegeben.
Der Search Daemon bietet einen Programmaufruf zur Erstellung bzw. inkrementellen
Aktualisierung des Suchindexes an. Dazu l¨adt er sich einen Datenbankabzug des Wikis
herunter oder fragt die ¨Anderungen direkt vom Wiki ab, wenn dort die OAI Repository
Erweiterung [68] installiert ist. W¨ahrend der Indexerstellung l¨asst sich der alte Index zur
Suche weiterhin nutzen, denn das
”
Umschalten“ auf den neu generierten Index erfolgt
durch das Umlegen eines symbolischen Links im Dateisystem.
Jede Media Wiki-Installation bietet mit dem PHP-Skript w/api.php eine API an, ¨uber
die Programme, sogenannte Bots, Daten aus dem Wiki lesen und Daten des Wikis ¨an-
dern k¨onnen. Mit dem Java Wiki Bot Framework (JWBF) [19] existiert eine Java-
Klassenbibliothek, welche diese Schnittstelle nutzt. Die Klasse MediaWikiBot verwaltet
zum Beispiel die Verbindung zu einem Wiki, einzelne Artikel werden durch SimpleAr-
ticle repr¨asentiert.
2.5. Serviceorientierte Architekturen (SOA) als
Architekturparadigma
Serviceorientierte Architekturen bezeichnen ein Architekturparadigma f¨ur verteilte
Systeme, welches darauf abzielt, grobgranulare IT-Gesch¨aftsprozesse einheitlich zu imple-
mentieren und konzernweit verf¨ugbar zu machen. Der Einsatz von SOA im Kontext der
semantischen F¨oderation wird durch zwei Tatsachen motiviert: zum Einen ist der Zugriff
auf Datenbest¨ande im Unternehmensumfeld ¨uber ein verteiltes System ohnehin sinnvoll,
da sich so Sicherheits- und Konsistenzregeln, sowie eine zentrale Datenhaltung durchset-
zen l¨asst. Außerdem wird der gleichzeitige Zugriff auf die Daten durch mehrere Nutzer
erm¨oglicht. Ein SOA-Dienst bietet dar¨uber hinaus die Modellierung der ausgetauschten
Daten als komplexe Gesch¨aftsobjekte.
Serviceorientierte Architekturen k¨onnen desweiteren eingesetzt werden, um aufw¨andige,
parallelisierbare Verarbeitungsschritte des Natural Language Processings auf verschiede-
nen Rechnern als Dienst anzubieten und so die Last optimal zu verteilen. Das UIMA-
Framework bietet die M¨oglichkeit an, einzelne Verarbeitungsschritte als Dienst auszula-
gern. Dies soll jedoch hier noch nicht weiter verfolgt werden.
Ein Dienst im Sinne der SOA repr¨asentiert eine gekapselte fachliche Funktionalit¨at in
einem Netzwerk. Er wird plattformunabh¨angig angeboten, implementiert eine wohldefi-
nierte ¨offentliche Schnittstelle und ist in einem Verzeichnis registriert. Der Dienst wird bei
der Ausf¨uhrung (z.B. durch einen noch grobgranulareren Dienst) ggf. ¨uber das Verzeichnis
24

2.5. Service Oriented Architectures (SOA)
lokalisiert und dynamisch gebunden, das heißt, der Dienst selbst muss zur Erstellung der
Anwendung noch nicht implementiert sein (wohl aber muss die Schnittstelle definiert sein)
(vgl. [59]).
Die Komposition (Orchestrierung) der Dienste kann im einfachsten Fall durch eine
Punkt-zu-Punkt-Verbindung realisiert werden. Bei ausgedehnten Servicelandschaften emp-
fiehlt es sich jedoch, einen sogenannten Message-Broker (auch Message Oriented
Middleware MOM oder Enterprise Service Bus ESB) zur Vermittlung zwischen
Dienstnutzer und Dienstanbieter zu implementieren, um die Komplexit¨at des Gesamt-
systems zu senken.
Die Generizit¨at des Architekturmusters SOA zeichnet sich dadurch aus, dass sie unter-
schiedlichste Transportprotokolle f¨ur die Kommunikation zwischen Dienstnutzer und -
anbieter erlaubt. Bedingt durch den anhaltenden Erfolg des Webs erfreut sich allerdings
vor allem die Familie der Webservice-Protokolle stetiger Beliebtheit. Hier wird h¨aufig
HTTP favorisiert, seltener kommen SMTP oder FTP zum Einsatz. Da diese Protokolle
jedoch ebenfalls reine Nachrichtenprotokolle sind, sind zur Vereinheitlichung der Nachrich-
tenstruktur und der Beschreibung der Webservice-Schnittstelle weitere Standards n¨otig.
Hier sind vor allem REST (Representational State Transfer) [69], JSON (JavaScript Ob-
ject Notation) [65] und das XML-basierte Protokoll-Paar SOAP und WSDL zu nennen.
Diese werden in den folgenden Unterabschnitten beschrieben.
2.5.1. Die Web Service Description Language (WSDL)
Die Web Service Description Langugage (WSDL) beschreibt Schnittstellenaufruf und
-nutzung von XML-basierten SOA-Diensten. Dienstschnittstellen, welche durch WSDL
beschreieben werden, bezeichnet man als Web Services. Die Sprache WSDL wurde 2001
erstmals vom W3C [66] ver¨offentlicht und ist derzeit in der Version 2.0 verf¨ugbar [64].
In einer WSDL-Definition sind abstrakten Definitonen und konkreten Definitionen ei-
ner Dienstschnittstelle angegeben. In abstrakten Definitionen werden Datenstruktu-
ren vereinbart, die in der Kommunikation zwischen Dienstnutzer und -anbieter verwendet
werden (Types). Ferner werden atomare Nachrichten (Messages) definiert, die zwischen
den Parteien ausgetauscht werden und Instanzen der vorher definierten Datenstrukturen
(Parts) enthalten. Schließlich werden Port Types (bzw. seit WSDL 2.0 Interfaces) defi-
niert, welche eine eine Menge von Operationen (Operations) anbieten, die vom Dienstnut-
zer aufgerufen werden k¨onnen. F¨ur jede Operation werden zul¨assige Input-, Output- und
Fault-Messages festgelegt.
Mit diesen abstrakten Definitionen ist WSDL vergleichbar zu einer Schnittstellenbeschrei-
bungssprache wie der Interface Description Language [73]. Dar¨uber hinaus werden durch
konkrete Definitionen konkrete Transportprotokolle vereinbart. Diese Definitionen bein-
halten Bindings, in denen f¨ur alle Operations (und damit alle Messages) eines abstrakten
Port Types) je ein ¨Ubertragungsprotokoll mit seinen eventuellen Parametern spezifiziert
wird. Schließlich werden in Service-Definitionen alternative Ports (bzw. seit WSDL 2.0
25

2. Technologien
Endpoints) angeboten, die jeweils auf verschiedene Bindings, und damit auf alternative
¨Ubertragungsprotokolle, eines gemeinsamen Port Types verweisen. Zu jedem Port/End-
point werden außerdem transportprotokollspezifisch Einstellungen, wie die physikalische
URL, unter der der Webservice erreichbar ist, festgelegt.
Listing A.4 zeigt eine WSDL-Definition f¨ur eine im Rahmen dieser Arbeit entwickelten
Webservice-Schnittstelle: der Schnittstelle des Document Provider Webservices zum Zu-
griff auf heterogene Dokumente. Dieser Webservice wird in Abschnitt 4.2 erkl¨art. Bei
der Definition der Types wird typischerweise mittels xsd:include auf eine externe XSD-
Grammatik verwiesen.
Zur Standardisierung von bestimmten, st¨andig wiederkehrenden Web Service Technolo-
gien, wie z.B. (zuverl¨assige) Nachrichten¨ubertragung, Austausch von Metadaten, Sicher-
heit, Datenschutz, Spezifikation von Ressourcen oder Gesch¨aftsprozessen, Durchf¨uhrung
von Transaktion mit Hilfe von Webservices oder Verwaltung von Webservices, existieren
weitere Standards, die man allgemein mit WS-* bezeichnet, die allerdings von keinem
gemeinsamen Standardisierungsgremium entwickelt werden. Desweiteren sind durch die
Web Service Interoperability Organization (WS-I) Richtlinien und Tests zur Gew¨ahrleis-
tung der Interoperabilit¨at von Web Services definiert. [41]
2.5.2. SOAP als Protokoll zur Nachrichten¨ubermittlung
SOAP, urspr¨unglich Simple Object Access Protocol, hat seit der Version 1.2 den Status ei-
ner W3C-Empfehlung [86]. Es spezifiziert ein Protokoll zum Austausch von XML-basierten
Nachrichten in verteilten Systemen, um Remote Procedure Calls (RPC) zu realisieren. Als
zugrunde liegende Transportprotokolle kommen HTTP, HTTPS (Post-Methode), seltener
auch FTP oder SMTP zum Einsatz. Als Anwendungsprotokoll erlaubt es den Aufbau
schwach gekoppelter Systeme und eignet sich besonders, wenn direkter Zugang zu einem
System zugrunde liegender Daten nicht m¨oglich ist oder eingeschr¨ankt werden soll. Es eig-
net sich damit besonders als Nachrichtenprotokoll f¨ur Serviceorientierte Architekturen.
Minimale SOAP-Nachrichten bestehen aus einem <Envelope>-Element 2
, welches zumin-
dest ein <Body>-Element enth¨alt und einen <Header> enthalten kann. Innerhalb von <Bo-
dy> und <Header> k¨onnen beliebige XML-Informationen stehen.
Im Kontext von Web Services tauchen in <Body> ¨ublicherweise Messages auf, die in einer
WSDL-Definition definiert wurden und ¨uber den targetNamespace der WSDL-Definition
referenziert werden k¨onnen. Sie enthalten entweder Informationen zum entfernten Proze-
duraufruf eines Dienstnutzers an den Dienstanbieter (Input Message) oder Ergebnisse des
Prozeduraufrufs (eine Output oder Fault Message), die vom Dienstanbieter an den Dienst-
nutzer zur¨uckgesendet wird. Listing A.6 in Anhang A.1.3 stellt eine SOAP-Nachricht dar,
wie sie im Rahmen der Dienstnutzung des Document Provider Webservices versendet wird
(s. Abschnitt 4.2).
2
Namespace http://www.w3.org/2003/05/soap-envelope
26

2.5. Service Oriented Architectures (SOA)
2.5.3. Bew¨ahrte Konzepte bei der Realisierung Entwurf von
Webservices
Beim Entwurf eines Webservices als Softwaresystem stellt sich die Frage, wie eine Web-
service-Schnittstelle
”
in Code gegossen“ werden kann. Eine m¨ogliche Variante ist, f¨ur jedes
in der WSDL-Definition angegebene Binding eine Schnittstellenklasse zu definieren, die
dann vom Programmierer implementiert und zur Laufzeit f¨ur jede konkret durchgef¨uhr-
te Webservice-Anfrage instantiiert wird. In der Schnittstellenklasse wird jede Operation
durch genau eine Methode der Klasse repr¨asentiert. Input- und Output-Messages der in
WSDL definierten Operation entsprechen dann ¨Ubergabe- und R¨uckgabeparameter der
Methode, Fault-Messages werden durch Exceptions repr¨asentiert.
Die in der WSDL-Definition deklarierten Typen und Messages werden zur Laufzeit durch
Java-Objekte repr¨asentiert, der Code f¨ur die entsprechenden Klassen kann z.B. ¨uber ein
XML Data Binding Framework wie Castor dynamisch generiert werden (s. Unterab-
schnitt 2.2.2). Jede auf diese Art verwendete Methode empf¨angt als ¨Ubergabewert ihr ent-
sprechendes Input-Message-Objekt und gibt schließlich auch eine Output-Message-Objekt
zur¨uck. Beachtet man einige Konventionen, kann man auf das Kapseln (
”
wrapping“ ) des
Message-Inhaltes in einem der Methode ¨ubergebenen Message-Objekt allerdings verzich-
ten und stattdessen die in der Message enthaltenen Parameter direkt ¨ubergeben. Diese
Konventionen – von Microsoft Webservices verwendet, allerdings nicht offiziell dokumen-
tiert – sind: [63]
• Die Input Message enth¨alt einen einzigen Part.
• Dieser Part ist in der XSD ein Element Type.
• Das Element hat den Namen der Operation und keine Attribute.
Diese Konvention hat auch den Vorteil, dass aus dem Body eines SOAP-Envelope sofort
ersichtlich ist, um welche Operation es sich handelt, da der Name der Operation im ersten
Kindelement des <Body>-Elementes auftaucht.
2.5.4. Webservice-Technologien f¨ur Java
Um Webservices auf Java Webserver realisieren zu k¨onnen, ist zun¨achst ein Webserver
mit Servlet-Container vonn¨oten: es k¨onnen z.B. Glassfish [14] mit Grizzly oder
Tomcat [3] mit Catalina zum Einsatz kommen. Mit dem Anwendungsserverpaket wer-
den h¨aufig Plug-Ins f¨ur ¨ubliche IDEs, wie Eclipse [10], angeboten.
Unterst¨utzung von WSDL, SOAP und anderen Webservice-Technologien wird durch ver-
schiedene Webservice Frameworks f¨ur Java bereitgestellt. Die Glassfish API fasst eini-
ge dieser Webservice-Technologien unter dem sogenannten Metro-Stack [23] zusammen.
Neben dem Metro Webservice Stack steht mit Apache Axis [35] ein schlankes Frame-
work zur Realisierung von Webservice-Clients und -Servers auf Basis von SOAP und
WSDL zur Verf¨ugung. Das Framework erlaubt (ant-basierte) Codegenerierung von Typ-
27

2. Technologien
als auch Interface-/Rumpfklassen aus WSDL-Dateien und kann gemeinsam mit dem
XML-Data-Binding-Framework Castor eingesetzt werden. F¨ur die Serverkomponente
kontrolliert ein Servlet den Lebenszyklus des entsprechenden Java-Programms, welches
die Webservice-Schnittstelle implementiert. F¨ur die Clientkomponente werden ¨uber JAX-
RPC gem¨aß dem Proxy Design Pattern Remote Procedure Calls an den Webservice gesen-
det. Ein Vergleich von Apache Axis mit JAX-WS und anderen Web Service Frameworks
kann unter [36] nachgelesen werden.
2.6. Abgrenzung gegen verwandte Arbeiten
In den vorangegangenen Abschnitten wurden sowohl Technologien, als auch fr¨uhere For-
schungsarbeiten in den f¨ur diese Arbeit relevanten Disziplinen der Informationstechnologie
vorgestellt. Letztere sollen hier noch einmal zusammengefasst und gegen diese Arbeit ab-
gegrenzt werden.
Ausgangspunkt f¨ur diese Arbeit, und bereits mit diversen Ver¨offentlichungen in der wis-
senschaftlichen Gemeinschaft bekannt, ist das InfexNG-Framwork, dass im Rahmen des
AIM-Projektes entwickelt wurde [80, 99]. Allerdings wird das Framework derzeit nur im
Kontext der Informationsextraktion aus Internetforen mit dem Ziel der Qualit¨atssicherung
durch Analyse der Kundenzufriedenheit eingesetzt. Die Komponenten wurden teilweise
auch daf¨ur eingesetzt, Werkstattberichte zu analysieren, um festzustellen, welche Teile
h¨aufig defekt sind und getauscht werden. Zur F¨oderation von hererogenen Informations-
quellen, d.h., zur Analyse heterogener Dokumente, wurden diese Komponenten allerdings
noch nicht eingesetzt.
Das Aletheia-Projekt [47] ist dem AIM-Projekt verwandt, betrachtet aber dar¨uber hinaus
die Wissensextraktion von beliebigen Produktinformationen aus beliebigen heterogenen
Informationsquellen des World Wide Web, d.h., beschr¨ankt sich weder auf die Dom¨ane des
Automobilbaus, noch auf Diskussionen zur Produktqualit¨at, sondern versucht, beliebige
Fakten zu Produkten zu extrahieren. Dennoch wurde auch hier nicht versucht, Technologi-
en des Information Retrieval und Information Extraction direkt auf unternehmensinterne
Dokumente mit dem Ziel der Probleml¨osung, speziell in der Fahrzeugdiagnose, einzuset-
zen.
Firmen, die sich mit Wissensextraktion aus f¨oderierten Dokumenten befassen, wurden
kurz vorgestellt, darunter Attensity [16] und Gnowsis [1] mit dem Semantic Desktop.
Die hier eingesetzten Technologien basieren jedoch nicht auf frei verf¨ugbaren Frameworks
und sind f¨ur die spezielle Dom¨ane der Fahrzeugdiagnose nur bedingt geeignet. Auch ist es
nur eingeschr¨ankt m¨oglich, externe, bereits seit langer Zeit eingesetzte Informationsquellen
anzubinden.
Die Software OntoBroker der Firma Ontoprise erlaubt das Reasoning ¨uber beliebige
Ontologien. In diesem Zusammenhang wurde von Daimler eine firmenweite Ontologie
im Rahmen des Projektes Sidebar-Assistent entwickelt, das die Query Expansion von
Suchanfragen an die Intranetsuchmaschine erm¨oglicht, indem es z.B. ¨Uber- und Unterbe-
28