Empfehlungssysteme mit Ontologien - userpagesstaab/Teaching/MastersTheses/franz... · †...

Universitat Karlsruhe (TH)

Empfehlungssysteme mitOntologien

Diplomarbeit am Institut fur Angewandte Informatik und formaleBeschreibungsverfahren (AIFB)Priv. -Doz. Dr. Steffen Staab

Fakultat fur WirtschaftswissenschaftenUniversitat Karlsruhe (TH)

von

cand. Inform. -Wirt.Franz Sirch

Betreuer und Referent:

Priv. -Doz. Dr. Steffen Staab

Tag der Anmeldung: 30. Juli 2003Tag der Abgabe: 31. Januar 2004

Ich versichere hiermit wahrheitsgemaß, die Arbeit selbstandig angefertigt, alle be-nutzten Hilfsmittel vollstandig und genau angegeben und alles kenntlich gemachtzu haben, was aus Arbeiten anderer unverandert oder mit Abanderung entnommenwurde.

Karlsruhe, den 31. Januar 2004

Inhaltsverzeichnis

1 Einleitung 1

1.1 Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Ontologien 3

2.1 Formalisierung einer Ontologie . . . . . . . . . . . . . . . . . . . . . . 4

2.2 OntoBroker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 OntoEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Erklarungssysteme 9

3.1 Anwendungsgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Expertensysteme . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.2 Erklarungskomponenten fur die Validierung objektorientierterModelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Einfuhrung in die Problematik . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Inhaltsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 Regelpfade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1.1 MYCIN . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3.1.2 Reconstructive Explainer (REX) . . . . . . . . . . . 13

3.3.2 Strategische Erklarungen . . . . . . . . . . . . . . . . . . . . . 14

3.3.3 Aufgabenbasierte Erklarungen . . . . . . . . . . . . . . . . . . 15

3.3.4 Rechtfertigung von Wissen . . . . . . . . . . . . . . . . . . . . 15

3.3.4.1 XPLAIN . . . . . . . . . . . . . . . . . . . . . . . . 16

ii Inhaltsverzeichnis

3.3.4.2 Explainable Expert System (EES) . . . . . . . . . . 17

3.3.4.3 CoGenTex . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.4.4 OntoNova . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Inhaltsorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.1 RST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.2 Toulmins Argumentationsmodell . . . . . . . . . . . . . . . . 23

4 Recommender Systeme im E-Commerce 25

4.1 Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Benutzeroberflache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Analyse des Systems 29

5.1 Funktionsweise des Recommender Systems der Mentasys GmbH . . . 29

5.2 Architektur des Systems . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Analyse des Kaufprozesses 35

6.1 Produktprasentation und Nutzenargumentation . . . . . . . . . . . . 36

6.2 Einwandbehandlung und Vertiefung des Kundenverstandnisses . . . . 37

7 Entwurf der Ontologie 39

7.1 Der Produktraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.2 Der Bedurfnisraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.2.1 Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.2.2 Falle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2.3 Fitnessklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.3 Der Begrundungsraum . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.4 Die Baumkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.5 Die Bewertung der Produkte . . . . . . . . . . . . . . . . . . . . . . . 50

7.6 Die Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.7 Die Bestimmung der Fitnessklasse . . . . . . . . . . . . . . . . . . . . 51

7.8 Die Begrundungsmechanismen . . . . . . . . . . . . . . . . . . . . . . 52

7.8.1 Inhaltsselektierung . . . . . . . . . . . . . . . . . . . . . . . . 52

7.8.2 Inhaltsorganisation . . . . . . . . . . . . . . . . . . . . . . . . 54

7.9 Modellierung eines Handyberaters . . . . . . . . . . . . . . . . . . . . 56

Inhaltsverzeichnis iii

8 Zusammenfassung und Ausblick 61

8.1 Effizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.2 Qualitat des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A Die Axiome 65

A.1 Baumkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

A.2 Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

A.3 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.4 Fitnesswerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.5 Inhaltsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

B Die Relationen und Konzepte des Basissystems in Frame-Logik 77

B.1 Produktraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.2 Bedurfnisraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.3 Begrundungsraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Literatur 81

1. Einleitung

Im heutigen Informationszeitalter werden Kaufentscheidungen zunehmend vom In-ternet beeinflusst, da die Moglichkeit besteht sich uber Produkte ausfuhrlich zuinformieren. Die zu bewaltigende Informationsvielfalt beim Internetkauf wurde mitunterschiedlichen Technologien reduziert, welche eine individuelle Selektion fur einenBenutzer vornehmen. Jedoch bietet das Internet bei Kaufentscheidungen derzeit na-hezu keinen Service. So kann beispielsweise ein Benutzer auf eine ausfuhrliche Bera-tung beim Kauf, wie er sie aus einem konventionellem Geschaft gewohnt ist, seltenhoffen. Die Mentasys GmbH versucht diesem Problem zu begegnen, indem sie einSystem fur diese Problematik entwickelt hat.

Unabhangig davon hat sich in der Informatik seit Anfang der fruhen neunziger Jahremit Ontologien eine neue Technologie etabliert. Von ihr verspricht man sich auf vielenAnwendungsgebieten einen Mehrwert, da Daten nun fur Maschinen interpretierbarsind. Die wohl bekannteste Anwendung ist das ’Semantic Web’, siehe [BLFD99].

Die vorliegende Diplomarbeit zum Thema Empfehlungssysteme mit Ontologien be-schaftigt sich damit, wie ein Empfehlungssystem der Mentasys GmbH mit Ontolo-gien realisiert werden kann.

1.1 Zielsetzung der Arbeit

Ziel dieser Arbeit ist nach einer theoretischen Betrachtung von Ontologien und einerAnalyse des Empfehlungssystems der Mentasys GmbH, eine Refernzmodellierung zuerstellen.

Mit der Referenzmodellierung soll Untersucht werden, welche Vor- und Nachteile dieVerwendung von Ontologien im Gegensatz zu den bestehenden Losungen hat.

1.2 Gliederung der Arbeit

Die Arbeit beinhaltet zuerst eine kurze Einfuhrung uber Ontologien. Es folgt eineallgemeine Betrachtung von Systemen, die Erklarungen generieren. Mit den Kapi-teln Recommender Systeme im E-Commerce, Analyse des Systems und Analyse des

2 1. Einleitung

Kaufprozesses wird das System der Mentasys GmbH erlautert. Im Kapitel Entwurfder Ontologie wird die Referenzmodellierung vorgestellt. Den Abschluss bildet eineZusammenfassung, welche die Starken und Schwachen des Entwurfs diskutiert undErweiterungsvorschlage fur die zukunftige Entwicklung des Systems erortert.

2. Ontologien

Es gibt keine eindeutige Definition von Ontologien. Definitionen, welche sehr ver-breitet sind liefern Gruber [Gru98]:

’An ontology is a specification of a conceptualization’

oder Swartout, Patil, Knight und Russ [BSR96]:

’An ontology is a hierarchically structured set of terms for describing a domainthat can be used as a skeletal foundation for a knowledge base.’

Ontologien sind wissensorientierte Datenstrukturen. Andere Datenstrukturen warenz.B. relationale Datenbank- oder XML-Schemata. Im Vergleich zu anderen Daten-strukturen besteht die Moglichkeit, semantische Informationen beispielsweise mitLogikregeln abzubilden. Diese Eigenschaft hebt Ontologien in ihrer Machtigkeit vonanderen Datenstrukturen ab, da intelligente Anwendungen realisiert werden kon-nen. Zudem kann das Schema unabhangig von den Daten auf sehr einfache Weiseverandert werden, was eine sehr große Flexibilitat schafft.

Wahrend sich in den fruhen neunziger Jahren eine eher kleine Gruppe von Wissen-schaftlern mit Ontologien beschaftigt hat, wird heute hierzu auf vielen Gebieten, wieKunstliche Intelligenz, Computer Linguistik und Datenbanktheorie geforscht. Fureinen Uberblick der unterschiedlichen Anwendungsgebiete siehe Guarino [Gua98].

Mit Ontologien kann man eine Domane strukturieren und visualisieren. Eine Doma-ne ist ein Wissensgebiet bzw. eine Wissensbasis, wie beispielsweise die Informatik,die Biologie oder die Medizin. Fur die Darstellung von Wissen ist wichtig, dass nichtnur elementare Einheiten des Wissens (Konzepte bzw. Begriffe) reprasentiert wer-den, sondern auch die Beziehungen zwischen ihnen (Wissenszusammenhange). DaBeziehungen zwischen Konzepten unterschiedlicher Art sein konnen, muss auch dieArt der Beziehung (Relation) festgehalten werden. Weiter erfolgt die Ordnung einerDomane uber die Gliederung der Konzepte in Hierarchien. Somit kann man Daten

4 2. Ontologien

(Instanzen) in einem semantischen Zusammenhang abspeichern, welcher es Rechnernermoglicht, diese zu interpretieren. Mit der Moglichkeit zusatzlich logische Regeln(Axiome) einzubauen, kann man beispielsweise neues Wissen generiert, ohne explizitDaten abgespeichert zu haben.

Die im Rahmen dieser Arbeit durchgefuhrte Modellierung einer Ontologie soll Wis-sen eines Recommender Systems, siehe Kapitel 4, darstellen. Des Weiteren beschaf-tigt sich diese Arbeit mit der Frage, ob man mit Ontologien im Vergleich zu denverwendeten Techniken von bestehenden ’state-of-the-art’ Recommender Systemeneinen Mehrwert schaffen kann. Hierbei ist zum einen wichtig, ob Mechanismen bzw.Prozesse komfortabler umgesetzt werden konnen. Zum anderen wird untersucht, obzusatzliche Prozesse implementierbar sind, die mit den bisherigen Systemen nichtmoglich oder nur sehr schwer realisierbar sind.

Fur die Modellierung des Recommender Systems dieser Arbeit wurden die ProdukteOntoBroker und OntoEdit der Firma Ontoprise vorgegeben, welche in den folgendenAbschnitten 2.2 und 2.3 beschrieben werden.

2.1 Formalisierung einer Ontologie

In einer Ontologie verwendet man, wie einleitend beschrieben, Konzepte, Relatio-nen, Instanzen, Attribute und Axiome, um eine Domane abzubilden. In Abbildung2.1 ist beispielhaft eine Konzepthierarchie, dazugehorige Relationen und ein Axiomdargestellt.

Ein Konzept ist ein abstrakter Begriff, welchem uber Relationen Eigenschaften (At-tribute) zugeordnet werden. Eine Relation legt einen Wertebereich fest.

Beispielsweise wird in Abbildung 2.1 uber die Relation ’is about’ beschrieben, dassjede Bestellung (’order’) Produkte (’product’) hat. Somit ist ’product’ ein Attributfur jede Instanz des Konzeptes ’order’ und der Wertebereich umfasst alle Instanzendes Konzeptes ’product’.

Die Erstellung einer Hierarchie erlaubt es in Ontologien, Konzepte zu ubergeordnetenKonzepten zusammenzufassen. Ein Unterkonzept erbt alle Eigenschaften ubergeord-neter Konzepte.

Beispielsweise wurde eine Relation ’has name’ des Konzeptes ’person’ von den Kon-zepten ’employee’, ’sales manager’ und ’client’ ubernommen werden. Das bedeutet,dass die drei Konzepte auch die Relation ’has name’ besitzen. Wohingegen die Re-lation ’is sales manager of’ nur fur das Konzept ’sales manager’ sinnvoll ist, weil sieeine spezifische Eigenschaft des Konzeptes widerspiegelt. Deshalb ist diese Relationnur in ’sales manager’ und nicht in ’person’ definiert.

Eine Instanz eines Konzeptes ist ein Datensatz, bei dem jedem definierten Attributdes Konzeptes konkrete Werte zugeordnet werden. In Abbildung 2.2 sind Instanzender Konzepte aus Abbildung 2.1 und die zugehorigen Attribute dargestellt.

Axiome ermoglichen nun, dass Beziehungen bzw. neues Wissen aus bereits vorhan-denem Wissen generiert werden kann.

2.1. Formalisierung einer Ontologie 5

��

��

��

��

��

��

��

�� !"!#� � $�%"� ��

��

��

��

��

&' �(

)*

"�+

��

��

��

��

��

�,

�� -��

��

��

.�/��

-�

��-��

��

��

�,

��/��

-�

Abbildung 2.1: Ontologie

Das Axiom aus Abbildung 2.1 legt beispielsweise fur jede Bestellung (’order’) einenVerkaufsmanager uber die Relation ’is handled by’ fest, siehe Abbildung 2.2. Vor-raussetzung dafur ist, dass die Person Verkaufsmanager des Produktes ist, um diesich die Bestellung dreht.

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

� ��

��! ��"

��! ��"

Abbildung 2.2: Instanzen

Die Formalisierung einer Ontologie wird bei OntoBroker mit einer Variante vonFrame-Logik realisiert. Frame-Logik, fur weiterfuhrende Literatur siehe [KLW90],ist eine deduktive Logik.

Frame-Logik verbindet Modell und Logik, da zum einen Informationen der Ontologiesowie zum anderen Axiome dargestellt werden konnen. Fur eine Beschreibung derwichtigsten elementaren Ausdrucke mit Frame-Logik siehe [Onta] und [DEFS98]. Imfolgenden eine kurze Einfuhrung in Frame-Logik:

• Unterklasse: c1::c2 bedeutet, c1 ist ein Unterklasse von c2.

• Instanz von: o:c bedeutet, o ist eine Instanz von Klasse c.

• Attribut Deklaration: c1[A =>> c2] bedeutet, dass fur eine Instanz der Klassec1 ein Attribut A definiert ist, welches als Wert eine Instanz von Klasse c2 seinmuss.

• Attribut Werte: o[A− >> V ] bedeutet, dass die Instanz o ein Attribut A mitWert V hat.

6 2. Ontologien

• Teil-Von: o1 <: o2 bedeutet, dass o1 ein Teil von o2 ist.

• Relationen: Pradikate, wie p(a1,...,a2) konnen, wie aus logikbasierten Forma-lismen(Datalog, Prolog usw.), verwendet werden. Weiter gibt es den Zusatz,dass auch Objekte als Argument verwendet werden konnen, anstatt nur Terme.

Aus elementaren Ausdrucken werden komplexe Ausdrucke konstruiert, wie Faktenund Axiome. Fakten sind eine Ansammlung elementarer Ausdrucke, wohingegenAxiome aus einem Kopf, einer Implikation und dem Korper bestehen. Fur eine Dar-stellung des oben beschriebenen Beispieles in Frame-Logik siehe Abbildung 2.3.

��

��

��

��

��

��

�� !"#$" %"&'$(� "

��

)'*$"

��

%"+"&,-��../0102

/��3��4��2�5� /��4�� 1�� 2�� 1�

67��6��

89":;,-��..20/5�/��3��4��2�

��4�� <�� =��4��

��3��4� ��

Abbildung 2.3: Frame-Logik

Daruberhinaus bietet OntoBroker in Frame-Logik, siehe Abbildung 2.3, die Moglich-keit, Anfragen an die Ontologie zu stellen, auch ’Query-Formalismus’ genannt.

2.2 OntoBroker

OntoBroker [Ontb] ist ein deduktives, objektorientiertes Datenbanksystem, welchesspeziell fur den Einsatz mit Ontologien entwickelt wurde. OntoBroker kann als Ser-ver, als eigene Applikation oder integriert in andere Applikation als Service verwen-det werden, um Anfragen zu bearbeiten. Im Rahmen dieser Arbeit wird OntoBrokerals Server genutzt, welcher auf Anfragen an eine eingelesene Ontologie Wissen ab-leitet und spezifische Antworten zuruckschickt.

OntoBroker kann mit Frame-Logik, RDF(S), XML, Prolog und OXML mehrere For-mate interpretieren. Desweiteren konnen unterschiedliche Ontologien bzw. Domanenmittels eines ’Namespace-Mechanismus’ separiert werden. Da Konzepte oft mit demselben Namen benannt werden, kann man sie in einem derartigen Fall nur uber den’Namespace’ bei der Bearbeitung von mehreren Ontologien unterscheiden. Weiterkonnen Datenbanken oder XML Dateien in der Art integriert werden, dass Schema-informationen importiert und in Ontologien eingebunden werden. Es besteht aucheine Schnittstelle, um Java-Programme einzubinden, falls die Funktionalitat erwei-tert werden soll.

2.3. OntoEdit 7

Daruberhinaus ist mit OntoBroker ’Meta-Inferencing’, siehe [AMO+03], moglich. DieTechnik des ’Meta-Inferencing’, welche von der Firma Ontoprise patentiert wordenist, erlaubt es nach einer Anfrage in einem zweiten Schritt zu untersuchen, welcheAxiome mit welchen gebundenen Variablen fur die generierte Antwort benotigt wur-den. Diese Technik erlaubt es, erneut Wissen abzuleiten oder abgeleitetes Wissen zuerklaren. Siehe in diesem Zusammenhang das in Abschnitt 3.3.4.4 beschriebene, vonder Firma Ontoprise realisierte System ’OntoNova’.

2.3 OntoEdit

Die Modellierung von großeren Ontologien wird aufgrund der Komplexitat schnellunubersichtlich [SSA02]. OntoEdit, eine Entwicklungsumgebung speziell fur Ontolo-gien, erlaubt die Erstellung und Wartung mittels einer grafischen Benutzeroberflache[Ontc]. OntoBroker ist in OntoEdit integriert. Somit besteht die Moglichkeit Anfra-gen an Ontologien wahrend des Konstruktionsprozesses zu stellen. Daruberhinauskann man mit OntoEdit unterschiedliche Ontologien mit unterschiedlichen ’Name-spaces’ uber die Benutzeroberflache zusammenfugen (Ontomapping) und eine neueOntologie definieren. Auf die selbe Weise konnen auch Datenbanken oder XML Da-teien integriert werden.

8 2. Ontologien

3. Erklarungssysteme

Das in Kapitel 7 modellierte Recommender System soll seine Ergebnisse erklarenbzw. begrunden. Dieses Kapitel liefert eine Bestandsaufnahme maschinellen Erkla-rens und gibt einen Uberblick uber die wichtigsten Ergebnisse anderer realisierterSysteme.

Man kann feststellen, dass Menschen Dinge erklaren, um etwas zu veranschaulichen,zu lehren oder zu uberzeugen. Nach einer Analyse naturlichsprachlicher Erklarungenin [JGL83] kann man ’Beispiele geben’, ’Begrunden’ oder ’Alternativen eliminieren’als wesentliche Methoden des Erklarens identifizieren. Die Tabelle 3.1 zeigt, wannwelche Methode bevorzugt verwendet wird. Wichtig ist festzuhalten, dass fur die Er-klarungstypen unterschiedliche Schwierigkeitsgrade herrschen. Das Uberzeugen stellthierbei sicherlich eine der schwierigsten Aufgaben dar, da eine Argumentation not-wendig ist [AHO90].

Methode Art der Erklarung

Beispiele geben Veranschaulichen

Begrunden Lehren,Uberzeugen

Alternativen eliminieren Veranschaulichen,Uberzeugen

Tabelle 3.1: Methoden

In der Informatik beruht das Bedurfnis, dass Softwaresysteme Antworten rechtferti-gen bzw. sich erklaren, letztendlich auf der Interaktion mit Menschen. Diese habendas Bedurfnis eine produzierte Antwort oder Aktionen eines Systems nachzuvoll-ziehen. Eine Erklarung ist komplett, wenn der Benutzer zufrieden ist und er dasKonzept, welches erklart wurde, versteht [Woo98].

In diesem Zusammenhang ist in der Informatik die Problematik der Generierungvon Erklarungen entstanden. Das Uberbrucken der großen Unterschiede zwischenden formalen und textuellen Reprasentationsschemas hat sich als die großte Heraus-forderung bei der Konstruktion eines Erklarungssystem herausgestellt [LP97].

10 3. Erklarungssysteme

3.1 Anwendungsgebiete

Angewandt werden Erklarungssysteme nach [Woo98] unter anderem in Hilfesyste-men, Trainingssystemen, Expertensystemen oder fur die Validierung objektorientier-ter Komponenten. Die nachfolgenden Abschnitte 3.1.1 und 3.1.2 geben eine kurzeErlauterung zu den wichtigsten Anwendungsgebieten Expertensysteme und Validie-rung objektorientierter Modelle.

3.1.1 Expertensysteme

Expertensysteme sind Anwendungen, die in einer bestimmten Domane (Medizin,Chemie, Physik usw.), wie ein Experte, Auskunft geben oder Entscheidungsunter-stutzung bieten. Expertensysteme waren die ersten Anwendungen und somit Vorrei-ter, bei denen es erforderlich war naturliche Sprache zu generieren, da diese Systemeihre Schlussfolgerungen erklaren sollten [BMR+98]. Die meisten Erklarungskompo-nenten, welche im Folgenden vorgestellt werden, sind Teile von realisierten Exper-tensystemen. Dies belegt die Prasenz dieses Anwendungsgebietes bezuglich der Ge-nerierung von Erklarungen.

3.1.2 Erklarungskomponenten fur die Validierung objekt-orientierter Modelle

