Konzeption und Realisierung eines Agenten zum Einholen von Angeboten für Finanzdienstleistungen im Internet

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Übersicht und Motivation
1.1 Beschreibung des Softwareagenten Trustee und dessen Forschungsumfeld
1.1.1 Definitionen
1.1.2 Die Vision des Softwareagenten Trustee
1.2 Problemfelder der Finanzberatung
1.3 Motivation des Trustee
1.4 Aufbau der Arbeit

2. Bisherige Ansätze auf beteiligten Gebieten
2.1 Personalisierung und Privatsphäre
2.2 Internetbasierte Softwareagenten
2.3 Zusammenfassung

3. Planung und Realisierung eines Prototypen
3.1 Arbeitsfelder der Trustee-Entwicklung
3.2 Schnittstellen zu den Clusterprojekten
3.2.1 Übersicht
3.2.2 SIPKIS
3.2.3 SIPREACT
3.3 Konzepte und Architektur des Prototypen
3.3.1 Übersicht der Architektur
3.3.2 Die Kommunikationskomponenten des Trustee
3.3.2.1 Kommunikation mit den Kunden
3.3.2.2 Kommunikation mit den Cluster-Partnern
3.3.2.3 Kommunikation mit den Anbietern
3.3.2.4 Kommunikation mit dem Wissensingenieur
3.3.2.5 Der Trustee-Kern
3.3.3 Der Ablauf der Angebotseinholung
3.4 Ausgewählte Kernbereiche des Prototypen
3.4.1 Wissensrepräsentation und –speicherung
3.4.1.1 Übersicht
3.4.1.2 Repräsentation des Domänenwissens
3.4.1.2.1 Besondere Konzepte der Beschreibungslogik
3.4.1.2.2 Die Verwendung der Beschreibungslogik beim Trustee
3.4.1.3 Repräsentation der Anbieterseiten
3.4.1.3.1 Die Modellierungssprache TRS
3.4.1.3.2 Verknüpfung der Seitenmodelle mit der Wissensbasis
3.4.2 Schutz der Kundendaten
3.4.2.1 Übersicht der zu schützenden Kundendaten
3.4.2.2 Umsetzung
3.4.2.2.1 Sicherung der Internetebene und der Transportebene
3.4.2.2.2 Sicherung der Applikationsebene

4. Zukünftige Entwicklungen

Literaturverzeichnis

Anhang
I. Modell einer Anbieterseite in TrusteeScript
II. Inhaltsverzeichnis der natürlichsprachlichen Beschreibung
III. EBNF-Darstellung von TrusteeScript
IV. Interner Workshopbericht des FORSIP zum Trustee
V. Bericht des Teilprojekts SIPKIS über Kundeneinstellungen
VI. Bericht des Teilprojekts SIPKIS über Kundeninformationen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1 Übersicht der Projekte

Abbildung 2 Die logische Architektur des Trustee

Abbildung 3 Eine beispielhafte XQuery-Anfrage

Abbildung 4 Verarbeitung der Anbieterseiten

Abbildung 5 Der Trustee-Kern

Abbildung 6 Anwendungsszenario der Individuenklassifikation

Abbildung 7 Anwendungsszenario der Subsumtion

Abbildung 8 Auszug aus einem TRS-Seitenmodell

Abbildung 9 Profil-Portfolio

Abbildung 10 Darstellung des Datenbaumes

Tabellenverzeichnis

Tabelle 1 Übersicht der Projektpartner

Tabelle 2 Der Trustee als Softwareagent

Tabelle 3 Übersicht über Problemstellung und Lösungsansätze

Tabelle 4 Schnittstellen SIPKIS

Tabelle 5 Schnittstellen SIPREACT

Tabelle 6 Syntax von TRS/TRSML

Tabelle 7 Übersicht der Kundeneinstellungen ([Winkl03])

Tabelle 8 Übersicht der Kundeninformationen ([Winkl03a])

Tabelle 9 Vorgehen bei Kundendatenänderungen

Tabelle 10 Übersicht der Datenfreigabe

1. Übersicht und Motivation

Diese Diplomarbeit beschreibt die Konzeption und Realisierung eines Agenten zum Einholen von Angeboten für Finanzdienstleistungen im Internet. Im ersten Kapitel werden die Grundlagen für die weitere Arbeit gelegt. Diese bestehen aus den wichtigsten Definitionen, den Problemfeldern der Finanzberatung und der daraus resultierenden Motivation des Projektes. Ein Überblick des Diplomarbeitsaufbaus beschließt das erste Kapitel.

1.1 Beschreibung des Softwareagenten Trustee und dessen Forschungsumfeld

Bevor die Einzelheiten des Softwareagenten Trustee vorgestellt werden, wird zunächst das Forschungsumfeld beleuchtet, in dem dieses System entsteht. Das Projekt Trustee ist ein Teil des FORSIP^[1]. Dieser Forschungsverbund mit Prof. Kießling als Sprecher wurde im Jahr 2002 vom bayerischen Staat ins Leben gerufen und wird von diesem gefördert.

Das FORSIP ist ein Verbund thematisch verwandter Projekte, die sich mit den Forschungsfeldern Situierung, Personalisierung und Individualisierung, sowohl im Wohnbereich, im Bereich der Mimik- und Gestikerkennung als auch im Bereich der elektronischen Einkaufsberatung, befassen. Die einzelnen Teilprojekte sind in Gruppen (sog. Cluster) organisiert. Zwischen den Teilprojekten in einem Cluster bestehen inhaltliche Anknüpfungspunkte, so dass Möglichkeiten der interdisziplinären Zusammenarbeit bestehen. An dieser Stelle erfolgt keine Beschreibung aller Teilprojekte des FORSIP, jedoch wird das Cluster, in dem der Trustee entsteht, näher vorgestellt. Dieses Cluster setzt sich aus vier verbundenen Teilprojekten zusammen wie aus Tabelle 1 ersichtlich ist.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1 Übersicht der Projektpartner

Als Domäne für das Cluster wurde die private Altersvorsorge gewählt. Dabei geht es konkret um die Deckung der Versorgungslücke, die als Differenz zwischen dem Finanzbedarf im Alter und der Höhe der gesetzlichen Rente/Pension definiert ist. Die Aufgabe von SIPKIS ist es dabei, die vorhandene Versorgungslücke und den notwendigen Sparbetrag zu errechnen und für den Kunden ein maßgeschneidertes Produktportfolio auszugeben, dessen Ertrag im Alter die gesetzliche Rente ergänzt. Die Aufgabe des Trustee ist die Suche nach und das Einholen von Produktangeboten der im Portfolio angegebenen Produktkategorien im Internet.

Ein Meilenstein der Planung des FORSIP ist eine erfolgreiche Teilnahme an der Computermesse SYSTEMS 2003 in München. Jedes Cluster stellt jeweils ein Exponat für diese Messe zusammen.

Das Cluster, dem der Trustee angehört, plant u. a. einen funktionsfähigen Messedemonstrator, der ein integriertes Gesamtsystem der drei Teilprojekte darstellt. Zukünftig sollen die Prototypen der Teilprojekte jedoch auch im Stand-Alone-Betrieb funktionieren.

1.1.1 Definitionen

Die Begriffe Personalisierung und Individualisierung werden für den weiteren Verlauf der Arbeit folgendermaßen definiert:

„Der Begriff ‚Individuum’ beschreibt in Bezug auf einen Menschen die Menge aller Merkmale (physiologisch, geistig), die vorliegen. Die Merkmale sind weder vom Individuum selbst (Introspektion) noch von anderen Individuen vollständig erfassbar. Insbesondere sind die Merkmale relevant, mit denen sich der Mensch von anderen Menschen unterscheidet.“ [Farns03, S. 7]

Definition 1 Begriff des Individuums

„Im technologischen Sinn beschreibt Individualisierung die Fokussierung auf ein Individuum im Gegensatz zur bloßen groben Klassifizierung des Individuums. Fokussierung bedeutet hier die Erhebung und Nutzung von individuellen Daten und die Modellierung des Individuums mit diesen Daten. Der Begriff Individualisierung ist nur im Sinn einer Tendenz und Bestrebung zu verstehen und wird niemals vollständig umgesetzt, da ein Individuum prinzipiell nicht in allen seinen Merkmalen vollständig erfassbar ist. Daher sind Stereotypen auch bei der Individualisierung ein unumgängliches Werkzeug.“ [Farns03, S. 7]

„Vom lateinischen Wort ‚persona’, aus dem griechischen Wort ‚prosopon’ abgeleitet, was ‚Maske’ bedeutet. Die Persona war im Altertum die Maske, die sich die Schauspieler vor das Gesicht hielten. Daher ist die Person eng verknüpft mit dem Begriff der Rolle. Die Person beschreibt das, was vom Individuum gesehen wird.

Beim Personenbegriff steht immer die Interaktion im Mittelpunkt: er ist der "Inbegriff, das Zentrum und die Einheit der auf andere Personen intentional gerichteten Akte" (Schischkoff 1991). Nach Luhmann ist die Person nicht als ein Objekt zu verstehen, sondern als eine besondere Art der Unterscheidung. Mit der Person ist eine Adresse gemeint, an die sich eine Kommunikation richten kann. In diesem Sinn sind Personen kommunikative Artefakte. Der Psychoanalytiker C.G. Jung versteht unter Persona jenen Ausschnitt des Ich, dem die Beziehung mit der Umwelt obliegt. ‚Sie ist ein Kompromiss zwischen Individuum und Sozietät über das, ,als was Einer erscheint'’ (Jung 1933).“ [Farns03, S. 7]

Definition 2 Begriff der Person

„Die Personalisierung bedeutet nach dem oben gesagten die Betrachtung des Individuums in einer Rolle. Dazu wird die Individualisierung auf die Merkmale eingeschränkt, die für die Ausübung der Rolle notwendig sind. Die Personalisierung ist also ein Sonderfall der Individualisierung.“ [Farns03, S. 7]

„Als Situation wird zunächst die Gesamtheit der Umstände (wahrnehmbare und/oder antizipierte Gegebenheiten und Entwicklungstendenzen) eines Individuums bezeichnet. Dies kann z.B. zeitliche, räumliche, physiologische oder soziale Umstände umfassen. Die Betrachtung von Situationen erfolgt in der Regel intentional, wobei sich die Auswahl der zu betrachtenden Umstände aus der Intention ableitet.“[Farns03, S. 7]

