Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Technische Universit¨at Dresden Daimler AG
Fakult¨at Informatik Global Services & Parts
Institut f¨ur Systemarchitektur Op...
Fakultät Informatik, Institut für Systemarchitektur, Professur Rechnernetze
AUFGABENSTELLUNG FÜR DIE DIPLOMARBEIT
Name, Vo...
Selbstst¨andigkeitserkl¨arung
Hiermit erkl¨are ich, die vorliegende Diplomarbeit zum Thema
Semantische F¨oderation heterog...
”
Information ist nicht Wissen, Wissen ist nicht Weisheit,
Weisheit ist nicht Wahrheit, Wahrheit ist nicht Sch¨onheit,
Sch...
Kurzfassung
Die Informationsflut der heutigen Informationsgesellschaft erstreckt sich l¨angst nicht mehr
nur auf Medien des...
Abstract
Information flood, a phenomenon of todays information society, stopped being restricted
to the everyday media long...
Inhaltsverzeichnis
1. Einleitung 1
1.1. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...
Inhaltsverzeichnis
3.1.4. Auftragssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2. Herleitung der A...
Inhaltsverzeichnis
7. Ergebnisse und Ausblick 119
7.1. Beitrag dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . ....
1. Einleitung
Die F¨ulle an Informationen, die t¨aglich entsteht und menschlich wahrgenommen und ver-
standen werden muss,...
1. Einleitung
definierten Soll-Werten auf einen Fehler schließen. Die Daten in diesen Systemen werden
redaktionell gepflegt....
1.2. Projektkontext und Ansatz dieser Arbeit
Produkthaftung und des Datenschutzes von Kundendaten gar nicht erw¨unscht.
Ei...
1. Einleitung
m¨ogliches Zielsystem f¨ur das in dieser Arbeit zu entwickelnde System zur semantischen,
f¨oderierten Suche ...
2. Technologien zur Extraktion und
zum Retrieval von Wissen aus
f¨orderierten Dokumenten
In diesem Kapitel soll auf die in...
2. Technologien
Entscheiden
WissenSynthese
Zusammenfassung
InformationenAnalyse
Ordnen
(Roh‐)Daten
Ordnen
Sammeln
Abbildun...
2.2. Information Extraction
telligenz zum Einsatz. Ein Anwendungsfall entsprechender Methoden ist das Semantic
Web, dessen...
2. Technologien
n¨achst mit dem Blick auf die immer gr¨oßer werdende Informationsdichte im World Wide
Web. Auch Firmen wie...
2.2. Information Extraction
2.2.2. Verarbeitung semistrukturierter f¨oderierter Ressourcen in
XML
Als semistrukturierte Da...
2. Technologien
sequenziell eingelesen wird. F¨ur wohldefinierte Ereignisse, wie das Auftreten eines Start-
/Endtags wird e...
2.2. Information Extraction
2.2.3. Information Extraction aus Klartext durch Natural Language
Processing (NLP)
Die Struktu...
2. Technologien
w¨ahrend es im Deutschen weitaus mehr sind. Zus¨atzlich kommt hier das Problem der
Allomorphie (Um- und Ab...
2.2. Information Extraction
Part-of-Speech Tagging Schließlich wird f¨ur jedes Wort ein PoS-Tag, das die gramma-
tikalisch...
2. Technologien
denen Relationen k¨onnen der Wissensbasis hinzugef¨ugt werden. Zu diesem Thema
wurde im Daimler-Projekt
”
...
2.3. Information Retrival
lesen werden. Aus den XML-Dateien des Typsystems kann mithilfe eines Eclipse-Plugins
direkt der ...
2. Technologien
das Repr¨asentationsmodell (auch IR-Modell. Ausgehend von diesem Modell kann er-
mittelt werden, welches D...
2.3. Information Retrival
Das Maß
”
Term Frequency – Inverse Document Frequency“ wird durch Multiplikation der
beiden Term...
2. Technologien
Semantische Reichhaltigkeit, Formalisierungsgrad,
Aussagekraft, Komplexität
Topic Map
Ontologie
Taxonomie
...
2.4. Wissensrepr¨asentation und Semantic Web
nym- (Unterbegriff-) und dual Hyperonym- (Oberbegriff-) Relation (Subsumption)....
2. Technologien
AG aufzustellen.
Wissensbasen erm¨oglichen eine ¨ubergreifende, abstrahierende Sicht auf heterogene In-
fo...
2.4. Wissensrepr¨asentation und Semantic Web
schenlesbare XML-Repr¨asentation ist RDF/XML [55]. Eine k¨urzere Variante ist...
2. Technologien
http://example.org/automotive/diagnosis/symptoms/symptom_x
htt // l / t ti htt // l / t tihttp://example.o...
2.4. Wissensrepr¨asentation und Semantic Web
Semantic Media Wiki [27] ist eine Erweiterung der Media Wiki Software, welche...
2. Technologien
Erweiterung wird die Klasse SearchEngine durch die Klasse LuceneSearch ¨uberschrie-
ben: diese stellt die ...
2.5. Service Oriented Architectures (SOA)
lokalisiert und dynamisch gebunden, das heißt, der Dienst selbst muss zur Erstel...
2. Technologien
Endpoints) angeboten, die jeweils auf verschiedene Bindings, und damit auf alternative
¨Ubertragungsprotok...
2.5. Service Oriented Architectures (SOA)
2.5.3. Bew¨ahrte Konzepte bei der Realisierung Entwurf von
Webservices
Beim Entw...
2. Technologien
als auch Interface-/Rumpfklassen aus WSDL-Dateien und kann gemeinsam mit dem
XML-Data-Binding-Framework Ca...
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner
Nächste SlideShare
Wird geladen in …5
×

Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner

72 Aufrufe

Veröffentlicht am

"Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose".
Do not distribute.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Semantische Förderation heterogener Datenquellen in der Fahrzeugdiagnose - Diplomarbeit von Benjamin Söllner

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. ” 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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 Oberfl¨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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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

×