Unter ’Requirements Engineering’ versteht man die Erstellung einer Spezifikation derFunktionalitat großer und komplexer Softwaresysteme. Ein Teilbereich des ’Require-ment Engineering’ stellt die Analyse der Anforderungen dar. Die Analyse beinhaltetValidierung und Verifikation. Unter Validierung versteht man die Uberprufung, obdas Modell den Anforderungen des Benutzers gerecht wird. Bei der Validierung sindunterschiedliche Parteien mit unterschiedlichem Wissen involviert (Kunden, System-entwickler usw.). Die Validierung ist ein informeller Prozess, welcher nicht automati-siert (im Gegensatz zur Verifikation) werden kann und eine subjektive, menschlicheBeurteilung benotigt. Es wurden eine Reihe von Techniken (z.B. Modellsimulati-on, Modellplanung, Komplexitatsreduzierung usw.) zur Validierung verwendet. Umden Validierungsprozess zu realisieren, hat sich die Erklarungsgenerierung als eineangemessene Technik erwiesen, siehe [DJ97] oder [Gul96].

3.2 Einfuhrung in die Problematik

Damit ein System Schlussfolgerungen generieren kann, bedarf es in der Regel einerWissensbasis, welche explizite Informationen zu einer Domane speichert. Damit dasSystem auf Fragen Antworten hinsichtlich der Wissensbasis generieren kann, mussdas System des Weiteren automatisch schließen bzw. ableiten (auch ’Reasoning’,’Deduction’ oder ’Inferencing’) konnen, siehe Abbildung 3.1. Automatisches Schlie-ßen wiederum erfordert Regeln in Form von propositionaler Logik, Pradikat Calculusoder irgendeiner probabilistischen Struktur [GDS01]. Diese Regeln sind meist sehrkomplex und undurchsichtig fur Benutzer, die keinen Einblick in die Konstruktionder Wissensbasis hatten.

Allgemein lasst sich sagen, maschinelles Erklaren bedeutet, die relevanten Informa-tionen bei einer Schlussfolgerung oder Losung in einem wissensbasierten System zu

3.2. Einfuhrung in die Problematik 11

��

��

�� !"#!$#%&'(!()

*+,( -.�+/0%#!"��0%#!1�

Abbildung 3.1: Automatisches Schließen

extrahieren und schließlich in eine Form naturlicher Sprache zu ubersetzen, damitder Benutzer die Aktionen des Systems nachvollziehen bzw. verstehen kann [MS88].

3.2.1 Definition

In [TM93],[BMR+98], [MS88] oder [Gul96] wird das Problem, eine gute Erklarungin wissensbasierten Systemen zu generieren im wesentlichen in drei Funktionalitatenaufgeteilt: den geforderten Inhalt bestimmen, den Inhalt gemaß den Bedurfnissen desBenutzers gestalten und eine entsprechende Interaktion mit dem Benutzer erzeugen.

Das folgende Schema von [LP97] gibt hierzu einen detaillierten Uberblick:

• Discourse-Knowledge Engineering: Planung des Dialogs zwischen Systemund Benutzer, auch ’Discourse Strategy’ genannt.

• Explanation Planning: Auch ’Explanation generation’ oder ’Textplanning’genannt. Die Erklarungsplanung ist unabhangig von der Sprache, mit der dieErklarung prasentiert wird [Gul96]. Bei der Erklarungsplanung wird unter an-derem die gewunschte Lange oder relative Wichtigkeit einer Erklarung be-stimmt und beinhaltet folgende Prozesse:

– Inhaltsbestimmung (’Content Determination’): Inhalt des zugrundelie-genden wissensbasierten System selektieren

– Inhaltsorganisation (’Content Organisation’): Das selektierte Wissen derErklarung gemaß strukturieren

• Functional Realization: Bietet eine lexikalische und grammatikalische Un-terstutzung.

In alten Systemen sind Prozesse, wie Inhaltsbestimmung oder Inhaltsorganisation,teilweise zusammenhangend. In neueren Ansatzen ist jedoch klar zu erkennen, dassdie einzelnen Aufgaben voneinander getrennt werden. Fur die Modellierung in Kapi-tel 7 sind die Kriterien zur Inhaltsbestimmung und Ansatze der Inhaltsorganisationvon Bedeutung, da sie bei der Generierung von Erklarungen elementar sind.

Die Prozesse der lexikalischen und grammatikalischen Unterstutzung, ebenso wiedie Dialogplanung spielen fur die realisierte Modellierung keine Rolle, da der damitverbundene Aufwand im Rahmen dieser Arbeit zu hoch war. Beide Prozesse sindjedoch fur die Weiterentwichklung des Systems zur Unterstutzung des Kaufprozessesrelevant.

Die eigentliche Textgenerierung kann bei allen Prozessschritten erfolgen.


3.2.2 Anforderungen

Die Anforderungen an ein Erklarungssystem hangen sehr von seinem Anwendungs-gebiet ab [SM93]. Die Evaluierung der Gute von Erklarungen ist nach [LP97] einkritisches und nicht triviales Problem. Die wichtigsten Kriterien seiner Meinungnach sind Koharenz, Inhalt, Organisation, sprachliche Fahigkeit und Korrektheit.

Bei [SM93] wird Effektivitat und eine genaue Ubereinstimmung von Erklarung undder logischen Herleitung des Systems gefordert. Des Weiteren sollen verstandlicheErklarungen generiert werden, die der Terminologie der Domane entsprechen undunterschiedlichen Ebenen der Abstraktion bzw. Detaillierung entsprechen. Danebensollen unterschiedliche Standpunkte beleuchtet werden. Die Erklarung muss auf denBenutzer eingehen und naturlicher Sprache entsprechen. Eine wichtige Frage ist auch,was fur Wissen das System beinhalten soll, um angemessene Erklarungen zu erzeu-gen. Laut [SM93] hangt das Erklarungswissen, welches die Domane beinhalten soll,von den Erklarungstypen ab. Es wird unterschieden zwischen den Erklarungstypen,die das Verhalten des Systems erklaren, Rechtfertigungen erzeugen, Praferenzen bzw.Strategien erklaren, Erklarungen bezuglich der Domane geben oder Definitionen derTerminologie wiedergeben. Die wichtigsten Erklarungstypen werden im folgendenAbschnitt 3.3 genauer untersucht.

3.3 Inhaltsbestimmung

Nach [TM93] ist die Bestimmung des adaquaten Inhalts das zentrale Problem, dadie anderen Schritte in ihrer Qualitat entscheidend davon abhangen. Nach [Woo98]und [TM93] sind vier wichtige Techniken fur die Inhaltsbestimmung wesentlich. Eswird unterschieden zwischen schrittweisem Erklaren bzw. Regelpfaden (Verhaltendes Systems), strategischen Erklarungen, aufgabenbasierten Erklarungen und Recht-fertigung von Wissen. In [Woo98] werden zusatzlich noch generische Aufgaben als Er-klarungsform erwahnt. Diese aber gelten als eine Sonderform von aufgabenbasiertenErklarungen und werden in Abschnitt 3.3.4 mit den aufgabenbasierten Erklarungenerlautert.

Die Schwierigkeit bei der Bestimmung des Inhalts ist, dass das Wissen aus demder Inhalt bestimmt wird, dynamisch erzeugt wird. Im Gegensatz zu den oben auf-gefuhrten Techniken konnen Erklarungen auch statisch sein. Fur vorab bestimmteSchlusselworter wird eine Erklarung bereitgestellt. Diese werden bei der Implemen-tierung einem System beigefugt.

Die folgenden Systeme, welche teilweise beispielhaft eine Erklarungstechnik repra-sentieren, beinhalten zum Teil andere Erklarungstechniken, so dass Ubergange flie-ßend sind. Es gilt zu beachten, dass die Systeme zu unterschiedlichen Zeitpunktenentstanden sind und dass durchaus eine Entwicklung festzustellen ist, bei der dieNachteile alter Systeme vermieden werden.

3.3.1 Regelpfade

Erklarungsgenerierung anhand von Regelpfaden ist nach [Woo98] ein Prozess beidem Regeln identifiziert werden, die in einer bestimmten Reihenfolge benutzt wur-

3.3. Inhaltsbestimmung 13

den, um eine Schlussfolgerung zu erzeugen. Der generierte Pfad dient als Ausgangs-basis fur eine Erklarung. Das heißt es werden Erklarungen von Entscheidungen aufdem Niveau des Wissens des Systems generiert.

3.3.1.1 MYCIN

MYCIN [BS84], eines der ersten Systeme dieser Art, konnte ’Wie’ (Wie kommt es zudieser Schlussfolgerung?) und ’Warum’ (Fragen, welche dem Benutzer die Relevanzvon Eingabedaten verdeutlichen) erklaren.

MYCIN [AHO90] generiert dynamisches Wissen anhand von Benutzereingaben undabgeleiteten Regeln. Dieses dynamische Wissen steht dem Regelinterpreter und derErklarungskomponente zur Verfugung. Die Erklarungskomponente kann zusatzlichauf die Fakten (statisches Wissen) zugreifen, hat aber keinen Zugang auf das Wissendes Regelinterpreters.

Das dynamische Wissen entspricht einem Baum, bei dem jeder Knoten Auskunftuber die verwendete Regel und das beabsichtigte Ziel beinhaltet. Daruberhinauswird zu jedem Ziel die Information, ob die Regel abgeleitet werden konnte oder anwelcher Ableitung es scheiterte, bereitgestellt.

Systeme der ersten Generation, wie MYCIN, hangten ihre Erklarungen direkt andie Regeln. Das Ergebnis war, dass die Erklarungen zwar sehr genau, aber meistunverstandlich waren. Nach [SM93] war das direkte paraphrasieren der Regeln, diesich auf einer niedrigen Ebene befanden, nicht ausreichend. Diese Technik erlaubtnicht die Abstraktion, die hinter mehreren Regeln steht, zu reprasentieren. D.h. dasSystem konnte keine Aktionen erklaren, welche mehrere Losungsschritte benotigteund fur die eine zusammenfassende Erklarung notwendig war.

MYCIN hatte eine Reihe von ahnlichen Nachfolgern (einen guten Uberblick liefert[Ell89]), um mit NEOMYCIN einen der wichtigsten zu nennen. NEOMYCIN erwei-terte MYCIN um zusatliche Metaregeln (Regeln, welche nur zur Erklarung andererRegeln dienen), ist aufgabenbasiert (siehe Abschnitt 3.3.4) und wurde verwendet,um die Ergebnisse von MYCIN zu erklaren [Woo98].

3.3.1.2 Reconstructive Explainer (REX)

Der im Folgenden beschriebene Ansatz eines ’Reconstructive Explainers’ [Wic93] be-ruht auf der Beobachtung, dass fur die Erklarung einer Aktion nur bestimmte Teileeines Regelpfades relevant sind. Der Pfad der Schlussfolgerungen wird fur Erklarun-gen neu konstruiert - deshalb der Name ’Reconstructive Explainer’.

Die Herausforderung, nach [Wic93], eine gute Erklarung zu generieren, besteht nundarin, unter allen beobachteten Aktionen die wichtigsten zu selektieren und mitein-ander zu verbinden. Nach [Dal92] sind Erklarungen dann effektiv, wenn sie unter-schiedliche Teile eines konzeptionellen Modelles, z.B. die unterschiedlichen Fakten,genauso wie dynamisch abgeleitete Regeln verbinden.

Das Expertensystem [M.R92], siehe Abbildung 3.2, generiert eine Reihe von Pfaden.Die Pfade enthalten die verwendeten Schlusseldaten und Schlussfolgerungen, diewahrend der tatsachlichen Problemlosung vom System verwendet worden sind.


��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Abbildung 3.2: Architektur Rex

Der Inhalt wird bestimmt, indem Pfade an einen ’Screener’ weitergereicht werden,der festlegt, welche Informationen fur das Erklarungssystem zuganglich sind. Hierbeiwerden vordefinierte Erklarungsklassen unterschieden. Die selektierten Pfade, auchAspekte genannt, werden mit der Spezifikation der Domane des Expertensystemsverglichen. Hierbei wird mit einem zusatzlichen Filter, welcher von der Domaneabhangt, die Spezifikation gestutzt und letztendlich an den ’Explainer’ ubergeben.Der ’Explainer’ generiert mit Relationen und Methoden neue Pfade, speziell furdie Erklarung. Die Relationen und Methoden gehoren der Domane fur Erklarungen(’Explanatory Knowledge’) an.

Die Organisation des Inhalts ubernimmt der ’Story Teller’, der anhand einer Gram-matik, siehe [M.R92], einen Baum erzeugt, welcher als Ausgangsbasis fur eine insich stimmige Erklarung dient. Der ’Verbalizer’ ubersetzt diesen Baum in eine Er-klarung naturlicher Sprache (entspricht der in Abschnitt 3.2 genannten ’FunctionalRealization’).

Ein großer Vorteil der hier angewandten Technik ist, dass sich die Aspekte zu-sammenhangslos, in unterschiedlichen Teilen der Domane befinden konnen. Wissen[BMR+98] wird bei REX in Wissen der Domane und Wissen fur Erklarungen unter-teilt.

Systeme, wie [SR98],[SM99] oder [BMR+98] beziehen sich auf die Technik, die mitREX umgesetzt wurde.

3.3.2 Strategische Erklarungen

Dieser Erklarungtypus beschreibt, warum bestimmte Strategien bzw. Alternativengegenuber anderen bevorzugt wurden. Die Erklarungen beziehen sich deshalb auf Re-gelpfade, welche aufgrund von Entscheidungen generiert wurden, um das eigentlicheZiel des Benutzers umzusetzen. Das System hangt von Praferenzen bzw. Parameternab, welche die Entscheidung beeinflussen.

’Rationale’ [AHO90] ist beispielsweise ein medizinisches Diagnosesystem. Das Wissenuber die Domane ist hierarchisch in Hypothesen und Subhypothesen organisiert. Das


Herleiten der Diagnose wird uber die Konstruktion eines Baumes an Hypothesenerreicht.

Der Baum dient als Ausgangsbasis fur die dynamischen Erklarungen, da er alle In-formationen uber erfolgreiche und gescheiterte Herleitungen beinhaltet, ahnlich wiebei MYCIN. Des Weiteren wird durch separates Wissen unterstutzt, warum speziel-le Regeln im Vergleich zu einer Alternative bevorzugt wurden, warum Ausnahmenzuruckgewiesen wurden und warum globale Ableitungsstrategien in manchen Fallenerfolgreich sind und in manchen nicht.

Mit dem System kann eine Wissensbasis mit mehreren unterschiedlichen Domanenerstellt werden, bei der jede Domane einen eigenen Hypothesenbaum und ein speziel-les Ziel hat. Die Wurzel eines Baumes reprasentiert hierbei das Ziel der Domane. Zieleines Hypothesenbaumes von ’Rationale’ ist die Diagnostizierung einer Krankheit.Der Hypothesenbaum beinhaltet folglich alle zur Diagnose moglichen Strategien. DieAufteilung des Wissens in unterschiedliche Domanen hat den Vorteil, dass bei derErklarung die verantwortliche Domane nur dann nach einer entsprechenden Hypo-these durchsucht wird, wenn sich der Ableitungsprozess darauf bezieht.

3.3.3 Aufgabenbasierte Erklarungen

Aufgabenbasierte Erklarungen beziehen sich auf Aktionen und Folgerungen des Sys-tems in Bezug auf die Ziele einer Aufgabe (’Problem-Solving-Task’), welche ausge-fuhrt wurde. Im Prinzip bedeutet das Losen einer Aufgabe unterschiedliche Strate-gien (’Problem-Solving-Strategy’), wie in Abschnitt 3.3.2 beschrieben, zu verfolgen.Aufgabenbasierte Erklarungen stellen einen hohren Abstraktionsgrad dar, da dasErklarungssystem in logische Komponenten zerlegt werden kann, welche bestimmteAufgaben losen.

Generische Aufgaben, [Cha93] oder [Tan95], sollen wiederverwendet werden und die-nen als Bausteine fur komplexere Aufgaben [SM93]. In [TM93] wurden ca. 100 Mo-dule, die bei der Problemlosung miteinander kommunizieren, implementiert. DieKomponente, welche eine Entscheidung bezuglich einer Aufgabe trifft, muss dieseerklaren. Damit Erklarungen jedoch koharent bleiben, mussen, so [TM93], Aufgabeund Methode voneinander getrennt werden. Erklarungen sind somit an die Aufgabegekoppelt und unabhangig von der Strategie, mit der die Aufgabe gelost wird. Auf-grund dieser Trennung kann in aufgabenlogische, hierarchische Strukturen unterteiltwerden, aus denen Erklarungen in unterschiedlichen Abstraktionsgraden abgeleitetwerden konnen. Jede Aufgabe tragt somit partiell zur Erklarung des ganzen Systemsbei.

MYCIN, in Abschnitt 3.3.1.1, lost beispielsweise diagnostische Aufgaben mit unter-schiedlichen Methoden (z.B. heuristische Klassifikation), welche wiederum in ver-schiedene Subaufgaben (Datenanalyse oder heuristisches Vergleichen) unterteilbarsind. Im Idealfall konnen die Subaufgaben fur andere diagnostische Aufgaben wie-derverwendet werden.

3.3.4 Rechtfertigung von Wissen

Die wichtige Erkenntnis [Ell89] in Abschnitt 3.3.1, dass Regelpfade das Programm-verhalten exakt beschreiben aber auf der anderen Seite keine Rechtfertigung liefern,


warum bestimmte Regeln in den Losungsweg eingebaut wurden, versuchen die imFolgenden vorgestellten Ansatze zu uberwinden.

Die Integration von zusatzlichem Wissen in Problemlosungssysteme bzw. aufgaben-basierte Systeme, dient als Ausgangsbasis fur die Rechtfertigungen von Losungenoder Rechtfertigung von verwendeten Regeln. Es konnen darauf aufbauend Erkla-rungen generiert werden, die beschreiben, wie Folgerungen bzw. Ableitungen desProblemlosungswissens in Bezug auf das Wissen der Domane erzielt wurden.

Die Rechtfertigung von Schlussfolgerungen schafft letztendlich Vertrauen in das vomSystem abgeleitete Ergebnis und ist deswegen unerlaßlich.

3.3.4.1 XPLAIN

XPLAIN [Swa83], ein medizinisches Expertensystem, war das erste System, wel-ches seine Losungen rechtfertigte. Auch XPLAIN arbeitet auf Basis eines Regelpfa-des und verfolgt Losungsstrategien, wie in Abschnitt 3.3.1 und 3.3.2 beschrieben.Bei XPLAIN [AHO90] wurde zusatzlich Wissen der Domane explizit unterteilt inModell (’Domain Model’ oder auch ’Domain Rationale’) und Prinzipien (’DomainPrinciple’).

Das ’Domain Model’ ist ein beschreibendes Netzwerk aus kausalen Beziehungen wah-rend ’Domain Principles’ vorschreibende Strategien bzw. Regeln fur die Schlussfol-gerung sind. Die Trennung des Wissens erlaubt dem System, Rechtfertigungen furausgefuhrte Regeln zur Verfugung zu stellen, Methoden abstrakter zu formulierenund ’Domain Model’ und ’Domain Principles’ unabhangig voneinander zu modifi-zieren.

In Abbildung 3.3, siehe auch [Swa81], ist die Struktur von XPLAIN dargestellt.’Domain Model’ und ’Domain Principles’ stehen dem ’Program Writer’ zur Verfu-gung, damit dieser das Expertensystem generieren kann. Die ’Refinement Structure’kann als ein vom ’Program Writer’ erzeugter Regelpfad interpretiert werden, welcherverdeutlicht, wie das System entwickelt wurde.

��

��

��

��

��

��

��

��

��

��

��

��

Abbildung 3.3: Architektur Xplain

Die in Tabelle 3.2 dargestellte Strategie einer Diagnose konnte beispielsweise fur einepharmazeutische Behandlung von Entwicklern implementiert worden sein. Systeme,


wie MYCIN, siehe Abschnitt 3.3.1.1, haben kein zusatzliches Wissen bezuglich einerStrategie implementiert. Deshalb sind diese Systeme nicht in der Lage die Art undWeise des Vorgehens nachzuvollziehen, sondern folgern nur anhand der Fakten. EineErklarung, warum beispielsweise die Information aus Schritt 2 (Ist es Meningitis?)wichtig fur die Strategie ist, kann MYCIN deshalb nicht liefern. XPLAIN hingegenkann seine abgeleiteten Schritte uber den ’Language Generator’ rechtfertigen, da esgleichzeitig auf die ’Refinement Structure’ zugreifen kann.

1. Gibt es eine Infektion?

(wenn ja) 2. Ist es Meningitis?

(wenn ja) 3. Ist es bakteriell?

(wenn ja) 4. Ist es diplococcus-pneumoniae?

-> Diagnose A -> Medikament B

Tabelle 3.2: Diagnosevorgang nach bewahrter Strategie

Obwohl XPLAIN gegenuber MYCIN eine Verbesserung darstellt, gibt es zu beman-geln, dass einzelne Prinzipien bzw. Regeln innerhalb der Domane nicht wiederver-wendet werden konnen, da sie einmalig mit einem Teil eines speziellen Problems asso-ziert werden. Des Weiteren kann man XPLAIN nicht auf neue Erklarungen erweitern,da der ’Program Writer’ auf vordefinierte Strukturen angewiesen ist [AHO90].

3.3.4.2 Explainable Expert System (EES)

EES stellt eine Antwort auf die Mangel von XPLAIN dar und ist aufgabenbasiert.EES [AHO90] wurde entworfen mit dem Ziel, dass das System erweiterbar und mo-difizierbar ist und trotzdem Erklarungen generiert, welche anschaulich das Verhaltendes Systems rechtfertigen.

��

��

��

� ��

��

��

� ��

��

!��

!��"��

�� !��#��

$�

Abbildung 3.4: Architektur EES

In EES [SW91], siehe Abbildung 3.4, gibt es in der Wissensbasis Plane, um Problemezu losen bzw. eine Diagnose zu erstellen (’Problem-Solving-Principles’). Jeder Plan


enthalt eine Beschreibung seiner Fahigkeiten und seinen Gebrauch. Wahrend desProzesses der Problemlosung werden Beschreibungen von Aufgaben, welche ausge-fuhrt werden sollen als Ziele formuliert und angefragt. Das System ordnet Plane zu,indem die Ziele mit den Planbeschreibungen verglichen werden. Jeder Plan enthaltweiter eine Strategie, welche durch eine Reihe von Schritten bzw. Regeln festlegt,wie ein Ziel erreicht wird.

In EES wird die Wissensbasis weiter unterteilt in Wissen der Domane (’Descripti-ve Domain Knowledge’), welches angewandt wird, um allgemeine Plane (’Problem-Solving-Principles’) auf ein spezielles Problem abzubilden. Dieses Modell ist hierar-chisch geordnet.

Wissen der Domane wird in Beziehung zu den Problemlosungstrategien gebrachtbzw. miteinander verbunden, um rekonstruieren zu konnen, wie spezifische Aktionenvon allgemeinen Prinzipien abgeleitet worden sind.

Der ’Automated Program Writer’ konstruiert ein ausfuhrbares System aus den unter-schiedlichen Bestandteilen der Wissensbasis. Wahrend der Laufzeit wird das Systemvon einem Interpreter ausgefuhrt, der die Regelpfade auf Anfrage eines Benutzers ge-neriert. Der Erklarungsmechanismus (’Explanation Generator’) kann auf die Regel-pfade und auf das System zugreifen. Wenn unter Ausfuhrung eines Planes Variableneiner Strategie gebunden werden, wird diese Spezialisierung aufgezeichnet und uberden Zugriff auf das System, welches die Information der Wissensbasen beinhaltetkann der Schritt nachvollzogen werden.

EES leitete die speziellen Aktionen von der abstrakten Spezifikation einer Strategieab. Das fuhrte zu einem großeren Grad an Konsistenz im Vergleich zu Systemen, diestatisch Aktionen mit allgemeinen Strategien verketteten [SM93].

Andere Erklarungssysteme, wie in [Gul96] und [DJ97] beschrieben, beziehen sich aufden Ansatz des EES.

3.3.4.3 CoGenTex

Ziel des in [BMR+98] vorgestellten Ansatzes ist es, das Erklarungssystem von derSchlußfolgerungskomponente (’Reasoning’) abzukapseln, so dass es als eigenstandigbetrachtet werden kann. Dies hat den Vorteil, dass bei der Entwicklung von Regelndie Bedingungen fur die Erklarungen nicht in Betracht gezogen werden mussen, wiebei den zuvor betrachteten Ansatzen. Dies erlaubt einen großeren Grad an Wie-derverwendung fur unterschiedliche Domanen. Bei dem Ansatz von [BMR+98] wirdWissen deshalb in drei Bereiche unterteilt:

• Reasoning Domain Knowledge (RDK): Wissen uber die Domane in Formeiner Terminologie, Instanzen und Regeln.

• Communication Domain Knowledge (CDK): Wissen uber die Doma-ne (’Domain Model’), welches nur fur die Kommunikation uber die Domanebenotigt wird, nicht fur Schlussfolgerungen (’Reasoning’). CDK dient haupt-sachlich der Inhaltsselektierung, kann aber auch der Festlegung der relativenWichtigkeit zwischen zwei Objekten der Domane dienen.


• Domain Communication Knowledge (DCK): Wissen, welches festlegt,wie in der Domane kommuniziert wird(z.B. Genre, Horerbedurfnisse oder kul-tureller Kontext). Es hat mit dem Wissen innerhalb der Domane nichts zu tun.Es ist deshalb nicht ausgeschlossen, dass DCK in unterschiedlichen Experten-systemen wiederverwendet werden kann.

Das System folgert im RDK wie gehabt uber Produktionsregeln, um Schlussfolge-rungen zu erzielen. CDK beinhaltet Konzepte der Domane mit ihren zugehorigenAttributen und Relationen (ist-ein, hat-ein usw.). RDK und CDK sind in ihremAufgabenbereich getrennt, uberschneiden sich aber in der Darstellung, da sie beidedie Domane beschreiben.

Da Wissen der Domane alleine nicht ausreicht, um ausdrucksstarke Erklarungen zugenerieren, werden beim CDK Erweiterungen beigefugt, um Aktionen besser selek-tieren und organisieren zu konnen.

• Wichtigkeitsindikator: Die Definiton der relativen Wichtigkeit fur jede Re-lation und jedes Attribut erlaubt dem System, Erklarungen unterschiedlicherLange zu generieren.

• Schlusselattribut: Ein Schlusselattribut identifiziert eine Instanz eines Kon-zeptes (z.B eine ID).

• Wechselseitige Abhangigkeiten: Falle, in denen bestimmte Attribute oderRelationen nur prasentiert werden konnen, falls andere Relationen oder Attri-bute auch prasentiert werden konnen.

• Ordnung zwischen Relationen und Attributen: Legt die Reihenfolge fest,in der Relationen und Attribute prasentiert werden sollen.

• Meta Relationen: Relationen zwischen dem selben Konzept.

Um Erklarungen abzuleiten, wird die CDK-Basis in Abhangigkeit der Schlussfolge-rungskomponente (RDK) instanziert. Als Resultat besitzt die Wissensbasis Instan-zen, Attribute und Variablen gebunden an Werte, die fur Ableitungen einer Losungnotwendig waren. Die instanzierte Wissensbasis wird in [BMR+98] als ’Content Re-presentation Graph’ (CRG) bezeichnet. Der CRG enthalt dann alle Informationen,die fur eine Erklarung notwendig sind. Der CRG dient ausschließlich der Inhaltsbe-stimmung.

Mit DCK erfolgt die Inhaltsorganisation. Fur die Sortierung bzw. Organisation desInhalts eines Textes konnen mehrere Techniken verwendet werden. Eine mogliche,namlich die in [BMR+98] verwendete ’Retorical Structure Theory’ (RST), wird inAbschnitt 3.4.1 vorgestellt.

3.3.4.4 OntoNova

OntoNova [AMO+03] ist ein wissensbasiertes System, welches mit OntoBroker, sieheAbschnitt 2.2, realisiert wurde. Da OntoBroker auch fur die Modellierung in Kapitel


7 verwendet wurde, verdient hier das System besondere Beachtung. Das System istim Rahmen des Projektes ’Project Halo’ entstanden, beantwortet Fragen aus derDomane ’Chemie’ und erklart die Losung.

Bei einer Anfrage an das System wird von OntoBroker ein LogFile der einzelnenabgeleiteten Regeln, auch Beweisbaum genannt, generiert. Das LogFile enthalt allefur eine Losung erfolgreich abgeleiteten instanzierten Regeln. Die Regeln sind in F-Logik dargestellt. Das LogFile dient als Eingabe fur einen zweiten Durchgang, indem in Abhangigkeit der gebundenen Variablen der Regeln spezifische Erklarungengeneriert werden. Diese Prozedur, auch ’Meta-Inferencing’ genannt, hat den Vorteilerneut Ableitungsmechanismen auf das dynamisch generierte Wissen anwenden zukonnen. Fur OntoNova wurde zusatzlich fur den zweiten Schritt eine Wissensbasisnur fur Erklarungen erstellt.

Zur Veranschaulichung ist in Abbildung 3.5 eine Ontologie dargestellt, in der jedePerson, welche ein Dokument bearbeitet, automatisch uber die Regel Experte zumExperten uber das Thema des Dokumentes wird. Da unter den Fakten die Person’Franz’ ein Dokument ’Diplomarbeit’ mit dem Thema ’Ontologien’ bearbeitet, ist erbezuglich dieses Themas auch Experte.

��

��

��

�

�!"#��$��

�

�%�#&��

�

��'%&$�&#�())*��+�,-.�$/"$%��0��()) �!"#��$-.�$�12��$�+�())�%�#&3�

�!"#��$'%&$�.$�4())*��+�,-%&$�%�#&())�%�#&3�

�%�#&'�&#�())*��+�,3�

5�&�6��5�&�6'%&$�&#�7))85�&�6*.�9%:

.�$/"$%��0��7)) .24�#&�;�.$3�

.24�#&�;�.$� �!"#��$� .24�#&�;�.$'%&$�%�#&7))��$�4�<.��-

%&$�.$�47))8/�=��>"�<�� 83�

��$�4�<.��%�#&��$�4�<.��'�&#�7))8��$�4�<.��83�

5��/??2��@A>�!"#��$@A

$%�#&@

2��@'.�$�12��$�+�7))$%�#&@3

B7 2��@��'.�$/"$%��0��7))>�!"#��$@3

&�> >�!"#��$@� �!"#��$'%&$�%�#&7))$%�#&@3

&�> $%�#&@��%�#&�

Abbildung 3.5: Beispiel Ontologie

Tabelle 3.3 zeigt das LogFile ’Explanation’, welches generiert wird, wenn die Ontolo-gie aus Abbildung 3.5 in OntoBroker geladen wird. Das LogFile zeigt die instanzier-ten und zugewiesenen Variablen. Wobei ’a173’ den Korper der Regel darstellt und’a177’ den Kopf und somit die Zuweisung, dass Person ’Franz’ Experte bezuglich desThemas ’Ontologien’ ist.


a177:Instantiation[ofRule->>r10;

dependsOnInstantiation->>{a173};

instantiatedVars->>{i(a,Franz),i(b,Ontologien)}].

a173:Instantiation[ofRule->>Regel Experte;

instantiatedVars->>{i(person1,Franz),i(thema1,Ontologien),

i(dokument1,Diplomarbeit)}].

Tabelle 3.3: LogFile ’Explanation’

In Tabelle 3.4 ist nun eine Regel dargestellt, welche mit den instanzierten Variablenaus Tabelle 3.3 einen Text generiert und ein Pradikat ’explain()’ erzeugt. D.h. diegebundenen Variablen Person und Thema mit den Werten ’Franz’ und ’Ontologien’werden in den Text eingefugt.

Das LogFile und die Regel in Tabelle 3.4 mussen fur das ’Meta-Inferencing’ gleich-zeitig in OntoBroker geladen sein.

FORALL text,i,p1,t1

explain(text)

<- i:Instantiation[ofRule->>Regel Experte;

instantiatedVars->>{i(person1,p1),

i(thema1,t1)}]

and (text is

("Die Person "+p1+" ist Experte in dem Themengebiet "+t1+",

weil diesbeszuglich ein Dokument von ihr verfasst wurde)).

Tabelle 3.4: Metainferencing

Mit der Abfrage aus Tabelle 3.5 kann der generierte Text angezeigt werden.

FORALL text <- explain(text).

Tabelle 3.5: Anfrage

Das System bietet somit die Moglichkeit zusatzliches Wissen fur den zweiten Durch-gang zu integrieren, falls der Beweisbaum nicht genugend Information enthalt, umverstandliche Erklarungen zu erzeugen. Redundanz kann reduziert werden, da unter-schiedliche Losungswege, welche dasselbe Ergebnis haben, durch Vorrangsregeln furdie Erklarungen eliminiert werden konnen. Unterschiedliche Ebenen der Abstraktionkonnen erreicht werden, indem unterschiedlich viel Ableitungsschritte fur Erklarun-gen zusammengefasst werden. Zusammenfassend kann gesagt werden, dass mit dengenannten Moglichkeiten auch ein hoher Grad an Personalisierung fur Erklarungenerreicht wird.


3.4 Inhaltsorganisation

In den besprochenen Systemen unter 3.3.4.2, 3.3.4.1 und 3.3.1.2 waren Inhaltsbe-stimmung und Inhaltsorganisation sehr miteinander verflochten. In vielen weiterendarauf aufbauenden Ansatzen, beispielsweise 3.3.4.3, stehen jedoch die zwei Kom-ponenten in erganzender Beziehung zueinander [Hor92].

Insbesondere haben sich bei vielen Ansatzen zwei Techniken bewahrt, die in diesemKapitel naher erlautert werden sollen. Man muss hierbei jedoch beachten, dass dieAnspruche bei den Ansatzen an die Inhaltsorganisation hoch sind. Der Anspruch er-gibt sich, weil man von unterschiedlichen Dialogstrategien (’Discourse Strategy’) mitdem Benutzer ausgeht, bei dem mehrere Aspekte beachtet werden mussen (Kontext-sensitivitat, Dialogverlauf usw.). Auch wenn der in Kapitel 7 vorgestellte Entwurfdiese Anspruche nicht hat, sind die Ergebnisse fur eine Weiterentwicklung, wie be-reits erwahnt, relevant.

3.4.1 RST

Seine Herkunft, nach [Gul96], hat die Rhetorical Structure Theory (’RST’) aus in-tensiven Studien von naturlich vorkommenden Mustern in Texten. RST ist deskrip-tiv und konstruktiv zugleich. Sie basiert auf der Annahme, dass Texte hierarchischstrukturiert sind und vorkommende kleinste koharente Teile (Nucleus) und even-tuell mehrere erganzende, unterstutzende Teile (Satelliten) besitzen. Nucleus undSatelliten stehen in einer speziellen Beziehung (Relation) zueinander.

In RST wird eine Textstruktur als ein Baum eines instanzierten Schemas dargestellt.Ein Schema legt fest, wie speziell ein Textsegment in andere Segmente zerlegt wird.Es wird uber Relationen definiert. Ein Nucleus ist hierbei, wie bereits erwahnt, daszentrale Segment und besitzt eine Reihe von Satelliten, welche mit dem Nucleusverbunden sind. Es existieren auch Relationen, die in gleichbedeutende Teile zerlegtwerden konnen, siehe Tabelle 3.7. Die Definition einer RST Relation bestimmt, wanndas korrespondierende Schema angewandt wird.

��

��

��

��

��!��"#�� $%&�

$� ��

'()*+(+,-./