Definition 3 Begriff der Situierung

„Situierung heißt, dass ein Bezug zu der Situation des Individuums besteht bzw. hergestellt wird. Es bedeutet auch, dass den Änderungen von individuellen Merkmalen über die Zeit Rechnung getragen wird.“[Farns03, S. 8]

1.1.2 Die Vision des Softwareagenten Trustee

„Ein Trustee ist ein Agent, der im Internet zwischen dem Kunden und dem Anbieter vermittelt. Der Kunde tritt nicht mehr direkt mit dem Anbieter in Kontakt, sondern vertraut dem Trustee seine Daten an. Der Trustee besitzt Branchenwissen, das er nutzt, um die notwendigsten Daten für einen Abschluss vom Kunden zu erheben. Der Trustee kennt zudem die typischen Kundenmodelle der Anbieter einer Branche. Er verwaltet die Kundendaten und kann einerseits den Kunden davor schützen, zu viele Informationen von sich preiszugeben, andererseits kann er die Kundendaten gegenüber dem Anbieter so einsetzen, dass es den höchstmöglichen Nutzen für den Kunden bringt. Zu dem kann ein Trustee die Kundendaten so verändern, dass der optimale Abschluss nicht gefährdet ist, aber die Anonymität des Kunden gewahrt bleibt.“ [Farns03, S. 7]

Definition 4 Zentrale Eigenschaften des Trustee

Das Wort Trustee stammt aus dem Englischen und bedeutet übersetzt „Treuhänder“ oder „Verwalter“.

Dass der Trustee zu Recht als Softwareagent bezeichnet wird, zeigt sich daran, dass er die charakteristischen Agentenkriterien erfüllt. Im Folgenden sind nur die wichtigsten Kriterien aufgelistet. Diese folgen den Agentendefinitionen in [Ferbe01, S. 29], [RusNo03, S. 33] und [FraGr96].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2 Der Trustee als Softwareagent

Der Trustee verfolgt die drei Ziele Angebotseinholung, Verhandlungsführung und Tätigung von Vertragsabschlüssen für Kunden.

Bis zur SYSTEMS 2003 sollen folgende Teilz

- iele erreicht sein: zum einen soll der Trustee Angebote einholen und zum anderen die dadurch gewonnenen Ergebnisse klassifizieren und präsentieren können. Auch eine Erklärungskomponente für die Entscheidungen des Trustee soll bis dahin integriert sein.

Bisher gibt es ein Testszenario des Trustee, in dem das relativ komplexe Webformular des Fondsanbieters „SEB-Invest“, der individuelle Angebotsportfolios im WWW^[2] erstellt, verarbeitet wird. Die Modellierung anderer Anbieter ist noch in Arbeit.

Die Anzahl der Anbieter im Internet, die individuelle Kundeneigenschaften in ihre Angebote einbeziehen, ist momentan noch gering.

Anbieter, die Verhandlungen über ihre Produkte zulassen, sind nicht zu finden.

1.2 Problemfelder der Finanzberatung

Exemplarisch werden hier allgemeine Probleme der Finanzberatung aufgezeigt, wobei speziell auf die Beratung im Internet eingegangen wird. Im weiteren Verlauf der Arbeit wird demonstriert, wie sich diese Probleme mit dem Trustee umgehen lassen, und so eine Motivationsquelle für die Entwicklung des Trustee darstellen.

Als erstes Problem ist die fehlende Unabhängigkeit eines professionellen Beraters zu nennen. Er wird mit großer Wahrscheinlichkeit nicht neutral beraten, da er das Unwissen des Kunden und die Intransparenz des Marktes und der angebotenen Produkte zu seinen Gunsten ausnutzen kann. Dies ist für den Kunden meist nicht ersichtlich. Als Modell dafür dient die Principal-Agent-Theorie (vgl. [Picot01, S. 56-61]), in der ein Principal (Auftraggeber, Kunde) einen Agenten (Berater) mit der Wahrung seiner Interessen betraut. Der Agent wird jedoch aus Eigennutz neben den Zielen des Auftraggebers auch seine eigenen Ziele verfolgen. Aufgrund der asymmetrischen Informationsverteilung zwischen Principal und Agent ist dies für den Auftraggeber nur schwer zu durchschauen. Ein Berater wird also einem Kunden immer die Lösung anbieten, die sowohl dem Kunden als auch ihm am meisten entgegenkommt. Oft sind Berater für eine bestimmte Organisation tätig, z. B. für eine Bank oder ein Investmenthaus. Dadurch sind sie ebenfalls in ihrer Unabhängigkeit eingeschränkt, da sie primär am Verkauf der eigenen Produkten interessiert sind. Selbst so genannte „unabhängige“ Berater sind an ihrem Eigennutz interessiert und werden bevorzugt solche Produkte und Dienstleistungen anbieten und verkaufen, die für sie die höchste Provision einbringen.

Ein weiteres Defizit ist die in der Finanzberatung vorherrschende Intransparenz. Versicherungen und Fondsgesellschaften haben beispielsweise kein Interesse daran, ihre Produkte vergleichbar zu gestalten, was dazu führt, dass eine Vielzahl von Produktvarianten und Anlagemöglichkeiten zu den unterschiedlichsten Konditionen existiert. Für den Kunden sind die Vor- und Nachteile der einzelnen Angebote schon allein wegen ihrer Anzahl häufig nicht erkennbar. Hinzu kommt der Aufwand, der damit verbunden ist, Informationen über die einzelnen Angebote einzuholen und sie zu vergleichen. Dies schreckt viele Kunden von einem gründlichen Produktvergleich ab.

Neben den bisher genannten Problemen weist die elektronische Beratung noch einige besondere Schwachstellen auf. Dazu zählt u. a. die oft unpersönliche Präsentation der Beratung. Im Allgemeinen gehen die Internetangebote kaum auf die Lebenssituation oder auf Besonderheiten des Kunden ein. Wenige Internetanbieter machen sich die Mühe, Kundeninformationen in den Angebotsprozess mit einzubeziehen.

Da bei der elektronischen Beratung sensible Daten übermittelt werden, besteht die Gefahr der Datenausspähung durch Dritte, entweder bei der Übermittlung oder wenn Datenbestände beim Anbieter in die falschen Hände fallen.

Ist der Kunde selbst im Internet unterwegs, können seine Aktionen von den Webseiten, die er besucht, aufgezeichnet werden, um implizite Benutzerprofile zu erstellen. Techniken hierfür sind Cookies und die Protokollierung von IP-Adressen, um häufige Benutzer wieder erkennen und um ihre Vorlieben und Nutzungsgewohnheiten erfassen zu können. Beispielsweise arbeitet die bekannte Suchmaschine Google mit sehr langlebigen Cookies für ihre Benutzer (nach [Schrö03]). Auch das Internet-Handelshaus Amazon protokolliert die Einkäufe der Kunden mit, um per Collaborativ Filtering dem Kunden weitere, zu ihm passende Empfehlungen geben zu können (vgl. [LinSm03]). Dieser zunächst positiv anmutende Service birgt die Gefahr, dass der Kunde durch eine Zusammenführung der gesammelten Daten über ihn zum „gläsernen“ Konsumenten wird, oder er dank seines gespeicherten Profils nur noch in eine Richtung beraten wird, selbst wenn sich seine Interessen inzwischen geändert haben.

Eine weitere Gefahr im Internet stellt die unverlangte Zusendung von Werbe-E-Mails (Spam) dar. Eine Geheimhaltung der persönlichen Adressdaten ist somit sinnvoll, wofür der Trustee eine Hilfe sein kann.

1.3 Motivation des Trustee

Nach der Erläuterung der Problemfelder der konventionellen Finanzberatung, werden nun die Vorteile erläutert, die ein Trustee bei der Beratung und Vermittlung von Finanzdienstleistungen bietet.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3 Übersicht über Problemstellung und Lösungsansätze

Tabelle 3 zeigt eine Übersicht über die genannten Problemfelder und die Lösungsansätze des Trustee.

Ein großer Vorteil für den Kunden ist, dass der Trustee nicht eigennutzorientiert handelt und zunächst unabhängig von bestimmten Produkten oder Organisationen ist. Er hat keinen Anreiz, seinen eigenen Vorteil zu suchen, indem er Produkte mit hohen Provisionen zuerst anbietet. Er ist auch an keinen Anbieter gebunden. Des Weiteren ist der Trustee perfekt überwachbar, so dass die Probleme, die die Principal-Agent-Theorie beschreibt, keine Anwendung finden.

Ob der Vorteil der Unabhängigkeit direkt an den Endkunden weitergegeben wird, ist aber fraglich. Es ist genauso möglich, dass der Betreiber des Trustee, beispielsweise eine Bank oder eine Versicherung, ihn zum Vorteil der eigenen Organisation parametrisiert. Damit wäre der Vorteil der Unabhängigkeit nicht mehr gegeben.

Ein weiterer Vorteil des Trustee ist die verbesserte Schaffung von Transparenz am Markt gegenüber traditionellen Beratern. Erreicht werden soll dies durch einen umfassenden Marktüberblick. Diesen gewinnt das System dadurch, dass es Wissen über Anbieter besitzt, dass es ein Produktmodell der Anbieter hat und dass es zukünftig Wissen mit anderen Trustees austauscht. Ein Faktor, der zur Erhöhung der Markttransparenz beiträgt, ist die Arbeitsgeschwindigkeit des Trustee. Durch sie kann der Agent in der selben Zeit wesentlich mehr Angebote sichten als ein vergleichbarer menschlicher Berater.

Gegen die oft anonyme Präsentation bei Internetangeboten setzt der Trustee auf Situierung und Personalisierung der Angebote und der Verhandlung. Der Kunde soll die Möglichkeit haben, an seine Bedürfnisse angepasste Angebote zu erhalten. Die Erklärungskomponente des Trustee ist ein Teil davon, sie passt sich an den Wissensstand des Benutzers an und versorgt ihn mit den Informationen, die er benötigt.

Ein umfassendes Anonymisierungs- und Sicherheitskonzept soll die Gefahr der Datenausspähung und des Datenmissbrauchs so gering wie möglich halten. Ein weiterer Grundsatz ist die Datensparsamkeit, so dass nicht mehr Kundendaten an den Anbieter übermittelt werden als notwendig (siehe auch Abschnitt 3.4.2.2 auf Seite 50). Dies bedeutet, dass der bestmögliche Kompromiss zwischen der dem Anbieter übermittelten Datenmenge und der Güte des Angebotes anzustreben ist. Je besser die Datengrundlage über den Kunden ist, desto genauer kann das Angebot auf den Kunden maßgeschneidert werden. Im selben Maße steigt mit der Herausgabe von persönlichen Daten auch deren Missbrauchsrisiko.

