Merge branch 'olzama-dev' into main

semi.vpm

@@ -0,0 +1,178 @@
+;;; -*- 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]
+
+;; DPF 2020-12-17 - Only used in mal-variant of the ERG
+;;
+SEMPOS : SEMPOS
+  adjrel             <> adjrel
+  advrel             <> advrel