User Model The User Modeling Shell System BGP-MS User Modeling For Personalized City Tours By Steven Sun & Yu-Chyuan (Trent) Su

User ModelUser Model

The User Modeling Shell System BGP-MS User Modeling For Personalized City Tours

By

Steven Sun & Yu-Chyuan (Trent) Su

The User Modeling Shell The User Modeling Shell System BGP-MSSystem BGP-MS

Introduction Information Flow User Modeling

Representation Inference Interface for

Application Developer

Comparison with Other Shell Systems

Example Client: HN-AHS

Conclusion

IntroductionIntroduction

BGP-MS is a user modeling shell system – Helping application in adapting to users base on their

knowledge, beliefs, and goals. Offers several ways for communicating

– Send user information to BGP-MS, and obtaining information from BGP-MS

Infer additional assumptions based on– Initial interview, observed user actions, and

stereotypical knowledge about pre-define user subgroups.

Introduction (Cont.)Introduction (Cont.)

Application developer’s goal– Draw assumption about the user base on his interaction– Represent and store these assumptions– Draw additional assumption based on initial ones– Take appropriate actions when inconsistencies between

assumptions are detected– Supply the application with current assumption about the user

Additional assumptions are acquired by– Current entries in the user model– User’s answer in the questionnaire– Observed user actions– Stereotypical knowledge about the user subgroup

Classify the user to one or more subgroups

Information FlowInformation Flow

Communication between application and BGP-MS via KN-IPCMS

Types of messages between application and BGP-MS Informing BGP-MS about observed user beliefs and

goals Interviewing the user Informing BGP-MS about observed user actions Asking BGP-MS for current assumption about user

beliefs and goals Send important inferred assumptions to the application

Information Flow: KN-IPCMSInformation Flow: KN-IPCMS

A platform-independent message-oriented communication protocol that allows both synchronous and asynchronous communication.

Application developers must intergrade a set of pre-defined C functions into their program environment that implement the KN-IPCMS protocol.

At runtime, application must register as participant using its port name.

Information Flow: Message Information Flow: Message TypesTypes

Application can inform BGP-MS about observed user beliefs and goals

BGP-MS can send the application interview question Application can send answer to BGP-MS Application can inform BGP-MS about observed user

actions. Application can ask BGP-MS for current assumption

about the user. BGP-MS can answer such questions of the application BGP-MS can send important events to the application

Information Flow: Message Information Flow: Message Types (Cont.)Types (Cont.)

Information Flow: Informing Information Flow: Informing Beliefs and GoalsBeliefs and Goals

Uses belief and goal description language (BGDL) for communication

‘B’ = believe, ‘W’ = want ‘S’ = System, ‘U’ = User, ‘M’ = Mutually Shared Example #1

Example #2

Information Flow: InterviewingInformation Flow: Interviewing

Initial interviews are a major source of information about the user (e.g. user is a student.)

Processes needed for initial interviews:– To determine the questions that must be asked– To display these questions, and receive answers– To draw inferences about the user based on the his answer– To enter these assumptions into the user model

BGP-MS’s interviewing component handles tasks (a), (c), and (d)

Information Flow: Interviewing Information Flow: Interviewing (Cont.)(Cont.)

Example BGP-MS question:

Example user answer:

Information Flow: Informing Information Flow: Informing ObservationObservation

Provided directly by the user Draw inferences based on the

user’s input Message format for reporting

user actions:

Information Flow: Asking for Information Flow: Asking for Current AssumptionsCurrent Assumptions

Message with label bgp-ms-ask Example question:

Example answer

Information Flow: Send Information Flow: Send Inferred AssumptionsInferred Assumptions

Normally information flow from BGP-MS to the application is driven by the demands of the application

BGP-MS can inform the application about important events, such as

Representing User Model and Representing User Model and Domain KnowledgeDomain Knowledge

Representations types– Integrated suite of knowledge representation mechanisms for representing

Its assumptions about the current user Domain-specific user modeling knowledge General knowledge about the application domain

– Outer representation layer called partitions represented in: Conceptual representation scheme First-order predicate calculus

