This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
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.
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 I-can-EIB@offis.de 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
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
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.
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.
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
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
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])
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 arbei-
tet 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:
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
...
%WETTERVORHERSAGE
... 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,’
’), succ(X,’
’).
Die Zeile drückt aus, dass nach einer Textstelle im Dokument gesucht wird, die von den Zeichenfolgen „
“ und „
“ 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 „
“ in „
“ und „“ in „
“ 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. ...
...
Das milde Wetter in Niedersachsen...
...
... 3
In Thüringen wird es überwiegend...
4
...
...... 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).
!
!
! "# $%&'"(
231 4 5&'"#
)*% + $%&'"(
, ".
/ . s s
65 ". #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
_inReader = new java.io.InputStreamReader(connection. getInputStream()); _in = new java.io.BufferedReader(_inReader); _inputLine = new java.lang.String(); _reply = new java.lang.String();
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 3 4 ... 5 6 7 ... 8 9 10 ... 11 12 13 14 15 ... 16 17 18 19 20 ... 21 22 23 1
2
Listing 14.11: Beispiel für ein Agentenskript
59
Mit dem Paket vnet.client.script und seinen Unterpaketen.
254
14 Wissensmarktplatz mit Agenten und Avataren
Listing 14.12 zeigt die formale Definition von Skriptpunkten in der ASML-DTD. Name und Beschreibung eines Agentenskripts sind optional. Es hat als zusätzliche Elemente eine Menge von Skriptpunkten und von Subskripten. Die oben genannten Eigenschaften werden nachfolgend näher betrachtet. 1
2
Listing 14.12: Agentenskript
Skriptpunkte Ein Skript enthält in seiner obersten Ebene neben möglichen Subskripten bestimmte Punkte (Skriptpunkte), die sequentiell durchlaufen werden. An diesen Punkten (z. B. der Skriptpunkt mit der ID 2 in Listing 14.13) können beliebige, parametrisierte Verhaltensklassen ausgeführt werden. Skriptpunkte erhalten eine ID, damit auf diesen Ein- und Aussprungspunkte für Subskripte definiert werden können (s. u.). ... 3 4 5 6 7 ... 8 9 10 11 12 13 ... 14 15 16 17 ... 18 1 2
Listing 14.13: Skriptpunkte
14.3 Entwicklung mit VRML, AgentScript und JADE
255
Listing 14.14 zeigt die formale Definition von Subskripten in der ASML-DTD. Name und Beschreibung eines Subskripts sind optional, während die Angabe des Attributs id als Ein- oder Aussprungspunkt vorgeschrieben ist. 1
2
Listing 14.14: Element- und Attributdefinition in der ASML-DTD für Skriptpunkte
Verhaltensdefinition Die Verhalten können seriell oder parallel abgearbeitet werden (wird durch das Attribut sequence bestimmt, siehe Listing 14.15). 3 1
2
Listing 14.15: Element- und Attributdefinition in der ASML-DTD für Verhaltenssequenzen
Das Element enthält mehrere Verhaltenssequenzen, die wiederum die einzelnen Verhalten beinhalten. Die Angabe, ob die Verhalten in einer Sequenz hintereinander oder parallel ausgeführt werden, ist obligatorisch. In Listing 14.16 ist eine serielle Verhaltenssequenz dargestellt (siehe auch Abb. 14.23), in der Folgendes hintereinander passiert: 1. Der Agent läuft von seinem aktuellen Standort zu dem 3D-Punkt (-15.0, 0.0, 8.0). 2. Dort bleibt er für drei Sekunden stehen. 3. Anschließend übermittelt er den Satz „Das ist interessant!“. 4. Dann wartet er eine Sekunde. 5. Zuletzt setzt er seinen Weg fort zu der Koordinate (-13.5, 0.0. -6.0).
Listing 14.16: Beispiel für eine serielle Verhaltenssequenz
Das Element enthält das Attribut className (siehe Listing 14.17), das als Wert den voll qualifizierten Klassennamen des Verhaltens besitzt, damit das Verhalten zur Laufzeit in den Speicher geladen werden kann. Die JADE-Implementation von ASML instanziiert aufgrund dieser Angabe dynamisch das richtige Verhalten. Die Angabe dieses Attributs ist obligatorisch.
14.3 Entwicklung mit VRML, AgentScript und JADE
1 2
257
Listing 14.17: Element- und Attributdefinition in der ASML-DTD für Verhalten
Abb. 14.23: Skriptablauf für Listing 14.16
Einige Konstruktoren von Verhaltensklassen erfordern die Übergabe von formalen Parametern, wie z. B. die X-, Y - und Z-Koordinaten für ein Laufverhalten zu einem bestimmten Punkt im Raum (siehe Listing 14.18). public WalkBehaviour(float x, float y, float z){ super(STEP_PERIOD); 3 this.x = x; 4 this.y = y; 5 this.z = z; 6 ... 7 } 1 2
Listing 14.18: Übergabe von formalen Konstruktorparametern
258
14 Wissensmarktplatz mit Agenten und Avataren
ASML unterstützt die Übergabe einer Liste von Werten der primitiven Typen boolean, byte, char, short, int, long, float oder double und von String-Objekten wie in Listing 14.19 beschrieben. 3 1
2
Listing 14.19: Element- und Attributdefinition in der ASML-DTD für Parameter
In Listing 14.20 werden die Koordinatenparameter eines 3D-Punkts für ein Laufverhalten festgelegt. 2 3 4 5 6 7 1
Listing 14.20: Parameter für Verhalten
Die einzelnen -Elemente werden für jedes Verhalten als Liste in dem Element gebündelt. Die Reihenfolge der Parameterangaben bestimmt deren Parameterposition im Konstruktor. Angewendet auf das obige Beispiel (Listing 14.18) bedeutet das für die Koordinaten: X = 13.1758, Y = 0.0 und Z = 34.1758. Der Programmierer eines Skripts ist für eine korrekte Angabe der Formate (d. h. den Wert des Attributs value) verantwortlich, da sie im Konstruktor des entsprechenden Verhaltens erwartet werden.
Subskripte Skriptpunkte können Subskripte enthalten, die zyklisch bzw. nicht zyklisch durchlaufen oder randomisiert werden. Subskripte sind also Verzweigungen innerhalb eines
14.3 Entwicklung mit VRML, AgentScript und JADE
259
Skripts. Sie bestehen wiederum aus Skriptpunkten, an denen wieder neue Subskripte betreten werden können, die dann rekursiv abgearbeitet werden. Listing 14.21 verdeutlicht, wie Skriptpunkte in Subskripten referenziert werden, indem Ein- und Aussprungspunkte durch Skriptpunkt-IDs festgelegt werden. Das heißt, der Ablauf des Subskripts mit Namen subscript1 wird zuerst durch die Definition von Skriptpunkten festgelegt. Jeder Skriptpunkt wird dabei mit einer ID bezeichnet. Erst dann wird ein Subskript angelegt, das genau einen Ein- und einen Aussprungspunkt besitzt. In Listing 14.21 hat das Subskript subsubscript1 als Ein- bzw. als Aussprungspunkt eine Referenz auf die Skriptpunkte mit ID 4 bzw. ID 7. Verschiedene Subskripte können die gleichen Ein- und Aussprungspunkte besitzen. Die AgentScript-Implementation für JADE wählt in diesem Fall die Subskripte zufällig aus. 3 ... 4 5 ... 6 7 ... 8 9 ... 10 11 ... 12 13 14 15 16 17 ... 18 19 20 21 22 1
2
Listing 14.21: Festlegung von Ein- und Aussprungspunkten anhand von Skriptpunkt-IDs
Listing 14.22 zeigt die formale Definition von Subskripten in der ASML-DTD. Name und Beschreibung eines Subskripts sind optional, während (analog zu oben) die Angabe der Ein- und Aussprungspunkte Pflicht ist.
260
14 Wissensmarktplatz mit Agenten und Avataren
1 2
Listing 14.22: Subskript Element- und Attributdefinition in der ASML-DTD
JADE-Implementation Um ASML sinnvoll zu nutzen, müssen in einer Interpreter-Implementation für ein Agentensystem folgende Anforderungen umgesetzt werden: 1. Es gibt ein übergeordnetes Verhalten (Interpreter), welches das eingelesene Skript ausführt. Dieses Verhalten kann einem Agenten zugeordnet werden, so dass dieser die Kontrolle über seine geskripteten Verhaltensweisen besitzt. 2. Die einem Agenten zugeordneten Verhalten müssen beim Start eines Agenten über ein XML-API eingelesen und dynamisch von einem Reflection-API initialisiert werden. 3. Parallele und sequentielle Verhaltensabarbeitung muss möglich sein. 4. Der Interpreter kann zu jedem Zeitpunkt feststellen, an welchem Punkt sich das Skript befindet. 5. Das Skript kann vom Agenten verlassen werden, um auf Anfragen von „außen“ zu reagieren (z. B. möchte ein Chatteilnehmer vom Agenten eine Frage beantwortet haben). Der Skriptablauf wird im Moment des Verlassens vom Interpreter „eingefroren“. Bei Rückkehr des Agenten wird er an genau dieser Stelle fortgesetzt. 6. Subskripte können randomisiert ausgeführt werden, um einen Agenten unberechenbar erscheinen zu lassen. 7. Es wird erlaubt, dass ein Skript zyklisch durchlaufen wird, d. h., ist der letzte Skriptpunkt erreicht, wird das Skript erneut gestartet. Um diese Anforderungen zu erfüllen, wurden die Pakete vnet.client.script und vnet.client.script.io erstellt. Das Paket vnet.client.script.io umfasst die zwei Klassen ScriptBuilder und XMLReader. Diese Klassen benutzen das XML-API JDOM60 , um die einzelnen Elemente und Attribute aus der XML-Datei zu extrahieren und mit der BuilderKlasse die XML-Daten in Java-Objekte (s. u.) umzuwandeln. Im Paket vnet.client.script sind die Kerndateien für die JADE-Implementation von AgentScript enthalten: 60
Siehe http://www.jdom.org, besucht am 29.03.2005.
14.3 Entwicklung mit VRML, AgentScript und JADE
261
• AbstractScript: Diese abstrakte Oberklasse vereint die gemeinsamen Eigenschaften der Klassen AgentScript und SubScript: – Variablen und Methoden für das Abfragen und Setzen des Namens und die Beschreibung des Skriptes. – Listen, in denen die Skriptpunkte und Subskripte gehalten werden. – Konkrete Methoden, um Skriptpunkte oder Subskripte zu entfernen und hinzuzufügen. – Eine Variable, konkrete Methoden für das Abfragen und Setzen eines Skriptpunktes und eine abstrakte Methode um einen aktuellen61 Skriptpunkt auszuwählen. • AgentScript: Dies ist das analoge Java-Objekt zum -Element. Es kapselt alle ScriptPoint-Objekte und führt diese zyklisch oder azyklisch aus. An jedem Skriptpunkt wird auf mögliche Verzweigungen in Subskripte geprüft und wenn vorhanden, zufällig ausgeführt (siehe Abb. 14.24).
Abb. 14.24: Aktivitätsdiagramm für den Skriptablauf
• SubScript: Dieses Objekt wird aus dem -Element erzeugt. Es enthält Referenzen auf sein Vaterskript und auf den Ein- und Ausstiegspunkt in diesem. Alle vorhandenen Skriptpunkte werden nacheinander traversiert. Enthält 61
Der Skriptpunkt, der umgehend zur Ausführung ansteht.
262
14 Wissensmarktplatz mit Agenten und Avataren
ein Skriptpunkt eine oder mehrere Verzweigungen in weitere Subskripte, wird zufällig entschieden, ob in eines von diesen verzweigt oder der nächste Skriptpunkt angesprungen wird (siehe Abb. 14.24). • BehaviourClass: Beim dynamischen Einlesen62 einer Verhaltensklasse aus einem ASML-Skript (siehe auch Listing 14.16) wird über ihren voll qualifizierten Klassennamen ein BehaviourClass-Objekt erstellt. Dieses kapselt ein fertiges JADE Behaviour-Objekt, das über die Methode newInstance() referenziert werden kann. • BehaviourList: Diese Liste enthält entsprechend zum Element ein Reihe von Verhalten. Diese Liste ist von java.util.ArrayList abgeleitet und zusätzlich mit der Information versehen, ob die Verhalten parallel oder sequentiell abgearbeitet werden. • Parameter: Ein -Element wird beim Erstellen eines Verhaltensobjektes in ein Objekt vom Typ Parameter eingelesen und an seinen entsprechenden Verhaltenskonstruktor übergeben. public class EAIClientAgent extends BasicAgent{ protected ScriptControlBehaviour scriptControlBehaviour; 3 ... 4 protected void setup() { 5 ... 6 scriptControlBehaviour = new ScriptControlBehaviour(this, scriptURL); 7 addBehaviour(scriptControlBehaviour); 8 ... 9 } 10 } 1 2
Listing 14.23: Zuweisung des Skriptkontrollverhaltens
• ScriptControlBehaviour: Für die Kontrolle des Skripts ist diese Klasse zuständig. Ein Agent initialisiert ein Objekt dieser Klasse und fügt es seinem Verhaltenspool hinzu. Dies bietet sich bei einem JADE-Agenten in seiner setup()Methode an (siehe Listing 14.23). Abbildung 14.25 zeigt den Kontrollfluss eines Agentenskripts. Das ScriptControlBehaviour-Objekt führt das Skript Punkt für Punkt aus, bis eine Unterbrechung von außen – z. B. durch das Ansprechen des Agenten, dem das Skript zugeordnet ist – erfolgt. In diesem Fall reagiert der Agent auf die Unterbrechung, wobei das Skript suspendiert wird. Nachdem die Reaktion auf die Unterbrechung beendet ist, wird das Skript an der unterbrochenen Stelle fortgesetzt. In Listing 14.24 initiiert die Interpreterklasse ScriptControlBehavior das Einlesen des Skripts über die Hilfsklassen 62
Nutzung des Java Reflection-API.
14.3 Entwicklung mit VRML, AgentScript und JADE
263
XMLReader und ScriptBuilder (s. o.). Das fertige Skript wird als aktuelles eingesetzt (Zeile 9 – 11). private AgentScript agentScript; ... 3 private void initScript(InputStream in){ 4 Document doc = new XMLReader(in).getDocument(); 5 buildScript(doc); 6 } 1 2
Listing 14.24: Erstellung der Skriptobjekte mit dem XML-API
• ScriptPoint: Die Klasse ist das Pendant zum -Element. Sie stellt Methoden zum Abfragen und Setzen der Informationen zu ID, Name und Beschreibung des Skriptpunktes zur Verfügung und führt eine Liste von Verhaltenssequenzen, die an diesem Punkt ausgeführt werden können.
Abb. 14.25: Aktivitätsdiagramm für die Skriptkontrolle
Nachfolgender Abschnitt befasst sich damit, welche Verhalten die JADE-Implementation für ASML mit dem Paket vnet.client.script.behaviours zur Verfügung stellt und wie neue Verhalten erzeugt werden können.
264
14 Wissensmarktplatz mit Agenten und Avataren
14.3.3 JADE-Verhaltensentwicklung für AgentScript Ein Agent muss neben seinen intrinsisch motivierten Verhaltensweisen in der Lage sein, mehrere Aufgaben, die sich aus Reaktionen auf externe Ergeignisse ergeben, simultan abzuarbeiten. Von den in JADE angebotenen Basisverhalten (siehe auch Abschnitt 14.2.2) abgeleitet, wurden deshalb spezielle Verhalten implementiert, die über die AgentScript Markup Language (ASML) zur Gestaltung der Drehbücher für Agenten verwendet werden können.
„Lauf“-Verhalten Das WalkBehaviour lässt einen Agenten zu einem bestimmten Punkt in der VRMLWelt gehen und dreht ihn in eine bestimmte Richtung, wenn er dort angekommen ist. Gesteuert werden kann, neben dem Zielpunkt, sowohl die Geschwindigkeit, mit der der Agent laufen soll, als auch die Länge eines Schrittes. Die Blickrichtung wird mit einem Winkel von 0◦ bis 360◦ relativ zur Raumachse der VRML-Welt bestimmt. Abgeleitet ist das WalkBehaviour von der JADE-Basisklasse TickerBehaviour bzw. von dem neu definierten AbstractBlockableTickerBehaviour, da die Basisklasse ein Blocken nicht ermöglicht63 . 1
public WalkBehaviour(float x, float y, float z){...}
2 3
public WalkBehaviour(float stepWidth, long period, float x , float y, float z){...}
4 5
public WalkBehaviour(float x, float y, float z, float orientationDegAngle){...}
6 7
public WalkBehaviour(float x, float y, float z, int stopSteps){...}
8 9
public WalkBehaviour(float stepWidth, long period, float x , float y, float z, float orientationDegAngle){...} Listing 14.25: Konstruktoren für das WalkBehaviour
Zur Initialisierung stehen eine Vielzahl von Konstruktoren (siehe Listing 14.25) zur Verfügung. Als Parameter wird grundsätzlich der Zielpunkt des Agenten mit einzelnen Werten für die X-, Y- und Z-Koordinate festgelegt. Dabei sind Einschränkungen durch die Datentypen für Parameter, die durch ASML übergeben werden können, zu berücksichtigen. Das Laufverhalten kann durch die Werte für die Schrittweite (stepWidth) und die Geschwindigkeit (period) beeinflusst werden. Ein weiterer 63
Näheres hierzu im Beispiel für Verhaltensentwicklung in Abschnitt 14.3.4.
14.3 Entwicklung mit VRML, AgentScript und JADE
265
Konstruktor initialisiert den Blickwinkel (orientationDegAngle), d. h. die Richtung, in die der Agent am Ende der Route schaut. Der Blickwinkel ist relativ zur Raumachse, nicht zur Blickwinkelachse des Agenten. Da das Laufverhalten auch vom „Treffpunkt“-Verhalten (MeetingBehaviour, s. u.) verwendet wird, kann mit dem Parameter stopSteps die Anzahl der Schritte bestimmt werden, die der Agent vor dem eigentlichen Ende seiner Route stehen bleiben soll, um zu verhindern, dass mehrere Agenten (die sich an einem Punkt treffen) übereinander stehen.
„Warte“-Verhalten Mit dem WaitBehaviour kann eine Verzögerung in der Abarbeitung des Drehbuchs erreicht werden. Der Agent wartet einen Zeitraum, der im Drehbuch in Millisekunden angegeben wird, bevor er mit dem nächsten Punkt im Skript fortfährt. Auch das WaitBehaviour ist von TickerBehaviour abgeleitet. Der Konstruktor initialisiert die Zeit in Millisekunden, die der Agent warten soll (Parameter period in Listing 14.26). 1
public WaitBehaviour(long period){...} Listing 14.26: Konstruktor für das WaitBehaviour
„Dreh“-Verhalten Das TurnBehaviour bewirkt eine Drehung relativ zur aktuellen Blickrichtung. Negative Gradzahlen werden als Drehung entgegen dem Uhrzeigersinn interpretiert. Das TurnBehaviour ist wiederum vom TickerBehaviour abgeleitet. Bei jedem Tick dreht sich der Agent um einen bestimmten Betrag in die entsprechende Richtung. Der Winkel wird als Parameter (degrees in Listing 14.27) übergeben . 1
public TurnBehaviour(float degrees){...} Listing 14.27: Konstruktor für das TurnBehaviour
„Drehe zu“-Behaviour Im Gegensatz zum TurnBehaviour dreht das TurnToBehaviour den Agenten zu einem bestimmten Punkt hin. Hier wird keine Angabe in Grad verwendet, sondern ein Punkt im Raum über die einzelnen Koordinaten X, Y und Z angegeben (siehe
266
14 Wissensmarktplatz mit Agenten und Avataren
Listing 14.28), zu dem der Agent schauen soll. Die Drehrichtung wird dabei automatisch bestimmt. Beträgt der Winkel genau 180◦ , dreht sich der Agent rechts herum. 1
public TurnToBehaviour(Agent a, float x, float y, float z) {...} Listing 14.28: Konstruktor für das TurnToBehaviour
„Sprech“-Verhalten Mit dem TalkBehaviour kann der Agent einen vorgegebenen Text im Chat an alle Teilnehmer senden. Das TalkBehaviour ist ein OneShotBehaviour. Nach dem Senden des Textes (Parameter text in Listing 14.29) an das Chatsystem wird das Verhalten beendet. 1
public TalkBehaviour(String text){...} Listing 14.29: Konstruktor für das TalkBehaviour
„Treffpunkt“-Verhalten Um einen möglichst realistischen Eindruck zu hinterlassen, ist es den Agenten auch möglich, sich an einem bestimmten Punkt im Raum zu treffen (MeetingBehaviour), beispielsweise um sich dort zu unterhalten. Der Punkt wird, aufgeteilt in die einzelnen Koordinaten x, y und z, an den Konstruktor (der zweite in Listing 14.30) übergeben. Ist kein Punkt angegeben, wird der aktuelle Standpunkt des Agenten als Treffpunkt angenommen (der erste Konstruktor in Listing 14.30). Ein Agent (derjenige, der laut Drehbuch das Meeting initiiert) versucht, zunächst weitere verfügbare Agenten zu einem bestimmten Punkt (Meeting Point) zu bestellen. Er stellt fest, welche Agenten gerade keinen Gesprächspartner haben und gibt den Treffpunkt an sie weiter. Nachdem alle beteiligten Agenten dort angekommen sind, wird der vorgegebene Dialog gestartet. Um den Eindruck einer „echten“ Unterhaltung zu unterstützen, werden die einzelnen Redebeiträge mit einer Zeitverzögerung ausgegeben. 1
public MeetingBehaviour(){...}
2 3
public MeetingBehaviour(float x, float y, float z){...} Listing 14.30: Konstruktoren für das MeetingBehaviour
14.3 Entwicklung mit VRML, AgentScript und JADE
267
Prinzipiell kann jedes selbst implementierbare Verhalten in einem AgentScript-Drehbuch verwendet werden. Die einzige Anforderung an ein solches Verhalten liegt in der Typbeschränkung der Startparameter. Es darf über den Konstruktor nur Werte annehmen, die in einfachen Java-Datentypen abgelegt werden können (siehe Abschnitt 14.3.2).
14.3.4 Beispiel für die Entwicklung eines Verhaltens Im folgenden Beispiel wollen wir anhand des WalkBehaviour zeigen, wie man aus den JADE-Basisverhalten ein neues, in Drehbüchern verwendbares Verhalten erstellt. Eine wichtige Frage bei der Erstellung eines neuen Verhaltens ist, von welcher JADE-Basisklasse abgeleitet werden soll. Im Fall des WalkBehaviour kann diese Frage anhand der Anforderungen leicht entschieden werden. Das Verhalten soll einen Agenten von einem Punkt zu einem anderen Punkt bewegen, wobei die Laufgeschwindigkeit beeinflussbar bleiben soll. Hier bietet sich das TickerBehaviour als Basisklasse an s. hierzu auch Abschnitt 14.2.2). Das TickerBehaviour führt in gewissen Zeitabständen ein OneShotBehaviour mit nur einem Schritt aus. Da es möglich ist, die Zeitabstände zwischen den Schritten selbst zu bestimmen, entsteht der Eindruck, der Agent würde schneller oder langsamer laufen. Noch flexibler wird das Verhalten, wenn zusätzlich die Schrittweite angegeben wird. Ein Problem ergibt sich allerdings aus der Auswahl des TickerBehaviour als Basisklasse: Ein TickerBehaviour kann nicht geblockt werden. In diesem Fall bedeutet dieser Umstand, das ein Agent seinen Weg nicht unterbrechen kann, sobald er gestartet ist. Ein einfacher Workaround schafft hier Abhilfe. Zunächst wird eine neue Basisklasse entwickelt, die das TickerBehaviour um die Möglichkeit des Blockens erweitert, dann wird das WalkBehaviour von dieser neuen Klasse abgeleitet. Das Blocken des Verhaltens wird durch die zusätzliche geschützte Variable blocked von Typ boolean realisiert, die ein erneutes Starten des Verhaltens nur dann zulässt, wenn es auch gewünscht ist. Der Neustart wird manuell mit manualRestart() ausgeführt. Listing 14.31 zeigt den Quellcode des neuen AbstractBlockableTickerBehaviour. public abstract class AbstractBlockableTickerBehaviour extends TickerBehaviour 3 implements BlockableTickerBehaviourInterface{ 1 2
4 5
protected boolean blocked = false;
6 7 8 9 10
public AbstractBlockableTickerBehaviour(long period){ super(null, period); }
268
14 Wissensmarktplatz mit Agenten und Avataren public void block() { blocked = true; super.block(); }
public void restart(){ if(!blocked){ super.restart(); } }
31 32 33 34 35 36
public void reset(){ super.reset(); blocked = false; }
37 38 39 40 41
public void reset(long period){ super.reset(period); blocked = false; }
42 43 44 45 46
} Listing 14.31: Quellcode des AbstractBlockableTickerBehaviour
Das AbstractBlockableTickerBehaviour erweitert nicht nur das TickerBehaviour aus den JADE-Bibliotheken, sondern implementiert zusätzlich noch das Interface BlockableTickerBehaviourInterface. Durch dieses Interface wird die Klasse um die Methode manualRestart() erweitert. Sie ist notwendig, da bei einem neuen Start durch die übliche Methode restart() der JADE-Basisklasse die zusätzliche Klassenvariable blocked nicht zurückgesetzt werden würde. Listing 14.32 zeigt den Quellcode der Schnittstelle.
14.3 Entwicklung mit VRML, AgentScript und JADE
269
public interface BlockableTickerBehaviourInterface { public void manualRestart(); 3 } 1 2
Listing 14.32: Quellcode des BlockableTickerBehaviourInterface
Wie oben bereits beschrieben, lässt das WalkBehaviour den Agenten in bestimmten Zeitintervallen mit einer bestimmten Schrittlänge in eine bestimmte Richtung im Raum „gehen“. Die Schritte werden in der onTick()-Methode, die aus dem TickerBehaviour der JADE-Verhaltensklassen stammt, vollzogen. Ein Schritt wird allerdings nur ausgeführt, wenn das Verhalten nicht geblockt ist, was sich mit der neuen Basisklasse nun an dem Indikator blocked feststellen lässt. Wie die Richtung genau bestimmt wird und die neuen Koordinaten an das VNet-System weitergegeben werden, soll an dieser Stelle nicht weiter ausgeführt werden. Hierfür stehen diverse private Methoden zur Verfügung (z. B. computeNewOrientation(), calculateAngle(VSFVec3f normVec)). Listing 14.33 zeigt den Quellcode des WalkBehaviour, ohne die zu Beginn bereits beschriebenen Konstruktoren und Klassenvariablen. public class WalkBehaviour extends AbstractBlockableTickerBehaviour{ 3 ... 4 protected void onTick(){...} 1 2
public void setGoToPosition(VSFVec3f goToPosition) { ... }
26
27
public VSFRotation getFinishOrientation() { ... }
28 29
public void setFinishOrientation(VSFRotation finishOrientation) { ... }
30
31
} Listing 14.33: Quellcodeauszug aus WalkBehaviour
14.3.5 Agenten zur Raumerstellung und Konfiguration Im Folgenden werden typische webbasierte Aufgaben beschrieben, die mittels JADEAgenten realisiert werden. Dabei verwenden wir eine 3-Tier-Architektur64 , die Webserver und JADE-Backend kapselt. Die Konfiguration von bestehenden Einstellungen ist eine für Web-Interfaces typische Aufgabe. Sie wird nicht auf dem Webserver mittels Servlets ausgeführt, sondern an Agenten delegiert. Diese kommunizieren daraufhin mit anderen Agenten (prinzipiell entfernt), die mit der Ausführung der Aufgabe betraut werden. JADE-Anbindung Als Agenten-Framework wird JADE verwendet. Die Kommunikation der Agenten untereinander wird über das Framework geregelt und kann somit auch auf unterschiedlichen Knoten ablaufen. In JADE wird die plattformübergreifende Kommunikation über eine Implementierung des IIOP-basierten Transportprotokolls gewährleistet. Die Abbildung 14.26 verdeutlicht den Zusammenhang der Agenten und des Frontends s. dazu auch Abschnitt 14.2.2). Im Web-Container wird über ein Controller-Servlet bei der Initialisierung im Hintergrund ein Controller-Agent gestartet, der im Folgenden auf Anweisungen des Servlets wartet. Die kontextabhängige Visualisierung, wie z. B. die Konfiguration von Einstellungen bzw. Erstellung von virtuellen Räumen, wird über dieses Servlet verarbeitet. Hierfür stehen verschiedene Worker65 bereit, die die entsprechende aufgabenspezifische Darstellung vornehmen. Im Gegensatz dazu steht nur ein Servlet bereit, um die Anzahl der Agenten begrenzt zu halten. Der ausführende ControllerAgent wird bei der Initialisierung der JADE-Plattform mit initialisiert und wartet 64
Teilung der Architektur in Präsentations-, Verarbeitungs- und Datenhaltungsschicht. Worker übernehmen die eigentliche Aufgabe. Agenteninitialisierung und ServletKommunikation bleibt Aufgabe des Servlets. 65
14.3 Entwicklung mit VRML, AgentScript und JADE
271
Abb. 14.26: JADE-Servlet-Kommunikation
auf Befehle seitens des Servlets. Um weitere Aufgaben durch Servlets zu realisieren, können neue Worker erstellt werden, die folgende Anforderungen erfüllen sollten: Ein Worker implementiert die abstrakten Methoden der Klasse ControllerWorker und erweitert somit die Funktionalität des Servlets um die folgenden Methoden: • processCmd(HttpServletRequest request, HttpServletResponse response) entnimmt dem Request-Objekt Kommandos und stößt eine Weiterverarbeitung, z. B. über Agenten, an. • generateOutput(HttpServletResponse response) erstellt eine Antwortseite, die mit den Ergebnissen der gewünschten Anfragen versehen wird. Neben der Implementierung der beiden Methoden muss nun noch die Funktionalität des Controller-Agenten und des Servlet-Agenten angepasst werden. Der passiv agierende Controller-Agent arbeitet Nachrichten über das Verhalten ChooseCmdBehaviour ab. Der Servlet-Agent ist der aktive Kommunikationspartner und muss somit ebenfalls erweitert werden. Die Definition neuer Nachrichten geschieht über das Interface Cmd und wird von beiden Agenten benutzt. Der Umgang mit Agentenverhalten wird in den Abschnitten 14.2.2 und 14.3.3 beschrieben. Abschließend müssen Aufrufe an den neuen Worker im Servlet delegiert werden. Es folgt ein Beispiel, das mittels Agenten die Uhrzeit der JADE-Plattform angibt. Der Entwicklungsprozess bei der Erstellung eines neuen Workers unterteilt sich in fünf Schritte:
272
14 Wissensmarktplatz mit Agenten und Avataren
1. Der erste Schritt umfasst die Definition neuer Kommandos, mittels der die Kommunikation zwischen den Agenten erweitert wird. In Listing 14.34 wird ein Request- für die Anfrage und ein Confirm-Kommando für die Antwort gezeigt. ... public static final int REQUEST_TIME_CMD = 16; 3 public static final int CONFIRM_TIME_CMD = 17; 4 ... 1 2
Listing 14.34: Kommandoliste im Interface Cmd erweitern
2. Wie bereits erwähnt, wird die Ausführung einer Aufgabe in der Klasse ChooseCmdBehaviour realisiert. Hierzu ist es erforderlich, dass neu definierte RequestKommando abzufangen und entsprechend eine Aufgabenausführung einzuleiten (siehe Listing 14.35). In Zeile 5 wird die ermittelte Zeit als ACL-Nachricht an den Anfragenden gesendet. if (m.getPerformative() == ACLMessage.REQUEST) { switch (command) { 3 case Cmd.REQUEST_TIME_CMD: 4 long time = System.getCurrentMillis(); 5 ((ControllerAgent) myAgent).sendCommandMessage(m. getSender(), time, Cmd.CONFIRM_TIME_CMD, ACLMessage.CONFIRM); 6 break; 7 } 8 } 1
2
Listing 14.35: Verarbeitung in ChooseCmdBehaviour implementieren
3. Nachdem die Verarbeitung der Anfrage abgeschlossen ist, folgt die Verarbeitung der Antwort. Diese geschieht in der Verhaltensbeschreibung des ControllerServletAgent. In Listing 14.36 wird das hierfür erstellte Kommando abgefangen und schließlich an den für die Darstellung des Ergebnisses verantwortlichen TimeWorker (siehe Listing 14.37) weitergereicht. case Cmd.CONFIRM_TIME_CMD: timeWorker.setTime(msgContent); 3 timeWorker.wakeup(); 4 break; 1 2
Listing 14.36: Verhalten des ControllerServletAgent erweitern
14.3 Entwicklung mit VRML, AgentScript und JADE
273
4. Der TimeWorker verarbeitet in der Methode processCmd(...) eventuell auftretende Kommandos und sendet schließlich eine Nachricht an den ControllerAgent. Die Methode generateOutput(...) kommt bei der Visualisierung des Ergebnisses zum Einsatz (siehe Listing 14.37). 1
public class TimeWorker extends ControllerWorker{
2
public void processCmd(HttpServletRequest request, HttpServletResponse response) throws IOException { String msgContent = Cmd.REQUEST_TIME_CMD + ":"; ACLMessage m = new ACLMessage(ACLMessage.REQUEST); m.addReceiver(mainServlet.controllerAgentID); m.addReplyTo(mainServlet.servletAgent.getAID()); m.setContent(msgContent); mainServlet.servletAgent.addBehaviour(new SenderBehaviour(mainServlet.servletAgent, m)); wait(); generateOutput(response); }
3
4 5 6 7 8 9
10 11 12 13
public void generateOutput(HttpServletResponse response) throws IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println(""); out.println(time); out.println(""); }
14
15 16 17 18 19 20 21
} Listing 14.37: TimeWorker implementieren
5. Abschließend wird im ControllerServlet eine Weiterleitung an den neu erstellten Worker eingerichtet (siehe Listing 14.38). Diese Weiterleitung geschieht durch einen Vergleich der angeforderten URL und einem entsprechenden Eintrag im ControllerServlet. if(request.getRequestURI().equals("/control/timeController ")) { 2 worker = new TimeWorker(request, this); 3 } 1
Listing 14.38: ControllerServlet um neuen Worker erweitern
274
14 Wissensmarktplatz mit Agenten und Avataren
Ausstellungseditor Da die Raumerstellung für den virtuellen Marktplatz Kenntnisse über VRML voraussetzt, wurde eine abstraktere Form gewählt. Hierbei sind lediglich Grundkenntnisse der Raumaufteilung erforderlich, wie z. B. die Ausmaße, die Farbgebung, die Position und letztendlich die Einbindung von Bildern. Mittels dieser Informationen werden VRML-Konstrukte erstellt, die schließlich einen kompletten Raum darstellen. Es ist somit im Wesentlichen möglich, bestehende Ausstellungen mit neuen Inhalten zu versehen bzw. leichte Änderungen der Raumstruktur vorzunehmen. Die Raumerstellung ist somit nicht als grafischer VRML-Editor zu sehen, sondern vielmehr als Ausstellungskonfigurator. Eine Raumbeschreibung liegt in einem XML-Format vor, das wesentliche Eigenschaften (siehe Abb. 21.2) enthält. Diese Eigenschaften werden mittels eines XSLStylesheets in eine VRML-Umgebung transformiert und in die bestehende virtuelle Welt eingehängt. Ausstellungen können bestimmten Wochentagen zugeordnet werden, wobei zusätzlich die Wahl zwischen endgültiger und temporärer Speicherung besteht. Die Konfiguration der Ausstellungen wird in Abschnitt 21.2.3 detailliert besprochen.
15 Entwicklung und Integration von Rich Media Learning Objects Andreas Eißner
15.1 Rich Media Content im E-Learning Der Einsatz von Multimedia in der Aus- und Weiterbildung hat sich inzwischen im Rahmen des Blended Learning erfolgreich in der Praxis durchgesetzt. Der Begriff „Multimedia“ soll hier für die parallele Interaktion von Nutzern mit einem ELearning- oder E-Informationssystem im Rahmen verschiedener Medientypen stehen. Dazu gehören Text, Grafik, Audio und Video, die zum Zwecke der Wissensvermittlung vielfältig miteinander gekoppelt und kombiniert werden. Je nach Lernziel und Zielgruppe muss eine sinnvolle Kombination dieser Medien vorgenommen werden. Dabei sollte der Lernnutzen für die betreffende Zielgruppe und nicht die technische Machbarkeit der Handlungsmaßstab sein. Erfahrungsgemäß ist vor allem die Interaktion Schlüssel zur Akzeptanz multimedialer Lerneinheiten, wenn sie die Kontrolle des Lernablaufs durch den Lerner ermöglicht. Die Aufmerksamkeit und die Motiviertheit beim Lernen werden zumindest kurzfristig deutlich erhöht. Kombiniert mit Interaktionsmöglichkeiten werden multimediale Lernmodule bzw. Lerneinheiten1 auch als „Rich Media Content“ bezeichnet; besonders dann wenn sie zusätzlich „dynamic motion“ beinhalten (z. B. Video- oder grafische Animationssequenzen). Unsere Rich-Media-Content-Module sind wesentlicher Bestandteil des I-can-EIBProjektes, dessen Philospohie schon eingangs kurz charakterisiert wurde. I-can-EIB möchte die Chancen des E-Learning einer fachbezogenen Community eröffnen. Dabei sollte eine Alternative zum wenig akzeptierten, isolierten Selbstlernen geschaffen werden. Diese Alternative zeichnet sich durch ein nachweislich wirkungsvolles Lernarrangement aus: eine berufsbezogene Online-Community, die sich durch informellen, internetgestützten Wissenserwerb und -austausch berufliches Fortkommen verspricht. Es handelt sich dabei um Personengruppen, die im Kontext ihrer beruflichen Tätigkeit ein gemeinsames Interesse an einer Frage- oder Problemstellung 1
Häufig einfach als „Content“ bezeichnet.
276
15 Entwicklung und Integration von Rich Media Learning Objects
haben und die zu diesem Zwecke netzgestützt Wissen austauschen, dokumentieren, generieren und dabei voneinander lernen. Angebote und Nutzung solcher Communities fanden bisher nur sehr zögerlich Beachtung in der betrieblichen Bildungsarbeit, obwohl damit ein wichtiges Instrument für arbeitsplatznahes Problemlösen, für das Lernen nach Bedarf, gegeben ist.2
15.1.1 Das Projekt I-can-EIB Inhaltlicher Schwerpunkt des Projektes ist die Vermittlung fachspezifischen Wissens über den EIB (Europäischer Installations-Bus) – eine innovative Elektroinstallationstechnik, über die alle elektrischen Schalt- und Regelungsvorgänge in einem Gebäude zentral verwaltet und frei programmiert werden können. Für dieses Buch und seine Leser mit vielfältigen alternativen Interessen, generalisieren wir EIB zu Einer Innvoativen Basisidee. Das I-can-EIB-System, wie wir es hier vorstellen, ist nützlich für die Wissenskommunikation sowohl im Sinne von EIB als Haustechnik als auch im Sinne Einer Innovativen Basisidee. Speziell in diesem Kapitel reden wir aber vom EIB im engeren Sinne (Haustechnik). Der Leser sollte aber immer an die prinzipielle Übertragbarkeit der Konzepte auf Eine Innovative Basisidee denken. Um einen Nutzer zunächst unabhängig von seiner spezifischen Sichtebene für den EIB zu interessieren und zu motivieren, werden Informations- und Lernmodule über innovative Gebäudetechnik herstellerneutral angeboten. Im Entwurfs- bzw. Planungsstadium einer EIB-Anlage soll eine produktnahe Situation geschaffen werden, in der vom Nutzer bestimmte konkrete EIB-Komponenten als Lernmodule bearbeitet werden können. Die Produktnähe wird durch Einbindung der Hersteller der EIBKomponenten erreicht. Kunden im Elektrohandwerk verlangen heute verstärkt nach innovativer, technisch versierter und umfassender Dienstleistung aus einer Hand. In den Elektrohandwerksbetrieben und bei den Anwendern der neuen Techniken ist der Informationsbedarf dementsprechend hoch. Die vorhandenen Informationsquellen sind jedoch ungenügend strukturiert und bieten so nur bedingt Hilfestellung. Verstärkt wird diese Entwicklung durch die Schnelligkeit technologischer Entwicklungen. Notwendig ist ein umfassendes, den vielfältigen Problemstellungen gewachsenes Informationssystem, das Handwerksbetriebe wie auch Anwender der EIB-Technik ausreichend informiert und berät. Insbesondere Handwerksbetriebe werden bei der Einführung und Verbreitung des EIB unterstützt und durch Qualifizierung in eine konkurrenzfähige Lage versetzt. Im Projekt I-can-EIB wurde insbesondere Wert auf zielgruppenspezifische, praxisnahe Wissensvermittlung und -erwerb mit Unterstützung von multimedialen Lerneinheiten, virtuellen (Avataren) und nichtvirtuellen (bfe-Experten) Online-Beratern 2
Online-Communities in der Berufsbildung – Ergebnisse einer Online-Befragung und Ansatz für die Gestaltung offener Lernarchitekturen; Dr. Gert Zinke, Bundesinstitut für Berufsbildung, Bonn.
15.2 Entwicklung von Rich Media Content im E-Learning
277
gelegt. Der Avatar dient u. a. der Personalisierung des Systems (siehe Kapitel 12). Über das erstellte Portal werden verschiedene Zielgruppen angesprochen: (1) Bauherren (Endkunde), (2) Planer, (3) Architekten, (4) Handwerker, (5) Großhändler, (6) Hersteller und (7) Bildungsstätten. Content kann zielgruppenspezifisch ausgewählt werden. Beispielsweise bekommen Bauherren oder Architekten vorzugsweise entscheidungsrelevante Informationen wie allgemeine Vorteile und Kosten des EIB angeboten. Planer und Handwerker dagegen erhalten auch technische Details zur Installation und Inbetriebnahme. Die Lernplattform bietet zunächst produktneutrale Informationen. Für die Planungsphase können jedoch auch EIB-Komponenten verschiedener Hersteller betrachtet werden. Die Produktpräsenz im Lernportal bietet Herstellern und Großhändlern die Möglichkeit gezielter Werbung.
15.2 Entwicklung von Rich Media Content im E-Learning Um spätere Enttäuschungen bei der Entwicklung von E-Content zu vermeiden, haben erfahrene E-Learning-Anbieter Vorgehensmodelle in Form von Leitfäden und Checklisten entwickelt. Erfahrungen des bfe-Oldenburg im Projekt I-can-EIB zeigen, dass bei der Entwicklung von Lerninhalten der Zuschnitt auf die zukünftige Zielgruppe eine entscheidende Rolle spielt. Dazu gehört das methodisch didaktische Konzept, das dem didaktischen Drehbuch zugrunde liegt. Darunter verstehen wir Konzepte, Ablaufpläne und Regieanweisungen für Multimedia-Entwickler, die gemäß diesem Drehbuch ablauffähige multimediale Lernmodule erstellen. Besonders vorteilhaft ist es, wenn Fachautor und Drehbuchautor ein und dieselbe Person sind. Am bfe-Oldenburg wurden dazu Fachdozenten zu Drehbuchautoren fortgebildet. Zur Entwicklung von Rich Media Content sind folgende Projektphasen notwendig, die z. T. parallel ablaufen: 1. 2. 3. 4. 5. 6. 7. 8. 9.
Grobkonzept Feinkonzept Drehbuchentwurf und Abnahme Programmierung Grafik-, Foto- und Animationserstellung Videoaufnahmen mit authentischen Personen Audio- und Sprecheraufnahmen Qualitätssicherung Projektleitung
Bei der Gliederung der Lernmodule sind möglichst kleine, didaktisch in sich geschlossene Lernschritte vorzunehmen. Die Feingranulierung der Lernmodule hat insbesondere den Vorteil, die Wiederverwendung in anderen Kontexten zu erleichtern oder den didaktischen Aufbau beispielsweise für andere Zielgruppen anpassen zu
278
15 Entwicklung und Integration von Rich Media Learning Objects
können. Ein solcher Lernschritt enthält dabei ca. 5 bis 6 multimediale Sequenzen (z. B. Sprechertexte, Grafiken, Animationen, Interaktionen), die als Folge den didaktischen Aufbau der Bildschirmseite bzw. des Lernmoduls ergeben. Die detaillierte Gliederung sowie der genaue Ablauf des Programms werden in der Grob- und Feinkonzeption festgelegt. Zeit- und Kostenkalkulation hängen von vielen weiteren, aber kostenverursachenden Details ab: • Schwierigkeitsgrad (Definition der Zielgruppen), • Anzahl und Niveau der interaktiven Aufgaben, • Interaktionsgrad des Lernprogramms (wie stark und wie oft kann der Nutzer eingreifen), • Material zur fachlichen Einarbeitung der Autoren, • Verfügbarkeit von Foto- und Grafikvorlagen, • Aufwand bei Videoproduktionen, • Art der Navigation durch das Lernmodul (z. B. vor, zurück, Sprung zum Anfang, welche Maustasten), • zusätzliche Optionen im Lernmodul (z. B. Sprung ins Menü, wie im Menü navigieren, Notizzettelfunktion, Suchfunktion, Druckfunktion, kontextsensitive Hilfe), • Lernerdaten (z. B. Punktestand erfassen, wie viel Versuche bei einer Aufgabe, welche Seiten wurden bereits bearbeitet), • zu beachtende Standards für die Einbindung in Learning Management Systems (LMS) (z. B. LOM, SCORM, AICC), • Beenden des Programms (Speichern der Lernerdaten), • Installationsroutinen, • Offline/Online-Versionen, • Layout. 15.2.1 Fein- und Grobkonzept von Lerninhalten Neben der Beherrschung eines Drehbucheditors sollten Drehbuchautoren insbesondere auch mediendidaktische Kriterien bei der Entwicklung multimedialer Lernprogramme beachten. Dies sollte auch Gegenstand einer Fortbildung von Fachautoren zu Drehbuchautoren sein: 1. Die Autoren lernen die spezielle Aufbereitung von Lerninhalten für ihre Präsentation in multimedialer Form. Dabei entstehen Drehbücher, in denen Lernsequenzen zwar detailliert festgelegt werden, die sich aber von E-Books („Blättermaschinen“) unterscheiden müssen. Das fertige Produkt soll natürlich sachlich und sprachlich korrekt, aber dennoch für den Nutzer interessant, abwechslungsreich und interaktiv sein. Die Erstellung eines Grob- und Feinkonzeptes steht am Anfang im Vordergrund. Fachbegriffe und Abkürzungen für die Zusammenarbeit aller Beteiligten werden anschließend definiert. Dann erfolgen die Zuordnung von Rich-Media-Elementen zu didaktischen Zwecken und die Abschätzung des erforderlichen Entwicklungsaufwandes.
15.2 Entwicklung von Rich Media Content im E-Learning
279
2. Ein weiterer Ausbildungsschritt dient der Umsetzung des Feinkonzepts in eine normierte Maske eines Autorenwerkzeugs. Diese Maske orientiert sich am Bedarf des Drehbuchautors und der Medienentwickler. Das Autorenwerkzeug wird im Abschnitt 15.3 näher beschrieben. 3. Zuletzt werden praktische Anwendungen des Autorenwerkzeugs trainiert und gelungene Beispiele (best cases) bereits fertig gestellter Lernmodule besprochen. Eigene Feinkonzepte werden übernommen und getestet, Fragen und Probleme werden gemeinsam diskutiert. Das Grobkonzept liegt in den meisten Fällen bei Beginn der Entwicklung von multimedialen Lernmodulen bei den Auftraggebern oder den Projektverantwortlichen bereits in unterschiedlich detaillierter Form vor. Fachinhalte gibt es in Form von Gliederungen, Manuskripten, Lehrgangsunterlagen, Literatur, Printmedien oder Präsentationsfolien. Meist sind sie didaktisch jedoch bestenfalls für den Präsenzunterricht aufbereitet. Aufbauend auf dem Grobkonzept wird das Feinkonzept entwickelt, das zwar die fachlichen Inhalte unverändert lässt, jedoch zusätzlich die mediendidaktische Aufbereitung der Inhalte berücksichtigt. Beispielsweise sollten hier keine Stichpunkte mehr auftauchen, die ursprünglich als Gedankenstütze für den Dozenten gedient hatten. Diese müssen in geeigneter Weise aufbereitet werden, beispielsweise: • • • •
Formulierung eines erklärenden Sprechertextes. Hinweis auf eine parallel dazu startende Animation. Hinweis auf die Einblendung eines zusammenfassenden Bildschirmtextes. Gegebenenfalls Hinweis auf die Einblendung eines Fotos.
Im Feinkonzept finden sich weitere Hinweise auf Quellen von Fotos und Abbildungen, Texthinweise, wann eine Animation, ein Videofilm, eine Interaktion oder eine interaktive Aufgabe erscheinen soll, sowie verbale Beschreibungen der Animationen, Videos oder Interaktionen. Je ausführlicher und detaillierter im Feinkonzept der mediendidaktische Ablauf der Lerneinheit beschrieben ist, desto leichter lässt sich später das Drehbuch erstellen. Erfahrungen in verschiedenen Projekten haben gezeigt, dass Drehbuchautoren zumindest ansatzweise auch die Medienerstellung selbst vornehmen möchten. Dies ist für die Identifikation mit dem Produkt förderlich, bleibt aber in Effizienz und Qualität hinter der professioneller Medienentwickler oder Programmierer zurück. Dies gilt besonders für Rich-Media-Komponenten wie interaktive Aufgaben, interaktive Animationen und Videos oder Simulationen. Solche Elemente müssen vom Drehbuchautor besonders detailliert spezifiziert werden. In manchen Fällen reicht ein Text; oft müssen jedoch Tabellen, Grafiken, Ablaufpläne oder separate Funktionsbeschreibungen zusätzlich angefertigt werden.
280
15 Entwicklung und Integration von Rich Media Learning Objects
Als Beispiel zeigen wir einen Auszug aus einem Feinkonzept für ein elektrotechnisches Lernthema (ST = Sprechertext; PBF = Pause/Benutzerführung; g = Grafik; BT = Bildschirmtext): Seite 4 (Nr.: 11.01.03.04 ) Überschrift: Wechselstromsteller mit ohmscher Last – Effektivwert der Ausgangsspannung ST Da die Spannungs-Zeit-Flächen im positiven und im negativen Bereich unabhängig vom Zündwinkel immer die gleiche Größe haben, ist der Mittelwert der Ausgangsspannung immer null. ST . g8420401. Dann g8420402. Der graue Schatten wandert nach rechts und kippt dann nach unten. PBF ST Bei alpha gleich null Grad, d. h., Eingangs- und Ausgangsspannung sind identisch, beträgt der Effektivwert der Ausgangsspannung 230 Volt. ST . g8420403. PBF ST Bei einem Zündwinkel von 90 Grad sind die Spannungs-Zeit-Flächen im positiven und im negativen Bereich in Summe so groß wie die Fläche einer Halbwelle. g8420404. ST . Dynamischer Übergang von g8420404 in g8420405. Die negative gestreifte Fläche wandert auf dem dargestellten Weg in den positiven Bereich zwischen 0 und 90 Grad. Im Endbild ist dann nur die positive Halbwelle komplett schraffiert. PBF ST Ist während der Periodendauer nur eine Halbwelle an der Last aktiv, wird die maximale Leistung um 50 Prozent reduziert. ST . g8420406. PBF ST Obwohl die Leistung um 50 Prozent reduziert wurde, ändert sich die Spannung nicht auf den halben Wert. Die Begründung hierfür ist, dass sich die Leistung P mit dem Quadrat der Spannung U ändert. ST . In g8420406 BT1 einfügen. PBF BT1 Die Leistung P ändert sich mit dem Quadrat der Spannung U P ∼ U2 ......... Ein didaktisch gutes Lernmodul sollte neben möglichst vielen sinnvollen Interaktionen auch Testfragen für den Lerner enthalten. Interaktive Aufgaben, selbst wenn sie nur die üblichen Multiple-Choice-Aufgaben implementieren, können jedoch bei gu-
15.2 Entwicklung von Rich Media Content im E-Learning
281
ter mediendidaktischer Aufbereitung schon relativ großen konzeptionellen Aufwand erzeugen. Soll dem Lerner für jede mögliche Antwort-Kombination ein qualifiziertes „Feedback“ in Form von Textrückmeldungen gegeben werden, muss sich der Autor oft sehr viele verschiedene Feedbacktexte überlegen, die je nach Zahl der Versuche, die der Nutzer zur Lösung der Aufgabe hat, unterschiedlich formuliert sein sollten. Dieser Qualitätsanspruch kann wegen des hohen Aufwandes oft nicht eingelöst werden, was zu Frustrationen oder Langeweile beim Lerner führen kann. Beispielsweise können für eine Mehrfach-Multiple-Choice-Aufgabe mit 5 Antwortmöglichkeiten mit mehreren Auswahlantworten 32 verschiedene Feedbacktexte möglich sein (25 = 32). Je nach Kombination der gewählten Antworten sollten dann die gegebenen Feedbacktexten hilfreiche Hinweise für den Lerner zur Lösung der Aufgabe enthalten. Die Qualitätssicherung der Lerninhalte ist zwar eingangs als eine Phase in der Medienentwicklung aufgeführt worden, muss aber als ein übergreifender Prozess betrachtet werden. Beim Entwurf eines Feinkonzeptes, spätestens aber bei dem des Drehbuchs, sollte der Inhalt mit mehreren Drehbuchautoren diskutiert und ggf. korrigiert werden. Wichtig ist die Diskussion des mediendidaktischen und fachlichen Aufbaus der Lernmodule. Die Korrektur vorhandener Entwürfe ist oft sehr zäh und zeitaufwändig, was nicht verwunderlich bei mehreren Fachleuten ist, die das gleiche Thema erklären wollen. Das Resultat sind aber oft sehr gut aufbereitete Lernmodule. Die Korrektur bzw. Diskussion der Entwürfe kann entweder mit dem Feinkonzept oder aber auch mit dem Drehbuchentwurf vorgenommen werden. Das Feinkonzept hat den Vorteil, dass es oft besser „lesbar“ ist, da noch keine Aufteilung in verschiedene Medienarten, Felder und Nummerierungen erfolgt ist, wie dies im Drehbuchentwurf vorgenommen wird.
15.2.2 Drehbuchentwicklung Das eigentliche Drehbuch stützt sich auf das Feinkonzept des Lernmoduls. Das Drehbuch wird nicht in einem standardisierten Prozess erstellt. Es wird deshalb nach den verschiedensten Varianten verfahren. Es sollen möglichst viele Informationen aus dem Drehbuch direkt und automatisch in das ablauffähige Lernmodul übernommen werden. Das geschieht mit verschiedenen Softwaretools, die dieses Ziel mehr oder weniger erfüllen. Unabhängig davon bleibt jedoch die Erstellung der eigentlichen Medien wie Sprecheraufnahmen, Fotos, Grafiken oder Animationen. Da diese vor allem bei technischen Inhalten fachlich oft sehr speziell sind, kann hier meist nicht auf vorgefertigte Assets zurückgegriffen werden. Als Drehbuchablage werden im einfachsten Fall Textverarbeitungsprogramme, Tabellenkalkulationssoftware, Präsentationstools oder andere spezielle Drehbuchsoftware verwendet. Alle eignen sich mehr oder weniger gut, haben jedoch einen eigenen Code, der zur Datenübernahme in eine ablauffähige Lernsoftware und zur späteren Wiederverwendung nicht sonderlich geeignet ist. Daher wurde im Projekt “I-can-
282
15 Entwicklung und Integration von Rich Media Learning Objects
EIB“ ein Drehbucheditor entwickelt, der auf dem XML-Datenformat basiert. Die Beschreibung dieses Werkzeugs erfolgt im Abschnitt 15.3. Im Drehbuch werden nun prinzipiell die gleichen Informationen abgelegt, die bereits im Feinkonzept erarbeitet worden sind. Als zusätzliche Informationen werden hier detailliertere Regieanweisungen, Nummerierungen, Hinweise und Links auf mögliche vorhandene Dateien und weitere Metadaten hinzugefügt. Die Art der Metadaten ist abhängig davon, in welcher Tiefe die Granulierung der einzelnen Medien zur späteren Wiederverwendung und nach welchem Standard die Metadatenbeschreibung erfolgen soll (z. B. SCORM, AICC). Besonders zur späteren Einbindung des Lernmoduls in LMS oder im Zusammenhang mit der Implementierung eines Avatars (s. Abschnitt 3) sind weitere Metadaten vom Autor einzugeben. Beispielsweise sind zur späteren Identifizierung des Lernmoduls bei Suchanfragen durch die Nutzer (Lerner) Schlagwörter (Keywords) und Frage-Antwort-Paare (FAP) zu definieren, die Bezug zum jeweiligen fachlichen Inhalt des Lernmoduls haben (siehe Kapitel 13, 19).
15.2.3 Erstellung ablauffähiger Lernsequenzen Das durch die Drehbuchautoren abgenommene Drehbuch wird zur Umsetzung in ablauffähige Lerneinheiten an Medienentwickler und Programmierer übergeben. Die Erstellung der einzelnen Medien (Grafiken, Animationen, Aufnahme der Sprechertexte, Videos) sowie die Programmierung der Interaktionen, Aufgaben oder Simulationen erfolgt i. d. R. zeitlich parallel, je nach Verfügbarkeit der entsprechenden Ressourcen. Auf die Besonderheiten bei der Erstellung der einzelnen Medien soll hier nicht weiter eingegangen werden. Für jedes Medium existiert eine Vielzahl von Autoren- und/oder Bearbeitungssoftware, die je nach Anforderungen und Randbedingungen der geplanten Projekte ausgewählt werden müssen. Im Beispielprojekt Ican-EIB wurden professionelle Entwicklungstools wie Adobe Photoshop, Macromedia Flash, Corel Draw oder Macromedia Authorware zur Erstellung verwendet. Trotz ständig steigender Geschwindigkeit der Datenübertragung bei der Online-Nutzung von Lerninhalten ist bei der Entwicklung auf die „Online-Fähigkeit“ der Inhalte zu achten. Dies betrifft sowohl die Datenmenge einzelner Medien als auch die Art des Datenstromes bei der Anwendung durch den Nutzer. Heute übliche Autorenwerkzeuge bieten dazu ausreichende Komprimierungs- und Streamingverfahren (z. B. Flash, Authorware). Bei der Verwendung der Lernmodule als reines CBT sind i. d. R. Metadaten nicht erforderlich. Bei der Neuentwicklung von Lerninhalten sollte jedoch immer die Erfassung von Metadaten berücksichtigt werden, da eine spätere Wiederverwendung der entwickelten Lernmodule oder die Einbindung in LMS ermöglicht werden sollte (siehe Abschnitt 15.2.4). Nach erfolgter Umsetzung des Drehbuches in ein ablauffähiges Lernmodul muss zur Qualitätssicherung die Abnahme durch den Drehbuchautor erfolgen. Mögliche Fehler oder technisch nicht korrekte Sachverhalte sowie Fehler bei der Bedienung werden durch die Medienentwickler beseitigt. Danach erfolgt die Endabnahme und ggf. der Test mit Vertretern der zukünftigen Zielgruppe. Dieser Schritt empfiehlt sich be-
15.2 Entwicklung von Rich Media Content im E-Learning
283
sonders dann, wenn Erfahrungen mit der Zielgruppe bei der Nutzung von E-Learning noch nicht vorliegen. Beispielsweise haben Tests mit Vertretern aus dem Elektrohandwerk gezeigt, dass viele wertvolle Hinweise und Anregungen besonders bei der Bedienung und Steuerung von Lernmodulen, bei der Eingabe von Antworten oder bei der generellen Mediengestaltung nachträglich eingearbeitet wurden. Damit konnte die Akzeptanz von multimedialen Lernmodulen deutlich gesteigert werden. Zusammenfassend sind in Abbildung 15.1 die Schritte zur Entwicklung von Rich Media Content grafisch dargestellt. Besonders vorteilhaft ist es, wenn alle Vorgänge und Teilschritte in einem Team bearbeitet werden können, da Absprachen, Rückfragen und Besprechungen leichter zu organisieren sind. Außerdem müssen erfahrungsgemäß besonders die Drehbuch- und/oder Fachautoren häufiger für Rückfragen bei der Umsetzung der Drehbücher konsultiert werden, da z. B. spezielle technische Abläufe in Animationen oder Simulationen hohe Komplexität haben können. In Abbildung 15.2 ist als Beispiel ein Auszug aus einem Lernmodul zum Thema „Beleuchtungssteuerung“ dargestellt. Als eine einfache Form der Interaktion kann hier durch die Betätigung des virtuellen Schalters der Verlauf der elektrischen Impulse auf dem Bussystem durch den Lerner verfolgt werden. Dazu ist eine Arbeitsanweisung unter dem Schalter als Text eingeblendet. Durch eine realitätsnahe Abbildung der Schalter und Komponenten sowie durch eine schematische Gegenüberstellung der realen Schaltung mit dem Schaltbild und den Schaltsymbolen können hier dem Praktiker die technischen Zusammenhänge anschaulich dargestellt werden.
15.2.4 Implementierung, SCORM-Metadaten Zur Sicherung der Nachhaltigkeit ist die Wiederverwendung von Lerninhalten wünschenswert. Das geht nur, wenn die Lernmodule entsprechend internationaler Standards entwickelt wurden. Nur so können sie dann in ebenfalls standardisierten, internetbasierten Lern-Managementsystemen ablaufen. Die Standardisierung muss bereits in die Konzeption einbezogen werden (siehe auch Abschnitte 15.2.2 und 15.2.3). Sie ermöglicht die Kombination verschiedenster Weiterbildungsangebote, vom einfachen Textdokument über Rich-Media-Module hin zum interaktiven Virtual Classroom Training. Dabei ergeben sich jedoch auch Probleme, beispielsweise hinsichtlich der Konsistenz einmal erstellter Lernmodule zum jeweiligen thematischen und didaktischen Kontext sowie hinsichtlich der Nutzungsrechte und Honorierung. Die Wiederverwendung und der flexible Einsatz von Lernmodulen wird durch das Hinzufügen von Metadaten unterstützt. Dazu haben sich in den letzten Jahren zahlreiche Standardisierungskonsortien gebildet. Sie verfolgen das Ziel, offene technologische Standards für computergestützte Lernumgebungen (LMS), E-LearningModule und die sie kennzeichnenden Metadaten zu definieren. Die verschiedenen Standardisierungsbemühungen wie AICC oder SCORM werden genauer in Kapitel 16 beschrieben. Bei vielen LMS wird zwar beispielsweise die „SCORM-Fähigkeit“
284
15 Entwicklung und Integration von Rich Media Learning Objects
Lehrkraft ist bereits Drehbuchautor?
nein
Lehrkraft ist ausreichend qualifiziert?
ja nein
Qualifizierung von Lehrkräften zu Drehbuchautoren
ja
Sind Kenntnisse im Umgang mit Editor vorhanden?
nein
Einweisung in speziellen Drehbucheditor
ja
Grobkonzept, Feinkonzept, Drehbucherstellung
Drehbuchbesprechung mit mehreren Fachautoren
Programmierung durch Multimedia-Entwickler
Erstellung von Grafiken, Videos, Animationen
Aufnahme Sprechertexte, Audios
Abnahme durch Drehbuchautor
Korrektur durch Programmierer
Test mit Teilnehmern
Endabnahme
Abb. 15.1: Phasen bei der Erstellung von Rich Media Content
der Lernmodule gefordert. Es zeigt sich jedoch oft, dass die angebotenen Metadaten nicht oder nur begrenzt im LMS weiterverarbeitet werden. Hier wird sich jedoch zukünftig zeigen, welche der Metadaten sich durchsetzen.
15.3 Der XML-Drehbucheditor Zur Erstellung XML-basierter Drehbücher wurde ein XML-Editor verwendet. Wir haben hier das Open-Source-Prinzip verletzt und aus Bequemlichkeit ein kommerzielles Tool (Altova XMLSPY) verwendet. Im Prinzip wären aber auch freie Tools
15.3 Der XML-Drehbucheditor
285
Abb. 15.2: Auszug aus einem multimedialen Lernmodul mit Interaktion
einsetzbar. Wir zeigen die einzelnen Schritte mit Screenshots nur um die Arbeitsschritte zu veranschaulichen. Es ist klar, dass bei Verwendung anderer Tools die Screenshots anders aussehen würden. Unabhängig davon wäre aber die Abfolge der Arbeitsschritte gleich. Der verwendete XML-Editor sollte folgende Anforderungen erfüllen: • Moderne Benutzeroberfläche mit verschiedenen Sichten auf die Daten und weitgehenden Konfigurationsmöglichkeiten. • Unterstützung aller wichtigen Verwaltungsaufgaben zum Einfügen, Löschen, Umbenennen und Exportieren von XML-Dokumenten. • „On the fly“-Unterstützung von XSL-Transformationen. • Einbindung von Browsern und PDF-Betrachtern zur leichten Überprüfung der Transformationsergebnisse. • (Optionale) Anbindung einer XML-Datenbank (beispielsweise Xindice). Wird von Content-Sharing (siehe Abschnitt 16.2) gesprochen, ist im Allgemeinen der Austausch bzw. die gemeinsame Nutzung von Inhalten gemeint. Die Modularisierung von Content bietet den Vorteil der verteilten Entwicklung durch verschiedene Autoren und der relativ leichten Austauschbarkeit. Die Einigung auf ein gemeinsa-
286
15 Entwicklung und Integration von Rich Media Learning Objects
mes Austauschformat fällt leicht, wenn man sich auf XML festlegt. Dadurch ergibt sich eine Reihe von Vorteilen: • Einfacherer Austausch der Daten zwischen Fachexperten, Multimedia-Entwicklern, Drehbuchautoren und weiteren Partnern. • Vorbereitung der Datenstrukturen für eine Inter-/Intranet-Version. • Relativ leichte Lesbarkeit des kompletten Dokuments für den Menschen. Die Drehbuchautoren arbeiten mit dem XML-Editor zur Drehbucherstellung und geben die Inhalte über Masken und Formulare ein. Das Tool ist hier weitgehend beliebig und hängt nur von persönlichen Präferenzen ab. Fertig gestellte Drehbücher werden in eine XML-Datenbank (Xindice) übernommen, aus der später die Informationen sowohl für das Lernsystem als auch für die Multimedia-Entwickler in anderen Formaten (z. B. als Text) extrahiert werden können. Sämtliche Vorschauen des Drehbuchs werden über eigens entwickelte Stylesheets (XSLT und XSL FO) erzeugt (siehe Abb. 15.3), so dass diese unabhängig vom XML-Editor verwendet werden können. Somit können weitere Beteiligte am Content-Produktionsprozess entsprechende relevante Drehbuchdaten erhalten (z. B. Sprechertexte für den Sprecher, s. Abb. 15.3).
15.3.1 Beschreibung der Eingabefelder Die Beschreibung der Eingabefelder dient nur der exemplarischen Verdeutlichung der einzelnen Arbeitsschritte. Bei anderen Tools gäbe es aber äquivalente Felder. Der Drehbucheditor hilft dem Autor, den Ablauf eines Lernmoduls, mediale Elemente sowie Regieanweisungen zur Erstellung von Rich Media Content zu beschreiben und in entsprechende Felder einzugeben (allgemeine Einstellungen des XMLEditors und Strukturen zur Benennung der Drehbuchdateien sollen hier jedoch nicht weiter beschrieben werden). Die wichtigsten Elemente, die bei Drehbuchbeschreibungen benötigt werden, sind: • • • • • • • • • •
Infos zum Modul selbst (inkl. erforderlicher Metadaten) Einfacher Bildschirmtext Grafik Audio Animation, Movie Löschen eines Elementes Pause (weiter durch Benutzereingabe) Aufdimmen Abdimmen Aufgaben, z. B. – Multiple-Choice einfach – Multiple-Choice mehrfach
15.3 Der XML-Drehbucheditor
287
Abb. 15.3: Auszug aus einem Drehbuch als Textdatei
• •
– Zuordnungsaufgaben Freitexteintrag Infotext (als Hinweis für die Medienentwickler)
Zu jedem dieser Elemente sind verschiedene Pflichtangaben durch den Autor einzutragen. Werden diese vergessen, erfolgt ein entsprechender Hinweis. Andere Felder dienen der verbalen Beschreibung (z. B. einer Animation) und können ggf. auch leer gelassen werden. Im Folgenden sollen einige ausgewählte Eingabemasken, die zur Beschreibung einzelner Elemente des Lernmoduls durch den Drehbuchautor dienen, beispielhaft vorgestellt werden. Infos zum Modul In dieser Eingabemaske (siehe Abb. 15.4) werden zusätzlich zu allgemeinen Angaben zum Lernmodul auch die Schlüsselwörter und die Frage-Antwort-Paare (FAPs) eingetragen, die insbesondere für die Einbindung von Avataren die entscheidende
288
15 Entwicklung und Integration von Rich Media Learning Objects
Voraussetzung zur Identifizierung des Lernmoduls sind (siehe Kapitel 13, 19). Das Feld „Priorität“ gibt dem Autor die Möglichkeit, mehrere Keywords oder FAPs anzugeben und nach Wichtigkeit in Bezug auf die Lerninhalte zu ordnen. Die Felder
Abb. 15.4: Allgemeine Eingabefelder für das Lernmodul
„Klasse/Aufwand“ sollen eine Abschätzung durch den Autor geben, welche Gesamtzeit für die Erstellung des Moduls erforderlich ist (Programmierer, Sprecher usw.). Dies dient der späteren Abschätzung des Entwicklungsaufwandes, da allein von der Menge der Einträge im Drehbucheditor der Entwicklungsaufwand oft nicht direkt abgeleitet werden kann. Einfacher Bildschirmtext In diesem Element wird ein Bildschirmtext und dessen Bedeutung und ggf. dessen Formatierung beschrieben (siehe Abb. 15.5). Außerdem können bestimmte Eigenschaften und die Platzierung des Textes auf dem Bildschirm angegeben werden.
Abb. 15.5: Eingabefelder für „Bildschirmtext“
15.3 Der XML-Drehbucheditor
289
Im Feld „Delay“ kann eine Verzögerung zum Erscheinen des Textes angegeben werden, z. B. wenn der Text erst einige Sekunden nach dem Ende eines vorhergehenden Sprechertextes erscheinen soll. Im gezeigten Beispiel soll der angegebene Text „Bitte wählen Sie die richtige Antwort aus!“ als Arbeitsanweisung dargestellt werden, was eine bestimmte vorab vereinbarte Formatierung des Textes zur Folge hat. Das Feld „Position“ gibt dem Medienentwickler eine Orientierung, an welcher Stelle des Bildschirmes sich der Text befinden soll. Dazu muss eine entsprechende Matrix verabredet sein, z. B.: f1 f4 f7 f2 f5 f8 f3 f6 f9
Der Buchstabe „f“ steht für Feld, f1 bedeutet dabei „links oben“, f9 „rechts unten“. Diese Positionsangaben sind auch bei anderen Elementbeschreibungen (wie Grafik, Animation) in gleicher Weise gültig. Weitere Formatierungsangaben (z. B. reine Textformatierungen, Textanimationen wie Blinken oder Hinweis auf einen Hypertext) sind möglich. In einer „BrowserView“, die im Editor gewählt werden kann, sieht der Autor bereits eine erste Voransicht des erstellten Inhaltes oder des formatierten Textes im späteren Layout. Audio Ein Audio ist i. d. R. ein Sprechertext, der den fachlichen Inhalt des Lernmoduls im Zusammenhang mit weiteren Elementen wie Grafik, Animation oder Aufgaben erklärt. Dieser wird vom Autor als Text formuliert, vom Sprecher aufgenommen und anschließend von den Medienentwicklern eingebunden. Alternativ sollte die Möglichkeit eingeplant werden, den Text auch als Textfenster einblenden zu können, da Kunden auch oft das Lernmodul ohne Sprecherausgabe verwenden wollen. Dies erleichtert insbesondere die Verwendung des Lernmoduls in verschiedenen Sprachversionen. Der eigentliche Sprechertext wird im Feld „Sprechertext“ abgelegt (siehe Abb. 15.6). Soll aufgrund eines Stichwortes eine Aktion ausgelöst werden (z. B. eine Texthervorhebung, eine Grafik oder ein blinkender Bereich in einer Grafik), kann dies im Feld „Stichwort“ benannt werden (z. B. „Skala kurz optisch hervorheben“). Im Feld „Bemerkung“ können Hinweise für den Sprecher zur Betonung oder zur Aussprache gegeben werden. Animation Animationen werden vom Drehbuchautor in verbaler Form beschrieben, da Dateivorlagen hier meist noch nicht existieren. Oft liegen jedoch Grafiken vor, die als Grundgrafik verwendet werden können (Start- oder Endbild) oder zumindest als Vorlage dienen. Hier ist es wichtig, dass der Autor möglichst genaue verbale Beschreibungen im Feld „Beschreibung“ oder „Bemerkung“ liefert, da hier erfahrungsgemäß die
290
15 Entwicklung und Integration von Rich Media Learning Objects
Abb. 15.6: Eingabefelder für Audio
meisten Absprachen zwischen Autor und Medienentwickler erforderlich sind (siehe Abb. 15.7).
Abb. 15.7: Eingabefelder für Animation
Pause Dieses Element wird eingefügt, wenn im Ablauf der Lernsequenz eine Unterbrechung eintreten soll. Der Ablauf der Lernsequenz wird erst dann fortgesetzt, wenn der Benutzer (Lerner) den „Weiter“-Button betätigt (Pause-Benutzer-Führung: PBF). Dies ermöglicht dem Autor, innerhalb eines Lernmoduls kleinere in sich abgeschlossene Lernsequenzen festzulegen. Meist eignen sich diese Lernsequenzen jedoch noch nicht als eigenständige didaktische Objekte im Sinne der SCORM-SCOs. Daher verbleiben sie im Lernmodul, das erfahrungsgemäß etwa 5 bis 6 solche Lernsequenzen enthält und dann als SCO (Sharable Content Object) beschrieben werden kann.
15.3 Der XML-Drehbucheditor
291
Aufgaben Auf die Beschreibung von Aufgaben im Drehbuch soll hier nicht näher eingegangen werden, da die Felder ähnlich der bereits gezeigten Beispiele auszufüllen sind. Hinzu kommt jedoch, dass die Zahl der Felder pro Aufgabe stark zunimmt, um alle möglichen Feedbacktexte einzugeben, die bei den verschiedenen Antwortmöglichkeiten festgelegt werden müssen. Hier muss besonders auf qualifizierte Feedbacktexte geachtet werden, um bei möglichst allen Antwortmöglichkeiten den Lerner nicht nur mit „Richtig!“ oder „Falsch!“ abzuspeisen. Besonders in der Selbstlernphase können solche Rückmeldungen des Lernprogramms frustrierend wirken. Allerdings ist die Konzeption von Aufgaben sehr aufwändig und wird daher leider oft vernachlässigt. Im Drehbucheditor können alle üblichen Aufgabentypen wie Multiple-Choice (einfach, mehrfach), Zuordnungsaufgaben oder Freitextaufgaben eingegeben werden.
16 Standardisierung der Lerneinheiten Claudia Janßen
Durch zunehmende Verbreitung des Internets finden E-Learning und E-Training in der universitären Lehre und der beruflichen Aus- und Weiterbildung immer mehr Anwendung. Diese Entwicklung bietet eine Reihe von Chancen (unter anderem Einsparpotentiale). Gleichzeitig wird evident, dass die fehlende Standardisierung die Kosten in die Höhe treiben kann, da Entwickler Bausteine anderer Systeme nicht ohne aufwändige Re-Implementation wiederverwenden können. Um diesen Nachteil zu beheben, wurde eine Reihe Standardisierungsinitiativen gegründet. Auf dem Weg zum Standard befindet sich SCORM1 (Shareable Content Object Reference Model). SCORM setzt sich zurzeit international durch und bildet die Grundlage der im Folgenden vorgestellten Maßnahmen. Anhand des im I-can-EIB-Projekt entwickelten Drehbucheditors (vgl. Abschnitt 15.3) wird untersucht, welche Erweiterungen notwendig sind, um SCORM-kompatible Lernmaterialien zu erstellen, und inwieweit dieser Prozess automatisiert werden kann (vgl. [Möbus u. a. 2003b]).
16.1 Entwicklung eines Drehbucheditors zur Unterstützung von Autoren bei der Content-Entwicklung Im Projekt ist die Autorenunterstützung ein zentrales Thema. Die Autoren sollen zum einen in ihrer Konzeptionsphase unterstützt werden, zum anderen soll die Wiederverwendung der bereits entwickelten Lerninhalte gefördert werden. Bei Projektbeginn wurde deshalb bzgl. des Ablaufs der Content-Entwicklung beim Partner bfe beobachtet, dass es eine strikte Arbeitsteilung zwischen Drehbuchautoren und Multimedia-Entwicklern gibt. Für die Autoren hat das den Vorteil, sich nicht in die umfangreichen Multimedia-Tools einarbeiten zu müssen. Sie können sich auf didaktische Aspekte konzentrieren. 1
Siehe http://www.adlnet.org/, letzter Zugriff am 26.02.2005.
294
16 Standardisierung der Lerneinheiten
Die Autorenunterstützung durch einen Drehbucheditor sollte eine umfangreiche Reorganisation des Workflows vermeiden und doch Rahmenbedingungen in Form von Schablonen bzgl. des Aufbaus der Lernmodule vorgeben. Schablonen in Form von vordefinierten Eingabemasken fördern nicht nur die angeleitete konzeptionelle Umsetzung, sondern ermöglichen auch, die Entwicklungszeit und -kosten besser abzuschätzen. Ein besonderes Augenmerk wurde auf das Content-Sharing gerichtet. Zu diesem Zweck sollte die Erfassung von Metadaten möglich sein, um diese zur Identifikation von Ressourcen heranziehen zu können. Nach einer eingehenden Tool-Recherche wurde zu Projektbeginn die Entscheidung getroffen, ein eigenes XML-Derivat zu konzipieren, das Richtlinien für Autoren durch Schablonen manifestiert und Metadaten vorsieht. Die Eigenentwicklung – wie kurz im Abschnitt 15.3 beschrieben – ist plattformunabhängig und bietet per XSLT2 die Möglichkeit, andere (zukünftige) Standards zu berücksichtigen. In den folgenden Abschnitten wird zunächst ein kurzer Überblick über Standardisierungsaktivitäten und SCORM gegeben. Anschließend wird der Prozess der nachträglichen SCORM-Standardisierung des E-Learning-Contents beschrieben. Der entscheidende Vorteil der SCORM-Kompatibilität ist, dass dieser Content in beliebigen SCORM-fähigen Learning Management Systems (LMS) wiederverwendet werden kann.
16.2 Content-Standardisierung: ADL-SCORM Besonders im Hinblick auf das Content-Sharing ist die standardisierte Gestaltung der Lerninhalte unverzichtbar. Das Ziel ist es, die Lerninhalte durch Rekombination, Reorganisation und Rekontextualisierung in verschiedenen Anwendungen und Systemen nutzen zu können. Hier ist die Beachtung von Standards in der ContentHerstellung im Hinblick auf die Kursgestaltung und den Datenaustausch hilfreich. Die Advanced Distributed Learning Initiative (ADL) wurde 1997 vom amerikanischen Department of Defense und dem White House Office of Science and Technology Policy gegründet und integriert verschiedene Standardisierungsansätze, u. a. von AICC3 , LTSC-IEEE4 , IMS5 und ARIADNE6 . Als Referenzmodell für webba2
Siehe http://www.w3.org/TR/xslt, letzter Zugriff am 26.02.2005. AICC: Aviation Industry CBT Commitee, siehe http://www.aicc.org/, letzter Zugriff am 26.02.2005. 4 LTSC-IEEE: Learning Technology Standards Commitee, siehe http://ltsc.ieee.org/, letzter Zugriff am 26.02.2005. 5 IMS: Instructional Management System, siehe http://www.imsproject.org/, letzter Zugriff am 26.02.2005. 6 ARIADNE: Alliance of Remote Instructional Authoring and Distribution Networks for Europe, siehe http://www.ariadne-eu.org/, letzter Zugriff am 26.02.2005. 3
16.2 Content-Standardisierung: ADL-SCORM
295
sierte Lerninhalte wurde das Shareable Content Object Reference Model (SCORM) entwickelt und liegt aktuell in der Version SCORM 2004 vor. SCORM setzt sich im Wesentlichen aus dem Content Aggregation Model (CAM) und einer RuntimeEnvironment (RTE) zusammen. Das CAM beschreibt die Zusammenstellung von Lernsequenzen aus einzelnen Lerneinheiten. Diese Pakete können in ein Learning Management System (LMS) importiert werden. Die RTE stellt eine Schnittstelle zwischen dem LMS und einzelnen Lerneinheiten zur Verfügung (vgl. [ADL 2004a], [ADL 2004b], [ADL 2004c]). Eine dritte Komponente, Sequencing and Navigation (SN) (vgl. [ADL 2004d]), beschreibt die Navigation durch einen Kurs. Es werden also die Reihenfolge von Kapiteln oder ereignisgesteuerte Sprungstellen bestimmt. Die kleinste Einheit in SCORM, vergleichbar mit einer Stand-alone-Lesson, ist ein Sharable Content Object (SCO). SCOs setzen sich aus nicht weiter zerlegbaren Bestandteilen (Assets) zusammen, z. B. Bilder, Texte oder Soundfiles, oder enthalten wiederum SCOs. Die SCOs und Assets werden durch Metadaten beschrieben, die zur Identifikation und Suche herangezogen werden können und somit die Wiederverwendung erleichtern. Derzeit findet hierfür die LOM (Learning Object Metadata)Spezifikation7 Anwendung. Diese umfasst neun Kategorien mit verschiedenen (optionalen) Attributen, ist aber grundsätzlich erweiterbar. Grundlage der MetadatenStandardisierung ist das Metadata Element Set der Dublin Core Metadata Initiative8 . • • • • • • • • •
General: Allgemeine Informationen Lifecycle: Merkmale zur Versionenentwicklung und zum Versionsstatus Meta-metadata: Informationen über Metadaten Technical: Angaben über technische Anforderungen und Eigenschaften Educational: Informationen zu pädagogischen Aspekten Rights: Informationen zum Nutzungsrecht Relation: Angaben bzgl. Beziehungen zwischen Lerneinheiten Annotation: Kommentare Classification:Hierarchische Einordnung der Lerneinheiten
Metadaten sind zum einen für den gesamten Kurs vorgesehen (Course Metadata), daneben auch speziell für die einzelnen SCOs (Content Metadata) und Assets (Raw Metadata). Die Tabelle 16.1 führt zu den einzelnen Kategorien die verbindlichen Metadaten auf. Alle weiteren Metadaten sind optional und in der LOM-Dokumentation nachzulesen. Um die Integration des Contents (SCOs) in die jeweiligen LMS und den Austausch zu ermöglichen, wurde im IMS-Projekt eine Content-Packaging-Spezifikation entwickelt. Ein Content Package (CP) repräsentiert z. B. einen Kurs und besteht aus Lernmaterialien, Metadaten-Dateien und einem Manifest. Das Austauschformat ist eine komprimierte Datei (Package Interchange File, PIF) (vgl. Abb. 16.19 ). 7
16 Standardisierung der Lerneinheiten Tabelle 16.1: Pflicht-Metadaten Metadata SCO Mandatory General yes Identifier yes Title yes Catalog yes Entry yes Description yes Keyword yes Lifecycle yes Version yes Status yes Meta-metadata yes Identifier yes meta-data schema yes Technical yes Format yes Location yes Educational no Rights yes Cost yes Coypright and other restrictions yes Relation no Annotation no Classification yes Purpose yes Description yes Keyword yes
Asset Mandatory yes yes yes no no yes no no no no yes yes yes yes yes yes no yes yes yes no no no no no no
Das Manifest ist ein XML-Dokument (mit der Bezeichnung imsmanifest.xml) zur Beschreibung des CP und stellt dessen zentrales Dokument dar. Es enthält Metadaten zur Beschreibung des CP selbst, eine Organisationseinheit zur Beschreibung der SCO-Hierarchie und Referenzen auf die Ressourcen (SCOs und Assets). Das Listing 16.1 zeigt das Gerüst einer Manifest-Datei mit den 4 Elementen Manifest, Metadata, Organizations und Resources. Das Element Manifest umfasst die anderen drei Elemente. Zu Beginn sind die Standorte der LMS- und XML-Parser zwecks Validierung angegeben.
16.2 Content-Standardisierung: ADL-SCORM
297
Content Package Manifest Metadaten SCO-Hierarchie Referenzen auf Ressourcen (Sub-)Manifest(e)
Ressourcen
Abb. 16.1: SCORM – Package Interchange File
1
2
9 10
...
11 12
...
13 14
...
15 16
Listing 16.1: Manifest
Die Listings 16.2, 16.3 und 16.4 enthalten jeweils kurze Ausschnitte zur Veranschaulichung. Die Ausschnitte behandeln die Manifest-Abschnitte Metadata, Organizations und Resources.
298
16 Standardisierung der Lerneinheiten
ADL SCORM 3 1.2 4 5 ... 6 ... 7 8 1 2
Listing 16.2: Ausschnitt Manifest: Metadata
3 EIB Kurs zum Thema "Visualisierungen mit Touch-Displays" 4 5 Visualisierungen mit Touch-Displays 6 7 Touch-Panel monochrom 8 9 10 Touch-Panel mit Funk 11 12 ... 13 14 1 2
Listing 16.3: Ausschnitt Manifest: Organizations
3 4 ... 5 6 ... 7 1
2
Listing 16.4: Ausschnitt Manifest: Resources
16.3 Generierung SCORM-kompatibler Lerneinheiten
299
Um die unabhängige Nutzung der einzelnen SCOs in anderen Kontexten zu ermöglichen, werden die SCOs nicht direkt verknüpft. Die Navigation durch die Lerninhalte erfolgt ausschließlich durch das LMS auf Grundlage der SCO-Hierarchie aus den Manifest-Dateien. Die Kommunikation zwischen den Lerneinheiten und dem LMS wird von der Runtime Environment (RTE) gesteuert. Dazu gehört das Aufrufen, Starten und die externe Navigation zwischen unterschiedlichen SCOs. Genaueres zur Sequentialisierung und Navigation findet sich in [ADL 2004d].
16.3 Generierung SCORM-kompatibler Lerneinheiten Die verteilte Entwicklung multimedialer Lerninhalte gliedert sich im Projekt arbeitsteilig in mehrere Schritte. Im ersten Schritt werden Themen, Konzepte und Content der Lerneinheiten von Fachdidaktikern ausgearbeitet und die Drehbücher erstellt. Im Anschluss daran wird dieses Drehbuch von Multimedia-Entwicklern umgesetzt, indem z. B. Flash-Filme mit Audio-, Video- und Textelementen sowie Animationen erstellt werden. Gegebenenfalls enthält der Flash-Film am Ende eine Lernkontrolle. Die Autoren notieren in den Drehbüchern bereits einige Metadaten (z. B. Keywords, Beschreibung des Contents, Zielgruppe) und in einer gesonderten Datei den Ablauf des Kurses (Reihenfolge der Kapitel). Das Ziel ist es, auf Basis der Drehbücher und Metadaten ein Content Package zu erstellen, das in einem beliebigen SCORM-konformen LMS lauffähig ist. Für Testzwecke haben wir die ADL-Sample-RTE v. 1.2.110 verwendet. Der Drehbucheditor sollte im Zuge der Standardisierung strukturell nur minimal verändert werden. Es werden lediglich Eingabefelder für die Metadaten, die gemäß der LOM-Spezifikation verpflichtend sind, hinzugefügt. Zu diesem Zweck wird der Workflow um einen Arbeitsschritt erweitert, in dem die Metadaten abgefragt werden. Die anschließende Transformation der Drehbücher zu SCOs wird automatisch mittels XSLT, einem Standard für textbasierte Transformationen, vorgenommen, ohne dass weitere Schritte seitens der Entwickler erforderlich sind. Diese Transformation ist in der Abbildung 16.2 schematisch dargestellt. Der erste Schritt der XSL-Transformation besteht aus der Sammlung der relevanten Daten aus den XML-Drehbüchern. Aus den Drehbücher werden z. B. die Metadaten extrahiert und in Variablen zwischengespeichert. Im zweiten Schritt werden diese Daten in neu generierte Dateien (Metadata.xml, Manifest.xml) geschrieben. Die Kapitelhierarchie (Ablauf des Kurses) und die Referenzen auf die Ressourcen werden in der Manifest.xml-Datei festgehalten. Diese Angaben nutzt das LMS zur Navigation durch den Kurs. Die SCO-interne Navigation bleibt davon unberührt. Aus dem 10 Siehe http://www.adlnet.org/index.cfm?fuseaction=rcdetails\&libid=398\&filterid=35\ &, letzter Zugriff am 26.02.2005.
300
16 Standardisierung der Lerneinheiten SCORM-Erweiterung
Drehbuch.xml
Content Package
XSLTransformation
Manifest.xml
Metadata.xml
SCO.html
SCOs
Asset.html
Assets
Multimedia-Bausteine
Abb. 16.2: SCORM – Transformation der Lernmaterialien
Lernstoff eines Drehbuches wird ein SCO generiert, dazu werden die erforderlichen Dateien SCO.html und Asset.html erzeugt. Im dritten und letzten Schritt werden alle Dateien zum Package Interchange File zusammengefasst. Da die Eingabe der Metadaten auf die Pflichtdaten beschränkt wurde, ist der zusätzliche Arbeitsaufwand für die Drehbuch- und Multimedia-Entwickler gering. Neben der rein technischen Abwicklung, wie XSLT-Entwicklung und Durchführung der Transformation, ist jedoch auch konzeptionelle Arbeit erforderlich. Vor der Transformation müssen die Kapitel und Kurse hinsichtlich der vorgesehenen Lernpfade (Kurs-Ablaufplanung, Sequentialisierung der Kapitel) analysiert werden. Vorgesehene Navigationen, die zu festen Verknüpfungen zwischen SCOs führen würden, müssen entfernt werden. Ansonsten wäre die einzelne Wiederverwendung eines SCO nicht möglich. Die SCO-interne Navigation kann unverändert bleiben. Als schwierig erwies sich die Frage nach der SCO-Größe. Werden die SCO sehr klein geplant, können im Zuge des Content-Sharings viele Kombinationen erzeugt werden. Jedoch erhöht sich der Aufwand der Metadaten-Generierung entsprechend. Auch die Analyse der Verknüpfungen wird schwieriger, falls beim Zerlegen der Lerneinheiten essentielle Zusammenhänge auseinander gerissen werden. Andererseits erschwert die Generierung großer SCOs das kontextkonforme Einbinden in andere Systeme. Innerhalb der ADL-RTE lassen sich die Kurse vollständig durchlaufen, so dass Darstellung und Navigation getestet werden können. Wir konnten durch diese Maßnahmen einen Weg aufzeigen, wie auf Basis eines XML-basierten Drehbucheditors und den zugehörigen multimedialen Bausteinen halbautomatisch SCORM-kompatible webbasierte Lerninhalte generiert werden können, ohne dabei zu sehr in den Workflow von Fachautoren und Multimedia-
16.3 Generierung SCORM-kompatibler Lerneinheiten
301
Entwicklern einzugreifen. Diese Lerninhalte sind in hohem Maße wiederverwendbar sowie plattform- und toolunabhängig. Der durch die Angabe der Metadaten kritisierte Zusatzaufwand kann aber gleichzeitig vorteilhaft sein. So können bei der Content-Entwicklung Ressourcen in firmeninternen Repository identifiziert und herangezogen werden. Auch kann durch eine sorgfältige Beschreibung der bereits entwickelten multimedialen Einheiten eine redundante Entwicklung verhindert werden. Weiteren Nutzen bringen sie, wenn sie zur Parametrisierung der Transformation dienen. Dadurch kann eine zielgruppenspezifische Gestaltung der Lerneinheiten erreicht werden. Im I-can-EIB-Portal sind für die unterschiedlichen Zielgruppen spezielle Views vorhanden.
17 Evaluation Claudia Janßen und Claus Möbus
Am Beispiel von EIBY wurde eine Evaluation durchgeführt, die formativen und summativen Charakter hatte. Untersuchungsgegenstand waren die Erwartungshaltungen und die Akzeptanz von Nutzern aus KMU bezüglich natürlicher und virtueller Berater. Der Begriff Evaluation ist dem Qualitätsmanagement zuzuordnen. Gegenstand der Evaluation können Prozesse und Prozessergebnisse (Outcomes) sein. Die Untersuchungsfragen beziehen sich dann entweder auf den Ablauf oder auf das Ergebnis. Die Datenerhebung erfolgte nach einem klassischen Pre-Post-Testversuchsplan, um das Vorgehen und die Ergebnisse objektiv nachvollziehbar und überprüfbar zu machen. Zweck der Evaluation war zum einen die rückblickende Wirkungskontrolle, in der z. B. festgestellt wird, ob die Bildungsmaßnahme erfolgreich war. Zum anderen erfüllt die Evaluation eine vorausschauende Steuerung, indem nach Verbesserungsmöglichkeiten für die durchgeführte Maßnahme gesucht wird. Die Verwendung von Fragebögen – ein Standardmessverfahren – ist eine einfache Möglichkeit, eine große Zahl von Adressaten zu erreichen. Allerdings gibt es eine Reihe von Punkten zu beachten. So erlauben Fragebögen, anders als mündliche Befragungen, z. B. kein Nachfragen bei Unklarheiten, wie etwa missverständlichen Formulierungen oder Versprechern (vgl. [Kirchhoff u. a. 2001]). Der Aufbau des Fragebogens, die Reihenfolge der Fragen, die Wortwahl, die Formulierung der Fragen oder die Antwortvorgaben haben einen erheblichen Einfluss auf die (Qualität der) Antworten und evtl. auch auf die Rücklaufquote. Wir haben keine repräsentative Stichprobe gezogen, sondern gezielt die Teilnehmer eines Meisterkurses am bfe Oldenburg in die Untersuchung einbezogen. Dabei wurden die Richtlinien des Datenschutzes beachtet.
304
17 Evaluation
17.1 Evaluationsobjekt I-can-EIB-Avatar Gegenstand der Evaluation war der in den vorangegangenen Kapiteln vorgestellte Avatar EIBY. Es wurde in einem klassischen Test-Retest-Versuchsplan (vgl. Abschnitt 17.3) geprüft, wie sich die Einstellungen und der Goodwill von Handwerkern gegenüber einem virtuellen Assistenten (Avatar) darstellen. Um Bezugspunkte zu bekommen, wurde auch nach den Einstellungen und Erwartungen gegenüber einem idealen Avatar und einem idealen menschlichen Assistenten gefragt. Die Erhebung erfolgte vor und nach der Beschäftigung mit dem Avatar und klassischen E-Learning-Modulen zum Thema Europäischer Installations-Bus. In den folgenden Abschnitten werden der Fragebogen und das Testdesign vorgestellt. Anschließend wird kurz die statistische Auswertung sowie deren Ergebnisse und Konsequenzen beschrieben.
17.2 Fragebogen An dieser Stelle soll nicht der vollständige Fragebogen, sondern der den Avatar betreffende Ausschnitt vorgestellt werden. Zur Zusammenstellung des Fragebogens lassen sich in der Literatur Untersuchungen finden, die sich mit der Gestaltung und Evaluation von Avataren befassen. Bente und Krämer (vgl. [Bente u. Krämer 2001]) beschäftigen sich mit psychologischen Aspekten bei der Gestaltung und Evaluation anthropomorpher Schnittstellen. Der Fokus dieser Untersuchungen ist auf nonverbale Verhaltenskomponenten gerichtet. Nonverbale Kommunikationskanäle werden durch die visuelle Präsenz virtueller Gesprächspartner eröffnet. Als besonderer Zweck des Einsatzes natürlicher Kommunikationskanäle wird der intuitive Zugang zu Systemen genannt, der sich positiv auf Effizienz und Akzeptanz auswirken soll. In Anlehnung an diese Untersuchung wurden für die Evaluation die folgenden 18 Attribute in den Fragebogen aufgenommen, anhand derer der Avatars beurteilt werden sollte. Die Bewertung erfolgte im Intervall von -3 bis 3. Diese Werte wurden im Fragebogen mit der Semantik „inakzeptabel bis wünschenswert“ belegt, die genauere Differenzierung blieb den Teilnehmern überlassen. 1. 2. 3. 4. 5. 6. 7. 8.
möchte ihn wiedersehen sympathisch überspannt motiviert gereizt begeistert ängstlich nervös
17.4 Datenanalyse und statistische Auswertung
9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
305
erschrocken interessiert aufgeregt aufmerksam wachsam feindselig streng bestimmt bedrängend aktiv
Zusätzlich wurden vier offene Fragen aufgenommen, um evtl. Aspekte zu erfassen, die durch die Attribute nicht abgedeckt werden. Zum anderen wollten wir den Kursteilnehmern die Möglichkeit geben, sich uneingeschränkt zur Thematik zu äußern. 1. In welchen Themenbereichen halten Sie den Einsatz von virtuellen Assistenten für sinnvoll? 2. Wie beurteilen Sie das Verhalten und das Aussehen des virtuellen Assistenten? 3. Wie bewerten Sie die Effizienz bzw. Effektivität des virtuellen Assistenten? 4. Ist Ihnen die Gegenwart eines virtuellen Assistenten recht? Bitte begründen Sie die Antwort.
17.3 Pre-Post-Testdesign Die Teilnehmer des Meisterkurses haben den Fragebogen zunächst vor der Beschäftigung mit dem I-can-EIB-System und dem Avatar bearbeitet (Pre-Test). Sie wurden aufgefordert, die Attribut-Ausprägungen auf der Skala von -3 bis 3 für den I-canEIB-Avatar anzugeben. Um Vergleiche ziehen zu können, wurden auch für einen idealen menschlichen Assistenten und einen idealen Avatar Bewertungen vorgenommen. Somit ergeben sich für den Fragebogen drei Beurteilungsobjekte. Nach einer Beschäftigung mit dem Schulungsmaterial von etwa 70 Minuten wurde der Fragebogen erneut ausgefüllt (Post-Test). Eine schematische Darstellung des Testdesigns zeigt die Abbildung 17.1.
17.4 Datenanalyse und statistische Auswertung Zu Beginn der statistischen Auswertung wurden die Daten der Fragebögen in eine Tabelle übertragen, die z. B. in ein Tabellenkalkulationsprogramm oder eine statistische Software importiert werden kann. Damit die Informationen der Fragebögen den Einträgen der Tabelle auch später noch zuzuordnen sind, werden zunächst Bezeichnungen für die Zeilen und Spalten der
306
17 Evaluation
Pre-Test idealer menschlicher Berater Attribute: aktiv bedrängend … nervös
Post-Test T-Test für abhängige Stichproben
T-Test für unabhängige Stichproben
idealer Avatar
idealer menschlicher Berater Attribute: aktiv bedrängend … nervös
idealer Avatar
Attribute: aktiv bedrängend … nervös
Attribute: aktiv bedrängend … nervös
I-can-EIB-Berater
I-can-EIB-Berater
Attribute: aktiv bedrängend … nervös
Attribute: aktiv bedrängend … nervös
Abb. 17.1: Pre-Post-Testdesign
Tabelle festgelegt. Bei dieser Verkodung werden also den Datensätzen, Fragen und Antworten eindeutige Bezeichner zugeordnet. In der Tabelle wurden zeilenweise die Daten der einzelnen Fragebögen erfasst. In die Spalten wurden die Attribute bzw. Antwortvorgaben eingetragen. Fehlende Angaben (missing values) wurden aus der Wertung genommen. Die Antworten der offenen Fragen wurden unverändert (nicht kodiert) erfasst. Von besonderem Interesse waren die Attribut-Mittelwerte der 3 Beurteilungsobjekte. Die Daten wurden deshalb einem T-Test unterzogen, um signifikante Mittelwertdifferenzen festzustellen. Der T-Test berechnet, ob die beobachteten Mittelwertdifferenzen statistisch signifikant sind. Die durchgeführten Analysen teilten sich in die Bereiche T-Test bei unabhängiger Stichprobe und T-Test bei abhängiger Stichprobe. In der Abbildung 17.1 sind beide T-Test-Varianten eingetragen. Ein Anwendungsgebiet für den T-Test bei abhängigen Stichproben ist z. B. die Durchführung von zwei Messungen an einer Stichprobe (Messwiederholung). In unserem Fall ist dies die Messung vor und nach der Beschäftigung mit dem Lernmaterial und dem Avatar. Ein T-Test bei unabhängiger Stichprobe wird typischerweise durchgeführt, wenn Mittelwerte derselben Variablen (entspricht hier den Attributen) in zwei verschiedenen Fallgruppen miteinander verglichen werden. Es wird untersucht, ob sich die durchschnittlichen Ausprägungen einer bestimmten Variablen signifikant unterschei-
17.5 Ergebnisse
307
den. Es wurden die Variablenausprägungen für die drei Beurteilungsobjekte paarweise verglichen. Dieser Test wurde jeweils mit den Daten des Pre- und des Post-Tests durchgeführt. Ausführliche Informationen zum T-Test und den Voraussetzungen für die Durchführung finden sich z. B. in [Bortz 1989], [Fahrmeir u. a. 2003] und [Westermann 2000].
17.5 Ergebnisse Die Ergebnisse waren insgesamt für uns ermutigend. Im Pre-Test waren die Erwartungen und Einstellungen für alle drei Beurteilungsobjekte auf den 18 Eigenschaftsskalen ziemlich gleich (nichtsignifikante Unterschiede). Nur bei den Eigenschaften ’motiviert’ und ’begeistert’ erwarteten die Probanden vom idealen menschlichen Assistenten mehr (Einsatz). Nach der 70-minütigen Beschäftigung mit I-can-EIB wurden alle 3 Objekte gleich (statistisch nicht signifikante Mittelwertsunterschiede) beurteilt. Damit fiel unser Avatar nicht gegenüber Idealvorstellungen zurück. Allerdings zeigte sich in den Pre-Post-Test-Vergleichen, dass fast alle Urteile in ihrem Ausmaß zurückgenommen wurden. Das deutet darauf hin, dass die Wichtigkeit eines Assistenten (auch eines idealen menschlichen) mit der (erfolgreichen) Beschäftigung mit dem Schulungsmaterial abnimmt. Auch die Beantwortung der offenen Fragen des Fragebogens deutet in die gleiche Richtung. Somit ergibt sich für die Zielgruppenpositionierung des Avatars, dass er in der Wahrnehmung der Meisterschüler für die Anfangsberatung von Hausbesitzern besser geeignet ist als für die technische Beratung von Experten und Langzeitnutzern. Beispielhaft zeigen die Abbildungen 17.2 und 17.3 die grafische Darstellung der Ergebnisse des T-Test-Verfahrens. Es sollen an dieser Stelle lediglich die Relationen der Mittelwerte zwischen den 3 Beurteilungsobjekten veranschaulicht werden. Die Abbildung 17.2 zeigt den Mittelwertvergleich des Pre-Tests. Die Abkürzungen der Legende weisen auf den Pre-Test und die Beurteilungsobjekte Idealer menschlicher Assistent (IM-Pre), Idealer Avatar (IA-Pre) und I-can-EIB-Avatar (ICE-Pre) hin. Die signifikanten Mittelwertabweichungen betrafen die Attribute „motiviert“ und „begeistert“. In der Abbildung 17.3 wird die bereits erwähnte Beobachtung sichtbar, dass viele Urteile in ihrem Ausmaß zurückgenommen wurden.
Die unten stehende Auflistung fasst die Antworten der offenen Fragen im Pre-Test in alphabetischer Reihenfolge zusammen. 1. In welchen Themenbereichen halten Sie den Einsatz von virtuellen Assistenten für sinnvoll? a) Beratung b) Frage-Antwort-Systeme c) Hilfethemen d) keine/gar nicht e) neue/schwierige Themen f) ... 2. Wie beurteilen Sie das Verhalten und das Aussehen des virtuellen Assistenten? a) egal b) gut c) „na ja“ d) ruhig und sachlich e) schlicht f) zurückhaltend und visuell ansprechend g) ...
17.5 Ergebnisse
309
3. Wie bewerten Sie die Effizienz bzw. Effektivität des virtuellen Assistenten? a) bringt mich nicht weiter b) gut c) gut, solange er nicht zu aufdringlich wird d) wichtig e) ... 4. Ist Ihnen die Gegenwart eines virtuellen Assistenten recht? Bitte begründen Sie die Antwort. a) ja, aber nur auf Abruf b) ja, für Hilfe c) ja, für schnelle Unterstützung bei Fehlbedienungen d) nein, ich arbeite mich selbst durch Programme und greife auf Hilfetexte zurück e) ... Im Vergleich dazu wurde im Post-Test folgendermaßen auf die offenen Fragen geantwortet. 1. In welchen Themenbereichen halten Sie den Einsatz von virtuellen Assistenten für sinnvoll? a) Beratung b) egal c) gar nicht d) Hilfethemen e) ... 2. Wie beurteilen Sie das Verhalten und das Aussehen des virtuellen Assistenten? a) bescheiden b) geschmacklos c) gut d) langweilig e) normal, nicht übertrieben f) schlicht g) visuell ansprechend, wie Office XP h) ... 3. Wie bewerten Sie die Effizienz bzw. Effektivität des virtuellen Assistenten? a) als Hilfssystem gut b) ein direkter Ansprechpartner wäre mir lieber c) gut, wenn er Tipps gibt d) ...
310
17 Evaluation
4. Ist Ihnen die Gegenwart eines virtuellen Assistenten recht? Bitte begründen Sie die Antwort. a) ja, als Hilfesystem b) ja, bei allen Themen c) ja, in schwierigen Themenbereichen d) nein, er sollte lediglich durch Fragestellung aktivierbar sein e) zur Fragestellung wünschenswert f) ...
möchte ihn wiedersehen sympatisch überspannt motiviert gereizt begeistert
Abb. 17.3: Signifikante Abweichungen im Pre-Post-Test: Idealer menschlicher Assistent
17.6 Zusammenfassung und Resümee Wir haben eine Evaluation mit klassischer Methodologie über die Akzeptanz unseres Avatars durchgeführt. Die Ergebnisse zeigen, dass zumindest bei unserer ausgewählten Stichprobe (Meisterschüler) die Erwartungen an einen Helfer am Anfang der Beschäftigung mit dem I-can-EIB-System ausgeprägt vorhanden waren und dass man von einem idealen menschlichen Helfer nur mehr Motivation und Begeisterung erwartet als von unserem realen Avatar. Nach einer gewissen Gewöhnung an
17.6 Zusammenfassung und Resümee
311
das System mit möglicherweise Erfolgserlebnissen wird die Wichtigkeit eines externen Helfers generell abgeschwächt. Unser Avatar fällt nicht sehr negativ gegenüber Idealvorstellungen ab. Insgesamt gesehen, sind die Ergebnisse sehr motivierend. Es ist zu erwarten, dass bei verbesserter Kompetenz und besserer Bekanntheit des Avatars die Einschätzungen noch weit positiver werden können. Selbstkritisch muss man attestieren, dass diese Untersuchung nicht nur bei EIB-Experten (Meisterschüler), sondern auch bei I-can-EIB- bzw. EIB-Einsteigern hätte durchgeführt werden sollen. Gerade bei Novizen und Einsteigern wären möglicherweise die Effekte größer gewesen.
Teil III
Für Administratoren: Installation und Konfiguration
18 Portal Stefan Sölbrandt
In diesem und den folgenden Kapiteln sollen dem Administrator Hilfestellungen bei der Installation und Konfiguration eines prototypischen I-can-EIB-Systems gegeben werden. Dieses Kapitel bezieht sich zwar explizit auf das Portal (vgl. Kapitel 10), die Mehrzahl der zu installierenden Komponenten sind aber auch für die Einrichtung von TreeTagger, A.L.I.C.E.-Server, Avatar- und 3D-Multiagentensystem Voraussetzung. Dem Administrator bleibt es je nach eigenem Kenntnisstand selbst überlassen, Abschnitte zu überspringen oder nicht detailliert genug behandelte Themen an anderer Stelle nachzuschlagen. Gegebenenfalls wird auch auf entsprechende OnlineDokumentation verwiesen.
18.1 Systemvoraussetzungen Für den Prototyp des I-can-EIB-Servers wurde Debian-Linux als Open-SourceBetriebssystem verwendet. Grundsätzlich sollte die Installation auch unter anderen Distributionen (z. B. SuSE Linux) funktionieren. Allerdings müssten dafür alternative Instruktionen in die Beschreibungen bzw. in die jeweiligen Installationsskripte integriert und getestet werden. Dieses hätte den Rahmen einer Prototyp-Entwicklung gesprengt. Die Anweisungen in diesem und den nächsten Kapitel(n) beschreiben darum ausschließlich die Installation und Konfiguration unter Debian. Für die Installation des Portals in der Grundversion werden folgende Komponenten benötigt: • Apache HTTP-Server • PHP Version 4 • MySQL-Datenbank • TikiWiki
316
18 Portal
Teilweise sind diese schon in der standardmäßigen Knoppix-Installation enthalten. Es sollte auf jeden Fall geprüft werden, ob die in den nächsten Abschnitten beschriebenen Komponenten bereits auf dem Serversystem vorkonfiguriert sind.
18.2 Apache HTTP-Server Der Apache HTTP-Server1 wurde mit dem Aufsetzen von Debian-Linux wahrscheinlich schon mitinstalliert. Ein Aufruf von http://localhost/
im Web-Browser schafft Gewissheit. Sollte eine Fehlermeldung erscheinen, ist der Server nicht installiert bzw. falsch konfiguriert. In einem solchen Fall sei auf eine ausführliche Anleitung im Internet2 verwiesen.
18.3 PHP Version 4 PHP Version 4 (oder kurz: PHP4) lässt sich unter Debian Linux einfach mit dem Befehl
apt-get install php4
installieren. Als Nächstes sollte überprüft werden, ob dem Apache HTTP-Server in seiner Konfigurationsdatei (/etc/apache/conf/httpd.conf) das PHP-Modul bekannt gemacht wurde (vgl. Listing 18.1). Ansonsten ist diese Datei dementsprechend zu modifizieren. ... # Dynamic SharedObject(DSO) Support ... LoadModule php4_module /usr/lib/apache/1.3/libphp4.so ... Listing 18.1: PHP-Erweiterung in der "‘httpd.conf"’-Datei
1 2
Siehe http://httpd.apache.org/, besucht am 24.03.2005. Siehe http://httpd.apache.org/docs-2.0/install.html, besucht am 24.03.2005.
18.4 MySQL
317
18.4 MySQL MySQL ist wohl der populärste Open-Source-Datenbankserver der Welt. Seine preisgekrönte Geschwindigkeit, Skalierbarkeit und Zuverlässigkeit sind nur einige Gründe, die den Einsatz im TikiWiki-System rechtfertigen.
18.4.1 Installation Die Installation erfolgt analog zu PHP4 mit den Befehlen: apt-get install mysql-server apt-get install mysql-common
Im Falle einer vorherigen Einrichtung von PHP4 sollte geprüft werden, ob in der zugehörigen Initialisierungsdatei (/etc/php4/apache/php.ini) das MySQL-Modul ordnungsgemäß gesetzt wurde (vgl. Listing 18.2). Ist dies nicht der Fall, muss die Datei dementsprechend modifiziert werden. ... extension=mysql.so ... Listing 18.2: MySQL-Erweiterung in der "‘php.ini"’-Datei
18.4.2 Starten des MySQL-Dämons Der MySQL-Dämon lässt sich mit mysqld_safe&
starten. Wenn alles ordnungsgemäß funktioniert, sollte nun sinngemäß eine Meldung ähnlich Starting mysqld daemon with databases from /var/lib/mysql
erscheinen. Falls Fehler oder andere Probleme auftreten, sei auf die Online-Dokumentation3 verwiesen.
3
Siehe http://dev.mysql.com/doc/, besucht am 25.03.2005.
318
18 Portal
18.4.3 Erstellung der Tiki-Datenbank Die neue Datenbank lässt sich im MySQL-Monitor einrichten. Alternativ können natürlich auch Tools wie MysqlAdmin4 oder Webmin5 genutzt werden. Die folgenden Shell-Kommandos richten eine neue Datenbank dbtiki inklusive Benutzer admintikidb ein. mysql ... create database dbtiki; grant allprivileges on dbtiki.* to admintiki@localhost; exit
Ein Passwort lässt sich mit dem folgenden Befehl setzen: mysqladmin -u admintikidb -p password ’ gnaz3sciheers7psowrast’
Die Administrierung auf Shell-Ebene ist etwas umständlich, deshalb wird zu diesem Zweck PHPMyAdmin6 empfohlen.
18.4.4 PHPMyAdmin Die Installation funktioniert unter Linux Debian wie gehabt: apt-get install phpmyadmin
Während der Abarbeitung des Installationsskripts werden vom Nutzer noch einige Angaben benötigt. Bei der Frage „Which Web Server?“ sollten apache, apache-ssl, apache-perl und apache2 schon angewählt sein. Zur Bestätigung reicht es, per TABTaste auf „OK“ zu springen und Enter zu drücken. Es werden nun einige Konfigurationsfiles generiert. Schließlich fragt PhpMyAdmin, ob es Apache neu starten soll, was mit dem Druck auf Enter bestätigt werden kann. PhpMyAdmin sollte nun über http://localhost/phpmyadmin
aufrufbar sein.
4
Siehe http://dev.mysql.com/doc/mysql/en/mysqladmin.html, besucht am 25.03.2005. Siehe http://www.webmin.com/, besucht am 25.03.2005. 6 Siehe http://www.phpmyadmin.net/, besucht am 25.03.2005. 5
18.5 TikiWiki
319
18.5 TikiWiki Als Erstes benötigt man den Tarball oder das ZIP-Archiv von TikiWiki. Es lässt sich im Download-Bereich der TikiWiki-Website7 finden. Das Archiv lässt sich komfortabel mit unzip [NAME DES ZIP-ARCHIVS]
entpacken und an die gewünschte Stelle kopieren. Damit das Installationsskript nicht mit einer Fehlermeldung abbricht, müssen die Zugriffsrechte geändert werden: chmod -R a+rwx [NAME DES TIKI-ORDNERS]/
Um TikiWiki online zu schalten, sollten in /etc/apache/conf/httpd.conf die Ordner-Freigabe und ein entsprechender Alias-Eintrag gesetzt werden (s. Listing 18.3). Alias /tiki/ /...[PFAD ZUM TIKI-ORDNER].../ Options Indexes MultiViews ExecCGI AllowOverride None Order deny,allow Allow from all Listing 18.3: Alias-Eintrag in der httpd.conf-Datei
Abschließend ist noch der DirectoryIndex anzupassen, damit der Apache HTTPServer die PHP-Seiten ordnungsgemäß verarbeitet (s. Listing 18.4). DirectoryIndex ... ... ... ../aiml/beratung/*.aiml Listing 19.1: Konfiguration eines Chatbots in der Datei startup.xml
Für jeden Bot werden Ersetzungsregeln (substitutions) und Trennzeichen für die Eingaben (sentence-splitters) festgelegt. Die Standardkonfiguration ist hierfür ein guter Ausgangspunkt. Jeder Chatbot enthält darüber hinaus eine Referenz auf seine Wissensbasis. Diese besteht aus einer Liste von AIML-Dateien. Innerhalb des learn-Elements können die Dateien einzeln oder mit einfachen Wildcard-Ausdrücken referenziert werden. Der Pfad wird dabei relativ zum Pfad der Konfigurationsdatei angegeben (z. B. ../aiml/standard/*.aiml). Das letzte Konfigurationselement eines Chatbots ist das listeners-Element. Dieses wird benötigt, wenn der Chatbot auf einem IRC-Channel oder anderen InstantMessenger-Protokollen arbeiten soll. Da in diesem Buch der Schwerpunkt auf der Kommunikation über ein Web-Interface liegt, wird dieser Punkt nicht ausführlich behandelt. Hilfestellungen zu diesem Aspekt finden sich in den Mailinglisten.
326
19 Gesprächskomponenten des I-can-EIB-Systems
19.2.4 Eine Web-Applikation erzeugen Um den A.L.I.C.E.-Server zu betreiben, muss dieser als Web-Applikation zusammengepackt werden. Dieses geschieht mit dem Kommando ant configure. Das Programm erzeugt daraufhin das Archiv build/alice.war, das sich aus den benötigten Bibliotheken, den Konfigurationsdateien, den Templates und den AIMLDateien zusammensetzt. Zusätzlich enthält das Archiv auch die Datei web.xml, in der die Konfiguration der Servlets vorgenommen wird. Nähere Informationen zur Konfiguration von Servlets findet man auf den Seiten des Tomcat-Projekts 4 . 19.2.5 Auf dem Server installieren Die soeben erzeugte Datei muss nun auf dem Server installiert werden. Hier gibt es zwei alternative Vorgehensweisen: Man kann entweder die erzeugte Web-Applikation einfach in das root-Verzeichnis des Tomcat-Servlet-Containers kopieren oder die „Tomcat Manager Application“ benutzen. Die einfachere Variante ist es, über die Manager-Applikation das Servlet zu installieren, die im Normalfall unter der IPAdresse des Servers auf Port 8080 (andere Konfigurationen benutzen andere Ports) zu erreichen ist. Hat man die A.L.I.C.E.-Web-Applikation erfolgreich auf dem Server installiert, so steht nach kurzer Wartezeit unter der Adresse http://[Server]:[Port]/alice/alicetagged ein einfaches HTML-Interface zur Verfügung. Verschiedene Chatbots können über den Servlet-Parameter botid auch von außen angesprochen werden. Ein weiterer Servlet-Parameter ist die userid, unter der ein Benutzer den Dialog führt und die ihn eindeutig referenziert. Über den Parameter text bekommt das Servlet die Eingabe des Benutzers übermittelt. Der letzte Parameter beeinflusst das Antwort-Template und wird benutzt, um verschiedene Templates dynamisch zur Verfügung zu stellen. Gültige Werte sind hier unter anderem xml, text und plaintext. Da der A.L.I.C.E.-Server Log-Dateien in sein Verzeichnis auf dem Servers schreibt und eventuell über das Netzwerk auf den TreeTagger zugreifen muss, benötigt die Web-Applikation die entsprechenden Rechte vom Tomcat-Server. Nähere Informationen zu diesem Thema sind in der Tomcat-Dokumentation zu finden. 19.2.6 Wissensinhalte verfügbar machen Dieser Abschnitt bezieht sich nur auf die allgemeinen Vorgänge, die nötig sind, um Wissensinhalte für die Chatbots verfügbar zu machen. Die Erstellung der Wissensinhalte kann entweder direkt in AIML geschehen (siehe Abschnitte 13.3.5 und 13.3.7) oder mit der in Abschnitt 13.4.1 beschriebenen Methode der Entscheidungsbäume. 4
Apache Jakarta Tomcat: http://jakarta.apache.org/tomcat/, letzter Zugriff am 14.04.2005.
19.3 Webbasierte Datenextraktion mit W3 xtract
327
Es gibt verschiedene Vorgehensweisen, die Wissensinhalte für den Zugriff durch Chatbots zu strukturieren. Sowohl die AIML-Dateien selbst als auch die Verzeichnisstruktur bieten dazu Möglichkeiten. Um die Konfiguration einfach zu halten, können alle Dateien eines Chatbots in einem Verzeichnis gespeichert werden. Eine andere Vorgehensweise ist, die Verzeichnisse thematisch nach ihren Wissensinhalten zu sortieren und eventuell für verschiedene Chatbots unterschiedliche Versionen bereitzuhalten. Falls der Server alle Anfragen durch einen der Stemmer vorweg verarbeitet, sollte der gleiche Vorgang auch mit den AIML-Dateien durchgeführt werden. Zu diesem Zweck wurden verschiedene Ant-Tasks geschaffen, die sowohl einzelne Dateien als auch ganze Verzeichnisse verarbeiten können. Hierfür wird der in der Konfigurationsdatei referenzierte Stemmer-Prozess eingesetzt. Die genauen Aufrufe sind in der Datei build.xml und dem Programm org.offis.aimlTools.AutoGenAIML dokumentiert. Wurden die Wissensinhalte mit der Methode der Entscheidungsbäume aus Abschnitt 13.4.1 erfasst, so muss das Wissen aus dem Entscheidungsbaum in AIML transformiert werden. Diese Aufgabe löst ebenfalls das Programm AutoGenAIML. Für eine erfolgreiche Transformation benötigt das Programm XSL-Transformationen, die genau auf den Algorithmus des Entscheidungsbaums abgestimmt sind. Beispiele für die XSL-Transformationen und den Algorithmus sind in dem auf der Website bereitgestellten Paket vorhanden. Damit die Chatbots nicht unerreichbares Wissen im Speicher halten, sollten alle nicht mehr benötigten AIML-Dateien aus der Konfiguration des Chatbots entfernt werden. Dieses kann durch Verschieben der nicht mehr benötigten Dateien oder durch genaue Referenzierung der einzelnen Dateien in der Konfigurationsdatei erfolgen. Abschließend erzeugt man eine neue Web-Applikation und installiert diese auf dem Server wie in den Abschnitten 19.2.4 und 19.2.5 beschrieben.
19.3 Webbasierte Datenextraktion mit W3 xtract 19.3.1 Installation Die Installation des W3 xtract-Tools gestaltet sich sehr einfach. Nach dem Herunterladen5 und Entpacken des erforderlichen Installationspakets müssen nur die Anweisungen der enthaltenen readme-Datei befolgt werden. 19.3.2 Konfiguration und Wartung Eine Beispielkonfiguration für die Extraktion der aktuellen Wettervorhersage ist bereits im Paket enthalten. Sie lässt sich problemlos durch eine eigene austauschen 5
Zu beziehen über http://www.i-can-eib.de.
328
19 Gesprächskomponenten des I-can-EIB-Systems
bzw. um eigene Anweisungen ergänzen. Zu beachten ist, dass für jede Webseite, die zur Datenextraktion herangezogen wird, ein W3 xtract-Job (vgl. Abschnitt E.5) in Form einer XML-Datei (siehe Abschnitt 13.4.3) anzulegen ist. Nach einer abschließenden Modifikation der W3 xtractConfig-Datei werden bei der nächsten Programmausführung u. a. die neuen Jobs eingelesen und ausgeführt. Es ist darauf zu achten, dass die definierten Zieldateien (siehe Abschnitt E.3.5) ordnungsgemäß erzeugt werden und die gewünschten Informationen beinhalten. Hinweise auf eventuelle Fehler während der Datenextraktion liefert die Log-Datei (siehe Abschnitt E.3.2). Eine mögliche Fehlerursache könnte z. B. sein, dass der Informationsanbieter das Layout seiner Webseite (und damit den Aufbau des DOM-Baums) geändert hat (vgl. Abschnitt 13.4.3). In diesem Fall müsste der entsprechende XPath-Ausdruck neu ermittelt werden (siehe Abschnitt 19.3.4).
19.3.3 Zeitgesteuerte Ausführung Ursprünglich wurde das W3 xtract-Tool speziell für dynamische Web-Inhalte konzipiert. Die Wettervorhersage z. B. ändert sich tagtäglich und mindestens genauso oft werden Wetterdienste ihre Internetseiten auch aktualisieren. Aus diesem Grund sollte das Tool in fest definierten zeitlichen Abständen wiederholt ausgeführt werden. Unter Linux als Betriebssystem lässt sich dies sehr einfach mittels Cron Daemon6 einrichten. Der abgebildete Eintrag in der crontab-Datei (vgl. Listing 19.2) ruft das Skript „dynamicKnowledgeUpdate“ 10 Minuten nach jeder vollen Stunde auf (0.10 Uhr, 1.10 Uhr, 2.10 Uhr, usw.). 1
Listing 19.2: Auszug aus der crontab-Datei für den automatisierten stündlichen Aufruf des ausführbaren Skripts dynamicKnowledgeUpdate
Dieses Skript wiederum enthält den korrekten Aufruf zum Starten des W3 xtractTools: java -jar /home/dev/web/dynamic/knowledge/wwwxtract.jar / home/dev/web/dynamic/knowledge/xml/
6
Der Cron Daemon ist eine Jobsteuerung von Unix bzw. Unix-artigen Betriebssystemen wie Linux, die wiederkehrende Aufgaben oder Befehle zu einer bestimmten Zeit ausführen kann. Die auszuführenden Einträge werden in der sog. crontab-Datei gepflegt.
19.3 Webbasierte Datenextraktion mit W3 xtract
329
19.3.4 XPath-Ausdruck ermitteln Das W3 xtract-Tool generiert intern zu einer eingelesene Webseite den entsprechenden DOM-Baum. Für die Definition der W3 xtractJob-Dateien ist es notwendig, die XPath-Ausdrücke zu bestimmen, die zu den Informationen in diesem Baum führen. Exemplarisch werden zwei Möglichkeiten aufgezeigt, um einen XPath-Ausdruck zur gesuchten Information zu ermitteln. Dazu wird als Vorbedingung davon ausgegangen, dass die aktuelle Wettervorhersage über eine URL der Art „http://[WETTERSERVER]/wetter.html“ im Internet abrufbar ist.
xmllint Unter Linux lässt sich u. a. xmllint für die XPath-Ermittlung nutzen. Es wird standardmäßig bei der Installation der XML::LibXML-Bibliothek7 mitgeliefert. Der Aufruf xmllint --shell --html http://[WETTER-SERVER]/wetter.html
in der Shell reicht aus. Nachdem xmllint die Seite fehlerfrei eingelesen hat, der DOM-Baum also korrekt generiert wurde, kann nach einer signifikanten Zeichenfolge aus der Wettervorhersage (in diesem Fall das Wort „Kaltfront“) mittels des „grep“-Befehls gesucht werden. Der Pfad (hier: „/html/body/.../td“) zu dieser Zeichenfolge im Baum entspricht dem XPath-Ausdruck: / > grep Kaltfront /html/body/table/tr/td[1]/table[1]/tr/td/table/tr[5]/td [3]/div[2]/table/tr/td[1]/table[2]/tr/td[3]/table[3]/ tr[2]/td[3]/table/tr/td : t-130 Die Kaltfront eines Tiefs ...
Mozilla DOM-Inspector Wer Schwierigkeiten hat, mit xmllint auf Shell-Ebene zu arbeiten, kann auch einen grafisch ansprechenderen DOM-Inspektor nutzen, wie er z. B. im Mozilla-Browser8 integriert ist. Die Funktionsweise lässt sich anhand des Screenshots in Abbildung 19.1 einfach veranschaulichen. Mozillas DOM-Inspector kann grob in vier Bereiche gegliedert werden. In der oberen Leiste wird, wie in einem normalen Browser, die Internetadresse der Webseite eingetragen. Die gerenderte Seite ist im Screenshot unten zu sehen. Das Besondere ist, dass hier einzelne Elemente des Dokuments anklickbar sind, wenn sich der Nutzer im Node-Inspect-Modus befindet. Dieser lässt sich 7 8
über den Button oben links neben dem Fernglas-Symbol aktivieren. Im linken Bereich des DOM-Inspectors wird der Pfad durch den DOM-Baum zu der angeklickten Information angezeigt. Rechts ist der Inhalt des ausgewählten Node-Elements zu sehen. In der Abbildung ist gerade der Text-Node mit der aktuellen Wettervorhersage ausgewählt. Der Pfad durch die DOM-Elemente von der Wurzel bis zum selektierten Knoten entspricht dem gesuchten XPath-Ausdruck.
Abb. 19.1: Mit Mozillas DOM-Inspector lassen sich die XPath-Ausdrücke einfach ablesen
19.3.5 Alternative HTML-Parser Das W3 xtract-Tool nutzt das frei erhältliche JTidy9 , um aus einer Webseite einen DOM-Baum zu generieren. Das Tool enthält einen HTML-Parser, der auch kleinere Fehler intern korrigiert. Diese resultieren oftmals daraus, dass die HTMLDokumente größtenteils nicht XML-konform sind. In einigen Fällen bricht auch JTidy beim Parsen mit Fehlermeldungen ab. Sollte die zu extrahierende Information nicht auf einer anderen Webseite angeboten werden, bietet sich die Verwendung eines alternativen HTML-Parsers (z. B. CyberNeko10 ) an. Für den geübten JavaEntwickler sollte die Integration ins W3 xtract-Tool kein großes Hindernis darstellen.
9 10
Siehe http://jtidy.sourceforge.net/, besucht am 28.03.2005. Siehe http://www.apache.org/ andyc/neko/doc/html/index.html, besucht am 31.03.2005.
20 Avatar-System Stefan Sölbrandt
20.1 Installation 20.1.1 Allgemeines Das Avatar-System setzt sich aus dem Editor EDGAR und der webfähigen Darstellungskomponente für den „EIBY“ (vgl. jeweils Kapitel 12) zusammen. Letztere ist als Java-Applet konzipiert und lässt sich einfach in das Tiki-Portal integrieren (siehe Abschnitt 18.5) oder als Stand-alone-Version in eine HTML-Seite einbetten. In diesem Kapitel werden die notwendigen Schritte für eine standardmäßige Installation und Konfiguration beschrieben. Ein besonderes Augenmerk liegt dabei auf der Kommunikation zwischen Applet und Server sowohl während der Initialisierungsphase als auch im laufenden Betrieb. Es wird empfohlen, die Konfigurationsanweisungen dieses Kapitels mit den Hinweisen in den aktuell erhältlichen Installationspaketen1 abzugleichen.
20.1.2 Systemanforderungen Im Folgenden werden die für den Aufbau des Avatar-Systems erforderlichen clientund serverseitigen Komponenten getrennt behandelt. Alle verwendeten Technologien sind Open Source bzw. frei erhältlich. Einzige Ausnahme bildet die Logox WebSpeech-Engine2 , für deren Installation auf einem Server Lizenzgebühren entrichtet werden müssen.
1 2
Siehe http://www.i-can-eib.de. Siehe http://www.webspeech.de, besucht am 04.05.2005.
332
20 Avatar-System
Clientseite Der Avatar-Editor EDGAR setzt nur eine standardmäßig eingerichtete Java-Umgebung (ab Version 1.4) voraus. Die webfähige Darstellungskomponente ist dagegen in der derzeitigen Version nur auf dem Betriebssystem Windows getestet. Für die Sprachausgabe des Avatars „EIBY“ kommt das für die Clientseite kostenlos erhältliche Logox WebSpeech-Plugin3 zum Einsatz. Als Browser wird der Internet Explorer (IE) von Mircrosoft inklusive aktivierter Java Virtual Machine (MS-JVM) empfohlen. Leider ist die Auslieferung der MS-JVM nur bis zu Windows XP (Version SP1a) sichergestellt. Sollte sie in der eigenen IE-Version nicht vorhanden sein, werden zwei Lösungswege empfohlen: • Die MS-JVM wird nach wie vor auf einigen Internetseiten zum Download angeboten. Eine entsprechende Suche4 ist auf jeden Fall lohnenswert, da nur mit diesem Plugin eine funktionierende Sprachausgabe sichergestellt ist. • Als Alternative zum IE lässt sich beispielsweise auch der Open-Source-Browser Mozilla Firefox5 mit installiertem Java-Plugin von SUN6 verwenden. In diesem Fall müsste allerdings die Kommunikation zwischen Applet und WebSpeechPlugin überarbeitet werden, da die Sprachausgabe über browserspezifische JavaScript-Funktionen realisiert wird.
Serverseite Als Grundlage dient der in Abschnitt 21.1.1 beschriebene prototypisch aufgebaute Webserver, wobei die VNet- und JADE-Komponenten für die Installation des Avatar-Systems nicht erforderlich sind. Optional bietet das System die Möglichkeit der lippensynchronen Sprachausgabe. Dieses Feature wurde mittels des Logox WebSpeech SDKs implementiert, für das eine entsprechende Lizenz notwendig ist. Die Integration einer alternativen Speech-Engine ist möglich, vorausgesetzt sie besitzt eine Java-Schnittstelle (siehe hierzu Abschnitt 20.2.4). Um Avatar-Modelle direkt aus dem zugehörigen Editor EDGAR auf den Server hochladen zu können, ist zusätzlich die Einrichtung eines FTP-Servers erforderlich. Weitere Informationen zu diesem Thema (inklusive guter Tutorials) lassen sich problemlos im Internet7 finden.
3
Siehe http://www.webspeech.de/download.php, besucht am 04.05.2005. Tipp: Eine Suche nach „msjavx86“ auf http://www.google.de liefert entsprechende Download-Seiten. 5 Siehe http://www.mozilla.org/products/firefox/, letzter Zugriff am: 06.05.2005. 6 Siehe http://java.sun.com/, letzter Zugriff am: 06.05.2005. 7 Siehe z. B. http://www.pro-linux.de/work/server/ftp01.html, besucht am 20.03.2005. 4
20.1 Installation
333
20.1.3 Installation des Avatar-Editors EDGAR Die Installation von EDGAR gestaltet sich sehr einfach und funktioniert prinzipiell auf allen Rechnern mit Java-Umgebung ab Version 1.4. EDGAR ist im Gegensatz zur Darstellungskomponente eine offline ablauffähige Java-Applikation. Einzig die Nutzung des Upload-Features, das es ermöglicht, im Editor erstellte Avatare direkt auf den Server hochzuladen, erfordert temporär eine FTP-Verbindung. Ausführlichere Informationen sind im Installationspaket enthalten.
20.1.4 Installation des Java-Applets Nach der standardmäßigen Einrichtung des Servers kann das Avatar-System aufgesetzt werden. Dazu ist es erforderlich, das entsprechende Installationspaket herunterzuladen und auf dem Server zu entpacken. Unter Beachtung ergänzender Hinweise in der enthaltenen readme-Datei sollte auf dem Server schließlich eine Ordnerstruktur wie in Abbildung 20.1 vorliegen. Dieser Verzeichnisbaum (inklusive Dateien) muss im Internet mit einem Browser erreichbar sein. Im Folgenden wird davon ausgegangen, dass der Zugriff auf den Wurzelordner „ice“ über eine URL der Form http://[SERVER-IP]/ice/
möglich ist. Dazu genügt es, ein entsprechendes Alias in der Konfigurationsdatei (httpd.conf ) des Apache Webservers zu setzen (vgl. Abschnitt 18.3). Nach der korrekten Installation lässt sich der Avatar „EIBY“ über den Browser aufrufen. Wurde der Avatar als Portlet in das Tiki-System integriert, sollte sich dem Nutzer ein Bild ähnlich wie in Abbildung 2.4 (vgl. Kapitel 2) präsentieren.
20.1.5 Das Applet in der Initialisierungsphase Beim ersten Aufruf des Applets herrscht rege Kommunikation mit dem Server. Ein genauerer Blick auf die Vorgänge verdeutlicht Sinn und Aufbau der in Abbildung 20.1 dargestellten Ordnerstruktur. Zur besseren Referenzierbarkeit der Dateien wurA – ) H versehen. de die Abbildung mit Markierungen ( 1. Im ersten Schritt fordert der Browser die HTML-Seiten an. Die Datei applet_iceFace3d.html enthält dabei die zur Darstellung des Applets benötigten PaH rameter (vgl. ). 2. Als Nächstes werden zusätzlich benötigte Bibliotheken (z. B. für die AvatarDarstellung, Sprachausgabe oder Plugin-Erkennung) in Form von jar-Archiven, G JavaScript- und VB-Script-Dateien nachgeladen (vgl. ). 3. Nach der Initialisierung wird das Applet gestartet. In der Grundkonfiguration lädt es vom Server das Avatar-Modell „EIBY“ und bereitet es für die Visualisie-
334
20 Avatar-System
& &
& & &&
& &&
& &&
&
& &#!
&!&&
!&
&& !&
&&
!& !&
&
& &" &#!
& &" &#!
&
&
Abb. 20.1: Die Ordnerstruktur nach der Installation von EIBY
rung auf. Bei den Modelldateien (hier: eiby.ser.gz) handelt es sich um gezippte, B serialisierte Java-Objekte, so wie sie von EDGAR erzeugt werden (vgl. ). 4. Anschließend werden die Definitionen für „EIBYs“ High-Level-Animationen (vgl. Abschnitt 12.4.3) nachgeladen. Als Grundlage für jedes Avatar-Modell dient die avataranimations.xml-Datei. Sie enthält u. a. die zur Erzeugung der Basisemotionen (vgl. Abschnitt 12.4.2) notwendigen Spezifikationen. Zusätzlich können modellspezifische Animationen zur Ergänzung oder Überlagerung herangezogen werden. Sie werden jeweils in einer Datei mit dem Namen [MoC dellname]_avataranimations.xml definiert (vgl. ). 5. Für eine ansprechende GUI-Darstellung (insbesondere in der MS-JVM) wurde das als Open Source erhältliche Thinlet-Toolkit8 verwendet. Vorab wird eine F Properties-Datei (SWS_Gui.properties) geladen (vgl. ). 6. Zur Initialisierung der Indexsuche werden die Stichwörter aus einer XML-Datei E (SWS.xml) eingelesen (vgl. ). 7. Zuletzt wird die Spezifikationsdatei für den Aufbau der Thinlet-GUI geladen D (vgl. ). 8
Siehe http://thinlet.sourceforge.net/, letzter Zugriff am 06.05.2005.
20.2 Konfiguration
335
20.2 Konfiguration 20.2.1 Einleitung Das Applet bietet dem Nutzer verschiedene Informationszugänge über anklickbare Karteireiter (vgl. dazu Abb. 13.21 und Abb. 13.22 in Kapitel 13). Über den jeweiligen Zugang kann er • Anfragen in natürlicher Sprache über eine Eingabemaske an die A.L.I.C.E.Komponente auf dem Server stellen, • Stichwörter zu einem bestimmten Thema aus einer automatisch generierten Liste wählen oder sich • vordefinierte Fragen (ähnlich wie FAQs) oder zusätzlichen Content (z. B. Multimedia-Filme) zum ausgewählten Stichwort beantworten bzw. anzeigen lassen. Der nächste Abschnitt beschreibt die erforderliche Kommunikation zwischen Applet und Server aus technischer Sicht.
20.2.2 Kommunikation zwischen Applet und Server Anfragen seitens des Applets werden über das HTTP-Protokoll an entsprechende Servlets auf dem Server übertragen. Um möglichen Problemen mit Firewalls aus dem Wege zu gehen, sollte die Kommunikation vollständig über den Standardport 80 laufen9 .
Anfragen an den Server Im Wesentlichen gibt es zwei Servlets, die jeweils Anfragen vom Applet entgegennehmen: •
Freitext-Servlet: Dieses Servlet ist für die Verarbeitung natürlichsprachlicher Dialoge zuständig. Für seinen korrekten Aufruf kodiert das Applet den Eingabetext des Nutzers in eine spezielle URL-Anfrage, die es an den Server sendet. Beispielsweise wird die an EIBY gerichtete Frage „Wie alt bist du?“ in die folgende Form gebracht: http://[SERVER-IP]/tomcat/alice/alicetagged?botid= Experte&type=text&text=wie%20alt%20bist%20du? 9 Entsprechende Dokumentation über das Betreiben des Tomcats auf Port 80 ist auf http://jakarta.apache.org/tomcat/ zu finden, letzter Zugriff am 06.05.2005.
336
20 Avatar-System
• Stichwort-Servlet: Im Gegensatz dazu werden themenspezifische Content-Anfragen an das SWS-Servlet gerichtet. Exemplarisch sei hier die URL-Anfrage für das Stichwort „Starkstrom“ gezeigt: http://[SERVER-IP]/tomcat/SWS/SWS?input=Starkstrom
Antwort an das Applet Die Antworten des Servers werden im XML-Format unter Verwendung des HTTPProtokolls zurückgesendet. Das heißt, falls sich die zuvor beschriebenen Anfragen auf Clientseite auch direkt in den Browser eingeben lassen. Als Antwort wird ein für Menschen lesbares XML-Dokument zurückgesendet. Der Ausschnitt einer solchen Antwort auf die Stichwort-Anfrage bzgl. „Starkstrom“ ist in Listing 20.1 zu sehen. 3 Was ist Starkstrom? 4 5 Im allgemeinen Sprachgebrauch gilt bereits die normale 230 Volt-Verkabelung eines Gebäudes als Starkstromleitung. 6 7 ... 8 9 Übertragungsmedium Powerline 10 movie/010107_001.swf 11 10 12 13 ... 14 15 ... 16 1 2
Listing 20.1: Antwort des Servers bei Anfrage bzgl. des Stichworts "‘Starkstrom"’
Exemplarisch ist nur ein Frage-Antwort-Paar () und ein Multimedia-Film () im Listing zu sehen. Die „echte“ Anfrage liefert eine weitaus umfangreichere Auflistung von „FAPs“ und „Movies“. Die -Tags beinhalten den Text, genauso wie er vom Avatar auch gesprochen wird. Zusätzlich können noch Annotationen enthalten sein. Auf diese Weise kann der Avatar beispielsweise textsynchronisiert bestimmte Animationen abspielen (vgl. Abschnitt 12.4.3).
20.2 Konfiguration
337
20.2.3 Die Applet-Parameter Es gibt eine ganze Reihe von Applet-Parametern, die zur Konfiguration des GUIs (inklusive Avatar) verwendet werden: • URL_AVATAR_DIR: Übers Web erreichbares Verzeichnis, das die gezippten und serialisierten Avatar-Modell-Objekte enthält (Default-Wert: „http://[SERVERIP]/ice/dynamic/ser/“). • URL_AVATAR_DIR(1..9): Es lassen sich noch weitere Verzeichnisse als Quellen für Avatar-Modelle angeben. Das ist insbesondere sinnvoll, falls nachträglich bestimmte Verzeichnisse über einen FTP-Port nach außen geöffnet werden, um die Upload-Funktion von EDGAR zu nutzen. •
SPEECH_OBJECT: Spezifiziert die verwendete Speech-Engine (Default-Wert: “WEB_SPEECH“).
•
AVATAR_VISIBLE: In bestimmten Anwendungsfällen kann es auch sinnvoll sein, die Visualisierung des Avatars zu unterdrücken (Default-Wert: „TRUE“).
•
VISUALIZATION_MODUS: Dieser Parameter legt fest, ob das Applet in eine HTML-Seite eingebettet („INTERN“) oder in einem eigenen Fenster angezeigt werden soll (Default-Wert: „FRAME“).
• AVATAR_MODEL_NAME: Spezifiziert das initial darzustellende Avatar-Modell (Default-Wert: „eiby“). •
FACE_ANIMATION_DELAY: Bestimmt die Animationsgeschwindigkeit des Avatars. Je höher der Wert, desto schneller (aber auch hektischer) sind seine Bewegungen (Default-Wert: „0“).
•
AVATAR_PROACTIVE_ASK_MOVIES: Das Setzen dieses Parameters veranlasst
den Avatar, dem Nutzer proaktiv Rich Media Content anzubieten, wenn er über einen längeren Zeitraum keine Eingaben mehr getätigt hat (Default-Wert = „TRUE“). • AVATAR_PROACTIVE_ASK_SWS: Analog dazu kann der Nutzer auch proaktiv auf bestimmte Stichwörter angesprochen werden (Default-Wert = „TRUE“). •
URL_ALICE_INPUT_SERVLET: URL-Adresse des Freitext-Servlets zur Kommunikation mit der A.L.I.C.E.-Komponente (Default-Wert: „http://[SERVERIP]/tomcat/alice/alicetagged?botid=“).
•
BOT_ID: Die A.L.I.C.E.-Komponente bietet die Möglichkeit, je nach Setzen dieses Parameters unterschiedliche Regeln zur Antwortgenerierung heranzuziehen. Auf diese Weise lassen sich unterschiedliche Gesprächskompetenzen simulieren (Default-Wert = „Experte“).
338
20 Avatar-System
• URL_SWS_SERVLET: URL des Stichwort-Servlets, das die entsprechenden FrageAntwort-Paare und Informationen über relevante Multimedia-Filme im XMLFormat liefert (Default-Wert: „http://[SERVER-IP]/tomcat/SWS/SWS“). •
URL_AVATAR_ANIMATIONS: URL der High-Level-Animations-Definitionen für die Avatar-Modelle (Default-Wert: „http://[SERVER-IP]/ice/dynamic/xml/avatar/ animation/avataranimations.xml“).
20.2.4 Anbindung alternativer TTS-Engines Es ist durchaus möglich, anstatt Logox WebSpeech eine alternative Speech-Engine in das Avatar-System zu integrieren. Abbildung 20.2 zeigt das Klassendiagramm der relevanten Komponenten. Wenn die neue Speech-Engine eine Java-Schnittstelle besitzt, lässt sie sich durch Erweiterung der abstrakten Klassen Speech und SpeechTagger ansteuern. Die genaue Funktionsweise erschließt sich dem Java-Programmierer am besten durch eine Analyse des Source-Codes10 . Aus diesem Grund soll hier auf die konkrete Implementierung nicht weiter eingegangen werden.
# $
!"
!"
# $
!" &%'' (
!" &%'' (
& &
% &
&
Abb. 20.2: Klassendiagramm der Sprachkomponente (vgl. Abschnitt 12.2) 10
Zu beziehen über http://www.i-can-eib.de.
21 3D-Multiagentensystem Jens Krefeldt, Jörg Stumpe und Stefan Willer
21.1 Installation Das Multiagentensystem (MAS) besteht aus zwei Teilen, der Serverseite und der Clientseite. In den folgenden Abschnitten werden die allgemeinen Systemanforderungen für die jeweiligen Komponenten besprochen und die Vorgehensweise bei der Installation auf einem Linux-System beschrieben. Die Installationsbeschreibung sollte jedoch mit einer Online-Version verglichen werden, um Änderungen am I-can-EIBSystem zu berücksichtigen.
21.1.1 Systemanforderungen Das MAS stellt eine Reihe an Systemanforderungen, die für die beiden Komponenten erklärt werden. Zu den Anforderungen wird jeweils eine exakte Version der bestehenden Testinstallation angegeben.
Clientseite Auf der Clientseite wird über ein Applet ein VRML-Plugin angesteuert und mit dem VNet-Server kommuniziert. Als VRML-Plugin stehen verschiedene Produkte zur Auswahl. Im Testumfeld haben sich jedoch bisher zwei Player bewährt: • Blaxxun Contact 51 • BS Contact VRML 6.12 1
Siehe http://www.blaxxun.com/de/products/contact/index.html, letzter Zugriff am 06.05.2005. 2 Siehe http://www.bitmanagement.de/?page=/products/bs_contact_vrml.html, letzter Zugriff am 06.05.2005.
340
21 3D-Multiagentensystem
Beide Player sind frei verfügbar und werden als Plugin in den Internet Explorer eingebettet. Im Falle einer Installation des BS Contact 6.1 sollte der „Manuelle Download“ anstatt der „Automatischen Installation (Cab-Datei)“ gewählt werden. Da die beiden Player in der Entwicklung mit der Java Virtual Machine von Microsoft (MSJVM) zusammenarbeiten, sollte diese MS-JVM installiert und aktiviert sein. Eine Aktivierung lässt sich bei Vorhandensein verschiedener VMs über die Systemsteuerung (Abschnitt ’Java Plugin’) vornehmen. Zu beachten ist weiterhin, dass die Verbreitung dieser MS-JVM nur bis zu Windows XP (Version SP1a) sichergestellt ist. Nachfolgende Windows-Versionen werden nicht mehr mit einer MS-JVM ausgeliefert. Voraussetzungen für den Einsatz der VRML-Plugins werden sich somit in der Zukunft wahrscheinlich diesen Änderungen anpassen.
Serverseite Das MAS besteht aus einem virtuellen Chatsystem und einer Agentenkommunikationsplattform. Darüber hinaus werden ein Webserver, ein Servlet-Container und Chatbots benötigt. Als virtuelles Chatsystem wird VNet (siehe Abschnitt 14.2.1) verwendet. Die über das Chatsystem ansprechbaren Agenten werden mittels der Agentenkommunikationsplattform JADE (siehe Abschnitt 14.2.2) bereitgestellt. Ihre Interaktionsfähigkeit stellt der Chatbot-Server A.L.I.C.E. (siehe Abschnitt 14.2.3) sicher. Konfigurationsaufgaben, wie die Anpassung von VRML-Ausstellungen und die Konfiguration der Agenten werden durch Servlets realisiert, wodurch ein Servlet-Container notwendig ist. Als Servlet-Container wird Apache Tomcat (siehe http://jakarta.apache.org/ tomcat/) verwendet. Abschließend liefert ein Webserver zusätzlich PHP-Funktionalität – z. B. Apache3 . Da nur plattformunabhängige, auf Java basierende Bestandteile verwendet werden, ist die Wahl der Plattform prinzipiell freigestellt. Hier nun eine Zusammenstellung der genauen Versionen aller Systemkomponenten: • • • • • •
OS: Debian 2.4 (Knoppix 3.4) Java: JDK1.3.1_03-b03 und JDK1.4.2_02-b03 VNet: Version 2.0.39 JADE: Version 3.2 Tomcat: Version 4.1.31 Apache: Version 1.3.31 und PHP Version 4
21.1.2 Installation des MAS-Systems Das 3D-Multiagentensystem ist weitestgehend eigenständig. Es ist lediglich über den A.L.I.C.E.-Server mit dem I-can-EIB-System verbunden. Diese Anbindung ermöglicht die Dialogführung zwischen realen Benutzern und virtuellen Agenten im Chat. 3
Siehe http://httpd.apache.org, besucht am 29.03.2005.
21.1 Installation
341
Somit wird an dieser Stelle bei der Installation von A.L.I.C.E. auf Abschnitt 19.2.2 verwiesen.
Installation der Komponenten Ausgegangen wird bei dieser Installation von einem Debian-System (prinzipiell alle Linux-Derivate) und der Vorinstallation folgender Applikationen: • • • • •
JDK 1.3.1_03 für die VNet-Entwicklung bzw. Lauffähigkeit. JDK 1.4 für die JADE-Entwicklung bzw. Lauffähigkeit. Ant 1.5 für die diversen Build-Skripte in VNet und JADE. Apache HTTP-Server für den Web-Zugriff auf VNet. Jakarta Tomcat 4.1.x für die Konfiguration von JADE (siehe Abschnitt 21.2.2), den Ausstellungseditor (siehe Abschnitt 21.2.3) und A.L.I.C.E. (siehe Abschnitt 19.2.2). • Weitere Applikationen wie perl und find für Skripte. Nun sollten die für das MAS notwendigen Module installiert werden. Folgende Module werden in einem dafür angelegten Ordner auf gleicher Ebene entpackt: • • • •
ice-content beinhaltet Multimedia-Inhalte zur Darstellung im Chatsystem. ice-vnet beinhaltet den VNet-Server. ice-jade beinhaltet die JADE-Plattform. misc beinhaltet HTTP-Server-Anpassungen und Skripte.
Nachdem die Ordnerstruktur erstellt wurde, sind die folgenden Installationsschritte durchzuführen: 1. IPs der Konfigurationsdateien müssen dem aktuellen System entsprechen. Hierzu wird das Skript misc/change-ip.sh verwendet. Dieses muss auf die aktuelle Server-IP angepasst werden. Nach dem Editieren sollte es aus dem Hauptverzeichnis gestartet werden: sh misc/change-ip.sh 2. Installationspfade müssen in folgenden Dateien angepasst werden: • ice-jade/jadectl • ice-jade/config.xml • ice-vnet/vnetctl • misc/httpd.conf 3. Der Hostname der Rechners muss in die ice-jade/servlet_controller.property eingetragen werden. 4. Umgebungsvariable JAVA_HOME auf das JDK1.4 setzen. Wird von Tomcat benötigt. 5. Umgebungsvariable JAVA_HOME_1.3.1_03 in ice-vnet/build.xml setzen. 6. Umgebungsvariable JAVA_HOME_1.3.1_03 in ice-jade/build.xml setzen. 7. Umgebungsvariable JAVA_HOME_1.4 in ice-jade/build.xml setzen. 8. Umgebungsvariable TOMCAT_HOME in ice-jade/build.xml setzen.
342
21 3D-Multiagentensystem
9. Umgebungsvariable JAVA_HOME_1.4 in ice-jade/jadectl setzen. 10. misc/httpd.conf ins Konfigurationsverzeichnis des Apache HTTP-Servers kopieren oder die bestehende Konfigurationsdatei erweitern. Nachdem alle Einstellungen getätigt worden sind, kann das System gestartet werden. In der bereitgestellten Version muss keine Neukompilierung des Systems erfolgen, um es zu starten. Lediglich die Servlet-Anwendung ice-jade/lib/JADE-VNetControllerServlet.war muss installiert werden und der Hostname in der servlet_controller.property, wie eingangs erwähnt, angepasst werden. Der erste Schritt sollte der Dokumentation des Servlet-Containers entnommen werden. Der Systemstart umfasst vier Schritte in folgender Reihenfolge: 1. 2. 3. 4.
Das System ist nun gestartet und kann verwendet werden. Der 3D-Chat ist unter der Adresse http://[SERVER-IP]/ice/vnet/index.php erreichbar. Die Konfiguration erscheint unter http://[SERVER-IP]:8080/control/configurationController. Die Veränderung der Räume erfolgt unter der Adresse http://[SERVER-IP]:8080/control/ designerController.
Neukompilierung des Systems Falls das System verändert wird, steht je nach Veränderung eine Neukompilierung der Module an. Das Erstellen der einzelnen Module geschieht mittels Ant-build Dateien. Für die Module alice-tomcat, ice-vnet und ice-jade liegt jeweils eine build.xmlDatei vor. Das Erstellen des alice-tomcat-Moduls wird in Abschnitt 19.2.2 beschrieben. Für die Module ice-vnet und ice-jade wird das Ant-Target ant all verwendet. Dieses Target startet wiederum untergeordnete Aufgaben, die der Entwickler bei Bedarf den Build-Dateien entnehmen sollte. Falls die Servlet-Anwendung verändert wurde, so muss die neu erstellte war-Datei dem Servlet-Container bereitgestellt werden. Sie liegt im Verzeichnis ice-jade/lib.
21.2 Konfiguration In den folgenden Abschnitten werden die Konfigurationsmöglichkeiten des I-canEIB-Systems dargestellt. Ausgehend von den Eigenschaften des VNet-Chatsystems werden die Einstellungen des JADE-Multiagentensystems erläutert und abschließend wird auf den Ausstellungskonfigurator eingegangen.
21.2 Konfiguration
343
21.2.1 VNet-Client/Server-Konfiguration Die Konfigurationsmöglichkeiten des Clients und des Servers beschränken sich auf die Angabe des Ports, auf dem sie kommunizieren. Der Port für den Client kann direkt in dem Applet-GUI eingegeben werden, falls er vom Standardport 8888 abweichen sollte. Dem Server kann beim Starten optional4 auf der Kommandozeile der Port übergegeben werden, z. B. wenn der Port 8889 genutzt werden soll: java -cp ... VSystem 8889
bzw. über das Linux-Start/Stopp-Skript vnetctl: vnetctl 8889.
21.2.2 JADE-Eigenschaften Das Laufzeitverhalten der JADE-Agenten kann über zwei Wege verändert werden. Neben einem Web-Interface, welches das Editieren der Eigenschaften ermöglicht, ist auch die direkte Manipulation einer Textdatei ([INST-DIR]/ice-jade/config.xml) auf der Serverseite vorgesehen. Das Web-Interface greift auf diese Datei zu und vereinfacht das Editieren. Abbildung 21.1 zeigt diese Konfigurationshilfe mit vorgegebenen Werten. Es lassen sich z. B. Basiseinstellungen zu den Agenten oder Verzeichnissen vornehmen. Eine detaillierte Beschreibung der Verwendung dieser Felder ist im Anhang (G) zu finden.
Konfigurationsdateien Der Wissensmarktplatz wird wie in Abschnitt 21.2.2 erwähnt mittels einer XMLDatei config.xml konfiguriert. Die entsprechende Datenstruktur ist die Klasse vnet.control.controller.config.Configurator. Falls die Konfiguration erweitert wird, muss die Klasse Configurator angepasst werden. Die Konfiguration wird in sechs Bereiche unterschieden, zu denen folgende Eigenschaften (Elemente) editiert werden können: • : Verbindungs- und aussehensspezifische Informationen der Chatagenten. • : Verhalten eines Agenten. • : Verfügbare Rollen repräsentiert durch A.L.I.C.E.-Agenten. • : Skriptverzeichnis für die Agenten. • : Verzeichnisse für die Ausstellungskonfiguration. • : Bestimmung der Log-Einstellungen. 4
Wie beim Client wird auch beim Server standardmäßig Port 8888 genutzt.
344
21 3D-Multiagentensystem
Abb. 21.1: Konfiguration der JADE-Eigenschaften
Element clientAgent • : Port, den VNet zur Verbindung vorgibt. • : Begrüßungstext, der im Chatfenster direkt nach dem Einloggen erscheint.
21.2 Konfiguration
345
• : Maximale Anzahl an gleichzeitigen Gesprächsteilnehmern eines Agenten. • : Die Zeiteinheit, die ein Agent zur Verfügung steht, nachdem er angesprochen wird. Wird er in dieser Zeit nicht noch einmal angesprochen, verabschiedet er sich aus dem Gespräch. • : Nachricht, falls sich der Agent schon im Gespräch befindet. • : Präfix „Mein Kollege“ für den Satz „Mein Kollege XXX steht Ihnen jetzt zur Verfügung.“. • : Suffix „ steht Ihnen jetzt zur Verfügung.“ für den Satz „Mein Kollege XXX steht Ihnen jetzt zur Verfügung.“. Dieser Satz wird aus dem Präfix, dem Namen des Agenten und dem Suffix zusammengestellt. • : Relativer Pfad zur VRML-Darstellung eines Agenten. • : Default-Name für einen Agenten, falls keine Namen zur Verfügung stehen. • : Ist ein Identifikator, der nach der Rolle des Agenten erscheint, z. B. das „[EIB]“ in „Andreas – Experte [EIB]“. Element controllerAgent • : Der Name, unter dem der Controller-Agent im DF eingetragen wird. – : Element, das alle möglichen Namen für Agenten enthält, die erstellt werden können. · : Element, das alle möglichen Namen für Agenten enthält. · 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.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.
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.
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
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
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. ...
<strong>Die Wetterlage
< /tr>
3
4
5 6
Die Kaltfront eines Tiefs überquert heute Deutschland von Nordwest nach Südost, dahinter strömt kühlere Meeresluft zu uns.
...
7 8
9 10
... 11 1
2
Listing E.1: Ausschnitt einer HTML-Seite mit Informationen über die aktuelle Wetterlage
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.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
Transkription
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
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
