generic user modeling systems alfred kobsa presenter: michael v. yudelson

Generic User Modeling Systems

Alfred Kobsa

Presenter: Michael V. Yudelson

Michael V. Yudelson (C) 2005 2

Roadmap

1. Definition

2. Academic (classic) GUMS Functionality, Requirements, Examples

3. Commercial GUMS Functionality, Requirements, Examples

4. Future of GUMS

5. Advanced Examples


Definition Generic/General User Modeling Systems

(GUMS)†

AKA User Modeling Shell Systems Generic/general – i.e. application

independent. Configured at development time, filled with specific user data and queried at run time.

†Term coined by Tim Finin inFinin, T. W. (1989), GUMS: A general user modeling shell. In: A. Kobsa and W.

Wahlster (eds.), User Models in Dialog Systems. Springer-Verlag, Berlin, Heidelberg, pp. 411-430, 1989


Roadmap

1. Definition



4. Future of GUMS



Academic (classic) GUMS

Early 90-ies Inherit from user-adaptive systems Structure and Process components choice

Intuition and experience based


Functionality if Academic GUMS(1) Represent assumptions about individual

characteristics (knowledge, goals, plans) Represent assumptions about group

characteristics – stereotypes (expert, novice) Classifying users into stereotypes Storing users’ history interaction with the

system Forming assumptions about user based on

his/her past interaction with the systems


Functionality if Academic GUMS(2) Generalization of user interaction histories

into stereotypes Inferring additional assumptions on the initial

ones Maintaining consistency of the model Evaluation of the entries in user model and

comparison with standards

All listed services are all ‘observational’


Requirements of Academic GUMS (Classical requirements)

Generality and domain independenceUsable in as many applications and domains as

possible and provide as many services as possible

Expressiveness Express as many assumptions about user as

possible Strong inferential capabilities

Perform various types of reasoning and conflict resolution


Observations on Academic GUMS Domain independence is often violated (at

the cost of generality)Adaptive learning environments (Brusilovsky)User-tailored web sites (Kobsa)Complex capabilities are becoming redundant

Almost all GUMS are ‘mentalistic’Model propositions (goals, plans, knowledge),

behavior is an information sourceVery few detect behavior patterns (e.g. LaboUr,

DOPPELGÄNGER)


Examples of Academic GUMS (1) BGP-MS (Kobsa and Pohl, 95; Pohl, 98)

Assumptions about user and user groups Assumptions represented in first order

predicate logicSubset of assumptions are stored as

terminological logic Inferences across multiple types of

assumptions (i.e. types of modals)Deployed as a server with multi-user and

multi-application capabilities


Examples of Academic GUMS (2) DOPPELGÄNGER (Orwant, 95)

Accepts information from software and hardware sensors

Generalizing and extrapolating data from sensors

linear prediction Markov models unsupervised clustering for stereotypes

Scrutabile and open user model (inspectable and modifiable)


Examples of Academic GUMS (3) um (Kay, 95) – a toolkit for user modeling

Stores assumptions about user characteristics Knowledge, beliefs, preferences

Stores as attribute-value pairsEach piece of information has a list of evidence

for its truth or falsehoodThe source of each piece of evidence is also

recorded


Roadmap

1. Definition



4. Future of GUMS



Commercial GUMS

Personalization paradigm Individualized delivery of promotions, news,

ads, and services Shift to a “one-to-one” marketing in e-

commerce


Characteristics if Commercial GUMS User information is stored in an integrated

repository shared by multiple applications User information acquired by one system can

be employed by others Information about user is stored in non-

redundant manner User stereotypes are set a priori Methods and tools for security, identification,

and access control are actively used

User information


Requirements of Commercial GUMS

Comparing different user actionsMatching definitive actions (purchases of certain

items) to vague concepts: taste, personality, lifestyle. AKA Collaborative filtering

Import of external user informationBroad variety of user data and data formats

require interfaces allowing integration at a reasonable cost

Privacy support


Observations on Commercial GUMS

Very behavior-orientedAction patterns lead directly to adaptation

without explicit representation (e.g. via goals, plans)

Rate poorly on requirements of Academic GUMS Generality, expressiveness, inference)

Quite domain dependantUsed for limited personalization purposes


Classical GUMS Requirements revised for Commercial GUMS (1)

Quick adaptationE-commerce web application require adaptation

after a short term of interaction. Methods vary depending on amount of information at hand

ExtensibilityStrong data and process integration capabilities

are required Load balancing

Servicing high volumes of users without degradation of quality


Classical GUMS Requirements revised for Commercial GUMS (2)