Partition hierarchies– Representing individual user models and stereotypes– DN-PART is the outer knowledge representation layer in BGP-MS– Allow the arbitrary partition hierarchies that child nodes inherit the

contents of the parent.– Leaf partitions with direct or indirect inherited contents are called views.

Representation of the domain knowledge– Domain knowledge must be stored in a separate partition, named ‘SB’ for

‘System Believes’.

Representing User Model and Representing User Model and Domain Knowledge (Cont.)Domain Knowledge (Cont.)

Representation of individual user module– Frequently employed types of assumptions:

SBUB for System Believes User Believes SBMBUB – the mutual beliefs of the system and the user about the

user’s beliefs about the application domain SBMB – the mutual believes of the system and the user about the

application domain SBUW for System Believes User Wants SBMBUW SB

– Partition Hierarchy

Representing User Model and Representing User Model and Domain Knowledge (Cont.)Domain Knowledge (Cont.)

Representation of stereotypes– Each stereotype is represented by a separate partition– If applies, an inheritance link is used between the user and each

stereotype (e.g Dos-Programmer in Figure 3.) Hybrid representation within partitions

– Conceptual knowledge representation language SB-ONE is used to formulate assumptions concerning the concepts of the application domain

First-order predicate calculus (FOPC) is used to express assumptions that cannot be represented in SB-ONE

Drawing InferencesDrawing Inferences

Inferences base on observed beliefs and goals– Mapping of expression of BGDL to entries for the user model

using ‘bgp-ms-tell’.– Example: when BGP-MS receives a message (bgp-ms-tell (B S

(B M (W U p)))), it will enter the first –order expression p into the partition SBMBUW.

– If developer wants both SB-ONE and FOPC for representation, KN-TRANS can assign p to the appropriate formalism.

Drawing Inferences Drawing Inferences (Cont.)(Cont.) Inferences from user interviews

– An interview consists of question blocks; each can consist of one or more question.

– The conclusions are drawn as soon as the answers for a question block are returned to the BGP-MS system.

– Example interview question:

Drawing Inferences Drawing Inferences (Cont.)(Cont.)

Inferences based on the user’s actions– Rules are often domain-specific– Example 1: A request for additional technical details about an

object implies that the user knows the object.– Example 2:

Drawing Inferences Drawing Inferences (Cont.)(Cont.) Activation and retraction of stereotypes

– BGP-MS automatically activates and retracts stereotypes for user by defining conditions for each case

– Only use most direct obtained assumptions Beliefs and goals reported by the application Assumptions made base on interview answers and dialog acts

– BGP-MS offers a set of pre-defined condition schemes for defining activation and retraction conditions.

IFKNOWN list – all knowledge in list are known IFUNKNOWN list – all knowledge in list are not known IFKNOWN% n – satisfied at least n percent of contents of the

stereotype are known IFKNOWN%OF n list- satisfied at least n percent for the contents in

the list– Example Activation condition:

Drawing Inferences Drawing Inferences (Cont.)(Cont.) Inferences within the individual user model

– Inferences within Views Use OTTER, resolution-based theorem prover Example:

– Inferences across Views Developer needs to formulate statements expression relationships

between different views Example


Inferences within the individual user model (Cont.)– Bi-directional inferences: Inference can be executed in two

ways Backward reasoning (refutation procedure in OTTER) - verifies

whether the queried item can be deduced from the current content of the user model

Forward reasoning - every input into BGP-MS can be examined to determine whether it leads to new assumptions.


Inferential dependencies and consistency maintenance– New assumptions may contradict old assumptions, so retract

is required– Store inferential dependencies between assumptions– Retract assumption, change assumption status instead of

hard-delete– Assign priorities to assumptions based on how and when they

were derived helping the retract process.

Interface for Application Interface for Application DeveloperDeveloper

Partition editor– Create and delete partitions– Create and delete

inheritance relationships between partitions

– Assign properties to partitions

Interface for Application Interface for Application Developer (Cont.)Developer (Cont.)

Stereotype editor– Define the activation and

