Web-Kommunikation mit OpenSource : Chatbots, virtuelle Messen, Rich-Media-Content 3540290931, 9783540290933

Citation preview

---

Xpert.press

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Claus Möbus · Andreas Eißner · Jan Feindt Claudia Janßen · Jens Krefeldt · Sven Sieverding Stefan Sölbrandt · Jörg Stumpe · Holger de Vries Stefan Willer

Web-Kommunikation mit OpenSource Chatbots, Virtuelle Messen, Rich-Media-Content Mit 128 Abbildungen

123

Claus Möbus Department für Informatik Universität Oldenburg Postfach 2503 26111 Oldenburg [email protected]

Unter Mitarbeit von: Andreas Eißner, Jan Feindt, Claudia Janßen, Jens Krefeldt, Sven Sieverding, Stefan Sölbrandt, Jörg Stumpe, Holger de Vries und Stefan Willer

Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISSN 1439-5428 ISBN-10 3-540-23286-9 Springer Berlin Heidelberg New York ISBN-13 978-3-540-23286-5 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: Druckfertige Daten der Autoren Herstellung: LE-TEX, Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 33/3142 YL – 5 4 3 2 1 0

Vorwort

Die Idee, dieses Buch zu schreiben, entstand in der zweiten Hälfte des Jahres 2004. Herr Schmidt vom Projektträger DLR (Deutsches Zentrum für Luft- und Raumfahrt) führte an einem Freitag Nachmittag eine mehrstündige Begehung unseres I-canEIB-Projekts im OFFIS (Oldenburger Forschungsinstitut für Informatik-Werkzeuge und -Systeme) durch. Ihn interessierte jedes Detail dieses Web-KommunikationsProjekts, besonders aber auch die Frage der Nachhaltigkeit der Projektergebnisse war ein Thema. Bei den Präsentationen der Mitarbeiter wurde uns selbst erst so richtig die Vielfalt der realisierten Ideen bewusst. Wir fanden, dass es notwendig sei, eine Abschlusspublikaton in Form eines Buches vorzulegen. Ohne Abstriche ist eine Vermarktung des Prototyps1,2 , wegen seines Umfangs nicht möglich. In diesem Sinne entspricht das Buch auch der vom Förderer Bundesministerium für Wirtschaft und Arbeit (BMWA) gewünschten Nachhaltigkeit der Projektergebnisse. Da wir I-can-EIB mit Open-Source-Software realisiert haben, lag es nahe, das Originalsystem zu publizieren, um den Staffelstab in andere Hände zu legen und nur die Anpassungen und Modifikationen vermarkten zu wollen. Dies ist uns z. B. mit dem Projekt Automotive Intelligence für die Volkswagen AG gelungen. Mit dem Springer-Verlag und seiner Xpert.press-Reihe wurde ein geeignetes Publikationsforum für ein Buch gefunden. Wir hatten im Laufe der Projektarbeit selbst viele Werke dieser Reihe gelesen, z. B. [Widhalm u. Mück 2002], [Braun 2003], [Christ 2003], [Eymann 2003], [Lindner 2003], [Rothfuss u. Ried 2003], [Weiß u. Jakob 2004], 1

Unter einem Prototyp versteht man im Softwareengineering Folgendes: „Diese werden im Laufe der Analyse und des Entwurfs erstellt, um den Kunden den Stand des Projektes besser zeigen zu können. Anhand von Prototypen können die Systemarchitektur, Anwenderschnittstellen und auch grundlegende Funktionen demonstriert und diskutiert werden“ [Zuser u. a. 2004, S. 56]. 2 „Ein Softwareprototyp ist die Anfangsversion eines Softwaresystems, die dazu verwendet wird, Konzepte zu demonstrieren, Entwurfsmöglichkeiten auszuprobieren und – grundsätzlich – Erkenntnisse über das Problem und seine möglichen Lösungen zu gewinnen.“[Sommerville 2001, S. 181]

VI

[Brügge u. a. 2004], [Glöggler u. Glöggler 2005]. Dem Verlag schwebte ein Handbuch über unser Thema mit dem speziellen Schwerpunkt WWW vor. Ein derart umfassendes grundlagenorientiertes Opus, wie z. B. [Meinel u. Sack 2004], wäre aber in der uns zur Verfügung stehenden Zeit nicht machbar gewesen. In mehreren Verhandlungen mit dem Herausgeber der Xpert.press-Reihe Herrn Schmidt (nicht identisch mit ersterem) wurde dann eine gemeinsame Konzeption erarbeitet, die für beide Seiten akzeptabel und hoffentlich auch für Leser und Käufer interessant ist. Ein Kompromiss ist auch der Titel des Buches, der aus Marketinggesichtspunkten „Web-Kommunikation mit Open Source – Chatbots, virtuelle Messen, Rich Media Content“ lautet. Wir hätten eine andere Akzentuierung „Wissenskommunikation im Web: Frage-Antwort-Systeme, animierte Chatbots, virtuelle agentenbasierte Messen“ präferiert. Ein Wort noch zu dem in diesem Buch verwendeten Begriff Open Source: Der Begriff Open Source wurde durch die „Debian Free Software Guidelines (DFSG)“ im Juni 1997 von Bruce Perens3 ins Leben gerufen und weist 10 Kriterien zur Begriffsdefinition auf.4 Im Rahmen des I-can-EIB-Projektes ist weitestgehend Open-SourceSoftware verwendet bzw. entwickelt worden. Ausnahmen bilden hier die vorgeschlagenen VRML-Viewer (siehe Abschnitt 14.2.1 und Abschnitt 21.1), die nichtkommerziell frei nutzbar sind und das Logox WebSpeech Plugin (im Abschnitt 11.3.4). Oldenburg, Juli 2005

Claus Möbus

Kontakt Für Anregungen oder Tipps sind die Autoren unter der E-Mail-Adresse [email protected] für Sie erreichbar. Wir bitten darum, im Betreff die angesprochenen Autoren namentlich zu nennen, damit die E-Mail ohne Verzug bearbeitet werden kann. Aktuelle und weiterführende Informationen sowie frei verfügbare Sourcen sind auf unserer Website http://www.i-can-eib.de zu finden. Danksagung Wir haben bereits an anderer Stelle unseren Dank für die finanzielle Förderung und an den Projektträger ausgesprochen. Besonders möchten wir unserer Manuela Wüstefeld danken. Sie hat uns tatkräftig beim Erfassen der Texte, Layouten, Korrekturlesen und bei der Erledigung vieler Formalitäten unterstützt.

3

Bruce Perens ist ehemaliger Maintainer von Debian GNU/Linux. Die Definition von Open Source wird von der Open-Source Initiative (OSI) unter http: //www.opensource.org/docs/definition.php bereitgestellt. Letzter Zugriff am 02.05.2005. 4

Die Autoren

Von links nach rechts: Jens Krefeld (Cand. Inform., Universität Oldenburg), Claudia Janßen (Dipl. Inform., OFFIS), Jan Feindt (Dipl. Inform., OFFIS), Holger de Vries (Dipl. Inform., OFFIS), Prof. Dr. Claus Möbus (Projektleiter, Universität Oldenburg, OFFIS-SCS), Stefan Sölbrandt (Dipl. Inform., OFFIS), Stefan Willer (Cand. Inform., Universität Oldenburg), Jörg Stumpe (Cand. Inform., Universität Oldenburg), es fehlen: Andreas Eißner (Abteilungsleiter Multimedia/Projekte am Bundestechnologiezentrum für Elektro- und Informationstechnik e.V., Oldenburg), Sven Sieverding (Cand. Inform., Universität Oldenburg).

Inhaltsverzeichnis Teil I Für Entscheider: Frage-Antwort-Systeme

1

1 Einleitung

3

2

Das E-Learning- und Informationssystem I-can-EIB 2.1 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Die LERNET-Ausschreibung des BMWA . . . . . . . . . . . . . 2.2.1 Arbeitsprozessorientierte Weiterbildung . . . . . . . . . . 2.2.2 Lernen am Kundenauftrag: Impliziter und expliziter Wissenserwerb . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Struktur des Rich-Media-Systems I-can-EIB . . . . . . . . . . . . 2.4 Prototypische Anwendungsszenarien von I-can-EIB . . . . . . . . 2.4.1 Szenario 1: Optimiertes Informationsangebot einer Zielgruppe: Forum für BMW-Fans und -Fahrer . . . . . . . . 2.4.2 Szenario 2: Einsatz im kommunalen Bürgerservice . . . . 2.4.3 Szenario 3: Einsatz im Customer Relation Management (CRM) der Unterhaltungsmedien . . . . . . . . . . . . . 2.4.4 Szenario 4: Interaktives Informationsangebot einer Musikkneipe . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Szenario 5: Informationsangebot eines Universitätsinstituts 2.4.6 Szenario 6: E-Learning- und Informationsangebot einer Schule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.7 Szenario 7: Beratungsservice eines innovativen Großunternehmens . . . . . . . . . . . . . . . . . . . . . . . . .

16 16

3 Die Entwicklungsgeschichte von I-can-EIB 3.1 Das Uni-Seminar Agenten und Avatare . . . . . . . . . . . . . . . 3.2 Der ffn-Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Die Vision eines internetbasierten Wissensmarktplatzes . . . . . .

23 23 23 25

4

29 29 37 38 39

Frage-Antwort-Systeme und I-can-EIB 4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Frage- und Antwort-Systeme . . . . . . . . . . . . . . 4.2.1 Theoretischer Rahmen von Frage und Antwort 4.2.2 Fragen . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

5 5 9 10 11 11 15

19 20 21 22 22

X

INHALTSVERZEICHNIS

4.2.3 4.2.4 4.2.5 4.2.6

Antworten . . . . . . . . . . . Eine abstrakte FAS-Architektur Frühere Systeme . . . . . . . . State-of-the-Art: Der Halo-Pilot

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

41 43 44 45

5 Die Auslegung des I-can-EIB-Systems

59

6

Ausblick: Eine Roadmap der FAS 2003 – 2006

67

7

Avatare im E-Learning und E-Business 7.1 Chatbots, Avatare und Agenten . . . . . 7.1.1 Agent . . . . . . . . . . . . . . 7.1.2 Chatbot . . . . . . . . . . . . . 7.1.3 Avatar . . . . . . . . . . . . . . 7.1.4 Talking Head . . . . . . . . . . 7.1.5 Embodied Conversational Agent 7.2 Zusatznutzen von Avataren . . . . . . . 7.3 Einsatzgebiete von Avataren . . . . . . 7.3.1 E-Learning . . . . . . . . . . . 7.3.2 E-Business . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

69 69 69 71 72 72 73 73 75 75 76

Gesprächskompetenz digitaler Agenten 8.1 Der Turing-Test . . . . . . . . . . . 8.2 Der Loebner-Preis . . . . . . . . . . 8.3 Chatbots . . . . . . . . . . . . . . . 8.4 Information-Retrieval . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

79 80 81 82 84

Checkliste der erforderlichen Kompetenzen für IT-Experten 9.1 Rollenträger . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Markup-Sprachen . . . . . . . . . . . . . . . . . . . . . . 9.3 Programmiersprachen . . . . . . . . . . . . . . . . . . . . 9.4 Administration . . . . . . . . . . . . . . . . . . . . . . . 9.5 Multimedia . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

87 87 88 88 89 90

8

9

. . . .

. . . .

Teil II Für Content- und Software-Entwickler: Das I-canEIB-System 10 Portal 10.1 Einleitung . . . . . . . . . . . . . 10.2 Begriffsdefinition . . . . . . . . . 10.3 Referenzarchitektur . . . . . . . . 10.4 Portal-Software . . . . . . . . . . 10.4.1 Portal-Anwendungen . . . 10.4.2 Portal-Basisdienste . . . . 10.5 Lösungen auf Open-Source-Basis

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

91 . . . . . . .

. . . . . . .

93 93 93 94 94 95 95 96

INHALTSVERZEICHNIS

XI

10.6 Das TikiWiki-System . . . . . . . . . . . . . . . . . . . . . . . . 10.6.1 Einbinden von Portal-Anwendungen . . . . . . . . . . . . 10.6.2 Das Template-System „Smarty“ . . . . . . . . . . . . . .

98 99 100

11 Sprache 11.1 Einführung und Grundlagen . . . . . . . 11.1.1 SAMPA . . . . . . . . . . . . . . 11.1.2 BOMP . . . . . . . . . . . . . . 11.2 Sprachsynthese . . . . . . . . . . . . . . 11.2.1 Verfahren der Sprachsynthese . . 11.2.2 Diphonsynthese . . . . . . . . . . 11.2.3 Unit-Selection . . . . . . . . . . 11.2.4 Mikrosegmentsynthese . . . . . . 11.3 TTS-Systeme . . . . . . . . . . . . . . . 11.3.1 MBROLA . . . . . . . . . . . . . 11.3.2 HADIFIX . . . . . . . . . . . . . 11.3.3 IMS-Festival . . . . . . . . . . . 11.3.4 G DATA Logox . . . . . . . . . . 11.4 Modellbasierte visuelle Synthese . . . . . 11.4.1 Parametrische Modelle . . . . . . 11.4.2 Muskelbasierte Gesichtsanimation 11.5 Steuermodelle . . . . . . . . . . . . . . . 11.5.1 Viseme . . . . . . . . . . . . . . 11.5.2 Koartikulationsmodelle . . . . . . 11.5.3 Triphonmodelle . . . . . . . . . . 11.6 Lippensynchronisation . . . . . . . . . . 11.7 Zusammenfassung . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

101 101 103 104 104 105 106 107 108 108 109 110 110 111 111 112 112 113 113 113 114 114 116

12 Der Avatar „EIBY“ 12.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Grundlegende Architektur . . . . . . . . . . . . . . . . 12.3 Modell und Animation . . . . . . . . . . . . . . . . . . 12.3.1 Mimik . . . . . . . . . . . . . . . . . . . . . . . 12.3.2 Spezifikation von Avatar-Modellen . . . . . . . 12.3.3 Avatar-Modellierung in ICE-FaceXML . . . . . 12.3.4 Steuerung über Low-Level-Animationen . . . . 12.4 Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1 Herstellung von Glaubwürdigkeit und Vertrauen 12.4.2 Darstellung von Emotionen . . . . . . . . . . . 12.4.3 Steuerung über High-Level-Animationen . . . . 12.4.4 Übertragbarkeit auf andere Modelle . . . . . . . 12.5 EDGAR – der Avatar-Editor . . . . . . . . . . . . . . . 12.5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . 12.5.2 Tour durch den Editor EDGAR . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

117 117 119 121 122 124 125 128 132 132 133 136 138 139 139 141

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

XII

INHALTSVERZEICHNIS

13 Gesprächskompetenz im I-can-EIB-System 13.1 Vorgehensmodell zur Verbesserung der Gesprächskompetenz . . . 13.2 Open-Source-Chatbots . . . . . . . . . . . . . . . . . . . . . . . 13.2.1 Selbstlernende Chatbot-Systeme . . . . . . . . . . . . . . 13.2.2 AIML-Chatbots . . . . . . . . . . . . . . . . . . . . . . . 13.3 A.L.I.C.E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.1 Kompetenzerwerb durch Supervised Learning . . . . . . . 13.3.2 A.L.I.C.E.-Server . . . . . . . . . . . . . . . . . . . . . . 13.3.3 Verarbeitung der natürlichen Sprache . . . . . . . . . . . 13.3.4 Web-Applikation . . . . . . . . . . . . . . . . . . . . . . 13.3.5 Wissensrepräsentation mit AIML . . . . . . . . . . . . . 13.3.6 Generierung der Antworten . . . . . . . . . . . . . . . . 13.3.7 Tools zur Bearbeitung und Analyse von AIML-Dateien . . 13.3.8 Einbindung von Skriptsprachen in die Antwort-Templates 13.4 Wissensbasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.1 Einsteigerberatung . . . . . . . . . . . . . . . . . . . . . 13.4.2 Information-Retrieval-Systeme . . . . . . . . . . . . . . . 13.4.3 Information-Mining dynamischer Inhalte aus dem Web . . 13.4.4 Zugriff auf Wissen über einen Index . . . . . . . . . . . .

147 147 151 151 152 153 153 154 156 160 162 166 170 174 176 177 191 199 208

14 Wissensmarktplatz mit Agenten und Avataren 14.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . 14.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . 14.2.1 Chatsystem (VNet) . . . . . . . . . . . . . . . 14.2.2 Agentensystem (JADE) . . . . . . . . . . . . . 14.2.3 Chatbot-Integration (A.L.I.C.E.) . . . . . . . . 14.2.4 CMS-Anbindung . . . . . . . . . . . . . . . . 14.3 Entwicklung mit VRML, AgentScript und JADE . . . 14.3.1 Virtual Reality Modelling Language (VRML) . 14.3.2 AgentScript und eine JADE-Implementation . 14.3.3 JADE-Verhaltensentwicklung für AgentScript . 14.3.4 Beispiel für die Entwicklung eines Verhaltens . 14.3.5 Agenten zur Raumerstellung und Konfiguration

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

213 213 215 218 225 246 249 250 250 251 264 267 270

15 Entwicklung und Integration von Rich Media Learning Objects 15.1 Rich Media Content im E-Learning . . . . . . . . . . . . . . 15.1.1 Das Projekt I-can-EIB . . . . . . . . . . . . . . . . . 15.2 Entwicklung von Rich Media Content im E-Learning . . . . . 15.2.1 Fein- und Grobkonzept von Lerninhalten . . . . . . . 15.2.2 Drehbuchentwicklung . . . . . . . . . . . . . . . . . 15.2.3 Erstellung ablauffähiger Lernsequenzen . . . . . . . . 15.2.4 Implementierung, SCORM-Metadaten . . . . . . . . . 15.3 Der XML-Drehbucheditor . . . . . . . . . . . . . . . . . . . 15.3.1 Beschreibung der Eingabefelder . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

275 275 276 277 278 281 282 283 284 286

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

INHALTSVERZEICHNIS

XIII

16 Standardisierung der Lerneinheiten 16.1 Entwicklung eines Drehbucheditors zur Unterstützung von Autoren bei der Content-Entwicklung . . . . . . . . . . . . . . . . . 16.2 Content-Standardisierung: ADL-SCORM . . . . . . . . . . . . . 16.3 Generierung SCORM-kompatibler Lerneinheiten . . . . . . . . .

293 293 294 299

17 Evaluation 17.1 Evaluationsobjekt I-can-EIB-Avatar . . . 17.2 Fragebogen . . . . . . . . . . . . . . . . 17.3 Pre-Post-Testdesign . . . . . . . . . . . . 17.4 Datenanalyse und statistische Auswertung 17.5 Ergebnisse . . . . . . . . . . . . . . . . . 17.6 Zusammenfassung und Resümee . . . . .

303 304 304 305 305 307 310

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Teil III Für Administratoren: Installation und Konfiguration 18 Portal 18.1 Systemvoraussetzungen . . . . . . . . 18.2 Apache HTTP-Server . . . . . . . . . 18.3 PHP Version 4 . . . . . . . . . . . . . 18.4 MySQL . . . . . . . . . . . . . . . . 18.4.1 Installation . . . . . . . . . . 18.4.2 Starten des MySQL-Dämons . 18.4.3 Erstellung der Tiki-Datenbank 18.4.4 PHPMyAdmin . . . . . . . . 18.5 TikiWiki . . . . . . . . . . . . . . . .

313

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

315 315 316 316 317 317 317 318 318 319

19 Gesprächskomponenten des I-can-EIB-Systems 19.1 TreeTagger . . . . . . . . . . . . . . . . . . . . . 19.1.1 Installationsvoraussetzung . . . . . . . . . 19.1.2 Installation . . . . . . . . . . . . . . . . . 19.1.3 Konfiguration . . . . . . . . . . . . . . . . 19.1.4 Programmstart . . . . . . . . . . . . . . . 19.1.5 Anmerkungen zur Nutzung als Web-Service 19.2 A.L.I.C.E. . . . . . . . . . . . . . . . . . . . . . . 19.2.1 Installationsvoraussetzungen . . . . . . . . 19.2.2 Installation . . . . . . . . . . . . . . . . . 19.2.3 Konfiguration . . . . . . . . . . . . . . . . 19.2.4 Eine Web-Applikation erzeugen . . . . . . 19.2.5 Auf dem Server installieren . . . . . . . . 19.2.6 Wissensinhalte verfügbar machen . . . . . 19.3 Webbasierte Datenextraktion mit W3 xtract . . . . . 19.3.1 Installation . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

321 321 321 321 322 322 322 322 322 323 323 326 326 326 327 327

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

XIV

INHALTSVERZEICHNIS

19.3.2 19.3.3 19.3.4 19.3.5

Konfiguration und Wartung . Zeitgesteuerte Ausführung . XPath-Ausdruck ermitteln . Alternative HTML-Parser .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

327 328 329 330

20 Avatar-System 20.1 Installation . . . . . . . . . . . . . . . . . . . . . . 20.1.1 Allgemeines . . . . . . . . . . . . . . . . . 20.1.2 Systemanforderungen . . . . . . . . . . . . 20.1.3 Installation des Avatar-Editors EDGAR . . . 20.1.4 Installation des Java-Applets . . . . . . . . . 20.1.5 Das Applet in der Initialisierungsphase . . . 20.2 Konfiguration . . . . . . . . . . . . . . . . . . . . . 20.2.1 Einleitung . . . . . . . . . . . . . . . . . . . 20.2.2 Kommunikation zwischen Applet und Server 20.2.3 Die Applet-Parameter . . . . . . . . . . . . 20.2.4 Anbindung alternativer TTS-Engines . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

331 331 331 331 333 333 333 335 335 335 337 338

21 3D-Multiagentensystem 21.1 Installation . . . . . . . . . . . . . . . . 21.1.1 Systemanforderungen . . . . . . 21.1.2 Installation des MAS-Systems . . 21.2 Konfiguration . . . . . . . . . . . . . . . 21.2.1 VNet-Client/Server-Konfiguration 21.2.2 JADE-Eigenschaften . . . . . . . 21.2.3 Ausstellungskonfigurator . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

339 339 339 340 342 343 343 348

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . . . . .

Teil IV Anhang A Avatar-Beschreibungssprache A.1 ICE-FaceXML-DTD . . . . . A.2 ICE-FaceXML-Tags-Übersicht A.2.1 . . . . A.2.2 . . . . . A.2.3 . . . . . . A.2.4 . . . . . A.2.5 . . . . . . A.2.6 . . . . . . A.2.7 . . . . . . . . A.2.8 . . . . A.2.9 . . . . . . A.2.10 . . . . . . . A.2.11 . . . A.2.12 . . . .

351 . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

353 353 354 354 354 354 354 354 355 355 355 355 356 356 356

INHALTSVERZEICHNIS

XV

A.3 Beispiel für eine Avatar-Beschreibung . . . . . . . . . . . . . . .

356

B Avatar-Animationssprache B.1 ICE-FaceAnimXML-DTD . . . . . . . . . B.2 ICE-FaceAnimXML-Tags-Übersicht . . . . B.2.1 . . . . . . B.2.2 . . . . . . . . . . . . B.2.3 . . . . . . . . . . . . . B.2.4 . . . . . . . . B.2.5 . . . . . . . . . . . . . . B.2.6 . . . . . . . . . . . . . . . B.2.7 . . . . . . . . . . . . B.2.8 . . . . . . . . . . . . . B.3 Avatar-Animationssprache – Beispielaufbau

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

357 357 357 357 358 358 358 358 359 359 359 359

C Beispiel einer Raumerstellung in VRML

361

D Definition AgentScript Markup Language

371

E W3 xtract E.1 Das Wetterbeispiel . . . . . . . . E.2 W3 xtractConfig-DTD . . . . . . . E.3 W3 xtractConfig-Tags-Übersicht . E.3.1 . . E.3.2 . . . . . . E.3.3 E.3.4 . . . . . . E.3.5 . . . . . . . E.4 W3 xtractConfig – Beispielaufbau . E.5 W3 xtractJob-DTD . . . . . . . . . E.6 W3 xtractJob-Tags-Übersicht . . . E.6.1 . . . . E.6.2 . . . . . . . . . . . E.6.3 . . . E.6.4 . . . . . . . . . . E.6.5 . . . . . . . . . E.6.6 . . . . . . E.6.7 . . E.6.8 . . . . . . E.6.9 . . . . . . . . E.6.10 . . . . . . . E.6.11 . . . . . . E.6.12 . . . . . . . . E.7 W3 xtractJob – Beispiel . . . . . . F VRML Interchange Protocol

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

373 373 374 374 374 374 374 374 374 375 375 376 376 376 376 376 376 376 377 377 377 377 377 377 378 379

XVI

F.1 F.2 F.3

F.4 F.5

INHALTSVERZEICHNIS

Einführung . . . . . . . . . . . . . VRML-Feld-Typenkodierung . . . . Nachrichtenformat . . . . . . . . . F.3.1 Objekt . . . . . . . . . . . . F.3.2 Feld . . . . . . . . . . . . . F.3.3 Wert . . . . . . . . . . . . . Pseudofelder reserviert von VNet . . Beispiele zum Nachrichtenaustausch

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

379 379 380 380 380 381 381 382

G Definition Wissensmarktplatz-Konfiguration

383

H Phonem-Übersicht

385

I

LERNET-Partner

389

J

Quellenangaben zu den Abbildungen

391

K Abkürzungs- und Akronymverzeichnis

393

Literaturverzeichnis

403

Index

419

Teil I

Für Entscheider: Frage-Antwort-Systeme

1 Einleitung Claus Möbus

Das vorliegende Buch über Kommunikation im Web ist nicht als Handbuch konzipiert, sondern wir stellen eine Reihe von relevanten Theorien, Vorgehensweisen, Methoden und Techniken an einem Best-Case-Beispiel – dem I-can-EIB-System – dar. I-can-EIB ist der Prototyp (vgl. [Zuser u. a. 2001, S. 58], [Zuser u. a. 2004, S. 56]) eines integrierten E-Learning- und Informationssystems, das eine Mischung aus offenem und betreutem Telelernen bzw. -informieren ermöglicht (vgl.[Dumke u. a. 2003]). Der Content für den Prototyp wurde für die Zielgruppe der EIB-Interessierten (Elektroinstallateure, Architekten, Bauherren u. a.) entwickelt. Die Abkürzung EIB steht für Europäischer Installations-Bus. Der EIB ist die Weiterentwicklung der herkömmlichen Elektroinstallation. Er erfüllt die Anforderungen der modernen Gebäudeinstallation hinsichtlich Komfort, Sicherheit, Wirtschaftlichkeit (Energieersparnis), Multimedia und Kommunikation. Bei einer EIB-Installation wird das Gebäude mitsamt seinen Außen- und Nebenanlagen „intelligent vernetzt“. Dadurch bleibt eine dezentrale (lokale) Steuerung einzelner Komponenten, wie z. B. des Lichts oder der Temperatur, weiterhin möglich. Zusätzlich bietet die Möglichkeit der zentralen Steuerung bemerkenswerte Vorteile. Besonders bekannt ist die zentrale Jalousien- oder Lichtsteuerung, die bei längerer Abwesenheit der Hausbewohner deren Anwesenheit vortäuscht. Über Displays lassen sich Einstellungen und Zustand einzelner Komponenten überwachen und steuern. So könnte am Display vor Verlassen des Hauses geprüft werden, ob wirklich alle Fenster und Türen geschlossen sind. Bewegungsmelder und Alarmanlagen runden das Sicherheitspaket ab. Es wird deutlich, dass der EIB in Wohnhäusern und Zweckbauten ein breites Spektrum an Funktionalität abdeckt. Da sich diese Technik mit der vorhandenen konventionellen Elektroinstallation verbinden lässt, ist sie nicht nur für Neubauten, sondern auch für Renovierungsobjekte interessant. Das Wissensgebiet EIB steht beispielhaft für andere Anwendungsgebiete die mit ihren Konzepten, Komponenten Funktionen und ihrem Anwendungs-, Montage- und Konstruktionswissen eine klare Struktur und ein gewisses Maß an Anschaulichkeit

4

1 Einleitung

besitzen. Kommt dann noch ein permanenter Schulungs- und Beratungsbedarf hinzu, ist unser I-can-EIB-System eine gute Wahl. Themengebiete mit unklarer Struktur und mit wenig objektivierbarem Wissen sind für I-can-EIB weniger gut geeignet. So sehen wir es als schwierig an, ein Schulungs- und Beratungssystem zur Whiskyverkostung mit I-can-EIB zu realisieren; aber wie heißt es so schön: „Nichts ist unmöglich !“ Unser I-can-EIB-Prototyp ist derart modular entwickelt worden, dass er aus den oben genannten Gründen für jedes beliebige klar strukturierte Themengebiet einsetzbar ist. Der EIB-Content dient uns nur als Beispielanwendung, anhand derer die Theorien, Vorgehensweisen, Methoden und Techniken vorgestellt werden. Über denkbare Einsatzgebiete gibt der Abschnitt 2.4 einen Überblick. Im Folgenden möchten wir diese alternativen Themen ebenfalls mit EIB bezeichnen, wobei die Abkürzung EIB jetzt für Eine Innovative Basisidee steht.

2 Das E-Learning- und Informationssystem I-can-EIB Claus Möbus und Andreas Eißner

2.1 Kommunikation Claus Möbus Unter Kommunikation im Web verstehen wir die computervermittelte Kommunikation zwischen „wissenshungrigen“ Menschen (Usern) und „mitteilungsfreudigen“ Experten über ein Thema, das wir EIB (Eine Innovative Basisidee) nennen wollen. EIB kann alles sein, was so wichtig und mitteilenswert ist, dass man ein webbasiertes E-Learning- und E-Informationssystem installieren möchte. In unserem I-can-EIBSystem stand EIB für Europäischer Installations-Bus – eine intelligente Haustechnik. Gesprächspartner der wissenshungrigen Nutzer können reale Menschen (Techniker, Ingenieure) oder auch virtuelle Chatbots mit oder ohne Verkörperung bzw. Avatare (d. h. Stellvertreter für Nutzer) sein. Man könnte hier vielleicht auch von Wissenskommunikation sprechen. Findet die Kommunikation im Web zwischen Menschen statt, ist sie zwar kompliziert, wenn man sie aus einer wissenschaftlichen (beispielsweise kommunikations-psychologischen) Perspektive betrachtet. Der Informatiker kann sich indes entspannt zurücklehnen, hat er doch nur die technischen Hilfsmittel und Kommunikationskanäle zur Verfügung zu stellen. Das ist im Allgemeinen eine normale ingenieurmäßige Aufgabe: nicht riskant und daher nicht besonders aufregend. Anders werden die Verhältnisse, wenn die Kommunikation sich zwischen menschlichen Nutzern und Chatbots bzw. Avataren abspielt, die noch zusätzlich eine gewisse körperliche Darstellung besitzen. Funktionalität und Mimik des virtuellen Gesprächspartners werden eine große Herausforderung für den Informatiker. Zugleich weiß er, dass die Kommunikation zwischen einem Menschen und einem Bot einfacher werden muss, weil der Bot von allen vier Facetten der Kommunikation Sachinhalt , Selbstoffenbarung, Beziehung und Appell (vgl. [Schulz von Thun 2004])

6

2 Das E-Learning- und Informationssystem I-can-EIB

vielleicht nur den Sachinhalt „versteht“. Für den menschlichen Gesprächspartner kann trotz dieser einseitigen Vereinfachung auf der Bot-Seite die Kommunikation eine komplizierte Sache bleiben. Gerade dann, wenn der Bot humanoid wirkt, liegt die Versuchung nahe, in allen 4 Facetten mit ihm kommunizieren zu wollen. Leicht werden hier Enttäuschungen ausgelöst, wenn hinsichtlich der Offenbarungs-, Beziehungs- und Appellfacette vom Bot keine Erwartungen bedient werden. Wir haben die Hypothese, dass der Grad der Erwartungen an die Kommunikationskompetenz in allen Facetten umso stärker ist, je humanoider der Bot wirkt. Manchmal ist auch hier weniger – letztendlich mehr. Wir haben aus diesem Grunde auch mit unserem Avatar EIBY Verlockungen oder auch Drohungen standgehalten: „Der hat ja gar keine Haare!“ Wir wussten, dass wir in solche Fallen erst dann tappen sollten, wenn EIBYs Kommunikationskompetenz ein entsprechendes Niveau erreicht hat. Nach [Schulz von Thun 2004] muss eine ideale Kommunikation vier Kriterien genügen. Das Handeln soll: • • • •

wertegeleitet, passend zur Persönlichkeit des Senders (authentisch), passend zum Charakter der Situation (authentisch), metakommunikatorisch und selbstreflexiv

sein. Die vier Kriterien in Echtzeit richtig einzusetzen, ist für Menschen erst nach langen Jahren der Erziehung möglich. Für unsere Bots sind sie unerreichbare Ziele. Daher wissen wir, dass die Nutzer-Chatbot-Kommunikation nicht ideal sein kann. Wollen wir genauer Chancen und Risiken einer derartigen Mensch-MaschineKommunikation untersuchen, ziehen wir aus pragmatischen Gründen das deskriptive Kommunikationsquadrat von Schulz von Thun heran. Jede Nachricht enthält vier Botschaften: (1) (2) (3) (4)

