Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

01.05.1987 - 

Modifikation von hierarchisch aufgebauten Schablonen dient als Basis:

User-Modell hängt nicht von der Anwendung ab

Ein ausbaufähiges und wiederverwendbares Benutzermodell ist das Ergebnis eines Forschungsvorhabens an der University of Pennsylvania in Philadelphia, USA. Das System trägt die Bezeichnung GUMS (Generelles User-Modell-System). Im Mittelpunkt der von Timothy Finin beschriebenen Methode stehen schablonisierte Vorstellungen vom Anwender, die in einem hierarchischen System geordnet sind. Der Dialog mit dem User dient dazu, die passende Schablone auszuwählen und zu modifizieren.

Das Konzept, Benutzermodelle in interaktive Systeme einzubauen, ist allgemein üblich geworden. Was unter "Benutzermodell" zu verstehen ist, hat sich laufend geändert und ist nicht immer klar. Bei dem Versuch festzulegen, was zu einem Benutzermodell gehört, tauchen eine Anzahl von Fragen auf.

Wer soll im Modell erfaßt werden?

Die ersten Unterscheidungsmerkmale sind hier, ob Einzelbenutzer oder eine Klasse von Benutzern im Modell erfaßt und ob ein Kurzzeit- oder ein Langzeitmodell aufgebaut werden soll. In diesem speziellen Fall bestand die Absicht, Langzeitmodelle für Einzelbenutzer aufzubauen und zu nutzen; also das Wissen und die Meinungen über Individuen darzustellen. Dies sollte in einer dauerhaften Aufzeichnung resultieren, die bei Bedarf wachsen und sich ändern kann. Dabei ist es nicht nötig, generelle Fakten darzustellen, die für große Klassen von (oder sogar alle) Benutzer gelten. Im einzelnen können solche Fakten Folgerungsregeln enthalten, welche die Meinung, das Wissen oder Verständnis einer Person von einem Ding mit der Meinung, dem Wissen und dem Verständnis von anderen Dingen verknüpfen.

Was soll im Modell erfaßt werden?

Der Brennpunkt der laufenden Arbeiten ist darauf gerichtet, ein allgemein verwendbares, bereichsunabhängiges System zu schaffen, das Benutzermodelle ständig aktualisiert. Dann steht immer genau die Information, der eine Gestalt gegeben werden soll, für die Anwendung zur Verfügung.

Wie soll das Modell erworben und auf dem laufenden gehalten werden?

Untersucht wird derzeit ein System, in dem ein Anfangsmodell aus einer Reihe von schablonenhaften Benutzermodellen ausgewählt wird. Die Auswahl der am meisten geeigneten Schablonen aus dem Vorrat kann mit Hilfe verschiedener Techniken durchgeführt werden: Zum Beispiel kann der Benutzer selber die Schablone auswählen, oder die Einschätzung des Users und die Auswahl der Schablone erfolgen durch ein Expertensystem. Wenn einmal ein Anfangsmodell ausgewählt ist, wird es fortgeführt und aktualisiert, sobald direktes Wissen über den Benutzer durch den Dialog mit einem System gewonnen wird vornehmlich dann, wenn, sich dabei etwas ergibt, das einer Tatsache in dem gegenwärtigen Modell widerspricht.

Die Aktualisierung des Modells kann zu einer Inkonsistenz führen die ins Lot gebracht werden muß. Wenn das Modell wieder konsistent gemacht werden kann, indem Ersatztatbestände ins Modell eingebracht werden, dann sollte dies getan werden. Gibt es verschiedene Tatbestände, die geändert werden können dann muß ein Mechanismus vorhanden sein, der bei der Auswahl hilft (zum Beispiel durch weiteren Dialog mit dem Benutzer). Wenn es keine Ersatzfakten gibt, die verwendet werden können, um das Modell konsistent zu machen, so muß die Schablone aufgebeben und eine neue gesucht werden. Fortsetzung auf Seite 78

Wie ist das Modell nutzbar?

Auf das Modell kann in zwei Hauptarten zugegriffen werden: Fakten können hinzugefügt, gelöscht oder berichtigt beziehungsweise gesucht oder gefolgert werden.

Das Ziel ist es, ein Hilfssystem für ein generelles Benutzermodell bereitzustellen, das nach den geschilderten Grundsätzen organisiert ist. Das Benutzermodellsystem stellt einem Anwendungsprogramm, das direkt mit dem Benutzer kommuniziert, einen Dienst zur Verfügung. Dieses Anwendungsprogramm sammelt durch seinen Dialog mit dem Benutzer Informationen über ihn und wählt einige dieser Informationen aus, um sie im Benutzermodell zu speichern. Ein Dienst des Benutzermodells besteht also darin, neue Informationen über den User entgegenzunehmen und zu speichern. Diese Information kann einen Schlußfolgerungsprozeß auslösen, der eine Reihe von Ergebnissen hat:

