<?xml version="1.0" standalone="yes"?>
<Paper uid="W04-2503">
  <Title>Using answer set programming to answer complex queries</Title>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2 Representing general knowledge
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.1 The &amp;quot;geography&amp;quot; module M1
</SectionTitle>
      <Paragraph position="0"> The geography module M1 will contain a list is(baghdad,city).</Paragraph>
      <Paragraph position="1"> is(iraq,country).</Paragraph>
      <Paragraph position="2"> ...</Paragraph>
      <Paragraph position="3"> of places and the definition of relation in(P1;P2) - &amp;quot;P1 is located in P2&amp;quot; The definition is given by a collection of facts: in(baghdad, iraq).</Paragraph>
      <Paragraph position="4"> in(iraq,middle_east).</Paragraph>
      <Paragraph position="5"> in(paris,france).</Paragraph>
      <Paragraph position="6"> in(france,western_europe).</Paragraph>
      <Paragraph position="7"> in(western_europe,europe).</Paragraph>
      <Paragraph position="8"> ...</Paragraph>
      <Paragraph position="9"> and the rule</Paragraph>
      <Paragraph position="11"> For simplicity we assume that our information about relation in is complete, i.e., if in(p1;p2) is not known to be true then it is false. This statement can be expressed by the rule</Paragraph>
      <Paragraph position="13"> often referred to as the CWA- Closed World Assumption (Reiter, 1978) (for in). Here !p stands for &amp;quot;p is false&amp;quot; while not p says that &amp;quot;there is no reason to belief p&amp;quot;.</Paragraph>
      <Paragraph position="14"> Similar assumption can be written for is. The program has unique answer set containing in(iraq;middle east), -in(iraq;europe), etc. This answer set, (or its relevant parts) can be computed by answer set solvers. Sometimes this will require small additions to the program. For instance SMODELS, which require typing of variables, will not be able to compile this program. This problem can be remedied by adding a rule position(P) :- is(P,C).</Paragraph>
      <Paragraph position="15"> defining the type position and a statement #domain position(P;P1;P2;P3) declaring the type of the corresponding variables. Now SMODELS will be able complete the computation.</Paragraph>
    </Section>
    <Section position="2" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.2 The &amp;quot;travelling&amp;quot; module M2
