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

1. Technische Universität Dresden Daimler AG Fakultät Informatik Global Services & Parts Institut für Systemarchitektur Operations Support Services Professur für Rechnernetze Diagnose- und Flash-Technologien Prof. Dr. rer. net. habil. Dr. h. c. Alexander Schill Diagnose Antriebsstrang / Aggregate Semantische Föderation heterogener Informationsquellen in der Fahrzeugdiagnose Diplomarbeit zur Erlangung des akademischen Grades Dipl.-Medieninf. Benjamin Söllner 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örn Schwennicke bjoern.schwennicke@daimler.com

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. Selbstständigkeitserklärung Hiermit erkläre ich, die vorliegende Diplomarbeit zum Thema Semantische Föderation heterogener Informationsquellen in der Fahrzeugdiagnose selbstständig und ausschließlich unter Verwendung der im Quellenverzeichnis aufgeführ- 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ältigt werden. v

4. ” Information ist nicht Wissen, Wissen ist nicht Weisheit, Weisheit ist nicht Wahrheit, Wahrheit ist nicht Schönheit, Schönheit 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örn Schwennicke von der Daimler AG für seine anhaltende und ansteckende Begeisterungsfähigkeit für das vorliegende Thema und für sein Talent, mir genau die Führung zu geben und den Freiraum zu lassen, die ich zum kreativen Forschen für diese Arbeit benötig- te, sowie an Daniel Schuster vom Lehrstuhl Rechnernetze der TU Dresden für die kontinuierliche Förderung meiner wissenschaftlichen Interessen, für die ungezwungenen fachlichen Diskussionen und für Rat und Kritik bezüglich meiner ersten Gehversuche bei wissenschaftlichen Abhandlungen. Ebenfalls danken möchte ich meinen Kollegen Ralph Ricker, Daniel Meidlinger und Dr. Tim Schlüsener, ohne die ich selbst im Infor- mationsdschungel der Daimler AG verloren gewesen wäre und die mich kompetent in die unvertraute Domäne der Fahrzeugdiagnose einführten. Bei meinem Vorgesetzten Dr. Harald Nauerz möchte ich mich für das in mich gesetzte Vertrauen und den mehrfachen Aus- druck der Wertschätzung meiner Arbeit bedanken. Ein Dank geht auch an die Text Mining-Experten der Daimler AG: Dr. Jürgen Franke, Jan Werrmann, Mathias Bank und Christian Hänig. Dan- ke für 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ützung und Vertrau- en ich es mit Sicherheit nicht bis zur Abgabe und Verteidigung einer Diplomarbeit gebracht hätte. vii

5. Kurzfassung Die Informationsflut der heutigen Informationsgesellschaft erstreckt sich längst nicht mehr nur auf Medien des Alltagsgebrauches, sondern wird vor allem in Unternehmen, in denen technische Entwicklungen rasant voranschreiten, bemerkbar. Das ” lebenslange Lernen“ repräsentiert zuweilen eine Jagd nach zielführenden Informationen zur Lösung von Pro- blemen, die besonders in Domänen mit Kundenkontakt fehlerfrei und effizient durchge- führt werden muss. Zu dieser Domäne gehört 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ählige Informationen in verschiedenen Informationsquellen abgelegt. Die Herausforderung ist, bei einer konkreten Kundenbeanstandung die korrekten Informationen in den Informationsquellen zu finden, die zur Behebung der Fehlers am Fahrzeug beitragen. Diese Arbeit führt zunächst 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üpft werden können, um Wissen zu repräsentieren. Außerdem werden die Informationsquellen in der Fahrzeugdiagnose am Beispiel der durch die Daimler AG verwendeten Systeme erläutert. Darauf aufbauend wird ein Konzept erarbeitet, mit dem die Informationsquellen auf eine einheitliche Datenstruktur abgebildet und unternehmensweit auf Basis einer Serviceorien- tierten Architektur verfügbar gemacht werden können. Danach wird beschrieben, wie aus den vereinheitlichten Daten Informationen extrahiert werden und wie diese Informationen in eine verknüpfte Wissensbasis oder ein Information Retrieval System geschrieben werden können, 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 unterzogen, dessen Ergebnisse in dieser Arbeit enthalten sind. Abschließend wird ein Ausblick für die Nutzung des Konzeptes in ähnlichen Anwendungsfällen und Domänen und dessen Erweiterung bis hin zu einer Semantic Middleware beschrieben. Stichworte Fahrzeugdiagnose, Entscheidungsunterstützungssystem, Informationsextrak- tion, Text Mining, Natural Language Processing, Named Entity Recognition, Semantische Föderation, Semantische Suche, Query Expansion, Information Retrieval, Lucene, Seman- tic Media Wiki, UIMA, Document Provider, Document Tree Model ix

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 information 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. 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öderierter Ressourcen . . . . . . . . . . . . . . . . . . . 8 2.2.2. Verarbeitung semistrukturierter föderierter 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äsentation und Semantic Web . . . . . . . . . . . . . . . . . . 18 2.4.1. Vom Glossar über 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übermittlung . . . . . . . . . . 26 2.5.3. Bewährte Konzepte bei der Realisierung Entwurf von Webservices . 27 2.5.4. Webservice-Technologien für 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. 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 über 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äsentation 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. Überblick 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ählte Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2.1. Die konkrete XSL-Transformation für die Informationsquelle Case- Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2.2. Entwurf einer Ordnungsrelation für Traverser Events . . . . . . . . 87 5.2.3. Integration von Axis und UIMA über 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. 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üge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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ührliche Darstellung des Lasttestes . . . . . . . . . . . . . . . . . . . . 135 Abkürzungsverzeichnis 139 Literaturverzeichnis 148 Abbildungsverzeichnis 150 Tabellenverzeichnis 151 Listings 154 xv