retraction conditions of stereotypes

Comparison With Other Comparison With Other Shell SystemShell System

GUMS (1989)– Based on Prolog– Aimed to provide a set of service for maintaining

assumptions for users.– Does not draw assumption itself– Allows only one type of assumptions about the user to be

made at a time.– Definition of a stereotype hierarchy restricted to a tree– Only a single stereotype may apply to a user at a time.– Support 2 types of inference rules: definite rules, and default

rules.

Comparison With Other Comparison With Other Shell System (Cont.)Shell System (Cont.)

UMT (1992)– Define user stereotypes characteristics using attribute-value

pairs.– Support inheritance of stereotype contents– Does not draw assumptions itself– Strength is the recording of the inferential dependencies

assumptions for maximum consistency.– UMT’s inference is carried out in a forward-chaining fashion,

where BGP-MS is bi-directional.


um (1994)– Toolkit for user modeling (simpler than other shell system)– Use attribute-value-like structures for representation– Graphic-based hierarchical browser– Components become organized using topics and sub-topics

called ‘partial model’ PROTUM (1994)

– Related to UMT– Better stereotype retraction mechanisms than UMT– Truth maintenance mechanisms are better than BGP-MS


TAGUS (1994)– Shell system for user modeling and student modeling– Like BGP-MS, it communicates by message other than

function calls– Assumption are expressed in first-order formulas– Allow definition of stereotype hierarchy– Contains an inference mechanism– Support powerful update and evaluation requests


DOPPELGANGER– User model server– Accept TCP/IP connection – Clustering of user models, called ‘communities’– Advantages:

Application can be low-end machine since server handles user modeling tasks

Easy to allow different application to share user models New stereotypes and new inference rules can be easily

performed from user data gathered by different application.

– Handles security risk using authentication server

KN-AHSKN-AHS

Introduction– First application uses BGP-MS– An adaptive hypertext client of BGP-MS – Adapts the presentation of information depending on user’s

knowledge level

Service of BGP-MS that are used by KN-AHS– Messages for reporting and querying assumptions about the

user– Partitions for the individual user model and the stereotypes

KN-AHS (Cont.)KN-AHS (Cont.) Service of BGP-MS that are used by KN-AHS (Cont.)

– Partition can be divided into three groups: Individual user model = SBUB and SB~UB Stereotypes – e.g. ANY-PERSON Domain knowledge = SB

– SB-ONE for representation of domain knowledge

KN-AHS (Cont.)KN-AHS (Cont.)

User model acquisition in KN-AHS– Draws assumptions about the user’s knowledge based initial

interview, and hypertext actions.– Primary assumptions drawn based on user’s action on the

interface: If the user requests an explanation, a graphic, an example, or a

glossary definition for a hotword, then he is assumed to be unfamiliar with this word.

If the user unselects an explanation for a hotword, then he is assumed to be familiar with the hotword.

If the user request additional details for a hotword, then he is assumed to be familiar with the hotword.


User model acquisition in KN-AHS (Cont.)– Example Interface:


Adapting the document based on the user’s conceptual knowledge

– Aims to adapt the new text object to user’s knowledge– For all hotwords in the new text, KN-AHS asks BGP-MS if the

user knows about them using the bgp-ms-ask message.

ConclusionConclusion

BGP-MS is a user modeling shell system Used to help application maintain user’s knowledge,

beliefs and goals BGP-MS runs concurrently with application. Provide several ways of get/set assumptions about the

user Provide two ways to represent beliefs and goals: FOPC

and SB-ONE Draw inferences based on initial interview, user

actions, and stereotype about subgroups. Implemented in CMU Common Lisp on SUN

workstations.

User ModelUser Model

The User Modeling Shell System BGP-MS User Modeling For Personalized City Tours

By

Steven Sun & Yu-Chyuan (Trent) Su

User Modeling For User Modeling For Personalized City ToursPersonalized City Tours

Introduction Requirements for User

Modeling System in Travel Domain

Directory Component

User Modeling Components

External Clients Access Control Conclusion

IntroductionIntroduction