Die implizite Erstellung eines Kundenprofils wird erschwert, da der Kunde für den Anbieter im Internet nicht persönlich in Erscheinung tritt, sondern der Trustee die Kundendaten verwaltet. Auch Cookies etc. bleiben beim Trustee.

Dies erscheint zunächst ein Nachteil für den Internetanbieter zu sein, verliert er so doch wertvolle Kundeninformationen und die Möglichkeit zur Kundendatenanalyse. Dies ist jedoch nicht der Fall, da die Webabfrage des Trustee nicht anonym geschieht – der Internetanbieter soll wissen, dass der Trustee für einen Kunden aktiv ist. Letztendlich ergibt sich eine Win/Win-Situation für Händler und Kunden. Der Trustee vermittelt dem Händler eventuell neue Kunden, und beim Kunden wächst aufgrund der Beratung und des Schutzes durch den Trustee die Akzeptanz gegenüber Webangeboten.

1.4 Aufbau der Arbeit

Diese Arbeit behandelt die Konzeption und teilweise Realisation eines Agenten zur Einholung von Angeboten für Finanzdienstleistungen aus dem Internet. Wichtige Arbeitsgebiete dieser Diplomarbeit sind die Darstellung der Agentenarchitektur sowie die Ausarbeitung von Konzepten für die Wissensrepräsentation und den Datenschutz für Kundendaten.

Nach einer Einführung in Kapitel 1 werden in Kapitel 2 die bisherigen Ansätze in beteiligten Gebieten betrachtet, die die Felder Personalisierung/Schutz der Privatsphäre und internetbasierte Softwareagenten umfassen. Zielsetzung dieses Kapitels ist es, die Arbeit relativ zum Forschungsstand auf diesen Gebieten einordnen zu können und zu zeigen, welche Lücke in der aktuellen Forschungslandschaft dadurch ausgefüllt wird.

Kapitel 3 trägt den Titel „Planung und Realisation eines Prototypen“ und ist thematisch in zwei große Bereiche aufgeteilt.

Der erste Bereich behandelt die Beschreibung der Schnittstellen zu den Projektbeteiligten (Kunde, Cluster-Partner, Wissensingenieur, Anbieter) und die Konzeption einer Architektur des Gesamtsystems. Daneben werden beispielhaft die Ablaufschritte einer Interaktion des Trustee mit einem Anbieter beschrieben.

Im zweiten Bereich werden die Arbeitsfelder Wissensrepräsentation und Datenschutz näher vorgestellt. Nach einer Einführung in die zur Wissensrepräsentation verwendete Beschreibungslogik wird demonstriert, wie dieser Formalismus für den Trustee verwendet werden kann. Im Teilbereich Datenschutz werden zu schützende Daten identifiziert und ein mögliches Sicherheitskonzept vorgestellt.

Kapitel 4 gibt einen Ausblick auf die zukünftigen Weiterentwicklungen des Systems, wobei im Besonderen auf die Möglichkeiten der Kommunikation zwischen Trustees eingegangen wird.

2. Bisherige Ansätze auf beteiligten Gebieten

Um den Trustee in der aktuellen Forschungs- und Entwicklungslandschaft einordnen zu können, wird in diesem Abschnitt auf Forschungsgebiete eingegangen, die thematisch die Aspekte des Trustee tangieren.

Da der Trustee als Projekt am Anfang seiner Entwicklung steht, ist noch nicht ganz überschaubar, welche Themenstellungen in der Zukunft bei der Weiterentwicklung im Raum stehen werden. Des Weiteren umfasst die Durchführung dieses Projektes eine so große Anzahl von Themen, angefangen von den technischen über die rechtlichen bis hin zu den wirtschaftlichen Aspekten eines solchen Systems, dass der gegenwärtige Forschungsstand auf allen diesen Gebieten nicht in dieser Arbeit abgehandelt werden kann.

Im Folgenden beschränken sich die Ausführungen auf die Themenkomplexe Privatsphäre und Personalisierung sowie das Gebiet internetbasierter Agentensysteme, da dies zwei zentrale Schwerpunkte des bisherigen Projektverlaufs und der vorliegenden Arbeit sind. Besonderes Augenmerk wird dabei auf den Vergleich des Trustee mit bereits existierenden, in ihrer Funktionalität ähnlichen Systemen gelegt.

2.1 Personalisierung und Privatsphäre

Wie bereits definiert, ist die Personalisierung die Modellierung der Persönlichkeit des Menschen. Das dabei entstehende Modell wird vom Rechner zur verbesserten Interaktion mit dem Menschen benutzt. Um ein solches Modell bilden zu können, benötigt das dahinter stehende System möglichst viele Daten der zu modellierenden Person. Zur Datengewinnung gibt es zwei Möglichkeiten: entweder werden die Daten explizit von der Person erhoben oder es erfolgt eine implizite Ermittlung der Daten.

Auf die Techniken der impliziten Datenermittlung, die auch unter dem Stichwort „Benutzermodellierung“ firmieren, und zu denen beispielsweise Collaborative Filtering, Profiling oder Data Mining gehören, wird in dieser Arbeit nicht weiter eingegangen, da der Trustee nicht mit diesen Techniken arbeitet. Es gibt jedoch umfangreiche Forschungsaktivität auf diesem Gebiet, wie [Bauer01] oder [CACM00] dokumentieren.

Da es sich das FORSIP zur Aufgabe gemacht hat, den Kunden individuell zu beraten und bei Internetgeschäften zu vertreten, benötigt es akkurate Daten und ist daher auf die explizite Erfassung der Daten einer Person, d.h. des Kunden, angewiesen. Dadurch ergibt sich das Problem der Verwendung und des Schutzes dieser Daten im Umgang mit Anbietern von Finanzprodukten aus dem Internet.

Dieser Datenschutz ist unumgänglich zur Aufrechterhaltung der Privatsphäre der Kunden. Als Privatsphäre unter Datenschutzaspekten soll hier die Wahrung der informationellen Selbstbestimmung des Kunden verstanden werden, d.h. der Kunde bestimmt, welche Daten er an wen weitergeben möchte. Dies dient zur Aufrechterhaltung der Anonymität des Kunden und somit zu seinem Schutz vor Ausspionierung und Profilbildung.

Dass die Privatsphäre der Kunden, die sich vom Trustee beraten lassen, sehr wichtig für sie ist, belegen die Ergebnisse einer Umfrage unter Benutzern des WWW, die vom Georgia Institute of Technology Ende 1998 durchgeführt worden ist. In einem Teil der Untersuchung wurden den Teilnehmern Fragen nach ihrer Einstellung zur Onlinesicherheit und ihrer Privatsphäre im Internet gestellt. An diesem Teil der Umfrage haben fast 1500 Personen teilgenommen.

Als Zusammenfassung der Ergebnisse dieser Teilumfrage lässt sich ein starker Kundenwunsch nach Wahrung der Privatsphäre im Internet ableiten. Dies belegt beispielsweise die Tatsache, dass zwei Drittel der Befragten die Anonymität des Internets sehr zu schätzen wissen. Darüber hinaus sind über 70 Prozent der Teilnehmer entschieden dafür, dass der Benutzer die vollständige Kontrolle über seine demographischen Daten behalten solle. Wenn Internetbenutzer die Wahl hätten zwischen Bequemlichkeit und ihrer Privatsphäre, würden über drei Viertel der Teilnehmer die Wahrung ihrer Privatsphäre vorziehen. (Alle Informationen und genaue Datensätze dazu sind unter [GTRC03] abrufbar.) Auf Seiten der Internetnutzer kann also ein großes Interesse an der Wahrung der Privatsphäre vermutet werden. Demgegenüber stellt sich die Frage, welche Konzepte die Forschung entwickelt hat, damit diese Nachfrage nach Privatheit auch Realität werden kann.

[Grimm00, S. 133] erwähnt einen Widerspruch, der für die weiteren Betrachtungen wichtig ist: E-Commerce und Datensparsamkeit haben konträre Ziele. “E-Commerce verlangt nach Kundenbindung und diese nach ausführlicher Kenntnis von Kundendaten. E-Privacy dagegen verlangt nach Datensparsamkeit.“ [Grimm00, S. 133]

Bei den weiteren Überlegungen geht es also nicht darum, völlige Anonymität erreichen zu wollen, sondern trotz Datensparsamkeit E-Commerce möglich zu machen. Da es sich im Kern der Sache um Datensparsamkeit und informationelle Selbstbestimmung handelt, werden hier keine Ansätze der Sicherung des Übertragungsmediums vorgestellt. Zweifellos schützen diese auch die Privatsphäre, jedoch auf einer für die folgenden Betrachtungen zu niedrigen Ebene.

Im Folgenden werden einige Ansätze des aktuellen Forschungsstandes zu den bisher genannten Gebieten dargelegt. Bei der Auswahl wurde darauf geachtet, dass die Ansätze Ähnlichkeit mit der Aufgabenstellung des Trustee im Bereich Datenschutz haben.

Als eine mögliche Technik zum Schutz der eigenen Daten im Internet wurde der P3P^[3] -Standard geschaffen. Seine genaue Definition ist bei [Marc03] zu finden.

[BaFra03] und [Marc03] geben eine gute Übersicht der Leitprinzipien von P3P:

„ 1. Benachrichtigung und Kommunikation
Ein Anbieter, der Daten über einen Nutzer sammeln möchte, soll diesem gegenüber eindeutig - sowohl maschinenlesbar als auch in Klartext – bekannt geben, welche Daten er zu welchem Zweck erhebt, wie er mit ihnen weiter verfährt u. a. Aufseiten des Benutzers sind Werkzeuge zu realisieren, die es ihm ermöglichen, unkompliziert die Anfrage eines Dienstes zu beantworten.
2. Wahlmöglichkeit und Kontrolle
Der Anwender soll stets bestimmen können, welchem Dienst er für welche Aufgaben welche Informationen zur Verfügung stellt. Auch im Nachhinein muss die Freigabe von Daten einsehbar und widerrufbar sein. Dazu stellt die Client-Software Funktionen bereit, die darüber hinaus sicherstellen, dass ein Zugriff auf persönliche Informationen erst nach einer wissentlichen Zustimmung (informed consent) des Kunden möglich ist.
3. Fairness und Integrität
Ein Diensteanbieter sollte nur diejenigen Daten vom Anwender abrufen, die er zur Durchführung der jeweiligen Aufgaben auch unbedingt benötigt. Außerdem hat er sich streng an die in der Benachrichtigung des Nutzers getroffenen Aussagen bezüglich Datenverwendung etc. zu halten.
4. Sicherheit

