LogonVpm

Variable Property Mapping

In the MRSs derived by grammars like the ERG, a fair amount of information is encoded as variable (or index) properties, i.e. attributes and values associated to semantic variables. TENSE, MOOD, and NUM(ber) are typical such properties, and often they facilitate an encoding of information that remains relatively close to morpho-syntactic, grammar-internal distinctions. For the external interface to each grammar, it seems desirable to aim for a unified, yet simple inventory of properties and values, shared across grammars (to the extent of actually being relevant for a token language). At the same time, a grammar may have internal constraints on the organization of morpho-syntactic information, and often there may be distinctions made in a grammar that need not be projected into the external, semantic interface. The Variable Property Mapping facility is a bi-directional tool that relates grammar-internal and -external encoding on the basis of a declarative specification of the mapping relations.

A Simple Example

Consider a grammar which records information about person and number in a single sortal hierarchy, with values like 1sg, 2per, et al. The grammar makes use of a feature PN as the home for the combined person and number values, and for grammar-internal reasons, PN is embedded below a feature PN inside of the feature structures that correspond to semantic variables in the MRS (keep in mind that MRSs are not feature structures, yet for each grammar there is a known bijection between the AVM and the MRS universes). Following is a mapping to convert the grammar-internal, conflated encoding of person and number into an external representation that is compatible to the MRS best practice in LOGON and the RMRS TDT.

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

The above example defines a set of rules that map one (or more) properties into one or more properties. When reading an MRS off the AVM produced by the grammar, for each correspondence of (groups of) properties, 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 subsequent rules continues against the original properties, so that there could be multiple matches: the PNG.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 included in the output MRS, i.e. everything not explicitly carried over will be suppressed.

VPMs can be applied in two directions: forward application, mapping from the left-hand side of rules into the right-hand side, and backward application, producing the inverse mapping. While the prototypical mapping rule is bi-directional, there may be special cases. the VPM machinery provides the following operators:

• <> defines an equivalence mapping, i.e. operates in either direction >> provides a forward-only mapping, i.e. in left to right direction << provides a backward-only mapping, i.e. in right to left direction

By default, values are compared by subsumption (against the type hierarchy of the grammar, for the time being). There are variants of the mapping operators that use equality for testing instead. These are ==, =>, and <=, respectively.

Furthermore, there are a few special operators for matching and outputting of values. In a nutshell, * will match any (existing) value in the input or insert whatever was matched into the output; conversely, ! will not insert the corresponding property into the output, e.g. the sub-rule from our example above

  1per <> 1 !

will have the effect of only inserting [PERS 1] into the output, while the NUM property will be omitted. When applied in backward direction, ! can be used to match absence of the corresponding property, but this usage is really only useful in conjunction with additional properties: without conditioning on another property, a rule matching on the absense of a value would insert the output property on variables of all types. A potentially more useful matching operator that facilitates the insertion of default values conditions a rule on the type of the embedding variable. The ERG, for example, includes the following mapping of TENSE values:

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

Here the effect of the last two sub-rules, which are limited to the backward direction, is to (a) convert all values not matched by earlier rules into untensed and (b) insert untensed on all variables of type e that have no TENSE property already. In other words, the [e] match operator subsumes the use of ! but additionally conditions on a specific variable type, so as to avoid inserting TENSE values into referential indices, say.

A grammar can include any number of VPMs; the function mt:read-vpm() can be used in the LKB `script' file to load a VPM and associate an identifier to it, e.g.

  (mt:read-vpm (lkb-pathname (parent-directory) "semi.vpm") :semi)

The distinguished identifier :semi will activate its VPM for the read-out of MRSs from parsing results (where the VPM is applied in forward direction) and, conversely, for the reverse mapping of MRSs given as input to the generator. Additional VPMs can be put to use in transfer, as an input or output filter for example.

ToDo