</SectionTitle>
      <Paragraph position="0"> This module describes the effects of a person travelling from one place to another. We are mainly interested in locations of people and in various travelling events which change these locations. Construction of M2 is based on the theory of dynamic systems () which views the world as a transition diagram whose states are labelled by fluents (propositions whose values depend on time) and arcs are labelled by actions. For instance, states of the diagram, D, can contain locations of different people; a transition h 0;fa1;a2g; 1i2 D iff 1 is a possible state of the domain after the concurrent execution of actions a1 and a2 in 0. There is a well developed methodology of representing dynamic domain in AnsProlog (Baral and Gelfond, 2000; Turner, 1997) which, in its simplified form, will be used in the construction of M2.</Paragraph>
      <Paragraph position="1"> The language of M2 will contain time-steps from [0;n], fluent loc(P;X;T) - &amp;quot;place P is a location of person X at step T&amp;quot;. Various types of travelling events - fly;drive, etc., will be recorded by the list: instance_of(fly,travel).</Paragraph>
      <Paragraph position="2"> instance_of(drive,travel).</Paragraph>
      <Paragraph position="3"> ...</Paragraph>
      <Paragraph position="4"> Description of an event type will contain the event's name and attributes. The following is a generic description of John flying to Baghdad.</Paragraph>
      <Paragraph position="5"> event(a1).</Paragraph>
      <Paragraph position="6"> type(a1,fly).</Paragraph>
      <Paragraph position="7"> actor(a1,john).</Paragraph>
      <Paragraph position="8"> destination(a1,baghdad).</Paragraph>
      <Paragraph position="9"> An actual event of this type will be recorded by a statement null occurs(a1;i).</Paragraph>
      <Paragraph position="10"> (where i is a time-step in the history of the world) possibly accompanied by the actual time of i. In addition, M2 will import relation in(P1;P2) from the geography module M1.</Paragraph>
      <Paragraph position="11"> The transition diagram, D, of M2 will be described by ?? groups of axioms.</Paragraph>
      <Paragraph position="12"> +. The first group consists of state constraints establishing the relationship between the domain fluents. In our case it is sufficient to have the rules:</Paragraph>
      <Paragraph position="14"> disjoint(P1,P2).</Paragraph>
      <Paragraph position="15"> Here neq stands for the inequality. The first rule allows us to conclude that if at step T of the domain history X is in Iraq then he is also in the Middle East. The second two rules guarantee that X is not in Europe.</Paragraph>
      <Paragraph position="16"> +. The second group contains causal laws describing direct effects of actions. For our example it suffices to have the rules</Paragraph>
      <Paragraph position="18"> not interference(E,T).</Paragraph>
      <Paragraph position="19"> The first rule says that, in the absence of interference, a traveller will arrive at his destination. The second - the CWA for interference - states that the interference is an unusual event which normally does not happen.</Paragraph>
      <Paragraph position="20"> +. The third group consists of executability conditions for actions, which have the form -occurs(E,T) :- cond(T).</Paragraph>
      <Paragraph position="21"> which says that it is impossible for an event E occur at time step T if at that time step the domain is in a state satisfying condition cond.</Paragraph>
      <Paragraph position="22"> Causal laws and state constraints determine changes caused by execution of an action. To complete the definition of the transition diagram of the domain we need to specify what fluents do not change as the results of actions. This is a famous Frame Problem from (McCarthy and Hayes, 1969) where the authors suggested to solve it by formalizing the Inertia Axiom which says that &amp;quot;things tend to stay as they are&amp;quot;. This is a typical default which can be easily represented in AnsProlog. In our particular case it will have a form:</Paragraph>
      <Paragraph position="24"> not loc(P,X,T+1).</Paragraph>
      <Paragraph position="25"> The above representation is a slightly simplified version of AnsProlog theory of dynamic domains which gives notation for causal relations of the domain, includes general (fluent independent) formulation of the inertia, explains how the set of causal relations define the corresponding transition diagram, etc. We used this version to simple save space. Given the following history of the domain loc(paris,john,0).</Paragraph>
      <Paragraph position="26"> loc(baghdad,bob,0).</Paragraph>
      <Paragraph position="27"> occurs(a1,0).</Paragraph>
      <Paragraph position="28"> information contained in M1 and M2 is sufficient to conclude loc(baghdad;john;1), loc(baghdad;bob;1), loc(middle east;john;1), -loc(paris;john;1), etc. To answer the original queries we now need to deal with timing our actions. Let us assume, for instance, that the timing of John's departure from Paris is recorded by statements: null time(0,day,11).</Paragraph>
      <Paragraph position="29"> time(0,month,12).</Paragraph>
      <Paragraph position="30"> time(0,year,03).</Paragraph>
      <Paragraph position="31"> Here day, month, and year are the basic time measuring units.</Paragraph>
      <Paragraph position="32"> Finally we may need to specify typical durations of actions, e.g.</Paragraph>
      <Paragraph position="34"> not -time(T+1,day,D).</Paragraph>
      <Paragraph position="35"> where 1 * D * 31.</Paragraph>
      <Paragraph position="36"> To reason about the time relation we need to include a new module, M3, which will allow us to change granularity of our time measure.</Paragraph>
    </Section>
    <Section position="3" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.3 M3 - measuring time