Das Benutzermodellsystem kann einen inneren Widerspruch entdecken und deshalb die Anwendung informieren. Es ist in der Lage, einen neuen Tatbestand über den Benutzer zu folgern. Außerdem mag es für das Benutzermodell notwendig werden, einige früher gefolgerte Ersatzinformationen über den Benutzer fortzuschreiben.

Eine andere Art des Dienstes, welche das Benutzermodell bereitstellen muß, ist das Beantworten von Fragen, die durch die Anwendung gestellt sind. Die Anwendung kann es erfordern, Informationen über den jeweiligen Benutzer bereitzustellen oder gewisse Informationen herzuleiten.

Die Reihe der zu leistenden Dienste, die für die ständige Aktualisierung des System denkbar ist, besteht aus folgenden Funktionen:

Eine Datenbank von Fakten, die über den Benutzer beobachtet wurden, muß auf dem laufenden gehalten werden. Zusätzliche verifizierte Tatbestände über den Benutzer, basierend auf den beobachteten Fakten, werden gefolgert; ebenso zusätzliche wahrscheinliche Tatbestände, die auf Ersatzangaben und Ersatzregeln basieren. Das Anwendungssystem muß darüber informiert werden, wann Tatbestände als wahr gefolgert oder als wahr angenommen werden können. Ein Zurückziehen von Ersatzinformationen, wenn diese nicht mit dem beobachteten Fakten übereinstimmen, hält die Konsistenz des Modells aufrecht. Die Bildung einer Hierarchie von Schablonen, die erste, bruchstückhafte Benutzermodelle bilden können, sollte in einem Mechanismus verankert werden. Außerdem ist es wichtig zu erkennen, wenn beobachtete Fakten über einen Benutzer nicht mehr zu einer vorgegebenen Schablone passen; dann müssen alternative Muster, die verträglich sind, vorgeschlagen werden.

Ein Benutzermodell ist besonders dann sehr nützlich, wenn die Anwendung keine vollständige Information über das Wissen und die Meinung ihrer Benutzer enthält. Das Problem dabei ist, einen gegebenen Benutzer in das Modell einzuordnen, von dem nur ein begrenzter Wissensumfang bekannt ist. Der mit dem Begriff "Generelles User-Modell-System" (GUMS) bezeichnete Lösungsversuch beinhaltet mehrere Formen von Ersatzschlußfolgerungstechniken (default reasoning techniques): Schablonen, explizite Ersatzregeln und "Fehlschlag als Verneinung".

Schablonen können in Hierarchien organisiert werden, in denen eine Schablone die andere in sich einschließt, wenn die erste als allgemeiner angesehen werden kann. Eine Schablone die wird genereller als eine Schablone "S2" genannt, wenn alles, was für "S1" wahr ist, notwendigerweise auch für "S2" wahr ist. Betrachtet man dies aus einem anderen Sichtwinkel, so beinhaltet eine Schablone alle Fakten und Regeln von jeder Schablone, der sie untergeordnet ist. Im Zusammenhang einer Anwendung zur Programmiererausbildung könnte man zum Beispiel Schablonen entsprechend unterschiedlicher Programmiererklassen haben.

Interpreter basiert auf Vier-Werte-Logik

GUMS erlaubt folgende beiden Fälle: Entweder sind Fakten und Regeln innerhalb einer Schablone definitiv wahr, oder sie sind durch Ersatz wahr. Im zweiten Fall gelten sie so lange als wahr, wie Informationen über das Gegenteil fehlen.

Das System gestattet auch explizite negative Fakten und Ersatzfakten. Wird die Negation in Beziehung zu einem negativen Faktum nachgewiesen, so gilt sie nicht als ein Ersatzfall. Ähnlich wird auch ein "Fehlschlag als Verneinung" nicht als ein Ersatz angesehen, wenn das negierte Prädikat geschlossen ist. Solche Unterscheidungen sind möglich, weil der GUMS-Interpreter auf einer Vier-Werte-Logik basiert.

Der Unterschied zwischen Wahrheit oder Unrichtigkeit durch Ersatz (Annahme) und Wahrheit oder Unrichtigkeit durch logische Folgerung ist für dieses System ein sehr bedeutender. Das zentrale Prädikat des Systems ist das mit zwei Argumenten versehene Prädikat "show"; es setzt eine Anfrage "G" (Goal), die durch ein Literal ausgedrückt wird, zu einem Wahrheitswert in Beziehung Folglich gibt "show" (Goal, Val) in der Variablen "Val" die aktuelle Glaubwürdigkeit für das Literal "Goal" wieder. "Val" kann auf "wahr", "falsch", "vermutlich" (wahr), "vermutlich" (falsch) gesetzt sein. Die Bedeutungen dieser Werte sind die folgenden:

wahr - definitiv wahr gemäß der aktuellen Datenbasis

vermutlich (wahr) - wahr durch Annahme (wahr durch Ersatz)

