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

2. The User Modeling Shell System BGP-MS Introduction Information Flow User Modeling Representation Inference Interface for Application Developer Comparison with Other Shell Systems Example Client: HN- AHS Conclusion

3. Introduction 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.

4. 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

5. Information 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

6. Information 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.

7. Information Flow: Message Types 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

8. Information Flow: Message Types (Cont.)

9. Information Flow: Informing Beliefs 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

10. Information 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)

11. Information Flow: Interviewing (Cont.) Example BGP-MS question: Example user answer:

12. Information Flow: Informing Observation Provided directly by the user Draw inferences based on the user’s input Message format for reporting user actions:

13. Information Flow: Asking for Current Assumptions Message with label bgp-ms-ask Example question: Example answer

14. Information Flow: Send Inferred 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

15. Representing User Model and Domain 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’.

16. Representing User Model and 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

17. Representing User Model and 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

18. Drawing 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.

19. Drawing Inferences (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:

20. Drawing Inferences (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:

21. Drawing Inferences (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:

22. Drawing Inferences (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

23. Drawing Inferences (Cont.) 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.

24. Drawing Inferences (Cont.) 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.

25. Interface for Application Developer Partition editor – Create and delete partitions – Create and delete inheritance relationships between partitions – Assign properties to partitions

26. Interface for Application Developer (Cont.) Stereotype editor – Define the activation and retraction conditions of stereotypes

27. Comparison With Other Shell 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.

28. Comparison With Other 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.

29. Comparison With Other Shell System (Cont.) 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

30. Comparison With Other Shell System (Cont.) 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

31. Comparison With Other Shell System (Cont.) 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

32. KN-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

33. 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

34. 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.

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

36. KN-AHS (Cont.) 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.

37. Conclusion 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.

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

39. User Modeling For Personalized City Tours Introduction Requirements for User Modeling System in Travel Domain Directory Component User Modeling Components External Clients Access Control Conclusion

40. Introduction 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.

41. Introduction: 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.

42. Introduction: Deep Map, WebGuide 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)

43. Introduction: Deep Map, 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

44. Requirements for UMS in Travel Domain 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

45. Requirements for UMS in Travel Domain: 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

46. Requirements for UMS in Travel 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.

47. 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

48. The Directory Component: Representation, User Model Devoted to users’ interests and preferences Example:

49. The Directory Component: Representation, 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:

50. The Directory Component: Representation, 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:

51. The Directory Component: Representation, 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.

52. The Directory Component: Communication 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)

53. The Directory Component: Scheduler Mediate between Directory Server and the user modeling components. Provision of LDAP-compliant user modeling functionality (e.g. creating and deleting user models) Example:

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

55. 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.

56. User Modeling Component: ULC (Cont.) Classification of a user’s interest:

57. User 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

58. User Modeling Component: MLC (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):

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

60. User 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.

61. External 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.

62. Access 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

63. Conclusion 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

64. General theme on User modeling software 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