</SectionTitle>
      <Paragraph position="0"> The module contains types for basic measuring units, e.g.</Paragraph>
      <Paragraph position="1"> day(1..31).</Paragraph>
      <Paragraph position="2"> month(1..12).</Paragraph>
      <Paragraph position="3"> part(start).</Paragraph>
      <Paragraph position="4"> part(end).</Paragraph>
      <Paragraph position="5"> part(middle).</Paragraph>
      <Paragraph position="6"> ...</Paragraph>
      <Paragraph position="7"> and rules translating from one granularity measure to another, e.g.</Paragraph>
      <Paragraph position="8">  answer our query. Ideally it should be much bigger and include a formalization of the calendar. Among other things the module should allow us to prove statements like next(date(10;12;03);date(11;12;03) and</Paragraph>
    </Section>
    <Section position="4" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
2.4 Planning the meeting - M4
</SectionTitle>
      <Paragraph position="0"> To answer the second question we need an additional module about the event meet. The event type for meet will be similar to the previously discussed flying event a1. It may look like: event(a2).</Paragraph>
      <Paragraph position="1"> type(a2,meet).</Paragraph>
      <Paragraph position="2"> actor(a2,john).</Paragraph>
      <Paragraph position="3"> actor(a2,bob).</Paragraph>
      <Paragraph position="4"> place(a2,baghdad).</Paragraph>
      <Paragraph position="5"> Notice however that the story contains no information about actual occurrence of this event. All we know is that a2 is planned to occur at time step one. We encode this by simply stating: planned(a2,1).</Paragraph>
      <Paragraph position="6"> Note that to give a positive answer to the question Q2 -&amp;quot;Did John meet Bob in the Middle East in mid-December? &amp;quot; we need to reason about planned events. It seems that our positive answer to this question is obtain by using a default: &amp;quot;people normally follow their plans&amp;quot;. Again this is a typical default statement which, according to the general knowledge representation methodology of AnsProlog could be expressed by the rule: occurs(E,T) :- planned(E,T), not -occurs(E).</Paragraph>
      <Paragraph position="7"> In a slightly more complex situation we may need to assume that people take their plans seriously - they persist with their plans until the planned event actually happen. This is encoded as follows: planned(E,T+1) :- planned(E,T), -occurs(E,T).</Paragraph>
      <Paragraph position="8"> Unlike traveling, the meeting event does not seem to have any obvious causal effects. It, however, has the following executability condition relevant to our story. -occurs(E,T) :- type(E,meet), actor(E,X), place(E,P), -loc(P,X,T).</Paragraph>
      <Paragraph position="9"> Now we have enough information to answer our second query, which can be encoded as ? occurs(E,T), type(E,meet), actor(E,john), actor(E,bob), loc(middle_east,john,T), time(T,month,12), time(T,part,middle).</Paragraph>
      <Paragraph position="10"> As expected the answer will be positive. There are several ways to obtain this answer. It can of course be extracted from the unique answer set of our program. With small additions of types and declaration of variables similar to that we used to define position in M1 this answer set can be found by SMODELS or any other answer set solver. This method however may not scale. The problem is caused the calendar. Its integer variables for months, days, etc, in conjunction with a longer history (and therefore a larger number of time steps) may cause an unmanageable increase in the number of ground rules of the program. It seems however that in many interesting cases (including ours), the computation can be made substantially more efficient by properly combining answer set finding algorithms with the traditional resolution of Prolog. The way of doing this will be illustrated in the full paper. We also plan to expand our modules especially those dealing with time and reasoning about plans.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 FrameNet and Events
</SectionTitle>
    <Paragraph position="0"> Our vision of the NLPM is that it will translate both our short text and also the queries into AnsProlog sentences.</Paragraph>
    <Paragraph position="1"> There is a body of literature on translating or parsing English sentences into a semantic representation such as First Order Logic. See (Blackburn and Bos, 2003) for a recent survey of such techniques. The semantic representation makes use of symbols based upon the lexicon of English.</Paragraph>
    <Paragraph position="2"> The success of our endeavor requires that there be an axiomatization of the relationship between the symbols representing functions and predicate symbols in our various AnsProlog theories (e.g., M1 - M4) and the symbols (based upon the lexicon of English) used in the semantic representation of the English queries and the narrative texts. The online lexical database, FrameNet(Baker et al., 1998) provides such a connection, especially for events.</Paragraph>
    <Paragraph position="3"> This is done through the notion of frame semantics that underlies FrameNet.</Paragraph>
    <Paragraph position="4"> Frame semantics assumes that lexical items draw their meaning from conceptual structures or frames that provide an abstract or scematic description of particular types of events. The frames are structured into an inheritance hierarchy. Each frame includes a number of frame elements (FEs) or roles that make up the conceptual structure. null For example, our &amp;quot;travelling&amp;quot; module M2 closely corresponds to the related FrameNet frames Travel, Move, and Ride Vehicle. The frames relate the various frame elements of Area (where the travelling takes place), Goal (where the travellers end up), Path (route of the travel), Source (starting point of the trip), and the Traveller (the living being which travels).</Paragraph>
    <Paragraph position="5"> Consider the phrase took a plane used to express the travelling activity. The verb take is associated with the frame Ride Vehicle. This information allows the connection with the axiomatization of flying events in M2. On the other hand FrameNet does not have entries for the verb spend as in spent Dec 10. But WordNet(Fellbaum, 1998) has 3 senses for the verb spend. Sense 1 is &amp;quot;pass - (pass (time) in a specific way. 'How are you spending your summer vacation?'). &amp;quot; Unfortunately, neither pass nor time allows us to index a useful frame for just being in a place. The coverage of FrameNet is not sufficient. It will be necessary to augment our use of FrameNet with other online sources such as WordNet and to also increase the number of frames within FrameNet.</Paragraph>
    <Paragraph position="6"> There has been some related work on using the frame of FrameNet for reasoning (Chang et al., 2002) and also on the automatic annotation of English texts with regard to the relevant frames (Gildea and Jurafsky, 2000) and frame elements.</Paragraph>
  </Section>
class="xml-element"></Paper>