GUMS - A General User Modeling Shell Timothy W. Finin Presentation by Walter Patterson >Class Notes by Alison Nichols >October 17, 1994 >The following are Walter's overheads: GUMS - A General User Modeling Shell A general architecture of a domain independent system for building and maintaini No long term models of individual users. What is a user model? A user model is that knowledge about the user, either explicitly or implicitly encoded, which is used by the system to improve the interaction. Additionally: 1. Separate Knowledge Base 2. Explicit Representation 3. Declarative rather than Procedural 4. Support for Abstraction 5. Multiple Use Important Issues: Who is being modeled? - degree of specialization - temporal extent What information is represented in the model? - Goals & Plans - Capabilities - Attitudes - Knowledge or Belief How is the model acquired and maintained? - Acquisition - Maintenance How will the model be used? - Support task of recognizing and interpreting behavior of user - Provide user with help and advice - Acquire information from the user - Provide information to user GUMS - A General User Modeling Shell User model as a Deductive Database: Allow models of individuals as facts that can be asserted, retracted, or queried. Who? Long term models of individual users, associated with one or more stereotypes What Modeled? Domain independent How Acquired and Maintained? Application responsible for acquisition, providing services for maintenance, selecting initial stereotype Why is the model there? Depends on application (domain independent) GUMS System Organization - GUMS derives user model from application, not directly from user - Collection of stereotypes organized in a hierarchical taxonomy - Collection of models for each individual: Users are leaves in the hierarchy tree - Facts and rules either definite or default Default Reasoning in GUMS Stereotypes and Individuals Definite Facts and Rules Default Facts and Rules Metaknowledge Default Reasoning with Rules facts and rules certain vs. default 4 value logic Failures as Negation "open world assumption" GUMS: can use "closed world assumption" also "completing the database" GUMS guts: Backward-chaining Prolog meta-interpreter Evaluates and compares many possible answers to each query Seeks strong answers before weak Limitations: Redundancies, efficiency >Class Discussion: Top level sterotype - programmer - list facts about programmers a.knows programming b.eats donuts @ 3:00 A.M. This is the default behavior, under which are subclasses such as novice programmers and wizards. These break down further into individuals : Tom, Bob These are the leaf nodes. They have all the properties including the default properties of all the higher rungs. If there is a conflict, backtrack up the tree until there is no conflict or contradiction. Definite facts & rules Default facts &rules GUMS is designed to work with facts (P is true), rules (if, then) and 4 value logic (true, false, assumed true, assumed false) Default facts are assumed to be true. Default P if Q is weaker form of logic but valuable to have these inferences. GUMS guts - Sits on the back of an application - automatically seeks string answers before weak answers (ones that are definitely true). When the model becomes too large, inconsistencies can occur. Questions: This is a general model and application independent. If system is too general purpose, do you lose usefulness? Unix, KShell are general purpose, but also flexible enough to do whatever you want. Should this be general enough to apply to word processing, games, spreadsheets, etc.? Even computers are specific to their use - one for desktop publishing, one for multimedia, etc. What about scalability? GUMS needs application specific interface perhaps. But, does that do away with the general-ness of it? GUMS isn't used as a system itself for its own sake. That is a problem in a way. Prolog is used for unification which can be good depending on what it's being used for. How does this system deal with contradiction? It pops you up to another level in the stereotype hierarchy. Where does it end? When you go out of a stereotype, where do you go? (Paths) What are the implcations of changing stereotypes? Is it sudden and shocking to the user? This may be difficult to compenste for. We can warn the user..."Do you really want to do this?"..... Is there a protocol for telling the user that the application is about the change or is it just done without the user's knowledge? What happens when the user graduates out of novice class? Binary tree may not be detailed enough to deal with all the individual user models. We may need more categories. The tree may not be big enough. There may be contradictory issues, for instance a user may be a Unix wizard and a C novice...does this person know the VI editor or not? This doesn't consider more that one application at a time. User in sterotype - the user can move up until there is no more place for him. But, how does the user get in the stereotype in the first place? This is left up to the application, but how is it handled? A serious set of assumptions is needed to move the user up and down another branch until a fit is found. You want the user in the group where he fits best, but you must have a good set of assumptions in order to get him there. Do these groups need to be mutually exclusive? Maybe not, but they need to fit the person in the right place.