Current travel system– provides personalized information using user’s interests and

preference. This paper focus on building user modeling server

(UMS)– Personalized information by analysis user actions and behavior– Make generalizations, predictions, and assumption based on

domain knowledge and characteristics of similar users. – The information collected is called “user model” and maintained

by a “user modeling system”. Deep Map

– A prototype providing personalized web tourist guides using user modeling system.

Introduction: Deep MapIntroduction: Deep Map

Benefited from prior experience from AVANTI Deep Map involves the following research area:

– Geo-information system– Databases– Speech input and output– Multilinguity– Intelligent user interfaces– Knowledge representation– User modeling

Provide personalized behavior using user’s individual interests and preference, which is maintained by UMS.

Introduction: Deep Map, Introduction: Deep Map, WebGuideWebGuide

Deep Map’s sub project, WebGuide– Makes personal tour recommendations for the city of

Heidelberg WebGuide uses the following information

– Geographical information– Information about points of interest (e.g. Heidelberg Castle)– Information about selected means of transportation (e.g. car or

bike)– Individual user’s interest and preferences– Tour restriction specified by the user (e.g. regarding distance

and duration)

Introduction: Deep Map, Introduction: Deep Map, WebGuide (Cont.)WebGuide (Cont.)

Example of “Tour Recommendation of WebGuide– Left recommendation ignores user’s interests and preference– Right recommendation take user’s interest into account: dislike of

environmental burden (e.g. routes along streets with high traffic.)

Example of Deep Map’s mobile application that are location-aware

Requirements for UMS in Travel Requirements for UMS in Travel DomainDomain

Requirement Analysis– Learn the interests and preferences of users base on

their usage of the application– Predict interests and preferences of users based on

those of similar users (stereotypes).– Infer additional interests and preferences using

domain knowledge– Store, update, and delete explicitly provided

information and implicitly acquired assumptions.– Consistency and privacy of the user model contents– Supply authorized applications with current user

information

Requirements for UMS in Travel Requirements for UMS in Travel Domain: Generic UMSDomain: Generic UMS

Generic User Modeling System

– For DeepMap, the modeling system needs to be independent from specific user adaptive application

– Uses generic user modeling system, more specifically user modeling servers (UMS)

– Used directory management system (LDAP) instead of traditional database

Requirements for UMS in Travel Requirements for UMS in Travel Domain: Generic UMS (Cont.)Domain: Generic UMS (Cont.)

Contains two components:– Directory Component, three subsystems

Representation of information about the user Communication with User Modeling Components and External

Clients Mediation of its interaction with the User Modeling Components

– User Modeling Components is for user modeling tasks. User learning Component (ULC) Mentor Learning Component (MLC) Domain Inference Component (DIC)

External Clients are “consumers” and “producers” of information contained in the UMS.

The Directory Component The Directory Component

Representation– Models are based on standard LDAP– Implementation of Directory Component is based on Directory

Server– User Model– Usage Model– System Model– Service Model

Communication (three interfaces)– FIPA– LDAP– ODBC

Scheduler– Mediator

The Directory Component: The Directory Component: Representation, User ModelRepresentation, User Model

Devoted to users’ interests and preferences Example:

The Directory Component: The Directory Component: Representation, Usage ModelRepresentation, Usage Model

Storage for usage-related data within the UMS (e.g. a counter for Peter’s interface events)

Usage Model from an administrator’s point of view:– DIM Events Processed includes information that is required for,

and results from, processing usage data contained in DMI Events.– Backup and Backup History contains events from DMI Events

that have already been processed. Example:

The Directory Component: The Directory Component: Representation, System ModelRepresentation, System Model

Contains information about the application domain relevant for all user-modeling components.

Three parts:– Classifiers – e.g. map user’s age into appropriate age groups– Demographics – e.g. age– Interests – e.g. restaurants, buildings, history, etc.

Example:

The Directory Component: The Directory Component: Representation, Service ModelRepresentation, Service Model

Each entry represents a description of a server-internal event that the user-modeling component is interested.

Monitor events, and report to MLC or DIC.