P3P stellt definiert zwar selbst keine Sicherheitsmechanismen, wie Verschlüsselung o. Ä., empfiehlt aber dringend deren Nutzung bei der Durchführung von P3P-Aktionen und stellt Schnittstellen zu Kryptographie-Werkzeugen zur Verfügung.“ [BaFra03, S. 3-4]

Im Rahmen von P3P wurde ein Standard geschaffen, der es erlaubt, automatisiert die Präferenzen und Daten des Kunden zu verwalten. Diese Sprachergänzung zu P3P wird mit APPEL^[4] bezeichnet und ist unter [Langh00] als W3C-Standard definiert. Zu dieser Sprache gehört, dass ein Agent, der APPEL benutzt, sich bei der Anbieterseite informieren kann, welche Datenschutzrichtlinien diese hat, wie der Anbieter die Verwendung der Kundendaten plant und welche Daten vom Anbieter verlangt werden. Anhand vom Kunden vordefinierter Regeln kann der Agent nun entscheiden, welche Daten für welchen Zweck an den Händler weitergeleitet werden.

Die Ansätze, die P3P repräsentiert, klingen viel versprechend, jedoch sollten folgenden Kritikpunkte an P3P in die Betrachtung mit einbezogen werden:

- Der Standard hat sich bisher kaum durchgesetzt. Es existieren kaum P3P-fähige Internetseiten und P3P-fähige Internetsoftware. Erst die neueste Generation von Browsern, namentlich Netscape 7.0 und der Internet Explorer 6.0, sind mit einer Unterstützung für das Protokoll ausgerüstet. Von einer Massenanwendung kann daher noch nicht gesprochen werden.
- Wie in [BaFra03, S. 13] unter Bezug auf [Catl03] erwähnt ist, kommt die Definition des Standards langsam voran, teilweise bedingt durch die Teilnahme vieler Interessengruppen an seiner Entwicklung.

Ausgehend vom P3P-Standard haben sich einige Forschungsprojekte gebildet, die diesen Standard als Grundlage ihrer Arbeiten haben. Dazu gehören das Shopping Gate von IBM, das Projekt OPA^[5] ebenfalls von IBM und das Projekt DASIT^[6].

Das Shopping Gate der IBM Corp., welches in [StStr01] beschrieben wird und P3P verwendet, hat zum Ziel, dem Kunden die Chance zu geben, gegenüber Händlern im Internet in verschiedenen „Skins“, d.h. Masken, aufzutreten. Realisiert werden diese Masken durch die Benutzung von Rollenmodellen durch den Benutzer. Ein Rollenmodell enthält eine Transaktionshistorie, ein einfaches Kundenmodell, ein Modell, das Eigenschaften von gewünschten Produkten abbildet und Bewertungskriterien für Produkteigenschaften. Ein Kunde kann sein Rollenmodell je nach Einkaufszweck wechseln, dem Internetladen werden nur die Informationen des jeweils aktuellen Rollenmodells übermittelt. Allerdings müssen die besuchten Internethändler die Spezifikationen des Shopping Gates unterstützen, was seine Verbreitung einschränken dürfte.

[Meyer03] stellt einen Ansatz vor, wie persönliche Daten im Web verwaltet und übertragen werden können, und wie man über sie verhandeln kann. Dazu entwickelte er eine Implementation der Standards P3P und APPEL und erweiterte sie um ein Verhandlungsmodul. Die technologische Basis ist der WBI^[7], ein programmierbarer HTTP-Proxy, der von IBM entwickelt wurde. Das resultierende System trägt den Namen OPA. „Der OPA vereinfacht Webtransaktionen und bietet Nutzern die nötigen Hilfen zur Verwaltung, Verhandlung und zum Transfer von persönlichen Daten im Web“[Meyer03, Seite i]. Dieses Projekt ist als interessante Technologiedemonstration zu werten, jedoch scheint der OPA nur ein Forschungsprojekt zu bleiben.

Das Projekt DASIT hat zum Ziel, „E-Commerce-Anwendungen durch E-Privacy-Mechanismen und –Policies zu erweitern und zu demonstrieren, dass dadurch sowohl das Geschäft verbessert als auch informationelle Selbstbestimmung gewahrt wird. Das wird beispielhaft für das Internet-Zahlungssystem SET implementiert und in einer Shoppingmallumgebung eingesetzt und erprobt.“ [Grimm00, S. 134] Im Folgenden werden Forschungsergebnisse präsentiert, die nicht direkt oder indirekt auf P3P beruhen.

Ein Forschungsansatz zum Thema Datenschutz wird in [Korba03] vorgestellt. Dieser hat den Vorteil, weit über die Schutzanliegen von P3P hinauszugehen, und sieht eine Verkettung der Datenschutzrichtlinien der Parteien mit Datenschutzgesetzen und Firmendatenschutzrichtlinien vor. Auch bezieht er die Verhandlung von Datenschutzrichtlinien und die Authentifizierung und Autorisation von Benutzern mit ein. Über das Stadium eines Forschungsberichtes ist dieser Vorschlag nicht hinausgekommen. Des Weiteren fehlen Vorschläge zur konkreten Implementierung der Ergebnisse.

Ein ähnliches Konzept wie das oben vorgestellte „Shopping Gate“ besitzt der „IntelliShopper“ [Mencz03]. Dieser Shoppingassistent lernt die Vorlieben des Kunden aus der Beobachtung seiner Einkäufe und weist den Kunden auf Internetseiten hin, die dessen Bedürfnissen entsprechen könnten. Darüber hinaus schützt dieser Agent die persönlichen Informationen des Kunden durch die Verwendung von Pseudonymen und anonymisierten IP-Adressen. In den Punkten Personalisierung und Schutz der Privatsphäre erreicht der „IntelliShopper“ unter allen vorgestellten Projekten am ehesten die zukünftige Funktionalität des Trustee.

Unter dem Stichwort Identitätsmanagement lässt sich ein weiterer interessanter Ansatz zusammenfassen. Dabei geht es um Techniken, die den Benutzer „in die Lage versetzen, persönliche Merkmale nur gezielt und bewusst weiterzugeben“ [FeBer00, S. 189]. Als Techniken werden dazu Pseudonyme eingesetzt, die dazu verwendet werden können, die Verkettbarkeit der Spuren des Benutzers zu verhindern. Um trotz eines Pseudonyms persönliche Eigenschaften nachweisen zu können, werden signierte Pseudonyme als Lösung vorgestellt. Das Ziel der Verfahren ist eher in der Wahrung der Anonymität zu sehen.

2.2 Internetbasierte Softwareagenten

Da das Thema Softwareagenten einen weiten Forschungsbereich darstellt, erfolgt hier zunächst eine Abgrenzung, auf welchen Gebieten der Stand der Technik präsentiert wird. Grundsätzlich beschränkt sich die Darstellung des Forschungsstandes auf Forschungsprojekte, die eine möglichst hohe Ähnlichkeit mit den Arbeitsschwerpunkten des Trustee haben. Daher erfolgt eine Konzentration der Darstellung auf Systeme des Finanz- und E-Commerce-Bereichs, da diese das momentan angestrebte Arbeitsfeld des Trustee sind. Ausgeklammert werden an dieser Stelle Darstellungen der Forschung an agentenbasierten elektronischen Verhandlungen (siehe dazu [DigSi01]), da dies bestenfalls ein Fernziel des Trustee darstellt, aber nichts mit dem aktuellen Entwicklungsstand des Trustee (Angebotseinholung) zu tun hat. Ebenfalls vernachlässigt werden Betrachtungen des Fortschritts der Multiagentensystemforschung (siehe dazu [Ferbe01]), mit der Begründung, dass das Zusammenspiel mehrerer Trustees ein Problem ist, welches nicht in den Rahmen dieser Diplomarbeit fällt. Eine weitere Dimension der Agentenforschung, nämlich mobile Agenten, treffen nicht den Arbeitsbereich des Trustee, da er bisher als stationäres System konzipiert ist.

Zur Klassifikation der vorzustellenden Anwendungen wird eine Systematik verwendet, die der Darstellung in [Brenn98, S. 223] folgt. Dort werden Agentensysteme nach ihren Aufgabenschwerpunkten eingeteilt, so dass drei Kategorien entstehen: Informationsagenten, Kooperationsagenten und Transaktionsagenten. Jedoch ist diese Abgrenzung nicht ganz trennscharf, da sich bei jeder Agentenart auch Merkmale der anderen Kategorien wieder finden lassen.

Informationsagenten helfen dem Benutzer bei der Suche, Filterung, Bewertung und Bereitstellung von Informationen. Transaktionsagenten überwachen Transaktionen und führen sie aus, wobei im Folgenden hauptsächlich von finanziellen Transaktionen (Kauf und Verkauf von Produkten) die Rede ist. Kooperationsagenten lösen komplexe Problemstellungen, indem sie mit anderen Teilnehmern kooperieren (nach [Brenn98, S. 223-224]). Auf diesen Agententyp wird hier nicht weiter eingegangen.

Im Folgenden werden die aktuellen Entwicklungen der Agententechnik hauptsächlich an konkret verfügbaren Systemen demonstriert, die entweder im Labor oder im Internet im Einsatz sind oder waren.

[Monde03] führt in seiner Arbeit eine Untersuchung der Fähigkeiten von Agenten durch, die im Bereich der Finanzwirtschaft tätig sind. Dabei betrachtet er eine Reihe von Agenten, die den Benutzer bei Geschäften an der Börse unterstützen. Als Dienste bieten diese Agenten die unternehmens- oder aktienspezifische Informationssuche, -filterung, -sammlung und –aufbereitung sowie oft eine einfache Verwaltung von Depots an [Zacko03, S. 5]. In seiner Zusammenfassung identifiziert er einige dieser Agenten als bloße Suchmaschinen. Agenten im Sinne der wissenschaftlichen Definition kommen nicht vor. Nach dem Schwerpunkt ihres Aufgabengebietes handelt es sich im Wesentlichen bei allen Agenten um Informationsagenten.

