Zunächst einmal wird die Anwendungsdomäne Diagnostik genauer

Studienarbeit
Kommunikation zweier Agenten in d3web
Raphaela Niklaus
Februar 2003
Betreuer:
Dipl. Inform. Mitchel Berberich
Prof. Dr. Frank Puppe
Lehrstuhl für Künstliche Intelligenz
und angewandte Informatik
Bayerische Julius-Maximilians-Universität Würzburg
People can’t share knowledge
if they don’t speak
a common language“
(T. Davenport, Working Knowledge)
1. Problemumfeld, Motivation und Zielsetzung
In diagnostischen Agentensystemen versuchen mehrere Diagnoseagenten, gemeinsam in
Teamarbeit, ein Diagnoseproblem zu lösen. Ihnen ist es möglich zu agieren („gezieltes
Fragestellen“, „Erstellen von Diagnosen“,…,), und zu
interagieren („Konsultation eines
anderen Agenten“, „Kritik der Lösung eines anderen Agenten“, „Fallabgabe an andere
Agenten“,… und vor allem „Verhandlung über eine bestmögliche Falllösung“), also
miteinander zu kommunizieren.
Ein Problem der Kommunikation ist, dass häufig Daten verschiedener Diagnoseagenten intern
anders repräsentiert werden. D.h. es sind Abbildungen nötig, die die Falldaten der einzelnen
Diagnoseagenten aufeinander abgleichen.
Um die Kommunikation zwischen Diagnoseagenten in dieser Arbeit zu realisieren wird als
erster
Schritt
„die
Kommunikation“
allgemein
untersucht.
Anschließend
wird
die
Anwendungsdomäne „Diagnostik“ genauer betrachtet, und wir werden die allgemeine
Agentenkommunikation auf Diagnoseagenten übertragen.
Darauf aufbauend wird dem Experten unter KnowMe ein Editor zur Verfügung gestellt, in den
er sein Abbildungswissen zur Kommunikation eingeben kann. Zur Durchführung der
Abbildungen wird eine Laufzeitkomponente bereitgestellt.
Zuletzt werden noch einmal alle angewandten Verfahren und die gewonnenen Ergebnisse
zusammengefasst. In einer Diskussion werden anschließend Vorteile und Nachteile gezeigt und
auch Verbesserungsvorschläge und Ausblicke erläutert.
-2-
2. Grundlagen
Beschreibung des Problembereichs und Begriffsbestimmung
Zunächst wird nun die Anwendungsdomäne Diagnostik genauer untersucht.
Die „Diagnostik“ charakterisiert
durch bestimmte Eigenschaften den Lösungsprozess für
Probleme. D.h. genauer, dass nach Puppe[90] der Problembereich aus zwei explizit gegebenen
disjunkten Mengen von Problemmerkmalen (Symptomen) und Problemlösungen (Diagnosen),
und aus typischerweise unsicherem Wissen über die Beziehungen zwischen Symptomen und
Diagnosen besteht. Dabei ist ein Problem durch eine eventuell unvollständige Teilmenge der
Symptome charakterisiert und die Lösung eines Problems besteht aus einer oder mehreren
Diagnosen. Wenn die Qualität der Problemlösung durch Erfassung zusätzlicher Symptome
verbessert werden kann, so ist es eine Teilaufgabe der Diagnostik zu bestimmen, ob und welche
zusätzlichen Symptome angefordert werden sollen. Dies kann graphisch anschaulich in
Abbildung 1 dargestellt werden:
X
?
X
X
X
X
X
X X
X
X
X
X
Problemmerkmale
X
Problemlösungen
Abbildung 1: Graphische Darstellung der „Diagnostik“
Diagnostisches Wissen kann unterschiedlich dargestellt und ausgewertet werden.
Es gibt zum Beispiel fallvergleichende (statistische) Diagnosesysteme, modellbasierte
Diagnosesysteme oder heuristische Diagnosesysteme.
In dieser Arbeit werden ausgehend von d3web ausschließlich heuristische (assoziative)
Diagnosesysteme im Bereich der medizinischen Diagnostik verwendet.
Heuristische Diagnosesysteme basieren auf Problemen, bei denen Erfahrungswissen verfügbar
ist. Man hat das Wissen, welche Merkmale oder Merkmalskombinationen mit welcher
Unsicherheit auf Zwischen- und Endlösungen hindeuten.
„Merkmal deutet auf Lösung“ (M -> L mit Unsicherheit x). Es wird die Lösung ausgewählt, die
die höchste Gesamtbewertung auf der Basis der beobachteten Merkmale erzielt.
Da heuristische Diagnosesysteme auf Erfahrungswissen von verschiedenen Experten beruhen,
ist es schwierig die Kombination sehr vieler Einzelbewertungen für eine Lösung überschauen zu
-3-
können. Daher ist die Technik der schrittweisen Abstraktion von Merkmalen zu Lösungen
notwendig. Einzelne Merkmalen, die von jedem Experten auf eine andere Art formuliert
werden, können zu einem Merkmal zusammengefasst werden.
Z.B.
Patient sagt: Mein Puls ist sehr schnell.
Arzt sagt:
Sie haben einen Puls von über 90 Schlägen pro Minute.
Diese beiden Aussagen können zusammengefasst werden zu dem Begriff „Tachykardie“.
Jeder Agent stellt ein Diagnosesystem dar, das selbständig Probleme in seinem Problembereich
lösen kann. Es gibt unzählige Definitionen von Agenten, in dieser Arbeit wird die allgemeine
Definition nach [Russelt und Norvig, 95]verwendet:
„For each possible percept sequence, an ideal rational agent should do whatever action is expected to maximize its performance measure, on the basis of the evidence provided by the percept sequence and whatever built-in knowledge the agent has.”
Übertragen auf diagnostische Agentensysteme heißt das, dass jeder Diagnoseagent seine eigene
Wissensbasis besitzt.
Eine Wissensbasis umfasst die zur Problemlösung notwendige Information z.B. Wissen,
Dokumente, Merkmalsmenge, Regeln, Diagnosen.
Dabei versteht man unter Wissen nach [Puppe, 90], Daten mit impliziten oder expliziten
Angaben über ihre Verwendung zur Lösung von Problemen.
Regeln (z.B. A->C) haben immer eine Vorbedingung und eine Aktion, welche dann ausgeführt
werden darf, wenn die Vorbedingung erfüllt ist.
Der Agent benutzt seine Wissensbasis autonom, jedoch auch abhängig von der Kommunikation
mit anderen durch Wissensaustausch zur Problemlösung.
D.h., das mitgegebene Wissen ermöglicht es dem Diagnoseagenten Teilprobleme zu lösen,
jedoch ist es hier für die Lösung diagnostischer Probleme unverzichtbar Informationen
untereinander im „Team“ auszutauschen.
Jeder Agent besitzt also seine eigene Wissensbasis mit seinem persönlichen Wissen. Zusätzlich
gibt es noch eine für alle Agenten gemeinsam Terminologie-Wissensbasis, die in unserem
System den Kern aller Verbindungen, im Idealfall vollständig vom Benutzer abgekapselt,
darstellt. Siehe dazu auch Abbildung 2.
-4-
AGENT1
AGENT2
Wissensbasis1
Wissensbasis2
„Teminologie-Wissensbasis“
AGENT3
AGENT4
Wissensbasis3
Wissensbasis4
Abbildung
2:
Kommunikation
von
Agenten
über
eine
gemeinsame
Terminologie-Wissensbasis
Es können also alle Wissenslieferanten selbst ihr Abbildungswissen von den einzelnen Agenten
zur Terminologie-Wissenbasis eingeben oder verändern. Das heißt, um bei unterschiedlichen
internen Begriffswelten eine gemeinsame Terminologie zur Kommunikation verwenden zu
können, müssen jeweils die Daten der verschiedenen Agenten in eine gemeinsame
Terminologie übersetzt werden.
Das eigentliche Hauptziel dieser Arbeit ist es also Möglichkeiten zu schaffen, Abbildungen
zwischen den Daten des Agenten und er Terminologie-Wissensbasis zu erstellen, um dadurch
semantische Unterschiede auszugleichen.
Die wichtigste Grundlage für die Kommunikation, also für den Datenaustausch, ist die
Erstellung einer gemeinsamen Terminologie/Ontologie zwischen den Diagnoseagenten.
Eine Terminologie [Puppe, 90] besteht aus Begriffen, die wichtige Konzepte des Fachbereichs
bezeichnen und im Gegensatz zur Alltagssprache präzise definiert sind.
Die Ontologie spezifiziert nach [WS 2001/2002 Vorlesung Verteilte KI] bereits die Objekte,
Konzepte und Beziehungen in einem bestimmten (realistisch begrenzten) Gebiet – „Vokabular“.
-5-
Die Entwickler sollen sich bereits vor Beginn der Agentenentwicklung auf eine möglichst
einheitliche Terminologie einigen, die dann auch als agenteninterne Terminologie Verwendung
findet. Damit wird die spätere Übersetzung erheblich vereinfacht.
Z.B.:
TEMINOLOGIE VON AGENT 1: „TEMPERATUR = ÜBER 37“
TEMINOLOGIE VON AGENT 2: „TEMPERATUR = ERHÖHT“
So kann beides auf den Begriff „FIEBER“ gesetzt werden.
Aus Gründen der Normierung wird dem Benutzer in dem entwickelten Editor dieser Arbeit zum
einen die Möglichkeit geboten alle bereits definierten Begriffe in der TerminologieWissensbasis anzuschauen und diese in der eigenen Wissensbasis exakt zu verwenden. Er kann
Teilbäume der Terminologie direkt in seinen Wissensbasis übernehmen oder eigene Begriffe,
die noch nicht in der Terminologie vorhanden sind dort hinzufügen.
Die Kernelemente der Wissensrepräsentation sind Merkmale und Merkmalsabstraktionen:
Es gibt hierzu verschiedene Typen:
Multiple-Choice
Welche Sprachen sprichst du?
O Englisch
O Deutsch
O Französisch
O Japanisch
O unbekannt
O nein/sonstiges
Der Benutzer kann eine/mehrere Sprachen oder „unbekannt“ oder „nein/sonstiges“ auswählen.
Wählt er unbekannt oder nein/sonstiges so kann er keinen Sprache auswählen. Diese drei
Gruppierungen schließen sich gegenseitig aus.
-6-
One-Choice
Wo ist dein Geburtsort?
O Berlin
O Würzburg
O Rom
O nein/sonstiges
Der Benutzer hat nur eine Auswahlmöglichkeit. Er markiert entweder
eine der drei Städte oder „nein/sonstiges“
Boolsch
Bist du älter als 18 Jahre
O ja
O nein
Boolesche Werte stellen eine Art von One-Choice-Typ dar.
Der Benutzer hat nur eine Auswahlmöglichkeit, d.h. er muss entweder ja oder nein markieren.
Numerisch
Wie alt bist Du
O __________
Bei dem numerischen Typ muss der Benutzer seinen Antwortwert selbst eingeben, Hier z.B. 24.
Gibt der Benutzer keinen oder einen falschen, also nicht definierten Begriff ein, so muss eine
Anzeige erscheinen, die ihn darauf hinweist und ihn zu einer erneuten, anderen Eingabe
auffordert.
-7-
Lösungsklassen und Lösungen
-
Status (etabliert, unsicher oder ausgeschlossen)
Dargestellt werden die Abbildungen zwischen den Daten der einzelnen Agenten und der
Teminologie-Wissensbasis im Editor in Tabellen.
In diesen Tabellen stehen die Quell-Merkmale, von denen ausgegangen wird in der ersten Zeile
und die Ziel-Merkmale, auf die abgebildet wird, in der ersten Spalte.
Nun kann man entsprechend der Zeile und der Spalte Abbildungen durch „ankreuzen“
definieren.
Hier nun einige Beispiele:
Welchen Ausbildungsabschluss hast Du?
Abitur
Abitur
Diplom
Realschule
Hauptschule
X
anderen Abschl.
1X
2X
3X
keinen Abschl.
Die Tabelle behandelt die Abbildung einer One-Choice-Frage auf eine
Multiple-Choice-Frage.
Die erste Spalte zeigt drei Abschlussmöglichkeiten als Antwortmöglichkeiten der
One-Choice-Antworten.
Die erste Zeile zeigt vier Abschlussmöglichkeiten als Antwortmöglichkeiten der
Multiple-Choice-Antworten.
Abgebildet wird „Abitur“ auf „Abitur“.
Die Rückabbildung von „Abitur“ kann exakt auf „Abitur“ definiert werden.
Abgebildet wird „Diplom“ oder „Realschule“ oder „Hauptschule“ auf „anderen Abschluss“.
In diesem Fall ist von „anderen Abschluss“ keine exakte Rückabbildung möglich.
Entweder kann „anderen Abschluss“ auf „Diplom“ oder auf „Realschule“ oder auf
„Hauptschule“ abgebildet werden.
-8-
Auf „keinen Abschluss“ wird nichts abgebildet.
Welchen möchtest Du trinken?
Wasser Apfelsaft Orangensaft
Apfelsaftschorle
1X
Orangensaftschorle
1X
1X
1X
Nein/sonstiges
Die Tabelle behandelt die Abbildung einer One-Choice-Frage auf eine
Multiple-Choice-Frage.
Die erste Spalte zeigt vier Abschlussmöglichkeiten als Antwortmöglichkeiten der
One-Choice-Antworten.
Die erste Zeile zeigt vier Abschlussmöglichkeiten als Antwortmöglichkeiten der
Multiple-Choice-Antworten.
Abgebildet wird „Wasser“ und „Apfelsaft“ auf „Apfelsaftschorle“.
Es muss also beides, „Wasser“ und „Apfelsaft“, markiert sein, um sie auf „Apfelsaftschorle“
abzubilden.
Bei der Rückabbildung wird „Apfelsaftschorle“ direkt auf „Wasser“ und „Apfelsaft“
abgebildet.
Abgebildet wird „Wasser“ und „Orangensaft“ auf „Orangensaftschorle“.
Bei der Rückabbildung wird „Orangensaftschorle“ direkt auf „Wasser“ und „Orangensaft“
abgebildet.
Abgebildet wird „Tomatensaft“ auf „Tomatensaft“.
Die Rückabbildung kann exakt von „Tomatensaft“ auf „Tomatensaft“ abgebildet werden.
Es gibt auch die Möglichkeit numerische Werte abzubilden:
Jedoch ist hier das Problem, dass der Benutzer nichts auswählen kann, sondern seinen eigenen
Wert über ein Editor-Fenster eingibt.
Z.B. bei Abbildungen von numerischen Antworten auf numerische Antworten.
Die Frage, „Wie hoch ist die Temperatur? (in Celsius). Ist nun die Temperatur in der
Terminologie-Wissensbasis in Fahrenheit abgespeichert, so muss eine Abbildung des CelsiusWertes auf den Fahrenheit-Wert definiert werden.
Verwirklicht wird dies mit einem zusätzlichen Editor für den Experten, in den er eine Formel
für die Umrechnung eingeben kann.
In diesem Fall muss für die Umrechnung von Celsius in Fahrenheit die Formel
„ 1,8 * (‚den eingegebenen Wert’) + 32“ eingegeben werden.
-9-
Gibt der Benutzer nun seinen Celsius-Wert ein, so wird er anschließend durch die Formel in
Fahrenheit umgewandelt.
Bei Abbildungen von One-Choice auf numerische Werte sieht es folgendermaßen aus:
Wie groß bist Du?
gering
160cm
mittel
groß
sehr groß
X
175cm
X
190cm
X
205cm
X
Die erste Zeile zeigt vier Größenbewertungen als Antwortmöglichkeiten der
One-Choice-Antworten.
Die erste Spalte zeigt vier Größenangaben in cm als Antwortmöglichkeiten der
numerischen Antworten.
Numerische Werte stehen für eine Intervall von null oder einem bereits gegebenen Wert bis
zum dem entsprechenden numerischen Wert.
Abgebildet wird gering auf 0 bis 160cm.
Abgebildet wird mittel auf >160cm bis 175.
Abgebildet wird groß auf >175cm bis 190.
Abgebildet wird sehr groß auf >190cm bis 205 .
Alle Rückabbildungen sind möglich.
Hat man also ausschließlich UND-Verknüpfungen und keine ODER-Verknüpfungen, so ist
immer eine exakte Rückabbildungen möglich. Doch dazu mehr in dem Kapitel „Erweiterung“
- 10 -
Die Durchführung und die anschließende Abspeicherung der Abbildungen werden in XSL
gemacht. Als Beispiel werden nun die oben in Tabellenform gezeigten Beispiele in XSL
abgebildet. Siehe also zum Vergleich jeweils oben.
Welchen Ausbildungsabschluss hast Du?
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<xsl:apply-templates></xsl:apply-templates>
</xsl:template>
<xsl:template match="//Question/Answer[@value='Diplom']">
<Answer value="anderen Abschluss"/>
</xsl:template>
<xsl:template match="//Question/Answer[@value='Realschule’]“>
<Answer value="anderen Abschluss"/>
</xsl:template>
<xsl:template match="//Question/Answer[@value='Hauptschule’]“>
<Answer value="anderen Abschluss"/>
</xsl:template>
<xsl:template match="//Question/Answer[@value='Abitur’]“>
<Answer value="Abitur’]>
</xsl:template>
</xsl:stylesheet>
- 11 -
Was möchtest du trinken?
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<xsl:apply-templates></xsl:apply-templates>
</xsl:template>
<xsl:template match="//Question/Answer[@value='Wasser']">
<xsl:choose>
<xsl:when test="//Question/Answer[@value='Apfelsaft']">
<Answer value="Apfelsaftschorle"/>
</xsl:when>
</xsl:choose>
</xsl:template>
</xsl:template>
<xsl:template match="//Question/Answer[@value='Wasser']">
<xsl:choose>
<xsl:when test="//Question/Answer[@value='Orangensaft']">
<Answer value="Orangensaftschorle"/>
</xsl:when>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
Wie hoch ist deine Temperatur?
Im Beispiel wird 36C in 96,8Fahrenheit umgerechnet.
- 12 -
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<xsl:apply-templates></xsl:apply-templates>
</xsl:template>
<xsl:template match="//Question/Answer[@value<='36']">
<xsl:variable name="fahrenheit" select="1.8*number(@value)+32"></xsl:variable>
<Answer value="{$fahrenheit}"/>
</xsl:template>
</xsl:stylesheet>
Abbildungsmöglichkeiten
Für die Kommunikation zweier Diagnoseagenten werden Abbildungen zwischen der
Terminologie der jeweiligen Agenten und der gemeinsamen Terminologie erstellt, die
Unterschiede in der Wissensrepräsentation aufeinander abgleichen.
Es werden folgende Arten von Abbildungsmöglichkeiten betrachtet:
1:1-Abbildung,
1:n-Abbildung,
n:1-Abbildung,
n:m-Abbildung
Es gibt die Möglichkeit von
 1 : 1 –Abbildungen
