Natural Language Interaction With Dynamic Knowledge Bases: Monitoring as Response

1. INTRODUCTION

The overall goal of this research is support fo r na tural language interactions with a dynamically changing knowledge base.* One significant aspect of this environment is the added dimension along which a system can respond: that is, it can take the initiative and attempt to provide additional information presumed relevant to the user. In par­ ticular, the system can offer to inform the user of any information it may learn in the future, that is relevant to the user's query. For example, (S: System, U: User)

• U: Did A T & T common stock go up today?
• S : Yt>s. Shall I let you know if it keeps rising? or
• s: No . But shall I let you know if it starts a comeback?

In order to take such initiatives the system must be competent enough to monitor only for conditions which might possibly occur. Of course, this moni­ t oring behavior must also be relevant to the user's in.tentions. The major issues that must be addressed he re are as follows:

1. identifying those properties of actions, events, and processes that influence what monitor­ ing behavior is appropriate, e.g. what aspects of

+ This work is partially supported by a grant from the National Science Foundation, MCS 79-08401.

* For some work on cooperative responses in static knowledge bases , see L6], [8], and [9]. Some Issues concerning updatability are discussed in [5] . Fo r some work. on temporal aspects of knowledge bases, see [1], [2], [4], and [10] .

NATURAL LANGUAGE INTERACTION WITH DYNAMIC

KNOWLEDGE BASES: MONITORING AS RESPONSE+

Eric Mays, Sitaram Lanka, Aravind K. Joshi, and Bonnie L. Webber

Department of Computer and Information Science University of Pennsylvania Philadelphia, Pennsylvania 19104

the world may change and hence, what updates t o the knowledge base are expected or possible, how those aspects of the world may change and hence, what constraints exist on updates, etc. The l atter are also necessary for maintaining the consistency of the knowledge base as updates occur. Given that the events, processes and actions that the know­ ledge base reflects may not (or perhaps should not) be modelled as independent, knowing exactly what needs to be monitored will involve addressing the frame problem as well [7].

1. developing on adequate knowledge repre­ s entation capable of representing such properties. (Since our primary concern is appropriate monitor­ ing behavior, a full representation of actions, events and processes may not be necessary).
2. developing a language for expressing monitors.
3. identifying natural language cues to the kinds of additional information a user would find relevant**·
4. designing and implementing a system whi ch exhibits appropriate monitoring behaviors.

We have begun research in these five areas, and the brief examples which follow illustrate not only our current status but also the larger goals of the research on question-answering and monitor­ ing over dynamic knowledge bases.

2. EXAMPLE

For the purpose of illustration, we assume an entity-relationship type of model [3], as illus­ trated in Figure 1. Entity sets are shown in rec­ tangles, relationships set in diamonds with arrows from participating entity sets, and attributes with dotted links to the entity sets. So, for example, this particular schema shows that some users may run some programs, some have a name and a password, some users register for some courses, e t c . The crucial aspect is that the possible changes in the world represented in this da tabase (i.e., its updatability) can be encoded in the schema. Updatability here corresponds to the ability to update instances of an entity set, re­ l ationship set or attribute.

** ' Complete knowledge of the user s intentions would clearly help to frame appropriate monitoring behavior. However achieving this unambiguously is a formidable if not impossible problem. On the other hand, it is possible for the system to pre­ sume a certain intent and then exhibit the corres­ ponding monitoring behavior. What is necessary here is that the system inform the user of its presumptions so that s/he had the opportunity to correct them.

One method of encoding updatability informa­ tion is by means of the f orm (square brackets in­ di ca te choice and angle brackets, variables).

(UPDATABILITY <entity> [ADD, NO-ADD) (DELETE, NO-DELETE))

(UPDATABILITY <relationship> [ADD, NO-ADD] [DELETE, NO-DELETE])

(UPDATABILITY <attribute> [UPDATE, NO-UPDATE])

These assertions basically s tate whether or not additions and deletions can be made to a set and whether or not the value of an attribute may be upda ted. The following updatability assertions might be made for the schema shown in Figure 1.

(UPDATABILITY USERS ADD NO-DELETE) (UPDATABILITY USER-NAME NO-UPDATE) (UPDATABILITY USER-PASSWORD UPDATE) (UPDATABILITY PROJECTS NO-ADD NO-DELETE) (UPDATABILITY PROJECT-NAME NO-UPDATE) (UPDATABILITY PROGRAMS ADD DELETE) (UPDATABILITY PROGRAM-NAME NO-UPDATE) (UPDATABILITY COURSES NO-ADD NO-DELETE) (UPDATABILITY COURSE-NAME NO-UPDATE) (UPDATABILITY WORK NO-ADD NO-DELETE) (UPDATABILITY RUN ADD DELETE) (UPDATABILITY REGISTER ADD DELETE)

However, such assertions are insufficient since updatability may itself change over time. For example, at many universities, a student's abi lity to change his/her registration status de­ pends on whether it is registration period, break, drop-add period, etc. Thus the updatability of the registration relationship set is better represented as

Now consider the following question and the va rious periods during which it may be posed:

U: "Has John registered for CSEllO yet?"

(During pre-registration or registration (add) ... )

S: "No, but I'll tell you when he does."

(During break, drop, or after drop (no-add) ... )

S : "No".

Contrast that behavi or with

U: "Is John still r egistered for CSEllO?"

(Dur i ng registration or drop (de lete) . . . )

S: "Yes, but I'll h ·t you know when he isn't."

(During pre-registration, break or after drop (no delete) ... )

S: "Yes ."

The rule in operation here is to set up a monitor when a situation expected by the user might possibly occur. While the rule is clearly oversimple, it does lead to the relevant behavior. A crucial assumption here is that the length of interaction is short enough that updatability will not itself change during the interaction. Although this is adequat e for displaying such behaviors during short inte ractions, say a terminal session of a few hours, it is clearly not the case for those job functions that span the entire life of the knowledge base. The determination of the interaction length is therefore critical in the inference of appropriate monitors .

In addition to illustrating how outside pro­ perties shape appropriate monitoring behavior, the previous examples illustrate two syntactic forms (is/still, has/yet) that suggest the user's interests and hence what monitor might be relevant. That is, "yet" conveys that an event is expected to occur and "still", that a state is expected t o continue holding. Appropriate monitoring behavior then in the first case involves an offer to announce the event (or such an event) when it occurs (e.g. "but I'll tell you when he does"), and in the second case, an offer to announce when that state no longer holds (e.g., "I'll let you know when he isn't"). In the absence of such cues as "yet" and "still", the system might que r y the user about the possibility of setting a moni­ tor. However, to allow maximum flexibility, we include an extra slot in the updatability asser­ tion indicating whether a monitor should be set, not set, or a question posed to the user.

3. SUMMARY

Natural language interactions with dynamical­ ly changing knowledge bases, invite types of co­ operative behavior beyond those needed for i nter­ ac ting with static knowledge bases. We have brie fly indicated the status of our work in this area and our larger goals for the research on monitoring aspects of dynamic knowledge bases.