AVM Task Representation

Chapter 8: Two Case Studies

8.1. Computer-Retailing System

The first describe ame as

described n 5.2.1. ter-retailing example. The task mainly consists ery system and the goal of the application is to provide the price of a computer selected according to specific features provided the comple ling task is not considered (no credi ed or whatever).

The database contains 350 different computer configurations split into 2

tables (for no _mac (pc or

mac), process brand.

example in sectio

d in the framework of SDS design is the s 1: the compu

in a database qu by the user. Notice that t-card number ask

te sel

tebooks and desktops) containing 6 fields each: pc or_type, processor_speed, ram_size, hdd_size and

8.1.1. AVM Task Representation

Since the task relies on an existing database, the AVM representation is quite straightforward. Attributes are the fields of the database and an additional attribute is added for the table name. Generally speaking, choosing the table in a database is often associated to the choice of a goal type. Here, two goal types can be distinguished, buying a notebook or a desktop computer. The

AVM representation of this task is shown in Table 15. The used database has three years old so described computers are not sold anymore.

Attributes # Values

table 2 ‘Notebook’, ‘Desktop’

pc_mac 2 ‘PC’, ‘Mac’

processor_type 9 ‘Pentium II’, ‘Pentium III’, ‘Celeron’, ‘AMD-K6- 2’,

‘AMD K7’, ‘AMD Athlon’, ‘Cyrix’, ‘G3’, ‘G4’

processor_speed 551 [350-900] MHz ram_size 3 32, 64, 128 hdd_size 4 20, 30, 40, 60 Gb

brand 14 ‘IBM’, ‘Sony’, ‘HP’, ‘Toshiba’, etc.

Table 15: AVM representation for the computer retailing task.

Some values for a given attribute exclude values for another (like, PC excludes the ‘G3’ value for the processor type) but such internal structure will not be specified. Indeed, if the user provides incompatible values, that will lead to an empty result of database queries. The system should learn to behave correctly in such a case.

8.1.2. Action Set

Since the task involves database querying, actions will not only imply interaction with the user but also with the database. The following action variables will be considered:

Variable Values

Type: AS

‘greet’, ‘constQ’, ‘openQ’, ‘expC’, ‘allC’, ‘rel’,

‘dbQ’, ‘close’

Attr ble,

{0,1}

ibutes: ta ac, pc_m

processor_type, processor_speed, ram_size,

hdd_size, brand

Table 16: Action set for the computer-retailing example

All attrib not modifying all actions thus, of the AS

variables exclude the 1 value ibute var example, the

‘greet’ ac g) is no any attri er the ‘close’

action. On another hand, there are some va

argument modifies them like (constra tion), ‘expC’

(explicit con

the size tributes

ording to these considerations, the action

As argued previously, the state space is very important and several state spaces can be investigated for the same task. Table 17 shows available state variables for building the current task’s state space. In this table, each attribute of the task’s AVM is present (Attributes), the ‘status’ variable indicates

utes are certain values

iables. For for certain attr

t modified by

tion (greetin bute, neith

lues involving that only one the ‘constQ’ ining ques

firmation) and ‘rel’ (relaxation) actions. This reduces dramatically of the action set. Finally, there are actions modified by all at

at the same time like ‘openQ’ (considering that the open ended questions accepts any attribute or sequence of attributes as a valid answer), ‘allC’

(confirma all) and ‘dbQ’ (since the database query is conditioned by all the attributes provided by the user). Acc

set size is 25.

Reader will notice that there is no data presentation action. Actually, it is considered that the data presentation is included in the ‘close’ action.

8.1.3. State Space

whether the attribute has been confi has a corresponding confidence leve

rmed by the user or not, each attribute l CL and the ‘DB’ variable indicates the

. It is important to know that the larger the value set is, the larger will

ro, 1994]).

When using the value set of the right column (only composed of Boolean values), the state space size decreases to 2¹⁰ states, which is already tractable but quite large for this simple task.

i

number of database records that correspond to AV pairs retrieved so far.

Table 17 also shows that different sets of values can be used for each variable

be the resulting state space.

For example, if one takes the values of the first column to build a state space, its size will reach more than 10⁹ states, which would lead to an almost intractable solution (unless using particular techniques like in [Tesau

Variable Values

Attributes: table, pc_mac,

processor_type, processor_speed, ram_size,

hdd_size, brand

Actual Values {known, unknown}

Status: {confirmed, not

confirmed}

ASRCL: {CL_i} Discrete Value

{.0, .1, …, 1.0} {high, low}

DB: retrieved

records Actual Values Number of records or {high, low}

Table 17: State space variables for the computer-retailing example

The state space size can still be reduced by noticing that when an attribute is

‘unknown’, it cannot nfidence level. Thus

plemented. This

In the experime here wo c tested. The

first is the 2⁸-state state space using Boolean values described in the above (S₁) and the other, even simpler is realised by n ing ‘DB’ variable

in the set of s ).

be ‘confirmed’ and has a ‘low’ co ave to be im some states will never been visited and don’t h

reduces the state space size to 2⁸.

nt exposed , t different state spa es are ot includ the tate variables (S₂