; COMPUTING GOOD-TIME AND BAD-TIME ; *** Can we generalise any of this? For example, can we generalise ; def_rel to a monotone quantifier? And can we generalise ; numbered_hour_rel, so that we have one function for dofm, dofw, ; numbered_hour, and so on? ; ; All these rules will need a temp_rel constraint on the bound ; variable in the input, once mrs munging rules can handle ; supertypes. This is so that we get good_time only when the ; appropriate variable is a temporal expression. And we will need ; corresponding good_place rules for place_rel's (e.g., "office" will ; have to be classified as a place_rel). ; ; All these expressions will have to have temp_rel and ; monotonic_quantifier conditions added once the munging rules can ; handle supertypes, and once the quantifier types are introduced. ; Nonmontone quantifiers such as "no" will need to be handled by other ; rules. ; ; alex_equals_rel(c,x) is to be interpreted as "c denotes an ; interval which temporally includes x". So remember that it's ; temporal inclusion rather than equality that we should have here!!!!!!!!! ; ; good_time(c) is to be interpreted as follows: ; good_time(c) is true iff: ; (a) c is a good time, and ; (b) if there is a c' such that for all P except good_time where P(c) ; is true, P(c') is also true, then c is contained in c'. That is, c ; is the minimal interval that satisfies the conditions in the MRS ; that are placed on c. ; ; bad_time(c) will be interpreted in a similar way. Note that if we ; sometimes need something other than the minimal interval, then we ; can separate out conditions (a) and (b) in the truth definition of ; good_time, and we should make good_time just mean (a), and some ; other predicate such as alex_mininterval_rel(c) mean the (b) part. ; ; When we have something like "every Monday is good", we will get ; good_time(c) in the top handel, and ; alex_equals_rel(c,x) in the scope of the quantifier every where x ; is the bound variable. This will mean that any x that satisfies ; Monday(x) is included in c, but c is also the smallest interval that ; contains these x's. In other words, c is exactly the set of ; elements x such that x satisfies Monday(x). In "No monday is good" ; we want to get bad_time(c) in the top handel, and ; alex_equals_rel(c,x) in the scope of a universal quantifier which has ; the same conditions in its restrictor as appear in the restrictor of ; "no". So this will mean that for any x such that Monday(x) is true, ; x is in c, and c is the smallest interval that contains these x's, ; and c is a bad_time. "No Monday is bad" will be similar, except ; we'll have good_time(c) replacing bad_time(c). ; ; Note that for non-monotone quantifiers, we must repeat the ; conditions in the restrictor within another quantifier. This is ; because putting alex_equals_rel(c,x) in the scope of the ; "no"-quantifier doesn't semantically give what you want. ; no(x,K1,K2) is verified by an embedding function f if for any g that ; extends f, if g verifies K1, then there is no h that extends g which ; verifies K2. So if we put alex_equals(c,x) in K2, then the result ; will mean that either alex_equals(c,x) is false, or Q(x) is false, ; where Q(x) is the original stuff that was in there. But we want to ; maintain that Q(x) is false, and ensure alex_equals(c,x) is true. ; This is why we have to repeat the restrictor stuff in a universally ; quantified formula in these cases. ; ; When we deal with something like "No Monday is good", we want ; bad_time(c) & alex_minimal_interval(c) at the top handel, and ; alex_includes_rel(c,x) in the scope of a universal quantifier which ; repeats the restrictor in the "no"-quantifier. "No Monday ; is bad" requires good_time(c) instead of bad_time(c). ; ; Dealing with " is fine" ; ------------------------------------------- ; ; I have ensured ; that good-time picks the right interval by identifying the variable ; with the one that _fine predicates over. This means that even ; though there is a reading of "two on the sixteenth is fine" where ; the quantifier introduced by the sixteenth has wide scope over the ; one introduced by "two o'clock" (and this is a spurious ambiguity), ; good-time will still predicate over a constant that is equal to the ; variable that denotes two o'clock, and this will be attached to the ; top handel. So here dealing with underspecification helps us; we ; don't have to worry about the relative scope of the quantifiers in ; the input to the re-write rule. ; ; This should handle "two is fine", "two fifteen is fine", "two ; o'clock on the sixteenth is fine", "two seems fine", "the sixteenth ; is fine", "two in the afternoon is fine", "two would be fine", "two ; would probably be fine". ; "that will be fine with me", "that's fine by me", "if you want to do ; it before twelve, that is fine" etc etc. Note that with this last ; sentence, discourse update would need to be used to resolve "that" ; to "twelve" rather than "you want to do it before twelve", because ; we are placing good-time(x) on the argument x of _fine. ; ; It should not do "Fine, but not two", or "Fine, at two", because ; "fine" in these sentences produces EXCL(fine) in the MRS. ; ; There are still bugs, which mean that "two seems fine" has ; interpretations were _sound_seem is in the restrictor of the ; quantifier. Furthermore, "fine by me" doesn't trigger this rule, ; because this sentence produces only readings for "fine" where it's ; an ADV rather than an ADJ, and it produces EXCL(fine) in the MRS. ; ; There's a sentence in the verbmobil corpus "That would be fine, on ; August 8th at 9:30", where we get good-time(v10) where v10 is ; identified with "that"; as with discourse update across sentence ; boundaries, we will have to use discourse principles to identify ; "that" with the time expression given, namely August 8th at 9:30. ; Similarly for "If you want to do it before 12, that would be fine". ; See the file ; ~/Research/California/Data/Parsed.Data/finding.antecedents for more ; on how we will resolve anaphora such as "that" in "that is fine". ; ; This rule will work for "that is fine"-type sentences only if we ; make the simplifying assumption that "that" always resolves to a ; time. For otherwise, we're stating good-time(x) on something that's ; not a time. This is an unsound assumption, but it seems to work in ; practice. This is because ; all the sentences in Verbmobil of the form "that's fine with me" are ; ones where it would be reasonable to identify "that" with a time ; expression (although many of these from a theoretical semantic point ; of view actually should stand for events such as "meeting you on the ; 16th"). There is one exception to this: "A: I would love to get ; some lunch afterwards. B: That would be fine." ; ; Note that as things stand, it supplies good-time even if _fine and ; support are in the restrictor of the quantifier. ; ; Note that this rule does not handle negation. We need to modify ; this rule by adding conditions in the input that negation isn't ; present, and then we need to produce a corresponding rule that ; produces bad-time in the output when there is negation in the input. ; As things stand, "two isn't fine" triggers the rule below, to ; produce good-time (but at least the alex_equals isn't in the scope ; of the negation!). time_is_fine_rule := mrs_rule & [ INPUT.LISZT , LCONDITION.LISZT , OUTPUT.LISZT ]. ; DEALING WITH " is impossible" ;------------------------------- ; This rule should fire for "two is impossible"; "the sixteenth is ; impossible"; "two sounds impossible" etc etc. We would have similar ; rules for "that is bad", "two is bad", "two is scheduled", "two ; seems bad", "the twenty seventh is pretty full", and so on. To get ; these other rules producing bad_time, just replace _impossible_rel ; below with _bad_rel, _full_rel, _schedule_rel, etc. ; ; ; This produces bad_time. We need a corresponding good_time rule for ; when negated condition is present (i.e., for "two is not impossible"). ; This rule lacks the necessary condition that there is no negation in ; the sentence. This has to be added. time_is_impossible_rule := mrs_rule & [ INPUT.LISZT , OUTPUT.LISZT ]. ; BEING ON VACATION ON ; ------------------------------------- ; This will produce bad_time for "I will be on vacation on ; ", where can be "the sixteenth" ; "some time around the sixteenth", (when time gets typed as a temp_rel ; and these rewrite rules are able to reason about supertypes), "every ; Monday in March", etc etc. It can also handle "I will take my ; vacation on ", "I plan to take my vacation on ; " etc. This is because there are no constraints at ; all on the INPUT as to what the verb is. The input only requires ; the word VACATION, and for there to be an _on_temp_rel to a time ; expression. So there is a danger of over-generation here. ; ; Note that there is a bug in the grammar (on 29/9/98), in that some ; of the parses of "I am on vacation on the sixteenth" produce MRSs ; that don't contain _vacation(x3). Some do, however. ; ; We will be able to generalise this rule once we can have ; inc_temp_rel as a supertype, to handle "vacation on...", "vacation ; for ...", "vacation in March" and "vacation around ...". When we ; can use supertypes, we can replace _on_temp_rel with ^c21 & ; inc_temp_rel in the input and output. We need another rule for ; handling "vacation until the sixteenth" or "vacation by then". In ; the former case, we want the bad_time to be ; between some anaphorically specified time and the ; sixteenth, rather than it being the sixteenth. This rule would need ; the same kind of ploy as we use in the rule for generating good_time ; for "Let's meet after the sixteenth", given below. Similarly for ; "vacation after the sixteenth" and "I will be on vacation by then" ; ; Note that there are some parses of "I am taking a vacation on the ; sixteenth", where the _on_temp_rel modifies "vacation" rather than ; the event. The rule below introduces bad_time for both the cases ; were the parse is "I am taking (vacation on the sixteenth)" and for ; the parse "(I am taking vacation) on the sixteenth". vacation_on_t_rule := mrs_rule & [ INPUT.LISZT , OUTPUT.LISZT ]. ; WORKS ; ---------------------- ; This produces good_time for "two o'clock works for me", "the ; sixteenth will work", "every monday in March works" etc. etc. ; ; Note that we need to add the negation constraint. We need a ; corresponding bad_time rule to deal with "the twenty seventh does ; not work". ; t_works_rule := mrs_rule & [ INPUT.LISZT , OUTPUT.LISZT ]. ; SOUNDS FINE ; ----------- ; ; "sounds/that is fine" should produce good-time. ; "sounds fine" doesn't explicitly produce a time variable, however. ; But it does produce a structure where there is a pron(x7) and ; _fine(x7,d8), and good_time ; should predicate over this pronoun. ; ; This deals with "sounds fine" when there is no quantifier, but a ; pronoun condition is introduced instead. There is no need ; for an alex_equals condition. This will also handle "that is fine", ; "that seems fine" etc.; ; ; Note that this rule overgenerates, because it doesn't take into ; account any resolution of the antecedent that "that" in "that is ; fine", or the implicit pronoun in "sounds fine". The algorithm for ; computing this has not been encoded yet; Ann will do it. See the ; file ~/Research/California98/Data/Parsed.Data/finding.antecedents ; for the heuristics for finding the antecedents. Once this ; algorithm is coded up, the rule below will need to be changed to include ; a temp_rel(x4) condition (as with all the other rules for ; introducing good_time and bad_time). There will also be an equivalent ; good_place rule for "that is fine", when the pronoun "that" is ; resolved to satisfy place_rel(x4). ; ; Note that this rule does not handle negation. We need to modify ; this rule by adding conditions in the input that negation isn't ; present, and then we need to produce a corresponding rule that ; produces bad-time in the output when there is negation in the input. sounds_fine_rule := mrs_rule & [ INPUT.LISZT , OUTPUT.LISZT ]. ; SOUNDS GOOD ;------------ ; "two sounds good" and "sounds good" should both produce good-time. ; "sounds good" doesn't explicitly produce a time variable, however. ; But it does produce a structure where there is a pron(x7) and ; _good(x7,d8), and given the parse for "two sounds good", good_time ; should predicate over this pronoun. ; ; ; This deals with "sounds good" when there is no quantifier, but a ; pronoun condition is introduced instead. ; ; Note that this rule does not handle negation. We need to modify ; this rule by adding conditions in the input that negation isn't ; present, and then we need to produce a corresponding rule that ; produces bad-time in the output when there is negation in the input. sounds_good_rule := mrs_rule & [ INPUT.LISZT , OUTPUT.LISZT ]. ;