Als einzige Ausnahme wird der auf der Multiagentenstruktur RETSINA^[8] basierende WARREN dargestellt, der neben Informationsdiensten auch die Prognose von Aktienkursen anbietet. [Monde03, S.23]

In der Klasse der Transaktionsagenten werden im Folgenden nur solche Agenten betrachtet, die im E-Commerce tätig sind.

Diese Agenten werden als Kaufagenten bezeichnet und lassen sich nach [Brenn98, S. 310] in einfache Kaufagenten, komplexe Kaufagenten und agentenbasierte Marktplätze gliedern. Für alle hier untersuchten Kaufagenten gilt, dass sie bisher nur einfache Produkte wie CDs, Bücher oder Konzertkarten verarbeiten können, da deren Eigenschaften bis auf den Preis komplett festgelegt sind. Verhandlungsfähige Agenten existieren, außer bei den Marktplatz-Ansätzen, nicht.

Einfache Kaufagenten unterstützen den Kunden bei der Suche, liefern eine Produktübersicht der gefunden Gegenstände und lassen nur feste Kategorien für Produkte zu. Ihre Funktionalität beschränkt sich auf den Preisvergleich der gefundenen Produkte wie bei traditionellen Preisagenturen. Es erfolgt keine Unterstützung der eigentlichen Kaufhandlung. Als Beispiel sei hier der „Bargainfinder“[Aoun03] als einer der ersten Vertreter von Kaufagenten [Maerz03, S. 14] angeführt. Dieser ist nicht mehr im Internet zu finden, da viele Online-Shops ihren Laden für den Agenten gesperrt haben. Ein weiteres Beispiel ist „Fido“, der eine ähnliche Funktionalität wie „Bargainfinder“ besitzt. Dieser ist ebenfalls nicht mehr verwendbar, da er nicht mehr gepflegt wird. Unter http://www.agentland.com/ finden sich eine Reihe neuerer Kaufagenten, jedoch bieten sie dieselben Funktionalitäten wie die oben beschriebenen einfachen Kaufagenten.

Ein besonders interessantes Exemplar eines einfachen Kaufagenten wird in [Doore97] beschrieben. Der als „Shopbot“ bezeichnete Agent ist in der Lage, selbständig Online-Shops nach günstigen Angeboten für Software oder CDs abzusuchen und dem Benutzer eine nach dem Preis sortierte Übersicht der Angebote zu präsentieren. Das Besondere an ihm ist seine Fähigkeit, selbständig lernen zu können, wie er bei neuen Händlern einkaufen kann. Dazu verlässt er sich auf eine Reihe von Heuristiken über den Aufbau des abzufragenden Online-Shops und bedient sich induktiver Lernverfahren um sein Wissen zu erweitern. Im Rahmen des „Verstehens“ einer Anbieterseite kreiert er seine eigen Seitenbeschreibung. Allerdings ist dieser Agent auf bestimmte strukturelle, wiederkehrende Ähnlichkeiten der Anbieterseiten angewiesen und es ist zweifelhaft, ob er mit der gestiegenen Komplexität der Internetauftritte heutiger Online-Shops zurecht kommen würde.

Im Gegensatz zu einfachen Kaufagenten unterstützen komplexe Kaufagenten auch den Kaufvorgang. Als Beispiel sei „Jango“ [Brenn98, S. 320] genannt, der neben der Informationsbeschaffung und dem Produktvergleich auch ein Ranking der Produkte und den Verkauf und die Bezahlung der Waren unterstützte. Sein Hersteller wurde im Zuge der Dot.Com-Euphorie von den Betreibern der Suchmaschine Excite^[9] aufgekauft und seitdem ist der Agent im Internet nicht mehr auffindbar.

Ein ähnliches Schicksal musste auch der komplexe Kaufagent DealPilot [Maerz03, S. 14] erleiden. Dieser Agent wurde von Bertelsmann 1999 aufgekauft und ist ebenfalls nicht mehr auffindbar. Zu seinem Verschwinden könnte das gewagte Geschäftsmodell der Betreiber beigetragen haben. Es umfasste zum ersten Mal Provisionszahlungen der Online-Shops an den Dealpilot bei erfolgreicher Vermittlung eines Kunden. Der DealPilot ist somit vermutlich Opfer der Dot.Com-Krise der letzten Jahre geworden.

Als vermutliche Zukunft des Kaufagenten wird an dieser Stelle der agentenbasierte Marktplatz Kasbah [Brenn98, S. 328] vorgestellt. Dieses Multiagentensystem wurde am MIT^[10] entwickelt und simuliert autonom handelnde Einkaufs- und Verkaufsagenten, die Verhandlungen für den Benutzer führen. Jeder Benutzer kann für ihn handelnde Agenten kreieren, ein Produkt und eine Verhandlungsstrategie festlegen und sie dann mit anderen Agenten in Transaktion treten lassen. Am Ende erhält der Benutzer die Angebote, die am Marktplatz ausgehandelt worden sind.

Im Rahmen des Bankmanagements untersuchte [Fuge03] die mögliche Entstehung virtueller Finanzintermediationssysteme, ausgelöst durch die Weiterentwicklung der Informations- und Kommunikationstechnologie. Softwareagenten werden von ihm als viel versprechende Basistechnik eingeordnet. „Mit weiterer Verbesserung der Agententechnologie ist zu einem späteren Zeitpunkt auch eine weitere Desintermediation des Aggregators möglich, so dass autonome agentengestützte Marktteilnehmer existieren“[Fuge03, S. 24]. Als Aggregatoren sind hier vornehmlich Finanzdienstleister gemeint, die Produkte und Dienstleistungen zukaufen und als Paket, also aggregiert, weiter vertreiben (MLP ist ein typisches Beispiel dafür). Der Autor vertritt hier die These, dass die Agententechnologie der Zukunft diese Zwischenhändler beseitigen könnte.

„Ungeachtet dieser Entwicklungen werden auch ‚klassische’ Finanzintermediäre aller Wahrscheinlichkeit nach auch in der Zukunft existieren – jedoch mit einem anderen Leistungsspektrum und verändertem Selbstverständnis. Transformationsfunktionen werden eher den virtuellen Systemen übertragen werden, da diese sie effizienter und kostengünstiger ausführen können. Was (für klassische Banken) bleibt, ist die Frage der Übernahme systematischer Risiken, die spezialisierte Produktion sowie die individuelle Beratungsdienstleistung“ [Fuge03, S. 25]. Die Möglichkeit, dass Softwareagenten individuelle Beratungsdienstleistungen erbringen, wird vom Autor offensichtlich nicht gesehen.

2.3 Zusammenfassung

Folgende Beobachtungen lassen sich bei der Analyse des Technikstandes machen:

- Internetbenutzer, insbesondere Teilnehmer am E-Commerce, sind sehr am Schutz ihrer Privatsphäre und an der Sicherheit ihrer Daten interessiert.
- Mögliche technische Standards zum Datenschutz sind noch nicht sehr verbreitet und nicht umfassend genug (vgl. Entwicklung von P3P), oder stellen hohe organisatorische Hürden dar (vgl. Signaturansätze).
- Intelligente Agenten sind im Internet bisher Mangelware, einfache Kaufagenten dominieren.
- Es besteht eine Lücke zwischen dem Stand der Forschung auf dem Gebiet intelligenter Agenten und der bisherigen Umsetzung dieses Wissensstandes in momentan im Internet verwendete Agenten.

Aus diesen Punkten folgt eine weitere Motivation für die Entwicklung des Trustee. Er besitzt die Fähigkeiten eines komplexen Kaufagenten, sorgt aber auch für die Anonymität der Kundendaten und die Personalisierung der Kundenschnittstelle. Diese Kombination von Fähigkeiten ist beim aktuellen Stand der Technik nicht zu finden.

3. Planung und Realisierung eines Prototypen

3.1 Arbeitsfelder der Trustee-Entwicklung

Das FORSIP hat sich zum Ziel gesetzt, auf der Computermesse SYSTEMS 2003 in München einen funktionierenden Prototypen vorzustellen. Um die dazu notwendigen Entwicklungsaufgaben des Trustee überblicken zu können, erfolgt in den nächsten Absätzen die Darstellung der Arbeitsfelder, die für einen lauffähigen Prototypen bewältigt werden müssen.

Ein wichtiger Bereich des Trustee ist die Modellierung und Einbindung des Branchenwissens in das System, wobei auf die Deklarativität der Wissensrepräsentationsform zu achten ist. Zum Branchenwissen gehören Anbieterseiten, die Angebote bereitstellen, und Übersichtsseiten, auf denen schon verdichtete Informationen wie Anbieterrankings oder Marktübersichten zu finden sind. Das Branchenwissen wird im Rahmen des Clusters in einer Ontologie der Finanzdienstleistungsbranche abgebildet, die zur einheitlichen Kommunikation im Cluster dient. Für diese Ontologie muss geklärt werden, inwieweit der Trustee sie als Wissensbasis nutzen kann und wie das Inferenzverhalten und die Inferenznutzung des Trustee gestaltet werden soll.

Eine weitere Aufgabe des Trustee ist die Präsentation der Suchergebnisse nach der erfolgten Angebotseinholung. Um diese Präsentation individuell auf den Kunden anpassen zu können, ist ein Vergleich der gefundenen Angebote mit den Ansprüchen des Kunden zu berechnen. Die gefundenen, besonders passenden Angebote können dann in einer Art „Hitliste“ hervorgehoben werden.

Zur Errechnung der passenden Angebote werden drei unterschiedliche Funktionen verwendet: eine Zielfunktion, eine Bewertungsfunktion und eine Rankingfunktion. Die Ausgestaltung dieser Funktionen wird im Folgenden beschrieben.

Die Zielfunktion bildet die wirtschaftlichen und persönlichen Präferenzen des Kunden ab. Um die persönlichen Präferenzen zu ermitteln, können die Daten aus dem Kundenmodell benutzt werden, im Besonderen die Kundeneinstellungen, die in Tabelle 7 auf Seite 49 aufgelistet sind. Die wirtschaftlichen Präferenzen betreffen quantitative Angebotseigenschaften wie beispielsweise die Laufzeit der Geldanlage.