Failover strategiesFallback (rollback) mechanisms in case of a

breakdown Transactional Consistency

Parallel read/writes of assumptions about user Inconsistency resolution


Examples of Commercial GUMS (1)

Group Lens (Net Perceptions 2000)Collaborative filtering to determine user

interestsCollects explicit ratings (online forms), and Implicit ratings, derived from navigation

Products user reviewed Products user added to the shopping cart Products purchased



Personalization Server (ATG 2000)Multiple rules for classifying user into

stereotypesUser data: demographic, system usage, user

software and network environmentRules for inferring individual assumptions from

user behaviorTarget: personalization of web-page contentHard-core stereotype approach (Rich)



Learn Sesame (Open Sesame, 2000)Domain model: objects, attributes and eventsCategorizes incoming information (from an

application) according to domain model Incremental clustering: detects

Recurring patterns Similarity Correlations

Interesting observations are reported back


Roadmap

1. Definition



4. Future of GUMS



Future trends of GUMS Mobile GUMS

Agents residing on mobile devices.Bandwidth and computation power limitation

GUMS for smart appliancesE.g. Car/engine lock and wheel/sit/mirrors

settings in smart card/chipE.g. Accelerator/Gear chip in Automobile


Roadmap

1. Definition



4. Future of GUMS



Advanced Examples

A. Unified User Context Model (UUCM) – Niederée et al

B. Personis – Kay et al


Advanced Examples – UUCM (1) Unified User Context Model (UUCM)

Contexts – capture user behavior relevant to different situations

Dimensions – address various approaches to personalization

UM LevelsAbstract – meta-ontology of:

Contexts, facets, facet properties, model dimensions

Concrete – extended ontology of: Dimensions and facets


Advanced Examples – UUCM (2) User model – consists of (1-M)

Contexts – described by (N-M) Facets – belong to one or many (N-1)

Dimensions, like Task dimension (Current task f., Task history f.) Relationship dimension () Cognitive pattern dimension (competence f., preference f.) Environment dimension (Time f., Location f., Device f.)

Abstract, Concrete


Advanced Examples – UUCM (3) Context – Passport presented to a system

Groups of facets relevant to particular role user plays – Working Contexts (UM design time conf.)

As user role changes – different WC is usedSubsets of the facet groups used by a particular

system – Context-of-Use (IS run time invocation) System might not address all the facets of the context

UM Context – IS interaction IS partially interprets Working Context (In) IS updates Contexts to reflect interaction with

user


Advanced Examples – UUCM (4) Summary

UUCM – Framework for cross-system deployment of multi-dimensional UM

UM defined as full as possible IS read and write from/to part of it

Protocols are yet to be developed


Advanced Examples

A. Unified User Context Model (UUCM) – Niederée et al

B. Personis – Kay et al


Advanced Examples – Personis (1) Main paradigm – scrutinized UM

User can review his/her UMUser can change his/her UM

Environment componentsUM ServerDirect (generic) scrutiny interfaceMultiple Adaptive SystemsMultiple Views/Filters between UM Server and

Adaptive Systems (AS scrutiny interface)


Advanced Examples – Personis (2) User control over the model

View/Change UMAllow Adaptive Systems to control parts of

his/her UM Parameters, values, source of information


Advanced Examples – Personis (3) Personis Internal Architecture

OODB accessible throughUser Model ServerManagement interfaceAdaptive Systems implemented as UMS Clients

Each AS deploys resolvers on UMS – interpreters of the low-level evidence

ImplementationXML RPC


Advanced Examples – Personis (4) Language of Personis (abstraction)

Connecting to UMS um=access(odbname,login,password)

Requesting information componenets=um.ask(context,view,resolver_id)

Writing information tell(context, component, evidence)


References Kobsa, A. (2001) Generic User Modeling Systems. User

Modeling and User-Adapted Interaction. 11, 49-63, Kluwer, 2001

Niederée, C., Stewart, A., Mehta, B. and Hemmje, M. (2004) A Multi-Dimensional, Unified User Model for Cross-System Personalization. In: Proceedings of the AVI 2004 Workshop On Environments For Personalized Information Access, 2004.

Kay, J., Kummerfeld, B., Lauder, P. (2002) Personis: A server for user models. In: AH’02: Proceedings of Adaptive Hypermedia and Adaptive Web-Based Systems, Springer-Verlag, London, UK, 2002


Questions…

generic user modeling systems alfred kobsa presenter: michael v. yudelson

Documents

yudelson slide

yudelson c

examples of academic

user groups assumptions

future of gums

user models

commercial gums functionality

doppelgnger slide