Sachinhalt, Selbstauskunft/Offenbarung, Beziehungsmitteilung und Appell/Sprechakt.

Mit einer Nachricht teile ich (1) (2) (3) (4)

ein Faktum, meine Befindlichkeit, etwas über meine Beziehung zu dem Gesprächspartner und meine Wünsche oder Aufforderungen mit.

Der Sprecher spricht nach Schulz von Thun mit vier Stimmen. Als Hörer setzt er vier Ohren mit entsprechenden Fragen ein:

2.1 Kommunikation

(1) (2) (3) (4)

7

Was ist der Sachverhalt?, Wie geht es ihm?, Wie will er seine Beziehung zu mir gestalten?, Was will er von mir? Was soll ich tun?

Wir wollen das an einem Beispiel erläutern. Ein Hausherr möchte etwas über die Verteuerung der Elektroinstallation durch den EIB von unserem Avatar EIBY herausbekommen. Er stellt die Frage: „Mal unter uns, der Preis erhöht sich doch wohl nicht um 400 Prozent?“ Die Frage enthält vier Botschaften: (1) Den Sachinhalt: „Verteuert sich durch Installation des EIB die normale Elektroinstallation nicht mehr als 400 Prozent?“, (2) die Selbstauskunft/Offenbarung des fragenden Bauherrn: „Ich bin ziemlich verunsichert, weiß nicht, welchen Preisangaben ich trauen soll?“, (3) die Beziehungsmitteilung: „Ich schenke dir spezielles Vertrauen, mir kannst du ruhig die Wahrheit sagen!“ und (4) der Appell/Sprechakt: „Lass bei der Preiskalkulation allen überflüssigen Schnickschnack weg!“. Kommuniziert ein menschlicher User mit einem virtuellen Bot, kann man eine FrageAntwort-Sequenz mit zwei Kommunikationswürfeln beschreiben (Abb. 2.1). Aufgrund der aktuellen Forschung ist zunächst die fehlerfreie Kommunikation der Sachinformation zu erwarten. Als Nächstes ist zu vermuten, dass der Avatar direkte Appelle kommunizieren und verstehen kann. Schwieriger wird es bei dem Verstehen der menschlichen Befindlichkeits- und Beziehungsäußerungen. Hier müsste der Avatar eine Persönlichkeit und Empathie entwickeln: schwierige Themen (vgl. [Dörner 2001], [Dörner u. Schaub 2002])! Aber auch beim rechten Kommunikationswürfel kann es Probleme geben. Ist der Avatar so humanoid, dass der Nutzer unbewusst in eine echte Kommunikation einsteigen will, die Selbstauskünfte hinsichtlich der Befindlichkeit des Avatars oder Aussagen über die Beziehung Avatar-Nutzer beinhaltet, kann nur Enttäuschung vorprogrammiert sein. In der Tat ist es immer wieder zu beobachten, dass Nutzer irgendetwas „Persönliches“ aus dem Avatar herausquetschen wollen. Wir haben aus diesem Grund unserem Avatar EIBY auch eine kleine „menschliche Seite“ beigegeben. Man kann sich mit ihm über Wettervorhersagen unterhalten. Zur Positionierung von Chatbots oder Avatare gibt es Empfehlungen von Praktikern der Kommunikations- und Marketingbranche (Abb.2.2 [Wize 2004, S. 78]). Sie können einerseits eine „Brücke“ zwischen konventioneller Website und Call-Center – also zwischen Information und persönlichem Gespräch – bauen und andererseits für zusätzliche Emotionalität in der Kommunikation sorgen. „Und es geht nicht um das Ersetzen von Irgendetwas, sondern um das Ergänzen!“ [Wize 2004, S. 78]. Mit dem Einsatz von Chatbots verbinden sich eine Reihe von Erwartungen: Verbesserung (1) der Service- und Beratungsqualität durch Entlastung des Call-Centers von Bagatellberatung, (2) der Kundenbindung durch Anytime-Beratung und -Feedback,

8

2 Das E-Learning- und Informationssystem I-can-EIB

(3) des E-Marketing durch personalisierte vertrauensfördernde Kundenbindung, (4) der Marktforschung durch die Analyse nichtreaktiver Daten von Nutzern, (5) von Möglichkeiten zum Recruiting von Mitarbeitern über Avatar-Dialoge, (6) der Mitarbeiterberatung im Intranet, (7) des Entertainment durch „packende“ Dialoge mit dem Avatar, (8) der engagierten, freundlichen, kompetenten und 24/7/365-anytimeE-Beratung, (9) des Wissensmanagement durch Wissenskommunikation auf einer kognitiven und emotionalen Ebene mit Möglichkeit zum Modelllernen, (10) des Dialogmarketing durch persönliche Ansprache, die nachhaltig wirkende Dialoge ermöglicht, (11) des Qualitätsmanagement durch gleichbleibende Dialog-, Instruktionsund Beratungsqualität der Kommunikation (s. auch [Wize 2004, S. 100–111]).

Nutzer t-1 Selbstauskunft

Avatar t Selbstauskunft

?

Sachinformation

Beziehungsinfo

Sprechakt/Appell

Nutzer t+1

?

Informative Antwort

?

Beziehungsinfo

performative Antwort

Selbstauskunft

Sachinformation

?

Beziehungsinfo

Sprechakt/Appell

Abb. 2.1: Frage-Antwort-Sequenz als Folge von Kommunikationswürfeln

In unserem Projekt erfolgt der Wissensaufbau oder die Kompetenzverbesserung auf der Nutzer- (Lerner-)seite über eine bestimmte Domäne, die wir hier abstrakt EIB (Eine Innovative Basisidee) nennen und die wir im konkreten Verlauf des Projektes I-can-EIB von Fall zu Fall mit dem Wissensgebiet des Europäischen InstallationsBusses (EIB) instanzieren wollen. Dazu wurde ein internetbasiertes integriertes ELearning- und Informationssystem – nämlich das I-can-EIB-System – entwickelt. Seine Entwicklung wurde im Rahmen der LERNET-Initiative durch das Bundesministerium für Wirtschaft und Arbeit (BMWA) gefördert. Als Projektträger begleitete uns das Deutsche Zentrum für Luft- und Raumfahrt (DLR).

2.2 Die LERNET-Ausschreibung des BMWA

9

Abb. 2.2: Positionierung von Chatbots in der Web-Kommunikation

2.2 Die LERNET-Ausschreibung des BMWA Claus Möbus und Andreas Eißner LERNET1 ist Teil des Aktionsprogramms „Innovation und Arbeitsplätze in der Informationsgesellschaft des 21. Jahrhunderts“ des BMWA und steht für die Entwicklung netzbasierter Lernlösungen für mittelständische Unternehmen und öffentliche Verwaltungen. Ziel war es, auf Basis der heutigen Informations- und Kommunikationstechnologien neue Formen der Weiterbildung für kleine und mittlere Unternehmen (KMU) sowie für öffentliche Verwaltungen zu entwickeln. Es sollten Good-Practice-Beispiele für selbstorganisiertes Lernen entstehen, mit denen Akzeptanz und Qualität netzbasierter Weiterbildung gesteigert sowie Nachahmungseffekte ausgelöst werden. Eine Besonderheit von LERNET ist die Zusammenführung von Grundlagenwissen und Technologien verschiedener Disziplinen – von der Informatik über die Kommunikationswissenschaften bis hin zur Pädagogik – zu innovativen, zielgruppengerechten netzbasierten Lernlösungen. Im April 2000 startete das BMWA den Wettbewerb „LERNET – Netzbasiertes Lernen in Mittelstand und öffentlichen Verwaltungen“. Aus 145 eingegangenen Ideenskizzen wurden von einer unabhängigen Jury elf Projekte zur Förderung ausgewählt. Eines dieser ausgezeichneten Projekte2 war I-can-EIB. Es bildete das kleinste Konsortium mit nur zwei Partnern – dem Oldenburger Bundestechnologiezentrum für Elektro- und Informationstechnik (bfe) und dem Oldenburger Forschungs- und

1

Siehe http://www.lernet-info.de/, letzter Zugriff am: 02.05.2005. clear2b, Go2Learning, HALMA, I-can-EIB, LEVER, NET-CA-T, NetLIm, prodela, VOCAL, WebTrain, eQtv 2

10

2 Das E-Learning- und Informationssystem I-can-EIB

Entwicklungsinstitut für Informatik-Werkzeuge und -Systeme (OFFIS).3 I-can-EIB steht einmal für die Absicht, die innovative Technik des Europäischen InstallationsBusses (EIB) beherrschen zu können („Ich kann EIB“) und andererseits als Akronym für „Innovative CBT-Architektur im InterNet für den EIB“ bzw. „Integriertes Cooperatives Avatarbasiertes Netz zum Europäischen Installations-Bus“. Die interdisziplinär zusammengesetzten LERNET-Konsortien realisierten die jeweilige spezielle Projektidee zum Hauptthema multimediale Weiterbildungssysteme für Mitarbeiter, Personalverantwortliche und Entscheider unterschiedlicher Branchen bzw. der öffentlichen Verwaltung bis Mitte 2004. 2.2.1 Arbeitsprozessorientierte Weiterbildung I-can-EIB wurde im Antrag so konzipiert, dass es weitgehend dem Konzept der Arbeitsprozessorientierten Weiterbildung (APO-W) entspricht. APO-W besteht aus vier Ideen: 1. Weiterbildung wird weitgehend als selbstgesteuertes informelles Lernen aufgefasst, 2. Weiterbildungsziele und -inhalte werden tätigkeitsprofilspezifisch aus systematisierten Arbeitsprozessen (Referenzprojekten) abgeleitet, 3. Weiterbildung findet als Teil des Arbeitsprozesses unmittelbar am Arbeitsplatz durch die Bearbeitung realer Projekte statt und 4. die Qualifizierung ist integriert in den normalen Ablauf am Arbeitsplatz. Die Idee des selbstgesteuerten informellen Lernens wird dabei nicht puristisch, sondern gemäßigt umgesetzt. Die Weiterbildung hat auch formelle Anteile: Sie findet auch im Team statt und wird durch Coachs (Lernbetreuer) und Fachexperten unterstützt. Für dieses Konzept erhielt die Deutsche Telekom AG und das Fraunhofer-Institut für Software- und Systemtechnik (ISST) den Weiterbildungs-Innovationspreis 2001 des Bundesinstituts für Berufsbildung (BIBB). Die Weiterbildung findet direkt am Arbeitsplatz (d. h. informell) statt und ist komplett in den Arbeitsprozess eingebunden. 3

Wir wollen an dieser Stelle dem Bundesministerium für Wirtschaft und Arbeit für die finanzielle Förderung, dem Projektträger Deutsches Zentrum für Luft- und Raumfahrt für die Betreuung und dem Controlling sowie dem Beirat (Hermann Behrens, DIN Deutsches Institut für Normung e. V.; Prof. Dr. Christine Fackiner, Fachhochschule Gelsenkirchen; Prof. Dr. Friedhelm Gehrmann; Dr. Thomas Heimer, Bankakademie e. V; Dr. Kathrin Hensge, Bundesinstitut für Berufsbildung; Michael Härtel, Bundesinstitut für Berufsbildung; Dr. Hans G. Klaus, Projektträger Neue Medien in der Bildung; Peter Littig, DEKRA Akademie GmbH; Prof. Dr. Werner Poguntke, Fachhochschule Südwestfalen; Prof. Dr. Bernd Stöckert, TU Chemnitz, Lehrstuhl Wirtschaftsinformatik I; Prof. Dr. Frank Thissen, Fachhochschule Stuttgart, Hochschule der Medien; Geerd Woortmann, Deutscher Industrie- und Handelskammertag) für das wohlwollende Verständnis für unsere innovativen Ideen noch einmal besonders danken.

2.3 Struktur des Rich-Media-Systems I-can-EIB

11

Die Teilnehmer qualifizieren sich nicht anhand theoretischer Aufgabenstellungen, sondern bei der praktischen Umsetzung eines realen Projekts. 2.2.2 Lernen am Kundenauftrag: Impliziter und expliziter Wissenserwerb In der LERNET-Initiative und besonders im I-can-EIB-Projekt findet sich die APOW in der speziellen Ausformulierung „Lernen am Kundenauftrag“ wieder. Darunter verstehen wir, dass die verschiedenen Zielgruppen (Bauherren, Handwerker, Architekten und Bauingenieure) sich in das Thema EIB anhand eines konkreten Auftrags, seiner Projektierung und seiner Realisation mit Hilfe von internetbasierten Techniken einarbeiten sollen. In Zukunft soll EIB nicht nur das Akronym für den Europäischen Installations-Bus sein, sondern EIB soll für Eine Innovative Basisidee stehen. Damit wollen wir deutlich machen, dass I-can-EIB domänenunabhängig für die Wissenskommunikation einer (beliebigen) innovativen Basisidee eingesetzt werden kann. Lernziele sollten der Erwerb deklarativen und prozeduralen Wissens in der Domäne EIB sein. Besonders der Erwerb von Kompetenzen wie die Kommunikations-, Verhandlungs- und Medienkompetenz (insbesondere die Abschlusssicherheit) waren erklärte Ziele des I-can-EIB-Projektes. Damit sollte es den Nutzern leichter fallen, Innovationswiderstände abzubauen: Erst ca. 10 Prozent aller relevanten Elektrohandwerksunternehmen setzen EIB ein. Realisiert wurden die Maßnahmen mit einem erweiterten Blended-E-Learning-Konzept. Das klassische Durcharbeiten von Lernmodulen wird vermischt (blended) durch die Face-to-FaceKommunikation in Kleingruppen sowie zwischen Lernern und Tutoren mit oder ohne Vermittlung übers Internet und nicht zuletzt durch die Kommunikation zwischen virtuellen Avataren und menschlichen Lernern (z. B. im Rahmen eines internetbasierten Wissensmarkplatzes).

2.3 Struktur des Rich-Media-Systems I-can-EIB Claus Möbus und Andreas Eißner Der Informationsbedarf von kleinen und mittelständischen Unternehmen (KMU) stellt vielfältige Anforderungen an ein integriertes Informations- und E-Learningsystem. Die vorhandenen, weitgehend unstrukturierten Informationsquellen (zertifizierte Schulungsstätten mit CBT-Unterstützung, Selbststudium mit Buchunterstützung) bieten nur bedingt Hilfestellung. Bauherren, Architekten und Planern waren von diesem Angebot bisher weitgehend ausgespart. Insofern würde ein allen Zielgruppen gerechtes E-Learning- und Informationssystem – das I-can-EIB – eine Bedarfslücke schließen. Dazu wurden verschiedene Komponenten einer Architektur entwickelt, die insgesamt als Instanz eines Rich-Media-Systems angesehen werden kann (Abb. 2.3).

12

2 Das E-Learning- und Informationssystem I-can-EIB

In der Ursprungsversion handelte es sich bei Abbildung 2.3 um eine bildschirmfüllende Flash-Animation, die während des Messeauftritts auf der LearnTec 2003 in Karlsruhe den Besuchern vorgeführt wurde. Ähnlich wie der Herzschlag eines lebenden Organismus hält der „Controller“ (in der Mitte dargestellt) das gesamte System in Betrieb und steuert bzw. regelt den Informationsfluss zwischen den anderen Komponenten. Durch die animierte Darstellung des Systems konnte auch dem eiligen Messebesucher auf anschauliche Weise ein guter Einblick in das zugrunde liegende Konzept gegeben werden. So bahnt sich der Informationsfluss im Uhrzeigersinn über die Komponenten „TreeTagger“, „Chatbot-Server“ , „Wissensbasis“, „DialogGedächtnis“, „3D-Chat“ und „Avatar“ seinen Weg. Der Leser kann genauso vorgehen oder seinen persönlichen Interessen und Zielvorstellungen folgend, seinen eigenen Weg durch die Kapitel finden. Ebenso ist es durchaus möglich, ein eigenes System zu konfigurieren, in dem bestimmte Komponenten weggelassen, durch andere ersetzt oder um neue ergänzt werden. Auch die Art und Weise, wie diese Komponenten zusammengeführt werden, ist aufgrund ihrer konzeptionellen Unabhängigkeit inklusive offener Schnittstellen nicht festgelegt. Im I-can-EIB-Projekt wurde zu ihrer Integration eine Open-Source-Portal-Software eingesetzt, die in den Kapiteln 7 und 15 näher beschrieben wird. Elementar für das Verständnis des gesamten Systems ist das Kapitel 12. Es beschreibt die Simulation einer adäquaten Gesprächskompetenz. Sie fängt bei der Vorverarbeitung und -analyse der Eingabe durch den „TreeTagger“ an, geht über die Weiterleitung an den „ChatbotServer“, zur Antwortgenerierung mittels „Wissensbasis und AIML4 -Regeln“, und endet schließlich in der Persistenzhaltung in der „Dialog-Historie“. Die Kontextunabhängigkeit einiger Komponenten gilt besonders für die beiden Visualisierungskomponenten. Sie markieren das Ende und gleichzeitig auch den Anfang des Informationsflusses.

4