d.h. ein Begriff wird genau auf einen anderen Begriff abgebildet
(Identitätsabbildung)
F1
F1
 1 : n –Abbildungen
Ein Begriff kann auf mehrere Begriffe abgebildet werden
F1
F1
F2
F3
- 13 -
 n : 1 –Abbildungen
Mehrere Begriffe können auf einen Begriff abgebildet werden, hier ist das Problem,
sobald die Begriffe durch ein „Oder“ verknüpft sind, ist nicht immer eine
Rückabbildung möglich
F1
F4
WENN F1 UND F2 UND F3
DANN F4
F2
F3
Problem: WENN F1 ODER F2 ODER F3 DANN F4
 m : n –Abbildungen
d.h. mehrere Begriffe können auf mehrere Begriffe abgebildet
werden, aber auch hier gelten die gleichen Probleme wie bei
n : 1 –Abbildungen
F1
F4
F2
F5
F3
F6z
Kann hierbei ein Element auf mehrere Arten hergeleitet werden, so kann teilweise das Problem
entstehen, dass nicht immer eine Rückabbildung möglich ist. Doch dazu genaueres in
4. Erweiterungen.
Verschiedene Kommunikationsarten
Direkte Kommunikation zwischen den Agenten
Bei der direkten Kommunikation von mehreren Agenten untereinander gibt es zwischen je zwei
Agenten einen Kommunikationskanal, d.h. jeder Agent übersetzt seine Sprache direkt in die
Sprache seines Kommunikationspartners. Das setzt auch voraus, dass jeder Agent die
Repräsentation der Falldaten jedes anderen Agenten kennt. Für diese Art der Kommunikation
müssen zwischen je zwei kommunizierenden Agenten zwei Abbildungen definiert werden.
AGENT1
AGENT2
AGENT3
AGENT4
Hier im Beispiel sind 12 Abbildungen notwendig.
- 14 -
Kommunikation über eine „universelle Sprache“
Bei der Kommunikation von mehreren Agenten über eine „universelle Sprache“ werden die
verschiedenen Sprachen aller Agenten in eine gemeinsame Sprache übersetzt. Die Agenten
kommunizieren über diese gemeinsame Sprache miteinander. Es sind also nur Abbildungen von
den einzelnen Agenten in diese „universelle Sprache“ nötig.
AGENT1
AGENT2
„universelle Sprache“
AGENT3
AGENT4
Hier sind genau 8 Abbildungen notwendig.
Um sich nun für eine Kommunikationsart entscheiden zu können, werden zunächst Vorteile und
Nachteile der einzelnen Verfahren aufgezeigt werden.
Vorteile einer „universellen Sprache“:
-
es müssen weniger Abbildungen zum Ausgleich der semantischen Unterschiede
zwischen den einzelnen Agentensprachen erstellt werden
(im Beispiel sind 8 statt 12 Abbildungen notwendig)
die Aktualisierung und Wartung wird vereinfacht
Nachteile einer „universellen Sprache“:
-
kommuniziert jeder Agent über eine universelle Sprache, so leidet die
Gesamtperformance der Problemlösung
Vorteile der „direkten Kommunikation“
-
Agenten können sich bei speziellen Anfragen, Teilproblemen, usw., direkt an den
dafür
zuständigen Agenten wenden, dadurch ist eine bessere Übersetzung möglich
Nachteile der „direkten Kommunikation“
-
je zwei Agenten müssen sich verständigen können, d.h. es müssen Abbildungen von
jedem Agenten zu allen anderen Agenten erstellt werden
(im Beispiel sind 12 statt 8 Abbildungen notwendig)
-
die Aktualisierung und Wartung wird erschwert
- 15 -
Vergleichssysteme für die „Kommunikation von Agenten“
„Ontoprise entwickelt semantische Technologien und Anwendungen. Mit diesen Technologien
können heutige IT Systeme in Ihrer Funktionalität deutlich verbessert werden. Zudem gestalten
wir aktiv die zukünftige Internet-Landschaft. Eine Umgebung, die unsere Sprache spricht und
unseren Anforderungen gerecht wird. Eine Plattform, die den einfachen Austausch von Ideen
unterstützt. Das SemanticWeb™ wird diese Plattform sein. Semantik ist der entscheidende
Schritt von der Informationstechnologie zur Wissenstechnologie. Ontoprise ist führend in der
Entwicklung semantischer Technologien und ist damit in der Position, zukünftige Standards zu
definieren.“
Das Unternehmen „Ontoprise“
Die Ontoprise GmbH, Karlsruhe, entstand 1999 als Spin-Off der Universität Karlsruhe. Das
Unternehmen ist führender Anbieter von semantischen Technologien und Anwendungen. Die
Smarter Knowledge Suite von ontoprise auf Basis semantischer Technologien ermöglicht die
einfache Integration des kompletten Unternehmenswissens aus heterogenen Datenquellen.
Zudem erlaubt sie einen intelligenten Zugriff darauf.
Durch den Einsatz von Wissensmodellen rückt die Bedeutung von Informationen in den
Vordergrund.
Der Einsatz von Smarter Knowledge ermöglicht die einfache Integration, den intelligenten
Zugriff auf Wissen und das Retrieval von Wissen sowie die flexible Wartbarkeit der Systeme,
da diese nicht mühsam programmiert, sondern intuitiv modelliert werden. Die Software ist in
der Lage, Inhalte aus Dokumenten und Datenbanken zu lösen und über regelbasierte
Ableitungssysteme neues Wissen zu generieren.
Die Produkte von Ontoprise sind OntoBroker v3.0, OntoEdit v2.0 und SemanticMiner v1.0. In
dieser Arbeit wird nur näher OntoEdit und OntoMap (ein Zusatzprogramm) eingegangen, da
dies die eigentlichen relevanten Produkte für diese Arbeit sind.
- 16 -
OntoEdit
OntoEdit ist ein Editor, der den Benutzer bei der Erstellung von Ontologien und deren
Verwaltung unterstützen soll. Auch bietet OntoEdit eine Vielzahl an Funktionen und
Exportfiltern für alle gängigen Repräsentationssprachen des Semantic Webs ( auf Basis des
W3C Standarts).
Hier nun ein Beispiel zur Erstellung einer Ontologie.
Zunächst muss der Benutzer eine neue Ontologie öffnen.
Mit OntoEdit kann der Benutzer Ontologien in einer „ is - a“ Hierarchie erstellen. Das heißt,
dass subconcepts alle Eigenschaften ihrer superconcepts besitzen. Wird zum Beispiel „Mann“
als subconcept von „Person“ definiert, so hat „Mann“ alle Eigenschaften von „Person“, weil
„Mann“ „ is – a “ „Person“.Um ein neues Konzept einzufügen muss der Benutzer das
superconcept auswählen und den ‚+’-Button drücken.
Im folgenden Beispiel sind nun „Person“ und „Firma“ als subconcepts von „Root“ (die
vordefinierte Wurzel der Hierarchie) und „Mann“ und „Frau“ als subconcepts von Person
definiert.
Als nächstes werden relations/Attribute erstellt. Um eine relation zwischen Konzepten zu
definieren muss man zunächst die gewünschten Konzepte markieren und dann „insert relation“
im Kontextmenü auswählen. Es öffnet sich nun eine Dialogbox, in der der Benutzer den
Wertebereich und die Kardinalität festlegen kann.
Im Beispiel ist nun das Plugin „instance ausgewählt. Auf der rechten Seite kann man die
Instanzen des ausgewählten Konzeptes auf der linken Seite sehen. Hier sind wieder alle
Instanzen auch Instanzen der superconcepts. Das heißt also „Raphaela Niklaus“ ist eine Instanz
von „Frau“, und gleichzeitig eine Instanz von „Person“.
- 17 -
Sind bereits erstellte Ontologien vorhanden und der Benutzer möchte nun zwischen zwei
Ontologien Abbildungen erstellen, so ermöglicht dies
OntoMap
OntoMap ist ein Editor speziell für die Abbildungserstellung zwischen zwei Ontologien.
Durch die zwei „dropdown-lists“ kann der Benutzer zwei bereits erstellte Ontologien
auszuwählen. Anschließend gibt es verschiedene Abbildungsmöglichkeiten.
Der Benutzer kann durch Drag&Drop-Pfeile
-
Konzepte auf Konzepte abbilden (siehe blauer Pfeil)
-
Attribute auf Konzepte abbilden (siehe lila Pfeil)
-
Attribute auf Attribute abbilden, (siehe roter Pfeil), jedoch müssen bei dieser Art
von Abbildung zunächst deren Konzepte aufeinander abgebildet werden sonst wird
einfach eine Attribute auf Konzept Abbildung definiert
-
„relations“ auf „relations“ abbilden,
Attributes und „relations“ sind beide mit dem „R“-icon.
Relations verbinden Konzepte miteinander (im Bsp. Person works_for Company)
Attribute markierten auf Kozepte (im Bsp. name of Person is of range STRING).
Um relations mit relations zu verknüpfen, muss der Benutzer vorher alle
zugewiesenen Konzepte (hier Company und enterprise) auswählen, danach kann er
die relation auf relation Abbildung definieren.
- 18 -
OntoBroker™
Logik und Methoden der künstlichen Intelligenz sind anwendbar
Durch offene Architektur und den Einsatz von wohl definierten Schnittstellen =>
Einfache und flexibleIntegration in allen gängigen Umgebungen und Anwendungen
Modularer Aufbau => bedarfsgerechte und beliebig erweiterbare Implementierung
Hohe Skalerbarkeit => ermöglicht Anpassung an jegliche Einsatzszenarien
SemanticMiner
Der SemanticMiner ist eine Knowledge Retrieval Plattform, mit der man einfach und schnell
das relevante Wissen in einem Unternehmen entdecken kann. Auf Basis semantischer
Technologien
erleichtert
der
SemanticMiner
die
Navigation
und
ermöglicht
die
Zusammenstellung geeigneter Anfragen, welche die Relevanz der Suchergebnisse drastisch
erhöhen. Doch das ist erst der Anfang. Die Smarter Knowledge Access Anwendungen zur
direkten Integration in die gewohnte Arbeitsumgebung, zur graphischen Navigation in
Wissensnetzen, zum Aufbau intelligenter Berater, zur flexiblen Konfiguration von Produkten
und weitere Produkte ergänzen das Angebot der ontoprise.
- 19 -
Die Frage ist nun welche Sprache kann man verwenden, um Ontologien zu beschreiben?
Betrachten wir zunächst einmal XML (Extensible Markup Language).
Reinem XML fehlen die geeigneten Primitive als auch Domänenspezifische ontologisches
Vokabular. So kann die Metasprache lediglich die Struktur und Syntax bestimmen. Doch die
Semantik ist für XML ein Problem. Es fehlen die üblichen Begriffe einer Framesprache, wie
z.B. “Klasse” und “Attribut”. Diese könne zwar deklariert werden, es fehlt jedoch ein allgemein
anerkannter Rahmen.
Also ging man den nächsten Schritt in Richtung RDF/S.
RDF - Resource Description Framework
RDF bedient sich der Syntax von XML, ohne dabei Annahmen über ein bestimmte
Anwendungsgebiet vorauszusetzen. Es existiert auch kein vordefiniertes Vokabular zur
Beschreibung von Metadaten, sondern bietet die Möglichkeit, verschiedene Standards
einzubetten oder gar neue zu definieren.
RDF-Datenmodell : Subjekt – Prädikat – Objekt
So zum Beispiel die einfache Aussage,
“http://... has the creator Mustermann.“, die nach
dem Schema S-P-O aufgebaut ist.
Als Programm sieht dieses Beispiel folgendermaßen aus:
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://description.org/schema/">
<rdf:Description about="http://…">
<s:Creator>Mustermann</s:Creator>
</rdf:Description>
</rdf:RDF>
In Zeile eins wird zuerst die zu verwendende XML-Version festgelegt, diese
Information ist für den Parser wichtig. Danach folgend in Zeile zwei und drei,
werden die XML-Namespaces [XMLNS99] (Namensräume, aus denen die
Worte der verwendeten Syntax stammen dürfen) referenziert. Die vierte Zeile
beinhaltet die zu beschreibende Ressource, welche durch ‚ Description
about=“...“ ’ bezeichnet wird.
- 20 -
Ein weiteres Merkmal für die Flexibilität von RDF ist die Verwendung von
Strukturierten Werten, d.h. verschachtelten Eigenschaften.
Z.B. die Eigenschaft Creator hat strukturierte Daten, im speziellen E-Mail und
Name:
"http://... has creator a1
and a1 has name Mustermann and e-mail [email protected]"
007
RDF-Schema
Das RDF-Modell beschreibt Ressourcen durch Eigenschaften, über die jedoch
zunächst keine näheren Aussagen gemacht werden hinsichtlich ihrer
Charakteristiken, diese werden erst im RDF-Schema als gültiges Vokabular definiert.
In diesen Schemas wird für jede Eigenschaft festgelegt, was sie für eine Bedeutung
hat, welche Werte für diese Eigenschaften erlaubt sind, welche Arten von
Ressourcen diese Eigenschaften besitzen und, welche Beziehungen sie zu anderen
Eigenschaften haben. Diese Typen von Eigenschaften (property types) werden
charaktersiert durch:
Klassen: Class, Property, Resource
Properties: SubClassOf, SubPropertyOf, seeAlso,
isDefinedBy,…
-> Einschränkungen: domain, range
RDF/S bietet zwar Möglichkeiten Ontologien zu beschreiben. Trotzdem fehlen
wesentliche Bestandteile, um die Mächtigkeit von Ontologien auszuschöpfen. Nämlich
die wesentlichen Konstrukte und Relationen innerhalb von Klassen und über Hierarchie
bzw. Klassenebene hinweg. Formale Semantik und ein ausgeklügeltes Inferenzenmodell
sind - neben einer verfeinerten Modellierung von Primitiven – wesentliche
Erweiterungen, welche die Sprachen bieten, welche genau aus dieser Anforderung heraus
entstanden.
Dann folgte die Entwicklung von OIL und DAML-ONT
OIL ist das Ergbenis im Rahmen von On-To-Knowledge, einem contentdriven Projekt
aus der Information Society Technologies (IST), welches seit 1999 läuft. Das Ziel ist es,
Webbasierendes Wissen effizient aufzubereiten, so daß jedermann ( ob IT-Spezialist
oder nicht ) intuitiv verständlich darauf zurückgreifen kann. Dabei stützte man sich stark
auf die Entwicklungen aus der KI ab, welche den Begriff der Ontologie mit sich
brachten und somit die daraus resultierende Ontologiesprache OIL entstand.
- 21 -
Etwa ein Jahr später initiierte die US-Regierung
ebenfalls aus denselben Beweggründen das Projekt
„DARPA Agent Markup Language (DAML)“,
dessen Produkt die Ontologiesprache
„DAML-ONT“ war.
Die RDF/S Klassen Definitionen wurden weiterentwickelt und verfeinert. Schnell
wurden Parallelen zu OIL entdeckt und anfangs Erfolge von OIL
integriert. Schließlich wurden beide Sprachen zusammengefasst und als W3C-Standard
zur Beschreibung von Ontologien definiert: „DAML+OIL“
war geboren.
Eine Möglichkeit Ontologien zu definieren, zu verändern oder zu vergleichen bietet „UBOT“,
ein Programm, welches aus verschiedenen Tools besteht .UBOT ist vergleichbar mit dem
Wissenserwerbssystem KnowMe.
Eines dieser Tools ist aerodaml-mapper, welches ein Editor speziell für Abbildungen zwischen
DAML-Ontologien ist. Vergleichbar ist dieses Tool mit dem entwickelten Plugin AgentsPlugin
dieser Arbeit.
Für die Wissensrepräsentation verwendet UBOT die Sprache DAML (DARPA Agent Markup
Language).
UBOT bietet die Möglichkeit in „aerodaml-mapper“ zwei Ontologien als Baumformat in 1 und
2 zu laden ( load Ontology). Der Benutzer kann jeweils ein Element in jeder Ontologie
markieren. Anschließend hat er die Möglichkeit zwischen diesen markierten Elementen eine
Abbildung als „SameClassAs“ zu erzeugen(create link), oder eine bereits bestehende Abbildung
zu löschen ( Remove link).
Hat der Benutzer Abbildungen definiert, so kann er sich die Definitionen in der DAML-Sprache
im unteren Editor anzeigen lassen ( Map).
Zu jeder Zeit kann der Benutzer seine Abbildungsdefinitionen abspeichern ( save)
Es können beliebig viele Abbildungen zu Elementen einer anderen Ontologie erstellt werden.
D.h. n:n -Abbildungen. Angezeigt werden die erstellten Abbildungen in einer Tabelle. Die
- 22 -
Tabelle ist angepasst an den oberen Editor, d.h. nach der Abbildungsdefinition erscheinen die
Elemente in der Tabelle jeweils direkt unter der zugehörigen Ontologie. Elemente einer
Abbildungen stehen in einer Zeile verbunden durch die Spalte „SameClassAs“.
.
Abb. 3 der aerodaml-mapper
Jedoch sind im Gegensatz zu OntoMap von Ontoprise in Ubot nicht s näheres zu Relationen
zwischen Elementen einer Ontologie erwähnt. Auch findet man nichts von
Attribut-concepts-Abbildung usw.
Vergleicht man beide Systeme miteinander, so haben die Tools Ontoprise bei weitem mehr
Möglichkeiten für den Benutzer, was Abbildungen zwischen Ontologien betrifft, als Ubot.
- 23 -
Hier ist nun ein Auszug aus der Daml Ontologie mit den Elementen aus dem aerodaml-mapper.
(die verwendeten Elemente sind markiert)
Extraction Class
Description
Examples
PERSON
EMAIL
An email address
[email protected]
PHONENUM
A telephone/fax number
212-555-5555
NATIONALITY
Membership in a particular nation
American, Russian, Arab
ABSOLUTEDATE
A specific day
May 31, 2002, Thu Jul 18
AGO
A time earlier than the present time
2 years ago, this morning
HOLIDAY
All US holidays
Time
New Year, Christmas, Labor
Day
Organizations
COMPANY
EDUCATION
LEGAL
A commercial organization
An organization that provides instruction; an institution for teaching
Citigroup Inc., Capital One
Financial Corporation
City College of New York,
Harvard University, Martin
Luther King School
An organization for the administration Fourth circuit court of apof justice
peal, The supreme court
- 24 -
Das Beispiel im Aerodaml Mapper sieht in DAML-Sprache folgendermaßen aus:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE rdf.RDF [
<!ENTITY a"http://ubot.lockheedmartin.com/ubot/2002/08/aerodaml-ont.daml#>
<!ENTITY rdf"http://www.w3.org/1999/02/22-rdf-syntax-ns#>
<!ENTITY rdfs"http://www.w3.org/2000/01/rdf-schema#>
<!ENTITY daml"http://www.daml.org/2001/03/daml&oil#>
]>
<rdf:RDF xmlns:a="&a;"
xmlns="&rdfs;"
xmlns:rdf="&rdf;"
xmlns:daml="&daml;"
>
<daml:Class
rdfabout="http://ubot.lckheedmartin.com/ubot/2002/08/aerodaml-
ont.daml#EDUCATION">
<daml:sameClassAs
rdf:resource="http://ubot.lockheedmartin.com/ubot/2002/8/aerodaml-
ont.daml#EMAIL"/>
<daml:sameClassAs
rdf:resource="http://ubot.lockheedmartin.com/ubot/2002/8/aerodaml-
ont.daml#HOLIDAY"/>
</daml:Class>
<daml:Class
rdfabout="http://ubot.lckheedmartin.com/ubot/2002/08/aerodaml-
ont.daml#LEGAL">
<daml:sameClassAs
rdf:resource="http://ubot.lockheedmartin.com/ubot/2002/8/aerodaml-
ont.daml#HOLIDAY"/>
</daml:Class>
</rdf:RDF>
- 25 -
Übertragung auf das hier betrachtete Diagnosesystem
Es wurden nun „Ubot/ aerodaml-mapper“ und „Ontoprise“, als zwei Vergleichssysteme
betrachtet. Nun werden diese auf das hier betrachtete Diagnosesystem übertragen.
In dieser Arbeit wird nun ausgehend von den Ideen der Vergleichssysteme ein Editor speziell
für KnowMe entwickelt, der es dem Experten ermöglicht zwischen einem Agent und einer
Terminologie-Wissensbasis
Abbildungen
zu
erstellen.
Das
heißt
es
wird
als
Kommunikationsverfahren eine „universelle Sprache“ verwendet, in diese universelle Sprache
muss die Sprache jedes einzelnen Agenten übersetzt werden, bzw. müssen Abbildungen erstellt
werden. Jedoch gibt es zu den vorgestellten Vergleichssystemen einige Unterschiede. Zum
einen verwenden die Agenten statt „Ontologien“, welche durch die Beschreibung von
Konzepten und Beziehungen von Datenelementen sehr mächtig sind, „Wissensbasis-Objekte“,
die aus einfachen D3-Wissensbasis-Attributen bestehen.
Es werden alle oben genannte Abbildungsmöglichkeiten, einschließlich „UND-Verknüpfungen,
als auch „ODER“- Verknüpfungen zwischen den einzelnen Elementen der Agenten zugelassen1.
Die Rückabbildungen werden, sofern es möglich ist (siehe Erweiterungen) automatisch mit
definiert.
1
Siehe auch 4. Erweiterungen
- 26 -
3. Entwurf eines Abbildungs-Editors
Aufbauend auf die besprochenen Vergleichsysteme, „Ontoprise“ und „Daml“ ist in dieser
Arbeit nun ein weiteres Plugin „Agents Plugin“ als Abbildungseditor für KnowMe entwickelt
worden. Dieses ermöglicht es zusätzlich zu einer geladenen Wissensbasis eine TerminologieWissensbasis in das System zu laden. Es werden keine Ontologien, wie in den
Vergleichssystemen verwendet, sondern die aus den D3-Wissensbasis-Attributen bestehenden
Wissensbasen der Agenten. Zunächst nun ein kurzer Überblick über den graphischen Aufbau
des Plugins.
Nach dem Öffnen von „Agents Plugin“ erscheint zunächst die „leere“, graphische
Benutzeroberfläche, wie sie in Abbildung 3.1 zu sehen ist. Die Zahlen 1-4 in Abbildung 3.1
sollen als Orientierungs- bzw. Erklärungshilfe dienen.
Nr.1 zeigt den Editor für eine zu ladende Wissensbasis.
Nr.2 zeigt den Editor für weitere Wissensbasis.
Nr.3 zeigt den leeren Editor für die spätere Abbildungs-Tabelle zur Wissenseingabe.
Nr.4 zeigt den leeren Editor für die Überblicks-Tabelle über alle erstellten Abbildungen.
Zwischen den Tabellen sind noch einige Buttons für verschiedene Funktionen zu sehen
(„Abbildung hinzufügen“, „Abbildung entfernen“, „Alle Abbildungen“, „Öffnen“, „Speichern“)
die jedoch erst später näher erläutert werden.
3
1
2
4
Abbildung 3. 1: Die leere Oberfläche von AgentsPlugin
- 27 -
Eine Wissensbasis/Terminologie – Wissensbasis laden
Zum Laden der Wissensbasis klickt man mit der Maus das Icon
in der Toolbar, angezeigt
durch die roten Pfeile im Screenshot. Wobei das Icon mit Pfeil Nr. 1 für das Laden einer
beliebigen Wissensbasis in den linken Editor, siehe Abbildung 3.1.Nummer 1,steht, und das
Icon mit Pfeil Nr. 2 für das Laden einer Wissensbasis in den rechten Editor, siehe Abbildung
3.1 Nummer 2.
In dem nun geöffneten Fenster kann der Experte eine Wissensbasis aus einer Datei auswählen
und anschließend durch das drückendes des Buttons „Öffnen“ in das Plugin laden.
Eine Abbildung definieren
Als nächstes wählt der der Experte nun ein Element der Wissensbasis und ein Element der
Terminologie – Wissensbasis aus. Anschließend erscheinen die Antwort-Alternativen der
ausgewählten Elemente in der nun erscheinenden Abbildungstabelle, dargestellt in
Abbildung…. Im Beispiel aus Abbildung
wurden die Alternativen der Elemente „Diagnose-
grob“ (erste Tabellenzeile) und Klin. Fragestellung-2 (erste Tabellenspalte) verwendet.
- 28 -
Nun kann der Benutzer an der Schnittzelle der gewünschten Eigenschaften durch Anklicken der
entsprechenden Zelle ein Pop-up Menü öffnen und die Abbildungen durch Auswählen einer
Zahl definieren. Es gibt für den Benutzer verschiedenen Verknüpfungsmöglichkeiten für die
abzubildenden Elemente, jedoch abgebildet wird immer von links nach rechts:
„UND“-Verknüpfungen
mit „UND“-Verknüpfungen ist zum Beispiel gemeint:
WENN TEMPERATUR ERHÖHT UND HALSSCHMERZ POSITIV DANN GRIPPE
Eigenschaften, die einer gemeinsamen „UND“-Gruppe/“UND“-Verknüpfung angehören
müssen alle die gleiche Zahl erhalten.
„ODER“-Verknüpfungen
mit „ODER“-Verknüpfungen ist zum Beispiel gemeint:
WENN BEINFRAKTUR POSITIV ODER SCHNITTVERLETZUNG GROß DANN
SCHMERZEN
Eigenschaften, die durch „ODER“-Verknüpfungen miteinander verbunden sind müssen
verschiedene aufsteigende Zahlen bekommen.
Für die Probleme bei den Rückabbildungen siehe Kapitel Erweiterungen.
- 29 -
Ein Beispiel für eine Abbildung ist die Identitäts-Abbildung von „männlich, weiblich“ auf sich
selbst in Abbildung…
Eine Besonderheit stellen noch die numerischen Elemente dar. Bei der Auswahl eines solchen
Elementes aus der Wissensbasis muss der Experte in den Editor in Abbildung… Intervalle
eingeben. Z.B. „10 35 60“. Das heißt für die Antwort-Alternativen „kleiner, gleich 10“,
„kleiner, gleich 35“, „kleiner, gleich 60“, größer, siehe auch Tabelle…..
kleiner, gleich 10 kleiner, gleich 35 kleiner, gleich 60 größer
männlich
weiblich
- 30 -
Eine Abbildung hinzufügen
Nach der Definition einer Abbildung muss der Experte seine Abbildung durch Klicken des
„Abbildung hinzufügen“-Buttons „Vorspeichern“. D.h. nach dem Hinzufügen einer Abbildung
erscheint diese in der Überblick-Tabelle, falls das Element in der linken Wissensbasis markiert
ist.
Eine Abbildung löschen
Ebenso wie eine Abbildung hinzugefügt wird kann eine Abbildung aus dem „Vorspeicher“ auc
gelöscht werden. Dazu muss die Abbildung in der Übersichts-Tabelle markiert werden und der
„Abbildung löschen“ Button gedrückt werden. Anschließend verschwindet die Abbildung in
beiden Tabellen.
Alle Abbildungen anzeigen
Durch den Button „Alle Abbildungen“ kann sich der Experte alle bereits definierten
Abbildungen in der Übersichts-Tabelle anzeigen lassen.
Datei speichern
Sobald alle Abbildungen zwischen beiden Abbildungen definiert wurden, können diese durch
Klicken des „Speichern“-Buttons endgültig gespeichert werden.
Datei öffnen
Durch drücken des „Öffnen“-Buttons kann eine Datei mit Abbildungen in den Editor geladen
werden
Teilbäume kopieren
Es gibt im Abbildungseditor aus Zwecken der besseren Normierung noch die Möglichkeit
Teilbäume aus der linken Wissensbasis in die rechte Wissensbasis zu kopieren. Man markiert
ein Element der linken Wissensbasis und zieht es durch Drag&Drop auf ein Element der rechten
Wissensbasis.
- 31 -
Der Teilbaum wird unterhalb des Knotens der rechten Wissensbasis eingefügt. Es werden neue
IDs erstellt speziell für die linke Wissensbasis. Auch werden automatisch Identitätsabbidlungen
zwischen den kopierten, identischen Elementen der beiden Wissensbasen gebildet, siehe
Abbildung….. Diese können jederzeit über die Tabellen bearbeitet oder gelöscht werden.
- 32 -
4. Erweiterungen
Der Editorentwurf aus dieser Arbeit ermöglicht es 1:1, 1:n, n:1 und n:m-Abbildungen
ausschließlich mit „UND“–Verknüpfung zwischen den Falldaten eines Agenten und einer
Terminologie-Wissensbasis zu erstellen.
Jedoch kann das Erstellen von Abbildungen auch sehr komplexe Formen annehmen, wenn nicht
nur Abbildungen mit „UND“ –Verknüpfungen möglich sind, sondern auch Abbildungen mit
„ODER“ - Verknüpfungen.
„UND“-Verknüpfung:
Falldaten:
TEMPERATUR ist erhöht
HALSSCHMERZ positiv
KOPFSCHMERZ positiv
Abbildungsregel:
WENN TEMPERATUR erhöht UND
WENN KOPFSCHMERZ ist positiv UND
WENN HALSSCHNERZ ist positiv DANN GRIPPE
Durch die Anwendung von „UND“-Verknüpfungen kann die Rückbbildung von GRIPPE exakt
„TEMPERATUR ist erhöht“, „HALSSCHMERZ positiv“ und „KOPFSCHMERZ positiv“
zugeordnet werden.
„ODER“-Verknüpfung:
Falldaten:
Patient hat Schock
Patient hat Sport gemacht
Abbildungsregel
WENN Patient hat Schock ODER
WENN Patient hat Sport gemacht DANN PULS ERHÖHT
Möchte man nun eine Rückabbildung von „PULS ERHÖHT“, so kann man nicht exakt
zuordnen, ob der Patient einen Schock hat oder, ob der Patient Sport gemacht hat.
Es müssten also zusätzlich noch weitere Merkmale zu Verfügung stehen, wie zum Beispiel
WENN PULS ERHÖHT UND PATIENT NACH AUTOUNFALL, dann kann man auf Patient
hat Schock Rückschließen.
In dieser Arbeit werden nur Abbildungen zwischen Daten mit „UND“-Verknüpfungen erstellt.
- 33 -
5. Literatur und Links
[1] Cand.Inform. Krellner, K.:
JavaBeans für grafische Wissenserwerbs- und Autorensysteme
Diplomarbeit Universität Würzburg, 30.Juli 2001;
[2] DUBOT AeroDAML:DAMLOntology Mapper Guide
http://ubot.lockheedmartin.com/ubot/hotdaml/aerodamlmapperguide.html
[3] „Ontoprise“
http://www.ontoprise.de
[4] Bamberger, S.: Verteiltes Problemlösen mit wissensbasierten Diagnosesystemen
Dissertation Universität Würzburg. DISKI 203, St Augustin: infix 1999;
[5] Puppe, F.: Einführung in Expertensysteme, 1990
[6] Puppe, F.: Problemlösungsmethoden in Expertensystemen, 1990
- 34 -