10. 1. Einleitung Die Fülle an Informationen, die täglich entsteht und menschlich wahrgenommen und verstanden werden muss, steigt in der aktuellen Informationsgesellschaft weiter stetig an [82]. Insbesondere im Geschäftsumfeld müssen 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ürzen und somit Zeit und Kosten einsparen. Nach einer Erhebung der Living-e AG unter 300 deutschen Führungskräften sehen 37 Prozent der Befragten die Gefahr, im beruflichen Informationsdschungel die Orientierung zu verlieren. Beinahe 50 Prozent der Unternehmen schätzen den Anteil der Informationssuche an der Gesamtarbeitszeit auf 15 Prozent, 24 Prozent sogar auf mehr als ein Fünftel [52]. Dieses Problem ist auch für 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äte eine Rolle. Die- se Komponenten steuern oder überwachen Funktionen von Sicherheitsausstattungen, wie die automatische Reifenluftdruckmessung, oder Komfortausstattungen, wie Multimedia- geräte im Fahrzeug, die vor einiger Zeit noch nicht denkbar waren. Neben der höheren Komplexität stellt die höhere Flexibilität 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ändig aneignen konnte, sind damit vorbei. Er muss von Fahrzeu- gentwicklern und spezialisierten Diagnosebedatern aus dem Konzern kontinuierlich mit möglichst aktuellen Informationen versorgt werden. 1.1. Problemstellung Um dieses Informationsbedürfnis zu erfüllen, werden dem Werkstattmitarbeiter verschiedene Informationsquellen angeboten. Außerdem stehen ihm Feedbacksysteme zur Verfügung, über die er mit Spezialisten aus dem Konzern, sogenannten Produktbetreu- ern, Kontakt aufnehmen kann. Schließlich existieren Diagnosesysteme, die am Fahrzeug automatisierte Prüfungen durchführen und über den Vergleich des Fahrzeugzustandes mit 1

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ülle nicht ausreichend schnell gefunden. Dies kann unter Anderem folgende Ursachen haben: 1. Für ein- und denselben Anwendungsfall existieren mehrere unterschiedliche Sys- teme. Zur Bestellung von Bauteilen muss beispielsweise ein anderes System verwendet werden als zur Bestellung von technischen Dokumentationen, wie Bedienungs- anleitungen. 2. Eine Verlinkung zwischen den Systemen fehlt häufig. Es ist zum Beispiel nicht möglich, bei der Ansicht der Prüfanweisung eines Bauteils direkt auf dessen Bauplan zuzugreifen oder es, falls es defekt war, per Knopfdruck zu bestellen. Für die drei Anwendungsfälle werden drei unterschiedliche Systeme genutzt. In einigen Fällen 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 übertragen werden. 3. Es existiert keine übergeordnete, kundenorientierte Sicht auf den Service- auftrag. Die kleinste abzuarbeitende Einheit aus Sicht des Werkstattmitarbeiters ist das Fahrzeug mit allen über 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äufig in einer Auftragsmappe zusammengefasst, die während des Auftrages mit Blättern gefüllt wird und das Fahrzeug begleitet. Sie erlaubt jedem Werkstattmitarbeiter die Sicht auf die gesammelten Daten. In den bisherigen Systemen müssen diese Daten – beginnend mit der Fahrzeugidentifkationsnummer (FIN), aus der sich zum Beispiel Hersteller, Baureihe und Baumuster schließen lassen – für jeden neuen Auftrag oder beim Wechsel zwischen zwei Aufträgen erneut eigegeben werden. 4. In den Systemen existiert keine hinreichend präzise, tolerante Suche. Kennt der Nutzer die Identifikationsnummer eines Teiles oder Dokumentes, das für sein Informationsbedürfnis relevant ist, nicht, steht ihm häufig die Möglichkeit offen, dieses Dokument über redaktionell verwaltete baumstrukturierte Inhaltsverzeichnisse zu suchen. In einigen Systemen ist eine Volltext-Datenbanksuche implementiert, die aber nur exakte, wörtliche Treffer findet und entsprechend langsam ist. 5. Feedback der Werkstattmitarbeiter wird häufig unstrukturiert, aber immer nicht-öffentlich abgelegt. Das gewonnene Fallwissen anderen Werkstätten zur Ver- fügung 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ür die Veröffentlichung sehr hoch, im zweiten Fall ist die Veröffentlichung wegen der fehlenden Protokollierung quasi unmöglich. Aber auch in moderner gestalteten Ticketsystemen werden Anfragen stets nicht-öffentlich behandelt, was bedeutet, dass ähnliche Anfragen mehrfach recherchiert und beant- wortet werden müssen. Die Veröffentlichung ist jedoch teilweise aus Gründen der 2