AIML (Artificial Intelligence Markup Language) ist ein XML-Dialekt, der es gestattet, Dialogwissen in Form von Reiz-Reaktions-Regeln zu repräsentieren. (Siehe http://www. alicebot.org/documentation/aiml-primer.htm, besucht am 5.7.2005)

2.3 Struktur des Rich-Media-Systems I-can-EIB

13

Abb. 2.3: Die Architektur des I-can-EIB-Systems (Stand Februar 2005)

Als Komponenten stellen „Avatar“ und „3D-Chat“ die Schnittstellen zwischen den menschlichen Nutzern und dem System zur Verfügung. Kapitel 11 und 19 geben einen detaillierten Einblick in die Programmierung bzw. Konfiguration des Avatars „EIBY“. Der 3D-Chat wird in den Kapiteln 13 und 20 ausführlich beschrieben. Beide Komponenten können relativ problemlos auch in anderen Umgebungen als der beschriebenen eingesetzt werden. Allerdings soll nicht verschwiegen werden, dass eine Anpassung des 3D-Chats dem Leser dieses Buches einiges mehr an softwaretechnischem Wissen abverlangt als die Konfiguration eines eigenen „EIBYs“. Soll der Avatar als zusätzliches Feature auch eine lippensynchrone Sprachausgabe spendiert bekommen, ist vorab das Studium von Kapitel 10 sehr zu empfehlen. Der Avatar EIBY5 soll die Anfangsberatung von EIB-Novizen übernehmen und der 3D-Chat in Form eines Wissensmarktplatzes die weitere Kommunikation mit Avataren für natürliche und virtuelle Nutzer, die verschiedene Rollen (Architekten, Bauherren, Handwerker etc.) annehmen bzw. annehmen können. 5

Unter einem Avatar versteht man im Allgemeinen einen Stellvertreter. EIBY wurde nicht als Stellvertreter, sondern als ein Original konzipiert. Definitorisch korrekt kann man von einem Embodied Conversational Agent (vgl. [Cassell u. a. 2000]) sprechen, wenn man mal davon absieht, dass EIBY nicht alle Merkmale (z. B. die Autonomie) eines Agenten voll erfüllt. Wir werden hier zur Sprachvereinfachung dennoch vom Avatar EIBY sprechen.

14

2 Das E-Learning- und Informationssystem I-can-EIB

Abb. 2.4: Das Portal von I-can-EIB im Internet mit EIBY und 3D-Chat

EIBY reagiert als Talking Head auf Stichwörter und natürlichsprachliche (textuelle) Anfragen, die er textuell sowie mit synthetischer Stimme beantwortet. Er hat eine autonome Ausdruckslogik, die ihm ein comicähnliches Aussehen verleiht, ohne zu anthropomorph zu sein. Von dieser speziellen Auslegung erhoffen wir, dass er „Goodwill“ für I-can-EIB erzeugt. Die Avatare des Wissensmarktplatzes lassen sich z. T. kontrollieren. Mit ihnen kann man sich wie auf einer normalen Informationsmesse anderen Rollenträgern (Avatare, die für Handwerker, Bauherren, Architekten und Ingenieure stehen) nähern und ihnen im Rahmen eines Chatsystems Fragen stellen. Ferner kann man mit Hilfe seines eigenen Avatars durch die Messeräume schlendern und die Leistungsangebote von Handwerkern und Firmen, die als berührbare Sites an den Wänden der Messeräume hängen, erkunden. Die Website von I-can-EIB mit Zugriff auf EIB-Experte EIBY und 3D-Chat (d. h. Wissensmarktplatz) findet sich in Abb.2.4 und ist jetzt unter dieser URL6 erreichbar. Uns erscheint dies – im Rahmen des Blended Learning – als ein weitgehend authentisches Abbild der Arbeitswelt, das von der Auslegung der EIB-Anlagen über deren Installation bis hin zum Funktionstest und Wirtschaftlichkeitsanalyse reicht. Wir haben damit versucht, virtuelle Realität [Bente u. Krämer 2002] zu erzeugen. Die Avatare extrahieren ihr Wissen aus den im Projekt entwickelten multimedialen Lerneinheiten bzw. deren zugrunde liegenden Drehbüchern. Um das automatische zielgerichtete Suchen nach Fachinformationen zu ermöglichen, werden die anfangs noch als „Lernschritte“ konzipierten Inhalte stark modularisiert und u. a. in einem XML-basierten Format ab6

http://www.i-can-eib.de

2.4 Prototypische Anwendungsszenarien von I-can-EIB

15

gespeichert. Somit ist auch ein einfacher Datenaustausch zwischen Avataren, EIBExperten, Multimedia-Entwicklern und Drehbuchautoren möglich. Nachdem wir die Struktur des Systems beschrieben haben, müssen wir noch prüfen, ob I-can-EIB, wie eingangs behauptet, insgesamt nicht nur ein Multimedia-, sondern darüber hinaus ein Rich-Media-System ist. Hierzu ziehen wir die Definition des National Center on Accessible Information Technology in Education der University of Washington von Rich Media zurate: The term rich media was coined to describe a broad range of digital interactive media. Rich media can be downloadable or may be embedded in a webpage. If downloadable, it can be viewed or used offline with media players such as Real Networks’ RealPlayer, Microsoft Media Player, or Apple’s QuickTime, among others. The defining characteristic of rich media is that it exhibits dynamic motion. This motion may occur over time or in direct response to user interaction. Two examples of dynamic motion that occur over time are a streaming video newscast and a stock „ticker“ that continually updates itself. An example of dynamic motion in response to user interaction is a prerecorded webcast coupled with a synchronized slide show that allows user control. Another is an animated, interactive presentation file embedded in a web page. Elements of rich media are increasingly used in education, in areas ranging from distance l earningto web-based teaching and instructional tools7 . Nach dieser Definition sind die meisten sichtbaren Komponenten von I-can-EIB rich-media, da das obligatorische Attribut „dynamic motion“auf sie zutrifft: EIBY, 3D-Wissensmarktplatz und Rich-Media-Lernmodule des bfe. Allerdings gehen wir über die Liste der aufgezählten Player hinaus, indem wir zusätzlich die Java-Runtime-Engine als Browser-Plugin und damit als Player verwenden.

2.4 Prototypische Anwendungsszenarien von I-can-EIB Claus Möbus und Claudia Janßen Im Folgenden präsentieren wir sieben prototypische Anwendungsszenarien für einen neuen EIBY und für ein neues I-can-EIB. Wir wollen Wissen über EIB (Eine Innovative Basisidee) kommunizieren und den Erwerb entsprechender Kompetenzen ermöglichen.

7

Siehe http://www.washington.edu/accessit/articles?146, letzter Zugriff am: 07.04.2005.

16

2 Das E-Learning- und Informationssystem I-can-EIB

2.4.1 Szenario 1: Optimiertes Informationsangebot einer Zielgruppe: Forum für BMW-Fans und -Fahrer

Abb. 2.5: BMW-Treff-Forum (besucht am 15.03.2005)

Einige BMW-Händler bieten auch Minis an. Versucht man an einen Mini für eine Probefahrt heranzukommen, gelangt man auch auf die Site der BMW-Fans und -Fahrer.8 Kann man hier seinen Wunsch nach einer Probefahrt mit dem Mini in vertretbarer Zeit beantwortet bekommen? Unser EIBY würde sicher die Frage komfortabel und Goodwill-schaffend beantworten können. 2.4.2 Szenario 2: Einsatz im kommunalen Bürgerservice Webseiten von Kommunalverwaltungen (Abb. 2.6, Abb. 2.79 ) bieten dem Benutzer häufig Textfenster an, in denen Suchbegriffe angeklickt oder eingegeben werden können (Abb. 2.6). Daraufhin wird dem Benutzer (hoffentlich) eine korrekte und nützliche Antwort gegeben. Jedenfalls wirken die Seiten ziemlich sachlich und nicht persönlich ansprechend.

8 9

Siehe http://www.auto-treff.com/bmw/, letzter Zugriff am: 02.05.2005. Siehe http://www.oldenburg.de/suche/index.html, besucht am 05.03.2005.

2.4 Prototypische Anwendungsszenarien von I-can-EIB

17

Abb. 2.6: Bürgerservice einer Stadt am Neckar

Abb. 2.7: Suchfenster im konventionellen Web-Auftritt der Stadt Oldenburg

Unser Konzept sieht vor, dass ein Avatar in einen bereits bestehenden Web Auftritt integriert werden kann. Dadurch wird die bisherige Online-Beratung erweitert, da neben ungewissen Freitextanfragen auch in Ansätzen (sichere) Dialoge geführt werden können. Erkundigt sich ein Bürger z. B. nach einem zuständigen Sachbearbeiter für Personalausweisangelegenheiten (zugestandenermaßen keine innovative Basisidee), könnte seitens des Avatars ein Dialog gestartet werden, der (evtl. auch ungefragt) zusätzliche Informationen liefert. Es könnte auf erforderliche Unterlagen oder gesonderte Öffnungszeiten hingewiesen werden (vgl. Abb. 2.8). Auch auf die Möglichkeit, An-

18

2 Das E-Learning- und Informationssystem I-can-EIB

träge online zu stellen, könnte der Avatar verweisen und die entsprechenden Dokumente liefern. Dem Bürger werden so unnötige Wege erspart und die Bearbeitung beschleunigt.

Einen Personalausweis können Sie im Ordnungsamt beantragen. Sie benötigen dazu ein Passfoto und…

Abb. 2.8: EIBY im elektronischen Bürgerbüro

Die bürgerfreundliche Verwaltung könnte auch aktuelle Informationen und Termine zu Veranstaltungen auf diesem Wege bekannt geben. Vielfach wäre ein Link auf eine entsprechende Webseite schon ausreichend. Die Integration des Avatars in den Web Auftritt erfordert im Vorfeld die Sammlung aller relevanten Dokumente und FrageAntwort-Paare.

2.4 Prototypische Anwendungsszenarien von I-can-EIB

19

2.4.3 Szenario 3: Einsatz im Customer Relation Management (CRM) der Unterhaltungsmedien

Abb. 2.9: Potentielles Einsatzgebiet für einen EIBY „Alles über Harald Schmidt“

Geht man auf die Website von Harald Schmidt (Abb. 2.910 ), gibt es zwar einen Button „Best of ...“, aber man kann gezielte Fragen nicht los werden. Hier würde sich der Einsatz eines Gag-Bot möglicherweise empfehlen.

10

Siehe http://www.daserste.de/haraldschmidt/bestof.asp, besucht am 05.03.2005.

20

2 Das E-Learning- und Informationssystem I-can-EIB

2.4.4 Szenario 4: Interaktives Informationsangebot einer Musikkneipe

Abb. 2.10: Webseite der Musikkneipe Charlys in Oldenburg ohne EIBY

Die Website der Musikkneipe Charlys in Oldenburg (Abb. 2.1011 ) ist ziemlich typisch für das Genre. Man ist z. B. erfreut zu sehen, dass Walter Trout am 13.04.2005 in die Stadt kam, um ein Konzert zu geben. Dabei fällt dem Surfer ein, dass Dave Hole auch schon lange nicht mehr in der Stadt weilte. Es ist aber leider nur möglich, diese Frage im Chat („Communicate“) loszuwerden und irgendwann ein nicht autorisierte Antwort zu bekommen. Auch hier könnte ein EIBY sinnvolle Dienste leisten.

11

Siehe http://www.charlys-musikkneipe.de/start.php, besucht am 05.03.2005.

2.4 Prototypische Anwendungsszenarien von I-can-EIB

21

2.4.5 Szenario 5: Informationsangebot eines Universitätsinstituts

Abb. 2.11: Webseite des Instituts für Mathematik ohne EIBY

Kommt man auf die Seite des Instituts für Mathematik (Abb. 2.1112 ), ist man überrascht über die ansprechende grafische Gestaltung mittels eines Phantasieroboters. Man könnte sich vorstellen, dass dieser Roboter „lebt und spricht“ wie EIBY.

12

Siehe http://www.mathematik.uni-oldenburg.de/, besucht am 05.03.2005.

22

2 Das E-Learning- und Informationssystem I-can-EIB

2.4.6 Szenario 6: E-Learning- und Informationsangebot einer Schule

Abb. 2.12: Website des LmTM-E-Learning-Servers ohne EIBY

Andreas Rittershofer ist ein sehr engagierter Lehrer. Seine Website (Abb. 2.1213 ) zeigt die neuesten Web Tools im Einsatz und ist somit eine Art E-Learning-Aquarium. Auch in einer derartigen Umgebung könnte sich ein EIBY wohlfühlen. 2.4.7 Szenario 7: Beratungsservice eines innovativen Großunternehmens Das schwedische Großunternehmen .K.. ist bekannt für seine manchmal schrillen TV-Clips, mit der jugendliches Publikum angesprochen werden soll. Auf der Website14 trifft man denn auch die blonde Avatarin Anna an (leider wurde uns vom Unternehmen ...A das Copyright für einen Screenshot von Anna verweigert), die für Fragen ansprechbar ist. Es wäre sicher nicht von Nachteil, wenn ein zweiter Avatar die Beratung im technischen Kundendienst übernehmen würde. EIBY wäre hier durchaus geeignet, zumal er durch seine dynamische Mimik lebendiger wirkt.

13 14

Siehe http://www.lmtm.de/, besucht am 05.03.2005. www...e..de, besucht am 11.03.2005.

3 Die Entwicklungsgeschichte von I-can-EIB Claus Möbus

3.1 Das Uni-Seminar Agenten und Avatare Die Idee, das I-can-EIB zu entwickeln, kam nicht spontan, sondern hatte eine längere Inkubationszeit in Form von Seminaren im Department für Informatik zum Thema Agenten und Avataren. Wir untersuchten 3D-Visualisierungen (vgl. [von Koenigsmarck 2000b], [von Koenigsmarck 2000a], [Vogel u. a. 1999]), Chatbots wie A.L.I.C.E. 1 , kognitive Modelle und Theorien (vgl. [Anderson 1993], [Anderson u. Lebiere 1998], [Dörner 2001]), virtuelle Agenten (vgl. [Brenner u. a. 1998], [Wooldridge 2000], [Bigus u. Bigus 2001a]), Development Kits (vgl. [Microsoft 2000]), Wissensrepräsentationsformalismen (vgl. [Helbig 2001]) und speziell die Dialogagenten mit körperlicher Erscheinung (vgl. [Cassell 2000]). Irgendwann stieg während des Abwägens, Analysierens und Bewertens die Fazittendenz so stark an, dass wir den „Rubikon überschritten“ (vgl. [Heckhausen u. a. 1987]) und selbst ein System realisieren wollten.

3.2 Der ffn-Chat Besonders ein Artikel der Agentur „less rain“ in der Dezemberausgabe 2001 der Zeitschrift PAGE gab interessante Impulse. In „The Making of: ffn-Funkhaus-Chat with FLASH & JAVA“ wird die Konzeption, die Produktion und Implementation des interaktiven 3D-Chats, der Avatare und deren Navigation beschrieben. Das virtuelle Funkhaus schwebt als 3D-Chat im Äther (Abb. 3.1), besteht aber wie ein reales Funkhaus aus mehreren Ebenen. Auf dem Screenshot ist die Sonnenterrasse mit einigen Avataren (ECON, PCM, LARA, SUNNY29 NR ONE) zu sehen. Die Avatare stellen die Verkörperung realer Chatteilnehmer oder -teilnehmerinnen im virtuellen Funkhaus dar. Will man mit einem Avatar kommunizieren, muss man 1

Siehe http://www.alicebot.org/, letzter Zugriff am: 02.05.2005.

24

3 Die Entwicklungsgeschichte von I-can-EIB

Abb. 3.1: Der ffn-Chat im Internet

sich ihm/ihr – wie im realen Leben – nähern. Allerdings kann dieser ausweichen, wenn er nicht zur Kommunikation aufgelegt ist. Sollte sich eine besondere Beziehung anbahnen, kann man auch in ein Chambre Séparée (Abb. 3.2) wechseln. Man kann seinem eigenen Avatar eine besondere Erscheinung (Gesichts-, Mund- und Antennenform etc.) verpassen, sodass man attraktiv, interessant und sympathisch erscheint. Bei besonderer Sympathie können auch noch sichtbare Herzen verschenkt werden. Im Zweierchat (Abb. 3.2) überrascht hier die EVA23 den Avatar PCM (ein Autor dieses Buches) mit dem (nicht gestellten) Vorstoß „Warum so alleine hier?“ Hier kam die Überlegung auf, ob alle Avatare ohne Ausnahme Repräsentanten realer Menschen wären. Der ffn-Chat ist ja nur attraktiv, wenn er bevölkert ist. In schwachen Besucherzeiten wäre er unattraktiv. Eine Abhilfe könnte darin bestehen, rein virtuelle Avatare zur „Auffüllung“ einzusetzen. Das muss nicht unbedingt auffallen. Man weiß vom Loebner-Contest (einem modernen Turing-Test), dass es relativ einfach ist, den Turing-Test zu passieren, wenn der Diskursbereich bizarre Antworten, Blödeleien oder Flirts zulässt (vgl. [Dennett 2004, S. 314 f.]). Wir haben diese Vermutung nicht klären können. Allerdings hat uns diese Hypothese inspiriert, sie gezielt in I-can-EIB umzusetzen. Heute sieht der ffn-Chat viel nüchterner und technischer aus. Vielleicht sind die Phantasien der Benutzer dafür umso romantischer und entrückter.

3.3 Die Vision eines internetbasierten Wissensmarktplatzes

25

Abb. 3.2: Zweiterchat „Was soll PCM jetzt EVA23 antworten ?“

3.3 Die Vision eines internetbasierten Wissensmarktplatzes Ein Teil der LERNETt-Projekte (darunter auch I-can-EIB) wurde erstmals auf dem Workshop „Qualitätsmodelle netzbasierten Lernens“ im Rahmen der LearnTec am 07.02.20022 öffentlich vorgestellt. Dabei wurden Ansätze und Modelle für praxisnahe Qualifizierungsangebote für kleine und mittelständische Unternehmen, für die Branchen Elektrotechnik und Leitungsbau sowie für öffentliche Verwaltungen präsentiert und diskutiert. Im Vordergrund stand die Entwicklung von Branchen- bzw. Poollösungen, mit denen der Aufwand für die Integration von elektronischen Lernund Informationssystemen in die betriebliche Weiterbildung deutlich verringert werden kann. Zentraler Ansatz von „I-can-EIB“ ist das „Lernen am Kundenauftrag“, d. h. die Lösung konkreter Problemstellungen in realen Handlungsszenarien. Im Sinne einer „offenen Wissenslandschaft“ (d. h. eines Kommunikationsforums oder Wissensmarktplatzes mit angedockten Lerneinheiten, Abb. 3.3) werden die Informationen für unterschiedliche Zielgruppen (u. a. Architekten (A), Bauherren (X), Handwerker (H), 2

Möbus, C.: Lernen am Kundenauftrag in einer offenen Wissenslandschaft mit Hilfe eines avatar-basierten Wissens-Chat, Vortrag im Workshop „Qualitätsmodelle netzbasierten Lernens“ auf der LearnTec, 2001.

26

3 Die Entwicklungsgeschichte von I-can-EIB

Ingenieure (I) und Hersteller (X)) zum aktiven „Abholen“ durch die Akteure bereitgestellt.

Die-Entwicklungsgeschichte.tex Abb. 3.3: Vision des I-can-EIB-Wissensmarktplatzes – LearnTec 2001

Den Anwendern stehen dabei verschiedene Lernmodule, die z. B. die Planung und den Einsatz des/der EIB per Projektion auf einen Screen vermitteln, zur Verfügung. Eine Besonderheit des Projektes ist der Einsatz virtueller Rollenträger (Avatare), die in der Kommunikationsplattform die Rolle kommunikativer Nutzer übernehmen können. Es gibt zwei Nutzergruppen: virtuelle Agenten (mit „@“-Kopf) und menschliche reale Agenten (mit „ e“-Kopf). Die virtuellen @-Agenten sollten als Lernkumpane (vgl. [Wang u. Chan 2000])verschiedene Rollen übernehmen. So können Lernkumpane „Überflieger“, „Blödmänner“, „Feinde“ oder „Freunde“ spielen. Dadurch geben sie der Lernsituation einen speziellen situativen Reiz, den man für kontextuelle Anreize nutzen kann. Nutzerspezifische Anfragen erfordern die zielgruppenspezifische Aufbereitung des E-Learning-Contents. Die Informationssuchenden erhalten auf eine Anfrage entweder eine vom System generierte (und durch Avatare vermittelte) oder eine von anderen Anwendern verfasste Antwort. Die Unterscheidung zwischen Avatar und eingeloggtem Anwender war – zumindest am Anfang des Projektes – nicht vorgesehen, d. h., der Nutzer sollte nicht erfahren, ob seine Anfrage von einer realen Person oder von einem Avatar über ein automatisch generiertes Frage-Antwort-Protokoll beantwortet wird. Wir wollten damit ein gleitendes Verhältnis von @- zu e-Avataren erreichen. In Zeiten schwachen Besucherzustroms sollten die Avatare für Kommuni-

3.3 Die Vision eines internetbasierten Wissensmarktplatzes

27

kationsdynamik sorgen. In Situationen mit regem Besucherstrom hätte man dann alle @-Avatare zurückziehen können. Dann hätten wir einen ganz normalen 3D-Chat im Wissensmarktplatz realisiert. Wir beabsichtigten damit ein nahezu uneingeschränktes Neben- und Miteinander von „künstlicher Intelligenz“ in Form von Avataren, deren Antworten standardisiert durch Plausibilitätsschlüsse aus einem Frage-AntwortPool (FAP-Pool) generiert werden, und realen Nutzern. Dies sollte den kontinuierlichen Betrieb des Forums auch zu besucherschwachen Zeiten sicherstellen. Im Forum sollte nicht zwischen Avatar und Mensch, sondern zwischen Rollen (Architekt, Produzent, Kunde etc.) und Fragestellern und Antwortgebenden unterschieden werden. Es kann sich jeder Leser des Buches und Verwender der Software ein Urteil darüber erlauben, wie weit dieses Ziel erreicht wurde. Die Abbildung 3.3 versucht diese Systemphilosopie – entsprechend dem LearnTec-Vortrag 2001 – zu konkretisieren: Es gibt Gebäude, Projektionsflächen und Avatare mit den verschiedenen Rollen Architekten, Entwickler, Ingenieuren, Handwerkern und der unbekannten Rolle X. Da auch schon am Anfang des Projektes die Problematik autonom und ohne Rückkopplung mit den Domänenexperten erzeugter Antworten klar war, wurde ein gesicherter Antwortmodus eingeplant. In diesem Modus werden nur Fragen zugelassen, zu denen eine korrekte Antwort im Sinne der Domänenexperten verfügbar ist. Die sich daraus ergebenden notwendigen konstruktiven Maßnahmen wurden uns erst mit der Zeit klar. Wir haben dann aus speziellen praxisbedingten Anforderungen (z. B. die einfache Wart- und Erweiterbarkeit) auf die zunächst gewünschte tiefe Wissensrepäsentation (in Form z. B. semantischer Netze – im Sinne z. B. [Helbig 2001] – oder Frames bzw. Frame-Logik - à la [Kifer u. a. 1995] oder [Angele u. Lausen 2004] ) zugunsten einer flachen Repräsentation von Wissen mit Antwortschablonen (in Form von Stimulus-Response-Regeln) verzichtet bzw. verzichten müssen.

4 Frage-Antwort-Systeme und I-can-EIB Claus Möbus

4.1 Einleitung Eingangs schrieben wir, dass I-can-EIB ein integriertes E-Learning- und Informationssystem über den EIB (Eine Innovative Basisidee – im Projekt instantiiert mit dem Europäischen Installations-Bus) verkörpert. Mit ihm wollen wir u. a. die Kommunikation im Web fördern. Darunter verstehen wir in unserem Anwendungsfall die computervermittelte Kommunikation zwischen „wissenshungrigen“ Menschen (Usern) und „mitteilungsfreudigen“ Experten über das EIB-Thema. Wir haben die vier Facetten der Kommunikation im Lichte der Theorie von Schulz von Thun diskutiert und reduzieren hier den Begriff der Kommunikation zwischen Agenten für die weiteren Betrachtungen auf einfache Frage-Anwort-Paare. Wir lassen damit den inhaltlichen Ablauf von Dialogen schweren Herzens außer Acht (vgl. [Wettler 1980, Kap. 9]). Das hat ganz einfach pragmatische Gründe, die mit dem State-of-the-Art der Kommunikationskompetenz technischer Systeme zusammenhängen. Wir wollen im Weiteren I-can-EIB u. a. als Frage-Antwort-System (FAS) im Sinne der KI verstehen. Mein Interesse für Frage-Antwort-Systeme (FAS) und virtuelle Agenten erwachte, als mir im Jahr 1972 das Buch Semantic Information Processing von [Minsky 1982] in die Hand fiel. Ich kämpfte gerade in meiner Dissertation mit dem abgedrehten Thema Ein Beitrag zur Metrischen und Nonmetrischen Analyse von Nichtsymmetrischen Proximitätsmatrizen mit Multidimensionalen Skalierungsmodellen. Hier aber öffnete sich eine neue faszinierende Welt. Sollte ich das Dissertationsthema hinwerfen? Viele Beiträge des Buches initiierten später eigene Forschungslinien, so z. B. Semantic Memory von M. Ross Quinlan, [Quillian 1968], A Deductive QuestionAnswering System von Fischer Black und Programs with Common Sense von John McCarthy [McCarthy 1982]. Besonders ein Artikel hatte es mir angetan. Er lautete SIR: A Computer Program for Semantic Information Retrieval von Bertram Raphael [Raphael 1982]. Mit SIR sollte ein System ... having certain cognitive abilities and exhibiting some humanlike conversational behavior [Raphael 1982, S. 33] realisiert werden.

30

4 Frage-Antwort-Systeme und I-can-EIB

(•••.EVERY BOY IS A PERSON) (I UNDERSTAND) (•••.A FINGER IS PART OF A HAND) (I UNDERSTAND) (•••.EACH PERSON HAS TWO HANDS) (THE ABOVE SENTENCE IS AMBIGUOUS •• PLEASE RE-PHRASE IT) (•••.THERE ARE TWO HANDS ON EACH PERSON) (I UNDERSTAND) (•••.HOW MANY FINGERS DOES JOHN HAVE Q) (THE ABOVE SENTENCE IS AMBIGUOUS •• BUT I ASSUME (HAS) MEANS (HAS AS PARTS)) (I DON’T KNOW WHETHER FINGER IS PART OF JOHN) (•••.JOHN IS A BOY) (I UNDERSTAND) (•••.HOW MANY FINGERS DOES JOHN HAVE Q) (THE ABOVE SENTENCE IS AMBIGUOUS •• BUT I ASSUME (HAS) MEANS (HAS AS PARTS)) ((HOW MANY FINGER PER HAND Q)) (•••.EVERY HAND HAS 5 FINGERS) (THE ABOVE SENTENCE IS AMBIGUOUS •• BUT (I UNDERSTAND)

I ASSUME (HAS) MEANS (HAS AS PARTS))

(•••.HOW MANY FINGERS DOES JOHN HAVE Q) (THE ABOVE SENTENCE IS AMBIGUOUS •• BUT I ASSUME (HAS) MEANS (HAS AS PARTS)) (THE ANSWER IS 10) (•••.HOW MANY AUTOMOBILES DOES JOHN HAVE Q) (THE ABOVE SENTENCE IS AMBIGUOUS •• PLEASE RE-PHRASE IT) (•••.WHO IS PRESIDENT OF THE UNITED STATES (STATEMENT FORM NOT RECOGNIZED) (•••.THE BOY IS JUST TO THE LEFT OF THE (G02840 IS A TABLE) (I UNDERSTAND)

Q)

TABLE)

(•••.THE LAMP IS JUST TO THE LEFT OF THE TABLE) (G02841 IS A LAMP) (THE ABOVE STATEMENT IS IMPOSSIBLE) (•••.THE TABLE IS TO THE RIGHT OF THE CHAIR) (G02842 IS A CHAIR) (I UNDERSTAND) (•••.WHAT IS THE RELATIVE POSITION OF A PERSON Q) (THE LEFT-TO-RIGHT ORDER IS AS FOLLOWS) (CHAIR (BOY TABLE))

Abb. 4.1: Beispieldialog mit SIR

SIR war der Versuch, mittels extern gegebener Informationen und Belehrungen (statements) eine symbolische Konzeptstruktur aufzubauen, die zur Beantwortung von Fragen mit fragespezifischen Algorithmen durchsucht wurde. Einige Stärken waren nach [Minsky 1982, S. 4]:

4.1 Einleitung

31

Ambiguities in the statements must be resolved when they are understood, and sometimes the system itself can do it on the basis of knowledge about how a relation has been used in the past. It is thus truly capable of using the context of „coherent discourse.“ SIRs Wissensbasis wurde nicht wie bei I-can-EIB explizit ausprogrammiert, sondern wurde mittels Supervised Learning autonom vom SIR-Agenten gelernt. Es war in der Lage z. B. den Dialog in Abbildung 4.1 zu führen. Eine Reproduktion ohne die LISP-typischen Klammern und Meldungen über neu erzeugte Objekte findet sich in [Raphael 1976, S. 198]. Da SIR zunächst kein Situationswissen enthält, musste es zuerst über die konkrete Instanz- bzw. Objektwelt informiert werden. So kommen im Dialog anfangs hauptsächlich Instruktionen vor (Abb.4.1 [Raphael 1982, S. 34]).

Instruktionsmuster

Fragemuster

(* IS *)

(IS * ?)

(* OWNS *)

(DOES * OWN * ?) (HOW MANY * DOES * OWN ?)

(* IS * PART OF *)

(IS * PART OF * ?)

(* HAS A PART ON *)

(HOW MANY * ARE PARTS OF * ?)

(THERE ARE * ON *)

(HOW MANY * ARE THERE ON * ?)

(THERE IS ONE * ON *) (* HAS *)

(HOW MANY * DOES * HAVE ?)

(* IS JUST TO THE RIGHT OF *)

(IS * JUST TO THE RIGHT OF *)

(* IS JUST TO THE LEFT OF *)

(IS * JUST TO THE LEFT OF *)

(* IS TO THE RIGHT OF *)

(IS * TO THE RIGHT OF *)

(* IS TO THE LEFT OF *)

(IS * TO THE LEFT OF *) (WHERE IS * ?) (WHAT IS THE * OF * ?)

Abb. 4.2: Satzmuster in SIR

Die Eingaben wurden mit den Satzmustern in Abbildung 4.2 verglichen. Dabei wurden die Variablen in den Satzmustern (hier mit „*“ bezeichnet) mit den entsprechenden Satzteilen gebunden, ein Konzeptgraph mit Konzeptrelationen zur Wissensrepräsentation unter Einbezug der Vererbung (ein Vorläufer der heute bekannten se-

32

4 Frage-Antwort-Systeme und I-can-EIB

mantischen Netze) aufgebaut und die Anfragen durch Suchalgorithmen beantwortet. Eine auch für die Lehre brauchbare Rekonstruktion von SIR in LISP fand sich einige Jahre später in [Shapiro 1979, Kap. 7]. Eine Schwäche von SIR waren die fragespezifischen Antwortalgorithmen, die eine Skalierung des Systems unmöglich machten. Zu jeder Frage musste ein Algorithmus entwickelt werden. Dabei stellte sich heraus, dass diese Algorithmen teilweise in Interaktion treten mussten. Das führt zu einer kombinatorischen Explosion. Auch die Verwendung von Mustern zur Erkennung der Fragesemantik kann komplex werden. Wie tückisch die Verwendung von alltagstauglichen Mustern zur Satz- und Konzepterkennung werden kann, zeigt das Beispiel Abbildung 4.3, 4.4 von [von Wendt, K. - L. 2003, S. 43]. Es bezieht sich nur auf die gängigen Möglichkeiten, Preisanfragen zu erkennen. Es wird sich zeigen, dass I-can-EIB aufgrund der praxisbedingten Anforderungen hinsichtlich Robustheit und Wartungsfreundlichkeit des FAS, Korrektheit, Nützlichkeit, Natürlichkeit (d. h. die Kooperativität) der generierten Antwort sowie der Nichtirreführung des Fragenden durch die generierte Antwort (zwangsläufig) eine andere Architektur besitzen muss, als sie das SIR-System oder z. B. deduktive FAS, wie z. B. bei [Green 1969a] und [Green 1969b] hatte. Die speziellen Anforderungen an I-can-EIB zeigen sich an den (teilweise überraschenden) Fragen, die von realen Nutzern (hier: Bauherren) an reale Domänenexperten (hier: Diplomingenieure der Elektrotechnik) gestellt wurden, und die Antworten, die sie erhielten (s. a. Abb. 4.4). Vergleicht man die Komplexität der Frage-Antwort-Paare (FAPs) in Tabelle 4.1 mit der in Abbildung 4.4 sieht man die besondere Herausforderung, denen sich alltagstaugliche FAS wie I-can-EIB stellen müssen.

Wie viel kostet X ?

Was kostet X ?

Wie viel muss ich dafür raustun ?

Was muss ich abdrücken ?

Abb. 4.3: Fragemuster zur Erkennung von Preisanfragen

4.1 Einleitung

33

((für & %WIE VIEL & (%BEKOMMEN_SYNONYME_KONJUGIERT / ((kann /können) & (kaufen /erwerben /erstehen))) & (ich /man /wir)) ~%GELD) /

für

%wie viel %Geld %Geld

%bekomme kann können

kaufen erwerben erstehen

ich man wir

?

Die Bezeichner mit Präfix % verweisen auf Untermuster

Abb. 4.4: Übersetzung eines Musterfragments in einen „einarmigen Banditen“

Die folgenden Frage-Antwort-Paare wurden während zweier Bauherrentage im bfe Oldenburg (02.02.2002 und 16.03.2002) bei Informationsveranstaltungen mitprotokolliert. Die Fragen wurden von realen Interessenten (Bauherren) gestellt und sind daher authentisch. Die Antworten sind nur unvollständig mitprotokolliert, da sie teilweise in Überbeantwortungen eingebettet waren. Diese enthielten von den Experten ad hoc assoziierte Zusatzinformationen. Tabelle 4.1: Frage-Antwort-Paare während zweier Bauherrentage in dem bfe Oldenburg

F01: Werden die 230V-Leitungen zentral oder dezentral geschaltet? A01: Ursprünglich wurden die Leitungen dezentral geschaltet, 95 Prozent aller Neubauten werden jedoch inzwischen nach Variante 2 gebaut. F02: Darf die Busleitung parallel zu den Steuerungs-/Stromleitungen verlegt werden? A02: Ja, soll sogar, durch verdrillte abgeschirmte Adernpaare und die Software ist genug Sicherheit vorhanden. F03: Werden die Elemente über den Bus mit Strom versorgt? A03: Die Elemente können über den Bus versorgt werden, dann können auf einer Busleitung aber weniger Geräte geschaltet werden. F04: Können die Fensterkontakte zentral ausgelesen werden? A04: Ja, es gibt Tasterschnittstellen mit bis zu 8 Eingängen. F05: Wie kann ich Schaltzeiten ändern?

34

4 Frage-Antwort-Systeme und I-can-EIB Tabelle 4.1: Frage-Antwort-Paare während zweier Bauherrentage in dem bfe Oldenburg

A05: Normalerweise sind in den Schaltkästen einfache Uhren, die jeder einfach verstellen kann. Es gibt jedoch auch Visualisierungsprogramme zum Schalten mit Computer, diese sind jedoch teuer. F06: Es gibt doch auch Unterputz-Schalter? A06: Ja, dann braucht man aber auch Unterputz-Aktoren. F07: Wie groß müssen dann die Dosen sein? A07: – F08: Gibt es für einen Fensterkontakt mehrere Schaltmöglichkeiten? A08: Ja, so kann man zum Beispiel die Heizkörperventile zudrehen, öffnen, Alarmanlage etc. schalten. F09: Wenn die Jalousien mal nicht um 8 Uhr, sondern erst um 9 Uhr hoch sollen, kann ich das selbst schalten? A09: Ja, das ist kein Problem. F10: Macht es Sinn, im Wohnzimmer Bustechnik zu legen, aber im Gästezimmer nicht? A10: Man muss nicht komplett in jedem Raum Bustechnik verlegen, aber ein Vorteil geht dabei verloren: komplette Kontrolle über Fenster, Licht etc. und damit sind keine echten Zentralbefehle mehr programmierbar. F11: Wenn ich nur eine Summe X zur Verfügung habe? A11: Dann auch Bustechnik, aber möglichst günstige Bauteile. F12: Gibt es auch Alternativen zum EIB? A12: Ja, aber man macht sich abhängig von einem Hersteller. F13: Gibt es die Möglichkeit, Geräte extern zu steuern? A13: Ja, über ein spezielles Gerät (Kommunikator) kann man mit dem Handy oder Notebook auf die Geräte zugreifen. F14: Inwiefern kann ich etwas abfragen? A14: Alles ist möglich, der Kommunikator kostet jedoch 1.000 e. F15: Ist damit zu rechnen, dass die Preise runtergehen? A15: Nein, die Preise sind seit Jahren stabil.

4.1 Einleitung

35

Tabelle 4.1: Frage-Antwort-Paare während zweier Bauherrentage in dem bfe Oldenburg

F16: Gibt es Schnittstellen zwischen LAN und EIB? A16: Nein. F17: Gibt es irgendwelche Normen für die EIB-Kabel? A17: Ja, die Kabel müssen geschirmt sein und mindestens 0,8 Quadratmillimeter haben. Es werden allerdings gerne grüne Leitungen genommen, da sich die EIB-Leitung dann sofort unterscheidet. F18: Kann man leicht selber etwas an dem System ändern? A18: Das ist schwierig. F19: Kann man die Programmierung selbst vornehmen? A19: Das bfe bietet einen einwöchigen Kurs an, in dem man das Programmieren lernen kann. F20: Gibt es vorinstallierte Grundmuster in der Programmierumgebung? A20: Nein, das Programmieren ist eigentlich nur Parametrisieren. F21: Warum wird die 2. Variante gewählt? A21: Die 2. Variante ist billiger, da z. B. mehrkanalige Aktoren eingesetzt werden können. Die dezentrale Lösung erfordert am Anfang zwar weniger Aufwand, ist später aber teurer, da jedes Gerät dann einen eigenen Aktor benötigt. F22: Was ist, wenn man mit einem Schalter später eine andere Lampe mitschalten möchte? A22: Der Aufwand bei Änderungen ist in Variante 2 geringer, da die Änderungen dann hauptsächlich durch die Programmierung vorgenommen werden können und nicht jedes Mal die Wand aufgerissen werden muss. F23: Wie oft gehen die Geräte kaputt? A23: In den ersten drei Monaten geht vielleicht 1 von 100 Geräten kaputt. F24: Was passiert mit den Daten bei einem Stromausfall? A24: Die Informationen sind fest in ein EEPROM eingebrannt, ähnlich dem Bios auf Mainboards, Grafikkarten etc. F25: Wie lang dürfen die Kabel des EIB-Busses sein?

36

4 Frage-Antwort-Systeme und I-can-EIB Tabelle 4.1: Frage-Antwort-Paare während zweier Bauherrentage in dem bfe Oldenburg

A25: Normalerweise benutzt man pro Etage einen Unterverteiler, da sonst die Kabel zu lang werden. F26: Wie werden die Etagen verbunden? Gibt es einen Gesamtbus? A26: Ja, die Unterverteiler sind miteinander verbunden und können von außen wie ein großes Bussystem betrachtet werden. F27: Was muss ich tun, wenn ich noch nicht alle Geräte über den EIB steuern will, mir aber die Möglichkeiten offen halten möchte? A27: In diesem Fall ist die Variante 1 zu bevorzugen. F28: Wie kommen Verwandte mit den Schaltern zurecht? A28: Für jeden Schalter kann man einen „Blödmann-Modus“ programmieren, die Tasten werden einzeln beschriftet. Über ein Kommunikationsmodul ist es sogar möglich, eine SMS zu verschicken, falls im abgeschlossenen Haus ein Schalter betätigt wird. F29: Kann ich die Heizung auch völlig frei programmieren? A29: Ja, das ist kein Problem. F30: Wie hoch sind die Kosten für ein EIB-System? A30: Die Kosten betragen 15.000 e oder mehr. F31: Wie weit kann ich das System abspecken? A31: Die Kosten für Alarmschaltung, Wohnbereichschaltung und Heizung im Wohnzimmer liegen bei 7.000 – 10.000 e. Das Bussystem ist bei gleicher Leistung 3-4 mal teurer als die konventionelle Lösung. Lichtszenen sind jedoch nicht konventionell machbar oder deutlich teurer. F32: Gibt es Probleme beim Einsatz von Geräten verschiedener Hersteller? A32: Nein, alle EIB-Systeme sind kompatibel. F33: Gibt es noch andere Bus-Systeme? A33: Es gibt nur wenige Bus-Systeme, von denen im Eigenheim-Bereich das EIB-System die größte Rolle spielt, in sehr großen Gebäuden wird LON eingesetzt. F34: Wann ist der richtige Zeitpunkt für die Planung der EIB-Installation?

4.2 Frage- und Antwort-Systeme

37

Tabelle 4.1: Frage-Antwort-Paare während zweier Bauherrentage in dem bfe Oldenburg

A34: Die Planung sollte erfolgen, bevor Kabel verlegt werden. Für die Planung reicht der Bauplan, es muss jedoch bekannt sein, wo Heizkörper und Lampen sitzen. Auf jeden Fall sollte in jedem Raum die Bus-Leitung vorhanden sein. F35: Gibt es auch EIB-fähige Heizkesselregler? A35: Gibt es, diese sind jedoch oft nicht gewünscht.

4.2 Frage- und Antwort-Systeme Wir wollten in unserem Projekt I-can-EIB ein E-Learning- und Informationssystem zur Vermittlung und Einübung von Wissen über EIB (Eine Innovative Basisidee bzw. den Europäischen Installations-Bus) realisieren, das auch dem eiligen Lerner bzw. Informationssuchenden von Nutzen ist. Es war klar, dass unser E-Learning-System ein leistungsfähiges FAS haben müsste, das nach dem Anytime-Konzept funktionierte: Give information anytime, anyone, anywhere. Wir hatten damit auch Nutzer als Zielgruppe im Auge, die nur kleine Informationslücken hatten und die keine umfassenden E-Learning-Kurse buchen wollten. Kurzum das FAS I-can-EIB sollte formelles wie auch informelles Lernen unterstützen. Zur Eingrenzung von FAS versuchen wir zunächst eine Definition für den FAProzess im FAS zu geben (vgl. [Maybury 2004, S. 3]): Question answering (QA) is an interactive human computer process that encompasses understanding a user information need, typically expressed in a natural language query; retrieving relevant documents, data, or knowledge from selected sources; extracting, qualifying and prioritizing available answers from these sources; and presenting and explaining responses in an effective manner. Wir stellen fest, dass das I-can-EIB damit eine Instanz eine QA-Systems bzw. eines FAS ist. Der am EIB interessierte Benutzer formuliert natürlichsprachliche Fragen, die er dem System und seinen Avataren bzw. anderen Nutzer präsentiert. Es werden entweder direkt Antworten gegeben oder relevante multimediale Dokumente oder Assets präsentiert. Auf Nachfragen werden dann – soweit möglich – Erklärungen generiert. Was ein FAS von einem vollständigen E-Learning-System unterscheidet, ist die in letzterem anzutreffende zusätzliche Übungsbetreuung, die zum Erwerb von Kompetenzen oder Skills notwendig ist. Bei I-can-EIB wird hier auf das bewährte Konzept des Blended Learning zurückgegriffen: Praktische Übungen finden unter Anleitung menschlicher Tutoren entweder face-to-face oder über Chats statt.

38

4 Frage-Antwort-Systeme und I-can-EIB

4.2.1 Theoretischer Rahmen von Frage und Antwort Die Beantwortung von Fragen mit Artefakten (wie z. B. Avataren) befindet sich im Schnittbereich mehrerer Disziplinen. Die Kognitionspsychologie befasst sich mit Bedingungen, unter denen Fragen bzw. Antworten akzeptabel, hilfreich oder ärgerlich sind. Wie müssen Informationen in Granularität und Menge beschaffen sein, dass sie hilfreich wirken. Die Computerlinguistik stellt u. a. Methoden der Satzanalyse und Textgenerierung zur Verfügung. Die Künstliche Intelligenz entwickelt Wissensrepräsentationsformalismen zur Inferenz und zur Verarbeitung unsicherer oder vager Informationen. Die Praktische Informatik bietet Methoden und Techniken, mit der FAS als internetbasierte Systeme realisierbar sind. FAS können – derart konzipiert – als natürlichsprachliche Schnittstellen für Datenbanken, als Assistenz- bzw. Hilfesysteme sowie als E-Learning-Systeme für inzidentelles bzw. nichtintentionales (d. h. informelles) Lernen dienen. Eine Frage ist Teil einer kommunikativen Botschaft und enthält nach dem Kommunikationswürfel von Schulz von Thun (s. a. Abbildung 2.1) vier Teilbotschaften: (1) Selbstauskunft/Offenbarung, (2) Sachinformation, (3) Beziehungsinformation und (4) Appell/Sprechakt. Ein Beispiel mit zwei unterschiedlich formulierten Fragen soll das verdeutlichen. Frage A: „Hast du schon vom Beobachtermuster im Software Engineering gehört?“ Frage B: „Hast du etwa noch nicht vom Beobachtermuster im Software Engineering gehört?“ Die beiden Fragen unterscheiden sich fundamental in den vier Komponenten ihrer Bedeutung (Tabelle 4.2). Tabelle 4.2: Unterschiedliche Semantik der Fragen A und B nach dem 4-Komponenten-Modell

Semantikkomponenten

Frage A

Frage B

Selbstauskunft / Offenba- ich habe keine Ahnung ich habe Ahnung von ... rung, von ... Sachinformation

ich möchte den Fakt wis- benötige keine Faktenwissen sen

Beziehungsinformation

Wir haben doch gemeinsa- Du kannst mir nicht das me Interessen Wasser reichen

Appell/Sprechakt

Kannst Du mir helfen?

Frisch Dein Wissen mal auf!

Wir wollen im Folgenden nur die zweite und vierte Kompontente der kommunikativen Botschaft (die Sachinformation und den Appell/Sprechakt) betrachten, weil diese am ehesten mit Informatikmethoden zu bearbeiten sind. Die erste Frage ist mehrdeutig. Sie kann eine Faktenfrage – nämlich nach dem Wissensstand des Adressaten – oder einen Sprechakt bedeuten. Die Bedeutung der zwei-

4.2 Frage- und Antwort-Systeme

39

ten Frage ist eindeutig. Es kann nur ein Sprechakt sein. Eine Antwort besteht entweder aus der angefragten Information oder aus der erwünschten Handlung. Eine Antwort auf eine Frage setzt sich zusammen aus informativen oder performativen (d. h. handlungsorientierten) Anteilen. Deshalb kann eine Reaktion des Adressaten mehrere Formen annehmen (Tabelle 4.3): (1) eine verbale oder textuelle Antwort, (2) Zusatzinformationen oder Handlungen, die wichtig für die Antwort sind, (3) Informationen oder Handlungen, die anstelle einer Antwort gegeben werden, (4) Zusatzinformationen oder Handlungen, die wichtig für den Ersatz einer Antwort sind. Durch diese Unterteilung der Reaktion des Adressaten können wir vier Reaktionstypen definieren (s. a. [Webber 1987]): Alle vier Reaktionsarten sind auf eine Frage Tabelle 4.3: Reaktionsarten auf eine Frage

direkt

Antwort

Ersatz für Antwort

(1) Information bzw. Handlung

(3) Informationen bzw. Handlung

Zusatzkomponente (2) antwortrelevante Zusatzinfor- (4) ersatzrelevante Zusatzinformatimation bzw. -handlung on bzw. -handlung

(z. B. „Wie lautet die PIN für dein neues E-Banking-Konto?“) möglich. Reaktion R1 ist eine direkte Antwort (R1: „1704“). Reaktion R2 zeigt zusätzlich eine erläuternde Handlung (R2: „Ich glaube 1704; sicher bin ich mir erst beim Eintippen“ ... tippt die Zahl ein). Reaktion R3 gibt einen Ersatz für eine Antwort (R3: „Hab gerade per Post die PIN erhalten.“). Reaktion R4 gibt wie R3 keine direkte Antwort sondern nur einen Ersatz – zusätzlich mit einer ergänzenden Information (R4: „Hab gerade per Post die PIN erhalten; werde sie aber sowieso wieder ändern, wenn das möglich ist.“). Reaktion R5 liefert ebenfalls keine direkte Antwort, (R5: „Warum fragst du? Was man nicht weiß, macht einen nicht heiß!“). Die normale Rollenverteilung (wie im I-can-EIB) sieht den menschlichen Nutzer als Fragesteller und das System als Antwortenden. Sinnvoll ist es manchmal, dass das System die Initiative ergreift und Gegenfragen stellt. 4.2.2 Fragen Welche Sorten von Fragen sind zu erwarten? In diesem Kapitel sind einige wichtige Typen aufgeführt. Weiterführende Typologien findet man z. B. bei [Helbig 2001, Kap. 3.2] und beim des USC Information Sciences Institute in Form der The ISI Question Answer Typology. Letztere Taxonomie nennt 140 Antworttypen (Qtargets) 1 gewonnen aus ca. 17.000 Fragen. Die wichtigsten Qtargets sind in Abbildung 4.5 aufgeführt: 1 Siehe http://www.isi.edu/natural-language/projects/webclopedia/Taxonomy /taxonomy toplevel.html, besucht am 07.04.2005.

40

4 Frage-Antwort-Systeme und I-can-EIB

There are several different types of qtargets: •Relational qtargets - R-CAPITAL-PLACE - What is California's capital? •Abstract qtargets - A-DEFINITION, A-WHY-FAMOUS-PERSON – Who was Jane Goodall? •Semantic qtargets - C-DATE, C-PROPER-PERSON – Who discovered America? •Syntactic qtargets - S-NP, S-VP - What did John Hinckley do to impress Jodie Foster? •Role targets - ROLE REASON - Why can't ostriches fly? •Slot qtargets - SLOT TITLE-P TRUE - Name a poem by Milton. •Lexical qtargets - LEX Berlin - What's the capital of Germany? •Combinations of qtargets - ((C-PROPER-CITY 1.0) (EQ C-PROPER-PLACE 0.8)) – Where is the Getty Museum?

Abb. 4.5: Einige wichtige Qtargets der ISI Question Answer Typology

Wir beschränken uns hier in Anlehnung an [Webber 1987] auf 4 Haupttypen: (1) Dieser Fragetyp hat den Wahrheitswert einer Aussage zum Ziel (Entscheidungsfragen nach [Helbig 2001]. Solche Fragen werden oft gestellt, um bestimmte Informationen zu erhalten, Verhaltensweisen zu initiieren oder um sicherzustellen, ob der Adressat etwas richtig verstanden hat: F16: Gibt es Schnittstellen zwischen LAN und EIB? A16: Nein. F04: Können die Fensterkontakte zentral ausgelesen werden? A04: Ja, es gibt Tasterschnittstellen mit bis zu 8 Eingängen. F02: Darf die Busleitung parallel zu den Steuerungs-/Stromleitungen verlegt werden? A02: Ja, soll sogar, durch verdrillte abgeschirmte Adernpaare und die Software ist genug Sicherheit vorhanden. Hier ist „Nein“ in A16 und „Ja“ in A04 bzw. A02 die eigentliche Antwort mit nützlicher Zusatzinformation in A04 und einer zusätzlichen Erklärung in A02. (2) Die Frage versucht zu klären, welche Individuen, Mengen, Handlungen, Ereignisse etc. eine – möglicherweise unvollständige – Beschreibung erfüllen: F23: Wie oft gehen die Geräte kaputt? A23: In den ersten drei Monaten geht vielleicht 1 von 100 Geräten kaputt. F30: Wie hoch sind die Kosten für ein EIB-System? A30: Die Kosten betragen 15.000 e oder mehr. (3) Mit diesem Fragetyp kann man versuchen, die Bedeutung eines Konzepts zu erfragen. Solche Fragen werden oft gestellt, um etwas über neue Konzepte in

4.2 Frage- und Antwort-Systeme

41

Erfahrung zu bringen oder den Antwortenden besser zu verstehen: F20: Gibt es vorinstallierte Grundmuster in der Programmierumgebung? A20: Nein, das Programmieren ist eigentlich nur Parametrisieren. Hier wird in A20 definiert, was unter Programmierung des EIB zu verstehen ist. (4) Dieser Fragetyp bezieht sich auf die Antezedenzbedingungen eines Ereignisses (Warum-Fragen): F21: Warum wird die 2. Variante gewählt? A21: Die 2. Variante ist billiger, da z. B. mehrkanalige Aktoren eingesetzt werden können. Die dezentrale Lösung erfordert am Anfang zwar weniger Aufwand, ist später aber teurer, da jedes Gerät dann einen eigenen Aktor benötigt. 4.2.3 Antworten Die Kooperativität und damit die Qualität einer Antwort bestimmt sich danach, ob sie (1) korrekt, (2) nützlich und (3) nicht irreführend ist. (1) Die Korrektheit von Antworten ist kein Problem, wenn die Welt und die Frage im Sinne von Datalog modelliert werden und die Beantwortung der Frage durch Instantiierung des Anfragemusters zustande kommt (vgl. [Ullmann 1988, Kap. 3]). F08: Gibt es für einen Fensterkontakt mehrere Schaltmöglichkeiten? A08: Ja, so kann man zum Beispiel die Heizkörperventile zudrehen, öffnen, Alarmanlage etc. schalten. Schwieriger wird die algorithmische Fragebeantwortung, wenn die Repräsentationssprache mächtiger als Datalog ist. So konnte in unserem Problemlösemonitor ABSYNT (vgl. [Möbus 1995] [Möbus u. a. 2003a]) nicht die vollständige Erkennung korrekter funktionaler Programme mittels PROLOG garantiert werden. Die Frage F kann mit zwei Antworten beantwortet werden: F: Ist dieses Programm eine korrekte Implementation des Konzepts „XYZ“? AA: JA, ich erkenne das Programm als korrekte Implementation von XYZ. AB: NEIN, ich kann dieses Programm nicht als korrekte Implementation von XYZ erkennen; das bedeutet jedoch nicht, dass das Programm nicht XYZ implementiert. Noch schlechter sieht es mit der Beantwortung von Fragen aus, wenn die Domänentheorie mittels Prädikatenlogik ausformuliert wurde (vgl. [Webber 1987, S. 816]). Die Prädikatenlogik ist nur semi-entscheidbar. Unerfüllbare Formeln können mit dem Algorithmus von Gilmore nach endlicher Zeit als solche erkannt werden; erfüllbare dagegen nicht (vgl. [Schöning 2000]). Für die Praxis ist das aber nicht entscheidend, weil jede Entscheidungsprozedur, die die Geduld

42

4 Frage-Antwort-Systeme und I-can-EIB

von Nutzern überstrapaziert (max. 15 sec) praktisch unbrauchbar ist: A decision procedure, that requires enormous amounts of time or intermediate storage is indistinguishable, in practice, from a proof procedure that never terminates for some wffs 2 [Green 1969a, S. 19]. (2) Die Nützlichkeit von Antworten hängt besonders vom Situationskontext, dem Vorwissen des Dialogpartners (hier: des menschlichen Fragestellers) und dem Wert der Antwort für eine Planerstellung ab. Das soll folgender Dialog verdeutlichen: FA: Wo ist der Etzhorner Krug? AA: In Norddeutschland AB: In Oldenburg AC: In Etzhorn AD: In Oldenburg in Etzhorn AE: 200 m von hier AF: In Oldenburg in Etzhorn, 200 m von meinem Haus in der Ernst-Löwenstein-Straße FB: Wo ist die Ernst-Löwenstein-Straße? BA: In Oldenburg in Etzhorn, 200 m vom Etzhorner Krug Die Antwort AA ist nicht sehr nützlich, weil sie kaum eine detaillierte Reiseplanung zulässt. Die Antwort AC wird geradezu als Provokation empfunden. Die Antwort AE ist wertlos, solange der Adressat den Standort des Fragestellers nicht kennt. Auch BA gilt als Provokation, wenn sie nach AF gegeben wird. Auch hier gibt [Webber 1987, S. 816] weitere Literaturhinweise. (3) Kooperative Antworten müssen zudem nichtirreführend sein. Irreführung kommt leicht vor, wenn die Antwort korrekt, aber minimal informativ ist und der Adressat diese zwar korrekte, aber minimal informative Antwort überinterpretiert. Hier ein Beispiel vom Bauherrentag. Wenn nur A14(1) gegeben worden wäre, hätten wir es mit einer Irreführung zu tun. Zur Ehrenrettung des EIB-Teams schob der Experte noch A14(2) nach. F14: Inwiefern kann ich etwas abfragen? A14(1): Alles ist möglich, ... A14(2): ,... der Kommunikator kostet jedoch 1.000 e.

2

wffs = well-formed functions

4.2 Frage- und Antwort-Systeme

43

4.2.4 Eine abstrakte FAS-Architektur

Abb. 4.6: Abstrakte Architektur eines FAS

Die Abbildung 4.6 (vgl. [Maybury 2004, S. 9]) zeigt die abstrakte Architektur eines FAS im Sinne des kleinsten gemeinsamen Nenners. Es gibt eine Reihe von Fragen (Wie?, Was? ,Wenn?, Wo?, Warum?, Wozu?, ...). Zu deren Beantwortung muss eine Reihe von Wissensquellen (Dokumente, Webseiten, Datenbasen (z. B. auch in Form semantischer Netze)) durchforstet werden. Ein FAS enthält typischerweise Module oder Komponenten zur Frageanalyse, Quellenaktivierung (z. B. auch Aktivierungsprozesse in einem Gedächtnis), Informations- und Antwortextraktion (z. B. auch eine Inferenzprozedur oder Suchalgorithmen) und zur Antwortpräsentation (z. B. auch mit Antwortschablonen). Es sollte eine Feedbackmöglichkeit zur Verbesserung der Beantwortungskompetenz geben. Für die nähere Zukunft werden FAS erwartet, die sich hinsichtlich mehrerer Dimensionen unterscheiden: (1) Benutzeradaptivität: generische Antworten für den durchschnittlichen Frager vs. maßgeschneiderte Antworten für den Fragesteller mit speziellen Bedürfnissen. (2) Semantische Tiefe der Beantwortung: Es wird nur die für den Frage „beste“ oder alle möglichen Antworten geliefert – zusätzlich noch mit einer Erklärung versehen. (3) Kontext der Antwort: Antwortschnipsel, die sich auf Entitäten (wie Leute, Orte, Zeitpunkte für Wer-, Wound Wann-Fragen) beziehen, Zitate oder ganze Dokumente mit oder ohne Erklärung.

44

4 Frage-Antwort-Systeme und I-can-EIB

4.2.5 Frühere Systeme Die Versuche, Frage-Antwortsysteme zu realisieren, gehen bis in die Anfänge der frühen 60er Jahre zurück, wie die Übersicht von Maybury (Abb. 4.7, vgl. [Maybury 2004, S. 7]) zeigt. Wir können hier aus Platzgründen nur einige wenige Beispiele kommentieren. Bert Green’s Baseball System (vgl. [Green u. a. 1961]) ermöglicht einen natürlichsprachlichen Zugang zu einer Datenbank (daher NL DB Query), mit Ergebnissen der nordamerikanischen Baseball-Liga. Es gab Antworten auf faktoide Fragen, wie z. B.: Wann?, Wo?, Wer?, Wie hoch? Die nächsten Kategorien werden von FAS gebildet, mit denen man sich über Geschichten, Zeitungsnachrichten etc. unterhalten kann (Story Q&A), die ausgefeilte Dialoge ermöglichen (Dialogue) und die durch ihre Erklärungsmöglichkeiten auffallen (Explanation). Hierzu zählt insbesondere Cordell Green’s QA3-System(vgl. [Green 1969a]), der neben Kowalski (vgl. [Kowalski 1979, S. 39 f.]). die Fragebeantwortung auf ein modifiziertes maschinelles Theorembeweisen zurückführte und Grundlagen für z. B. Ontonova im Halo-Piloten (s. u.) legte. Interessanterweise untersuchte Green in seiner Dissertation (1969) 34 Jahre vor dem Halo-Piloten (s. u.) die Beantwortung von Fragen zur Chemie (vgl. [Green 1969a], [Coles u. Green 1969]). Die Ideen von Green (besonders sein Antwortprädikat answer(X)), sind heute fester Bestandteil der Logikprogrammierung (vgl. [Schöning 2000, Kap. 3.1]). In der Kategorie Evaluation & Resources wird u. a. die TREC-Konferenz (Text Retrieval Conference3 ) erwähnt, die mit ihren seit 1992 durchgeführten Wettbewerben einen direkten Vergleich von Dokumentretrievalsystemen möglich macht. Zu den nicht hier aufgeführten Dialogsystemen, die für das Pattern-Matching des A.L.I.C.E.-System (s. u.) eine gewisse Bedeutung erlangt haben, gehört Weizenbaums Doctor bzw. besser bekannt als Eliza (vgl. [Weizenbaum 1966]).Ebenfalls aufgeführt sind die Systeme des Halo-Wettbewerbs („HaloPilot“4 ), der aber erst 2003 stattfand und den State-of-the Art widerspiegelt. Mit Halo werden wir uns im nächsten Abschnitt befassen.

3 4

Siehe http://trec.nist.gov/, letzter Zugriff am 02.05.2005. Siehe http://www.projecthalo.com/ (Website des Halo-Projekts), besucht am 19.03.2004.

4.2 Frage- und Antwort-Systeme

45

Abb. 4.7: Die Historie der FAS

4.2.6 State-of-the-Art: Der Halo-Pilot Das Projekt Halo hat aus mehreren Gründen für uns Bedeutung erlangt. Am 12.06.2003 wurde in Seattle eine Pressemitteilung mit folgendem Titel veröffentlicht: VULCAN INC. COMPLETES FIRST STEP TOWARD DIGITAL ARISTOTLE „Project Halo“ Exceeds Expectations for Automated Reasoning by Artificial Intelligence Systems. SEATTLE - June 12, 2003 - Vulcan Inc., the Seattle-based investment and project management organization founded by investor and philanthropist Paul G. Allen, today announced it has completed the first step in its long-range efforts to develop a „Digital Aristotle,“ an advanced software system enabling a tutorial application capable of delivering answers to complex questions in a wide range of domains. In response to a challenge presented by Vulcan, the initiative, dubbed Project Halo, is being developed by three teams, each a leader in the field of artificial intelligence (AI): Cycorp, Inc., Ontoprise GmbH, and a team led by SRI International comprising of SRI, University of Texas at Austin, and Boeing Phantom Works.5

5

Siehe http://www.projecthalo.com/, besucht am 12.03.2005.

46

4 Frage-Antwort-Systeme und I-can-EIB

Es stellt zurzeit den State-of-the-Art von Frage-Antwortsystemen mit expliziter Wissensrepräsentation dar. Die Philosophie des Projekts zeigt sich in den Inspirations (Abb. 4.8) 6 .

Abb. 4.8: Inspirationsquellen des Halo-Projekts

Durch seine standardisierte Aufgabenstellung in einem Wettbewerb macht es wie eine Art Rosetta-Stein verschiedene Ansätze direkt miteinander vergleichbar (vgl. [Friedland u. a. 2004b]). Alle von VULCAN ausgewählten Wettbewerber setzten im Gegensatz zu I-can-EIB auf eine „tiefe“ Wissensrepräsentation. Dadurch war es möglich, neue Antworten und Begründungen auf Fragen deduktiv zu generieren. Project Halo is a multistaged effort aimed at creating Digital Aristotle (DA), an application encompassing much of the world’s scientific knowledge and capable of answering novel questions through advanced problem solving [Friedland u. a. 2004a, S. 30]. Für unseren I-can-EIB-Ansatz stellte sich die Frage, ob wir nicht durch die verwendete „flache“ Wissensrepräsentation einen Fehler gemacht haben. Wegen der grundsätzlichen Bedeutung dieser Frage, wollen wir Halo (oder genauer gesagt den Halo-Piloten) näher darstellen und untersuchen. Erklärtes Ziel von Halo ist es, nach dem Vorbild des realen Universalgenies Aristoteles (384 – 322 v. Chr.) eine digitale Version zu schaffen, die (1) als Tutor Studenten im Sinne von Instruktionen unterrichten und (2) als interdisziplinär kompetenter Assistent Forscher bei der Arbeit unterstützen soll. Dabei soll der DA eine Weiterentwicklung der klassischen Expertensysteme (vgl. [Davis u. Lenat 1982], [Hayes-Roth u. a. 1983], [Nebendahl 1987] [Ullmann 1988]) sein, (siehe Abb. 4.8), [Friedland u. a. 2004a, S. 30]. Letztere kamen wegen ihrer beschränkten Leistungsfähigkeit in Verruf und leiteten den so genannten „KI-Winter“ ein, der jetzt aber beendet zu sein scheint. Die Zielsetzungen des DA sind mit denen von I-can-EIB weitgehend identisch. Halo-Pilot wird die erste 6-monatige Projektphase genannt, deren Ergebnisse 6

Siehe http://www.projecthalo.com/halotempl.asp?cid=80, besucht am 19.03.2005.

4.2 Frage- und Antwort-Systeme

47

jetzt publiziert wurden. Im Halo-Piloten wurden von den drei Konsortien drei FrageAntwort-Prototypen implementiert. Die Ergebnisse des Halo-Piloten zeigen, dass die Unabhängigkeit von Knowledge Engineers – eines unserer erklärten Entwicklungsziele – zurzeit liegt I-can-EIB vorne. Dafür ist seine Erklärungsfähigkeit verbesserungsbedürftig. Tabelle 4.4: Leistungsmerkmale des digitalen Aristoteles als Weiterentwicklung der klassischen Expertensysteme Klassische Expertensysteme

Digitaler Aristoteles

Speed and ease of knowledge ... required years to perfect ... will provide tools to faciand highly skilled knowledge litate rapid knowledge formuformulation engineers to craft them lation by domain experts with little or no help from knowledge engineers Coverage

... were narrowly focused on ... will over time encompass a single topic for which they much of the world’s scientific were specifically designed knowledge

Reasoning techniques

... mostly employed a single ... will employ multiple techinference technology nologies and problem solving methods

Explanations

... produced explanations de- ... will produce concise explarived directly from inference nations, appropriate to the doproof trees main and the user’s level of expertise

Die drei Konsortien wurden verpflichtet, an einer Evaluation ihrer implementierten Systeme teilzunehmen. Dazu war eine Domäne zu wählen, die für einen 6-monatigen Wettbewerb bei Verwendung einer etablierten Technik „nicht zu schwer“ ist. Damit schieden Fachgebiete mit unsicherem Wissen (wie z. B. Medizin, Psychologie, Volkswirtschaft) von vorneherein aus. Man favorisierte eine „harte“ Naturwissenschaft mit gesichertem Textbuchwissen. VULCAN entschied sich dann für die relativ einfache Domäne Chemie und hier speziell für ... a 70-page subset of introductory college-level advanced placement (AP) chemistry ... because it was reasonably self-contained and did not require solutions to other hard AI problems, such as representing and reasoning with uncertainty, or understand diagrams [Brown u. a. 2003]. This latter consideration, for example, argued against selecting physics as a domain (vgl. [Friedland u. a. 2004a, S. 30]). Das im Halo-Piloten berücksichtigte Hintergrund- und repräsentierte Fachwissen findet sich in Abbildung 4.9 [Brown u. a. 2003]. Das Fachwissen enthielt fast 100 chemische Gesetze. Es war so umfassend, dass es zur Fragebeantwortung komplexe Inferenzen notwendig machte, und so klein, dass es in 4 Monaten repräsentierbar war. Die Zeit war von VULCAN knapp bemessen worden, um Neuentwicklungen in der Technologie auszuschließen. Es sollte nur der State-of-Art und nicht die Neuentwicklungskompetenz der Konsortien evaluiert werden.

48

4 Frage-Antwort-Systeme und I-can-EIB 2. Atoms, Molecules, and Ions (background material) ch. 02.06

Molecules and Molecular Compounds (background material)

p. 049-059

ch. 02.07

Ions and ionic Compounds (background material)

p. 052-055

ch. 02.08

Naming Inorganic Compounds (background material)

p. 056-062

ch. 02.09

Some Simple Organic Compounds (background material)

p. 062-065

3. Stoichiometry: Calculations with Chemical Formulas and Equations ch. 03.01

Chemical Equations

p. 075-079

ch. 03.02

Some Simple Patterns of Chemical Reactivity

p. 080-083

ch. 03.04

The Mole (background material)

p. 087-089

4. Aqueous Reactions and Solution Stoichiometry ch. 04.01

General Properties of Aqueous Solutions

p. 113-116

ch. 04.02

Precipitation Reactions

p. 117-121

ch. 04.03

Acid-Base Reactions

p. 121-127

ch. 04.04

Oxidation-Reduction Reactions

p. 128-133

ch. 04.05

Concentration of Solutions: Molarity (background material)

p. 134

15. Chemical Equilibrium (background material) Ch. 15.02

The Equilibrium Constant: equilibrium expression (background material)

p. 580

16. Acid-Base Equilibria ch. 16.01

Acids and Bases: A Brief Review

p. 613-614

ch. 16.02

Bronsted-Lowry Acids and Bases

p. 614-619

ch. 16.03

The Autoionization of Water

p. 620-621

ch. 16.04

The ph Scale

p. 621-625

ch. 16.05

Strong Acids and Bases

ch. 16.06

Weak Acids

p. 625-627 p. 627-635

ch. 16.07

Weak Bases

p. 636-638

ch. 16.08

Relationship Between Ka and Kb

p. 639-640

ch. 16.09

Acid-Base Properties of Salt Solutions

p. 640-643

ch. 16.10

Acid-Base Behavior and Chemical Structure

ch. 16.11

Lewis Acids and Bases

p. 644-648 p. 648-653

17. Additional Aspects of Aqueous Equilibria (background material) ch. 17.02

Buffered Solutions (background material)

p. 664-670

Abb. 4.9: Verwendete Wissensquellen aus Chemistry [Brown u. a. 2003]

4.2 Frage- und Antwort-Systeme

49

Alle drei Teams hatten die gleichen Probleme zu lösen: Repräsentation von Domänenwissen in einer formalen Sprache, Übersetzung natürlich-sprachlicher Fragen in die jeweilige formale Wissensrepräsentationssprache, Beantwortung von Fragen mit formalen deduktiven Verfahren und Generierung kohärenter Erklärungen in natürlicher (englischer) Sprache. Alle setzten Wissensingenieure zur Enkodierung des Wissens und automatische Deduktionsverfahren zur Antwortgenerierung ein. Die Wissensrepräsentations- und Inferenzsprache von Ontoprise war F(rame)-Logik mit dem proprietärem Inferenzsystem Ontobroker (vgl. [Angele u. Lausen 2004],[Angele u. a. 2003]). Trotz der Ähnlichkeiten im Vorgehen unterschieden sich die Ansätze besonders bezüglich der Antwortgenerierung. Jedes System deckte einen signifikanten Teil des relevanten Lehrbuchauszug ab. Dadurch war es möglich, eine bedeutende Zahl von neuen Fragen zu beantworten. Alle Systeme enthielten eine klassenbasierte Taxonomie, um (1) Konzepte (z. B. Säuren, physikalische Konstanten oder Reaktionen), (2) Attribute von Klassen (mittels Relationen) und (3) Relationen zwischen Klassen (mittels Regeln) zu organisieren und zu ordnen. Da VULCAN nicht nur Wissen in Form des 70-seitigen Lehrbuchextrakts, sondern auch 50 Beispielfragen vorschrieb, konnten die Teams zwischen drei Vorgehensmodellen wählen: einmal – vorwärts – von der Wissensquelle zu den Fragen (targetdriven), – rückwärts – von den Fragen zur Wissensquelle (question-driven) oder jojo-mäßig vorwärts und rückwärts. Der Target-driven-Ansatz wurde von Cycorp und Ontoprise gewählt, während SRI sich für die Question-driven-Vorgehensweise entschied. Das Vorgehensmodell von Ontoprise gliederte sich in drei Phasen: (1.1) Enkodierung des Domänenkorpus in eine Ontologie F-Logic mit Klassen, Instanzen, Attributen, Methoden, Relationen, Axiomen und Regeln (vgl. [Kifer u. a. 1995], [Fensel 2001, Kap. 3.2.1], [Angele u. Lausen 2004],[Gómez-Pérez u. a. 2004, Kap. 4.3.5]), (1.2) Test des Antwortverhaltens dieser Ontologie mit den zum Wissenskorpus passenden Textbuchfragen (vgl.[Brown u. a. 2003]); (2.1) Test des Antwortverhaltens der Ontologie mit den zum Wissenskorpus passenden, aber von VULCAN formulierten Fragen; die Coverage lag hier bei 30 Prozent; (2.2) Tuning der Wissensbasis, sodass die Coverage 70 Prozent erreichte; (2.3) Enkodierung der Erklärungsregeln; (3.0) Tuning der Wissensbasis und der Erklärungsregeln. Die Vorgehensmodelle von Cycorp und SRI wichen hiervon mehr oder minder stark ab (vgl. [Friedland u. a. 2004a]). Beide Teams stützten sich bei der Entwicklung der Wissenbasis auf bestehende Ontologien von Alltags- und Wissenschaftskonzepten ab. Nur Ontoprise fing mit einer Tabula- rasa-Ontologie an. Bei Fertigstellung enthielt die Ontologie als Wurzelkonzepte nur allgemeine Chemiekonzepte wie Elemente, Gemische und Reaktionen. Bei der Erstel-

50

4 Frage-Antwort-Systeme und I-can-EIB

lung der Ontologien ließ sich nur das SRI-Team von 4 Chemikern helfen. Die beiden anderen Teams setzten nur ihre Wissensingenieure und das Textbuch von Brown ein. Auch in der Erklärungsgenerierung gingen die Teams verschiedene Wege. Ontonova – das System von Ontoprise (vgl. [Angele u. a. 2003]) – generierte Antworten mittels deduktiver Ableitungen und natürlichsprachliche Erklärungen mittels Metaregeln auf der Basis von Ableitungstraces als Datenbasis. Eine Beispielfrage soll das Vorgehen veranschaulichen (vgl. Tabelle 4.5 [Friedland u. a. 2004a, 7/6/2004, S. 11]). Darin wird nach dem Ka-Wert einer Substanz gefragt, bei gegebener Stoffmenge in Mol. In einem Logfile wird die Erstellung des Ableitungsbaums dokumentiert. Ein Eintrag dokumentiert den Zustand zum Zeitpunkt a15106 (1. Zeile der Tabelle 4.5): (1) Die Regel kavalueMPhKa wurde zum Zeitpunkt al5106 angewendet; (2) dann wurden die Variablen M und PH mit den Werten 0.2 und 3.0 instantiiert. Metaregeln zur Erklärung der Ableitung z. B. mit der Regel kavalueMPhKa liefen auf der Basis der Logfileeinträge. Eine Erklärungsregel in F-Logic, die vom Logfileeintrag in der 1. Zeile getriggert wird, findet sich in der 2. Zeile der Tabelle 4.5. Erklärungsregeln bestehen aus (1) einer Referenz auf die zugrunde liegenden Ableitungsregel (hier: kavalueMPhKa), (2) den Instantiierungen der Variablen in der Regel und (3) einem Erklärungstext, der von einem Experten formuliert wurde. Wird die Erklärungsregel (2. Zeile) durch das Logfilefakt (1. Zeile) gefeuert, wird der Erklärungstext (3. Zeile) ausgegeben. Der Vorteil dieser Erklärungsregeln liegt darin, dass sie Zusatzinformationen enthalten, die über das rein deduktiv Notwendige hinausgehen. In I-can-EIB wird die Zusatzinformation in den Antwortteil der flachen S-R-Regeln7 vom Domänenexperten automatisch und unbewusst eingesetzt. Da dem OntopriseTeam die zugestandene Zeit nicht reichte, blieben auf der Erklärungsseite einige Probleme ungelöst: (1) Integration weiteren Zusatzwissens, (2) Beseitigung von Redundanzen, (3) Abstraktion feinkörniger Erklärungen und (4) Generierung personalisierter Erklärungen. 7

Unter S-R-Regeln versteht man Stimulus-Response-Regeln (so genannte Produktionen) oder WENN-DANN-Regeln. Diese Regeln lösen bestimmte Effekte im DANN-Teil aus, wenn bestimmte Bedingungen im WENN-Teil gelten. Damit ist es möglich intelligentes Sprachverhalten im Sinne der Behavioristen SKINNER (http://www.bfskinner.org/) zu simulieren.

4.2 Frage- und Antwort-Systeme

51

Das SRI-Team ging mit von Experten formulierten Erklärungsschablonen ähnlich vor. Dagegen setzte Cycorp auf die automatische kompositionelle Generierung von Erklärungstexten. Diese Texte wirkten auf die Reviewer unnatürlich und teilweise geschwätzig, was zu Punkteabzügen bei der vergleichenden Systembewertung führte. Tabelle 4.5: Mehrstufiger Prozess einer Erklärungsgenerierung in Ontonova(vgl. [siehe Friedland u. a. 2004a, S. 11])

Logfileeintrag

al5106:Instantiation[ofRule-»kavalueMPhKa; instantiatedVars-»[i(M,0.2),i(PH,3.0),...].

Erklärungsregel für Regel kavalueMPhKa

FORALL I, M1, PH1 explain(EXl,I)  ?     "

#$ '%&%

@

  ! "  #$ %&%

 

#$ '%; %

)  :

  " @ @

 

@

  ! "  #$ %; %

 

#$ '%=%



        



    

)  :

  "

 

 

@

  ! "  #$ %=%



        


   

   

@

@ )  :

  "

 

# $ 

 " 
:B

Abb. 13.5: Ablaufdiagramm des Pattern-Matching-Algorithmus: Rauten stellen Entscheidungsstellen, Rechtecke rekursive Aufrufe und Sechsecke die Festlegung eines neuen Startknotens des Algorithmus dar

beginnt mit der Region, die zum ersten Buchstaben oder auf A.L.I.C.E. bezogen zu dem ersten Wort passt. Die Suche wird dann auf genau diese Art und Weise fortgesetzt, bis die gesuchte Phrase gefunden wurde. Somit ist der Algorithmus eine stark eingeschränkte Version der Tiefensuche innerhalb des Baums, auch als Backtracking bekannt. Bevor der Algorithmus starten kann, werden aus der Eingabe alle Satzzeichen entfernt und zuvor festgelegte Umformungen durchgeführt. Eine Sonderstellung haben in A.L.I.C.E. die Wildcards „_“ und „*“. Sie sind besondere Zeichen, die vor dem Knoten „0“ bzw. nach dem Knoten „Z“ durchsucht werden. Die Suche durch den Baum beginnt immer mit dem Teilbaum „_“, darauf folgt eine Suche durch die alphabetischen Teilbäume, und als Letztes – falls dieses auch noch nicht zum Erfolg geführt hat – wird der Teilbaum durchsucht, der mit „*“ beginnt. Die Suche wird so lange rekursiv mit dem Rest der Eingabe in dem aktuellen Teilbaum weitergeführt, bis die Eingabe endet. Begonnen wird wieder in den Kategorien, die diesen Anfang und „_“ haben, gefolgt von den Kategorien, die den Anfang und ein anderes Wort enthalten und wiederum als Letztes in den Kategorien, die den

168

13 Gesprächskompetenz im I-can-EIB-System

Anfang gefolgt von einem „*“ besitzen. Ist die Suche beendet und der gefundene Knoten ein Blatt des Baums, so wird die Antwort des Blatts ausgegeben. Die Abbildung 13.621 zeigt den Baum der Kategorien in einer Spirale, wobei die Spirale selbst die Wurzel des Baums darstellt.

Abb. 13.6: Visualisierung der geladenen Kategorien eines A.L.I.C.E.-Chatbots, die Wurzel des Kategorien-Baums entspricht der Spirale

21 Quelle: The A.L.I.C.E. Artificial Intelligence Foundation, http://www.alicebot.org, letzter Zugriff am 04.05.2005.

13.3 A.L.I.C.E.

169

Werden in den Kategorien die Tags und genutzt, verläuft die Suche durch die Pattern in der folgenden Reihenfolge (vgl. [Ringate 2001]): • • • • • • • •

atomare Pattern mit einem - und -Tag atomare Pattern mit einem -Tag Default-Pattern mit einem - und -Tag Default-Pattern mit einem -Tag atomare Pattern mit einem -Tag atomare Pattern Default-Pattern mit einem -Tag Default-Pattern

Spezielle Kategorien werden also den allgemeineren Kategorien vorgezogen. Da in A.L.I.C.E. zeitgemäße Sprache und keine abstrakten Kategorien wie „Nomen“ oder „Verb“ benutzt werden, kann das System sehr viel schneller einen unsinnigen Satz erkennen und entsprechend reagieren, als dies normale Parser können (vgl. [Rooijmans 2001]). Das Zeitverhalten ist ein nicht zu unterschätzender Aspekt bei der Kommunikation, da Benutzer schon nach wenigen Sekunden unzufrieden sind, wenn sie auf eine Antwort warten müssen, nur weil der Parser noch nicht fertig ist. Die Antwortzeit von A.L.I.C.E. wird auch bei großen Bäumen nicht zu lang, da nach Analysen von Dr. Richard S. Wallace (vgl. [Wallace 2002b]) schon mit 2000 verschiedenen Satzanfängen im Englischen wie auch in anderen natürlichen Sprachen ein Ergebnis erreicht werden kann, das den Benutzer zufrieden stellt. Für das zweite Wort im Satz genügen in diesem Fall sogar zwei Wahlmöglichkeiten im Durchschnitt, so dass die Geschwindigkeit nochmals verbessert wird. Dieses lässt sich auch sehr gut in Abbildung 13.6 erkennen. Die von Wallace durchgeführten Analysen belegen somit, dass eine Konversation genauso wie ein zusammenhängender Text dem Gesetz von Zipf (siehe [Li 1999]) folgt: Die Häufigkeit eines Wortes in einem längeren Text ist indirekt proportional zu der Rangstelle dieses Wortes in der Rangfolge. So kommt z. B. das Wort auf Platz zwei der Rangfolge ann¨’ahernd doppelt so häufig im Text vor wie das Wort auf Platz vier. Das Zipf’sche Gesetz wird auch in leichter Abwandlung für deutsche Texte von [Knüppel 2001] belegt. Die sprachlichen Ausdrucksmöglichkeiten sind prinzipiell unendlich groß, zu einem bestimmten Zeitpunkt sind allerdings nur wenige von diesen Möglichkeiten sinnvoll. Die von [Wallace 2002b] durchgeführten Analysen zeigen auch, dass 95 Prozent der Benutzeranfragen mit ca. 6000 Regeln erkannt werden, so dass der Baum eine geringe Breite behält. Das Zipf’sche Gesetz kann nicht mehr so gut angewendet werden, wenn die Anfragen an den Chatbot eher einer Anfrage an eine Suchmaschine gleichen. Das Vokabular der Anfragen an Suchmaschinen folgt laut einer von [Wang u. a. 2003] durchgeführten Untersuchung nicht mehr dem Zipf’schen Gesetz. Die Analyse von mitgeloggten Anfragen mehrerer Internet-Suchmaschinen aus den Jahren 1997 und 1998

170

13 Gesprächskompetenz im I-can-EIB-System

sowie einer Universitätsseite aus den Jahren 1997-2001 ergab, dass Suchanfragen meistens nur zwei oder drei Worte lang sind und eine sehr einfache Struktur haben. Zusammenhängende Dialoge sind für den Chatbot also einfacher in die Wissensbasis einzupflegen als unzusammenhängende Anfragen mit ihren Antworten, da für sie nur eine begrenzte Menge an Regeln nötig ist. Um das System möglichst flexibel zu gestalten, sollte jedoch für Eingaben, die Suchanfragen ähneln, ein entsprechender Suchalgorithmus in AIML programmiert oder eine externe Suchmaschine angebunden werden. Für einzelne Themengebiete lassen sich dann Kategorien schreiben, die das Themengebiet umfassend mit wenigen Kategorien abdecken. Da die Kategorien der Themengebiete dem Zipf’schen Gesetz unterliegen, kann so z. B. der gewünschte „Smalltalk“ relativ schnell realisiert werden. Der Entwickler Noel Bush hat im Jahr 2001 einen Vergleich von A.L.I.C.E. mit anderen englischsprachigen Chatbots im Internet durchgeführt (vgl. [Bush 2001]). Darunter waren Chatbots der Firmen „Virtual Personalities“, „NativeMinds“, „Kiwilogic.com“ und „Artificial Life“. Auf die Frage „Was ist der Unterschied zwischen natürlicher Sprachverarbeitung und professioneller Kosmetikwissenschaft?“ antworteten die meisten nur auf das Schlüsselwort „natürliche Sprachverarbeitung“. Die anderen umgingen die Frage und versuchten auf ihnen bekannte Themen auszuweichen. In keinem Fall erkannten sie die Frage nach einem „Unterschied“, wozu sie nicht einmal einen grammatischen Parser gebraucht hätten. A.L.I.C.E. kennt die Antwort auf diese Frage auch nicht, antwortet jedoch mit den englischen AIML-Dateien scherzhaft „Sind sie nicht gleich?“ und erscheint dadurch menschlicher. Der Aufwand, ein Pattern zu „matchen“, ist laut Dr. Wallace nur abhängig von der Länge des Wegs von der Wurzel zum korrespondierenden Blatt. Dieses dauert im Durchschnitt so viele Schritte, wie das Pattern Wörter enthält, unabhängig von der Anzahl der Kategorien im Baum. Der Algorithmus kann also mit einem Aufwand von O(1) ausgeführt werden (vgl. [Bush 2001]). Im Augenblick existiert nur eine sehr kleine AIML-Sammlung für die deutsche Sprache, in der ein wenig Smalltalk enthalten ist. Diese muss noch weiterentwickelt werden, um eine gute Akzeptanz zu erreichen. Die Programmierung der AIMLKategorien ist jedoch einfach und kann auch für die deutsche Sprache sukzessive erfolgen. 13.3.7 Tools zur Bearbeitung und Analyse von AIML-Dateien Dieser Abschnitt befasst sich mit der Bearbeitung und Analyse von AIML-Dateien. Im Anschluss an die Beschreibung der verschiedenen Log-Dateien werden die verfügbaren Tools kurz vorgestellt. Zur Unterstützung des Wissensingenieurs bei der Erweiterung und Nachbesserung der Wissensbasis gibt es verschiedene Log-Dateien. Gerade die Analyse dieser Log-

13.3 A.L.I.C.E.

171

Dateien ermöglicht es, die fehlenden oder fehlerhaften Dialoge und damit auch die AIML-Kategorien zu erkennen. Der Server schreibt für jeden Chatbot in eine Datei den gesamten Gesprächsverlauf mit allen Benutzern, bestehend aus der jeweiligen Benutzer-ID, dem Benutzernamen, der Chatbot-ID, der Ein- und Ausgabe und dem Zeitpunkt der Konversation. So können im Nachhinein komplette Dialoge analysiert und nachvollzogen werden. Für diese Datei gibt es eine Visualisierung, die mittels einer XSL-Transformation aus der XML-Datei eine HTML-Datei macht. Diese kann anschließend in jedem Browser bequem betrachtet werden. Zusätzlich wird bei eingeschalteter „Trace“-Option das gesamte Zustandekommen der Antwort in eine weitere Log-Datei gespeichert. Diese Option vereinfacht die Suche nach Fehlern gerade dann, wenn in den AIML-Kategorien häufig die Funktion eingesetzt wird. Durch Analyse der einzelnen Schritte, die bei der Antwortgenerierung ausgeführt werden, kann sehr genau der Ort des Fehlers innerhalb der AIML-Regeln bestimmt werden. In einer anderen Log-Datei werden bei eingeschaltetem „Targeting“ die Kategorien abgelegt, die mindestens ein Wildcard-Zeichen enthalten und durch eine Eingabe aktiviert wurden. In der Log-Datei werden dazu die Eingabe, die aktivierte AIMLKategorie und die Antwort des Bots gespeichert. Ein Tool, das in der Distribution von Program D22 schon mitgeliefert wird, ist das „AIML Targeting-Tool“, dessen Aufbau Abbildung 13.7 zeigt. Das Tool analysiert die Log-Datei und zeigt dem Wissensingenieur zuerst die am häufigsten aktivierte AIML-Kategorie aus den gesammelten „Targets“ an. Dieser hat nun im unteren Teil die Möglichkeit, die vorgeschlagene neue Kategorie (im Bild „new category“) zu verwerfen, einfach zu übernehmen oder sie noch an seine Vorstellungen anzupassen. Wenn er eine neue Kategorie aus dem Vorschlag bildet oder diese übernimmt, so muss er sie anschließend mit dem Button „Save Category“ speichern. Das Tool erzeugt dann eine AIML-Datei im gleichen Verzeichnis wie die Log-Datei, in der alle neuen Kategorien enthalten sind. Abschließend muss der Wissensingenieur diese neue AIML-Datei nur noch in den Chatbot einbinden, um das neue Wissen verfügbar zu machen. Der Chatbot bezieht sein Wissen also aus AIML-Dateien. Die einfachste Möglichkeit, AIML-Kategorien in die Dateien zu schreiben oder zu ändern, ist ein Texteditor, XML-Unterstützung (z. B. Syntax highlighting) oder ein richtiger XML-Editor sind jedoch vorzuziehen.

22 Program D ist die in der Programmiersprache Java geschriebene Referenzimplementierung (siehe auch Abschnitt 13.3).

172

13 Gesprächskompetenz im I-can-EIB-System

Abb. 13.7: AIML Targeting-Tool mit geladener Target-Log-Datei

Außerdem sind einige spezielle AIML-Editoren in Entwicklung, die den Wissensingenieur bei der Arbeit unterstützen sollen. Zu erwähnen sind hier „AIMLpad“23 und das Eclipse-Plugin „AIMLEditor“24 . Das Programm „AIMLpad“ ist ein AIML-Interpreter, der ursprünglich als „persönlicher Assistent“ dem Benutzer in einer Texteditor-Umgebung unter Windows dienen sollte. Das Programm bietet dem Benutzer allerdings keine Interpretation von HTML und auch keine Unterstützung von JavaScript in den Antworten. Außerdem ist das Programm noch nicht vollständig AIML-1.0.1-kompatibel. Beachtet werden sollte, dass „AIMLpad“ nicht den AIML-Interpreter aus den Bibliotheken von Program D benutzt, so dass nicht von einer 100%ig identischen Interpretation der AIMLKategorien ausgegangen werden kann. Trotzdem bietet das Programm eine einfache Möglichkeit, AIML-Kategorien zu entwerfen, zu testen und zu speichern. Insbesondere eine Funktion zum Auffinden von Duplikaten oder nicht erreichbaren Kategorien machen das Tool interessant. 23

Website von AIMLpad: http://program-n.sourceforge.net/, letzter Zugriff am 04.05.2005. AIMLEditor – Eclipse-Plugin: http://www.aitools.org/editor/userguide.html, letzter Zugriff am 04.05.2005. 24

13.3 A.L.I.C.E.

173

Das „AIMLEditor“ Eclipse-Plugin befindet sich noch in einer eher prototypischen Phase und soll später zu einem „Open Knowledge Editor“ ausgebaut werden, der den Entwickler bei der Erfassung, Verbreitung und Pflege des Wissens unterstützt. Hier bleibt abzuwarten, welche Unterstützung der Benutzer durch das Tool bekommt. Die geplanten Programmeigenschaften ähneln jedoch denen von „AIMLpad“. Eine wichtige Eigenschaft des Servers ist, dass er dynamisch AIML-Kategorien aus neuen Dateien nachladen kann. Zu diesem Zweck überwacht der Server mit der Klasse AIMLWatcher in festgelegten Zeitabständen die AIML-Dateien auf Änderungen und lädt die geänderten Dateien in den Speicher. So kann das Wissen des Chatbots erweitert werden, ohne den Server neu zu starten. Zusätzlich können auch schon vorhandene Wissensbasen in AIML integriert werden, wie z. B. eine FAQ-Liste. Liegt diese in einem XML-Format vor, so kann durch einfache XSL-Transformationen eine AIML-Datei generiert werden. In Listing 13.8 wird ein Ausschnitt der Ausgangsdatei mit den FAQ gezeigt. Listing 13.9 zeigt den entsprechenden Ergebnis-Ausschnitt in AIML, die eigentliche Transformation ist nur wenige Zeilen lang. Ein weiteres Beispiel für eine Integration vorhandenen Wissens durch Transformation ist im Abschnitt 13.4.1 beschrieben.

3 ... 4

5

6 Was heißt EIB? 7

8

9 Es heißt Europäischer Installation-Bus 10 und bezeichnet eine Technik, durch die 11 sich Gebäudefunktionen automatisieren 12 lassen (z. B. Beleuchtung, Jalousie, 13 Heizung, Klima, Sicherheitstechnik). 14

15

16

17 ... 18 1 2

Listing 13.8: Die Wissensbasis der FAQ in Form einer XML-Datei (Ausschnitt)

174

13 Gesprächskompetenz im I-can-EIB-System

3 ... 4

5

6 was heißt EIB? 7

8

9 Es heißt Europäischer Installations-Bus 10 und bezeichnet eine Technik, durch die 11 sich Gebäudefunktionen automatisieren 12 lassen (z. B. Beleuchtung, Jalousie, 13 Heizung, Klima, Sicherheitstechnik). 14

15

16 ... 17 1 2

Listing 13.9: Die FAQ-Liste als aufbereitete AIML-Datei (Ausschnitt)

13.3.8 Einbindung von Skriptsprachen in die Antwort-Templates Die Einbindung von Skriptsprachen in die Antwort-Templates gibt dem Administrator mehr Möglichkeiten bei der Beantwortung. Es sollte beachtet werden, dass natürlich auch Skriptsprachen in die Antwort integriert werden können, die erst auf dem Clientrechner ausgeführt werden, z. B. wenn das HTML-Interface benutzt wird. Hier sollen allerdings die Möglichkeiten der auf Serverseite ausgeführten Skriptsprachen untersucht werden. In den verschiedenen AIML-Interpretern werden unterschiedliche Skriptsprachen serverseitig unterstützt, darunter PHP oder auch JavaScript. Das folgende Listing 13.10 zeigt eine einfache Berechnung der Zeit und die Berechnung einfacher Rechenaufgaben auf Serverseite mit JavaScript. Zu diesem Zweck ist in den A.L.I.C.E.-Server in Program D der Rhino JavaScript-Interpreter25 der Mozilla Foundation integriert. Das Ausführen von JavaScript auf Serverseite kann über die Eigenschaft programd.javascript-allowed erlaubt oder verboten werden, so dass – wie schon erwähnt – die Sicherheit des Servers bei ausgeschaltetem JavaScript erhöht wird. Wenn wie im zweiten Beispiel für die Berechnung Daten aus der Eingabe benutzt werden, um zu einer Antwort zu kommen, so muss diese Eingabe (meist in einer Wildcard enthalten) innerhalb des JavaScripts verfügbar gemacht werden. Zu 25 Rhino – JavaScript for Java: http://www.mozilla.org/rhino/, letzter Zugriff am 04.05.2005.

13.3 A.L.I.C.E.

175

diesem Zweck wird eine Variable in Zeile 27 mit dem Wert der Wildcard initialisiert. Das XML-Element wird vom AIML-Interpreter noch vor der Ausführung des Skripts durch den Inhalt der Wildcard ersetzt. Stände das Element innerhalb des CDATA-Abschnitts, so würde entsprechend des XML-Standards die Zeichenkette verwendet und nicht der Wert der Wildcard.

3

4 WELCHES DATUM HABEN WIR HEUTE 5 Heute ist der 6

7

19

20

21

1 2

22

BERECHNE * 25

26

27 var star = ’’; 28

31

32

33

34 23 24

Listing 13.10: Aktuelles Datum und Rechenoperationen mit serverseitigem Java"-Script in AIML ermitteln (Ausschnitt)

176

13 Gesprächskompetenz im I-can-EIB-System

13.4 Wissensbasen Wie in den vorherigen Kapiteln beschrieben, wird im Projekt I-can-EIB ein dialogorientiertes E-Learning- und Informationssystem entwickelt. Der Avatar wird hauptsächlich in der Einsteigerberatung und weniger in der Fachberatung eingesetzt. Die Einsteigerberatung umfasst Fragen, die insbesondere beim Erstkontakt mit einem Thema auftreten. Der Avatar nimmt neben Stichwörtern, die der Benutzer aus einer Liste auswählen kann, auch Freitextanfragen entgegen. Er liefert Antworten in schriftlicher und gesprochener Sprache. Im Projekt wurde die Wissensbasis in zwei Blöcke geteilt, für die jeweils ein geeignetes Wissensrepräsentationsformat gewählt wurde. Die Klassifizierung der Inhalte wurde anhand des Kriteriums „Thema der Einsteigerberatung“ bzw. „Thema der Fachberatung“ vorgenommen (vgl. Abb. 13.8).

Abb. 13.8: Wissensbasen für Einsteiger- und Fachberatung

Bei dieser Charakterisierung spielt der Aspekt der „Halbwertzeit des Wissens“ eine Rolle, besonders relevant ist aber die Tiefe, d. h. der Detaillierungsgrad, der Informationen. Die Einsteigerberatung umfasst nach unserem Verständnis allgemeine Fragen, die das Thema eher in der Breite als in der Tiefe betrachten. Zur Gestaltung eines sicheren Dialoges wird der Bereich der Einsteigerberatung mit Entscheidungsbäumen realisiert. Fachfragen, die darüber hinaus gehen und wesentlich komplexere Antworten erfordern, können z. B. durch Suche in einer Dokumentenbasis beantwortet werden (vgl. Abschnitt 13.4.2). Als dritte Komponente der Wissensbasis wird im Abschnitt 13.4.3 beschrieben, wie externe Inhalte integriert werden können. Daneben ist es möglich, durch Stichwortsuche adäquate Antworten zu finden. Dieses Vorgehen wird im Abschnitt 13.4.4 beschrieben.

13.4 Wissensbasen

177

13.4.1 Einsteigerberatung Für die Qualität der Antworten des Avatars ist die Content-Strukturierung ein wesentlicher Faktor. Entscheidend für den problemlosen Einsatz eines Chatbots ist der leichte Aufbau bzw. die einfache Wartung der Wissensbasis. Gerade in der Anfangsphase des Einsatzes sind häufig Änderungen und Erweiterungen nötig, die sich z. B. aus der Auswertung der Log-Dateien ergeben. Wird der Chatbot zur Verbreitung aktueller Informationen genutzt, sind häufige Aktualisierungen ebenfalls nötig (geringe Halbwertzeit des Wissens). Im Projekt wurde eine Entscheidungsbaumstruktur gewählt und ein entsprechender Suchalgorithmus entwickelt. Der Suchalgorithmus erhält als Input die lemmatisierte Freitextanfrage (Benutzereingabe) und vergleicht diese mit Elementen des Entscheidungsbaums, um eine geeignete Antwort zu identifizieren. Die Wissensbasis sollte möglichst einfach und komfortabel durch einen Domänenexperten gewartet werden können, ohne dass spezielle Informatik-Kenntnisse erforderlich sind. Der Experte muss anhand der Struktur der Wissensbasis die Antworten des Chatbots vorhersagen können. In Bezug auf sach-/fachbezogene Themen sollen die Antworten des Chatbots keine Überraschungen liefern. Genauso soll ausgeschlossen werden, dass der Chatbot stumm bleibt. Dies kann verhindert werden, indem auch allgemeinere Antworten vorhanden sind oder zum Smalltalk gewechselt wird. Vor diesem Hintergrund wurde eine XML-Struktur der Daten in Form eines Entscheidungsbaumes entwickelt, die mit einer DTD spezifiziert wird. Die Pfade des Baumes werden durch Keywords eindeutig beschrieben und führen über mehrere Stufen schließlich zu den Blättern, in denen die konkreten Antworten auf Benutzerfragen notiert sind. In einem XML-Editor kann ein entsprechendes Dokument erstellt werden, das anschließend in ein A.L.I.C.E.-konformes AIML-Dokument (vgl. Abschnitte 13.3 und 19.2.6) transformiert wird. Der Umweg über XML erspart dem Domänenexperten die Einarbeitung in AIML. Mittels spezieller Eingabemasken in einem XML-Editor ist unter Umständen auch eine Einarbeitung in XML nicht notwendig. Ferner kann schnell und einfach durch Anpassung der Transformationsvorschrift auf Änderungen in der Struktur des Entscheidungsbaumes reagiert werden. Die Einsteigerberatung unterscheidet sich damit deutlich von der Suche in einer Dokumentenbasis. Diese Art der Antwortgenerierung könnte mittels Lucene (vgl. Abschnitt 13.4.2) realisiert werden. Dabei wird eine Antwort bzw. eine Menge von Antworten in Form von (Teil-)Texten generiert, statt vorgefertigte Antworten abzurufen. Die Ergebnisse sind deshalb vom Domänenexperten nicht mehr vollständig vorherzusagen, vor allem dann, wenn sich die Dokumentenbasis im Laufe des Avatar-Einsatzes ändert. In diesem Kapitel wird zunächst ein kurzer Überblick über Entscheidungsbäume gegeben und der Aufbau der Wissensbasis für den Bereich der Einsteigerberatung beschrieben. Ziel ist die Gestaltung eines sicheren Dialoges, der garantiert, dass immer

178

13 Gesprächskompetenz im I-can-EIB-System

eine relevante Antwort zurückgeliefert wird. In diesem Teilbereich der Wissensbasis soll sichergestellt werden, dass der Domänenexperte die Antworten des Avatars genau kontrollieren und nachvollziehen kann. Entscheidungsbäume – ein kurzer Überblick Entscheidungsbäume sind eine Methode zur (grafischen) Darstellung von Entscheidungsproblemen. Sie bilden nacheinander zu treffende Entscheidungen ab und führen schließlich zu Endpunkten, in denen das Resultat der Entscheidungen abzulesen ist. Bei der Verwendung von Entscheidungsbäumen im Projekt ist die zentrale Idee, den gesamten möglichen Output des Avatars (z. B. Antworten auf Benutzeranfragen, Beispiele oder Lernmaterialien zu einem bestimmten Thema) strukturiert zu erfassen. Durch die Beschriftung der Pfade mit Keywords wird die eindeutige Auswahl der Outputs gewährleistet. Die natürlichsprachliche Eingabe des Benutzers wird einem bestimmten Knoten, also einer passenden Antwort, im Entscheidungsbaum zugeordnet, indem die Benutzeranfrage hinsichtlich der enthaltenen Keywords analysiert wird. In unserem Ansatz gehen wir davon aus, dass eine adäquate Antwort zurückgeliefert wird, wenn genügend Keywords der natürlichsprachlichen Eingabe mit denen im Baum übereinstimmen.

Abb. 13.9: Allgemeiner Entscheidungsbaum

Das Suchen einer passenden Antwort wird also verglichen mit einem Entscheidungsproblem. Ein Entscheidungsbaum zu einem Entscheidungsproblem ist ein gerichteter

13.4 Wissensbasen

179

Baum, bestehend aus Knoten und Kanten (vgl. Abb. 13.9). Jeder Knoten (Entscheidungsknoten), mit Ausnahme der Blätter, repräsentiert eine Entscheidung. Auf dem Weg von der Wurzel bis zu den Blättern wird jeweils ein Teilproblem gelöst. Die alternativen Lösungswege werden durch Kanten beschrieben, die mit Bedingungen ausgezeichnet sind (vgl. [Claus u. Schwill 2003], [Bamberg u. Coenenberg 1996]). Anders ausgedrückt, repräsentieren innere Knoten Attribute (Attri ), deren Gültigkeit geprüft und durch den Kantenverlauf dargestellt wird. Die Blätter repräsentieren ein Element einer (Ergebnis-)Klasse (Ki ). Das folgende Beispiel zeigt den Aufbau und die Anwendung eines Entscheidungsbaumes. Ausgangspunkt ist das Entscheidungsproblem „Autokauf“. Ein Gebrauchtwageninteressent findet bei einem örtlichen Gebrauchtwagenhändler vier Autos. Zur Entscheidungsfindung notiert er die für ihn relevanten Kriterien. Demnach sind ihm die Anzahl der Sitze, der Wagentyp und das Alter des Wagens wichtig. Die vorhandenen Alternativen, d. h. die vier Autos, fasst er in einer Tabelle zusammen (vgl. Abb. 13.10). Gebrauchtwagen-ID

Anzahl Sitze

Typ

Alter

1

5

Combi

3

2

2

Sportwagen

8

3

5

Limousine

4

4

2

LKW

6

Abb. 13.10: Tabelle zur Beschreibung des Entscheidungsproblems „Autokauf“

Aus dieser Tabelle lässt sich der folgende (verkürzte) Entscheidungsbaum (Abb. 13.11) generieren, der so aufgebaut ist, dass eindeutige Pfade vorhanden sind. Der Gebrauchtwageninteressent entscheidet sich für einen Wagen mit 5 Sitzplätzen. Da er den Wagen nicht für Transporte nutzen möchte, benötigt er keinen Combi, sondern bevorzugt eine Limousine mit einem Höchstalter von 5 Jahren. Die Auswertung startet in der Wurzel („Anzahl Sitze“) und endet schließlich im Blatt „ID=3“ (vgl. hervorgehobener Pfad in Abb. 13.11). Demnach entspricht der Wagen mit der ID=3 aus dem Angebot des Gebrauchtwagenhändlers genau seinen Anforderungen. Entscheidungsbaum im Projekt I-can-EIB Im I-can-EIB-Entscheidungsbaum enthalten die Knoten Antworten auf mögliche Benutzerfragen. Die Kanten sind mit Keywords beschriftet, die mit der Benutzereinga-

180

13 Gesprächskompetenz im I-can-EIB-System

Abb. 13.11: Entscheidungsbaum-Anwendung

be verglichen werden. Ist ein Keyword in der Frage enthalten, wird dieser Pfad im Entscheidungsbaum ausgewählt. Die dazu notwendige Bearbeitung der Freitextanfrage (Lemmatisierung) ist im Abschnitt 13.3.3 beschrieben. Wie bereits erwähnt, beginnt die Auswertung an der Wurzel. Die Besonderheit im Ican-EIB-System ist, dass nicht nur die Blätter Ergebnisse einer Auswertung sein können. Sollte ein Abstieg in den Baum bis zu einem Blatt mittels Keyword-Vergleich nicht möglich sein, werden höher liegende Knoten zurückgeliefert („fallback“). Das Systemverhalten, ohne Berücksichtung zeitlicher Aspekte („Inactivity“) oder Rücksprüngen zwecks Dialogfortführung, zeigt das Aktivitätsdiagramm in Abbildung 13.12. Durch den „Fallback-Mechanismus“ wird sichergestellt, dass der Avatar immer eine Antwort geben kann. Für relativ unspezifische Knoten, die weit oben im Baum angeordnet sind, kann es empfehlenswert sein, allgemein formulierte Antworten vorzusehen. In diesen können Keywords vorgegeben werden, die den Benutzer in Richtungen lenken, die einen tieferen Abstieg in den Baum ermöglichen. Grundsätzlich ist der Fokus der Fragebeantwortung auf das Fachthema gerichtet. Ist es dem Avatar auch nach einer Nachfrage nicht möglich, eine adäquate Antwort zu liefern, wird in Smalltalk gewechselt. Es ist aber vorgesehen, dass relativ schnell wieder zum Fachthema gewechselt wird. Der Fragebeantwortungsalgorithmus sieht auch die Gesprächsfortführung (Proaktivität des Avatars) vor. Dabei registriert der Avatar die Zeit seit der letzten Benutzereingabe. Nach einer definierten Mindestwartezeit wird er aktiv, indem er an das aktuelle Thema anknüpft und weitere Informationen dazu anbietet. Zur Realisation der Proaktivität haben die Antwortknoten im Entscheidungsbaum optionale Geschwisterknoten, die Beispiele, weiterführende Erklärungen oder Verweise auf relevanten Content aus dem Lernsystem enthalten.

13.4 Wissensbasen

181

natürlichsprachliche Benutzeranfrage Fokus setzen: Einsteigerberatung Keyword-Suche zur Topic-Group-Identifikation [Keyword-Match nicht erfolgreich] [Keyword-Match erfolgreich]

Fokus setzen: Smalltalk

Smalltalk

Topic Group mit Antworten auswählen Keyword-Suche zur Topic-Identifikation [Keyword-Match nicht erfolgreich] [Keyword-Match erfolgreich]

Allg. Antwort „EinsteigerBeratung“ ausgeben

Topic mit Antworten auswählen

Keyword-Suche zur Antwort-Identifikation [Keyword-Match nicht erfolgreich] [Keyword-Match erfolgreich]

Topic-Group-Antwort ausgeben

Topic-Antwort ausgeben

Abb. 13.12: Aktivitätsdiagramm: Fragebeantwortung

Die folgenden Abschnitte beschreiben die Content-Erfassung und die Entscheidungsbaum-Generierung. Besonderes Augenmerk wird dabei auf die Generierung der Keywords gelegt. Aufbau der Wissensbasis: Content-Erfassung Die Wissensbasis für den Bereich der Einsteigerberatung besteht aus einer Sammlung von Frage-Antwort-Paaren (FAP). Die Domänen-Experten (EIB-Experten) haben wegen ihrer umfangreichen Erfahrungen in Kundengesprächen, Informationsveranstaltungen oder durch Lehrveranstaltungen ein großes Repertoir von Frage-

182

13 Gesprächskompetenz im I-can-EIB-System

Antwort-Paaren zusammenstellen können. Weil im Drehbucheditor bereits entsprechende Eingabefelder vorgesehen sind, konnte das oftmals parallel zur Drehbuchentwicklung (vgl. Kapitel 15) geschehen. Alle gesammelten Fragen wurden von uns kategorisiert, wobei sich als Hauptkategorien die Bereiche Allgemein, Contra, Pro, Definitionen und Kosten herausgebildet haben. Die Bereiche fassen jeweils Fragen zusammen, die einen abstrakteren Themenblock betreffen. Der Bereich Allgemein umfasst z. B. Fragen, die sich auf die Bezeichung EIB, Hersteller, Lieferanten oder Einsatzmöglichkeiten beziehen. Andere Fragen ließen sich den spezielleren Themen wie Pro- oder Contra-Argumente, technischen Definitionen oder dem Kostenaspekt zuordnen. • Allgemein – Einsatzmöglichkeiten • Contra – Installationsaufwand • Pro – Komfort – Sicherheit – Energie • Definitionen – Allgemeine Definitionen – Technische Definitionen – Definitionen zur Installation • Kosten – Installationskosten Zur weiteren Differenzierung wurden diese Hauptkategorien weiter unterteilt. So wurde z. B. die Kategorie Pro in die Punkte Komfort, Sicherheit und Energie zerlegt. Ein Frage-Antwort-Paar aus dem Bereich Sicherheit bezieht sich z. B. auf die unerlaubte Einflussnahme auf die EIB-Installation eines Wohnhauses, etwa durch Steuerung der Alarmanlage: Frage: Wie sicher ist die Anlage? Können Fremde auf mein Haus zugreifen? Antwort: Hinsichtlich der Sicherheit gibt es natürlich keinen hundertprozentigen Schutz. Ein Zugriff auf die Anlage durch Außenstehende wird aber durch folgende Daten verhindert: die reservierte Telefon-Nr., die PIN-Nr. und die Funktion der unterschiedlichen Datenpunkte. Wie sollte jemand all diese Dinge erraten? Der so entstandene Entscheidungsbaum wurde von uns um zusätzliche Knoten erweitert. Diese Knoten enthalten Antworttexte für höhere Ebenen im Baum oder zu einer Antwort passende Erklärungen und Beispiele. Zur Realisierung der Proaktivität des Avatars werden „Inactivity“-Texte erfasst und evtl. auf Inhalte aus dem Lernsystem verwiesen („Inactivity“-Links).

13.4 Wissensbasen

183

Aufbau der Wissensbasis: Entscheidungsbaumerstellung Es wurde eine DTD entwickelt, die für den zusammengetragenen Content eine Entscheidungsbaumstruktur vorgibt.

3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 2

Listing 13.11: DTD für den Entscheidungsbaum

Die Antworten sind mit Metadaten (Keywords) ausgestattet, welche die Grundlage für den Suchalgorithmus bilden (vgl. auch Abb. 13.12). Auf die KeywordGenerierung wird deshalb später genauer eingegangen. Im Folgenden wird die DTD (Listing 13.11) genauer beschrieben und beispielhaft ein Ausschnitt aus dem I-can-EIB-Content betrachtet. Als oberstes Element (root-Knoten) des Entscheidungsbaumes (Listing 13.11) wird das Element Anfangsberatung eingefügt. Die Anfangsberatung setzt sich aus einer beliebigen Anzahl von Topic Groups zusammen. Topic Groups umfassen jeweils einen größeren Themenbereich, der differenzierter betrachtet werden kann, indem er in Topics unterteilt wird. Topic Groups und Topics werden die Elemente Topic Name, Antworttext, Inactivity, und Keywords zugeordnet. Topic Groups enthalten zusätzlich eine beliebige Anzahl des Elements Antwort. In diesem Element werden Frage-Antwort-Paare erfasst.

184

13 Gesprächskompetenz im I-can-EIB-System

Um eine Dialogfortführung zu ermöglichen, werden den Antworten Beispiele, weitere Erklärungen und Inactivity-Elemente zugeordnet. Die Elemente werden mit Metadaten (Keywords) angereichert, die wie oben beschrieben zur Frageanalyse herangezogen werden. Das Element Antworttext ist nicht nur im Element Antwort enthalten, sondern kann auch den Elementen Topic Group und Topic zur Realisierung des „Fallback“Mechanismus zugeordnet werden. Die Abbildung 13.13 stellt die Entscheidungsbaumstruktur der DTD grafisch dar. Es sind zwei alternative Topic-Groups angedeutet, deren Zahl beliebig erhöht werden kann. Ebenso können andere Tags (z. B. Antworten) hinzugefügt werden. Das Listing 13.12 zeigt einen Ausschnitt (Frage-Antwort-Abschnitt) aus einer XMLDatei, die dieser DTD entspricht. Von Domänenexperten wurden Frage-AntwortPaare mit einem XML-Editor zur Topic Group „Pro“ erfasst.

13.4 Wissensbasen


   

   

 


   



  



 


   



  


      


   



  

  

   






!" 

Abb. 13.13: Entscheidungsbaum gemäß I-can-EIB-DTD

185

186

13 Gesprächskompetenz im I-can-EIB-System

3 4

5 Pro 6 Der EIB bietet eine Reihe von Vorteilen. Sie lassen sich u. a. in die Bereiche Komfort, Sicherheit oder Energie differenzieren. Haben Sie dazu Fragen? 7 ... 8

9 Sicherheit 10 ... 11

12 Sicherheit 13

14

15 Wie sicher ist die Anlage? Koennen Fremde auf mein Haus zugreifen? 16 Hinsichtlich der Sicherheit gibt es natuerlich keinen hundertprozentigen Schutz. Ein Zugriff auf die Anlage durch Außenstehende wird aber durch folgende Daten verhindert: die reservierte Telefon-Nr., die PIN-Nr. und die Funktion der unterschiedlichen Datenpunkte. Wie sollte jemand all diese Dinge erraten ? 17 ... 18

19

20 unerlaubter Zugriff 21 Telefon-Nr 22 Pin-Nummer 23 ... 24

25 ... 26

27

28 1 2

Listing 13.12: Content für die Anfangsberatung

13.4 Wissensbasen

187

In der Abbildung 13.14 ist das Frage-Antwort-Paar zur Veranschaulichung noch einmal den Elementen des Entscheidungsbaumes zugeordnet. Zusätzlich sind die Pfade mit einigen Keywords ausgezeichnet, um auf die Pfadauswahl mittels KeywordVergleich hinzuweisen.

Abb. 13.14: Entscheidungsbaum: Ausschnitt aus I-can-EIB-Content

188

13 Gesprächskompetenz im I-can-EIB-System

Ein schwieriger und wichtiger Schritt ist die Auswahl geeigneter Keywords. Da diese mit der Benutzereingabe verglichen werden, ist die Auswahl und Qualität der Antworten direkt davon abhängig. Die Keyword-Generierung findet im Projekt im Rahmen der Content-Erstellung statt. Es existieren dabei grundsätzlich zwei Möglichkeiten, die Keywords zu erfassen und anschließend auf Eindeutigkeit und Adäquatheit zu testen. Eine Möglichkeit besteht darin, aus dem Content automatisch alle Substantive und Eigennamen zu extrahieren. Eine zweite Möglichkeit ist die explizite Angabe der Keywords vom Domänenexperten. Der Vorteil dabei ist, dass diese Keywords nicht ausschließlich auf die „übliche Fachkonzept-Ontologie“ ausgerichtet sind, sondern sich wesentlich näher an den Formulierungen der Benutzer orientieren. Die Erfassung der Keywords (und auch des gesamten Contents) kann mit Unterstützung von Ontologie-Tools oder alternativ mit einfach gestalteten Eingabemasken eines beliebigen (XML-)Editors vorgenommen werden. Im Projekt wurde auf die Anbindung von Frontends verzichtet. Beispielhaft haben wir einen Ausschnitt des Contents mit dem Tool Protégé26 erstellt.

Abb. 13.15: Protégé: Class Browser

26

Siehe http://protege.standord.edu, letzter Zugriff am 26.02.2005.

13.4 Wissensbasen

189

Der Content kann in Protégé in Form einer Ontologie im Class Browser (vgl. Abb. 13.15) aufgebaut werden. Es werden die Klassen (Konzepte), deren Attribute und Relationen erfasst. Im Instance Editor (vgl. Abb. 13.16) werden Instanzen der Klassen erzeugt.

Abb. 13.16: Protégé: Instance Editor

Protégé unterstützt Abfragen (Queries), die in diesem Fall zur Überprüfung von Eindeutigkeit und Adäquatheit der Keywords genutzt werden können. Die Durchführung ist recht einfach und zielgerichtet möglich, da die Wissensstruktur einsichtbar ist. Beispielhaft haben wir eine Anfrage Suche Antwort (vgl. Abb. 13.17) definiert. Dabei werden die Keywords der Topic Group und eines Topics mit einem Teil der fiktiven Benutzereingabe („unerlaubter Zugriff“) verglichen. Die Anfrage-Ergebnisse können exportiert und weiterverarbeitet werden. Ebenso ist eine Tool-Anbindung mittels API möglich. Es ist zu bedenken, dass der Benutzer seine Anfragen später nicht innerhalb dieser Tool-Umgebung mit offen gelegter Wissensbasis, sondern indirekt über den Avatar stellt. Bei der Nutzung der Freitextanfrage kennt er die Wissensbasis nicht. Lediglich die Stichwortliste gewährt einen Einblick in einen Ausschnitt der Wissensbasis.

190

13 Gesprächskompetenz im I-can-EIB-System

Der Benutzer wird im Freitextmodus mit dem Problem konfrontiert, die passenden Stichwörter zu „erraten“, die ihm die gewünschte Antwort liefern. Dieses Problem kann minimiert werden, indem die Pfade des Entscheidungsbaumes mit einer hinreichend großen Menge von Keywords ausgezeichnet sind. Der entscheidende Vorteil ist, dass der Domänenexperte genau kontrollieren kann, welche Keywords zu einer bestimmten Antwort führen. So sollten „Überraschungen“ ausgeschlossen sein. Diese Kontrolle wäre nicht möglich, wenn die Generierung der Keywords automatisch durchgeführt würde.

Abb. 13.17: Protégé: Query

Nach Abschluss der Content-Erfassung werden die XML-Files mittels XSLT (Extensible Stylesheet Language Transformations), einem Standard für textbasierte Transformation27 , in das A.L.I.C.E.-konforme Format AIML (vgl. Abschnitt 13.3.5) transformiert. Die AIML-Dateien werden in das A.L.I.C.E.-System integriert. Der Vorteil dieser Trennung ist, dass der Domänenexperte nicht die Implementation des Avatars kennen muss, um den Content zu aktualisieren.

27

Siehe http://www.w3.org/TR/xslt, letzter Zugriff am 26.02.2005.

13.4 Wissensbasen

191

13.4.2 Information-Retrieval-Systeme In diesem Kapitel wird ein Ansatz aus dem klassischen Information-Retrieval (IR) vorgestellt, der auf der Grundlage vorhandener Textdokumente relevante Dokumente zu einer Anfrage auswählt. Anhand der IR-Bibliothek Lucene werden die Möglichkeiten eines IR-Systems zur Beantwortung von Fragen aufgezeigt und mögliche Erweiterungen in Bezug auf Lucene angedacht. Bei einem wissensbasierten Ansatz (wie z. B. im Abschnitt 13.4.1 dargestellt) wird eine Wissensbasis benötigt. Dafür müssen die gewünschten Informationen extrahiert und mit einer ausgewählten Repräsentationsmethode in der Wissensbasis abgebildet werden. Für die Erstellung einer Wissensbasis sind Experten notwendig, die genaues Wissen zum Fachgebiet besitzen, um so eine korrekte Darstellung der Informationen in der Wissensbasis zu gewährleisten. Hier soll ein Ansatz dargestellt werden, der nur auf den tatsächlich vorliegenden Dokumenten arbeitet. Der Vorteil von diesem Ansatz ist, dass automatisiert Wissen ohne weitere Wartung bereitgestellt werden kann. Im klassischen Information-Retrieval gibt es verschiedene Techniken, mit denen Informationen aus Texten gewonnen werden. Obwohl Texte grundsätzlich hierarchisch klassifiziert werden können, ist diese Methode des IR nicht immer effizient genug. Große Datenmengen machen diese Methode unbrauchbar, da der Benutzer durch lange Reihen von Kategorien und untergeordneten Kategorien navigieren muss, bis er zu dem gewünschten Dokument gelangt. Der in diesem Abschnitt beschriebene Ansatz geht einen anderen Weg: den Einsatz einer statistischen Suchmaschine. Ein zentraler Aspekt aller Suchmaschinen ist das Konzept der Indexierung. Diese muss durchgeführt werden, um aus den Originaldaten eine effizientere Datenstruktur zum Suchen zu generieren. Die Indexierung wird typischerweise zu Beginn und bei Änderungen des Suchraums durchgeführt. Der Index wird benötigt, um nicht bei jeder Suche alle Dateien nach der gesuchten Zeichenfolge zu durchsuchen. Je größer die Anzahl der Dateien, desto ineffizienter wäre dieser Vorgang. Der Index stellt dabei ein Datenformat dar, das von einem Suchalgorithmus sehr viel schneller durchsucht werden kann, so dass die sequentielle Suche nicht mehr benötigt wird. Die Suche ist ein Prozess, der in einem Index Wörter nachschlägt und somit die Dokumente, die diese Wörter enthalten, liefert. Die Qualität der Suche hängt von mehreren Faktoren ab: Präzision bei der Aussortierung nicht relevanter Dokumente, Suchgeschwindigkeit, Unterstützung von mehreren Termen und deren Verknüpfungen sowie eine einfache Syntax zur Eingabe der Suchanfragen. Im Folgenden wird die Integration einer Suchmaschine als Wissensbasis anhand eines Beispiels vorgestellt: dem Apache Jakarta-Projekt Lucene.

192

13 Gesprächskompetenz im I-can-EIB-System

Lucene Lucene ist eine hoch performante skalierbare IR-Bibliothek, durch die andere Applikationen mit Suchfunktionalität erweitert werden können. Sie gehört seit dem Jahr 2001 zu den Projekten der Apache Jakarta-Familie, die alle unter einer Open-SourceLizenz stehen, und wurde in Java implementiert. Die im Folgenden beschriebenen Eigenschaften von Lucene basieren auf der Version 1.4.3 vom November 2004. Seit Lucene zu den Projekten der Apache Software Foundation gehört, zählt es zu den am meisten eingesetzten IR-Bibliotheken im Java-Umfeld. Lucene bietet ein einfaches, aber effektives Java-API, für das nur ein minimales Verständnis von grundlegenden Vorgängen, wie z. B. Volltextindexierung und allgemeinen Suchmethoden, vorausgesetzt wird. Zeitgleich werden verschiedene Portierungen von Lucene vorangetrieben. Zurzeit existiert die Bibliothek zusätzlich in den Sprachen Perl, Python, C++, .NET und Ruby. Lucene ist keine fertige Applikation, sondern wie schon erwähnt eine Bibliothek. Verschiedene Applikationen wurden mit Hilfe von Lucene realisiert, so z. B. Zilverline, Nutch und LARM (eine Liste der Projekte, die Lucene einsetzen, ist auf der Webseite von Lucene zu finden28 ). Der Entwickler wird von Lucene bei der Erstellung einer Suchfunktion unterstützt, indem es einen Index und eine Umgebung zur Suche für alle Daten zur Verfügung stellt, die in ein Textformat umgewandelt werden können. So kann z. B. auch dann eine Suchfunktion für Texte in Datenbanken realisiert werden, wenn die Datenbank dieses selbst nicht unterstützt. Indexierungsvorgang Der Index von Lucene besteht aus Dokumenten und evtl. anderen Lucene-Indexen. Die Dokumente sind nicht die Originaldokumente, sondern abstrakte Objekte, die Felder mit Werten (z. B. Worte, Zahlen oder die URI eines Originaldokuments) enthalten. Durch das Konzept der Felder innerhalb von Dokumenten können neben dem eigentlichen Text auch weitere Metadaten wie z. B. der Name des Autors oder das Erstellungsdatum zu dem Dokument erfasst werden. Die Möglichkeiten der Suche werden dadurch verfeinert. Ein Dokument im Lucene-Index besteht (siehe auch Abb. 13.18) also aus mehreren Feld-Wert-Paaren. Sowohl das Dokument selbst als auch die einzelnen Felder können mit einem speziellen „Boost-Faktor“ versehen werden. Dieser bewirkt je nach Wert eine positive bzw. negative Verstärkung der Relevanz dieses Dokuments oder Felds. 28 Wiki des Projekts Lucene: http://wiki.apache.org/jakarta-lucene/PoweredBy, letzter Zugriff am 06.05.2005.

13.4 Wissensbasen

193

Die Felder eines Dokuments können mit drei verschiedenen Attributen markiert werden: indexed, tokenized und stored. Ist das Attribut indexed für ein Feld gesetzt, kann es von Lucene durchsucht werden. Felder die nicht durchsucht werden dürfen, können durch Nichtsetzen dieses Attributs geschützt werden. So kann es z. B. sinnvoll sein, die Suche nach der zu einem Namen gehörenden Telefonnummer innerhalb eines Telefonbuchs zuzulassen, nicht jedoch die Umkehrung: die Suche nach einem Namen anhand einer Telefonnummer. Ein weiteres Feld-Attribut ist tokenized. Ein Feld, bei dem dieses Attribut gesetzt ist, wird vor dem eigentlichen Indexierungsvorgang durch eine Aufbereitungsphase geschickt. Die Aufbereitung der Daten erfolgt, um bestimmte Worte aus den Dokumenten zu filtern oder diese zu bearbeiten und wird später noch genauer erläutert. Ist das Attribut stored gesetzt, so wird nicht nur die indexierte Form des Textes gespeichert, sondern auch der Originaltext selbst. Da in dem Feld durch die Aufbereitungsphase zumeist nicht mehr der Originaltext steht, ist es für die Ergebnispräsentation sinnvoll, den Originaltext auch im Index zu speichern. Der Vorteil der direkten Speicherung im Index wirkt sich jedoch auf die Performance des Systems aus, da für den Index nun mehr Speicher benötigt wird. Ansonsten muss der Originaltext für die Ergebnispräsentation erneut eingelesen und analysiert werden. Welche Lösung im Einzelfall zu bevorzugen ist, hängt von der Textmenge, der Anzahl der Anfragen zu einem Zeitpunkt sowie der eingesetzten Hardware ab. In den meisten Fällen liegen die Daten nicht nur in einem Format vor, was die Konvertierung in ein einheitliches Dokumentenformat notwendig macht. Wie schon erwähnt, benötigt Lucene für die Indexierung Daten im Textformat. Für die Extraktion des Textes aus verschiedenen Formaten wie z. B. XML, PDF oder RTF stehen verschiedene Dokument-Konverter zur Verfügung. Eine Liste dieser Konverter befindet sich auf der Projekt-Website unter den Beiträgen29 . Die Erstellung des Indexes besteht also aus den folgenden Schritten: Text extrahieren (gegebenenfalls mit einem Konverter), Text analysieren und Text indexieren. Schon bei der Extraktion kann es sinnvoll sein, nur bestimmte Textpassagen zu extrahieren. Dieses ist natürlich bei einem gut strukturierten Format wie XML am leichtesten und kann dort z. B. mit Digester, aber auch mit jedem anderen XML-Parser für Java erfolgen. Eine ausführliche Anleitung zur Extraktion mit Digester und anschließender Indexierung mit Lucene ist in dem Artikel „Parsing, indexing, and searching XML with Digester and Lucene“ [Gospodneti 2003] zu finden. Für das Projekt I-can-EIB kamen die folgenden Daten aus den XML-Dokumenten in Frage: Frage-Antwort-Paare, Sprechertexte, Schlüsselwörter und Bildunterschriften. Wie in Abbildung 13.18 in der Visualisierung durch Luke30 zu sehen ist, wurden in einem ersten Ansatz nur die Frage-Antwort-Paare mit zugehörigen Metadaten extrahiert und einzeln im Lucene-Index als Dokument abgelegt. 29

Beiträge zum Projekt Lucene: http://jakarta.apache.org/lucene/docs/contributions.html. Luke – Lucene Index Toolbox: http://www.getopt.org/luke/, letzter Zugriff am 06.05.2005. 30

194

13 Gesprächskompetenz im I-can-EIB-System

Abb. 13.18: „Lucene Index Toolbox“ Luke: Felder eines Dokuments

Im nächsten Schritt wird der extrahierte Text analysiert. Lucene stellt zu diesem Zweck Analyzer zur Verfügung, die den Text in eine normalisierte Form bringen. Selbstverständlich kann auch selbst ein Analyzer entwickelt werden. Die nach [Hardt u. Theis 2004] am häufigsten eingesetzten Analyzer sind der SimpleAnalyzer und der WhitespaceAnalyzer. Der SimpleAnalyzer arbeitet den Text auf Buchstabenebene ab. Alle großgeschriebenen Buchstaben werden in den entsprechenden kleingeschriebenen Buchstaben umgewandelt und der Text wird anhand der Leerzeichen aufgetrennt. Zeichen, die kein Buchstabe sind, werden aus dem Text entfernt. Der WhitespaceAnalyzer führt dagegen keine Umwandlung der Zeichen durch, sondern trennt den Text nur anhand der Leerzeichen auf. Da ein Analyzer den Inhalt des Indexes verändert, muss der bei der Indexierung verwendete Analyzer auch bei der Suche eingesetzt werden. Ein Index mit Wörtern, die in jedem Dokument vorkommen (wie z. B. „der“,„die“ oder „das“), besitzt in diesem Fall wenig Aussagekraft. Deshalb kann Lucene bei der Analyse des Textes eine Liste von unerwünschten Wörtern nutzen, automatisch aus den Texten entfernt werden. Hier bietet sich z. B. die Liste der hundert häufigsten Wörter innerhalb von Texten an, die vom Projekt „Wortschatz“ der Universität

13.4 Wissensbasen

195

Leipzig31 in den Sprachen Deutsch, Englisch, Französisch und Niederländisch zur Verfügung gestellt werden. Auch eine Vorverarbeitung ähnlich der im Abschnitt 13.3.3 vorgestellten Art macht Sinn, damit die Anfragen bessere Suchergebnisse erreichen. Durch die Indexierung der Grundformen statt der im Original vorliegenden Wörter gewinnt die Suche an Treffern, so dass alle Dokumente mit der Grundform der Anfrage-Terme in ihren Suchfeldern gefunden werden. Zu diesem Zweck kann die auch schon im Abschnitt 13.3.3 vorgestellte Bibliothek, der Snowball Stemmer, eingesetzt werden. Ein entsprechender Analyzer wird vom Projekt zur Verfügung gestellt. Durch die Indexierung der Grundformen verliert die Suche natürlich an Präzision, andererseits werden so Dokumente mit einer Suchanfrage erreicht, die sonst keine Relevanz hätten. Abschließend wird der nun extrahierte und analysierte Text indexiert. Bei der Indexierung wird für jedes Originaldokument ein Indexdokument erzeugt und der analysierte Text in die Felder geschrieben. Der letzte Schritt in der Indexerzeugung ist dann das Hinzufügen des Dokuments zu dem Index. Anfragesprache von Lucene Alle Anfragen an das Lucene-System setzen sich aus Termen und Phrasen zusammen. Terme sind dabei einzelne Wörter, Phrasen hingegen sind eine Zusammenfassung von mehreren Termen und werden durch Anführungszeichen gekennzeichnet. Die eben beschriebenen Terme und Phrasen können nun mit den auch von InternetSuchmaschinen bekannten booleschen Verknüpfungen kombiniert werden. In Lucene existieren die logische „UND“-Verknüpfung, die logische „ODER“-Verknüpfung und die Negation. Auch die im Index gespeicherten Felder können in einer Suchanfrage speziell genutzt werden. So wird beispielsweise über „Frage:EIB“ die Suche auf das Feld „Frage“ und das Wort „EIB“ begrenzt. Auch die logischen Verknüpfungen können hier wieder eingesetzt werden. Zusätzlich zu den booleschen Operatoren unterstützt Lucene „Joker“ bzw. „Wildcards“. Diese ersetzen in Wörtern einzelne Zeichen („?“ in Lucene) oder auch ganze Zeichenfolgen („*“ in Lucene). Eine Verfeinerung der Anfragesprache durch Gruppierung wird ebenfalls von Lucene angeboten. Hierzu werden wie aus der Logik gewohnt Klammerungsstrukturen eingesetzt. Da in der Anfragesprache einige Zeichen als Steuerzeichen verwendet werden, sind Anfragen, die speziell auch diese Zeichen enthalten sollen, gesondert zu behandeln. Um die Steuerzeichen als normale Zeichen in der Suche zu verwenden, benutzt die Anfragesprache das Zeichen „\“. Die Suche nach der Mathematikaufgabe (11*11)*22 sieht also wie folgt aus: \(11\*11\)\*22. 31 Webseite des Projekts „Wortschatz“: http://wortschatz.uni-leipzig.de/, letzter Zugriff am 06.05.2005.

196

13 Gesprächskompetenz im I-can-EIB-System

Lucene bietet allerdings auch einige Besonderheiten: „Boosting“ (Verstärkung der Relevanz einzelner Teile der Anfrage), „Suche unter Einhaltung bestimmter Abstände“ und einfache „Fuzzy“-Algorithmen. Wie bei der Indexierung kann auch bei der Suche ein „Boost“-Faktor eingesetzt werden. Auch in einer Suchanfrage sind dem Benutzer manche Wörter wichtiger als andere. Diese kann er durch die Notierung eines „Boost“-Faktors an dem Term oder der Phrase zum Ausdruck bringen. Negative Faktoren sind zulässig, Terme oder Phrasen ohne „Boost“-Faktor haben grundsätzlich den Faktor 1. Eine spezielle Eigenschaft von Lucene ist die „Suche unter Einhaltung bestimmter Abstände“. Mit dieser Methode kann nach mehreren Wörtern gesucht werden, die einen maximalen Abstand im Text zueinander haben dürfen. Der Ausdruck „Term1 Term2“∼4 stellt also die Suche nach Term1 und Term2 dar, wobei die Terme maximal vier Terme voneinander im Text entfernt stehen dürfen. „Fuzzy“-Algorithmen dienen der Suche nach syntaktisch ähnlichen Termen. Zur Ermittlung von ähnlichen Wörtern im Sinne der „Fuzzy“-Suche von Lucene wird die Levenshtein-Distanz benutzt. Die Levenshtein-Distanz gibt die Ähnlichkeit zweier Zeichenketten an. Sie ist die minimale Anzahl an Operationen (Löschung, Einfügung oder Tausch von Zeichen), durch die eine Zeichenkette in die andere transformiert werden kann (vgl. [Carstensen u. a. 2004, S. 465]). Diese Distanz wird für jeden Term einzeln angegeben. Für die hier vorgestellte Syntax enthält Lucene Parser, die eine Anfrage in die für die Suche benötigte interne Repräsentation umwandeln. Suchvorgang Die Suche ermittelt nun für eine Anfrage eine Liste von relevanten Dokumenten aus dem Index. Die Relevanz eines Dokuments für die Anfrage (in Lucene auch „Score“ genannt) ergibt sich aus verschiedenen Faktoren und bezieht sich auf die Ähnlichkeit eines Dokuments zu der Anfrage. In der Liste werden die Dokumente automatisch nach ihrer Relevanz sortiert. In Lucene ist eine sehr ausgefeilte Implementierung zur Berechnung dieses „Scores“ vorhanden, eigene Implementierungen sind auch an dieser Stelle möglich. In der Standardimplementierung wird der „Score“ vor allem durch die Terme und Phrasen der Anfrage sowie deren Boost-Faktoren beeinflusst. Der „Score“ eines Dokuments (d) berechnet sich in Abhängigkeit von den einzelnen Termen (t) und der Anfrage (q) wie folgt:

scored (q, d) =


t∈q

(tf (t, d) ∗ idf (t) ∗ boost(t, d) ∗ lN (t, d)) ∗ coord(q, d) ∗ qN (q)

13.4 Wissensbasen

197

Der „Score“ eines Dokuments (d) setzt sich dabei aus den folgenden Werten zusammen: • Häufigkeit (tf ) des Terms aus der Anfrage (t) im Dokument (d). •

Faktor (idf ), basierend auf der Anzahl der Dokumente im Index, die den Term (t) enthalten.

•

Boost-Faktor (boost) für den Term ((t).

•

Normalisierungsfaktor (lN) für den Term in Abhängigkeit von dem Dokument.

•

Überlappung aller Terme der Anfrage mit dem Dokument (coord).

• Normalisierungsfaktor (qN) für die gesamte Anfrage. Eine ausführliche Erklärung befindet sich in der API-Dokumentation von Lucene in der Klasse Similarity32 . Ergebnispräsentation Die Ergebnispräsentation hat in einem IR-System einen nicht zu unterschätzenden Einfluss auf die Benutzer. In den meisten Fällen muss der Benutzer nun aus einer Liste von Dokumenten das für ihn richtige auswählen. Damit der Benutzer schnell die wichtigen Informationen erreicht, sollte die Präsentation der Liste nicht mit Informationen überladen werden. Die von den InternetSuchmaschinen bekannten Techniken sollten auch bei der Präsentation zum Einsatz kommen. Dazu zählen das „Paging“ und die Präsentation von Textauszügen mit hervorgehobenen Termen aus der Anfrage. Durch das „Paging“ erhält der Benutzer die Ergebnisse der Suche in kleinen Portionen. Dazu werden die Ergebnisse in absteigender Relevanz so präsentiert, dass der Benutzer nicht durch lange Seiten scrollen muss, sondern die restlichen Ergebnisse auf Folgeseiten vorfindet. Die Präsentation von Textauszügen in der Ergebnisliste mit hervorgehobenen Termen aus der Suche bietet dem Benutzer eine einfache und schnelle Möglichkeit, die Relevanz des gefundenen Dokuments besser zu beurteilen. Diese Vorgehensweise erspart dem Benutzer in vielen Fällen das Öffnen und selbstständige Suchen innerhalb des Dokuments. Abbildung 13.19 zeigt einen Ausschnitt aus einer Ergebnispräsentation. In diesem Beispiel wurde für je ein Frage-Antwort-Paar ein Dokument im Lucene-Index angelegt. Aufgrund der Kürze der Dokumente wird in der Präsentation das gesamte Ergebnis dargestellt. 32 Lucene 1.4.3 API: http://jakarta.apache.org/lucene/docs/api/index.html, letzter Zugriff am 06.05.2005.

198

13 Gesprächskompetenz im I-can-EIB-System search powered by Suchen

Das Ergebnis für Ihre Suche: Was ist der EIB? Frage: Was heißt EIB? Antwort: Es heißt Europäischer Installations-Bus und bezeichnet eine Technik, durch die sich Gebäudefunktionen automatisieren lassen (z. B. Beleuchtung, Jalousie, Heizung, Klima, Sicherheitstechnik) Relevanter Multimedia-Film: EIB-Logo Score:1.0 Frage: Was ist eine so genannte EIB-Welt? Antwort: Dabei handelt es sich um eine Großanlage, die bis zu 15 Bereiche enthält. Relevanter Multimedia-Film: Ausbaustufen Score:0.86486495 Frage: Was bedeutet der Begriff sichere Trennung bezogen auf den EIB? Antwort: Die Busleitung muss gegenüber Leitungen anderer Netze eine ausreichende Isolation aufweisen. Sie muss z. B. entweder selbst ummantelt sein oder mindestens einen Abstand von 4 mm gegenüber anderen Aderleitungen aufweisen. Relevanter Multimedia-Film: Sichere Trennung Score:0.6554054

Abb. 13.19: Ergebnispräsentation durch das Web-Interface

Erweiterungen Wie schon beschrieben, stellt Lucene eine flexible Java-Bibliothek zur Verfügung, die leicht erweiterbar ist. Hierzu gehören auch die schon vorgestellten DokumentenKonverter. Eine Erweiterung der Suchmöglichkeiten nach ähnlich klingenden Worten auf Basis der Algorithmen „Soundex“, „Metaphone“ und „DoubleMetaphone“33 ist auch erhältlich. Interessant für die Suche ist auch die Nutzung eines Synonymwörterbuchs. Hier bietet es sich an, in der Wordnet-Datenbank34 oder im Projekt „Wortschatz“35 nach Synonymen für die Terme der Anfrage zu suchen und die Anfrage dann entsprechend zu erweitern. Eine solche Erweiterung ist ebenfalls schon implementiert36 . 33

Phonetische Algorithmen mit Adaptern für Lucene: http://www.tangentum.biz/en/products/phonetix/index.html, letzter Zugriff am 06.05.2005. 34 Das Wordnet-Projekt: http://wordnet.princeton.edu/, letzter Zugriff am 06.05.2005. 35 Webseite des Projekts „Wortschatz“: http://wortschatz.uni-leipzig.de/, letzter Zugriff am 06.05.2005. 36 Erweiterung von Lucene um die Wordnet-Synonyme zur Erweiterung der Anfrage: http://www.tropo.com/techno/java/lucene/wordnet.html, letzter Zugriff am 06.05.2005.

13.4 Wissensbasen

199

Eine andere Möglichkeit, die Beantwortung von Fragen (Fragesätzen) zu verbessern, ist die Erweiterung der Anfrage um alternative Formulierungen. Für diesen Zweck wird eine Sammlung von Fragemustern benötigt. Zu jedem Fragemuster ist in der Sammlung eine Reihe von alternativen Formulierungen enthalten, um welche die Originalanfrage erweitert wird. Durch diese Erweiterung werden dann deutlich größere Übereinstimmungen im „Frage“-Feld mit der Anfrage gefunden. So könnte beispielsweise die Frage: „Was ist der EIB?“ auch mit diesen alternativen Formulierungen gestellt werden: „Was bedeutet EIB?“ oder „Was heißt EIB?“. Die Anfrage könnte in der Syntax von Lucene dann wie folgt aussehen: („Was ist“ OR „Was bedeutet“ OR „Was heißt“) AND EIB. Eine Gewichtung zwischen den alternativen Formulierungen wird in diesem Beispiel noch nicht eingesetzt, könnte aber über den „Boost“-Faktor für die Original-Phrase erfolgen. Integration in den A.L.I.C.E.-Server Für eine Integration des vorgestellten IR-Systems in den A.L.I.C.E.-Server gibt es mehrere Möglichkeiten. Zum einen kann der Chatbot ein weiteres Fenster öffnen und die Ergebnisse seiner Suche wie von den Internet-Suchmaschinen gewohnt darstellen. Eine Alternative ist die Nutzung von speziellen Frage-Antwort-PaarDokumenten. Durch diese Art der Dokumente ist sichergestellt, dass in einem Dokument nur eine Frage mit der zu ihr gehörenden Antwort steht. Dadurch kann der Chatbot den besten Treffer extrahieren und innerhalb eines Dialogs direkt präsentieren. Zur Sicherheit sollte der Benutzer auf die Relevanz des Treffers (also auch auf die Suche mit statistischen Mitteln) hingewiesen werden. Die Integration in den A.L.I.C.E.-Server selbst kann ähnlich der Integration der dynamischen Inhalte aus dem Internet (siehe Kapitel 13.4.3) über JavaScript innerhalb von AIML erfolgen und wird deshalb hier nicht weiter vorgestellt. 13.4.3 Information-Mining dynamischer Inhalte aus dem Web Wäre es nicht schön, wenn der Avatar auf die Frage „Wie wird das Wetter morgen?“ die relevanten Informationen im Internet suchen und eine Antwort der Art „Zu neunzig Prozent wird’s sonnig und angenehm warm“ geben würde? Er könnte für diesen Fall auch ergänzend einige Ausflugsziele oder Veranstaltungen in der Region heraussuchen. Leider sind entsprechende Web-Services37 , die diese Daten maschinenlesbar liefern könnten, nicht immer verfügbar und die Nutzung oftmals auch nicht kostenlos. Trotzdem sind die Informationen allgemein zugänglich im Web vorhanden – allerdings überwiegend in HTML kodiert. Insbesondere die Wettervorhersage lässt sich sogar zu jedem Ort detailliert anzeigen; für die Korrektheit und Zuverlässigkeit der prognostizierten Aussagen kann natürlich auch das Web nicht garantieren. Aber 37

Für eine Einführung siehe http://www.webservices.org/, besucht am 04.03.2005.

200

13 Gesprächskompetenz im I-can-EIB-System

es muss ja nicht zwangsläufig das Wetter sein. Auch Fragen bezüglich der aktuellen Börseninformationen oder Sportmeldungen könnten mit Hilfe des Webs adäquat beantwortet werden. Obwohl diese Informationen im Internet vorliegen, werden sie nur selten für eine automatisierte Antwortgenerierung verwendet. Das liegt u. a. daran, dass die Informationsgewinnung aus dem Netz, auch Information-Mining genannt, mit einigen Schwierigkeiten verbunden ist. Dieses soll im Folgenden an einem Beispiel verdeutlicht werden. Das Wetterbeispiel Mit diesem Beispiel soll der Zugriff auf dynamische Daten – hier die aktuelle Wettervorhersage – demonstriert werden. Konkret soll ein Chatbot in die Lage versetzt werden, auf die Frage „Wie wird das Wetter heute?“ eine zufrieden stellende Antwort zu geben. Die Überlegungen, die in diesem Abschnitt zur Lösung des Problems angestellt werden, lassen sich auch auf die anderen zuvor genannten Fälle übertragen. Voraussetzung ist immer, dass die Antworten in Textform aus den Dokumenten gewonnen werden können. Zur Vereinfachung wird an dieser Stelle angenommen, dass die zu untersuchenden Dokumente immer über die gleiche URI erreichbar sind. Im Anhang (vgl. Anhang E.1) ist der Auszug eines HTML-Dokuments abgedruckt, wie es vergleichbar tagtäglich aktualisiert von einem Wetterdienst abgerufen werden kann. Für die Beantwortung der Frage nach dem Wetter ist insbesondere der folgende Ausschnitt aus dem HTML-Dokument interessant. ...Die Kaltfront eines Tiefs überquert heute Deutschland von Nordwest nach Südost, 3 dahinter strömt kühlere Meeresluft zu uns. 4 ... 1 2

Listing 13.13: Ausschnitt aus dem Originaldokument mit der Wettervorhersage (vgl. Anhang E.1)

Zwischen den geklammerten Ausdrücken und steht die gesuchte Information. Leider reicht es nicht aus, einfach die HTML-Seite vom Programm einlesen zu lassen und nach diesen Ausdrücken zu suchen, um den dazwischenliegenden Text als Antwort zu übernehmen. Ein genauerer Blick auf das HTML-Dokument (vgl. Anhang E.1) lässt erkennen, dass der Ausdruck mehrmals vorkommt. Es handelt sich hierbei um ein strukturierendes Tag, das eine Zelle innerhalb einer

-Definition auszeichnet. Da HTML-Seiten oftmals aus mehreren ineinander verschachtelten Tabellen aufgebaut sind, lassen sich die enthaltenen Informationen nur schwer in ihrer Bedeutung einordnen. Die Situation wäre einfacher, wenn die Wetter-Informationen in einem semantischen Tag (z. B. ) vorliegen würden. Dann bräuchte man nur gezielt nach diesen Tags zu suchen und die entsprechenden Informationen auszulesen.

13.4 Wissensbasen

201

Das semantische Web Das semantische Web (engl. semantic web) stellt eine Erweiterung des World Wide Web (WWW) um maschinenlesbare Daten dar, welche die Semantik der Inhalte formal festlegen. Entsprechende Ideen hat Tim Berners-Lee38 bereits 1994 vorgestellt. Im Mai 2001 erschien im Scientific American von ihm ein visionärer Artikel, in dem das semantische Web als eine Erweiterung des herkömmlichen Webs angesehen wird. Informationen werden im Semantic Web mit eindeutigen semantischen Markierungen versehen, um die Arbeit zwischen Maschinen zu erleichtern. „The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation.“39 Bestrebungen des World Wide Web Consortiums (W3C) die Idee des semantischen Webs voranzutreiben, konzentrieren sich unter anderem auf das Resource Description Framework (RDF)40 oder die darauf aufbauende Web Ontology Language (OWL)41 . Bei RDF handelt es sich um eine Auszeichnungssprache für Metadaten, die stark an die Conceptual Graphs (CG) von John F. Sowa42 angelehnt ist. Sie basiert auf so genannten Triples bzw. Statements, die aus subject, predicate (oder property) und object bestehen. Ebenfalls als Grundlage für ein semantisches Web könnte die Topic-Map-Technologie43 dienen, die einzelne Themen (Topics) in den Vordergrund stellt. Einen guten Überblick hierüber gibt das Buch „Topic Maps“ von Richard Widhalm und Thomas Mück (vgl. [Widhalm u. Mück 2002]). Es gibt allerdings einige Gründe, die eine umfassende Einführung des semantischen Webs abbremsen. An dieser Stelle seinen nur zwei genannt: •

Mit HTML lässt sich schnell eine Webseite konstruieren. Die effektive Verwendung von XML und RDF erfordert dagegen in der Regel eine gewisse Einarbeitungszeit.

•

Viele Anbieter von Informationen haben überhaupt kein Interesse daran, die von ihnen ins Internet gestellten Texte und Daten für ein Computerprogramm verständlich zu machen. Diese könnten dann automatisch kopiert und ungefragt in einem anderen Zusammenhang verwendet werden. Auch Werbebanner ließen sich nicht mehr im HTML-Code verstecken und könnten ohne Schwierigkeiten weggefiltert werden. 38

Tim Berners-Lee, britischer Informatiker, ist einer der Gründerväter des World Wide Web (WWW). 39 Zu finden unter http://www.scientificamerican.com/article.cfm?articleID=0004814410D2-1C70-84A9809EC588EF21&catID=2, besucht am 17.03.2005. 40 Siehe http://www.w3.org/RDF/, besucht am 18.03.2005. 41 Siehe http://www.w3.org/2004/OWL/, besucht am 18.03.2005. 42 Siehe http://www.jfsowa.com/cg/, besucht am 17.03.2005. 43 Siehe http://www.topicmaps.org/, besucht am 18.03.2005.

202

13 Gesprächskompetenz im I-can-EIB-System

Einige Entwickler gehen den Hindernissen, die sich durch fehlende semantische Strukturen in Webseiten ergeben, eher pragmatisch als analytisch aus dem Weg und behelfen sich mit manuellen Konstrukten. Stellvertretend werden im Folgenden Screen Scraper und Wrapper kurz vorgestellt. Teilweise flossen die verwendeten Konzepte in das W3 xtract-Tool (vgl. Anhang E) ein, das im Projekt für die automatische Extraktion dynamischer Inhalte entwickelte wurde. Screen Scraper Eines der länger bekannten und erfolgreich genutzten Verfahren ist die als Screen Scraping bezeichnete Technik. Der Programmierer eines Screen Scrapers geht von der Annahme aus, dass die zu extrahierenden Informationen ursprünglich aus einer Datenbank stammen. Folglich ist in den überwiegenden Fällen zu erwarten, dass das Gerüst der zur grafischen Repräsentation dienenden Elemente stets identisch ist. Bezogen auf das Wetter-Beispiel würde der Prozess, der seitens des Webservers durchgeführt wird, zwei Schritte beinhalten. Zuerst wird der Datensatz „aktuelle Wettervorhersage“ aus der internen Datenbank ausgelesen und anschließend in ein vorgefertigtes Template integriert. Der Ausschnitt eines HTML-Templates, wie es für das Wetterbeispiel aussehen könnte, ist in Listing 13.14 abgebildet. 1 2

... ... Listing 13.14: Ausschnitt aus dem HTML-Template für das Wetterbeispiel

Beim Ausdruck %WETTERVORHERSAGE handelt es sich um eine Variable, in die der ausgelesene Datensatz gespeichert wurde. Ein Entwickler analysiert für die Konstruktion eines Screen Scrapers zunächst manuell einige der dynamisch erzeugten Webseiten. Er schreibt dann ein Skript, das die gewünschten Informationen anhand bestimmter vorangehender sowie folgender Zeichenketten erkennt. Die entscheidende Zeile eines regelbasierten Screen Scrapers, der die Wetterinformationen aus dem gegebenen HTML-Dokument extrahiert, könnte exemplarisch folgendermaßen aussehen: Wetter(X):- prev(X,’’).

Die Zeile drückt aus, dass nach einer Textstelle im Dokument gesucht wird, die von den Zeichenfolgen „“ eingeschlossen wird. Falls eine solche Textstelle existiert, wird sie in der Variablen X gespeichert. Screen Scraper lassen sich relativ schnell und ohne komplizierte Überlegungen programmieren. Bevorzugte Programmiersprachen sind Perl oder PHP, da sie mächtige

13.4 Wissensbasen

203

Funktionen und Hilfsmittel für die textbasierte Suche und Verarbeitung regulärer Ausdrücke bereitstellen. Es gibt aber auch Umsetzungen auf Java-Basis, die ebenso gut ihren Dienst verrichten. Einige Vertreter aus dem Open-Source-Bereich sind z. B. TagSoup44 , WebL45 , ScrapeForge46 oder Phoenix47 . Der einfachen Konstruierbarkeit von Screen Scrapern steht allerdings ein Mangel an Robustheit bezüglich Layoutmodifikationen seitens der Informationsanbieter gegenüber. Schon das Ersetzen von „“ im HTML-Dokument (siehe Listing 13.13), um den Inhalt als Tabellenüberschrift (Table Header) darzustellen, führt zum Versagen des vorgestellten Erkennungsmechanismus. Zwar wäre eine Anpassung der Regeln bei jeder Modifikation denkbar, praktikabel ist diese Lösung jedoch nur, wenn sich die Änderungsfrequenz in Grenzen hält, da der Wartungsaufwand auf Dauer sonst zu hoch wäre. Mit zunehmender Komplexität des Regelapparats steigt auch seine Fehleranfälligkeit. Die wahre Kunst liegt in der geschickten Generalisierung von Regeln. Diese müssen einerseits so allgemein sein, dass sie robust gegenüber kleinen Änderungen sind, aber andererseits auch so speziell, dass keine relevanten Informationen überlesen oder nicht erkannt werden. Diese Erkenntnis führte zum Ansatz der automatischen Generierung so genannter Wrapper. Wrapper für Web-Schnittstellen Wrapper, in diesem Fall Wrapper für Web-Schnittstellen, sind auf den ersten Blick den manuell erstellten Screen Scrapern ähnlich. Sie arbeiten jedoch in der Regel auf einem internen Modell der Webseite anstelle der reinen Browserdarstellung. Wrapper für Web-Schnittstellen bieten über definierte Funktionen Zugang zu den entsprechenden Informationen. Applikationen, die Anfragen an einen Wrapper richten, brauchen sich in der Regel nicht um die Eigenschaften der dahinter verborgenen Webseite zu kümmern. So kann es zum Beispiel durchaus sein, dass der Wrapper für die Bearbeitung einer Abfrage erst durch mehrere Webseiten der Datenquelle navigieren muss. Wrapper für Web-Schnittstellen bieten also eine Art Datenzugriff für Datenquellen im Internet. Vielen dieser Systeme liegt das Grundprinzip der Induktion zugrunde. Anhand einer genügend großen Menge an HTML-Seiten, die die gewünschten Informationen enthalten, wird versucht, ein generelles Konzept zu ihrer Identifikation herzuleiten. Der Nutzer muss hierfür die Dokumente an den entsprechenden Stellen markieren. Das System generiert daraufhin automatisch einen Wrapper. Solche Wrapper sind im Gegensatz zu Screen Scrapern robuster gegenüber kleineren Modifikationen. Trotzdem gibt es auch mit diesem Ansatz Probleme, die zu 44

Siehe http://mercury.ccil.org/ cowan/XML/tagsoup/, besucht am 01.03.2005. Siehe http://www.research.compaq.com/SRC/WebL/, besucht am 01.03.2005. 46 Siehe http://scrapeforge.sourceforge.net/, besucht am 01.03.2005. 47 Siehe http://ki.informatik.uni-wuerzburg.de/~betz/phoenix/, besucht am 01.03.2005. 45

204

13 Gesprächskompetenz im I-can-EIB-System

einem unüberwindbaren Hindernis werden können. Die Regeln, die dem Wrapper zur Erkennung der Informationen dienen, bauen meistens auf dem HLRT-Konzept auf. HLRT steht für Head-Left-Right-Tail und beschreibt den Aufbau einer Erkennungsregel. Erkennt der Wrapper den „Head“ (z. B. bestimmter HTML-Code vor der gesuchten Information), erfolgt die Weiterverarbeitung innerhalb einer Schleife. Diese wird so lange durchlaufen, bis der Wrapper auf die durch „Tail“ gegebene Zeichenfolge trifft. Innerhalb dieser Schleife werden alle Informationen zwischen „Left“ und „Right“ gesammelt. Ineinander verschachtelte Tabellen (siehe Beispieldokument 13.15) können diesen Ansatz der Informationsgewinnung aushebeln, wenn sich der Wrapper schon in der informationssammelnden Schleife befindet, obwohl der eigentlich gesuchte „Head“ noch nicht gelesen wurde. ............ 1 2

Listing 13.15: Wetterbeispiel mit verschachtelten Tabellen

Es muss also sichergestellt werden, dass die gewünschten Informationen nicht in zu verschachtelten Strukturen eingebettet sind. W3 xtract – Web Extraction Tool Im Projekt wurde eine eigene Lösung auf Java-Basis in Form des Open-SourceTools W3 xtract entwickelt. Das Tool ähnelt in der Funktionsweise einem Screen Scraper, arbeitet allerdings nicht direkt auf dem HTML-Code. Vielmehr wird das HTML-Dokument eingelesen und daraus intern eine DOM-Repräsentation48 generiert. Diese Arbeit übernimmt das Herzstück von W3 xtract – das Open-Source-Tool jTidy49 . Dieses ist sogar in der Lage, HTML-Dokumente mit kleineren Fehlern (z. B. nicht korrekt geschlossene Tags) einzulesen und einen entsprechenden DOMBaum zu konstruieren. Hieraus werden dann mittels XPath-Ausdrücken die gesuchten Informationen extrahiert und in XML-Ausgabedateien geschrieben. Im nächsten Schritt werden die Informationen aus diesen Dateien für A.L.I.C.E. verfügbar gemacht (s. Abschnitt 13.4.3). Die von W3 xtract verwendete Technik hat den Nachteil, dass bei Layoutänderungen am HTML-Dokument die Anwendung des XPathAusdrucks wahrscheinlich nicht mehr die gewünschten Ergebnisse liefert (vgl. Ab48

Das Document Object Model (DOM) ist ein so genanntes Application Programming Interface (API) und beschreibt, wie man programmiersprachenunabhängig auf HTML- oder XML-Dokumente zugreifen kann. Es besteht aus Knoten (Nodes), die in einer Baumstruktur durch Zeiger miteinander verbunden sind. 49 Siehe http://jtidy.sourceforge.net/, besucht am 02.03.2005.

13.4 Wissensbasen

205

schnitt 13.4.3). Während der dreijährigen Projektlaufzeit hat sich aber gezeigt, dass die genutzen Informationsdienste so gut wie nie Layoutänderungen vorgenommen haben. Die Verwendung von XML als Ein- und Ausgabeformat sowie XPath für die Extraktion halten das System außerdem leicht wartbar. Einem Programmierer mit einfachen Java-Kenntnissen wäre es außerdem möglich, die Generierung des XPathAusdrucks zu automatisieren. Die Funktionsweise der Datenextraktion mit W3 xtract soll anhand des Aktivitätsdiagramms in Abbildung 13.20 erklärt werden. Zum besseren Verständnis des Diagramms sei auf die W3 xtract-Referenz sowie dem Ausschnitt einer W3 xtractJob-Datei im Anhang verwiesen (siehe Anhang E).









  
 
   

   










 
  


  




 

 
   



    !  


    !  


!





"# 
 
$%&'"( 


2
31 
4 



5&'"# 



)




*%+

 
$%&'"( 

  

  


,






 
".  



   


/








   

.s  s



      


      


6
5 ".  

#7&"8 




 
4 
1


0



 
(+ z
 

1


Abb. 13.20: Der Prozess der Datenextraktion mit W3 xtract dargestellt als Aktivitätsdiagramm

1. Zuerst wird die W3 xtractConfig-Datei (vgl. Anhang E.2) eingelesen. Sie enthält Informationen, die zur Konfiguration notwendig sind. In muss eine Log-Datei angegeben werden. Sie dient zum Mitspeichern von Fehlern, die eventuell während des Programmlaufs auftreten. Außerdem werden in die Pfade zu den Quelldateien, in denen die abzuarbeitenden Anweisungen stehen, definiert. In wird die Zieldatei für die extrahierten Informationen spezifiziert. 2. Aus der W3 xtractConfig-Datei wird der nächste abzuarbeitende W3 xtractJob ausgewählt. Falls es keinen Job mehr gibt, also alle abgearbeitet wurden oder

206

13 Gesprächskompetenz im I-can-EIB-System

keiner definiert wurde, wird das Programm W3 xtract beendet und ggf. nach einer definierten Zeitspanne (siehe hierzu Abschnitt 19.3.3) wieder ausgeführt. 3. Der entsprechende Source-File mit der Job-Definition wird eingelesen und die Parameter entsprechend gesetzt. Das Beispiel-Listing E.5 für den Wetter-Job ist im Anhang zu finden. Es enthält ein -Tag, das den Pfad zur Webseite definiert, von der Informationen gesammelt werden sollen. Außerdem sind ein oder mehrere W3 xtractInfo-Anweisungsblöcke enthalten. Diese spezifizieren genau, welche Informationen gesammelt werden sollen. 4. Der angegebenen URI des W3 xtractJobs entsprechend wird eine Webseite eingelesen. Falls dabei Fehler auftreten, wird dies in der Log-Datei gespeichert und anschließend der nächste Job ausgewählt. 5. Mittels jTidy wird die eingelesene HTML-Seite intern in einen DOM-Baum konvertiert. Fehler bei der Verarbeitung werden in der Log-Datei bzw. in der Konsole angezeigt. W3 xtract versucht in einem solchen Fall den nächsten Job auszuführen. Es lässt sich nicht ausschließen, das jTidy beim Parsen bestimmter Webseiten Schwierigkeiten hat. In einem solchen Fall sollte nach Ersatzseiten zur Datenextraktion gesucht werden. Eine weitere Möglichkeit besteht in der Verwendung eines alternativen HTML-Parsers (siehe Abschnitt 19.3.5). 6. Der nächste abzuarbeitende W3 xtractInfo-Anweisungsblock wird ausgewählt. Falls keiner vorhanden ist, werden die gesammelten Informationen im XMLFormat gespeichert und anschließend zum nächsten Job übergegangen. 7. Die aktuellen W3 xtractInfo-Parameter werden eingelesen. Es gibt zwei verschiedene Arten von Anweisungen: SystemDate- und XPath-Abfragen. 8. Die aktuelle Systemzeit wird eingelesen. Die Syntax, mit der diese Information in der Ausgabedatei gespeichert wird, wird durch einen Ausdruck im SimpleDateFormat bestimmt50 . Die Zeichenkette „E MMM dd HH:mm:ss z yyyy“ im Beispiel-Listing E.5 erzwingt beispielsweise die Darstellung in der Form „Sun Feb 20 15:10:03 CET 2005“. 9. Der XPath-Ausdruck wird auf den intern konstruierten DOM-Baum angewendet. Die im spezifizierten Knoten (meistens ein Text-Node) gefundene Information wird gespeichert. 10. Die gespeicherten Informationen werden entsprechend den Verarbeitungsanweisungen im W3 xtractOutput-Tag jeweils zu jedem Job in die Zieldatei geschrieben.

50 Siehe http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html, besucht am 01.03.2005.

13.4 Wissensbasen

207

Anbindung an A.L.I.C.E. zur Antwortausgabe Nachdem W3 xtract seine Datenextraktionen ordnungsgemäß ausgeführt hat, liegen die Informationen zur Weiterverarbeitung in Form von XML-Dateien vor. Bezogen auf das Wetterbeispiel befindet sich im Zielordner die aktuelle Wettervorhersage beispielsweise in der Datei „wwwxtractOutputWettervorhersage.xml“. Damit die Wetterdaten auch in einem Dialog zur Verfügung stehen, muss eine Verbindung zwischen den AIML-Kategorien des Chatbots und einzelnen Informationen aus der XML-Datei geschaffen werden. Im Folgenden wird eine Möglichkeit zur Verbindung anhand der JavaScript-Funktionalität des A.L.I.C.E.-Servers gezeigt. Die Anbindung der Wetter-Wissensbasis an A.L.I.C.E. besteht aus zwei Komponenten. Zuerst werden Dialoge benötigt, die über das dynamische Wissen kommunizieren. Innerhalb der AIML-Kategorien müssen also Muster hinterlegt werden, über die auf das externe dynamische Wissen zugegriffen werden kann. Für das Wetterbeispiel wäre dies zum Beispiel das Muster „Wie ist das Wetter in *“. Zusätzlich zu den Dialogen muss eine Schnittstelle aus AIML heraus zu den externen Daten geschaffen werden. Diese Aufgabe übernimmt eine spezielle AIMLKategorie, die über JavaScript mit einem externen Dienst kommuniziert. 1 2



3

WIE SEIN D WETTERN IN * 6 WETTER heute 7 4 5

8

WETTER * * 11

12

13 var title = ’’; 14 var subtitle = ’’; 15 var url = ’http://...wwwxtractOutputWettervorhersage. xml’; 16 var xpath = "//item/description[contains(../title,’"+ title+"’) and contains(../subtitle,’"+subtitle+"’) ]"; 17 var _url = java.net.URL; 18 var _connection = java.net.URLConnection; 19 var _in = java.io.BufferedReader; 20 var _inReader = java.io.InputStreamReader; 21 var _line = java.lang.String; 22 var _inputLine = java.lang.String; 23 var _reply = "Leider keine aktuellen Informationen gefunden."; 9

10

208

13 Gesprächskompetenz im I-can-EIB-System

24 25

26

url = new java.net.URL("http://.../tomcat/wetter/ XPathSearch?url=" + java.net.URLEncoder.encode(url )+"&xpath="+java.net.URLEncoder.encode(xpath)); connection = url.openConnection();

27 28

29 30 31

_inReader = new java.io.InputStreamReader(connection. getInputStream()); _in = new java.io.BufferedReader(_inReader); _inputLine = new java.lang.String(); _reply = new java.lang.String();

32

while ((_inputLine = _in.readLine()) != null) { _reply += _inputLine; 35 } 36 _in.close(); 37 _reply.toString(); 38

39

40 33 34

41 42

1 2

Listing 14.9: PHP-Schnittstelle zwischen CMS und VNet-Client

Natürlich ist der Aufruf des Applets mit vordefinierten Werten nicht nur aus einer PHP-Umgebung möglich. Bei einer Anbindung mit einem JSP- oder ASP-basierten System müssen die Parameter nickname, userrole und tikiid aus dem CMS der Technologie entsprechend an das Applet übergeben werden.

250

14 Wissensmarktplatz mit Agenten und Avataren

1 2

Listing 14.10: Aufruf des VNet-Clientapplet aus dem Tiki-CMS

14.3 Entwicklung mit VRML, AgentScript und JADE 14.3.1 Virtual Reality Modelling Language (VRML) Ziel dieses Abschnittes ist nicht eine komplette VRML-Einführung, sondern vielmehr ein Verständnis für die Einsetzbarkeit von VRML zu schaffen. Um eine

14.3 Entwicklung mit VRML, AgentScript und JADE

251

(Weiter-)Entwicklung von VRML-Welten selbst durchzuführen, ist weiterführende Literatur zum Thema VRML und die Spezifikation des Standards57 unablässlich. Die Spezifikation ist leicht zu lesen und bietet einen schnellen praktischen Einstieg. Eine gute Einführung ist z. B. in [Kloss u. a. 1998] zu finden. Bei VRML handelt sich um eine Sprache, mit der virtuelle Welten für das WWW erstellt werden können. Diese Entwicklung wurde angestoßen von Mark Pesce und Tony Parisi am 20.04.1994 auf dem ersten internationalen WWW-Kongress in Genf. Hieraus bildete sich schnell eine Gemeinde, die den ersten VRML-Kongress im Dezember 1995 organisierte. Dem Standard VRML95 folgte VRML97 und schließlich VRML2000. VRML wird in I-can-EIB für die Visualisierung und Interaktion im Wissensmarktplatz, speziell im Chatsystem, eingesetzt. Da das Chatsystem u. a. die räumliche Navigation und die visuelle Gestaltung der Avatare im virtuellen Wissensmarktplatz unterstützen sollte, erschien die Abstützung auf den weitverbreiteten und mächtigen VRML-Standard sinnvoll. Das für die Realisierung des virtuellen Marktplatzes eingesetzte Chatsystem VNet (Abschnitt 14.2.1) entspricht diesen Anforderungen. Die im virtuellen Marktplatz vorgestellten Ausstellungen werden durch VRML-Räume repräsentiert. Sie werden im Abschnitt 14.3.5 näher erläutert. Der Abschnitt 14.3.5 versucht, eine Abstraktion bei der Erstellung der VRML-Räume zu schaffen, in der nur eine geringe Anzahl an Eigenschaften editiert werden muss. VRML-Kenntnisse sind hierbei nicht erforderlich. Als Ergänzung hierzu bietet der Anhang C eine detaillierte Beschreibung der verschiedenen Schritte bei der VRML-Entwicklung eines bestimmten Raumes. Jeder Schritt wird hierbei durch ein VRML-Listing und die dazugehörige Visualierung begleitet. Dabei wird ein im Chatsystem verwendeter Raum beschrieben, um das Verständnis bzw. die Weiterentwicklung zu vereinfachen. 14.3.2 AgentScript und eine JADE-Implementation Agenten sollen in ihrer visualisierten Umgebung lebendig wirken, da sie Individuen simulieren bzw. repräsentieren. Ein möglicher Ansatz wäre es, in diesem Zusammenhang einen BDI-Agenten zu implementieren. Wie schon in Abschnitt 7.1.1 angesprochen, ist ein BDI-Agent nach folgender Struktur aufgebaut: • Wissen über seine Umwelt (Beliefs): Wichtig für einen autonom agierenden Agenten sind Informationen über den aktuellen Zustand seiner Umwelt, in der er sich bewegt und reagiert. Diese werden in einer Wissensbasis gespeichert, die Fakten über die aktuelle Umgebung, den internen Zustand des Agenten und bestimmtes Hintergrundwissen, das für Schlussfolgerungen notwendig sein kann, enthält. Die Wissensbasis wird dabei ständig aktualisiert, um dem Agenten ein möglichst „reales“ Modell seiner Umwelt zu liefern. • Ziele (Desires): Der Agent besitzt einen Speicher für Ziele, die für eine rationale Beurteilung der Situation seine Bewertungs- und Abwägeprozesse steuern. Aus einer Menge von Zielen wird eines als Intention (Absicht) ausgewählt, das 57

Siehe http://tecfa.unige.ch/guides/vrml/vrml97/spec/, besucht am 29.03.2005.

252

14 Wissensmarktplatz mit Agenten und Avataren

eine bestimmte Zeit lang (mit Energie oder Commitment) verfolgt wird. Ziele werden durch Problemstellungen entweder selbst oder extern gesetzt. Kann ein Ziel mit einer Lösungsstrategie nicht erreicht werden, sind schwache Heuristiken einsetzbar (z. B. Teilzielbildung, Suche nach Alternativen oder nachträgliche Abwertung des ursprünglich verfolgten Ziels). • Absichten (Intentions): Um eine ausgewählte Intention zu realisieren, muss der Agent einen Plan, der zielführende Aktionen enthält, entwickeln. Auch das Schlussfolgern kann im Sinne einer Planausführung verstanden werden. Für JADE steht die Erweiterung JADEX58 zur Verfügung, mit der BDI-Agenten entwickelt werden können. Im I-can-EIB-Projekt wurde dieser Ansatz jedoch aus den nachstehenden Gründen nicht verfolgt: • Die Pläne in JADEX sind nicht nach dem Verhaltensparadigma (siehe Abschnitt 14.2.2) implementiert, sondern sind eine proprietäre JADEX-Entwicklung und somit nicht mehr FIPA-konform. • Eine Wissensbasis auf BDI-Grundlagen würde erfordern, dem Agenten ein größtmögliches Modell über seine Umwelt zu liefern, um in ihr ein vernünftiges Agieren zu ermöglichen. Dies umfasst u. a. ein starkes Sensorumfeld, wie z. B. ein simuliertes visuelles System. Die Komplexität eines solchen Systems und die sich daraus ergebende lange Entwicklungszeit stand für unsere Fragestellungen in keiner Relation zu seinem zusätzlichen Nutzen. Der Entwicklungsschwerpunkt des I-can-EIB-Systems liegt trotz Agentenvisualisierung auf der Funktionalität der Beratungskomponente. • Die Wartung und Erweiterung von JADEX-basierten Agenten gestaltet sich aufwändig. Beispielsweise bedeutet alleine das Hinzufügen eines neuen Plans einen erheblichen Programmieraufwand mit Auswirkungen auf mehr als eine Systemkomponente. Prinzipiell ist es zwar möglich, JADEX für ein solches System zu nutzen. Für das Agentenverhalten im I-can-EIB-System wurde jedoch eine eigene Variante entwickelt, die ein einfaches, aber effektives Modell bereitstellt, um Agenten in ihrer Umgebung natürlich wirken zu lassen. Das System ist zum einen leicht wartbar und zum anderen um neue Verhalten erweiterbar. Die Agenten werden nach Drehbuchart über einfache XML-Skripte gesteuert. Um das zu erreichen, wurde die XML-basierte AgentScript Markup Language (ASML) entwickelt (siehe Referenz in Abschnitt 14.3.2 und in Anhang D). Diese Sprache erzeugt vielleicht nicht in dem Maße den Eindruck von Intelligenz, wie sie z. B. ein BDI-Agent suggerieren würde, bietet aber den Vorteil, dass sie mit wenig Aufwand dem Agenten „Leben einhauchen“ kann. Sie ist kurz und einfach aufgebaut und damit schnell erlernbar. Ihre Flexibilität erhält sie, indem verschiedenste Arten von Agentenverhalten eingepflegt werden können. ASML ist dabei von der Art des eingesetzten Agentensystems unabhängig. Wichtig 58 Siehe http://vsis-www.informatik.uni-hamburg.de/projects/jadex/, besucht am 29.03.2005.

14.3 Entwicklung mit VRML, AgentScript und JADE

253

ist nur, dass ein Verhaltensparadigma nach FIPA unterstützt wird. Eine Referenzimplementation wird für JADE zur Verfügung gestellt59 . Bei Nutzung eines anderen Agentensystems müsste lediglich der Quellcode für diese Pakete – insbesondere für die Verhaltensklassen – angepasst werden. AgentScript Ein Agentenskript (z. B. wie in Listing 14.11 und seiner formalen Definition in Listing 14.12) bietet auf unterschiedlichen Ebenen folgende Eigenschaften: •

•

Skriptpunkte (Listing 14.11, Zeilen 2 – 9): – Verhaltensdefinitionen (parallel und sequentiell) – Zyklische bzw. azyklische Abarbeitung Subskripte (Zeilen 11 – 22): – Skriptpunkte – Rekursive Abarbeitung



348

21 3D-Multiagentensystem

/application/cvs/icecheckout_file/ice-vnet/vrml/room-designer/ 56 room.xsl 57 /home/dev/web/vnet/gallery/wrl / 58 /application/cvs/icecheckout_file/ice-vnet/vrml/gallery/wrl/ 59

60

61 log.properties 62

63 55

Listing 21.1: Konfigurationsbeispiel für MAS

21.2.3 Ausstellungskonfigurator Der Ausstellungskonfigurator, wie er in Abbildung 21.2 zu sehen ist, stellt dem Benutzer ein Servlet zu Verfügung, mit dessen Hilfe neue Ausstellungen erstellt, bestehende angepasst und bestimmten Wochentagen zugewiesen werden können. Die vorzunehmenden Einstellungen werden durch das Servlet an einen JADE-Agenten (siehe Abschnitt 14.3.5) delegiert, der schließlich die Daten in Form von XMLDateien ablegt. Diese XML-Dateien werden mittels eines XSL-Stylesheets5 zu VRML-spezifischen Dateien transformiert, um den Zugang ohne VRML-Kenntnisse zu gewährleisten. Im oberen Teil (Markierung 1) der Grafik wird die Möglichkeit einer Neuerstellung eines Raumes gegeben. Hierbei wird eine neue XML-Datei mit angegebenem Namen erstellt. Diese kann im mittleren Teil mit Daten gefüllt werden (Markierung 2). Neben dem Ausstellungsnamen können Bilder (über URLs) hinzugefügt, Raumgrößen angepasst, Türpositionen angelegt und ein Vektor angegeben werden, der den Raum in der VRML-Welt positioniert. Der untere Teil (Markierung 3) startet schließlich eine Transformation der aktuell geöffneten Ausstellung und ordnet diese einem Ausstellungstag zu. Bei der Transformation kann zusätzlich ausgewählt werden, ob es sich um eine permanente (vrml) bzw. laufzeitabhängige (deploy) Speicherung handeln soll. Zum Testen der erstellten Ausstellung sollte anfangs nur eine Transformati5

Extensible Stylesheet Language (XSL): Sprache zur Transformation und Präsentation von XML-Daten. Nähere Information unter http://www.w3.org/Style/XSL/, letzter Zugriff am 06.05.2005.

21.2 Konfiguration

349

Abb. 21.2: Austellungseditor

on im Deploy-Modus stattfinden. Ausstellungen werden je nach Tag des Einloggens eines Besuchers angezeigt.

Abb. 21.3: Die entstandene Ausstellung

350

21 3D-Multiagentensystem

Ein detaillierteres Vorgehen bei der Erstellung neuer Ausstellungen setzt Kenntnisse in VRML bzw. XSL voraus, da entweder das XSL-Stylesheet oder die entstandene VRML-Ausstellung von Hand editiert werden müssen. Der Anwendungskontext besteht jedoch hierbei in der Konfiguration neuer Ausstellungen und nicht in der Erstellung neuer VRML-Räume. Abschließend wird in Abbildung 21.3 die in Abbildung 21.2 konfigurierte Ausstellung gezeigt. Diese wird je nach zugewiesenem Wochentag im Chatsystem platziert und ermöglicht somit eine vom Tag abhängige Ausstellungsvielfalt.

Teil IV

Anhang

A Avatar-Beschreibungssprache Stefan Sölbrandt

A.1 ICE-FaceXML-DTD

5 6 7 8 9 10 11 12 13 14 15 16 17 ]> 1 2

Listing A.1: ICE-FaceXML-DTD

354

A Avatar-Beschreibungssprache

A.2 ICE-FaceXML-Tags-Übersicht A.2.1 Jede Beschreibung eines Avatar-Modells beginnt mit diesem Wurzelelement. A.2.2 Jedes Avatar-Modell, das in ICE-FaceXML-Notation spezifiziert wird, setzt sich aus einer Menge von Polygonen1 zusammen. Das -Element umfasst alle -Elemente, die zu deren Definition herangezogen werden können. A.2.3 Das Element definiert einen Punkt, von denen mehrere zur Spezifikation von Polygonen bzw. Kreisen benötigt werden. Über die Attribute x, y und z wird die Position des Punkts im dreidimensionalen Raum festgelegt. Ist im Element nur das Attribut mark angegeben, dann handelt es sich um eine Referenz, die auf den an anderer Stelle definierten Punkt verweist. Die Verwendung des rotate-Attributs ist zu empfehlen, wenn zusätzlich zum Kopf weitere Teile des Avatar-Körpers sichtbar sein sollen. Um zu verhindern, dass bei Kopfdrehungen beispielsweise der Hals auf unnatürliche Weise mitrotiert, müssen nichtbewegliche Punkte gekennzeichnet werden. Das rotate-Attribut markiert dabei den ersten Punkt, auf den Rotationsbefehle keinen Einfluss haben. Das trifft genauso auf alle folgenden Punkte zu, weshalb die nicht rotierenden -Elemente zusammenhängend am Ende der unter aufgeführten Elemente stehen. A.2.4 Das Element fasst alle Polygon-Definitionen, die zur Darstellung des Avatars verwendet werden, zusammen. A.2.5 Mit diesem Element lässt sich ein Polygon definieren. Durch die Attribute R, G und B wird die Farbe des Polygons gewählt. Entsprechend einem normalisierten RGB1 Ein Polygon (griech. poly „viel“, gonos „Winkel“) ist ein Begriff aus der Geometrie und bedeutet Vieleck.

A.2 ICE-FaceXML-Tags-Übersicht

355

Farbmuster2 in Dezimalschreibweise, bedeutet beispielsweise eine Belegung R=“0“ G=“0“ B=“0“, dass das Polygon in der Farbe Schwarz darzustellen ist. Das Element kann zwei oder mehr Punkte enthalten. Im Normalfall werden Polygone durch drei Punkte definiert. Bei einer Polygon-Definition mit zwei Punkten wird ausgenutzt, dass die 3D-Engine den Avatar an der vertikalen Mittelachse gespiegelt darstellt. Das hat den Vorteil, dass nur eine Gesichtshälfte definiert werden muss. Die zwei Punkte werden dabei mit den eigenen Spiegelungen verbunden, so dass ein Viereck entsteht. Mit dem Wert „line“ für das Attribut type werden die im Element enthaltenen Punkte durch eine Linie eingerahmt. Nur in diesem Fall können auch mehr als drei Punkte im Element enthalten sein. Mit der Belegung type=“circle“ lässt sich die Darstellung eines Kreises realisieren. Er benötigt zur vollständigen Spezifikation zwei -Elemente, die entsprechend zwei Punkte definieren. Der erste entspricht dabei dem Mittelpunkt, der zweite dem Radius des Kreises. Zusätzlich lässt sich über das group- und colorgroupAttribut die Zugehörigkeit des Polygons zu einer Gruppe bzw. Farbgruppe festlegen. A.2.6 Das Element fasst alle -Elemente zusammen. A.2.7 Animationen lassen sich durch -Elemente definieren. Dabei werden auf Punkte Basistransformationen festgelegt. Jede flex-Animation lässt sich über den Wert des name-Attributs aufrufen. A.2.8 Ein -Element bestimmt, wie sich die Position eines Punkts im dreidimensionalen Raum bei Aufruf der entsprechenden flex-Animation ändern soll. Dazu wird zu jedem Punkt über die Attribute x, y und z die relative Positionsänderung spezifiziert. Die Referenzierung der Punkte erfolgt über das mark-Attribut. A.2.9 Speziell bei der Arbeit mit dem Avatar-Editor EDGAR ist es sehr hilfreich, bestimmte Polygone in Gruppen (z. B. „Polygongruppe-Nase“ oder „Polygongruppe-Mund“) zusammenzufassen. Das Element beinhaltet alle Gruppen. 2

RGB (Rot, Grün, Blau - englisch Red, Green, Blue) ist ein additives Farbmodell, bei dem sich die Grundfarben zu Weiß addieren (Lichtmischung). Eine Farbe wird durch drei Werte beschrieben: den Rot-, den Grün- und den Blauanteil. Jeder Farbanteil kann zwischen 0 Prozent und 100 Prozent (bzw. zwischen 0.00 und 1.00) variieren.

356

A Avatar-Beschreibungssprache

A.2.10 Der über das name-Attribut definierte Gruppenname des -Elements wird an die entsprechenden -Elemente als group-Attribut angehängt. A.2.11 Das Element beinhaltet alle Farbgruppen-Definitionen. A.2.12 Im Avatar-Editor EDGAR ist es möglich, verschiedene Farbgruppen (z. B. „Hautfarbe“ oder „Haarfarbe“) zu definieren. Dem -Element wird dabei über die Attribute R, G und B eine Farbe zugewiesen. Polygone lassen sich über das colorgroup-Attribut diesen Farbgruppen zuordnen (vgl. Listing A.2).

A.3 Beispiel für eine Avatar-Beschreibung

3

4

5 ... 6 7

8

9

10 ... 11 12

13

14

15 ... 16 ... 17 18

19 ...... 20 1 2

Listing A.2: Ausschnitt aus der ICE-FaceXML-Definition eines Avatar-Modells

B Avatar-Animationssprache Stefan Sölbrandt

B.1 ICE-FaceAnimXML-DTD

defaults (default)*> idles (idle)*> mappings (mapping)*> default (playanimation)> idle (playanimation)> mapping (playanimation)> playanimation (#PCDATA)> playanimation name CDATA #REQUIRED category #IMPLIED>

Listing B.1: ICE-FaceAnimXML-DTD

B.2 ICE-FaceAnimXML-Tags-Übersicht B.2.1 Jede Avatar-Animationsbeschreibung beginnt mit diesem Wurzelelement.

358

B Avatar-Animationssprache

B.2.2 Animationen lassen sich durch Grundanimationen zusammensetzen. Beispielsweise lässt sich durch Zusammenkneifen der Augen bei gleichzeitigem Herunterziehen der Brauen ein Gesichtsausdruck erzielen, der vom Betrachter als eher „böse“ empfunden wird. Analog dazu lassen sich aus der Kombination solcher Grundanimationen, die Augen-, Brauen-, Lippen- oder allgemein Kopfstellungen betreffen, eine vielfältige Palette von Gemütszuständen bzw. Emotionen darstellen (vgl. Abschnitt 12.4.2). Im Installationspaket sind bereits Animationskombinationen für eine ganze Reihe dieser Zustände, wie z. B. „freundlich“, „erschrocken“, „enttäuscht“, „angewidert“ oder „verängstigt“, vordefiniert. Zusätzlich werden auch kurze Bewegungssequenzen (z. B. für Kopfnicken oder Kopfschütteln) festgelegt oder Animationen, die den Avatar in Ruhestellung darstellen. Letztere werden in diesem Zusammenhang als Default-Animationen bezeichnet und stellen eine Art von Ankerpunkt dar, da der Avatar nach dem Abspielen anderer Animationen immer wieder zu ihnen zurückkehrt. Das Element fasst alle -Elemente zusammen. B.2.3 Das -Element beinhaltet genau ein -Element. B.2.4 Im -Element lässt sich eine beliebig komplexe Animationen zusammensetzen. Dieser wird über das Attribut name ein Referenzierungsname zugewiesen. Zusätzlich ist es möglich, über das category-Attribut Kategorien zu bilden. So lassen sich z. B. verschiedene Animationen einer Kategorie zuordnen. Das ist sinnvoll, da die Darstellungskomponente beim Abspielen einer Animation aus der Kategorie „freundlich“ aus einer Menge von Alternativen wählen kann. Das lässt den Avatar unvorhersehbarer in seinen Bewegungen erscheinen. Listing B.2 zeigt beispielhaft die Definition eines freundlichen Gesichtsausdrucks.

2 brows raised, head tilt center, mouth smiling1 3 1

Listing B.2: Beispiel-Definition eines freundlichen Gesichtsausdrucks

B.2.5 Das Element fasst alle -Elemente zusammen.

B.3 Avatar-Animationssprache – Beispielaufbau

359

B.2.6 Ein -Element beinhaltet analog zum -Element eine Animation, die über das -Element definiert wird. Idle-Animationen werden vom Avatar abgespielt, wenn der Nutzer über eine längere Zeitspanne keine Eingaben mehr getätigt hat. Der Avatar könnte dann z. B. mit besonderen Gesten (oder Grimassen) zu Aktionen des Nutzers animieren. Die Zeitspanne, die bis zum Einsetzen dieser Aktivität vergehen muss, lässt sich über Parameter einstellen. B.2.7 Das Element fasst alle -Elemente zusammen. B.2.8 Jedes -Element enthält jeweils ein -Element. Dieses Element wird verwendet, um Animationen bestimmten Namen zuzuweisen. Anders als bei den Default- bzw. Idle-Animationen werden die hier definierten Animationen nicht von der Darstellungskomponente aufgerufen. Das Abspielen der Animationssequenz wird hier explizit über Steuersymbole (Annotationen) im zu sprechenden Antworttext gestartet.

B.3 Avatar-Animationssprache – Beispielaufbau Ein Beispiel für eine Avatar-Animationsdatei ist in Listing B.3 zu sehen.

3

4

5

6 brows neutral, eyes wide, lids center, gaze center, ... 7

8

9

10

11

12

13 brows raised, head tilt center, mouth smiling1 1 2

360

B Avatar-Animationssprache

16 ... 17

18

19

20 brows raised, eyes wide, lids top, gaze center, ... 21

22

23

24

25 head down, wait4, head level, wait4, head down, wait3, head level 26

27

28 ... 29 14

15

Listing B.3: Beispiel-Definition von Avatar-Animationen

C Beispiel einer Raumerstellung in VRML Stefan Willer

Die Eigenschaften von VRML (siehe Abschnitt 250ff) sollen nun exemplarisch an einer Raumerstellung demonstriert werden. In über zehn aufeinander folgenden Schritten wird eine beispielhafte Einführung in die grundlegenden Eigenschaften von VRML gegeben. Für detailliertere Angaben sei auf die VRML2.0-Spezifikation1 des web3d-Konsortium verwiesen. VRML-Objekte werden als Textdatei mit einer Endung .wrl abgespeichert und müssen einen einleitenden Kommentar enthalten, der Auskunft über die VRML-Version und den Zeichensatz gibt. Diese erste Zeile ist notwendig für die Interpretation des Codes durch den Browser. Da VRML1.0 und VRML2.0 nicht kompatibel sind, wird der Browser somit angeleitet, den Code (Listing C.1) als VRML2.0 zu interpretieren. Im Folgenden wird zu jeder Codesequenz die passende Visualisierung der Bitmanagement2 -Weiterentwicklung von Blaxxun in Graustufen aufgeführt. Somit sollte der Code folgendermaßen beginnen: 1

#VRML V2.0 utf8 Listing C.1: VRML-Restriktionen

Von nun an wird der Code immer weiter vervollständigt (Listing C.2). Es kommen neue Knoten hinzu, die sich in einer Hierarchie anordnen lassen (sog. Szenengraph). Knoten dienen der Erstellung und der grafischen Gestaltung geometrischer Objekte sowie deren Gruppierung. Eine Hierarchie dient der Strukturierung des Inhaltes und stellt die Möglichkeit der Vererbung von Eigenschaften bereit.

1

Siehe http://www.web3d.org/x3d/specifications/vrml/vrml97/index.htm, besucht am 09.04.2005. 2 Bitmanagement-Software : www.bitmanagement.de, letzter Zugriff am: 06.05.2005.

362

C Beispiel einer Raumerstellung in VRML

Transform { translation 0 -0.5 15 5 children [ 6 Shape { 7 appearance Appearance { 8 material Material { 9 ambientIntensity 1 10 shininess .2 11 diffuseColor .3 .3 1 12 } 13 texture ImageTexture { 14 url "../img/misc/floor.gif" 15 } 16 } 17 geometry Box { 18 size 50 7 .2 19 } 20 } 21 ] 22 } 3 4

Listing C.2: Quader als Objekt

Ausgehend vom Transform-Knoten (Zeile 3), der als Gruppenknoten alle restlichen VRML-Inhalte kapselt, folgt der Unterknoten translation (Zeile 4), der eine Verschiebung aller hierarchisch untergeordneten Knoten bewirkt. Als Argument wird hier eine Kombination der x,y,z-Werte angegeben mit entsprechenden Werten für die Verschiebung in Achsenrichtung. Als Kindelemente wird im Listing ein Gestaltungsobjekt (Shape) mit zwei untergeordneten Knoten, appearance und geometry, aufgeführt. Dieses Gestaltungsobjekt gibt schließlich Auskunft über die Beschaffenheit des darzustellenden dreidimensionalen Objektes. Der Darstellung dienen u. a. material- und texture-Knoten. Der material-Knoten bestimmt z. B. die Reflektion von diffusem Licht (ambientIntensity), den Glanz des Objektes (shininess) oder die Farbe des reflektierten Lichtes (diffuseColor) (Zeilen 8 - 12). Der texture-Knoten ermöglicht es, ein Bild über das Objekt zu legen (Zeilen 13 - 15). Abschließend wird nun das eigentliche 3D-Grundobjekt mit seinen Ausmaßen angegeben (Zeilen 17 19) und in Abbildung C.1 visualisiert. Folgende Grundobjekte stehen zur Verfügung: • • • • • •

Box : ein Quader Cone : ein Kegel Cylinder : ein Zylinder Sphere : eine Kugel Text : ein Textobjekt ElevationGrid : Objekt zur Darstellung von Unebenheiten, die durch einzelne Grids (Felder) verursacht werden.

C Beispiel einer Raumerstellung in VRML

363

Es gibt noch weitere Darstellungsobjekte, die jedoch wesentlich mächtiger sind und deshalb in diesem Beispiel außer Acht gelassen werden. Bei Interesse sei auf die Spezifikation in [Kloss u. a. 1998] verwiesen.

Abb. C.1: Mauer als erstes dreidimensionales Objekt

Bei der Erstellung einer eigenen Welt kann es leicht zu einer kaum überschaubaren Anzahl an darzustellenden Objekten kommen. Hierbei gleichen sich in der Regel viele Objekte, so dass VRML das Konzept der Wiederverwendung unterstützt. Transform-Objekte können daher mittels des Schlüsselwortes DEF als wiederverwendbar gekennzeichnet werden und im weiteren Verlauf mittels des Schlüsselwortes USE referenziert werden. Diese Menge an Definitionen wird jedoch nicht aus einem Pool bzw. einer Bibliothek entnommen, sondern kann nach der ersten Verwendung/Deklaration im folgenden Kontext benutzt werden. Komplexere Objekte werden in so genannten (EXTERN)PROTOs gekapselt, die u. a. einen eigenen Namensraum für Definitionen haben. Auf PROTOs wird in diesem einführenden Beispiel verzichtet. Näheres entnehme der Leser der VRML-Spezifikation3 . Im aktuellen Beispiel Listing C.3 und zugehöriger Abbildung C.2 wird die Erstellung der Wände und des Bodens beschrieben, wobei die erste Wand (Zeile 3) mit einer Definition zugänglich gemacht und später (in Zeile 28) referenziert wird. Um eine Verschiebung der Wand zu gewährleisten, wird ein zusätzliches translation-Objekt der Referenz vorangestellt.

3 Siehe http://www.web3d.org/x3d/specifications/vrml/vrml97/index.htm, besucht am 09.04.2005.

364

C Beispiel einer Raumerstellung in VRML

DEF wall_long Transform { translation 0 -0.5 15 5 children [ 6 Shape { 7 appearance Appearance { 8 material Material { 9 ambientIntensity 1 10 shininess .2 11 diffuseColor .3 .3 1 12 } 13 texture ImageTexture { 14 url "../img/misc/floor.gif" 15 } 16 } 17 geometry Box { 18 size 50 7 .2 19 } 20 } 21 ] 22 } 23 # wall north 3 4

24

Transform { translation 0 0 -30 27 children [ 28 USE wall_long 29 ] 30 } 25 26

Listing C.3: Wiederverwendbarkeit von Objekten

Abb. C.2: Raumumriss mit Boden

C Beispiel einer Raumerstellung in VRML

365

Nachdem die äußeren Objekte erstellt wurden, wird schnell ersichtlich, dass Lichteinwirkungen für den inneren Aufbau des Raumes unerlässlich sind. VRML sieht hierfür verschiedene Objekte vor, die spezielle Lichteigenschaften darstellen. Die einfachste und häufig genutzte Lichtquelle bildet z. B. die Sonne nach und erhellt somit einen Bereich gleichmäßig (directionalLight). Weiterhin gibt es die Objekte PointLight und SpotLight. Das PointLight stellt eine punktförmige Lichtquelle dar, die in alle Richtungen scheint. Das SpotLight dagegen produziert einen gerichteten Lichtkegel, der u. a. als Schirmleuchte eingesetzt werden kann. Alle Lichtobjekte besitzen zur näheren Spezifizierung Kindelemente, z. B. zur Bestimmung der Farbe (color), der Lichtintensität (intensity) oder der Intensität der Rückstrahlung (ambientIntensity). Speziell DirectionalLight und SpotLight verfügen über eine Richtungskomponente (direction). Im Beispiel (Listing C.4) wird das Umgebungslicht als DirectionalLight simuliert. Außer der Richtung (Zeile 4) und der Rückstrahlung (Zeile 5) werden die Standardwerte für Farbe, Intensität und Sichtbarkeit übernommen. Die Abbildung C.3 veranschaulicht die Veränderungen. DirectionalLight { direction -0.2 -0.8 -0.6 5 ambientIntensity 0.5 6 } 3 4

Listing C.4: Lichteinwirkungen

Abb. C.3: Raumdarstellung ohne (links) und mit Lichteinwirkung (rechts)

Nun ergibt sich ein Raumgebilde, das Wände, Boden und Decke beinhaltet und mit Licht ausgestattet ist. Um einem Avatar den Raum zugänglich zu machen, werden Initialisierungspunkte beschrieben, von denen aus der Avatar seine Route beginnen kann. Diese Initialisierungspunkte werden als Viewpoint bezeichnet. Neben einem Viewpoint zum Betreten des Raumes kann es weitere geben, zwischen denen gewechselt werden kann. Ein Viewpoint wird durch Koordinaten (position), die Blickrichtung (orientation) und den Blickwinkel (fieldOfView) näher spezifiziert (Listing C.5). Neben diesen Kindelementen existieren noch weitere optionale Elemente, wie

366

C Beispiel einer Raumerstellung in VRML

z. B. eine Beschreibung des Standortes oder die Zeit, nach der der Avatar erscheinen soll. Transform { children [ 12 Viewpoint { 13 fieldOfView 0.785398 14 position 25 -1.75 0 # x-axis=25 in door | y-axis =-1.75 Avatar stands on the floor | z-axis=0 middle of the door 15 orientation 0 1 0 1.57 # turn pi/2(90degree) around y-axis 16 description "one" 17 } 18 Group { 19 children [ 20 DEF wall_long Transform { 10 11

Listing C.5: Viewpoints und Gruppen

Abb. C.4: Erster Viewpoint als Ausgangspunkt

Im Folgenden wird der Raum sukzessive erweitert. Eine Erweiterung (Abb. C.5 und Listing C.6) erfolgt durch Hinzufügen von neuen Elementen, die den Raum realistischer erscheinen lassen. Neben dem künstlerischen Geschick, auf das hier nicht eingegangen werden soll, können Elemente mit Multimedia-Inhalten versehen werden (Zeile 167). Über die Verbindung eines Elementes mit einer URL wird z. B. ein Web-Browser angesprochen. Hiermit wird die Integration von Web-Content in eine virtuelle Welt ermöglicht. In Listing C.6 wird dem Besucher über Bilder, die als VRML-Objekte an der Wand plaziert werden, die Themensuche erleichtert. Nach

C Beispiel einer Raumerstellung in VRML

367

der Wahl eines Themas kann über einen Link auf weiterführenden Inhalt verwiesen werden. 160 161

# Pictures # south

#Picture south 1 Transform { 164 translation -8.333333333333336 -0.5 14.7 165 children [ 166 Anchor { 167 url "http://[SERVER-IP]/ice/bfe/flash/index. swf?modul=movie/050103_001.swf&titel= Anwendungen" 168 description "Anwendungen von Motorsteuerungen " 169 parameter [ 170 "target=_blank" 171 ] 172 children [ 173 Transform { 174 children [ 175 Shape { 176 appearance Appearance { 177 material Material { 178 diffuseColor 1 1 1 179 } 180 texture ImageTexture { 181 url "../Abbildungen/ Motorsteuerung. jpg" 182 } 183 } 184 geometry Box { 185 size 5 3 0.001 186 } 187 } 188 ] 189 } 190 ] 191 } 192 ] 193 } 162 163

Listing C.6: Einbindung von URLs

Je detaillierter eine Welt wird, desto unüberschaubarer kann sie damit auch werden. Außerdem steigt die Größe erheblich, die somit das Laden im VRML-Browser be-

368

C Beispiel einer Raumerstellung in VRML

Abb. C.5: Einbindung von interaktiven Medientypen

einträchtigt. Um diesen Gegebenheiten gerecht zu werden, können VRML-Objekte ausgelagert werden. Diese externen Ressourcen werden dann zur Laufzeit nachgeladen (browserabhängig). In Listing C.7 wird über das Schlüsselwort Inline eine externe Ressource inkludiert. In Abbildung C.6 und Abbildung C.7 sind diese in Form von Deckenstrahlern und Mobiliar zu sehen. 447 448

# tracklights external objects to reuse DEF tracklights_west Inline { url [ " tracklights_west.wrl" ]} Listing C.7: Externe Ressourcen

Abb. C.6: Einbindung von wiederverwendbaren statischen externen Objekten

C Beispiel einer Raumerstellung in VRML

369

Das Ergebnis dieser kleinen Einführung stellt nun einen eingerichteten Raum (siehe Abb. C.7) dar, wie dieser im I-can-EIB-System verwendet wird. VRML ist jedoch weitaus mächtiger, als in diesem kleinen Beispiel demonstriert werden konnte. Die angesprochenen Knoten sollen lediglich einen Einstieg bzw. ein grobes Verständnis ermöglichen. Die Spezifikation ist bei der Entwicklung genauso unerlässlich wie CASE-Tools, um die entstehende Komplexität zu handhaben.

Abb. C.7: Eingerichteter Raum

D Definition AgentScript Markup Language Jens Krefeldt und Jörg Stumpe

1

2 3

4

5 6

9 10

11 12

13

14 15

19 20

21 22

23

24 25

30 31

32 33 34

372

D Definition AgentScript Markup Language

35

36

38 39

40

41 42

44 45

46 47

48

49

50

Listing D.1: Document Type Definition für AgentScript Markup Language

E W3 xtract Stefan Sölbrandt

E.1 Das Wetterbeispiel Listing E.1 zeigt den Ausschnitt einer HTML-Seite, die in ähnlicher Form von einem Wetterinformationsdienst täglich aktualisiert im Internet veröffentlicht wird. Mit dem W3 xtract-Tool lassen sich Informationen aus Webseiten vergleichbaren Aufbaus extrahieren. ...

%WETTERVORHERSAGE
’), succ(X,’
“ und „	“ in „	“ und „“ in „
...... Das milde Wetter in Niedersachsen...	... 3 In Thüringen wird es überwiegend... 4

< /tr> 3 10

Die Wetterlage
		4 5 6 ... 7 8 Die Kaltfront eines Tiefs überquert heute Deutschland von Nordwest nach Südost, dahinter strömt kühlere Meeresluft zu uns. 9

... 11 1 2

Listing E.1: Ausschnitt einer HTML-Seite mit Informationen über die aktuelle Wetterlage

374

E W3 xtract

E.2 W3 xtractConfig-DTD

(sourcefile,destfile)> (#PCDATA)> (#PCDATA)> ]>

Listing E.2: W3 xtractConfig-DTD

E.3 W3 xtractConfig-Tags-Übersicht E.3.1 Dieses Tag spezifiziert das Wurzelelement jeder W3 xtract-Konfigurationsdatei. E.3.2 Das -Tag erlaubt die Definition eines Verweises auf eine Log-Datei, die zur Speicherung eventuell auftretender Fehler in der Verarbeitung genutzt wird. E.3.3 Bei diesem Tag handelt es sich um das Topelement für die Konfiguration jedes W3 xtract-Jobs. E.3.4 Die Definitionen der W3 xtract-Jobs stehen in ausgelagerten XML-Dateien. Das -Tag beinhaltet einen Verweis auf eine solche Datei. E.3.5 Dieses Tag definiert die Zieldatei eines W3 xtract-Jobs. Die extrahierten Informationen einer Webseite werden im XML-Format in diese Zieldatei geschrieben. Der Aufbau dieses XML-Dokuments wird in der zugehörigen W3 xtract-Job-Datei genau spezifiziert.

E.5 W3 xtractJob-DTD

375

E.4 W3 xtractConfig – Beispielaufbau Ein Beispiel für eine W3 xtractConfig-Datei, die einen Job für die Extraktion der Wetterdaten ausführt, zeigt Listing E.3.

3 ./errorout.txt 4

5 ./wextract_wetter.xml 6 ./wetterresult.xml 7

8 1 2

Listing E.3: Beispielaufbau einer W3 xtractConfig-Datei

E.5 W3 xtractJob-DTD

12 1 2

(uri,(wwwxtractinfo)*,( (#PCDATA)> (name,(xpath | systemdate))> (#PCDATA)> (#PCDATA)> (#PCDATA)> ((outelement)*)> (outname,outvalue)> (#PCDATA)> (((outelement)*) | outstring | (#PCDATA)> (#PCDATA)>

Listing E.4: W3 xtractJob-DTD

376

E W3 xtract

E.6 W3 xtractJob-Tags-Übersicht E.6.1 Dieses Tag spezifiziert das Wurzelelement jeder W3 xtract-Job-Konfigurationsdatei. E.6.2 Das -Tag enthält den Verweis auf die Webseite, die zur Datenextraktion herangezogen wird. E.6.3 Dieses Tag kennzeichnet einen Block mit Anweisungen, der hier W3 xtractInfo genannt wird. Er beschreibt, wie eine bestimmte Information aus der angegebenen Webseite extrahiert werden kann. E.6.4 Das -Tag erlaubt die Angabe eines Identifikationsnamens. Anhand dieses Namens lässt sich die gewonnene Information im weiteren Verlauf der Verarbeitung referenzieren. Dieser Vorgang lässt sich also mit der Wertzuweisung einer Variablen vergleichen. E.6.5 Die gebräuchlichste Verwendung einer W3 xtractInfo erfolgt im Zuge einer Datenextraktion mittels XPath-Ausdruck. Dieser spezifiziert ein Element (meistens ein Textknoten) im intern generierten DOM-Baum der Webseite. E.6.6 Außer der Informationsgewinnung aus der Webseite kann es auch sinnvoll sein, Informationen des Extraktionskontexts für die Ausgabedatei zu sammeln. Mittels des -Tags lässt sich die aktuelle Systemzeit speichern. Die Referenzierung erfolgt analog zu über die im -Tag angegebene Zeichenfolge.

E.6 W3 xtractJob-Tags-Übersicht

377

E.6.7 Dieses Tag leitet den Definitionsblock für den Aufbau der XML-Ausgabedatei ein. Sie besteht aus einer Menge von Name-Value-Paaren, wobei die Name-Elemente ineinander verschachtelt sein können. Mit den folgenden Tags lässt sich eine Ausgabe solcher Name-Value-Paare definieren. E.6.8 Jedes -Tag enthält ein - und ein 5 6 7 8 9 10 11 12 13 14 4

15

17 18 19 20 21 25 16

26 27

28 29 30 31 32 33 34

37 35 36

38

40 41 42 43 39

44 45 46

Listing G.1: DTD für die Konfiguration des MAS

H Phonem-Übersicht Holger de Vries

Dem Konsonantensystem der deutschen Sprache werden in der Regel 17 bzw. 19 konsonantische Phoneme zugerechnet, abhängig davon ob gewisse Laute aus Lehnwörtern hinzugezählt werden (z. B. Dschungel). Die konsonantischen Phoneme werden unterschieden in sechs Plosive (Tab. H.1a), drei Affrikaten (Tab. H.1b), acht Frikative (Tab. H.1c) und zwei Approximanten (Tab. H.1d). Hinzu kommen fünf Sonoranten, die sich in drei Nasale (Tab. H.1e) und zwei Vibranten (Tab. H.1f) aufteilen. Zum Vokalsystem des Deutschen gehören insgesamt 21 vokalische Phoneme, die sich unterscheiden in sieben Kurzvokale (Tab. H.2a), acht Langvokale (Tab. H.2b), vier Diphthonge (Tab. H.2c) und zwei schwache Vokale (Tab. H.2d). Außerdem sind einige BOMP-spezifische (siehe Abschnitt 11.1.2) Erweiterungen aufgeführt. Dabei handelt es sich um drei Nasalvokale (Tab. H.2e) und drei nicht-silbische Vokale (Tab. H.2f). In der SAMPA-Notation (siehe Abschnitt 11.1.1) werden Wortbetonungen mit einem Hochkomma vor einer Silbe markiert, außer in einsilbigen Wörtern. Sekundäre Betonungen können durch ein Komma kenntlich gemacht werden. Folgt ein Doppelpunkt auf einen Vokal, wird dieser gedehnt. Silbengrenzen werden durch einen senkrechten Trennstrich repräsentiert (vgl. [Gibbon 1997]).

386

H Phonem-Übersicht Tabelle H.1: Konsonanten-Phoneme des SAMPA-Alphabets mit Beispielen

Symbol

Wort

p

Pein

paIn

stimmloser bilabialer Plosiv

b

Bein

baIn

stimmhafter bilabialer Plosiv

t

Teich

taIC

stimmloser alveolarer Plosiv

d

Deich

daIC

k

K unst

g

Gunst

Transkription Symbol

Wort

Transkription

pf

Pfahl

pf a:l

ts

Zahl

tsa:l

stimmhafter alveolarer Plosiv

tS

deutsch

dOYtS

kUnst

stimmloser velarer Plosiv

dZ

Dschungel

dZUN@l

gUnst

stimmhafter velarer Plosiv

b) Affrikaten

a) Plosive Symbol

Wort

Transkription

f

fast

fast

stimmloser labiodentaler Frikativ

s

Tasse

tas@

stimmloser alveolarer Frikativ

z

Hase

ha:z@

stimmhafter alveolarer Frikativ

S

waschen

vaS@n

stimmloser postalveolarer Frikativ

Z

Genie

Zeni:

stimmhafter postalveolarer Frikativ

C

sicher

zIC@r

stimmloser palataler Frikativ

x

Buch

bu:x

stimmloser velarer Frikativ

h

Hand

hant

stimmloser glottaler Frikativ

c) Frikative Symbol

Wort

Transkription

v

was

vas

stimmhafter labiodentaler Halbvolkal

j

Jahr

ja:r

palataler Halbvokal

d) Approximanten Symbol

Wort

Transkription

m

mein

maIn

n

nein

N

Ding

e) Nasale

Symbol

Wort

Transkription

bilabialer Nasal

l

Leim

laIm

lateraler Vibrant

naIn

alveolarer Nasal

r

Reim

raIm

uvularer Frikativ

dIN

velarer Nasal

f) Vibranten

H Phonem-Übersicht Tabelle H.2: Vokal-Phoneme des SAMPA-Alphabets mit Beispielen

Symbol

Wort

Transkription

I

Sitz

zIts

ungespannter kurzer ungerundeter vorderer Vokal

E

Gesetz

g@zEts

ungespannter kurzer ungerundeter halboffener vorderer Vokal

a

Satz

zats

offener hinterer Vokal

O

Trotz

trOts

ungespannter kurzer halboffener hinterer Vokal

U

Schutz

SUts

ungespannter kurzer gerundeter geschlossener hinterer Vokal

Y

hu¨ bsch

hYpS

ungespannter kurzer gerundeter geschlossener vorderer Vokal

9

pl o¨ tzlich

pl9tslIC

gerundeter halboffener vorderer Vokal

a) Kurzvokale Symbol

Wort

Transkription

i:

Lied

li:t

gespannter langer ungerundeter geschlossener vorderer Vokal

e:

Beet

be:t

gespannter langer ungerundeter halbgeschlossener vorderer Vokal

E:

sp¨at

SpE:t

gespannter langer ungerundeter halboffener vorderer Vokal

a:

Tat

ta:t

langer offener hinterer Vokal

o:

rot

ro:t

gespannter langer halbgeschlossener hinterer Vokal

u:

Blut

blu:t

gespannter langer gerundeter geschlossener hinterer Vokal

y:

s¨uß

zy:s

gespannter langer gerundeter geschlossener vorderer Vokal

2:

bl o¨ d

bl2:t

gerundeter halbgeschlossener vorderer Vokal

b) Langvokale Symbol

Wort

Transkription

aI

Eis

aIs

aU

Haus

haUs

OY

Kreuz

krO Yts

EI

Spray

sprEI

Symbol

Wort

Transkription

Symbol

Wort

Transkription

O

Jargon

ZargO