Um zu bewerten, ob ein Angebot den persönlichen Präferenzen des Kunden entspricht, wird die Bewertungsfunktion herangezogen. Diese definiert zu den Kundeneinstellungen analoge einstellungsorientierte Produkteigenschaften. Als Beispiel kann die Kundeneinstellung Risikobereitschaft dienen. Für diese Kundeneinstellung wird die dazu analoge einstellungsorientierte Produkteigenschaft Risikoträchtigkeit definiert, die das Anlagerisiko quantifiziert. In der Bewertungsfunktion wird zu jeder Kundeneinstellung der Wert der entsprechenden einstellungsorientierten Produkteigenschaft ermittelt, so dass ein Vergleich zwischen den Kundeneinstellungen und den einstellungsorientierten Produkteigenschaften möglich ist.

Bei der Bewertungserstellung der einzelnen einstellungsorientierten Produkteigenschaften ist eine Integration von Branchenwissen aus der Finanzdienstleistungsbranche gut vorstellbar, schließlich sollte der Trustee wissen, ob beispielsweise ein bestimmter Zinssatz im Vergleich mit der Branche als hoch oder niedrig einzustufen ist, oder welche Informationen es zur Bonität einer Versicherungsfirma gibt, da sich deren Bonität auf die Verlässlichkeit und das Verlustrisiko ihrer Angebote auswirkt.

Die Rankingfunktion übernimmt die Ergebnisse der Zielfunktion und der Bewertungsfunktion und stellt danach eine Reihenfolge der Angebote auf.

Nach der Suche der personalisierten Finanzdienstleistungen, soll der Trustee diese auch personalisiert präsentieren können. Dazu gehört u. a. eine Erklärungskomponente, die dem Kunden erläutert, wie die Reihenfolge der Angebotsempfehlung zustande kommt. Falls beim Kunden Unklarheiten bezüglich der Terminologie der Finanzbranche bestehen, soll das Hilfssystem Texte präsentieren, die auf das Wissensniveau des Kunden und auf die Komplexität der angebotenen Produkte zugeschnitten sind.

Vor allem die Architektur des Trustee, die Verwendung der Ontologie, die Behandlung des Branchenwissen, die Anonymisierung von Kundendaten und der Datenschutz sind Schwerpunkte der bisherigen Entwicklung und dieser Diplomarbeit. Sie werden in den folgenden Abschnitten ausführlich dargestellt und es werden Konzepte und die schon geleistete Implementierung auf diesen Feldern präsentiert.

3.2 Schnittstellen zu den Clusterprojekten

3.2.1 Übersicht

Abbildung 1 weiter unten gibt einen schematischen Überblick über die Dienste, die die anderen Teilprojekte des Clusters anbieten, wie sie vom Trustee genutzt werden und welche Protokolle und Formate zum Datenaustausch benutzt werden.

SIPKIS stellt zwei Dienste für den Trustee zur Verfügung, die aus der Abfrage der Kundendaten und der Übermittlung des errechneten Produktportfolios und der vorhandenen Produktkategorien bestehen.

SIPREACT bietet ebenfalls zwei Dienste an, wovon einer zum Abruf von situations- und nutzerbezogenen Hilfsdokumenten dient. Dazu verwendet er von SIPKIS und vom Trustee-Projekt bereitgestellte Informationsdokumente als Datengrundlage. Der andere Dienst ist für die Kundenrückfrage von noch nicht vorhandenen Nutzerdaten konzipiert. Dieser Fall kann auftreten, wenn ein Anbieter Informationen von einem Kunden benötigt, die nicht im Kundenmodell verzeichnet sind. Die Kundendaten werden in einer zentralen Datenbank gehalten, auf die beide Teilprojekte SIPKIS und SIPREACT zugreifen werden.

Das Projekt SIPRUM ist nicht durch Schnittstellen mit dem Trustee verbunden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Übersicht der Projekte

3.2.2 SIPKIS

In Tabelle 4 ist eine Übersicht der von SIPKIS angebotenen Dienste, deren Formate und deren Protokolle dargestellt.

Abbildung in dieser Leseprobe nicht enthalten^[11]

Tabelle 4 Schnittstellen SIPKIS

Die Produktkategorien für die SYSTEMS 2003 sind Sparpläne, Kapitallebensversicherungen, Aktienfonds und Rentenfonds. Nach der SYSTEMS wird die Zahl der Kategorien noch erweitert werden.

Das Kundenmodell wird mittels des OASIS^[12] -Standards xCIL^[13] übertragen, der eine applikationsübergreifende Struktur für Kundeninformationen bereitstellt. Genauere Erklärungen zum Übertragungsprotokoll SOAP sind in Abschnitt 3.3.2.2 auf Seite 24 zu finden. Dieser Service liegt schon in einer nutzbaren Implementierung vor.

Für den Austausch des Produktmodells wird nach der aktuellen Planung ein WebService verwendet werden, über den ein BMEcat-Dokument ausgetauscht wird, das das gesuchte Produktportfolio spezifiziert. Diese Schnittstelle befindet sich noch in der Entwicklung, daher stehen die technischen Details der Schnittstelle noch nicht vollkommen fest (Stand Mai 2003).

3.2.3 SIPREACT

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5 Schnittstellen SIPREACT

Dies sind die geplanten Schnittstellen zum Projekt SIPREACT. Der Stand der Umsetzung ist noch nicht soweit fortgeschritten wie die Schnittstellen zum Projekt SIPKIS. Eine konkrete Implementierungen wurde noch nicht vorgenommen.

Der Dienst „Personalisierte Dokumente“

soll technisch als HTML-Link, der auf eine bestimmte URL bei SIPREACT verweist, realisiert werden. An diese URL werden zwei Parameter übertragen, die spezifizieren, auf welchen Benutzer das auszuliefernde Dokument personalisiert werden soll.

Die Schnittstelle zur Interviewkomponente in SIPREACT ist ähnlich der Schnittstelle zum Abruf des Kundenmodells in SIPKIS realisiert.

3.3 Konzepte und Architektur des Prototypen

3.3.1 Übersicht der Architektur

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Die logische Architektur des Trustee

In Abbildung 2 ist die logische Architektur des Trustee dargestellt. Im Wesentlichen sind an der Entwicklungsphase des Trustee vier Gruppen beteiligt. Es handelt sich dabei um die Kunden, die eine fundierte Beratung und eine erfolgreiche Angebotseinholung vom Trustee erwarten. Die Anbieter ihrerseits stellen Angebote ins Internet in Form von HTML-Seiten, auf denen sie sich und ihre Leistungen präsentieren, und die vom Trustee ausgewertet werden. Die Cluster-Partner des Trustee sind die Teilprojekte, die am selben Cluster beteiligt sind, und die Daten und Services bereitstellen für den Trustee (siehe Abschnitt 3.2). Wissensingenieure modellieren das Branchenwissen in Form einer Ontologie und das Wissen über die Anbieter in Form von Modellen der Anbieterseiten für den Trustee. Daneben gibt es den Trustee selbst, der in fünf Bereiche gegliedert ist. Diese Bereiche entsprechen Programmmodulen, die die Kommunikation mit den jeweiligen Gruppen übernehmen. Der Trustee-Kern stellt das Verbindungsglied zwischen all diesen Kommunikationsmodulen dar.

Die in der Zeichnung verwendeten Pfeile stellen die Kommunikationsbeziehungen zwischen der jeweiligen Gruppe und dem Trustee dar.

Im Folgenden werden die einzelnen Kommunikationskomponenten des Trustee näher vorgestellt.

3.3.2 Die Kommunikationskomponenten des Trustee

3.3.2.1 Kommunikation mit den Kunden

Das hier beschriebene Modul bildet die Kundenschnittstelle des Trustee. Wie schon beschrieben stellen die Partnerprojekte im Cluster Services zur Verfügung, die die Kommunikation mit dem Kunden abwickeln. So erhebt SIPKIS die Kundendaten und leistet auch deren Pflege. Trustee kann sie über die Schnittstelle zu SIPKIS direkt übernehmen. Ein weiterer potentieller Berührungspunkt mit dem Kunden sind mögliche Nachfragen, die geschehen können, wenn notwendige Kundendaten nicht vorhanden sind, weil sie der Kunde bei der Aufnahme ins System nicht angegeben hat. Auch erfolgt eine Nachfrage, falls ein Datum zu anonymisieren ist, und der Kunde entscheiden muss, wie dies geschehen soll und welcher Wert statt des wahren Wertes zu verwenden ist. Alle diese Nachfragen sollen von Diensten des Teilprojekts SIPREACT übernommen werden. Die Nachfragen des Kunden beim System, beispielsweise nach der Bedeutung eines bestimmten Ablaufschrittes von Trustee, werden über spezialisierte, personalisierte Informationsdokumente abgedeckt, die von SIPREACT auf Anfrage präsentiert werden.

Die hier beschriebene Zusammenarbeit mit den Cluster-Partnern SIPKIS und SIPREACT befreit den Trustee weitgehend von der direkten Interaktion mit dem Kunden. Dies gilt jedoch ausdrücklich nicht, wenn der Trustee als eigenständiges System (Stand-Alone) betrieben wird, da der Trustee dort die oben beschriebenen Funktionen vollständig selbst übernimmt.

Der Teil der Kundenschnittstelle, der vom Trustee unabhängig von seiner Einsatzart selbst übernommen wird, ist die Präsentation der Ergebnisse, d. h. die Angebote, die durch die Abfrage der Anbieter ermittelt werden. Der Trustee soll dabei Erklärungen über das vorgenommene Ranking der gefundenen Treffer abgeben können, da der Kunde erkennen können muss, wieso der Trustee die Auswahl und Aufstellung der Ergebnisse getroffen hat.

Sinnvoll wären auch verschiedene Detailebenen bei der Präsentation, so dass der Kunde Detailinformationen zu den Angeboten sehen kann, aber das Wichtigste kompakt präsentiert wird. Ein gesetzlich vorgeschriebener Bestandteil der Angebotsdarstellung sind die Vertragskonditionen des Angebots. Diese erfordern eine besonders hervorgehobene Präsentation.