vermutlich (falsch) - falsch durch Annahme

falsch - definitiv nicht wahr

Übersetzungsprogramm ist in Prolog geschrieben

Die Vier-Werte-Logik erlaubt es, aus rein logischer Information gewonnene Schlußfolgerungen von solchen zu unterscheiden, die aus Ersatzinformationen gezogen wurden. Das Übersetzungsprogramm, auf dem GUMS basiert, ist ein in "Prolog" geschriebener Metalevel-Interpreter. Wegen der Vierwert-Logik und dem Vorhandensein von explizit negativer Information muß der Interpreter viele mögliche Antworten zu jeder Umfrage erzeugen und vergleichen. Starke Antworten zu einer Frage (das sind "true" und "false") werden zuerst gesucht. Sie werden gefolgt von schwachen "Antworten" (das sind "wahrscheinlich" (true) und "wahrscheinlich" (false).

Schablone muß dem Benutzer angemessen sein

Die derzeitige experimentielle Implementierung stellt die folgender, Kommandos der Anwendung zur Verfügung:

- "show" (Query, Val) funktioniert mit "Val" als dem stärksten Wahrheitswert für die Anfrage (Query). Eine Query ist ein teilweise oder vollständig vorbesetztes positives oder negatives Literal. "Val" ist der wiegergegebene Wert des jeweiligen Gewißheitsgrades. Wenn die Query teilweise vorbesetzt ist, dann werden über Backtracking, sofern möglich, mehrere Antworten zurückgegeben. Im allgemeinen wird eine Antwort für jede erlaubte Grusubstitution bereitgestellt, die mit den aktuellen Typendeklarationen übereinstimmt.

- "add" (Fact, Status) setzt den Wahrheitsgehalt des Fact auf "true". Wenn das Fact - oder jede erlaubte Vorbesetzung davon - dem geltenden Wahrheitsgehalt widerspricht, macht sich das Benutzermodell nach und nach in der Hierarchie höhere Schablonen zu eigen, bis eine gefunden ist, in der alle hinzugefügten Fakten konsistent sind. Wenn keine Schablone erfolgreich ist, wird keine Schablone benutzt. Alle Antworten werden ganz auf den hinzugefügten Fakten basieren. Das Fact muß teilweise oder ganz vorbesetzt sein. Es kann entweder ein positives oder ein negatives Literal sein. Der Status muß unvorbesetzt sein und ist für eine Nachricht bestimmt, die das Ergebnis des Hinzufügens beschreibt (zum Beispiel eine Fehlermeldung "Ok", den Namen einer neuen Schablone, etc.).

- "create-user" (UserName, Stereotype, File Status) speichert den aktuellen Benutzer, wenn es nötig ist, und schafft einen neuen Benutzerbereich, der dann der aktuelle ist. Der UserName ist vorbesetzt mit dem gewünschten Namen. Das Stereotype ist der logische Name der Schablone den das System annehmen sollte. File ist der Name der Datei, in welcher die Information, die den Benutzer betrifft, gespeichert wird. Der Status wird durch das System belegt und gibt Fehlermeldungen zurück. Um das System in die Lage zu versetzen auf Fragen zu antworten, muß ein Benutzerbereich geschaffen werden

- "store-current" (Status) speichert die aktuelle Information über den User und bereinigt den Arbeitsraum für einen neuen Benutzer. Der Status wird durch das System bei einem Fehler belegt.

- "restore-user" (User, Status) speichert einen vorherigen Benutzer wieder ein, nachdem der aktuelle Benutzer, falls dies nötig ist, gesichert ist. User ist der Name des Benutzers. Der Status wird durch das System belegt, um Fehlermeldungen zu übergeben.

- "done" speichert den Systemzustand des Benutzermodells, indem es den aktuellen Benutzer speichert falls dies nötig ist. Dieses Kommando sollte das letzte abgesetzte Kommando sein. Es muß am Ende jeder Session abgesetzt werden.

Viele interaktive Systeme erfordern es, Modelle einzelner Benutzer vorzuhalten. GUMS ist eine einfache Architektur für die allgemeine Einrichtung eines Benutzermodells; sie basiert auf den Ideen einer Ersatzlogik. Dieser Versuch stellt ein System zur Verfügung, das eine Datenbank von über Benutzern bekannten Informationen aufrechterhalten kann GUMS arbeitet auch mit Fakten, die einer Schablone zugeordnet sind. Diese Schablone soll dem jeweiligen Benutzer angemessen sein. Sie kann definitive Fakten enthalten, und sie kann Regeln von Rückschlüssen sowie Ersatzinformationen und Ersatzregeln festlegen. Die Regeln können benutzt werden, um neue Informationen - sowohl definitive als auch angenommene - von dem aktuell für richtig gehaltenen Kenntnisstand über den Benutzer abzuleiten.

Timothy Finin ist Dozent am Institut für Computer- und Informations-Wissenschaften an der University of Pennsylvania.