The Directory Component: The Directory Component: CommunicationCommunication

UMS clients and Directory Component communicate via three interfaces

FIPA Interface– Communicate via high-level messages instead of COM or RMI– Mediate between Deep Map’s message and LDAP interface

LDAP Interface– Native LDAP connectivity provided by the directory server

ODBC Interface– Define relational mapping for the LDAP representation– Access these mapping from different application via ODBC

Monitor user model content for certain conditions (e.g. creation of new user models)

The Directory Component: The Directory Component: SchedulerScheduler

Mediate between Directory Server and the user modeling components.

Provision of LDAP-compliant user modeling functionality (e.g. creating and deleting user models)

Example:

User Modeling Component User Modeling Component

Three Sub-Components:– User Learning Component (ULC)– Mentor Learning Component (MLC) – Domain Inference Component (DIC)

User Modeling Component: ULC User Modeling Component: ULC

Learns user interests and preference from usage data, and update individual user models.

Feature-based filtering or content-based filtering Uses univeriate significance analysis

– A statistical technique based on the assumption that the occurrence of identical object is normally distributed for the user.

User Modeling Component: ULC User Modeling Component: ULC (Cont.) (Cont.)

Classification of a user’s interest:

User Modeling Component: MLCUser Modeling Component: MLC

Predicts missing values in user model based on others. Collaborative filtering Uses Spearman correlation for determining the how close

users are related to each other Three processes for mentor learning

– Finding similar users

User Modeling Component: MLC User Modeling Component: MLC (Cont.)(Cont.)

– Selecting mentors Select a small number of most similar neighbors (mentors)

– Computing predictions Uses deviation-from-mean to make predictions

– Formula if mentor exist:

– Formula if mentor not exist (average of the deviation-from-means across all user):

User Modeling Component: MLC User Modeling Component: MLC (Cont.)(Cont.)

Example:

User Modeling Component: DICUser Modeling Component: DIC

Infers interests and preference explicitly from domain knowledge or implicitly from ULC and MLC

Two type of implicit inferences:– Sidewards propagation – If user interested in a minimum

percentage s of direct sub-interests of a given interest, then the user is assumed to be interested on other sub-interests as well.

– Upwards propagation – If the user is interested in a minimum percentage u of direct sub-interests, then the user also hold this interest with a probability.

External ClientsExternal Clients

Deep Map Agents– Provide tour recommendations, analyze spoken input and

generate speech output

LDAP Browser– Manage user model

LDAP-Compliant Application– Inspect user model contents (e.g. search for a specific user)

Analysis and Visualization Tools– Find characteristics of the whole user population.

Access ControlAccess Control Grants or rejects access to a user model

– Perform operations (e.g. modify) on objects (e.g. users) Type of authorization

– Explicitly (e.g. through dedicated access control rules) or implicitly (e.g. through general access control rules)

– Positively (grant) or negatively (deny)– Strongly (cannot be overridden), or weakly (can be overridden by

more specific authorization)– By positive defaults (granted if not explicitly denied), negative

defaults (denied if not explicitly granted) Access control rules

– System Model - administrators– Usage Model - WebGuide, and other modeling components– Service Model – administrator and user modeling components– User models – respective owners– Operational attributes – LDAP server

ConclusionConclusion

First prototypical application of the UMS in a mobile tourist guide

Store user model representation in directory management system instead of database, which offers the following advantages:

– Manage and retrieval of user related information– Add new user related information types– Distribution of information across a network efficiently– Replication of information for performance and availability of

service– Security of information

General theme on User modeling General theme on User modeling softwaresoftware

Model user’s behaviors through “reasoning” Confidence rating on data collected from user is important Generalize user model through communities and

stereotype

Use user modeling shell system or server (UMS) to generalized the problem building user model

Infer assumptions bases on user’s actions Group user group to draw additional stereotypical

knowledge The main purpose for User Model is used to provide

personalized behavior

Documents

User Model The User Modeling Shell System BGP-MS User Modeling For Personalized City Tours By Steven Sun & Yu-Chyuan (Trent) Su