0+123(.4/5

67+8.(+,-./9./,(+:,

;<=

><=

?<=><@

Abbildung 3.6: RST

Die Relationen in RST bieten eine abstrakte Sicht fur die Planung von hierarchischenTextstrukturen. RST erlaubt darauf aufbauend einen Mechanismus, der die Text-bausteine nach gewunschten Strategien (’Discourse Strategy’ in [Gul96] oder ’Plan

3.4. Inhaltsorganisation 23

Name der Relation Nucleus Satellite

Background Text, dessen Verstehen Text fur das Verstehenvereinfacht werden soll

Preperation Text, der prasentiert Text, welcher den Leser auf denwerden soll prasentierten Text vorbereitet

Elaboration Basisinformation zusatzliche Information

Tabelle 3.6: Relationen

Name der Relation Textbaustein anderer Textbaustein

Contrast Gesichtspunkt Im Kontrast stehender Gesichtspunkt

Tabelle 3.7: Relationen

Operator‘s’ in [SW91]) zusammensetzt. Diese Strategien legen fest, wie bestimmteThemen erklart werden. Dies erfolgt indem Textbausteinen, zwei oder mehr ergan-zende Bausteine, welche sich rhetorisch daruf beziehen, hinzugefugt werden. Darausergibt sich fur konzeptionelle Modelle der Vorteil, dass naturlich sprachlicher Textzusammengefugt werden kann und somit zusatzlich mehr koharenter Text erzeugtwird. In Abbildung 3.6 ist ein Text der Zeitschrift ’Scientific American’ anhand derRelationen, welche in Tabelle 3.6 und 3.7 beschrieben sind, strukturiert.

Anwendungen, welche mit RST unter anderen Erklarungen organisieren sind [DJ98],[BMR+98] und [Gul96].

3.4.2 Toulmins Argumentationsmodell

In Dialogsystemen, wie [Wic92], [DJ98] und [SM99] wurde Toulmins [S.58] Argumen-tationsmodell umgesetzt, um eine bessere Strukturierung zu erhalten, weiterfuhrendeFragen besser zu beantworten und detailliertere Erklarungen liefern zu konnen.

Die Struktur eines Arguments nach Toulmin unterscheidet zwischen Behauptungen(’claim’), Standpunkten (’ground’), Rechtfertigungen (’warrants’), Unterstutzungen(’backings’), Qualifizierungen (’qualifier’) und Widerlegungen (’rebuttals’).

Wird eine Behauptung selektiert, soll sie durch unterschiedliche Standpunkte unter-stutzt werden. Ein Standpunkt sollte eine Basis schaffen, um die Behauptung fureinen Benutzer akzeptabel zu machen. Falls ein Benutzer bezuglich des Argumentsmit Standpunkten alleine nicht zu uberzeugen ist, werden Rechtfertigungen benutzt.Rechtfertigungen erklaren die Beziehung zwischen Standpunkt und Behauptung underlautern somit die Relevanz eines Standpunktes bezuglich der Behauptung. DesWeiteren besteht die Moglichkeit durch Unterstutzung (’backing’) die Zuverlassig-keit und Relevanz einer Rechtfertigung zu beschreiben. Dies geschieht meist mitRegeln auf hoherer Ebene als Rechtfertigungen. Eine Qualifizierung in Form einerPhrase (’wahrscheinlich’ oder ’ziemlich sicher’) druckt die Uberzeugung aus mit derdie Behauptung unterstutzt wird. Widerlegungen beschreiben Umstande unter de-nen eine Behauptung nicht gilt, also Ausnahmen oder Anomalien.

Die Begriffe dienen als Raster unter denen der selektierte Inhalt geordnet wird. In[SM99] wird beispielsweise bei den Erklarungsstrategien zwischen Meta-Argument


und konkretem Argument unterschieden. Hierbei stellt ein Meta-Argument, sieheAbbildung 3.7, eine bestimmte Klasse von Argumenten dar. Ein konkretes Argu-ment ist eine Instanz einer dieser Klassen. Es wird Wissen uber die Kriterien undder Schlussfolgerung eingelesen und daraus eine Eignung des Argumenttypus abge-leitet. Im Beispiel wird untersucht, ob bezuglich eines erhohten Anteils an Blutplatt-chen Krankheiten am Patienten festgestellt werden konnen. Fur die Rechtfertigungdes Kriteriums ’Hoher Blutplattchenanteil’ konnen alle Bestandteile des Argumentsverwendet werden.

��

��

�� !"��"��#"��

$%&'()(*+,��"�

��"��

�*-%..&'/" 0�1#"��2�"��

�*3&%4.%56�"��

��1#��"��

�7��8�9��

��/2" � ��8�9�� :;<=>>>?

00@#"��AB�� "��

��8�9�� "��B<>=>>>?00@

$%&'()(*+�" ��

�*-%..&'��8�9�� "�7!�B

�� C��D:#"�� 2�"��

�*3&%4.%56�"��

EFGHIJKLMNFOG JKLMNFOG

Abbildung 3.7: Argument

4. Recommender Systeme imE-Commerce

E-Commerce erlaubt Firmen ihren Kunden eine individuellere Produktpalette anzu-bieten. Allerdings nimmt damit auch die Information zu, die ein Kunde zu verarbei-ten hat, bis er eine Kaufentscheidung treffen kann, welche ideal seinen Bedurfnissenentspricht [SKR99]. Recommender Systeme, siehe [Bur02], sind hierbei Systeme, dieindividuelle Empfehlungen produzieren oder Benutzer in einer personalisierten Artund Weise an mogliche, interessante oder nutzliche Objekte aus einer großen Aus-wahl von Objekten heranfuhren.

Systeme, wie Suchmaschinen oder Systeme zur Wiedergewinnung von Wissen (’Infor-mation Retrieval Systems’), unterscheiden sich davon, da sie keine Personalisierungbesitzen. Nach [SKR99] generieren diese Systeme Empfehlungen (’non-personalized’),welche fur alle Benutzer gleich sind.

4.1 Techniken

Entscheidend fur die Klassifizierung der Techniken bei Recommender Systemen istdie Quelle der Daten, auf denen die Empfehlung beruht und wie diese Daten zurGenerierung einer Empfehlung verwendet worden sind. Nach [Bur02] werden Datenunterschieden, welche vor dem Empfehlungsprozess vorhanden sind (’BackgroundData’) und Daten, die die Praferenzen des Benutzers widerspiegeln (’Input’). Weiterunterscheidet [Bur02] einen Algorithmus, welcher die Daten miteinander verbindet,um eine Empfehlung zu erzeugen.

Die wichtigsten Techniken, nach [Bur02], sind inhaltsbasierte Empfehlungen (’Content-Based’), Empfehlungen basierend auf einer Zusammenarbeit (’Collaborative’), nut-zenbasierte Empfehlungen (’Utility-Based’), demographische Empfehlungen (’Demografic-Based’) und wissensbasierte Empfehlungen (’Knowledge-Based’), siehe Tabelle 4.1.

In Tabelle 4.1 sind Background Daten und Input je Technik dargestellt. Hierbei istI die Menge aller Objekte (’Item’), uber welche Empfehlungen gegeben werden. U

26 4. Recommender Systeme im E-Commerce

ist die Menge aller Benutzer (’User’), deren Praferenzen bekannt sind. Weiter ist uder Benutzer, fur welchen die Empfehlung generiert wird.

Technik Background Data Input

Collaborative Bewertungen aus U von Objekten Bewertung von u vonaus I Objekten aus I

Content-Based Eigenschaften von Objekten Bewertung von u vonaus I Objekten aus I

Demografic-Based Demographische Information Demographische Informationuber U und ihre uber uBewertungen von Objekten aus I

Utility-Based Eigenschaften von Objekten aus I Eine Nutzenfunktion uberdie Objekte aus I, welchePraferenzen von u beschreibt

Knwoledge-Based Eigenschaften von Objekten aus I. Beschreibung der InteressenWissen wie diese Objekte mit und Bedurfnisse von uden Bedurfnissen einesBenuzters ubereinstimmen

Tabelle 4.1: Techniken

Collaborative Recommender Systeme erkennen Ahnlichkeiten zwischen Benutzern,indem sie Bewertungen von Objekten miteinander vergleichen, die von den Benut-zern erstellt wurden. Bei Ahnlichkeiten schließt das System auf ubereinstimmendeInteressen und kann Empfehlungen uber Objekte erstellen, welche einem Benutzernoch nicht bekannt sind. Diese Technik, siehe [SKR99], wird auch als ’People toPeople’ (Mensch zu Mensch) Korrelation bezeichnet.

Demographische Recommender Systeme kategorisieren den Benutzer anhand vonpersonlichen Attributen und generieren Empfehlungen mittels demographischer Klas-sen.

Content-Based Recommender Systeme erlernen Profile der Interessen eines Benut-zers auf Basis der Eigenschaften von Objekten, welche der Benutzer bewertet hat.Anhand des Profiles werden fur den Benutzer Empfehlungen generiert. Diese Tech-nik, siehe [SKR99], wird auch als ’Item to Item’ (Objekt zu Objekt) Korrelationbezeichnet.

Utility-based Recommender Systeme berechnen den Nutzen, den jedes Objekt fureinen Benutzer hat und empfehlen die Objekte mit dem großten Nutzen.

Knowledge-Based Recommender Systeme versuchen Empfehlungen zu generieren,indem sie bezuglich der Praferenzen und Bedurfnisse eines Benutzers geeignete Ob-jekte folgern. Der Unterschied zu anderen Recommender Systemen ist, dass sie funk-tionales Wissen daruber beinhalten, wie bestimmte Objekte mit bestimmten Bedurf-nissen von Benutzern ubereinstimmen.

Das System der Mentasys GmbH ist Utility- und Knowledge-Based und liefert dar-uberhinaus fur seine Entscheidungen Erklarungen, wie in Kapitel 3 beschrieben.

4.2. Benutzeroberflache 27

4.2 Benutzeroberflache

Die Benutzeroberflache legt fest, wie Empfehlungen prasentiert werden, d.h. mitwelchen verkaufsfordernden Maßnahmen ein Benutzer uberzeugt werden soll. In[SKR99] wird zwischen Navigation (’Browsing’), Empfehlungen von ahnlichen Pro-dukten (’Similar- Item’), elektronischer Post (’Email’), Kommentaren von anderenBenutzern (’Text Comments’) zu einem Produkt, nummerischen Bewertung von an-deren Benutzern (’Average Rating’) zu einem Produkt oder einer Liste der n bestenProdukte (’Top-N’) unterschieden.

28 4. Recommender Systeme im E-Commerce

5. Analyse des Systems

Dieses Kapitel beschreibt die Funktionsweise und Architektur des RecommenderSystems der Mentasys GmbH.

5.1 Funktionsweise des Recommender Systems der

Mentasys GmbH

Das System ist, wie bereits erwahnt nutzenbasiert und unterstutzt den Benutzer imFinden angemessener Eintrage im Produktkatalog, indem uberpruft wird, wie gutdie Katalogeintrage mit den Interessen des Benutzers ubereinstimmen. Daruberhin-aus rechtfertigt das System seine Entscheidung und versucht eine verkaufsforderndeBeratung zu erteilen, siehe Kapitel 6.

Das System weist Ahnlichkeiten zu ’Analytical Process Hierarchy’ (AHP) auf, einerMulti-Kriterium Entscheidungsmethode [T.L80]. Logisch zueinander stehende At-tribute konnen zu einem abstrakteren Uberbegriff verbunden und hierarchisch zueinem Baum geordnet werden. In Abbildung 5.1 sind beispielsweise ’Nummernspei-cher’ und ’Display’ zu einer Eigenschaft ’Telefon’ zusammengefuhrt, welche nichtdirekt am Gerat messbar ist.

Alle Knoten, auch Aspekte genannt, bekommen gemaß ihrer Relevanz fur den Be-nutzer Kantengewichte zugeordnet. Die ’Ratingaspekte’ bekommen zusatzlich nochParameter ubergeben, um eine Produktbewertung zu ermoglichen. In Abbildung 5.1sind Ratingaspekte die Blatter des Baumes (’Nummernspeicher’, ’Display’, ’Preis’,’Wap’ und ’Java’), welche mit einer vertikalen Linie dargestellt sind. Die Gewichtebzw. Parameter hangen von den Praferenzen des Benutzers ab.

’Questionaspekte’ (horizontalen Linie), in Abbildung 5.1 die Knoten ’Telefon’, ’Preis’und ’Internet’, stellen die Schnittstelle zum Benutzer dar. Der Benutzer außert sei-ne Praferenz, indem er ein qualitatives Merkmal bezuglich des Aspektes angibt(auch ’Aggregationswert’ genannt), wie beispielsweise ’Hoch’, ’Mittel’ und ’Egal’beim Aspekt ’Internet’.

30 5. Analyse des Systems

Der Modellierer des Empfehlungssystems muss fur alle Aspekte festlegen, welchesKantengewicht bzw. welcher Parameter bei einem Aggregationswert gesetzt wird.Bei Aspekten, welche keine Schnittstelle zum Benutzer haben, muss der Konstruk-teur festlegen, welche Aggregationswerte in Abhangigkeit des gesetzten Aggrega-tionswertes des Vorgangers gesetzt werden. Das Beispiel zeigt, welche Praferenzender Benutzer hat, indem die Aggregationswerte bzw. qualitativen Merkmale aller’Questionaspekte’ mit einem schwarzen Punkt versehen sind. Daraus ergibt sichdie Kantenbelegung der Aspekte ’Telefon’, ’Internet’ und ’Preis’. Da der Aspekt’Preis’ ebenfalls Ratingaspekt ist, wird ihm zusatzlich noch ein Parameter uberge-ben. Die Aggregationswerte der restlichen Aspekte werden in Abhangigkeit der Ag-gregationswerte ihrer Vorganger gesetzt. Hier hat der Benutzer keinen Einfluß mehrauf die Konfiguration des Systems. Im Beispiel wurde festgelegt, dass die Aspekte’Nummernspeicher’ den Aggregationswert ’Hoch’ und ’Display’ den Aggregations-wert ’Mittel’ bekommen, falls der Aspekt ’Telefon’ auf ’Hoch’ gesetzt ist. Darausergibt sich dann im Folgenden die in den gestrichelten Rechtecken gesetzte Kanten-und Parameterbelegung.

D.h. uber das Setzen der Aggregationswerte in den ’Questionaspekten’ vom Benut-zer wird der Baum vollstandig konfiguriert, da fur alle Nachfolger im Baum desModellierers die Konsequenzen festgelegt sind.

��

��

�� !"#$$%

&��'��!(�)*%

+�,�!-�%

.��!-�%

$/0 $

/1

$/1

$/2

$/2 $

/3

4�5�6785��

6785��9�

��

6785��9�

��

:��

;��!<2=$%

6785��>?@��

$/1

�� 9?�A��

��?BA��

:�� ?A��

��9��7C�

D�'�E)� F�G��G

Abbildung 5.1: Kriterienbaum

Der nachste Prozess, auch Bewertung (’Rating’) genannt, erfolgt uber die ’Ratin-gaspekte’ (vertikale Linie). Jeder Ratingaspekt benutzt eine Funktion, um eine Be-wertung vornehmen zu konnen, siehe Abbildung 5.2. Diese Funktion bekommt alsEingabe spezifische Parameter und Produktattributwerte ubergeben.

��

��

� ��

��

��

��

�!��"��

�

�

Abbildung 5.2: Ratingfunktion

Im Produktkatalog ist festgelegt, welche Attributwerte jedes einzelne Gerat besitzt,siehe Tabelle 5.1.

5.1. Funktionsweise des Recommender Systems der Mentasys GmbH 31

Eigenschaften/Handy Siemens c55 Nokia 7210

Nummernspeicher 160 99Display klein großPreis 300 150Java Ja NeinWap Nein Ja

Tabelle 5.1: Produktkatalog

In Tabelle 5.2 wird die Bewertung fur die Produkte aus Abbildung 5.1 vorgenommen.Der Einfachheit wegen sind die Funktionen so ausgewahlt, dass sie nur bestimmen,ob ein Produkt ein Kriterium bezuglich eines Parameters erfullt.

Rating Siemens c55 Nokia 7210

Nummernspeicher Nummernspeicher(160)=1 Nummernspeicher(99)=0Display Display(klein)=0 Display(groß)=1Preis Preis(300)=0 Preis(150)=1Java Java(Ja)=1 Java(Nein)=0Wap Wap(Nein)=0 Wap(Ja)=1

Tabelle 5.2: Rating

Der nachste Prozess wird Aggregation genannt. Alle Aspekte (’Aggregationaspekte’),welche Nachfolger besitzen, aggregieren uber diese. Aggregation bedeutet hier, dassdas Produkt aus Ergebnis und Gewicht der Nachfolger aufsummiert wird (sieheTabelle 5.3). Auch hier konnen beliebig andere Funktionen gewahlt werden.

Diese Theorie wird auch als ’Multi-Attribut-Utility-Theory’ bezeichnet (MAUT)[SC02]. MAUT ist eine normative Methode fur die Evaluierung von Attributen,welche zueinander im Wettbewerb stehen. Beurteilungsfunktionen und die relativeWichtigkeit legen fest, wie hoch der Nutzen eines einzelnen Attributes ist. Fur dieErrechnung des Gesamtnutzens eines Produktes werden alle Attribute mittels einerbeliebigen Funktion aggregiert.

Aggregation Siemens c55 Nokia 7210

Telefon 0.6*1+0.4*0=0.6 0.6*0+0.4*1=0.4Internet 0.5*1+0.5*0=0.5 0.5*0+0.5*1=0.5Kauf 0.4*0.6+0.4*0+0.3*0.5=0.39 0.4*0.4+0.4*1+0.3*0.5=0.71

Tabelle 5.3: Aggregation mittels gewichteter Summe

Den hochsten Gesamtnutzen, der sich in der Wurzel des Baumes gemaß der Prafe-renzen des Benutzers außert, hat im Beispiel das Handy von Nokia. Die Wurzel wirdauch als ’Scenarioaspekt’ bezeichnet.

Der nachste Prozess sorgt fur die Begrundung der empfohlenen Gerate. Das Sys-tem soll hierbei den Benutzer in dem Sinn unterstutzen, dass es die konventionelle


Beratung eines menschlichen Verkaufer ersetzt. Beispielsweise hat das Gerat von No-kia den besseren Preis und auch den hoheren errechneten Gesamtnutzen, aber dasGerat von Siemens bietet die besseren Telefonfunktionalitaten, siehe Tabelle 5.3.Das System muss dem Benutzer individuell erlautern konnen, welche Unterschiededie einzelnen Gerate aufweisen und hierbei eine Entscheidungsfindung herbeifuh-ren. Der Beratungsprozess bwz. Kaufprozess ist iterativ, da Praferenzen verandertwerden konnen und wird in Kapitel 6 genauer erlautert.

Ausgangsbasis fur die bisherige Beratung des Systems sind fur alle Aspekte, dieberechneten Nutzenwerte und die gesetzten Aggregationswerte. Allen berechnetenNutzenwerte wird eine Fitnessklasse (’erfullt’,’ubererfullt’ oder ’nicht erfullt’) uberdie Zugehorigkeit von festgelegten Intervallen zugeordnet. Uber das Zusammenspielvon Fitnessklassen und Aggregationswerten kann das System beispielsweise die Eig-nung von Aspekten gemaß der Praferenzen, Konflikte unterschiedlicher Aspekte oderVergleiche unterschiedlicher Gerate pro Aspekt erklaren, siehe Abbildung 5.3.

��

��

��

��

��

�� !��

��

"��

Abbildung 5.3: Begrundungen

5.2 Architektur des Systems

In Abbildung 5.4 ist die Architektur des Systemes dargestellt. Der Modellierer desEmpfehlungssystems legt in der Datenbasis mit XML-Dateien alle Informationenfest. Dazu gehoren die Struktur des Baumes in Form von Scenario-, Question-,Aggregation- und Ratingaspekten (siehe vorhergehenden Abschnitt 5.1), die Attri-butwerte der einzelnen Produkte und die Parameter und Kantengewichte, die gemaßaller moglichen Praferenzen des Benutzers gesetzt werden konnen. Des Weiteren wer-den fur jeden Aspekt Bedingungen in Form von Fitness- und Aggregationswertenfur korrespondierende Begrundungen beschrieben.

Die Klassen des Package ’Mentasys.compiler’ instanzieren aus der XML-Datenbasisunzusammenhangend alle moglichen Knoten (Question-, Aggregation- und Ratin-gaspekte), Begrundungen und Produkteintrage, die dem Kernsystem im Folgendenzur Verfugung stehen.

5.2. Architektur des Systems 33

Uber die Webapplikation (’Mentasys.webapplication’) erfolgt die Benutzereingabeund das instanzieren der Klassen ’Mentasys.core.question’ und ’Mentasys.core.profile’.Uber die Verknupfung der Schnittstellendefinitionen der ’Mentasys.core.profile’ Klas-sen und der generierten Instanzen des ’Mentasys.compiler’ wird die Struktur desBaumes erstellt und dieser initialisiert. Eine Validierung erfolgt bei der Initialisie-rung.

Die Klassen ’Mentasys.rating’, ’Mentasys.aggregation’ und ’Mentasys.reasoning’ set-zen fur jedes Produkt, die in Abschnitt 5.1 beschriebenen Prozesse um, siehe auchdie Abschnitte 7.5, 7.6 und 7.8.1 in Bezug auf die Realisierung mit einer Ontologie.Der ’Mentasys.recommender’ sorgt schließlich fur die Prasentation der Ergebnisse.

��

��

��

��

��

��

��

Abbildung 5.4: Architektur

6. Analyse des Kaufprozesses

Wahrend in Abschnitt 5.1 beschrieben wurde, wie das System der Firma Menta-sys kundenspezifisch filtert, erlautert dieses Kapitel die wichtigsten Prozesse einerkundenspezifischen Beratung der Mentasys GmbH.

Wie in Kapitel 5.1 gesagt, begrundet das System die Wahl der empfohlenen Pro-dukte. Das System soll, wie ein echter Verkaufer, uber einen Beratungsprozess denBenutzer zu einer Kaufentscheidung fuhren.

Die relevanten Produkte werden uber ihre Eigenschaften (Fakten) gefiltert. Im Ge-gensatz dazu kann das Beraten ein emotionaler Prozess sein, bei dem der Kundenty-pus eine Rolle spielt. Dieser Prozess ist iterativ, da das System auf Aktionen (Fragenbeispielsweise bezuglich Eignung des Produktes, Vergleiche zu anderen Produktenoder Einwande) des Benutzers individuell reagieren sollte, siehe Abbildung 6.1.

��

��

��

��

� ��!�� "#�� $%��

&��'��

()*��+),��

�� ,�-

.��/0�1 2 /"#�/ 3 ��43��5

.��/0�1 2 /"#�/&��

Abbildung 6.1: Begrundungen

Unter anderem ist es Ziel dieser Arbeit zu untersuchen, ob der Beratungsprozessmittels Ontologien fur den Benutzer vielfaltiger und individueller gestaltet werdenkann.

36 6. Analyse des Kaufprozesses

Der komplette Ablauf einer Beratungs-Session ist in Abbildung 6.2 dargestellt. DerKern des Beratungsprozesses umfasst die Phasen 3 und 4. Die Phasen 5 bis 6 sindletztendlich verkaufsfordernde Maßnahmen, welche sich auf den Beratungsprozessbeziehen. In dem in Kapitel 7 vorgestellten Entwurf sind nur Begrundungen derPhasen 3 und 4 realisiert worden. Jedoch sind die Vorraussetzungen fur eine Reali-sierung der Phasen 5 und 6 gegeben. Bedingung fur einen guten Beratungsprozessist eine moglichst genaue Erfassung der Kundenbedurfnisse in Phase 2. Dies wird inder Schnittstelle zum Benutzer realisiert, wie bereits erwahnt in Abschnitt 5.1, uberdie Unterscheidung qualitativer Merkmale bezuglich eines Aspektes.

��

��

� �

��

��

��

��

��

��

��

��

��

��

Abbildung 6.2: Kaufprozess

6.1 Produktprasentation und Nutzenargumenta-

tion

Produkte mussen als Losung des Kundenproblems prasentiert werden. Bei der Nut-zenargumentation soll sich der Berater nur noch ausschliesslich auf die zuvor erfass-ten Schlusselkriterien konzentrieren. Grundsatzlich sollten folgende Schritte einge-halten werden: ’Prasentation’,’Erklaren’ und ’Fragen beantworten’.

Bei der Prasentation und beim Erklaren ware es ideal einen stufenartigen Argumen-tationsprozess einzuhalten, welcher in Abhangigkeit des identifizierten Personlich-keitstypen Produkte erlautert. Dem Kunden werden Produktmerkmale (Aspekte)prasentiert, beispielsweise ’Wap’. Damit kann ein Produktnutzen, wie der Zugangzum Internet, aufgezeigt werden. Mit dem Produktnutzen lasst sich ein Kundennut-zen ableiten, beispielsweise fur einen Benutzer, welcher hohe Anspruche bezuglich’Businessfunktionalitaten’ hat (z.B. ’Sie haben somit jederzeit die Moglichkeit Bor-sendaten abzufragen’). Jedes Produkt hat Schwachen und diese sollten nach Moglich-keit dargestellt werden, wenn sie gemaß den Praferenzen eines Benutzers keine Rollespielen. Des Weiteren sollte der Benutzer jederzeit die Moglichkeit haben Antwortenzu bekommen (Detailinformationen, Hersteller, Qualitat, Leistungsfahigkeit in Be-zug auf das Kundenbedurfnis, Nutzung und Bedienung des Produktes, Liefer- undKaufbedingungen), welche dem System erlauben konnten, die Relevanz bestimmterAspekte zu unterscheiden.

Das Beratungssystem sollte eine lange Liste von Produkteigenschaften, Produkt-nutzen, Kundennutzen und weitergehenden Detailinformationen aufnehmen. Diesermoglicht dem System im jeweiligen Kundenfall optimal zu argumentieren. In Ta-belle 6.1 sind mogliche Argumentationen bei einer Kaufberatung in Abhangigkeitdes Personlichkeitstypen dargestellt.

6.2. Einwandbehandlung und Vertiefung des Kundenverstandnisses 37

Personlichkeitstyp Eigenschaften Argumentation

Analytiker Perfektionist, detailinteressiert, sachlicher Vergleichwunscht Kontrolle der Entscheidung der Produkteigenschaften

Beziehungsmensch sucht Anerkennung, emotionale Argumentewunscht Bestatigung

Direktor Pragmatiker, zielorientiert, Anwendungsfallwunscht ein Ergebnis abdecken

Socializer ’ich-bezogen’, Status emotionale Nutzen-steht im Vordergrund argumentation

Tabelle 6.1: Personlichkeitstypen

6.2 Einwandbehandlung und Vertiefung des Kun-

denverstandnisses

Einwande konnen gruppiert werden und es sollten jeweils fertige Antworten paratstehen. Einwande sind als Chance zu sehen, noch mehr uber das eigentliche Kun-denbedurfnis zu erfahren. Das bedeutet, dass Einwande eine implizite Bitte nachmehr Informationen sind und ein erster Schritt des Kunden zu einer tatsachlichenKaufabsicht. Die Behandlung von Einwanden ist ein notwendiger Schritt, um denKunden in seiner Uberzeugung zu starken, das richtige Produkt fur sich gefundenzu haben.

Unterschiedliche Kategorien von Einwanden waren beispielsweise Preis, Leistung,Anwendungsbreite, Bedienbarkeit bzw. Bequemlichkeit, Kundenservice, Qualitat unddie Suche nach Alternativen.

Der Kunde muss die Moglickeit haben, Einwande geltend zu machen. Dem Einwandwird optimal begegnet, wenn der Berater sich zunachst erklaren lasst, was das ei-gentliche Problem ist (z.B. ’Haben Sie Bedenken bei der Qualitat?’, ’Welche Bereichesprechen Sie damit genau an?’). Nach einer Analyse kann gezielt geantwortet werden.Eine Strategie konnte hierbei sein, dass dem Einwand zunachst zugestimmt wird, umdann zu verdeutlichen, dass objektiv in Relation zu den anderen Alternativen derEinwand nicht zutrifft (z.B. ’Das Produkt gehort zu der obersten Preisklasse. Indieser Klasse verfugt es uber das beste Preis-Leistungsverhaltnis’).

Entweder lasst sich ein Einwand mit Zusatzinformationen zum Produkt objektiventkraften, d.h dem Einwand wird eine neue positive Bedeutung gegeben (z.B. ’DasProdukt hat die besten Funktionalitaten des Produktkataloges bezuglich Internet’)oder dem Kunden wird Recht (z.B. ’Leider ist das Produkt sehr teuer’) gegeben.In diesem Fall werden ihm Alternativen mit den jeweiligen Folgen aufgezeigt. Einemoglich Folge konnte die Abnahme des Nutzens bei Produkten sein (z.B. schlechtereInternetfunktionalitaten), die billiger sind.

Unter Umstanden macht es Sinn bereits im Voraus diese Einwande aktiv zu prasen-tieren und zu entkraften, bevor sie vom Kunden eingebracht werden konnen.

38 6. Analyse des Kaufprozesses

7. Entwurf der Ontologie

In diesem Kapitel wird das in Kapitel 5 vorgestellte Modell des Recommender Sys-tems der Firma Mentasys mittels einer Ontologie modelliert.

Bei der Modellierung wurde zum einen besonderen Wert darauf gelegt, Teile der On-tologie moglichst abstrakt zu formulieren, damit diese Produktdomanen unabhangigwiederverwendet werden konnen. Die Axiome sollen einen hohen Grad an Wieder-verwendung bekommen, so dass die Konstruktion eines Standartsystems nur durcheinen Produktexperten effizient realisiert werden kann. Zusatzlich sollen Anpassun-gen an spezielle Produkte moglich sein, ohne das Basissystem zu verandern, indemein Experte mit Frame-Logik die Moglichkeit hat zusatzliche Axiome zu implemen-tieren. Zum anderen soll das Modell als Grundlage fur eine Verbesserung derbenotigten Erklarungen zur Unterstutzung des in Kapitel 6 vorgestellten Kaufpro-zesses dienen.

Die Ontologie gliedert sich in Produktraum, Bedurfnisraum und Begrundungsraum.Jeder dieser Raume beinhaltet einen abstrakten Teil, welcher fur alle RecommenderSysteme das Basissystem darstellt. Der produktspezifische Teil, wie in der Reali-sierung eines Handyberaters in Abschnitt 7.9 vorgestellt, ist die Instanzierung derOntologie.

7.1 Der Produktraum

Der Produktraum soll die Eigenschaften eines Produktes uber die Attribute prasen-tieren. Die abstrakte Konzepthierachie beinhaltet die in Tabelle 7.1 dargestelltenBestandteile:

40 7. Entwurf der Ontologie

OBJECT[]PRODUCT SPACE ELEMENT::OBJECT

PRODUCT::PRODUCT SPACE ELEMENTPRODUCT ATTRIBUTE TYPE ::PRODUCT SPACE ELEMENTATTRIBUTE::PRODUCT SPACE ELEMENT

Tabelle 7.1: Der Produktraum

Das Konzept PRODUCT, siehe Tabelle 7.2, besitzt Relationen zur Identifikationund fur die Festlegung der Attribute.

PRODUCTRelation Datentyp Erlauterung

hasProductID String IdentifikatorhasAttribute ATTRIBUTE Attribut eines Produktes

Tabelle 7.2: Das Konzept PRODUCT

Jede Instanz des Konzeptes ATTRIBUTE besitzt einen Ratingaspekt, damit be-stimmt werden kann, welcher Aspekt des Produktes bewertet wird. DieModellierung des Konzeptes RATING ASPECT wird in Abschnitt 7.2 naher erklart.Der eigentliche Wert des Produktattributes kann als String, Double oder als eigensdefinierter Attributtyp mit den jeweiligen Relationen ’hasValueString’,’hasDoubleString’und ’hasValueType’ festgelegt werden.

ATTRIBUTERelation Datentyp Erlauterung

hasValueString String Attributwert vom Typ StringhasValueDouble Double Attributwert vom Typ DoublehasValueType PRODUCT ATTRIBUTE TYPE Attributwert eines komplexeren TypshasRatingAspect RATING ASPECT korrespondierender Ratingaspekt

Tabelle 7.3: Das Konzept ATTRIBUTE

In Tabelle 7.4 ist eine elegantere Variante dargestellt. In diesem Fall wird uber dieRelation ’hasAttribute’ der jeweilige Ratingaspekt als Identifikator modelliert. InFrame-Logik ist diese Modellierung moglich, siehe Abbildung 7.1. Unter OntoEditwird diese Art der Modellierung uber eine grafische Benutzeroberflache noch nichtunterstutzt. Diese ist jedoch in Planung. Diese Variante hatte den Vorteil, dass dasKonzept ATTRIBUTE uberflussig ware und nicht fur alle Attributwerte eine Instanzerzeugt werden muss. Fur ein Produktivsystem wird diese Modellierungsmoglichkeituber die Benutzeroberflache sogar als zwingend notwendig angesehen, da fur einumfangreiches System die Instanzierung aller Attributwerte zu aufwendig ware. DieModellierung des Handyberaters in Abschnitt 7.9 ist ein uberschaubares System,deshalb kann die Instanzierung aller Attributwerte in Kauf genommen werden.

7.2. Der Bedurfnisraum 41

Der Vorteil der realisierten Modellierung ist, dass Systeme fur unterschiedliche Pro-dukte komplett uber die Benutzeroberflache realisiert werden konnen und somitkeine Kenntnisse in Frame-Logik erforderlich sind.

Bei einer Realisierung der alternativen Modellierung uber die Benutzeroberflachemussten die Axiome in Abschnitt 7.5 angepasst werden.

PRODUCTRelation Datentyp Erlauterung

hasAttributeDouble(RATING ASPECT) Double Attribut vom Typ DoublehasAttributeString(RATING ASPECT) String Attribut vom Typ StringhasAttributeType(RATING ASPECT) PRODUCT ATTRIBUTE TYPE Attribut eines komplexeren Typs

Tabelle 7.4: Alternative Modellierung

�� !�� "#$

%&'()) *)+(,-.+/0(

�� !��1��"#$

�� 23� 4��5�� !�6��#$

��!��1��"�� 23� 4��5�� "�� !�6��!��#$

�� 2718��4� $

��!�� 2718��4� $

�� 2718��4� $

��!�� 2718��4� $

Abbildung 7.1: Modellierung der Alternative in F-Logik

Schließlich beinhaltet der Produktraum das Konzept PRODUCT ATTRIBUTE TYPE,welches die Festlegung aller komplexen Attributwerte erlaubt.

PRODUCT ATTRIBUTE TYPERelation Datentyp Erlauterung

hasValue String Wert fur den komplexen Typ

Tabelle 7.5: Das Konzept PRODUCT ATTRIBUT TYPE

7.2 Der BedurfnisraumIm Bedurfnisraum ist die strukturelle Definition, die Konfiguration und die Bewer-tung der Produkte fur ein spezifisches Recommender System beschrieben. Der Mo-dellierer eines Systems legt die Struktur uber die in Abschnitt 7.2.1 beschriebenenAspekte fest, so dass ein Kriterienbaum, wie in Abschnitt 5.1 dargestellt, entsteht.Weiter werden alle Konfigurationen gemaß den moglichen Eingabewerten an Be-durfnissen eines Benutzers uber das in Abschnitt 7.2.2 erlauterte Konzept CASEfestgelegt. Uber Ratingfunktionen und Aggregationsfunktionen wird fur alle Aspek-te bezuglich eines Produktes ein Ruckgabewert berechnet, siehe Abschnitt 5.1. DieserRuckgabewert lasst sich in Klassen einteilen, welche die Eignung des Aspektes bezug-lich der Praferenzen widerspiegeln. Dies erfolgt uber das Konzept FITNESS CLASS,siehe Abschnitt 7.2.3.


OBJECT[]NEED SPACE ELEMENT::OBJECT

ASPECT::NEED SPACE ELEMENTQUESTION ASPECT::ASPECTAGGREGATION ASPECT::ASPECTRATING ASPECT::ASPECTSCENARIO ASPECT::ASPECT

FITNESS CLASS::NEED SPACE ELEMENTCASE::NEED SPACE ELEMENT

Tabelle 7.6: Der Bedurfnisraum

7.2.1 Aspekte

Ein Aspekt ist bildlich gesehen ein Element einer Baumstruktur. Mit der Definitionder Unterkonzepte QUESTION ASPECT, AGGREGATION ASPECT,RATING ASPECT und SCENARIO ASPECT und ihren spezifischen Eigenschaf-ten, ist durch deren Instanzen die Position des Aspektes im Baum eindeutig be-stimmt. Aspekte besitzen die in Tabelle 7.7 dargestellten Relationen. Der Namedient der Identifikation. Das Gewicht eines Aspektes wird uber gesetzte Praferenzenzugeordnet. Es beschreibt die relative Wichtigkeit zu anderen Aspekten in Bezug aufeinen ubergeordneten Aspekt. Der Zahler, welcher anzeigt, wie viele Unteraspekteder Aspekt besitzt, wird von der Aggregationfunktion benutzt, um das gewichte-te Mittel zu berechnen. Fur das Begrunden, siehe Abschnitt 7.3 ist wichtig, wel-che Prioritat der Aspekt hat, damit bei der Zusammenstellung einer Begrundungnur die wichtigsten Aspekte ausgewahlt werden. In der Regel konnen aufgrund derUbersichtlichkeit einer Begrundung nicht alle Aspekte berucksichtigt werden. DieRelation ’hasWinnerProduct’ dient fur den spezifischen Begrundungstyp ’Vergleich’(COMPARE CONTAINER) und zeigt an, welches Produkt bezuglich eines Aspektesdas Beste ist.

ASPECTRelation Datentyp Erlauterung

hasName String Name des AspekteshasWeight Double Relevanz des AspekteshasNumberAspect Double Anzahl der subsumierten Aspekte wird berechnethasReasonPriority Double Prioritat fur BegrundungenhasWinnerProduct String Gewinnerprodukt

Tabelle 7.7: Das Konzept ASPECT

Der QUESTION ASPECT, siehe Tabelle 7.8, dient als Schnittstelle zum Benutzer.Wie schon der Name impliziert wird dem Benutzer eine Frage gestellt, welcher dar-aufhin seine Praferenz angibt. Der QUESTION ASPECT ist in der BaumstrukturNachfolger des SCENARIO ASPECT und kann selber Nachfolger besitzen.

Der AGGREGATION ASPECT, in Tabelle 7.9 dargestellt, muss weitere Aspektebesitzen, uber die er mit einer ausgewahlten Funktion aggregiert. Dies erfolgt in

7.2. Der Bedurfnisraum 43

QUESTION ASPECTRelation Datentyp Erlauterung

hasPreference String Praferenzen des BenutzershasAspect ASPECT subsummierte Aspekte

Tabelle 7.8: Das Konzept QUESTION ASPECT

Abhangigkeit eines gesetzten Aggregationswertes. Der AGGREGATION ASPECTkann in der Baumstruktur alles außer ’Wurzel’ und ’Blatt’ sein.

AGGREGATION ASPECTRelation Datentyp Erlauterung

hasAggregationValue String AggregationswerthasAspect ASPECT Unteraspekt

Tabelle 7.9: Das Konzept AGGREGATION ASPECT

Der RATING ASPECT, siehe Tabelle 7.10, nimmt die Bewertung jedes Produktesfur jeweils ein Produktattribut vor. Er besitzt keine weiteren Aspekte und ist somitper Definition ’Blatt’ in der Baumstruktur. Er bekommt eine spezifische Anzahl anParametern, die jeweils von der Praferenz des Benutzers abhangen, in Form einerListe, siehe Abschnitt 7.11, ubergeben. Jeder Ratingaspekt bestimmt daruber hinausuber einen Indikator, mit welcher Ratingfunktion die Bewertung vorgenommen wird.

RATING ASPECTRelation Datentyp Erlauterung

hasParameter Double Liste an ParameternhasRatingFunction Double Bestimmung der verwendeten Ratingfunktion

Tabelle 7.10: Das Konzept RATING ASPECT

Der SCENARIO ASPECT ist die Wurzel und aggregiert uber alle QUESTION ASPECTS.Er ist in dem Sinn aber kein AGGREGATION ASPECT, weil er keinen Aggregati-onswert besitzt. Er besitzt lediglich die Relation ’hasAspect’.

Ein Vorteil von Ontologien ist das Prinzip der Mehrfachvererbung, d.h. eine Instanzkann von mehreren Konzepten gleichzeitig erben. Das Modell erfordert, dass z.Bein Questionaspekt auch Ratingaspekt oder Aggregationaspekt sein kann. Fur dieModellierung ergibt sich eine Vereinfachung, da uber eine Zuordnung automatischdie Eigenschaften bestimmt sind. Ein Modellierungsfehler ware es, wenn eine In-stanz Aggregationaspekt und Ratingaspekt ware, da beide Konzepte sich in ihrenEigenschaften ausschließen.

7.2.2 Falle

Alle Aspekte werden gemaß ihrer Eigenschaften und den Praferenzen des Benutzerskonfiguriert (Gewichte, Parameter und Aggregationswerte). Diese Information wirdin den Instanzen des Konzeptes CASE festgelegt. Die Axiome, welche in Abschnitt


7.4 genauer beschrieben sind, bestimmen wie ein Aspekt konfiguriert wird. Jede In-stanz des Konzeptes CASE hat einen korrespondierenden Aspekt. Des Weiteren be-sitzt jede Instanz eine Bedingung, welche in Form eines gesetzten Aggregationswerteseintritt und Konsequenzen in Form von Werten mit denen der Aspekt konfiguriertwird.

CASERelation Datentyp Erlauterung

inCaseOf String BedingunghasAspect ASPECT zum Fall korrespondierender AspektneedAggregationValue String zu setzender AggregationswertneedParameterDouble Double zu ubergebender Parameter vom Typ DoubleneedParameterString String zu ubergebender Parameter vom Typ StringneedWeight Double zu setzende Relevanz des Aspektes

Tabelle 7.11: Das Konzept CASE

Konsistenzbedingung hierbei ist, das jeder Case nur die Werte setzen kann, die seinkorrespondierender Aspekt besitzt. D.h. falls ein Case einen Aggregationsaspekt kon-figuriert, kann er ihm keine Parameter ubergeben, da dieser per Definition keinebenotigt. Genauso wie ein Ratingaspekt keinen Aggregationswert besitzt.

Wie in Abschnitt 7.1 bereits erwahnt, ware auch hier eine elegantere Form der Mo-dellierung durch eine Erweiterung der Relationen moglich, welche OntoEdit uber diegrafische Benutzeroberflache noch nicht unterstutzt. Es bestunde die Moglichkeit dasKonzept CASE wegzulassen und uber die Konzepte AGGREGATION ASPECTund RATING ASPECT alle Falle abzuhandeln. Zur Veranschaulichung sind in Ta-belle 7.12 alle Relationen aufgefuhrt. Der Aggregationwert ist auch hier vom TypString.

ALTERNATIVE AGGREGATION ASPECTRelation Datentyp Erlauterung

hasAggregationValue(AggregationValue) String zu setzender AggregationswerthasWeight(AggregationValue) Double zu setzende Relevanz

ALTERNATIVE RATING ASPECT

hasParameterString(AggregationValue) String zu ubergebender ParameterhasParameterDouble(AggregationValue) String zu ubergebender ParameterhasWeight(AggregationValue) Double zu setzendes Gewicht

Tabelle 7.12: Alternativmodellierung

7.3. Der Begrundungsraum 45

Abbildung 7.2 soll verdeutlichen, dass bei der alternativen Modellierung allebenotigten Konfigurationen in der Instanz eines Aspektes modelliert werden konnen.Im Gegensatz dazu muss bei der verwendeten Modellierung fur alle Moglichkeitenjeweils eine Instanz des Konzeptes CASE erzeugt werden. Die Axiome fur die Kon-figuration, siehe Abschnitt 7.4, mussten an eine alternative Modellierung angepasstwerden.

��

� �� !� "#$%&��'((�� !� "#$%&��)((*��+�,!�� -.

� ��/�01�23��0�*�� !� "#$%&�4�� 5 ��'((*�� !� "#$%&�4�� 5 ��)((*�� !� "#$%&�46�!!�&5��)((*�� !� "#$%&�46�!!�&5��7((5-.

� ��/�01�23��0�*�� !� ��'((*�� !� ��)((-.

� ��6�!!�&�� 6�!!�&�� !� "#$%&��)((�� !� "#$%&��7((*��+�,!�� -.

8��9:;��

<�9��=��

<�9��=��>8��9:;��

Abbildung 7.2: Modellierung der Alternative in F-Logik

7.2.3 Fitnessklassen

Fur jedes Produkt wird fur jeden Aspekt ein Ruckgabewert berechnet, siehe Ab-schnitt 7.5. Mit Fitnessklassen konnen Intervalle festgelegt werden, die bewerten,ob ein Produkt ein Kriterium bzw. einen Aspekt befriedigt. Fitnessklassen erlau-ben eine Kategorisierung in qualitative Beurteilungen, wie z.B. ’erfullt’, ’ubererfullt’oder ’nicht erfullt’. Dies spielt in erster Linie fur das Begrunden eines gewahltenProduktes eine Rolle. So bietet das Konzept, wie in Tabelle 7.13 beschrieben, dieMoglichkeit Intervallsgrenzen fur eine Klasse festzulegen und zur Identifikation denNamen der Fitnessklasse zu benennen.

FITNESS CLASSRelation Datentyp Erlauterung

hasFitnessName String NamehasMinRating Double untere Grenze des IntervallshasMaxRating Double obere Grenze des Intervalls

Tabelle 7.13: Das Konzept FITNESS CLASS

7.3 Der Begrundungsraum

Im Begrundungsraum sollen Begrundungen generiert werden, die die in Kapitel 6beschriebenen Verkaufsprozesse unterstutzen. Die Ontologie besteht hier zum einen


aus dem Konzept REASONING TEMPLATE, um bestimmte Begrundungstypenin Form einer Bauart zu definieren. Des Weiteren beinhaltet der Begrundungs-raum das Konzept REASONING DATA CONTAINER, in welchem zu jedem Ras-ter Bedingungen fur Begrundungen beschrieben werden. Die in Abschnitt 7.8.1 be-schriebenen Axiome uberprufen diese Bedingungen fur alle Aspekte und zu jedemProdukt und sammeln alle potentiellen Begrundungen in spezifischen Behaltern(’Container’). In Tabelle 7.14 sind die Behalter QUALIFICATION CONTAINER,CONFLICT CONTAINER und COMPARE CONTAINER modelliert. In dieser Artkonnen beliebig viele Typen definiert werden.

OBJECT[]REASONING SPACE ELEMENT::OBJECT

REASONING TEMPLATE::REASONING SPACE ELEMENTREASONING DATA CONTAINER::RESONING SPACE ELEMENT

QUALIFICATION CONTAINER::REASONING DATA CONTAINERCONFLICT CONTAINER::REASONING DATA CONTAINERCOMPARE CONTAINER::REASONING DATA CONTAINERusw.

Tabelle 7.14: Der Bedurfnisraum

Jedes Element des Begrundungsraumes besitzt einen Namen zur Identifikation. Dar-aus ergibt sich die, in der Tabelle 7.15 beschriebene, Relation fur das KonzeptREASONING SPACE ELEMENT.

REASONING SPACE ELEMENTRelation Datentyp Erlauterung

hasName String Name des Tempalte

Tabelle 7.15: Das Konzept REASONING SPACE TEMPLATE

Fur Begrundungen, welche eine ahnliche Struktur haben und fur jedes spezifische Re-commender System gleich bleiben, wird unter dem Konzept REASONING TEMPLATEeine Schablone definiert. Jede Schablone benotigt einen eigenen Behalter, aus demsie sich Begrundungen holt. Begrundungen sind Aspekte, die Bedingungen erfullenund werden im Behalter nach ihrer Prioritat geordnet. Sie werden in festgelegteTextbausteine (’Frames’) der Schablone eingebettet. Weiter muss der Modellierereine vorgegebene Anzahl an Begrundungen sowie die Verwendung der Textgenerati-onsfunktion bestimmen. Abbildung 7.3 veranschaulicht das Zusammenspiel zwischenSchablone und Behalter. Das Axiom in Tabelle 7.24 oder A.25, welches in Abschnitt7.8.1 erlautert ist, realisiert das Zusammenspiel.

7.3. Der Begrundungsraum 47

��

��

��

��

!�" �#$

%&'()*+,-.

/��

0+,1(2,-3.

/��

456�� 7�8 9�:;�8��

��

�� ;�:

Abbildung 7.3: Die Schablone ’Eignung’

Daraus ergeben sich die in Tabelle 7.16 beschriebenen Relationen.

REASONING TEMPLATERelation Datentyp Erlauterung

hasContainer String Name des korrespondierenden ContainershasReasonNumber Double Anzahl der benotigten BegrundungenhasReasonFunction Double Funktion zur SatzgenerierunghasFrame1 String Einleitung des SatzeshasFrame2 String Schluss des Satzes


Die Behalter legen fur die unterschiedlichen Begrundungstypen fest, welche Aggrega-tionswerte gesetzt und welche Fitnessklassen je Aspekt generiert sein mussen. Dieswird mittels der Relationen ’hasCondition’ und ’hasFitness’ eines Behalters vomKonstrukteur des Systems bestimmt. In der Relation ’hasReason’ kann bei Bedarfein Satzbaustein hinzugefugt werden, welcher mit dem Namen das Aspektes beiSelektierung verbunden wird. In der Relation ’hasPriority’ kann bestimmt werden,dass nur Aspekte mit einer bestimmten Prioritat fur einen Begrundungstyp relevantsind. Die Relation ’hasConditionAspect’ bietet die Moglichkeit fur einzelne Aspek-te Bedingungen festzulegen. Der Beispielcontainer in Abbildung 7.4 selektiert mitseinen gesetzten Bedingungen nur den Aspekt ’Telefon’ als potentielle Begrundung.Die Axiome in den Tabellen A.18 bis A.21 selektieren die jeweiligen Aspekte fur dierealisierten Behalter (siehe auch Abschnitt 7.8.1).

��

��

��

�� !��"��#�� #��

$��

�� !��"��#��

��

�� !��"��

Abbildung 7.4: Container

In Tabelle 7.17 sind die benotigten Relationen dargestellt.


REASONING DATA CONTAINERRelation Datentyp Erlauterung

hasCondition String Name gesetzter AggregationswerthasConditionAspect ASPECT korrespondierender AspekthasReason String SatzbausteinhasPriority Double Prioritat der BegrundunghasFitness FITNESS CLASS berechnete Fitness des Aspektes


7.4 Die Baumkonfiguration

Wie in Kapitel 5 beschrieben, werden bei der Baumkonfiguration die Kantengewich-te des Baumes, die entsprechenden Aggregationswerte fur die Aggregationsaspekteund die geforderten Parameter fur die Ratingaspekte in Abhangigkeit der Praferen-zen des Benutzers festgelegt. In der Modellierung dieser Arbeit wird dem Benutzererlaubt, uber die Instanzen des Konzeptes QUESTION ASPECT seine Praferen-zen uber qualitative Merkmalsauspragungen, wie z.B. ’Egal’,’Einfach’,’Mittel’ und’Hoch’, zu setzen. Der Benutzer kann nur uber diese Schnittstelle Einfluss auf dieKonfiguration des Baumes nehmen. Ist dieser Wert gesetzt, werden alle abhangigenWerte im Baum automatisch konfiguriert.

Bei allen Instanzen von AGGREGATION ASPECT, die zugleich QUESTION ASPECTsind, wird mit Axiom 1 die Praferenz des Benutzers ubernommen (siehe Tabelle A.1).Die Praferenz, welche uber eine Benutzeroberflache an ’hasPreference’ ubergebenwird, setzt den Aggregationswert des Aggregationsaspektes.

Die Axiome 2 bis 8 bestimmen fur jeden Aspekt in Abhangigkeit der gesetztenPraferenzen die korrespondierende Instanz des Konzeptes CASE (siehe die TabellenA.2 bis A.8). Diese beinhalten die Informationen fur die Konfiguration und werdengemaß der Eigenschaften des Aspektes ubertragen, siehe Abschnitt 7.2.2.

Das Axiom 2 bestimmt fur alle nachfolgenden Aggregationsaspekte eines Aggrega-tionsaspektes Kantengewicht und Aggregationswert.

Die Axiome 3 und 4 generieren fur alle nachfolgenden Ratingaspekte eines Aggrega-tionsaspektes Pradikate fur jeden Parameter der Instanz von CASE und legen dieKantengewichte der Ratingaspekte fest. Alle Pradikate eines Ratingaspektes werdenin Axiom 8 zu einer Liste zusammengefasst und dem jeweiligen Ratingaspekt zuge-ordnet. Die Abbildung 7.5 veranschaulicht, wie in Abhangigkeit des gesetzten Ag-gregationswertes des Aspektes ’Internet’ uber Axiom 4 (Parameter vom Typ String)der richtige Case identifiziert wird und die benotigten Werte des Aspektes ’Wap’gesetzt werden.

7.4. Die Baumkonfiguration 49

��

��

��

��

��

��

��

�� !��

��

��

�� "

�� !�� #��

�� "

�� !�� $#�%

&� ��'

�� (��)#�*&� ��'&� ��+

Abbildung 7.5: Baumkonfiguration

In Tabelle 7.18 ist das Axiom 4 dargestellt. Das Pradikat ’Parameter()’ besteht ausdem Aspekt, fur das der Parameter bestimmt ist und dem jeweiligen Parameter. BeiUbereinstimmung der Variablen ’ratingaspect1’ und ’aggregationvalue1’ ist fur eineInstanz des Konzeptes AGGREGATION ASPECT die korrespondierende Instanz’selectedcase1’ identifiziert. Somit kann der Parameter ’stringparameter’ und dasGewicht ’weight1’ im Kopf des Axioms gesetzt werden.

FORALL aggregationaspect1,ratingaspect1,weight1,

selectedcase1,aggregationvalue1,stringparameter1

ratingaspect1:ASPECT[hasWeight->>weight1]

and Parameter(ratingaspect1,stringparameter1)

<-

aggregationaspect1:AGGREGATION_ASPECT[hasAspect->>ratingaspect1;

hasAggregationValue->>

aggregationvalue1]

and ratingaspect1:RATING_ASPECT

and selectedcase1:CASE[needWeight->>weight1;

hasAspect->>ratingaspect1;

inCaseOf->>aggregationvalue1;

needParameterString->>stringparameter1].

Tabelle 7.18: Axiom 4

Die Axiome 5 und 6 behandeln den Fall, wenn der Questionaspekt ebenfalls Ratinga-spekt ist. Sie generieren, wie die Axiome 3 und 4, die Pradikate mit den Parametern,welche dann auch mit Axiom 8 zu einer Liste zusammengefasst werden. Die Kan-tenbelegung ist in diesem Fall nicht notwendig, da Axiom 7 fur alle Questionaspektedie Kantenbelegung festlegt.

Die Axiome 3 bis 6 konnten auch zu jeweils zwei Axiomen zusammengefasst werden.Der Ubersicht wegen sind sie aber gesplittet. Daraus folgt, dass fur die Konfigurationdes Modelles nicht mehr als 6 Axiome benotigt werden.


7.5 Die Bewertung der Produkte

Die Axiome 9 bis 11, siehe die Tabellen A.9 bis A.11, bewerten alle Gerate aus demProduktkatalog.

Es besteht, wie bereits in Abschnitt 2.2 erwahnt, bei OntoBroker die MoglichkeitJavaprogramme uber eine Schnittstelle anzusprechen. Diese werden nach [Ontb] alsBuiltIns bezeichnet.

Die Bewertung erfolgt, indem jeweils die generierte Parameterliste eines Aspektesund der korrespondierende Attributwert des Gerates an ein BuiltIn ’RatingFuncti-on()’ ubergeben wird. Es existiert fur jeden Attributtyp (String, Double, komplexerTyp) der Ubersicht wegen ein Axiom. Diese Axiome konnen zu einem Axiom zusam-mengefasst werden, wenn an das BuiltIn noch ein Typindikator ubergeben werdenwurde. Somit konnte der Datentyp im BuiltIn klassifiziert werden.

Das BuiltIn benotigt des Weiteren einen Indikator fur die gewunschte Ratingfunk-tion. Dieser Indikator muss vom Modellierer des Recommender Systems fur jedenRatingaspekt festgelegt werden. Die Firma Mentasys verwendet unterschiedliche Be-wertungsfunktionen, die uber die Schnittstelle bequem integriert werden konnen.

Die Axiome generiern Pradikate ’ReturnValue()’, welche aus Produkt, Aspekt undberechnetem Ruckgabewert bestehen. In Tabelle 7.19 ist das Axiom 9 dargestellt.Jedes Attribut hat einen korrespondierenden Ratingaspekt, welcher mit der Uber-einstimmung der Variable ’ratingaspect1’ in der Relation ’hasRatingAspect’ unterden Instanzen des Konzeptes RATING ASPECT identifiziert wird. Bei Ubereinstim-mung werden dem BuiltIn ’RatingFunction()’ die Parameterliste ’parameterliste1’,der Attributwert ’doublevalue1’ des Produktes und die geforderte Ratingfunktion’ratingfunction1’ ubergeben. Die Variable ’returnvalue1’ beinhaltet das Ergebnis desRatings.

FORALL product1,ratingaspect1,doublevalue1,returnvalue1,

ratingfunction1,attribute1,parameterliste1

ReturnValue(product1,ratingaspect1,returnvalue1)

<- product1:PRODUCT[hasAttribute->>attribute1] and

ratingaspect1:RATING_ASPECT[hasRatingFunction->>ratingfunction1;

hasParameter->>parameterliste1]

and attribute1:ATTRIBUTE[hasValueDouble->>doublevalue1;

hasRatingAspect->>ratingaspect1]

and RatingFunction(parameterliste1,doublevalue1,ratingfunction1,

returnvalue1).

Tabelle 7.19: Axiom 9 Rating (Parameter Double)

7.6. Die Aggregation 51

7.6 Die Aggregation

Die Axiome 12 bis 14 dienen der Aggregation (siehe die Tabellen A.12 bis A.14).

Mit Axiom 12 wird pro Aggregationsaspekt in Bezug auf ein Produkt eine Listeerzeugt. Diese Liste beinhaltet die Ruckgabewerte und korrespondierenden Kanten-gewichte aller Nachfolger. Das Pradikat ’MakeAggregation()’ zeigt je Aspekt undProdukt die korrespondierende Liste an. Dieses Pradikat dient vorwiegend der Eva-luierung, da alle benotigten Werte fur eine Aggregation, welche in der Liste zu-sammengefasst sind, uber die Anfrage in Abbildung 7.20 schnell abgefragt werdenkonnen.

FORALL product1,aspect1,liste

<- MakeAggregation(product1,aspect1,liste).

Tabelle 7.20: Evaluierung uber Pradikat MakeAggregation()

Das Axiom 13 berechnet wie viele Unteraspekte ein Aspekt hat.

Die eigentliche Aggregation ist in Axiom 14 implementiert (siehe Tabelle 7.21). Eswerden die in Axiom 12 generierte Liste (’aggregationliste1’) und die Anzahl der Un-teraspekte (’numberaspect1’) an das BuiltIn ’Aggregation()’ ubergeben. Das BuiltInberechnet das gewichtete Mittel uber alle Unteraspekte. Ahnlich wie beim Rating,konnten auch hier unterschiedliche Aggregationsfunktionen genutzt werden. Das Axi-om erzeugt ebenfalls ein Pradikat ’ReturnValue()’.

FORALL aspect1,aggregationliste1,returnvalue1,product1,numberaspect1

ReturnValue(product1,aspect1,returnvalue1)

<- MakeAggregation(product1,aspect1,aggregationliste1)

and product1:PRODUCT

and aspect1:ASPECT[hasNumberAspect->>numberaspect1]

and Aggregation(aggregationliste1,numberaspect1,returnvalue1).

Tabelle 7.21: Axiom 14 Aggregation

Das Axiom 12 ist nicht zwingend notwendig, da bei anderer Gestaltung des Buil-tIns die Aggregation allein mit den Axiomen 14 und 13 umgesetzt werden kann.Allerdings ist das Axiom 12 fur die Validierung des Modelles geeignet.

7.7 Die Bestimmung der Fitnessklasse

Die Axiom 15 bis 17 wandeln die berechneten Ruckgabewerte in qualitative Fitness-werte um, siehe Anhang A.15 bis A.17. Das Axiom 15 ist in Tabelle 7.22 dargestellt.Dabei wird lediglich uberpruft, ob sich der Ruckgabewert ’returnvalue1’ im jeweiligen


Intervall (’min1’,’max1’) der Fitnessklasse befindet. Es wird ein Pradikat ’Return-FitnessValue’ erzeugt, welches pro Produkt (’product1’) und Aspekt (’aspect1’) denFitnesswert (’fitnessvalue1’) angibt.

FORALL product1,apsekt1,returnvalue1,fitnessvalue1,min1,max1

ReturnFitnessValue(product1,apsekt1,fitnessvalue1)

<- ReturnValue(product1,apsekt1,returnvalue1)

and fitnessvalue1:FITNESS_CLASS[hasMinRating->>min1;

hasMaxRating->>max1;

hasFitnessName->>’Over_Satisfy’]

and lessorequal(returnvalue1,max1)

and greater(returnvalue1,min1).

Tabelle 7.22: Axiom 15 Fitness ’OverSatisfy’

7.8 Die Begrundungsmechanismen

Wie in Kapitel 3 erlautert, stehen die Prozesse Inhaltselektierung undInhaltsorganisation des referenzierten Schemas in Abschnitt 3.2.1 bei der Erzeu-gung von Begrundungen bzw. Erklarungen im Fokus dieser Arbeit. Die folgendenAbschnitte erlautern die Vorgehensweise.

7.8.1 Inhaltsselektierung

Vorab muss bestimmt werden unter welchen Umstanden ein Aspekt fur einen Be-grundungstyp relevant ist. Die Axiome 18 bis 21 generieren potentielle Begrundun-gen fur die unter dem Konzept REASONING CONTAINER definierten ’Container’(siehe die Tabellen A.18 bis A.21). Ahnliche Begrundungstypen sind unter einem’Containerkonzept’ zusammengefasst. In Tabelle 7.23 ist das Axiom 18 dargestellt,welche fur Aspekte die Eignung uberpruft.

Dies erfolgt, indem die generisch erzeugten Fitnesswerte (’fitnessvalue1’) sowie dieAggregationswerte (’condition1’) der Aspekte mit den Bedingungen (’condition1’)und den Fitnesswerten (’fitnessvalue1’) der Behalter verglichen werden (siehe auchAbbildung 7.4). Falls Bedingung und Fitness erfullt sind, wird ein Pradikat ’Contai-ner()’ erzeugt, welches den Behalternamen, den Aspekt, das Produkt, die Fitness desAspektes bezuglich des Produktes, die Prioritat und einen Hilfstextbaustein enthalt.Der Hilfstextbaustein besteht aus dem Namen des Aspektes sowie einem Fullwort.

In Axiom 22 (Tabelle A.22) werden pro Container alle Begrundungen zu einer Listezusammengefugt, um die Liste in Axiom 23 (Tabelle A.23) mit einem BuiltIn ’Sort()’gemaß der Prioritat nach Wichtigkeit zu sortieren. Das Pradikat ’SortListReason()’beinhaltet alle Begrundungen nach Wichtigkeit, sortiert pro Behalter und Produkt.

Das Axiom 24 (Tabelle A.24) generiert ebenfalls ein Pradikat ’SortListReason()’, wel-ches die in Axiom 21 erzeugten Begrundungen des Containers ’ContainerSuccessor()’

7.8. Die Begrundungsmechanismen 53

FORALL aspect1,prio1,aspectname1,reason1,container1,

fitnessvalue1,condition1,containername1,

assistanttext1,productid1,product1

Container(containername1,aspect1,product1,fitnessvalue1,prio1,reason1)

<- aspect1:ASPECT[hasReasonPriority->>prio1;

hasName->>aspectname1;

hasAggregationValue->>condition1]


and ReturnFitnessValue(product1,aspect1,fitnessvalue1)

and concat(assistanttext1,aspectname1,reason1)

and container1:QUALIFICATION_CONTAINER[hasFitness->>fitnessvalue1;

hasCondition->>condition1;

hasName->>containername1;

hasReason->>assistanttext1].

Tabelle 7.23: Axiom 18 Container (Eignung)

in Form einer Liste angibt. Dieses Axiom ist notwendig, da dieser Begrundungstyp(’Rechtfertigung uber Unteraspekte’) im Vergleich zu den anderen Begrundungsty-pen eine unterschiedliche Listengenerierung benotigt. Es werden, falls die Bedingun-gen erfullt sind, die Unteraspekte eines Aspektes zu einer Liste zusammengefugt.

In den Instanzen des Konzeptes REASONING TEMPLATE wird fur jeden Begrun-dungstyp ein Raster an Satzbausteinen (’textframe1’ und ’textframe2’), die Anzahlan benotigten Begrundungen (’numberreason1’) und die erforderliche Begrundungs-funktion mittels eines Identifikators (’reasonfunction1’) festgelegt. Jeder Behalterhat ein korrespondierendes Template (siehe auch Abbildung 7.3). In Axiom 25, sieheTabelle 7.24, wird fur jedes Pradikat ’SortListReason()’ das korrespondierende Tem-plate uber die Variable ’containername1’ ermittelt und die jeweiligen Werte inklusiveder Liste an potentiellen Begrundungen (’reasonliste1’) an das BuiltIn ’Reasoning()’ubergeben. Das Ergebnis (’returnreason1’) und der Name des Begrundungstypen(’templatename1’) wird fur jedes Produkt in dem Pradikat ’Reason()’ festgehalten.


FORALL textframe1,textframe2,reasontemplate1,product1,

returnreason1,templatename1,reasonliste1,containername1,

numberreason1,reasonfunction1,productid1

Reason(productid1,returnreason1,templatename1)

<- reasontemplate1:REASONING_TEMPLATE[hasFrame_1->>textframe1;

hasFrame_2->>textframe2;

hasNumberReason->>numberreason1;

hasContainer->>containername1;

hasName->>templatename1;

hasReasonFunction->>reasonfunction1]

and SortListReason(product1,reasonliste1,containername1)

and product1:PRODUCT[hasProductID->>productid1]

and Reasoning(reasonliste1,textframe1,textframe2,numberreason1,

reasonfunction1,returnreason1).

Tabelle 7.24: Axiom 25 Textgenerierung

Die Axiome 26 bis 28 unterstutzen die Inhaltsbestimmung (siehe die Tabellen A.26bis A.28). Mit ihnen wird fur jeden Aspekt das Produkt mit dem besten Ergebnisermittelt. Dies ist fur das Axiom 19 (’Compare Container’) von Bedeutung.

7.8.2 Inhaltsorganisation

Mit der Technik des ’Meta-Inferencing’, siehe die Abschnitte 2.2 und 3.3.4.4, konnenArgumentations-Modelle (Toulmin) oder Textstrukturierungs-Modelle (RST)implementiertwerden (siehe Abschnitt 3.4). Mit diesen Techniken konnen die erzeugten Begrundun-gen zu Argumenten oder zusatzlichem koharentem Text zusammengefugt werden. Eskonnen daruber hinaus neue Begrundungen erzeugt werden, um in Abhangigkeit desidentifizierten Personlichkeitstypen den Verkaufprozess zu unterstutzen (siehe Kapi-tel 6). Mit der in Tabelle 7.25 dargestellten Anfrage wird die Datei ’explanation.flo’generiert, welche alle instanzierten Pradikate ’Container()’ enthalt. In einem zweitenSchritt wird diese Datei von OntoBroker geladen und kann auf Inhalt untersucht undorganisiert werden.

FORALL name1,apsect1,product1,fit1,prio1,reason1 <-

Container(name1,apsect1,product1,fit1,prio1,reason1).

Tabelle 7.25: Anfrage fur ’Meta-Inferencing’

7.8. Die Begrundungsmechanismen 55

In Tabelle 7.26 ist exemplarisch eine Axiom dargestellt, welche ein Argument aus Be-hauptung und Standpunkt zusammenfugt. Dieses Axiom untersucht, ob ein Konflikt(Questionaspekte mit Belegungen ’Over Satisfy’ und ’Not Satisfy’) existiert, indemuberpruft wird, ob in Axiom 20 (Konfliktbehandlung) die Variablen Aspekt, Fit-ness und Produkt instanziert worden sind. Das Axiom in Tabelle 7.26 identifiziertunter den Aspekten jene mit einer hohen Fitness und generiert Standpunkte, sie-he Abschnitt 3.4.2. Standpunkte werden erzeugt, indem die Unteraspekte aufgezahltwerden, welche ebenfalls eine hohe Fitness besitzen, um den eigentlichen Aspekt bzw.die Behauptung zu stutzen. Das Axiom soll im Konfliktfall helfen den Benutzer zuuberzeugen.

FORALL reason1,I,aspect1,aspect2,fitnessvalue1,

fitnessvalue2,aspectname1,name2,product1,

productid1,aspect1_this,

fitnessvalue1_this,product1_this

Reason(productid1,reason1,’Standpunkt’)

<- I:Instantiation[ofRule->>Axiom 20 (Container Generierung);

instantiatedVars->>{i(aspect1,aspect1_this),

i(fitnessvalue1,fitnessvalue1_this),

i(product1,product1_this)}]

and aspect1_this:ASPECT[hasAspect->>aspect2;

hasName->>aspectname1]

and aspect2:ASPECT[hasName->>aspectname2]

and fitnessvalue1_this:FITNESS_CLASS[hasFitnessName->>"Over_Satisfy"]

and fitnessvalue2:FITNESS_CLASS[hasFitnessName->>"Over_Satisfy"]

and ReturnFitnessValue(product1_this,aspect2,fitnessvalue2)


and (reason1 is (" Das Gerat "+productid1+" ist bezuglich "+name1+"

deshalb so gut, weil es bezuglich "+aspectname2+" ausgezeichnet ist")).

Tabelle 7.26: ’Meta-Inferencing’

Die Abbildung 7.6 beschreibt das Zusammenspiel des Axioms 20 mit dem in Tabelle7.26 dargestellten Axioms anhand eines Beispiels. Der Benutzer hat hohe Praferenzenbezuglich Internet und mochte ein billiges Gerat. Das Gerat von Nokia hat hoheInternetfunktionalitaten, ist allerdings teuer. Das Axiom 20 generiert die Pradikate’Container()’. Anschließend wird uber das ’Meta-Inferencing’ identifiziert, ob dasGerat bezuglich ’Wap’ einen hohen Fitnesswert besitzt. Mit diesen Informationenwird ein Standpunkt generiert, welcher in einem Pradikat ’Reason()’ abgelegt wird.

An dieser Stelle sei erwahnt, dass das Axiom 20 lediglich Containerpradikate er-zeugt, welche Aspekte mit Prafixen (’Pro’ und ’Contra’) enthalten. Die eigentlicheUberprufung, ob tatsachlich ein Konflikt existiert, erfolgt uber die Prafixe im Buil-tIn ’Reasoning()’ des Axioms 24. D.h. ein Hinzufugen des generierten Standpunktes


aus Abbildung 7.26 musste mit den erzeugten Pradikaten ’Reason()’ des Axioms 24abgeglichen werden, da nicht alle erzeugten ’Container()’ automatisch ein Konfliktdarstellen.

��

��

��

��

!��!��!��

��"�� !��!��!��

��"�!��

��#�$�� %$

%$

��%$��

��&'�(��)� �� ***+�,-��%$��,�� &��$��&

./0/1 23

4/56789/:/8;780

Abbildung 7.6: Standpunkt

7.9 Modellierung eines Handyberaters

Realisiert wurde ein System, welches den Benutzer beim Kauf eines Mobiltelefonesunterstutzt. Auf der beigelegten CD befinden sich die Ontologie und die benotigtenBuiltIns.

Im Produktraum sind die unterschiedlichen Mobiltelefone mit ihren Attributen ein-gepflegt. Die Tabelle 7.27 zeigt eine Instanz eines Mobiltelefones und die zughorigeInstanz eines Attributwertes in F-Logik.

7.9. Modellierung eines Handyberaters 57

7210:MOBILE.

7210[hasProductID->>"7210";

hasAttribut->>NumberMemory_50;

hasAttribut->>AttributPrice_200;

hasAttribut->>AttributDesign_Outdoor;

hasAttribut->>EmailClient_true;

hasAttribut->>HtmlBrowser_true;

hasAttribut->>AttributWap_true;

hasAttribut->>JavaAbility_true;

hasAttribut->>NumberMemory_50;

hasAttribut->>DisplaySize_Small;

hasAttribut->>BusinessSoftware_1;

hasAttribut->>CommunicationSoftware_1;

hasAttribut->>FunSoftware_1].

AttributPrice_200:MOBILE_ATTRIBUT.

AttributPrice_200[hasRatingAspect->>Price_Aspect;

hasValueDouble->>200.0].

Tabelle 7.27: Produktraum

Die Struktur des Beratungsystems ist im Bedurfnisraum uber die Aspekte festgelegt,siehe Abbildung 7.7.

��

��

��

��

��

��

��

�� !� "�#��"��

Abbildung 7.7: Struktur

Die Instanzen des Konzeptes CASE legen die Baumkonfiguration in Abhangigkeitder Eingabe des Benutzers fest. In Tabelle 7.8 sind alle moglichen Benutzereingabenpro Questionaspekt dargestellt.


��

��

��

��

��

��

��

��

��

��

�� !��

��

��

��

��

"��#�

��

�$%��

��&' (��

�)� �*+

�,�((��

Abbildung 7.8: Qualitative Merkmale

In Tabelle 7.28 ist bespielhaft der Aspekt ’Business’ und ein Case fur den Aspekt’Internet’ in F-Logik definiert. Im Beispiel ist der Name, die Nachfolger und die Be-grundungsprioritat des Aspektes ’Business’ gesetzt. Der Wert der Relation ’hasPre-ference’ wird uber die Webapplikation vom Benutzer festgelegt. Die anderen Wer-te werden dynamisch erzeugt. Die Instanz des Konzeptes CASE legt fest, wie derAspekt ’Internet’ konfiguriert wird, wenn sein Vorgangeraspekt ’Business’ den Ag-gregationswert ’Hoch’ hat.

Business_Aspect:QUESTION_ASPECT.

Business_Aspect:AGGREGATION_ASPECT.

Business_Aspect[hasName->>"Business";

hasAspect->>Internet_Function;

hasAspect->>Software;

hasReasonPriority->>1.0

hasPreference->>;


hasWeight->>

hasWinnerProduct->> ].

Case_Internet_Function_Hoch:CASE.

Case_Internet_Function_Hoch[hasAspect->>Internet_Function;

needAggregationValue->>"Mittel";

needWeight->>0.7;

inCaseOf->>"Hoch"].

Tabelle 7.28: Bedurfnissraum

Im Begrundungsraum werden die Raster und ihre korrespondierenden Behalter fest-gelegt. In Tabelle 7.29 ist beispielhaft das Raster des Begrundungstyps ’Kurzverge-leich’ und sein korrespondierender Behalter festgelegt. Fur einen Kurzvergleich wirdnur eine Begrundung in die Satzbausteine des ’Templates’ eingepflegt. Siehe auch diekorrespondierenden Axiome 26 - 28 (im Anhang die Tabellen A.26 - A.28), welchefur alle Aspekte das Gewinnerprodukt ermittelt.

7.9. Modellierung eines Handyberaters 59

Rating_Template_Short:REASONING_TEMPLATE.

Rating_Template_Short[hasContainer->>"Compare_Container_Short";

hasFrame_1->>"Bezuglich";

hasFrame_2->>"ist das Gerat gemaß ihren

Praferenzen das beste des

Produktkatalogs.";

hasNumberReason->>1.0;

hasName->>"Vergleich_Kurz";

hasReasonFunction->>1.0].

Compare_Short:COMPARE_CONTAINER.

Compare_Short[hasFitness->>#Over_Satisfy;

hasFitness->>#Satisfy;

hasName->>"Compare_Container_Short";

hasReason->>"des Aspektes"].

Tabelle 7.29: Begrundungsraum

OntoBroker hat mehrere Schnittstellen, siehe [Ontb]. Eine mogliche Variante Onto-Broker anzubinden, ware innerhalb von JSP uber die Klasse ’Client’. Zusammen miteinem Webserver, welcher JSP interpretiert (’http://jakarta.apache.org/tomcat/’),kann man eine Webapplikation erstellen.

Der Benutzer muss uber das ’Frontend’ die Moglichkeit haben bezuglich aller einge-pflegten Questionaspekte in der Ontologie, seine Praferenz zu wahlen. Die gewahl-ten Werte werden bei einer Session an einen Server geschickt. Auf dem Server laufenmehrere OntoBroker mit der geladenen Ontologie gleichzeitig. Die Applikation wahlteinen freien OntoBroker und setzt die ubergebenen Praferenzen mit dem Kommando’add’. In Abbildung 7.30 sind die Befehle dargestellt, wie sie innerhalb von JSP ver-wendet werden. NS steht hier fur den Namespace (“http://www.mentasys.org/handy rec“).

ontobroker.Command(add NS#Business_Aspect:

NS#QUESTION_ASPECT[NS#hasPreference->>"’Hoch"’]).

ontobroker.Command(add NS#Price_Aspect:

NS#QUESTION_ASPECT[NS#hasPreference->>"’Niedrig"’]).

ontobroker.Command(add NS#Design_Aspect:

NS#QUESTION_ASPECT[NS#hasPreference->>"’Freaky"’]).

ontobroker.Command(add NS#Telefon_Aspect:

NS#QUESTION_ASPECT[NS#hasPreference->>"’Mittel"’]).

Tabelle 7.30: Praferenzen uber Webapplikation setzen

Die Produkte mit den besten errechneten Nutzenwerten, inklusive der erzeugtenBegrundungen, werden dem Benutzer prasentiert. Hierbei kann man mit Anfragen,wie in Abbildung 7.31 dargestellt, bezuglich der Produkte und der Begrundungs-typen sortieren. Die Ergebnisse konnen in eine JSP eingefugt werden. Uber ’Meta-Inferencing’ konnen weitere Begrundungen bei Bedarf generiert werden. Nach der


Beratung wird der OntoBroker neu geladen und somit alle in einer Session generier-ten Werte geloscht.

FORALL product1,reason1,reasontype1 <-

Reason(product1,reason1,reasontype1).

oder

FORALL product1,reason1,reasontype1,aspect1 <-

Reason(product1,reason1,reasontype1)

and aspect1:ASPECT[hasName->>"Gesamtnutzen";

hasWinnerProduct->>product1].

Tabelle 7.31: Anfragen

Falls keine Webapplikation zur Verfugung steht, mussen die Praferenzen uber dieKommandozeile hinzugefugt bzw. geloscht werden. Es ist pro Questionaspekt nureines der dargestellten qualitativen Merkmale aus Abbildung 7.8 moglich. Deshalbmuss beim Andern der Praferenzen die vorherige Praferenz geloscht werden. Die Ta-belle 7.32 zeigt beispielsweise, wie in zwei Schritten die Praferenz des Questionaspekt’Business’ von ’Hoch’ auf ’Mittel’ gesetzt werden kann.

1. Schritt

del NS#Business_Aspect:NS#QUESTION_ASPECT[NS#hasPreference->>"’Hoch"’].

2. Schritt

add NS#Business_Aspect:NS#QUESTION_ASPECT[NS#hasPreference->>"’Mittel"’].

Tabelle 7.32: Praferenzen uber Kommandozeile setzen

8. Zusammenfassung und Ausblick

Im Folgenden werden die Gesichtspunkte Effizienz und Qualitat des im Rahmen die-ser Arbeit entstanden Modells auch bezuglich der Modellierung mit OntoEdit, sieheAbschnitt 2.3, und eines eventuellen Produktivsystems mit OntoBroker, siehe Ab-schnitt 2.2, diskutiert. Abschließend wird eine Anregung fur eine Weiterentwicklungdes Modells gegeben.

8.1 EffizienzEs wurde ein hoher Grad an Abstraktion bei der Modellierung der Ontologie in demSinn erreicht, dass fur ein Basissystem mit einer Ontologie die Axiome und die Kon-zeptstruktur produktunabhangig gestaltet werden konnten. Dies hat zur Folge, dassman einen hohen Grad an Wiederverwendung fur die Modellierung aller weiteren,auf dem Basissystem aufbauenden, Empfehlungsysteme erlangt.

Ein weiteres Ziel, ein Basissystem zu modellieren, welches fur unterschiedliche Pro-duktdomanen wiederverwendet werden kann, ohne erneut Frame-Logik implemen-tieren zu mussen, wurde erreicht. Dies hat den Vorteil, dass ein Modellierer einesStandardsystems nur die Produktdomane kennen muss und keine Spezialkenntnis-se in Frame-Logik benotigt. Dies macht im Allgemeinen ein schnelleres Modellierenmoglich, da nur noch Fakten uber die Benutzeroberflache erstellt werden mussen.

Im Vergleich zum System der Mentasys GmbH ergibt sich bei der Modellierung uberdie Benutzeroberflache ein entscheidender Vorteil. Jedes weitere System kann schnel-ler und mit einer geringeren Fehlerhaufigkeit realisiert werden, da auf die Richtigkeitvon Referenzen innerhalb einer Vielzahl von XML-Dateien nicht geachtet werdenmuss. Dieser Gesichtspunkt ist fur eine schnelle Entwicklung eines Systems fur dieMentasys GmbH nicht unerheblich. Daruberhinaus ist der Editor OntoEdit fur dieModellierung von Ontologien gut zu bedienen und erleichtert das methodische Ent-wickeln.

Allerdings ist fur den Schritt zu einem Produktivsystem unerlasslich, dass die alter-native Modellierung von Relationen, wie sie in den Abschnitten 7.1 und 7.2.2 erlau-tert wurde, uber die Benutzeroberflache moglich ist. Dies wird aber von der Firma

62 8. Zusammenfassung und Ausblick

Ontoprise, wie bereits erwahnt, geplant. Der Aufwand ein umfangreiches System zurealisieren wurde sich erheblich verringern, da die Konzepte CASE und ATTRIBU-TE und ihre Instanzen nicht mehr benotigt werden wurden.

Ein weiterer Vorteil der Modellierung mit Ontologien ist, dass die Standardbegrun-dungen anhand der selektierten Aspekte und den festgelegten Textbausteinen desBasissystems, siehe Abschnitt 7.8.1, generiert werden. D.h. im Vergleich zum Systemder Mentasys GmbH, bei dem fur jedes neue System Begrundungen des Modellierersin Form von XML-Dateien erstellt werden mussen, kann hier erheblich XML-Codeund Zeit gespart werden.

Die Moglichkeit Datenbanken und XML-Dateien zu integrieren, sowie Ontologienmiteinander zu verbinden steigert die Effizienz, da eventuell schon existierende Mo-dellierungen oder Produktkataloge in Form von Datenbanken oder XML-Dateienin ein neues System ubernommen werden konnen. Hier hilft es uber Frame-Logikzusatzliche Axiome erstellen zu konnen, welche Bedingungen fur die Integration auf-erlegen.

8.2 Qualitat des Systems

Die Moglichkeit Programme in Java uber eine Schnittstelle (BuiltIn) einzubinden,erlaubt einen hohen Grad an Flexibilitat, da nicht die komplette Funktionalitat einesBasissystems mit Ontologien allein implementiert werden kann. So sind im Rahmendieser Arbeit, siehe die Abschnitte 7.5, 7.6 und 7.8.1, BuiltIns implementiert worden,die bequem innerhalb der Axiome verwendet werden und die Funktionalitat erwei-tern. Fur ein Produktivsystem ist folglich die Moglichkeit gegeben ein Java Frame-work fur Bewertungsfunktionen und Textgenerierungsfunktionen zu implementieren,was die Qualitat des Systems steigert.

Es konnen Anfragen an die Ontologie in OntoEdit gestellt werden, was eine Evalu-ierung wahrend der Entwicklung ermoglicht. Die eigens entwickelten BuiltIns, undsomit die Evaluierung im Zusammenspiel mit der Ontologie, konnten jedoch nuruber Starten von OntoBroker mit den jeweiligen Dateien realisiert werden. Idealware es, wenn die BuiltIns bei Bedarf unmittelbar in OntoEdit eingebunden werdenkonnten, da die Standard-BuiltIns der Firma Ontoprise, welche auch in OntoEditzur Verfugung stehen, nicht alle Funktionalitaten abdecken.

Die Moglichkeit des ’Meta-Inferencing’, siehe Abschnitt 7.8.2, erlaubt es den Verkauf-prozess, siehe Kapitel 6, ideal zu unterstutzen, da die abgeleiteten Resultate besseranalysiert werden konnen. Spezielle Begrundungen konnen daruberhinaus vielfalti-ger gestaltet werden, da man fur das Ableiten einer Erklarung Strategien entwerfenkann. Im Vergleich zum System der Mentasys GmbH ergibt sich mit dieser Technikdie Moglichkeit eine reichhaltigere und individuellere Beratung zu erreichen.

Jedes Recommender System hat in Abhangigkeit des Produktes andere Schwerpunk-te. Offensichtlich gibt es große Unterschiede zwischen einem System, welches beimVerkauf von Mobiltelefonen berat oder einem Softwarelizenzberater. Es ist nicht ab-sehbar, welche Anpassungen in Zukunft bei der Modellierung notwendig sein werden.Oft werden derzeit bei der Mentasys GmbH aufwendige Veranderungen im Basis-system bei Anpassungen durchgefuhrt. Der Entwurf bietet jedoch einen hohen Grad

8.3. Ausblick 63

an Flexibilitat, da weitere Axiome, BuiltIns oder das ’Meta-Inferencing’ reichhaltigeMoglichkeiten bieten Anpassungen vorzunehmen, ohne das Basissystgem verandernzu mussen. Deswegen ist jedes System auch leicht skalierbar, da das Hinzufugen vonAspekten oder Parametern uber die genannten Moglichkeiten bequem anzupassenist.

Uber die Performance bei der Generierung von Antworten lasst sich schwer eineAussage treffen, da das System nicht die Große eines umfangreichen Systems derMentasys GmbH hat. Es ist jedoch moglich bei OntoBroker unterschiedliche Strate-gien bezuglich Zugangsrate, Datenveranderungsrate und Anzahl an benotigten Re-geln umzusetzen, um die Performance bezuglich der Anwendung zu optimieren. DesWeiteren konnen Anfragen im Voraus berechnet oder im Cache bereitgestellt werden.

8.3 Ausblick

Visionen, welche im Rahmen dieser Arbeit entstanden sind, seien im Folgenden ge-nannt. Zum einen konnte mit dem realisierten Modell die Tauglichkeit untersuchtwerden, ob ein Beratungsprozess auch im Sinne eines Konfiguratorsystems reali-siert werden kann. Um dies mit dem entstandenen Basismodell zu realisieren, bietetsich an mehrere Ontologien mit unterschiedlichen ’Namespaces’ zusammenszustellen(Ontomapping, siehe Abschnitt 2.3). Hierbei konnen zusatzliche Axiome die Zusam-menstellungen der Produkte bzw. Bestandteile in Abhangigkeit der Benutzerprafe-renzen uberprufen. Fur weiterfuhrende Literatur zu diesem Thema siehe [MSS03].

Dialogstrategien, wie in 3.2.1 definiert, konnten uber die Technik des ’Meta-Inferencing’implementiert werden, um die in Tabelle 6.1 des Kapitel 6 definierten Personlichkeit-stypen mit individuell angepassteren Argumentationen beim Kaufprozess zu bera-ten. Weiter bestunde die Moglichkeit Cross-Selling Mechanismen einzubauen, welchedie gesetzten Praferenzen des Benutzers analysieren und beim Kauf des jeweiligenProduktes erganzende Produkte anbieten.

Schließlich konnten Ontologien auch dafur verwendet werden, lexikalische und gram-matikalische Unterstutzung bei der Erzeugung des Textes zu geben, was eine ab-wechslungsreichere Gestaltung von Erklarungen wahrend der Beratung ermoglichenwurde.

64 8. Zusammenfassung und Ausblick

A. Die Axiome

A.1 Baumkonfiguration

FORALL aspect1,aggregationvalue1

aspect1:AGGREGATIONASPECT[hasAggregationValue->>aggregationvalue1]

<- aspect1:QUESTION_ASPECT[hasPreference->>aggregationvalue1].

Tabelle A.1: Axiom 1 Aggregationswerte der Questionaspekte

FORALL aggregationaspect1,aggregationaspect2,weight1,

aggregationvalue1,aggregationvalue2,selectedcase1

aggregationaspect2:ASPECT[hasWeight->>weight1;

hasAggregationValue->>aggregationvalue1]

<- aggregationaspect1:AGGREGATION_ASPECT[hasAspect->>aggregationaspect2;


aggregationvalue2]


hasAspect->>aggregationaspect2;

needAggregationValue->>aggregationvalue1

inCaseOf->>aggregationvalue2].

Tabelle A.2: Axiom 2 Case Aggregationaspekte

66 A. Die Axiome


selectedcase1,aggregationvalue1,doubleparameter1


and Parameter(ratingaspect1,doubleparameter1)

<- aggregationaspect1:AGGREGATION_ASPECT[hasAspect->>ratingaspect1;

hasAggregationValue->

aggregationvalue1]





needParameterDouble->>doubleparameter1].

Tabelle A.3: Axiom 3 Casebestimmung Ratingaspekt (Parameter Double)


selectedcase1,aggregationvalue1,stringparameter1


and Parameter(ratingaspect1,stringparameter1)

<- aggregationaspect1:AGGREGATION_ASPECT[hasAspect->>ratingaspect1;


aggregationvalue1]




inCaseOf->>aggregationvalue1


Tabelle A.4: Axiom 4 Casebestimmung Ratingaspekt (Paramter String)

A.1. Baumkonfiguration 67

FORALL aggregationaspect1,name1,aggregationvalue1,

weight1,ratingaspect1,selectedcase1,doubleparameter1

Parameter(ratingaspect1,doubleparameter1)

<- aggregationaspect1:AGGREGATION_ASPECT[hasName->>name1;


aggregationvalue1]

and ratingaspect1:RATING_ASPECT[hasName->>name1]

and selectedcase1:CASE[hasAspect->>aggregationaspect1;


needParameterDouble->>doubleparameter1].

Tabelle A.5: Axiom 5 Casebestimmung Sonderfall (Parameter Double)

FORALL aggregationaspect1,name1,aggregationvalue1,

weight1,ratingaspect1,selectedcase1,stringparameter1

Parameter(ratingaspect1,stringparameter1)

<- aggregationaspect1:AGGREGATION_ASPECT[hasName->>name1;


aggregationvalue1]

and ratingaspect1:RATING_ASPECT[hasName->>name1]

and selectedcase1:CASE[hasAspect->>aggregationaspect1;



Tabelle A.6: Axiom 6 Casebestimmung Sonderfall (Parameter String)

68 A. Die Axiome

FORALL questionaspect1,aggregationvalue1,weight1,selectedcase1

questionaspect1:QUESTION_ASPECT[hasWeight->>weight1]

<- questionaspect1:QUESTION_ASPECT[hasAggregationValue->>aggregationvalue1]

and selectedcase1:CASE[hasAspect->>questionaspect1;


needWeight->>weight1].

Tabelle A.7: Axiom 7 Casebestimmung Questionaspekt

FORALL ratingaspect1,parameter1,parameterliste1

ratingaspect1:RATING_ASPECT[hasParameter->>parameterliste1]

<- Parameter(ratingaspect1,parameter1)


and not equal(parameter1,nil)

and list(ratingaspect1,parameter1,parameterliste1).

Tabelle A.8: Axiom 8 Parameterliste

A.2. Rating 69

A.2 Rating

FORALL product1,ratingaspect1,doublevalue1,returnvalue1,



<- product1:PRODUCT[hasAttribute->>attribute1]

and ratingaspect1:RATING_ASPECT[hasRatingFunction->>ratingfunction1;


and attribute1:ATTRIBUTE[hasValueDouble->>doublevalue1;


and RatingFunction(parameterliste1,doublevalue1,ratingfunction1,returnvalue1).

Tabelle A.9: Axiom 9 Rating (Parameter Double)

FORALL product1,ratingaspect1,stringvalue1,returnvalue1,






and attribute1:ATTRIBUTE[hasValueString->>stringvalue1;


and RatingFunction(parameterliste1,stringvalue1,ratingfunction1,returnvalue1).

Tabelle A.10: Axiom 10 Rating (Parameter String)

70 A. Die Axiome

FORALL product1,ratingaspect1,attributetype1,returnvalue1,

ratingfunction1,attribute1,parameterliste1,value1





and attribute1:ATTRIBUTE[hasValue->>attributetype1;


and attributetype1:PRODUCT_ATTRIBUTE_TYPE[hasValue->>value1]

and RatingFunction(parameterliste1,value1,ratingfunction1,returnvalue1).

Tabelle A.11: Axiom 11 (Parmeter komplexer Attributtyp)

A.3 Aggregation

FORALL product1,aspect1,weight1,returnvalue1,

aspect2,aggregationliste1,productid1

MakeAggregation(product1,aspect1,aggregationliste1)

<- aspect1:ASPECT[hasAspect->>aspect2]

and ReturnValue(product1,aspect2,returnvalue1)

and aspect2:ASPECT[hasWeight->>weight1]


and list(su(aspect1,product1),p(weight1,returnvalue1,productid1),

aggregationliste1).

Tabelle A.12: Axiom 12 Aggregationliste

A.4. Fitnesswerte 71

FORALL aspect2,aspect1,numberaspect1

aspect1:ASPECT[hasNumberAspect->>numberaspect1]


and count(aspect1,aspect2,numberaspect1).

Tabelle A.13: Axiom 13 Anzahl Unteraspekte

FORALL aspect1,aggregationliste1,returnvalue1,product1,numberaspect1

ReturnValue(product1,aspect1,returnvalue1)

<- MakeAggregation(product1,aspect1,aggregationliste1)


and aspect1:ASPECT[hasNumberAspect->>numberaspect1]

and Aggregation(aggregationliste1,numberaspect1,returnvalue1).

Tabelle A.14: Axiom 14 Aggregation

A.4 Fitnesswerte






hasFitnessName->>’Over_Satisfy’]



Tabelle A.15: Axiom 15 Fitness ’OverSatisfy’

72 A. Die Axiome






hasFitnessName->>’Satisfy’]



Tabelle A.16: Axiom 16 Fitness ’Satisfy’






hasFitnessName->>’Not_Satisfy’]



Tabelle A.17: Axiom 17 Fitness ’NotSatisfy’

A.5. Inhaltsbestimmung 73

A.5 Inhaltsbestimmung


fitnessvalue1,condition1,containername1,

assistanttext1,productid1,product1







and concat(assistanttext1,aspectname1,reason1)

and container1:QUALIFICATION_CONTAINER[hasFitness->>fitnessvalue1;

hasCondition->>condition1;



Tabelle A.18: Axiom 18 Container (Eignung)


fitnessvalue1,containername1,assistanttext1,productid1,product1

Container(containername1,aspect1,product1,fitnessvalue1,prio1,aspectname1)



hasWinnerProduct->>productid1]



and container1:COMPARE_CONTAINER[hasFitness->>fitnessvalue1;



Tabelle A.19: Axiom 19 Container (Vergleich)

74 A. Die Axiome


fitnessvalue1,condition1,containername1,assistanttext1,

productid1,product1


<- apsect1:ASPECT[hasReasonPriority->>prio1;




and ReturnFitnessValue(product1,apsect1,fitnessvalue1)

and container1:CONFLICT_CONTAINER[hasFitness->>fitnessvalue1;


hasPriority->>prio1;

hasReason->>assistanttext1;

hasCondition->>condition1]

and concat(assistanttext1,aspectname1,reason1).

Tabelle A.20: Axiom 20 Container (Konflikt)

FORALL product1,aspect1,fitnessvalue1,aspect2,

prio1,aspectname1,containername1,container1

ContainerSuccessor(containername1,aspect1,product1,fitnessvalue1,prio1,

aspectname1)


and aspect2:ASPECT[hasName->>aspectname1;

hasReasonPriority->>prio1]


and container1:JUSTIFICATION_CONTAINER[hasFitness->>fitnessvalue1;

hasName->>containername1].

Tabelle A.21: Axiom 21 Rechtfertigung (Standpunkt uber beste Unteraspekte)

FORALL product1,reason1,prio1,reasonliste1,

containername1,aspect1,fitnessvalue1

PreListReason(product1,reasonliste1,containername1)

<- Container(containername1,aspect1,product1,fitnessvalue1,prio1,reason1)

and list(u(product1,containername1),p(prio1,reason1),reasonliste1).

Tabelle A.22: Axiom 22 Begrundungsliste

A.5. Inhaltsbestimmung 75

FORALL product1,reasonliste1,reasonliste2,containername1

SortListReason(product1,reasonliste2,containername1)

<- PreListReason(product1,reasonliste1,containername1)

and Sort(reasonliste1,reasonliste2).

Tabelle A.23: Axiom 23 (Sortierung)

FORALL product1,reason1,prio1,name1,reasonliste1,

containername1,aspect1,fitnessvalue1

SortListReason(product1,reasonliste1,containername1)

<-

ContainerSuccessor(containername1,aspect1,product1,fitnessvalue1,prio1,reason1)

and aspect1:ASPECT[hasName->>name1]

and list(u(product1,containername1,aspect1),p(name1,reason1),reasonliste1).

Tabelle A.24: Axiom 24 (Begrundungsliste Rechtfertigung)

FORALL textframe1,textframe2,reasontemplate1,product1,

returnreason1,templatename1,reasonliste1,containername1,

numberreason1,reasonfunction1,productid1

Reason(productid1,returnreason1,templatename1)

<- reasontemplate1:REASONING_TEMPLATE[hasFrame_1->>textframe1;

hasFrame_2->>textframe2;

hasNumberReason->>numberreason1;

hasContainer->>containername1;

hasName->>templatename1;

hasReasonFunction->>reasonfunction1]

and SortListReason(product1,reasonliste1,containername1)


and Reasoning(reasonliste1,textframe1,textframe2,numberreason1,

reasonfunction1,returnreason1).

Tabelle A.25: Axiom 25 Textgenerierung

76 A. Die Axiome

FORALL aspect1,product1,returnvalue1,inversereturnvalue1,

ratingliste1,aspectname1,productid1

PreRating(aspectname1,ratingliste1,Gewinner)

<- ReturnValue(product1,aspect1,returnvalue1)


and aspect1:ASPECT[hasName->>aspectname1]

and evaluable_(inversereturnvalue1,-(1,returnvalue1)

and list(aspect1,su(inversereturnvalue1,aspectname1,productid1),ratingliste1).

Tabelle A.26: Axiom 26 Gewinnerliste

FORALL containername1,ratingliste1,ratingliste2,apsectname1

Rating(apsectname1,ratingliste2,containername1)

<- PreRating(apsectname1,ratingliste1,containername1)

and Sort(ratingliste1,ratingliste2).

Tabelle A.27: Axiom 27 Gewinnerliste

FORALL aspectname1,ratingliste1,containername1,number1,productid1,aspect1

aspect1:ASPECT[hasWinnerProduct->>productid1]

<- Rating(aspectname1,ratingliste1,containername1)

and indexinlist(su(number1,aspectname1,productid1),ratingliste1,0)

and aspect1:ASPECT[hasName->>aspectname1].

Tabelle A.28: Axiom 28

B. Die Relationen und Konzeptedes Basissystems inFrame-Logik

B.1 Produktraum

PRODUCT::PRODUCT_SPACE_ELEMENT.

ATTRIBUTE::PRODUCT_SPACE_ELEMENT.

PRODUCT_ATTRIBUTE_TYPE::PRODUCT_SPACE_ELEMENT.

PRODUCT[hasProductID=>STRING;

hasAttribute=>>ATTRIBUTE].

ATTRIBUTE[hasRatingAspect=>RATING_ASPECT;

hasValueType=>PRODUCT_ATTRIBUTE_TYPE;

hasValueDouble=>DOUBLE;

hasValueString=>STRING].

PRODUCT_ATTRIBUTE_TYPE[hasValue=>STRING].

B.2 Bedurfnisraum

ASPECT::NEEDS_SPACE_ELEMENT.

QUESTION_ASPECT::ASPECT.

AGGREGATION_ASPECT::ASPECT.

RATING_ASPECT::ASPECT.

SCENARIO_ASPECT::ASPECT.

FITNESS_CLASS::NEEDS_SPACE_ELEMENT.

CASE::NEEDS_SPACE_ELEMENT.

78 B. Die Relationen und Konzepte des Basissystems in Frame-Logik

ASPECT[hasName=>STRING;

hasWeight=>DOUBLE;

hasNumberAspect=>DOUBLE;

hasWinnerProduct=>>STRING;

hasReasonPriority=>STRING].

QUESTION_ASPECT[hasPreference=>STRING;

hasAspect=>>ASPECT].

AGGREGATION_ASPECT[hasAggregationValue=>STRING;

hasAspect=>>ASPECT].

RATING_ASPECT[hasRatingFunction=>DOUBLE;

hasParameter=>DOUBLE].

SCENARIO_ASPECT[hasAspect=>>ASPECT].

FITNESS_CLASS[hasFitnessValue=>INTEGER;

hasFitnessName=>STRING;

hasMinRating=>DOUBLE;

hasMaxRating=>DOUBLE].

CASE[needWeight=>DOUBLE;

needAggregationValue=>STRING;

needParameterString=>>STRING;

needParameterDouble=>>DOUBLE;

hasAspect=>ASPECT;

inCaseOf=>STRING].

B.3 Begrundungsraum

REASONING_TEMPLATE::REASONING_SPACE_ELEMENT.

REASONING_DATA_CONTAINER::REASONING_SPACE_ELEMENT.

QUALIFICATION_CONTAINER::REASONING_DATA_CONTAINER.

CONFLICT_CONTAINER::REASONING_DATA_CONTAINER.

COMPARE_CONTAINER::REASONING_DATA_CONTAINER.

JUSTIFICATION_CONTAINER::REASONING_DATA_CONTAINER.

REASONING_SPACE_ELEMENT[hasName=>STRING]

REASONING_TEMPLATE[hasFrame_1=>STRING;

hasFrame_2=>STRING;

hasNumberReason=>DOUBLE;

hasContainer=>>STRING;

hasReasonFunction=>DOUBLE].

B.3. Begrundungsraum 79

REASONING_DATA_CONTAINER[hasCondition=>>STRING;

hasConditionAspect=>>ASPECT;

hasFitness=>>FITNESS_CLASS;

hasPriority=>DOUBLE;

hasReason=>>STRING].

80 B. Die Relationen und Konzepte des Basissystems in Frame-Logik

Literatur

[AHO90] S. Abu-Hakima and F. Oppacher. Improving explanations in knowledge-based systems: Rationale. Knowledge Acquisition, 2:301 – 343, December1990.

[AMO+03] Jurgen Angele, Eddie Monch, Henrik Oppermann, Steffen Staab, andDirk Wenke. Ontology-based query and answering in chemistry: Onto-nova @ project halo. In Proceedings of the 2nd International SemanticWeb Conference (ISWC2003), October, 2003, Sanibel Island, FL, USA,LNCS, pages 913–928. Springer, 2003.

[BLFD99] T. Berners-Lee, M. Fischetti, and T. M. Dertouzos. Weaving the Web:The Original Design and Ultimate Destiny of the World Wide Web byits Inventor. Harpur, 1999.

[BMR+98] Regina Barzilay, Daryl McCullough, Owen Rambow, Jonathan DeChri-stofaro, Tanya Korelsky, and Benoit Lavoie. A new approach to expertsystem explanations. In Eduard Hovy, editor, Proceedings of the NinthInternational Workshop on Natural Language Generation, pages 78–87.Association for Computational Linguistics, New Brunswick, New Jersey,1998.

[BS84] B. G. Buchanan and E. H. Shortliffe. Rule-Based Expert Systems.Addison-Wesley, 1984.

[BSR96] Kevin Knight Bill Swartout, Ramesh Patil and Tom Russ. Toward distri-buted use of large-scale ontologies. In Proceedings of the Tenth Knowled-ge Acquisition for Knowledge-Based Systems Workshop,November 9-14,1996. Banff, Alberta, Canada. Springer, 1996.

[Bur02] Robin Burke. Hybrid recommender systems:survey and experiments.User Modeling and User-Adapted Interaction, 12(4):331 – 370, 2002.

[CB89] Josephson J.R. Chandrasekaran B., Tanner M.C. Explaining controlstrategies in problem solving. IEEE Expert, 4(1):9–24, 1989.

[Cha93] B. Chandrasekaran. Generic tasks in knowledge-based reasoning: High-level building blocks for expert system design. In B. G. Buchanan andD. C. Wilkins, editors, Readings in Knowledge Acquisition and Learning:Automating the Construction and Improvement of Expert Systems, pages170–177. Kaufmann, San Mateo, CA, 1993.

82 Literatur

[Dal92] Hercules Dalianis. A method for validating a conceptual model by natu-ral language discourse generation. In Pericles Loucopoulos, editor, Ad-vanced Information Systems Engineering, CAiSE’92, Manchester, UK,May 12-15, 1992, Proceedings, volume 593 of Lecture Notes in ComputerScience. Springer, 1992.

[DEFS98] Stefan Decker, Michael Erdmann, Dieter Fensel, and Rudi Studer. Onto-broker: Ontology based access to distributed and semi-structured infor-mation. Technical Report 382, University of Karlsruhe, Institute AIFB,76128 Karlsruhe, Germany, NOV 1998.

[DJ97] Hercules Dalianis and Paul Johannesson. Explaining conceptual mo-dels - an architecture and design principles. In David W. Embley andRobert C. Goldstein, editors, Conceptual Modeling - ER ’97, 16th Inter-national Conference on Conceptual Modeling, Los Angeles, California,USA, November 3-5, 1997, Proceedings, volume 1331 of Lecture Notes inComputer Science, pages 215–228. Springer, 1997.

[DJ98] Hercules Dalianis and Paul Johannesson. Explaining conceptual models- using toulmin’s argumentation model and rst. In The Third Interna-tional workshop on the Language Action Perspective on CommunicationModelling (LAP98) , Stockholm, Sweden, June 25-26, 1998, Proceedings,Lecture Notes in Computer Science, pages 131–140, 1998.

[Ell89] C. Ellis. Explanation in intelligent systems, pages 108–126. New Yorket al.: Halsted Press, 1989.

[GDS01] Russell Greiner, Christian Darken, and N. Iwan Santoso. Efficient rea-soning. ACM Computing Surveys, 33(1):1–30, 2001.

[Gru98] T. R. Gruber. A translation approach to portable ontology specification.Knowledge Acquisition, 5(2):21–66, 1998.

[Gua98] N. Guarino. Formal ontology and information systems. In Proceedings ofthe 1st International Conference on Formal Ontologies in InformationSystems, FOIS’98, Trento, Italy, pages 3–15, 1998.

[Gul96] Jon Atle Gulla. A general explanation component for conceptual mo-deling in case environments. Source ACM Transactions on InformationSystems (TOIS), 14(3):297 – 329, July 1996.

[Hor91] H. Horacek. Towards finding the reasons behind: Generating the con-tent of explanation. In T. Christaller, editor, GWAI-91: Proc. der 15.Fachtagung fur Kunstliche Intelligenz, Bonn, Deutschland, pages 96–105.Springer, Berlin, Heidelberg, 1991.

[Hor92] Helmut Horacek. Ian integrated view of text planning. In Robert Dale,Eduard H. Hovy, Dietmar Rosner, and Oliviero Stock, editors, Aspectsof Automated Natural Language Generation, 6th International Workshopon Natural Language Generation, Trento, Italy, April 5-7, volume 587of Lecture Notes in Computer Science, pages 29–44. Springer, 1992.

Literatur 83

[JGL83] James Weiner Joseph Goguen and Charlotte Linde. Reasoning and natu-ral explanation. International Journal of Man-Machine Studies, 19:521–559, 1983.

[KLW90] Michael Kifer, Georg Lausen, and James Wu. Logical foundations ofobject-oriented and frame-based languages. Technical Report TR-90-003, 1, 1990.

[LP97] James C. Lester and Bruce W. Porter. Developing and empirically eva-luating robust explanation generators: The KNIGHT experiments. Com-putational Linguistics, 23(1):65–101, 1997.

[M.R92] Wick M.R. Reconstructive expert system explanation. Artificial Intelli-gence, 54(1):33–70, 1992.

[MS88] K. R. McKeown and W. R. Swartout. Language generation and explana-tion. In M. Zock and G. Sabah, editors, Advances in Natural LanguageGeneration: An Interdisciplinary Perspective (Volume 1), pages 1–51.Pinter, London, 1988.

[MSS03] Andreas Maier, Hans-Peter Schnurr, and York Sure. Ontology-based in-formation integration in the automotive industry. In Proceedings of the2nd International Semantic Web Conference (ISWC2003), 20-23 Octo-ber 2003, Sundial Resort, Sanibel Island, Florida, USA, volume 2870 ofLNCS, pages 897–912. Springer, 2003.

[Onta] Firma Ontoprise. Flogik tutorial.

[Ontb] Firma Ontoprise. Ontobroker tutorial.

[Ontc] Firma Ontoprise. Ontoedit tutorial.

[S.58] Toulmin S. The Use of arguments. The Cambridge University press,1958.

[SC02] Bauer M. Schmitt C., Dengler D. The maut machine: An adaptive re-commender system. In ABIS Workshop 2002 in Hannover, Germany,2002.

[SKR99] J. Ben Schafer, Joseph A. Konstan, and John Riedl. Recommendersystems in e-commerce. In ACM Conference on Electronic Commerce,pages 158–166, 1999.

[SM93] W.R. Swartout and J.D. Moore. Explanation in second generation expertsystems. In J.-P. Krivine J.-M. David and R. Simmons, editors, SecondGeneration Expert Systems, pages 543–585. Springer Verlag, 1993.

[SM99] R. D. Shankar and M. A. Musen. Justification of automated decision-making: Medical explanation or medical argument? In Proc AMIASymp., pages 395–399, 1999.

84 Literatur

[SR98] Musen M.A. Shankar R.D., Tu S.W. A declarative explanation frame-work that uses a collection of visualization agents. Journal of the Ame-rican Medical Informatics Association, pages 602–606, 1998.

[SSA02] York Sure, Steffen Staab, and Jurgen Angele. Ontoedit: Guiding on-tology development by methodology and inferencing. In Proceedings ofthe International Conference on Ontologies, Databases and Applicationsof SEmantics ODBASE 2002, October 28 - November 1,University ofCalifornia, Irvine, USA, volume 2519 of LNCS, pages 1205–1222, 2002.

[Sut93] Daniel D. Suthers. Preferences for model selection in explanation. InIJCAI, pages 1208–1215, 1993.

[SW91] Moore J. Swartout W., Paris C. Design for explainable expert systems.IEEE Expert, 6(3):58–64, June 1991.

[Swa81] W. R. Swartout. Explaining and justifying expert consulting programs.In Proc. of the 7th IJCAI, pages 815–823, Vancouver, Canada, 1981.

[Swa83] W.R. Swartout. Xplain: A system for creating and explaining expertconsulting programs. Artificial Intelligence, 21(3):285–325, 1983.

[T.93] Maybury M. T. Communicative acts for generating natural languagearguments. In Proceedings of the 11th National Conference on Artifici-al Intelligence. Washington, DC, USA, July 11-15, pages 357–364. TheAAAI Press/The MIT Press, 1993.

[Tan95] Michael C. Tanner. Task-based explanations. Expert Systems with Ap-plications, 8(2):505–512, June 1995.

[T.L80] Saaty T.L. The Analytic Hierarchy Process. McGraw-Hill,Inc., 1980.

[TM93] Chanrasekaran B. Tanner M.C., Keuneke A.M. Explanation using taskstructure and domain functional models. In J.-P. Krivine J.-M. Davidand R. Simmons, editors, Second Generation Expert Systems, pages 586–613. Springer Verlag, 1993.

[Wic92] Michael R. Wick. Expert system in retrospect: A case study in dthevolution of expert system explanation. Journal of Systems and Software,19(2):159 – 169, July 1992.

[Wic93] Michael R. Wick. Second generation expert system explanation. InJ.-P. Krivine J.-M. David and R. Simmons, editors, Second GenerationExpert Systems, pages 614–640. Springer Verlag, 1993.

[Woo98] Bruce A. Wooley. Explanation component of software systems. ACMCrossRoads, 1998.

Empfehlungssysteme mit Ontologien - userpagesstaab/Teaching/MastersTheses/franz... · †...

Documents

Transcript of Empfehlungssysteme mit Ontologien - userpagesstaab/Teaching/MastersTheses/franz... · †...