semi_sg.vpm

;;; -*- Coding: utf-8; -*-
;;;
;;; a first attempt at mapping (systematically) between the grammar-internal
;;; name space (where, for example, there may be reasons to group sets of index
;;; properties in nested feature structures) and the external, SEM-I compliant
;;; interface.
;;;


;;;
;;; the correspondence between grammar-internal types and the one-letter codes
;;; encoding value types on MRS variables: the type mapping, conceptually, is
;;; applied parallel to the property mapping, i.e. context conditions in rules
;;; below should be cast in the appropriate name space.
;;;
event              <> e
ref-ind            <> x
do-index           <> x
overt_non_expl-ind <> x
nonconj_overt-ind  <> x
conj_non_expl-ind  <> x
full_non_expl      <> x
individual         <> i
handle             <> h
;;
;; _fix_me_
;; in creating an MRS from a parse result, the ERG deliberately makes the top
;; handle unbound, i.e. always makes the MRS read-out generate a new variable;
;; the code hard-wires the variable type to `h' _prior_ to VPM application, so
;; we need to provide an identity mapping for `h'.  personally, i must say, i
;; would prefer either the grammar or the code putting a full-blown =q there,
;; such that ERG MRSs go back to communicating which EP ranked highest during
;; composition.  even if formally equivalent (in terms of scope resolution),
;; that information is needed at times, e.g. in transfer.      (22-jan-09; oe)
;;
h              <> h
non_event      <> p
*              >> u
semarg         << u


;;;
;;; from here on, sets of rules that map one or more properties into one or
;;; more properties: for each correspondence, values are compared to sub-rules
;;; in order, until the first match: at that point, output values are inserted
;;; into the result set of properties.  processing of rules continues against
;;; the original properties, so that there could be multiple matches: the `PN'
;;; to `PERS' and `NUM' decomposition, thus, could also be done in two separate
;;; rule sets.  at the end of the day, however, only properties resulting from
;;; successful matches will be in the output, i.e. everything not explicitly
;;; carried over will be deleted.
;;;

PNG.PN : PERS NUM
  1s <> 1 sg
  1p <> 1 pl
  1  <> 1 !
  1  << 1 *
  2s <> 2 sg
  2p <> 2 pl
  2  <> 2 !
  2  << 2 *
  3s <> 3 sg
  3p <> 3 pl
  3  <> 3 !
  3  << 3 *
  *    >> ! !
  !    << * *

PNG.GEN : GEND
  masc    <> m
  fem     <> f
  neut    <> n
  animate <> m-or-f
  *       >> !
  !       << *


;;
;; the lexical property of being individuated, e.g. `road' _and_ `roads' will
;; both be [ IND + ], in contrast to DIV which co-varies with number.  to get
;; us started, this property projects the count vs. mass distinction into the
;; semantics, and dan at least argues that it is truly a semantic distinction.
;; so it might turn out that IND eventually replaces DIV in the interface.
;;                                                             (20-dec-06; oe)
;;
IND : IND
  + <> +
  - <> -
  * >> !
  ! << *

PT : PT
  std  <> std
  zero <> zero
  refl <> refl
  *    >> !
  !    << *


SF : SF
  comm             <> comm
  ques             <> ques
  prop             <> prop
  prop-like        >> prop
  basic-prop       >> prop
  prop-or-like     >> prop
  basic-wh-ques    >> ques
  basic-pol-ques   >> ques
  wh-ques          >> ques
  pol-ques         >> ques
  basic-comm       >> comm
  prop-or-ques     <> prop-or-ques
  prop-or-pol-ques >> prop-or-ques
  *                >> prop
  prop             << *
  prop             << [e]

E.TENSE : TENSE
  nonpresent <> past
  present    <> pres
  future     <> fut
  real_tense <> tensed
  untensed   <> untensed
  *          >> untensed
  untensed   << *
  untensed   << [e]


E.MOOD : MOOD 
  indicative      <> indicative
  subjunctive     <> subjunctive
  *               >> indicative
  indicative      << *
  indicative      << [e]

E.ASPECT.PROGR : PROG
  +       <> +
  -       <> -
  
;;
;; _fix_me_
;; we used to assume that an underspecified PROGR value meant non-progressive.
;; why should that no longer be the case (and, if so, what about PERF)?  even
;; if so, the `bool' and `*' rules could be merged, and what about the reverse
;; direction?                                                  (22-feb-09; oe)
;;
;; DPF 23-feb-09 - Agree that this setting needs more thought.  The motive
;; was to allow underspecified input to still let us generate e.g. "The dog 
;; stopped barking" where 'stop' idiosyncratically does not allow a [PROGR -]
;; VP complement. If the resulting inefficiency is worth this gain, then
;; perhaps PERF should be treated the same, though it would be good to find
;; an example that needs preserving of underspecified PERF.
;; DPF 2015-03-27 - Further on 23-feb-09: If we don't preserve the bool 
;; underspecification on PROG, then we can't generate from |the grumpy cat 
;; arose| if the MRS goes through the SEM-I and sets [PROGR -] on the ARG0
;; of `grumpy', since the generator cannot assign a value to the ARG0..PROGR 
;; of `grumpy' in `grumpy cat': (1) the grammar can't say PROGR - lexically 
;; since we also want |the cat is being grumpy| and (2) we can't say PROGR - 
;; on the adj_n rule since we use the same rule for |sleeping cat| where the 
;; value for `sleeping' is PROGR +.  
;;
  bool    <> bool
  *       >> -
  -       << *
  -       << [e]

E.ASPECT.PRF : PERF
  +       <> +
  -       <> -
  *       >> -
  -       << *
  -       << [e]
  
;; when we want to generate standard english sentences from Singlish ones, 
;; these three aspects will have to be gone in the generation.
;; put the line "  *       >> !" on the top row of each.
;; otherwise to generate Singlish, put * >> - on the third row
; for Singlish
E.ASPECT.INCHO : INCHO
  *       >> !
  +       <> +
  -       <> -
;  *       >> -
  -       << *
  -       << [e]

; for Singlish
E.ASPECT.EXP : EXPER
  *       >> !
  +       <> +
  -       <> -
;  *       >> -
  -       << *
  -       << [e]

; for Singlish
E.ASPECT.INCEP : INCEP
  *       >> !
  +       <> +
  -       <> -
;  *       >> -  
  -       << *
  -       << [e]