12. 1.2. Projektkontext und Ansatz dieser Arbeit Produkthaftung und des Datenschutzes von Kundendaten gar nicht erwünscht. 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ür die Werkstatt weiterhin relevant sind. Eine Lösung 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ür alle AfterSales-Kundenbeziehungen zu vereinheitlichen – mit dem Ziel, eine einheitliche kundenorientierte Oberfläche zu erhalten, die den gesamten Auftragsprozess von der Annahme bis zur Rechnungslegung unterstützt und Auftragsda- ten für alle abhängigen Systeme zur Verfügung 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ützungssystems (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ösung des Auftrages finden und daraus bestenfalls Daten bezüglich Kosten und Zeitaufwand extrahieren und dem Werkstattmitarbeiter präsentieren. Diese Arbeit soll einen Beitrag zur Entwicklung des Decision Support Systems leisten: Sie soll eine föderierte Suche über den unterschiedlichen, heterogenen Informationsquellen realisieren. Diese Suche soll semantisch funktionieren, das heißt, die Suchanfrage soll interpretiert und eventuell umgeschrieben werden, um das Informationsbedürfnis des Nutzers adäquater zu repräsentieren und Suchanfragen zu erlauben, die über 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öglich ist, für bestimmte Stichwörter in einem Dokument direkt zu relevanten Dokumenten zu gelangen, die diese Stichwörter beschreiben. 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äftigt man sich zudem damit, wie neue Technologien des World Wide Web im Diagnoseprozess genutzt werden können. Dies zunächst, um die betriebswirtschaftliche Einsetzbarkeit von community-basierten Re- daktionsprozessen, wie sie für 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ösung von Punkt (5.) entspricht. Als Prototyp wird in diesem Projekt ein Werkstattwiki aufgesetzt und ausgewählten Werkstätten als kollaboratives Informationssystem zu Testzwecken für einen beschränkten Zeitraum präsentiert. Da ein DSS- bzw. SAR-Frontend im Konzern noch nicht existiert, ist das Werkstattwiki ein 3

13. 1. Einleitung mögliches Zielsystem für das in dieser Arbeit zu entwickelnde System zur semantischen, föderierten Suche über 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äß des aktuellen Standes der Forschung auf dem Gebiet des Information Retrieval (für den An- wendungsfall der Suche) und der Informationsextraktion durch Named Entity Recognition und Natural Language Processing (für den Anwendungsfall der semantischen Suche und automatischen semantischen Verlinkung) abzuschätzen. Kapitel 3 detailliert die in diesem Kapitel vorgestellten fahrzeugtechnischen Problemstellungen und leitet daraus die konkreten Anforderungen an das zu realisierende System. In Kapitel 4 wird ein Konzept zur Lösung 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äß qualitativen und quantitativen Testergebnissen. Kapitel 7 fasst die Ergebnisse dieser Arbeit zusammen und diskutiert deren Anwendung gegenüber ausgewählten verwandten Aufgabenstellungen. Dabei werden Grenzen bezüglich der Erweiter- und Übertragbarkeit aufgezeigt und mögliche Weiterentwicklungen zur Beseitigung dieser Grenzen vorgeschla- gen. Außerdem wird ein langfristiger Blick in die Zukunft gewagt. 4

14. 2. Technologien zur Extraktion und zum Retrieval von Wissen aus förderierten Dokumenten In diesem Kapitel soll auf die informationstechnischen Grundlagen eingegangen werden, die nötig sind, um ein kollaboratives System zu entwickeln, welches die föderierte semantische Suche über heterogenen Informationsquellen unterstützt. Ziel dieses Systems ist, die in der Einleitung beschriebenen Herausforderungen zu bewältigen. Die in diesem Kapitel gelegten Grundlagen helfen bei der späteren Anforderungsanalyse, die informationstechnische Machbarkeit abzuschätzen. Eine Übersicht 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önnen, führt Abschnitt 2.1 zunächst 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ächst darauf eingegangen, wie semistrukturierte Daten benannt und einheitlich repräsentiert werden können und wie aus ihnen dann mit Hilfe von Methoden des Natural Language Processings und des Text Minings Informationen extrahiert werden können. Abschnitt 2.3 beschäftigt sich mit der Disziplin des Information Retrie- val – der möglichst effizienten Ablage von Informationen zum späteren Wiederauffinden hinsichtlich einer möglicherweise vage formulierten Problemstellung. Abschnitt 2.4 be- fasst sich mit der Einbindung von Informationen in hochverknüpfte 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. 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ür 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ür den Entwurf des Prototypen Leitbild sein sollen. Abschnitt 2.6 stellt die in den Kernthemen bereits präsentierten 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 üblicherweise isolierte, uninterpretierte und eindeutige Fak- ten aus der realen Welt – man spricht in diesem Zusammenhang auch von Rohdaten. Assoziation und Verknüpfung, d.h. Zuordnung von Daten/Fakten zueinander sowie Inter- pretation dieser Daten hinsichtlich ihrer Bedeutung (Semantik) in einem Themengebiet (einer Domäne) macht aus Daten Informationen. Werden diese wahrgenommen, verarbeitet und formell mit Bedeutung versehen, entsteht daraus Wissen (vgl. [100]). Der Übergang 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ässt sich bewusst wahrnehmen und durch natürliche Sprache artikulieren, während implizites Wissen sich durch unbewusste Annahmen oder Handlungen in einem bestimmten Kontext äußert, und eher durch Erfahrung gewonnen wird. Die Informationsverarbeitung beschäftigt sich damit, von Menschen verständliche 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änglich gemacht werden. Zusätzlich dazu soll die Wissensverarbeitung auch Wissen in rechnergestützten Systemen repräsentieren und verarbeitbar machen. Hier kommen vorwiegend Methoden aus der Künstlichen In- 6

16. 2.2. Information Extraction telligenz zum Einsatz. Ein Anwendungsfall entsprechender Methoden ist das Semantic Web, dessen Technologien in Abschnitt 2.4 eingeführt werden. Wissen stellt häufig die Grundlage für das Entscheiden und Handeln im Kontext eines Problems dar. Ein Problem muss zunächst als solches erkannt und das Problem selbst auf (möglichst formelle) Weise beschrieben oder in Worte gefasst werden. Daraufhin kann man ein Problemlösungsverfahren wählen, um das Problem zu beseitigen. Es existieren analytische Problemlösungsverfahren, bei der alle notwendigen Informationen zu Beginn vorhanden sind und über Schlussfolgern schrittweise eine Lösung entwickelt wird. Dem ge- genüber stehen Methoden, bei denen mit begrenztem Wissen in kurzer Zeit möglichst gute Lösungen gefunden werden sollen. Diese Methoden werden als Heuristiken bezeichnet. Ein prominentes Beispiel für Heuristiken sind mathematische Suchalgorithmen. Das Problem, welches durch den Nutzer formuliert wird, ist durch die Suchanfrage gegeben. Hier stellt sich für den Nutzer die Herausforderung, sein Problem möglichst klar durch eine entsprechende Suchanfrage zu repräsentieren. Die Lösung des Problems, also das Su- chergebnis, ist genau dann zielführend, wenn ein Dokument gefunden wird, welches genau die Informationen enthält, die den Informationsbedarf des Nutzers deckt. Interpretiert der Nutzer die Information und versieht sie mit Bedeutung, repräsentiert sie für ihn Wissen, dass zur Lösung seines Problems hilfreich ist. Die Qualität eines Suchalgorithmus wird nach der Definition einer Heuristik daran gemessen, ob der Nutzer mit begrenztem Wis- sen (möglicherweise mehrdeutige Suchanfrage) in kurzer Zeit (Performance des Suchalgo- rithmus) eine gute Lösung (Fund des zielführenden Dokumentes) findet. Weiterführende Informationen zu Suchalgorithmen werden in Abschnitt 2.3 gegeben. Ein häufiger Anwendungsfall für Heuristiken ist im Allgemeinen die Fehlersuche in großen Systemen. Im Speziellen wird dies in dieser Arbeit anhand der Fahrzeugdiagnose erläu- tert. Vor allem hier liegt unvollständiges Wissen über den Zustand des fehlerhaften System vor. Unmittelbar äuß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önnen beliebige Beziehungen bestehen, die über Heuristiken erst erschlossen werden müssen. Auch hier ist nur begrenztes Wissen, in diesem Fall über den Zustand des Fahrzeuges, vorhanden. Das Interesse einer schnellen, exakten Lösung ist hier bei allen Beteiligten gegeben: für die Daimler AG ist jede Reparatur, wenn auf Garantie oder Kulanz durchgeführt, teuer, für den Kunden der Verzicht auf das Fahrzeug unbequem und für die Werkstatt eine aufwändige, möglicher- weise nicht zielführende Diagnose, bei welcher der Kunde auf sein Fahrzeug warten muss, schlecht für die Reputation. 2.2. Von Daten zu Informationen durch Information Extraction Wie können Daten aus heterogenen Quellen vereinheitlicht, gefiltert und verknüpft werden, sodass Informationen abgeleitet werden können? Diese Fragen stellte man sich zu- 7

17. 2. Technologien nächst mit dem Blick auf die immer größer werdende Informationsdichte im World Wide Web. Auch Firmen wie die Daimler AG hatten ein berechtigtes Interesse, verlässliche Aussagen, zum Beispiel über die Kundenakzeptanz ihrer Produkte, in den endlosen Weiten des Webs zu finden. Das Projekt AIM (Automotive Internet Mining) [77] beschäftigt sich daher mit dem Crawling (systematischen Downloaden) von Internetforen aus der Domäne des Automobilbaus und der Extraktion von Kundenmeinungen aus den Forenbeiträgen. Ein ähnliches Ziel verfolgt das Aletheia-Projekt [47] der TU Dresden, das Technologien zur föderierten Produktsuche im Internet entwickelt. Längst 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önnen, die Aufschluss über häufig aufgetretene Symptome oder defekte Teile geben. In den folgenden Unterabschnitten werden die nötigen Technologien eingeführt. Zunächst werden Dokumente (oder Ressourcen), welche die Daten enthalten, eindeutig benannt (2.2.1). Dann werden diese semistrukturierten, föderierten Ressourcen in eine einheitliche Repräsentation überführt (2.2.2). Über Methoden des Natural Language Processings (NLP) werden aus diesen semistrukturierten Ressourcen schließlich Informationen gewonnen (2.2.3). UIMA und das bei Daimler entwickeltem Framework InfexNG können zur Realisierung von NLP-Systemen verwendet werden (2.2.4). 2.2.1. Benennung föderierter Ressourcen Um Aussagen über ein Dokument aus einer Informationsquelle oder ein im Dokument be- schriebenes Konzept aus der realen Welt zu tätigen, ist es nötig, 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 über HTTP erreichbar ist. Ein URN (Uniform Resource Name) bezeichnet einen allgemeinen und global eindeutigen Identifikator für ein Konzept, welches nicht notwendigerweise über das Netzwerk abruf- bar sein muss. URNs haben die Form urn:Namespace :GUID , wobei der Namespace den Adressraum der URNs in Namensräume unterteilen. Einige dieser Namensräume werden durch die IANA (Internet Assigned Numbers Authority) vergeben1 . Da URNs unabhängig vom Ort ihrer Ressource sind, können sie über die gesamten Lebenszeit der Ressource, die sie identifizieren, unverändert bleiben. 1 Liste der derzeit standardisierten Namensräume s. [46] 8

18. 2.2. Information Extraction 2.2.2. Verarbeitung semistrukturierter föderierter Ressourcen in XML Als semistrukturierte Daten bezeichnet man in der Datenbanktechnologie Daten, welche 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önnen semistrukturierten Daten so in strukturierte Daten überführt werden: Das Ergebnis sind eine oder mehrere Folgen von Objekten, wobei dies entweder komplexe Objekte sind, die in weitere Objekte zerlegt werden können oder atomare Objekte, die Werte eines bekannten, elementaren Datentyps enthalten (vgl. [50]). Semistrukturierte Daten, zerlegt in komplexe und schließlich atomare Objekte, kön- nen demnach als Baumstruktur repräsentiert 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änkungen bezüglich 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ält, 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äsentation von föderierten Doku- menten, welches in Unterabschnitt 4.2.1 erklärt wird. Das XSD-Dokument gehört dem Schema http://www.w3.org/2001/XMLSchema an, das im Quellcodebeispiel an den Prä- 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 über das Präfix 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ätze, die sich hinsichtlich 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ür 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über hinaus auch das Manipulieren und Zurückschreiben der Baumstruktur in ein XML-Dokument. Bei SAX wird das XML-Dokument als Datenstrom betrachtet, der 9

19. 2. Technologien sequenziell eingelesen wird. Für wohldefinierte Ereignisse, wie das Auftreten eines Start- /Endtags wird ein Ereignis ausgelöst und der Anwendungsprogrammcode (z.B. mittels Observer-Pattern [70]) benachrichtigt. Üblicherweise greift Anwendungsprogrammcode allerdings nicht direkt auf die Parser- API zu: stattdessen werden Regeln definiert, wie Instanzen von Programmlogikklassen bzw. -datenstrukturen über eine Parser-API in XML-Dokumente geschrieben (Marshal- ling bzw. Serialisierung) oder aus ihnen gelesen werden können (Unmarshalling bzw. Deserialisierung). Beispiele für solche Data Binding Frameworks sind JAXB [18] (Ja- va Architexture for XML Binding) oder Castor [29]. Mit beiden Frameworks ist es zum Beispiel möglich, direkt aus XSD-Dateien Java-Klassen zu generieren (Binding), welche zur Laufzeit die deserialisierten XML-Daten repräsentieren, oder aber Serialisierungsre- geln für 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öglich. Eine XSL-Transformation beschreibt das ” Gerüst“ des Zieldokuments, enthält 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, über den bestimmte Knoten im Quelldokument für die weitere Verarbeitung selektiert werden können. XPath erlaubt mit Hilfe von Funktionen und if-then-else-Konstrukten auch die einfache Analyse und Transformation von Knoteninhalten. Darüber hinaus lassen sich auch benutzerdefinierte XPath-Funktionen transformieren. XSL-Transformationen sind ein mächtiges Werkzeug zur Verarbeitung föderierter Daten: Sind semistrukturierte Daten zunächst, abhängig von ihrer Informationsquelle, auf unterschiedliche Weise in XML repräsentiert, können Daten der Informationsquelle in eine einheitliche Repräsentation überführt werden, indem sie der für ihre Informationsquelle speziell angelegten XSL-Transformation unterworfen werden. Im Rahmen dieser Arbeit werden XSL-Transformationen zur Überführung von föderierten 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ützt, welcher u.A. Selektionsbedingungen mit reguläre Ausdrücke erlaubt. Saxon steht in einer kostenlosen Home Edition zur Verfügung, diese kann Quell- und Zieldoku- mente allerdings nicht gegen ein XML-Schema validieren. 10

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äufig nicht aus, um alle nötigen 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ässt sich in Absätze, Sätze, Wörter und sogenannte Morpheme als kleinste bedeutungstragende Einheiten zerlegen. Methoden für die Zerlegung und Identifizierung dieser Einheiten zu entwickeln ist Aufgabe der Disziplin des Natural Language Processing, welche sich auf linguistische oder statistische Methoden stützt. Dabei kommen entweder regelbasierte oder selbstlernende Algorithmen (Algorithmen der Künstlichen Intelligenz) zum Einsatz. Das Fachgebiet der Informationsextraktion aus Klartext wird als Text Mining ( ” Textschürfen“) bezeichnet. Dieser Prozess analysiert den zugrundeliegenden Text in mehreren Schritten [97], welche im Folgenden erläutert werden. Text Cleaning Hier werden Störungen aus Textdaten entfernt sowie Strukturerkennungen und Format- vereinheitlichungen durchgeführt, um die Qualität der Daten zu steigern. Sprachidentifizierung Die Sprache kann durch häufig auftretende Muster im Text erkannt werden. Diese Muster können entweder besonders häufig vorkommende Wör- ter (Stoppwörter), zum Beispiel Artikel, Präpositionen 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öglich. Für eine bestimmte Sprache sind auch hier besonders häu- 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ängig sind, verbessert die Sprachidentifizierung die Qualität dieser erheblich. Tokenisierung (auch lexikalische Analyse) Aufgabe dieses Vorverarbeitungsschrittes ist es, den Text in kleinste, bedeutungstragende Einheiten zu zerlegen, wie zum Beispiel Wörter und Satzzeichen. Sogenannte Tokenizer arbeiten dabei häufig mit regulären Ausdrücken – dabei deckt ein regulärer Ausdruck genau ein Token ab. Durch eine Liste von regulären Ausdrücken können verschiedene Tokentypen identifiziert werden, z.B. Wörter oder Satzzeichen, aber auch Seriennummern, wie Teilenum- mern oder Dokumentennummern. Da sich die Gültigkeit verschiedener regulärer Ausdrücke überschneiden kann, müssen diese Liste priorisiert werden. Stemming Dieser Schritt reduziert Tokens, im speziellen Wörter, auf ihre Grundform. Die Schwierigkeit dieses Verarbeitungsschrittes ist von der Sprache abhängig: so existieren zum Beispiel im Englischen nur wenige Flexive (z.B. ” -s“, ” -ed“, ” -ing“), 11

21. 2. Technologien während es im Deutschen weitaus mehr sind. Zusätzlich kommt hier das Problem der Allomorphie (Um- und Ablautung) hinzu. Außerdem können 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örter entweder zu weit reduziert werden, sodass Informationen verloren gehen, oder nicht weit genug reduziert werden, sodass sie z.B. über ein Wörterbuch korrekt erkannt werden können. Rechtschreibkorrektur Rechtschreib- oder Tippfehler treten vor allem im Werkstattsze- nario dieser Arbeit häufig auf. Sie führen zu Wörtern, 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ür ein fehlerhaftes Wort wird automatisch das korrekte Wort ausgewählt. Dazu werden zunächst Worttoken darauf überprüft, ob sie im Lexikon der Text- sprache vorkommen. Ist dies nicht der Fall, werden Distanzmetriken verwendet, um aus dem Lexikon Wörter zu finden, die dem fehlerhaften Wort möglichst ähnlich sind. Hier kann die Editierdistanz (auch Levensthein-Distanz) [81] zu Rate gezogen werden, die beschreibt, wie viele Buchstaben entfernt, hinzugefügt oder vertauscht werden müssen, um ein Wort in das andere zu überführen. Eine andere oder zusätzli- che Möglichkeit ist das Messen der phonetischen Distanz [101], d.h. des Gleichklangs der Wörter. Auf diese Weise werden die Wörter mit minimaler Distanz als potentielle Korrek- turen ermittelt. Diese können noch weiter gewichtet werden: hierzu eignen sich Fre- quenzlisten (Wie häufig tritt das Wort üblicherweise in einem Text auf?) oder Kook- kurenzinformationen (Welche Worte treten häufig zusammen auf?). Insbesondere die letzten beiden Informationen lassen sich aus genügend großen Textkorpora automatisch 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 innerhalb des Textes. Besondere Herausforderung hier ist, dass nicht jedes vom To- kenizer erkannte Satzzeichen auch eine Satzgrenze beschreiben muss: Abkürzungen, direkte Rede oder Nachlässigkeit des Verfassers bei der Interpunktion stellen hier eine Herausforderung dar. Eine naheliegende Lösung ist, Abkürzungen über Aus- nahmelisten zu eliminieren. Eine ausgereiftere und zuverlässigere Lösung bietet zum Beispiel das SATZ-System [89, 90]: hier wird ein Tokenfenster der Länge sieben um das Satzzeichen gelegt und für jedes Token ein Vektor berechnet, der die Wahr- scheinlichkeiten der möglichen PoS-Tags (siehe unten) berechnet. Diese Merkmals- vektoren werden einer Support Vector Machine [61] übergeben, 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. 2.2. Information Extraction Part-of-Speech Tagging Schließlich wird für jedes Wort ein PoS-Tag, das die gramma- tikalische Wortart beschreibt, bestimmt. Hier können regelbasierte oder statistische Verfahren angewendet werden. Regelbasierte Verfahren stützen sich auf formalisier- tes Wissen aus der Linguistik. Ein Beispiel für 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änden generiert. Zwischen zwei Zuständen existieren Übergänge, die ebenfalls mit einer bestimmten Wahr- scheinlichkeit durchlaufen werden, wobei die Wahrscheinlichkeit für einen Folge- zustand nur vom aktuellen Zustand abhängt (Markov-Eigenschaft). Als Beobach- tungen werden in diesem Fall die Menge der Wörter des Lexikons verstanden, die Zustände entsprechen den möglichen PoS-Tags. Die Wahrscheinlichkeit, dass ein Zustand eine Beobachtung auslöst entspricht dann der Wahrscheinlichkeit, dass ein Wort einem bestimmten PoS-Tag angehört und die Zustandsübergangswahrschein- lichkeit entspricht der Wahrscheinlichkeit, dass ein bestimmtes PoS-Tag auf ein anderes folgt. Die Wahrscheinlichkeiten können über einen annotierten Referenzkor- pus stochastisch ausgezählt werden. Mehr Informationen zu PoS-Tagging nach dem Hidden-Markov-Model können in [43] nachgelesen werden. Information Extraction Aus den Daten können nun Informationen extrahiert werden. Ziel ist die strukturierte Speicherung von Informationen, wie die Erwähnung von bestimmten Entitäten (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äsen- tation dieser Konzepte kann zum Beispiel in einer Wissensbasis (s. Abschnitt 2.4.1) abgelegt sein, sodass über eine einfache Hashing-Tabelle ein Wort, und gegebenenfalls Ergebnisse der vorherigen Analyseschritte, einem Konzept effizient zugeordnet werden kann. Hier können 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 Über- bzw. Unterbegriffe in der Nähe 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önnen ebenfalls mit Hilfe einer Wissensbasis extrahiert werden: Der Relationsname kann ebenfalls in einer Wissens- basis als Entität definiert sein. Nimmt man an, dass eine Relation sowie die beteiligten Konzepte in einem Dokument gemeinsam erwähnt werden, kann man für jede Relation, die im Schritt der Named Entity Recognition erkannt wurde, nach an der Relation beteiligten Entitäten in deren unmittelbarer Umgebung suchen. Die gefun- 13

23. 2. Technologien denen Relationen können der Wissensbasis hinzugefügt 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öglichkeit der späteren Erweiterung auf Named Entity Recognition beschränken. 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öß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ützt 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ür große Datenmengen gewährleistet. 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 sogenannten CAS (Common Analysis Structure) verwaltet, welche von einem Analyseschritt zur nächsten übergeben wird. Sie enthält 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öglichen. Die Aufgabe einer einzelnen Analysis Engine ist es, aus einem CAS-Objekt unter der Verwendung aller dort abgelegten Daten neue Daten extrahieren. Dabei können alle im vorherigen Schritt gewonnenen Daten, insbesondere der Klartext, zu Rate gezogen werden. Sie – insbesondere der Klartext – dürfen jedoch nicht modifiziert werden. Eine Analysis Engine fügt der CAS lediglich neue Features hinzu und lässt die CAS sonst unangetas- tet. Spezielle Features sind Annotations. Sie markieren einen bestimmten Bereich im Klartext über einen Start- und Endindex und beschreiben diesen Bereich ggf. mit Hilfe von weiteren assoziierten Objekten. Über Annotationen ist die Darstellung der Analyse- ergebnisse aller im Abschnitt 2.2.3 besprochenen Verarbeitungsschritte möglich: Tokens können über Tokens repräsentiert werden, PoS-Tags über 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. 2.3. Information Retrival lesen werden. Aus den XML-Dateien des Typsystems kann mithilfe eines Eclipse-Plugins direkt der Java-Quellcode für 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ügbaren 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ängig oder in der Domäne des Automobilbaus einsetzbar. Allerdings lassen sich diese Frameworks für ihren Anwendungsfall vergleichsweise einfach in UIMA integrieren [33, 44, 45]. 2.3. Informationen wiederfinden mittels Information Retrieval Das Fachgebiet Information Retrieval beschäftigt sich mit dem gezielten, effizienten Auffinden von Dokumenten, die für ein Informationsbedürfnis eines Nutzers relevant sind. Zunächst muss der Anwendungsfall des Retrievals gegen den des Browsing abgegrenzt werden: Im Falle von Browsing ist die konkrete Problemstellung häufig nicht klar formulierbar 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öglicht, sondern es ist stets mit einer gewisse Vagheit der Anfrage und Unsicherheit der rück- gegebenen Information zu rechnen. Dieses Phänomen ist auch dadurch bedingt, dass ein Nutzer sein Informationsbedürfnis einerseits häufig nicht konkret maschinenlesbar formulieren kann und andererseits die in Dokumenten abgelegten Informationen häufig nicht exakt maschinell interpretiert werden können. Der Nutzer muss die Informationen daher weiter bewerten und möglicherweise mit anderen Informationen verknüpfen um sicheres Wissen zu erlangen, das für eine Entscheidung zielführend ist. Üblicherweise wirken zwei Akteure auf ein Information Retrieval System ein: Autoren und Anwender. Autoren schreiben Dokumente, welche zunächst in eine passende Dokumenten- repräsentation überführt (indiziert) werden müssen. Anwender haben hinsichtlich eines Problemes einen Informationsbedarf und formulieren darauf basierend eine Anfrage. Die Repräsentation der Dokumente und der Suchanfrage hängen eng zusammen und bilden 15

25. 2. Technologien das Repräsentationsmodell (auch IR-Modell. Ausgehend von diesem Modell kann ermittelt werden, welches Dokument für eine Anfrage relevant ist (Filterung) wonach die gefundenen Dokumente schließlich nach Relevanz sortiert werden (Ranking). Die Ergeb- nisliste kann den Nutzer dazu veranlassen, Änderungen an der Suchanfrage vorzunehmen oder, falls möglich, den Suchindex zu modifizieren. Wurde ein Modell gewählt, 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ür 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ügbares, java-basiertes Information Retrieval Framework ist Lucene [2] von der Apache Foundation. Für den Unternehmenseinsatz existieren weitere, zum Teil kommerzielle 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üssen. Als Indexterme können die im Klartextes des Dokumentes vorkommenden Wörter verstanden werden. Zur Extraktion dieser werden Algorithmen des Natural Language Processings verwendet, die bereits in Unterabschnitt 2.2.3 vorgestellt wurden. Durch die zusätzlichen NLP-Verarbeitungsschritte werden Rechtschreibfehler im Klartext korrigiert (Rechtschreibkorrektur) sowie, unter Nutzung einer Wissensbasis (siehe Abschnitt 2.4) synonymunabhängig auf ihre Konzep- te abgebildet (Named Entity Recognition). Indem sowohl Suchanfrage und Dokumente derselben NLP-Verarbeitung unterzogen werden, ist die Verarbeitung unter demselben Repräsentationsmodell gewährleistet. Das Vorverarbeiten der Suchanfrage wird dabei auch als Query Expansion bezeichnet. Die Gewichtung der Indexterme für 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über, mit welcher Frequenz ein Term ti im Dokument dj auftritt (ni,j drückt 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. 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 über den gesamten Korpus (hohe idfi) erreicht wird. Die Gewichtung eliminiert demnach besonders häufig vorkommende Wörter. 2.3.2. Bewertung von Retrieval-Systemen Um die Güte eines Information Retrieval Systems beurteilen zu können existieren die objektiven Maße Recall, Precision und Fallout, welche Werte zwischen Null und Eins annehmen können und voneinander abhängen. 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ürfnissen (übersetzbar in Suchanfragen) gegeben und für dieses Informationsbedürfnis die jeweilige Relevanz jedes Dokuments (relevant oder irrelevant). Die Suchergebnisse des Information Retrieval Systems hinsichtlich der Suchanfrage werden dann mit den erwarteten Ergebnissen verglichen und die Bewertungsgrößen Pre- cision, Recall und Fallout wie oben berechnet. Es ist zu beachten, dass ” relevant“ und ” irrelevant“ sich auf das Informationsbedürfnis, nicht auf die Suchanfrage beziehen – es reicht also zum Beispiel nicht aus, dass ein Dokument nur die durch die Suchanfrage beschriebenen Schlüsselwörter enthält. 17

27. 2. Technologien Semantische Reichhaltigkeit, Formalisierungsgrad, Aussagekraft, Komplexität Topic Map Ontologie Taxonomie Thesaurus Glossar Abbildung 2.3.: Vom Glossar über Taxonomien zu Ontologien 2.4. Von Informationen zu Wissen – Wissensrepräsentation und Semantic Web Aus Daten extrahierte Informationen repräsentieren, 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ützungssystem) auf Problemstellungen möglichst punkt- genaues, problemlösendes Wissen zu liefern. Dieser Abschnitt stellt Methoden zur Repräsentation von Wissen vor und gibt Beispiele für technische Realisierungen von Wissensbasen. Zunächst wird eine Einführung in verschiedene Modelle der Wissensrepräsentation gegeben (2.4.1). Daraufhin wird RDF als konkrete Technologie zur Realisierung einer Wissensbasis sowie die Sprache SPARQL zur Abfrage von Wissensbasen eingeführt (2.4.2). Schließlich wird das Semantic Media Wiki vorgestellt, eine System, in dem Dokumente abgelegt und mit einer Wissensbasis ” über- lagert“ werden können und das neben der Ausgabe von RDF auch viele kollaborative Funktionen, wie Diskussionen oder gemeinsames Arbeiten an Dokumenten, unterstützt (2.4.2). 2.4.1. Vom Glossar über Taxonomien zu Ontologien Um Wissen maschinenlesbar zu repräsentieren, müssen isolierte Konzepte und Rela- tionen zwischen diesen Konzepten formalisiert werden. Dies kann in unterschiedlich aus- geprägter Komplexität und Formalisierungsgrad geschehen. Abbildung 2.3 illustriert die entsprechende Terminologie, die im folgenden erläutert wird: Glossare stellen den niedrigsten Formalsierungsgrad dar und sind eine eher informell gehaltene Liste von Konzepten mit dazugehörigen Erklärungen. Taxonomien definieren eine Anzahl von Konzepten und zu diesen Begriffen eine Hypo- 18

28. 2.4. Wissensrepräsentation 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ätzlich die Einschränkung, dass ein Kon- zept nur genau einem übergeordneten Konzept zugeordnet sein darf, erhält man sogar eine Baumstruktur. Thesauri erweitern Taxonomien um eine Synonymrelation und weitere, beliebige (Ähn- lichkeits-) Relationen. Im Rahmen des Wordnet-Projektes [84] wurde zum Beispiel ein Thesaurus der englischen Sprache entwickelt. Topic Maps sind eine gemäß ISO-Standard 13250-2 [71] in XML definierte Repräsen- tationsform von Wissen. Eine Topic Map definiert abstrakte Begriffe (sg. Topics), mögliche Relationen zwischen ihnen und Gültigkeitsbereiche für sie (sg. Scopes) sowie 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äsentation von Wissen in pro- duktnahen Internetforenbeiträgen und zum Information Retrieval einsetzen (siehe [99]). Ontologien sind die mächtigsten (d.h. komplexesten und formellsten) Wissensrepräsenta- tionsformen. Sie gehen in folgenden Aspekten über eine Taxonomie hinaus: [72, 87] 1. Zwischen Konzepten lassen sich beliebige Relationen definieren, die ihrerseits Konzepte sind. 2. Für Konzepte lassen sich Attribute definieren – Variablen für Zeichenketten, die hinsichtlich eines definierten atomaren Datentyps interpretiert werden kön- nen. 3. Es lassen sich Axiome definieren. Dies sind prädikatenlogischen Regeln, die es erlauben, mittels Deduktion von vorhandenen Relationen oder Attributen auf neue Relationen zu schließen bzw. die Integrität von Relationen und Attributen zu überprüfen. 4. Man kann formell zwischen Ontologieschema und Ontologieinstanz unterscheiden. In einer Ontologieinstanz sind konkrete Instanzen für Konzepte mit konkreten Belegungen für Relationen und Attribute vorhanden. Das Prinzip der Instanziierung lässt sich jedoch auch über eine Instanziierungsrelation zwischen zwei Konzepten realisieren, sodass diese getypten Ontologien nicht aus- drucksstärker 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, über den mittels der Sprache F-Logic [76], einer Prolog-ähnlichen Sprache, Anfragen an die Ontologie gestellt werden können. Im Rahmen der Arbeit von [93] wurde und wird zur Zeit von der Firma Gigatronic der Versuch unternommen, eine Ontologie für die Fahrzeugdiagnose der Daimler 19

29. 2. Technologien AG aufzustellen. Wissensbasen ermöglichen eine übergreifende, abstrahierende Sicht auf heterogene In- formationsquellen. In strukturierten Informationsquellen (z.B. relationalen Datenbanken) können Beziehungen zwischen den Originaldaten und deren Attribute direkt isomorph auf Konzepte und deren Relationen abgebildet werden. Auf semistrukturierten Daten, speziell Textdokumenten, können 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ähnte 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äftigen 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 über Ressourcen, die sich durch einen URI repräsentieren lassen, abzulegen. Durch RDF sollen Heterogenität, Offenheit und Verknüpfung, d.h. Eigenschaften, die dem World Wide Web zum Erfolg verholfen haben, auf allgemeine Daten übertragen werden. RDF basiert auf einem einfachen, aber wohldefinierten Datenmodell (RDF-Modell). Daten in RDF sind wahre Aussagen über Ressourcen, die als Tripel formuliert werden. Ein Tripel besteht aus einem Subjekt, einem Prädikat und einem Objekt und stellt somit eine binäre, gerichtete Relation zwischen Subjekt und Objekt her. Die Menge der Tripel bildet einen gerichteten Graph. Das Subjekt ist eine URI und bezeichnet die Ressource, über welche die Aussage gemacht wird. Das Objekt kann entweder eine URI oder ein Literal (eine möglicherweise getypte Zeichenkette) sein. Das Prädikat wird ebenfalls in Form einer URI angegeben um die Beziehung eindeutig zu benennen. Damit ist es auch möglich, das Prädikat in weiteren Aussagen als Subjekt oder Objekt zu verwenden. Die Bedeutung der URIs ist von der Domäne abhängig. Es existieren verschiedene Be- mühungen, 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, über denen mithilfe eines Inferenzsystems lo- gische Schlüsse gezogen werden können. RDF eignet sich also zur Ontologie-Spezifikation gemäß den in Unterabschnitt 2.4.1 eingeführten Begriffen: Objekte entsprechen Konzep- ten, Prädikate entsprechen Relationen und Literale Attributen. Neben RDF existiert die weit komplexere Sprache OWL (Web Ontology Language) [98], mit der sich darüber hinaus Axiome modellieren lassen, die allerdings in dieser Arbeit nicht vorgestellt werden soll. Ein RDF-Modell kann auf verschiedene Art und Weise repräsentiert werden. Die men- 20

30. 2.4. Wissensrepräsentation und Semantic Web schenlesbare XML-Repräsentation ist RDF/XML [55]. Eine kürzere Variante ist N3, die von Tim Berners-Lee entworfene Notation 3 [57]. Tatsächlich werden RDF-Modelle jedoch in weitaus effizienteren Datenstrukturen (sogenannten Triple Stores) abgelegt. Eine Übersicht zu Triple Stores, die auch auf Skalierbarkeit und Performance eingeht, wurde durch das W3C erarbeitet (siehe [42]). Beispiele für 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önnen. 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önnen, so z.B. ARQ, eine Abfrage-Engine für das oben bereits vorgestellte Framework Jena. Listings 2.1 und 2.2 zeigen eine Mini-Ontologie aus der Domäne der Fahrzeugdiagnose in RDF/XML- bzw. N3-Schreibweise. Der Graph dieser Mini-Ontologie ist in Abbildung 2.4 dargestellt. In ihr wird ausgedrückt, 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ückgibt, für 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. 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öglicht SPARQL nur punktgenaue Fakten-Anfragen über den Triple Stores (ähnlich wie SQL über relationalen Datenbanken) und unterscheidet sich daher von Suchalgorithmen, die in Abschnitt 2.3 vorgestellt wurden. Es existieren Lösungen, 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 gemacht. Das dazugehörige Paper [85] beschreibt verschiedene Strategien, wie RDF-Tripel oder -Konzepte auf Lucene-Dokumente abgebildet werden können (Ressource-basiert – ein Dokument pro Konzept – oder Tripel-basiert – ein Dokument pro Tripel). Für die indizierten Tripeln stellt der SAIL virtuelle Prädikate wie matches zur Verfügung, mit denen IR-Suchanfragen direkt in SPARQL formulierbar sind. 2.4.3. Semantic Media Wiki als kollaborative semantische Dokumentenplatform Um Dokumente, oder darüber hinaus, enthaltenes Wissen dem Nutzer zu präsentie- ren, muss ein passendes Frontend ausgewählt werden. Ein Wiki ist eine kollaborative Hypertext-Plattform, auf der jeder Benutzer die gespeicherten Dokumente nicht nur lesen, sondern auch im Browser mittels einer einfach zu erlernenden Auszeichnungssprache bearbeiten, sowie über die Dokumente diskutieren kann. Ein Wiki als System zur Do- kumentenablage bietet einem Unternehmen so den Vorteil, dass Änderungen am Doku- mentenbestandes schnell und in Echtzeit durch alle Beteiligten online verfügbar gemacht werden können (Cloud Computing) und das zusätzlich ein öffentlicher Diskussionska- nal angeboten wird, der protokolliert wird und später als zusätzliche Wissensquelle dienen kann. Es existieren verschiedene Wiki-Systeme, das bekannteste ist die Software Media Wiki [22], welche von der Online-Enzyklopädie 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 Überführung von föderierten Dokumenten in ein Wiki sollten diese Grundsätze beachtet werden. 22

32. 2.4. Wissensrepräsentation 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öglicht. Beispielsweise kann in einem Dokument, welches unter 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ändiges Konzept identifiziert, für den ein eigenes Dokument (Lemma) angelegt werden kann. In einem Semantic Media Wiki ist nun zusätzlich die Typisierung des Links möglich: Schreibt man [[Fehlercode gesetzt::DCT Y]], etabliert man damit die Relation ” Symptom X“ hat ” Fehlercode gesetzt“ ” DCT Y“, ein Subjekt-Prädikat-Objekt-Faktum im Sinne einer Ontologie direkt auf dem Dokumentenkorpus. Auch hier können Prädikate als Subjekte oder Objekte in komplexeren Aussagen wieder- verwendet werden. Hierzu lassen sich Lemmata im speziellen Property-Namensraum definieren. 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ädikat als Zahl-Literal im Sinne einer Ontologie. Semantic Media Wiki interpretiert den Typ des Prädikates bei der Darstellung des konkreten 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önnen. Über Me- thoden des Natural Language Processing lassen sich diese semantischen Auszeichnungen automatisch generieren. Der Wiki-Text selbst wird durch eine Wissensbasis ” überlagert“, sodass das Wissen später in eine Ontologie integriert und über Abfragesprachen gezielt abgefragt werden kann. Im obigen Beispiel wäre eine Abfrage der Liste aller Symptome für einen bestimmten Fehlercode denkbar. Diese Abfrage könnte 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-ähnliche Abfragen erlauben. Außerdem ist der Export des aufgespannten Relationengraphes als RDF möglich. Die hinterlegten Fakten sind in einer einfachen relationalen Datenbank, in einer Tabel- le mit Subjekt-Prädikat-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öglichen würde (siehe Unterabschnitt 2.4.2), ist zum Zeitpunkt dieser Arbeit jedoch noch nicht vorhanden. Für die Software Media Wiki existiert weiterhin eine Erweiterung, welche das Suchfra- mework Lucene als Information Retrieval Lösung 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ässt. Innerhalb dieser 23

33. 2. Technologien Erweiterung wird die Klasse SearchEngine durch die Klasse LuceneSearch überschrie- ben: diese stellt die Suchanfrage des Nutzers über 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ür jede Suchanfrage wird über das Lucene-Framework ein Suchindex des Wikis abgefragt und das Ergebnis zurückgegeben. Der Search Daemon bietet einen Programmaufruf zur Erstellung bzw. inkrementellen Aktualisierung des Suchindexes an. Dazu lädt er sich einen Datenbankabzug des Wikis herunter oder fragt die Änderungen direkt vom Wiki ab, wenn dort die OAI Repository Erweiterung [68] installiert ist. Während der Indexerstellung lässt 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, über die Programme, sogenannte Bots, Daten aus dem Wiki lesen und Daten des Wikis än- dern können. 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äsentiert. 2.5. Serviceorientierte Architekturen (SOA) als Architekturparadigma Serviceorientierte Architekturen bezeichnen ein Architekturparadigma für verteilte Systeme, welches darauf abzielt, grobgranulare IT-Geschäftsprozesse einheitlich zu implementieren und konzernweit verfügbar zu machen. Der Einsatz von SOA im Kontext der semantischen Föderation wird durch zwei Tatsachen motiviert: zum Einen ist der Zugriff auf Datenbestände im Unternehmensumfeld über ein verteiltes System ohnehin sinnvoll, da sich so Sicherheits- und Konsistenzregeln, sowie eine zentrale Datenhaltung durchset- zen lässt. Außerdem wird der gleichzeitige Zugriff auf die Daten durch mehrere Nutzer ermöglicht. Ein SOA-Dienst bietet darüber hinaus die Modellierung der ausgetauschten Daten als komplexe Geschäftsobjekte. Serviceorientierte Architekturen können desweiteren eingesetzt werden, um aufwändige, parallelisierbare Verarbeitungsschritte des Natural Language Processings auf verschiedenen Rechnern als Dienst anzubieten und so die Last optimal zu verteilen. Das UIMA- Framework bietet die Möglichkeit an, einzelne Verarbeitungsschritte als Dienst auszula- gern. Dies soll jedoch hier noch nicht weiter verfolgt werden. Ein Dienst im Sinne der SOA repräsentiert eine gekapselte fachliche Funktionalität in einem Netzwerk. Er wird plattformunabhängig angeboten, implementiert eine wohldefinierte öffentliche Schnittstelle und ist in einem Verzeichnis registriert. Der Dienst wird bei der Ausführung (z.B. durch einen noch grobgranulareren Dienst) ggf. über das Verzeichnis 24

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ät des Gesamt- systems zu senken. Die Generizität des Architekturmusters SOA zeichnet sich dadurch aus, dass sie unter- schiedlichste Transportprotokolle für 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äufig 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ötig. 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öffentlicht und ist derzeit in der Version 2.0 verfügbar [64]. In einer WSDL-Definition sind abstrakten Definitonen und konkreten Definitionen einer 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) definiert, welche eine eine Menge von Operationen (Operations) anbieten, die vom Dienstnut- zer aufgerufen werden können. Für jede Operation werden zulässige Input-, Output- und Fault-Messages festgelegt. Mit diesen abstrakten Definitionen ist WSDL vergleichbar zu einer Schnittstellenbeschrei- bungssprache wie der Interface Description Language [73]. Darüber hinaus werden durch konkrete Definitionen konkrete Transportprotokolle vereinbart. Diese Definitionen bein- halten Bindings, in denen für alle Operations (und damit alle Messages) eines abstrakten Port Types) je ein Übertragungsprotokoll mit seinen eventuellen Parametern spezifiziert wird. Schließlich werden in Service-Definitionen alternative Ports (bzw. seit WSDL 2.0 25

35. 2. Technologien Endpoints) angeboten, die jeweils auf verschiedene Bindings, und damit auf alternative Übertragungsprotokolle, 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ür 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ärt. Bei der Definition der Types wird typischerweise mittels xsd:include auf eine externe XSD- Grammatik verwiesen. Zur Standardisierung von bestimmten, ständig wiederkehrenden Web Service Technolo- gien, wie z.B. (zuverlässige) Nachrichtenübertragung, Austausch von Metadaten, Sicher- heit, Datenschutz, Spezifikation von Ressourcen oder Geschäftsprozessen, Durchführung 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ährleis- tung der Interoperabilität von Web Services definiert. [41] 2.5.2. SOAP als Protokoll zur Nachrichtenübermittlung SOAP, ursprünglich Simple Object Access Protocol, hat seit der Version 1.2 den Status einer 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öglich ist oder eingeschränkt werden soll. Es eignet sich damit besonders als Nachrichtenprotokoll für Serviceorientierte Architekturen. Minimale SOAP-Nachrichten bestehen aus einem <Envelope>-Element 2 , welches zumindest ein <Body>-Element enthält und einen <Header> enthalten kann. Innerhalb von <Bo- dy> und <Header> können beliebige XML-Informationen stehen. Im Kontext von Web Services tauchen in <Body> üblicherweise Messages auf, die in einer WSDL-Definition definiert wurden und über den targetNamespace der WSDL-Definition referenziert werden können. 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ückgesendet 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. 2.5. Service Oriented Architectures (SOA) 2.5.3. Bewährte 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ögliche Variante ist, für jedes in der WSDL-Definition angegebene Binding eine Schnittstellenklasse zu definieren, die dann vom Programmierer implementiert und zur Laufzeit für jede konkret durchgeführ- te Webservice-Anfrage instantiiert wird. In der Schnittstellenklasse wird jede Operation durch genau eine Methode der Klasse repräsentiert. Input- und Output-Messages der in WSDL definierten Operation entsprechen dann Übergabe- und Rückgabeparameter der Methode, Fault-Messages werden durch Exceptions repräsentiert. Die in der WSDL-Definition deklarierten Typen und Messages werden zur Laufzeit durch Java-Objekte repräsentiert, der Code für die entsprechenden Klassen kann z.B. über ein XML Data Binding Framework wie Castor dynamisch generiert werden (s. Unterab- schnitt 2.2.2). Jede auf diese Art verwendete Methode empfängt als Übergabewert ihr ent- sprechendes Input-Message-Objekt und gibt schließlich auch eine Output-Message-Objekt zurück. Beachtet man einige Konventionen, kann man auf das Kapseln ( ” wrapping“ ) des Message-Inhaltes in einem der Methode übergebenen Message-Objekt allerdings verzich- ten und stattdessen die in der Message enthaltenen Parameter direkt übergeben. Diese Konventionen – von Microsoft Webservices verwendet, allerdings nicht offiziell dokumen- tiert – sind: [63] • Die Input Message enthält 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ür Java Um Webservices auf Java Webserver realisieren zu können, ist zunächst ein Webserver mit Servlet-Container vonnöten: es können z.B. Glassfish [14] mit Grizzly oder Tomcat [3] mit Catalina zum Einsatz kommen. Mit dem Anwendungsserverpaket werden häufig Plug-Ins für übliche IDEs, wie Eclipse [10], angeboten. Unterstützung von WSDL, SOAP und anderen Webservice-Technologien wird durch verschiedene Webservice Frameworks für Java bereitgestellt. Die Glassfish API fasst einige 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ügung. Das Framework erlaubt (ant-basierte) Codegenerierung von Typ- 27

37. 2. Technologien als auch Interface-/Rumpfklassen aus WSDL-Dateien und kann gemeinsam mit dem XML-Data-Binding-Framework Castor eingesetzt werden. Für die Serverkomponente kontrolliert ein Servlet den Lebenszyklus des entsprechenden Java-Programms, welches die Webservice-Schnittstelle implementiert. Für die Clientkomponente werden über JAX- RPC gemäß 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ühere For- schungsarbeiten in den für diese Arbeit relevanten Disziplinen der Informationstechnologie vorgestellt. Letztere sollen hier noch einmal zusammengefasst und gegen diese Arbeit abgegrenzt werden. Ausgangspunkt für diese Arbeit, und bereits mit diversen Veröffentlichungen in der wissenschaftlichen 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ätssicherung durch Analyse der Kundenzufriedenheit eingesetzt. Die Komponenten wurden teilweise auch dafür eingesetzt, Werkstattberichte zu analysieren, um festzustellen, welche Teile häufig defekt sind und getauscht werden. Zur Föderation 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über hinaus die Wissensextraktion von beliebigen Produktinformationen aus beliebigen heterogenen Informationsquellen des World Wide Web, d.h., beschränkt sich weder auf die Domäne des Automobilbaus, noch auf Diskussionen zur Produktqualität, 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ösung, speziell in der Fahrzeugdiagnose, einzuset- zen. Firmen, die sich mit Wissensextraktion aus föderierten 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ügbaren Frameworks und sind für die spezielle Domäne der Fahrzeugdiagnose nur bedingt geeignet. Auch ist es nur eingeschränkt möglich, externe, bereits seit langer Zeit eingesetzte Informationsquellen anzubinden. Die Software OntoBroker der Firma Ontoprise erlaubt das Reasoning über 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öglicht, indem es z.B. Über- und Unterbe- 28

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

Du liest eine Vorschau.

Hier ansehen

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

Weitere Verwandte Inhalte

Aktuellste (20)

Empfohlen (20)

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