Die technische Realisierung dieser Komponente beruht auf HTML-Seiten, die über das WWW vom Server des Trustee abgerufen werden können. Diese Seiten werden dynamisch auf dem Server erstellt. Intern handelt es sich um JSP^[14] -Seiten, die das HTML-Markup mit auf dem Server ausführbarem Java-Code verbinden. Als Webserver kommt das Open-Source Programm JBoss^[15] zum Einsatz. Dieser Applikationsserver beinhaltet den Webcontainer Jetty^[16], der den von Sun Microsystems spezifizierten JSP-Standard unterstützt. Zur Absicherung der Kommunikation mit dem Kunden bietet der Server die Möglichkeit, die Kommunikation mittels einer SSL-Verbindung abzuwickeln. Der Kunde benötigt zur Interaktion mit dem Trustee lediglich einen konventionellen Webbrowser, um die HTML-Seiten abrufen und darstellen zu können. Für den Kunden ist der Trustee eine reine Webanwendung.

3.3.2.2 Kommunikation mit den Cluster-Partnern

Die Art der Dienste und die ausgetauschten Datenformate mit den Clusterpartnern SIPKIS und SIPREACT wurden in Abschnitt 3.2 auf Seite 19 bereits ausführlich beleuchtet. Hier soll es im Folgenden um die mögliche Realisierung dieser Schnittstellen gehen. Für den Datenaustausch zwischen den Systemen der Cluster-Teilprojekte hat XML eine große Bedeutung. Sämtliche Datenaustauschformate stellen Dokumente nach dem XML-Standard dar, selbst das Protokoll SOAP basiert auf XML.

Der Trustee verwendet dabei zur Verarbeitung von XML den XML-Parser Xerces des XML-Projekts der Apache Software Foundation^[17]. Dieser zeichnet sich durch seinen fortgeschrittenen Entwicklungsstand und seine breite Entwicklerbasis aus.

Die Fähigkeit des Trustee, XML verarbeiten zu können, ist die Basis für die darauf aufbauenden Aufrufe entfernter Methoden über das Internet, die sog. Webservices. Bei dieser Form des Aufrufs von Methoden, die von Internetservern zur Verfügung gestellt werden, wird ein XML-Dialekt, SOAP, verwendet, um die Aufrufparameter und die Ergebniswerte zu kodieren. Der große Vorteil dieser Methode ist der Transport der Daten per HTTP. Zum einen kann so die bestehende Internetinfrastruktur für den Transport genutzt werden, zum anderen sind Firewalls typischerweise so konfiguriert, dass sie für HTTP durchlässig sind, so dass auch so geschützte Rechner solche Dienste anbieten oder in Anspruch nehmen können. Für Webservices spricht auch ihre Verwendung von offenen Standards zur Kommunikation (HTTP, SOAP, XML, XML-Schema). Rein wissenschaftlich gesehen stellen Webservices jedoch keine Innovation dar, da die ihnen verwandten RPC-Aufrufe unter Unix schon eine lange Tradition haben (nach [Langn03]).

Webservices werden in dem betrachteten Cluster für den Austausch des Kundenmodells, für den Austausch des Produktmodells und für die Interviewkomponente verwendet. Sie stellen somit einen großen Teil der Kommunikationsinfrastruktur der Teilprojekte.

Bei Trustee wird die Kommunikation mit den angebotenen Webservices mittels des Axis^[18] -Frameworks realisiert, welches ein Bestandteil des JBoss-Servers ist.

XML ermöglicht die strukturierte Speicherung von Daten, jedoch ist die Wiedergewinnung und die Abfrage der XML-Daten nicht Teil des XML-Standards. Um diese Lücke zu schließen, definiert das W3C momentan eine Abfragesprache für XML. Diese trägt den Namen XQuery und befindet sich im Moment im Status „Working Draft“. Dies weist darauf hin, dass es sich dabei noch um keinen endgültigen und definierten Standard handelt (Status „Recommendation“), sondern um einen Arbeitsentwurf. Entsprechend rar sind daher die bisherigen Implementierungen, die diesen Standard unterstützen. XQuery spielt für die Umsetzung der Interviewkomponente und den Austausch des Kundenmodells eine zentrale Rolle.

Die Suche nach einer geeigneten Implementierung gestaltete sich schwierig, da die XQuery-Software frei erhältlich sein musste und darüber hinaus auch in ihren Lizenzbestimmungen verträglich mit dem Forschungsumfeld sein sollte. Daher kamen keine kommerziellen Lösungen in Betracht. Die Entscheidung fiel auf IPSI-XQ^[19], das hinreichend ausgereift ist, den XQuery-Standard bis auf kleine Ausnahmen implementiert und über eine gute Entwicklerunterstützung verfügt.

Die Schnittstelle dieser XQuery-Implementierung ist einfach aufgebaut. Ihr wird ein Quell-XML-Dokument und eine XQuery-Anfrage als Zeichenkette übermittelt. Nach erfolgreicher Anfrageausführung wird ein XML-Dokument mit den gewünschten Informationen zurückgegeben. Diese können ein einzelner Wert, ein Teil des Quell-XML-Dokumentes oder eine XML-Struktur, die XQuery bei der speziellen Abfrage erst erzeugt hat, sein. In jedem Fall kann das Ergebnis mit den oben beschriebenen Werkzeugen wie jedes andere XML-Dokument weiterverarbeitet werden.

Um eine Vorstellung davon zu vermitteln, wie XQuery benutzt wird, wird in der folgenden Abbildung eine beispielhafte Abfrage eines XML-Dokuments gezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Eine beispielhafte XQuery-Anfrage

Das Schlüsselwort „document“ legt fest, auf welches XML-Dokument die Anfrage angewendet werden soll. Dazu dient die URL, die in den Klammern angegeben ist. Die eigentliche Anfrage beginnt mit den beiden Schrägstrichen, hinter denen das XML-Element steht, das gesucht wird. In diesem Fall soll dasjenige Element „CustomerDetails“ zurückgegeben werden, welches als Attribut die „CustomerID“ mit dem Wert „ID004“ besitzt. Das Ergebnis beinhaltet alle XML-Daten, die zwischen dem Start- und dem Endetag des gesuchten XML-Elements „CustomerDetails“ stehen. Falls das gesamte Dokument abgerufen werden soll, reicht die Angabe der beiden Schrägstriche. Diese denotieren das Wurzelelement eines XML-Dokuments.

3.3.2.3 Kommunikation mit den Anbietern

Die Kommunikation mit dem Anbieter umfasst drei große Aufgabenbereiche: die passende Konvertierung der Kundendaten in ein für die Webseite passendes Datenformat, die Befüllung und die Übertragung der Webformulare, und das Vergleichen der zurück gelieferten Seiten mit dem gespeicherten Seitenmodell.

Alle diese Aufgaben verlangen das Parsen und die Manipulation von HTML-Code. Daher verwendet der Trustee die Scriptsprache WebL von Compaq^[20], die speziell für die Entwicklung von Webanwendungen entworfen worden ist. WebL selbst ist in Java realisiert und stellt eine einfach aufgebaute Sprache dar, die mächtige Befehle zur Manipulation von HTML-Seiten und zur Kommunikation mit Webservern mittels HTTP (GET/POST-Anfragen) umfasst. Ein besonderer Vorteil von WebL ist, dass es mit Besonderheiten und Fehlern des HTML-Codes umzugehen weiß, wie z.B. mit nicht geschlossenen Tags und nicht wohlgeformtem HTML-Code.

In der Agentenbetrachtung des Trustee realisiert WebL die Sensoren und die Aktoren des Trustee. Der Trustee nutzt WebL zur Wahrnehmung seiner (Internet-)Umwelt und setzt die Sprache auch zur Manipulation derselben ein.

Zur Realisation des oben genannten ersten Aufgabenbereiches der Datenkonvertierung trägt WebL bei, indem es vom Wissensingenieur bei der Modellierung einer Seite verwendet wird, um die passende Konvertierung der vorliegenden Kundendaten zu übernehmen. Dies ist beispielsweise dann nötig, wenn das Alter eines Kunden in Form einer Zahl vorliegt, aber die Webseite nur den Eintrag bestimmter Altersklassen in Form von disjunkten Intervallen zulässt. Ein WebL-Skript übernimmt dann die Abbildung der Alterszahl auf das entsprechende Teilintervall. Ein anderes Beispiel ist die Konvertierung von einem Datumsformat („17.12.2003“) in ein anderes („12/17/2003“).

Auch beim Befüllung und bei der Übertragung der Webformulare erweist sich WebL als hilfreich. Das Befüllen eines HTML-Formulars entspricht technisch gesehen dem Setzen der richtigen Parameter im HTTP-Befehl „POST“ oder „GET“ beim Aufruf der URL, die die Formularwerte verarbeitet. Die ganze Arbeit des Verbindungsaufbaus, des Erzeugens des richtigen HTTP-Befehls und der Ausführung desselben wird komplett von WebL übernommen. Es bedarf lediglich der richtigen Parametrisierung mit der abzurufenden URL und den zu benutzenden Parametern.

Als ein wichtiger Akt der Kommunikation zwischen dem Trustee und dem Server des Anbieters ist die Kontrolle der Antwortseite zu sehen, die nach dem Befüllen und dem Absenden eines Webformulars erzeugt wird. Nur wenn diese Antwortseite vom Trustee als passend identifiziert werden kann, wird der Trustee von einer erfolgreichen Kommunikation mit dem Server ausgehen. In allen anderen Fällen sind die übermittelten Daten entweder fehlerhaft oder im falschen Format oder der Trustee besitzt ein falsches oder veraltetes Modell der Seite. Dies kann dadurch geschehen, dass das Seitenlayout der Anbieterseite in der Zeit zwischen Seitenerfassung und Abfrage geändert worden ist.

Zur eindeutigen Identifikation einer HTML-Seite müssen vom Trustee bestimmte, sich nicht verändernde Merkmal der HTML-Seite ausgewertet werden, z. B. das Vorhandensein und die richtige Benennung des „Form“-Tags oder bestimmte konstante Textpassagen. Zur Identifikation und Extraktion dieser Wiedererkennungsmerkmale einer HTML-Seite ist WebL sehr gut geeignet, da diese Sprache eine Markup-Algebra zur Verfügung stellt, die das Suchen nach bestimmten Elementen, Abfolgen von Elementen oder Mustern innerhalb einer Seite unterstützt. Sind diese Merkmale gefunden, so kann WebL den Vergleich mit den gespeicherten Refernzmustern durchführen.

Nach der erfolgreichen Datenübermittlung an den Anbieter generiert dieser ein Angebot mit den genauen Spezifikationen der Produkte und den Angebotskonditionen. Sofern das komplette Angebot in HTML vorliegt, kann der Trustee dies automatisch verarbeiten. Dazu lassen sich spezielle WebL-Skripte entwickeln, die anbieterindividuell die wichtigen Daten des Angebots aus der HTML-Seite extrahieren.

WebL basiert auf Java und benutzt daher die Netzwerkklassen von Java. Diese sind insbesondere die Klassen des java.net-Packages, und dort vor allem die Klasse URLConnection. Diese Klasse wählt nach geeigneter Parametrisierung der System-Laufzeitumgebung eine bestimmte Implementation für die HTTP-Übertragung von Daten. Dies kann eine Implementation sein, die die Verschlüsselung der Daten per SSL unterstützt. Diese Auswahl ist vollkommen transparent für die die Verbindung benutzende Anwendung und ist nur von der angefragten URL abhängig („https“ im Schema der URL sorgt für die Verwendung einer Implementation, die SSL beherrscht). Dank dieser Transparenz profitiert WebL automatisch von der SSL-verschlüsselten Datenübertragung, ohne dass die Sprache oder die WebL-Skripte anzupassen sind.

3.3.2.4 Kommunikation mit dem Wissensingenieur

Die Rolle des Wissensingenieurs im Rahmen des Trustee besteht aus der Modellierung der Anbieterseiten und des Branchenwissens. Für diese zentrale Aufgabe stellt der Trustee eine Kommunikationsschnittstelle für den Wissensingenieur bereit. Das ist notwendig, da der Trustee die Internetseiten von Finanzdienstleistungsanbietern nicht direkt verarbeiten kann.

Er benötigt dazu vielmehr Modelle der Seiten, die wichtige strukturelle Informationen wie Formularelemente oder Adressen der Folgeseiten enthalten, durch die er mit der Anbieterseite interagieren kann. Diese Modelle werden in einem für den Computer einfach zu verarbeitenden XML-Dialekt (TRSML) gespeichert. Um dem Wissensingenieur die mühsame und fehlerträchtige Arbeit der manuellen Erstellung dieses XML-Codes abzunehmen, wurde eine Zwischensprache geschaffen, die leicht vom Menschen zu bearbeiten ist, und die als Basis für die Erzeugung der Seitenmodelle dient. Diese Zwischensprache, die im Laufe des Projekts entwickelt wurde, nennt sich TrusteeScript (TRS) (siehe auch Abschnitt 3.4.1.3 auf Seite 42 für eine genauere Beschreibung der Sprache). Jede Anbieterseite, die der Trustee verwenden können soll, muss in TRS kodiert, in XML übersetzt und im System abgelegt werden. Die Kodierung der HTML-Anbieterseiten in TRS ist eine der Aufgaben des Wissensingenieurs.

Abbildung in dieser Leseprobe nicht enthalten

Die folgende Abbildung gibt einen Überblick über den Ablauf der Erfassung eines Anbieters. Zunächst verarbeitet der Wissensingenieur die HTML-Seiten des Anbieters zu TRS-Modellen. Diese werden dann durch den TRS-Compiler in das Speicherformat TRSML umgewandelt. Ein Indexer erstellt ein Verzeichnis aller vorhandenen Anbieter unter Verwendung der TRS-Modelle.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Verarbeitung der Anbieterseiten

Bei der Seitenmodellierung wird der Wissensingenieur in Zukunft vom Trustee durch ein Modellierungstool unterstützt werden, welches Teil der Kommunikationskomponente des Trustee sein wird. Diese Unterstützung ist notwendig, da Internetseiten sich leicht ändern können, und nur aktuelle und richtig modellierte Seiten für eine Abfrage durch den Trustee in Frage kommen.

Das Modellierungstool sollte den Anwender (=Wissensingenieur) zunächst beim Download des HTML-Codes der gewünschten Seite unterstützen. Dabei kann Hilfe von Seiten des Tools erforderlich sein, da die URL der interessanten Teile einer Seite oftmals nicht bekannt ist. Häufig benötigt der Wissensingenieur nur eine einzige HTML-Seite eines ganzen HTML-Framesets, da nur sie für die automatische Verarbeitung interessant ist. Die Strukturierung der Menge von HTML-Seiten eines Anbieters könnte eine Leistung des Tools sein. Gut vorstellbar ist hier eine baumartige Darstellung der Seiten, in der die Verknüpfungsbeziehungen der einzelnen Seiten untereinander deutlich werden.

Eine weitere Hilfestellung für den Anwender wird die teilautomatische Transformation der gewählten Anbieterseite von HTML in TRS sein. Dies könnte durch spezialisierte WebL-Skripte erledigt werden. Vorstellbar sind die automatische Entfernung des Head-Tags, der keine Bedeutung für die weitere Verarbeitung hat. Auch die Verarbeitung und Aufbereitung des Form-Tags, welchem bei der Modellierung der Anbieterseiten eine besondere Bedeutung zukommt, erscheint sinnvoll, da in dessen Eingabefelder später die Kundendaten einzutragen sind. Darüber hinaus sind noch etliche weitere Aktionen denkbar, die dem Wissensingenieur die Erstellung eines Seitenmodells in TRS vereinfachen können. Darunter fällt die Entfernung von Bildern und JavaScript-Ausdrücken aus der HTML-Seite, soweit sie Visualisierungszwecken dienen.

Als Ziel des oben beschriebenen Prozesses ist ein Skelett der zu modellierenden Seite anzustreben, welches nur noch diejenigen Elemente enthält, die auch Eingang in das spätere TRS-Modell finden.

Die vorverarbeitete Seite könnte dann in einem Editor vom Wissensingenieur weiterverarbeitet werden. Im Laufe der Modellierung einer Seite in TRS wird es hilfreich für den Wissensingenieur sein, den bisherigen Code auf Fehler untersuchen zu lassen. Dafür wird im Modellierungstool der TRS-Compiler zuständig sein, der mögliche Fehler oder falsche Syntax bei der Übersetzung zurückmeldet. Auch das Testen der in das Modell eingebetteten WebL-Skripts sollte vom Modellierungstool unterstützt werden. Wie Abbildung 4 zu entnehmen ist, muss die in TRS modellierte Seite noch in den XML-Dialekt TRSML übersetzt werden, um durch den Trustee nutzbar zu sein. Diesen Prozess sollte das Modellierungstool anstoßen können und eventuelle Erfolgs- und Fehlermeldungen zurückliefern. Nach der erfolgreichen Übersetzung erfolgt die Ablage des neuen Modells auf dem Server.

Das Modellierungstool sollte es weiterhin erlauben, Änderungen an schon gespeicherten Seitenmodellen vornehmen zu können, falls sich die dazugehörigen Seiten im Internet ändern. Als Hinweis auf eine mögliche Seitenänderung durch den Anbieter kann der fehlgeschlagene Angebotseinholungsprozess bei einem Anbieter dienen. Besser wäre es aber, nicht mehr aktuelle Seiten vor ihrer Verwendung und vor dem möglichen Scheitern der Angebotseinholung entdecken zu können

Durch die TRS-Modellierung der Anbieterseiten kann der Trustee die Syntax der Seiten erkennen. Was noch fehlt ist ein Überblick über die Art und den Inhalt der Angebote. (siehe auch Abschnitt 3.4.1.3.2 auf Seite 47 für eine genauere Betrachtung des Problems). Dazu dient der in der obigen Abbildung 4 schon gezeigte Indexer. Dieser hat die Aufgabe, eine Liste aller modellierten Seiten zu führen, in der vermerkt ist, welcher Anbieter welche Produktkategorien anbieten.

Die Eingabe und Pflege dieser Daten ist ebenfalls die Aufgabe des Wissensingenieurs. Unterstützt werden kann er durch den Trustee beispielsweise, indem dieser eine graphische Benutzerschnittstelle zur Verfügung stellt, mit der die Zuordnung einer Produktkategorie zu einem Seitenmodell vereinfacht wird.

Als sinnvolle Implementierung des Modellierungstools und des Indexers eignen sich JSP-Seiten. Mittels HTML-Formularen kann die benötigte Editor-Funktionalität bereitgestellt werden.

Der TRS-Compiler, der Indexer und das Modellierungstool werden als JSP-Komponenten im Applikationsserver JBoss realisiert. Ein klarer Vorteil, der sich dadurch ergibt, ist die Änderbarkeit der Seitenmodelle über das Internet, da das Modellierungstool als Webanwendung vorliegt.

Eine zweite Aufgabe des Wissensingenieurs ist die Modellierung des Branchenwissens. Dabei gewährt der Trustee selbst dem Wissensingenieur keine Unterstützung. Da das Branchenwissen jedoch als Ontologie realisiert ist (siehe Abschnitt 3.4.1.2), sind dafür bereits Werkzeuge existent, z.B. OILEd^[21]. Das Branchenwissen ist nicht Teil des Trustee selbst, sondern wird dynamisch über den Zugriff per Netzwerk auf einen Reasoner, z.B. den RACER^[22] Server, in den Verarbeitungsprozess integriert.

[...]

^[1] Bayerische Forschungsverbund für Situierung, Individualisierung und Personalisierung in der Mensch-Maschine-Interaktion

^[2] World Wide Web

^[3] Platform for Privacy Preferences

^[4] A P3P Preference Exchange Language

^[5] Online Privacy Agent

^[6] Datenschutz im Internet

^[7] Web Browser Intelligence. URL: http://alme1.almaden.ibm.com/cs/wbi/

^[8] Reusable Task Structure-based Intelligent Network Agents URL: http://www-2.cs.cmu.edu/~softagents/retsina_agent_arch.html

^[9] URL: http://www.excite.com

^[10] Massachusetts Institute of Technology

^[11] Simple Object Access Protocol

^[12] Organization for the Advancement of Structured Information Standards

^[13] Extended Customer Information Language

^[14] Java Server Pages

^[15] URL: http://www.jboss.org

^[16] URL: http://www.jetty.mortbay.org/jetty/index.html

^[17] URL: http://xml.apache.org/xerces2-j/index.html

^[18] URL: http://ws.apache.org/axis/

^[19] URL: http://ipsi.fhg.de/oasys/projects/ipsi-xq/index_e.html

^[20] URL: http://www.research.compaq.com/SRC/WebL/download.html

^[21] URL: http://oiled.man.ac.uk/download.shtml

^[22] Renamed ABox and Concept Expression Reasoner. URL: http://www.fh-wedel.de/~mo/racer/index.html