This page describes the transfer rule formalism used for, among other things, machine translation, paraphrasing, and (pre-processing in) generation. This page presents user-supplied information, hence may be inaccurate in some details, or not necessarily reflect use patterns anticipated by the original LOGON developers. The functionality documented here may still change. This page was initiated by FrancisBond; please feel free to make additions or corrections as you see fit. However, before revising this page, one should be reasonably confident of the information given being correct.
A little more information is available as an unfinished draft technical report: Oepen (2008) The Transfer Formalism: General-Purpose MRS Rewriting, LOGON Technical Report # 2007-11.
Table of Contents
- Table of Contents
- Basic Structure
- An example transfer rule (from JaEn)
- Trouble Shooting
- Loading the rules
- Setting up an MT system
- Other uses
A transfer rule is a quadruple <F, C, I, O>, where each element is a partial MRS, with:
- F: an input filter; when F matches against the input MRS, the rule is
blocked; F is evaluated after C and I have matched;
- C: the input context; needs to match for a rule to apply and binds
- variables, but is preserved in the output;
- I: the input description; matches against the input MRS; everything that
was matched in the input will be replaced by the output part O;
- O: the output description; everything in the output part is inserted
- into the MRS, respecting variable bindings that have been established in matching earlier components.
There is also a mysterious fifth element FLAGS, which has several subtypes (OPTIONAL, EQUAL, SUBSUME, BLOCK).
- - EQUAL: takes a list of identifiers and forces an equality comparison instead of a subsumption
- test wherever they appear in the rule.
- the MT system will fork creating an instance where the rule applied and another where it didn't.
- transfer process.
An example transfer rule (from JaEn)
This takes an input ep with a predicate of "_inu_n_rel" (犬) and transfers it to one with a predicate of "_dog_n_1_rel" (dog), preserving the values of the LBL and ARG0.
inu_n := noun_mtr & [ INPUT.RELS < [ PRED "_inu_n_rel" ] >, OUTPUT.RELS < [ PRED "_dog_n_1_rel" ] > ].
which is a subtype of:
noun_mtr := monotonic_mtr & [ INPUT.RELS < [ LBL #h1, ARG0 #x1 ] >, OUTPUT.RELS < [ LBL #h1, ARG0 #x1 ] > ].
You can use regular expressions in predicate names, by starting them with a tilde ~. They cannot be used with variables. Regular expressions are commonly used in the C element, both for transfer and generation.
Here is an example of a pair of rules to switch the arguments of prepositions. The first rule identifies prepositions using a regular expression ~_p_ and marks them with a special, transfer-internal predicate. The second rule removes the special predicate, and reverses the arguments.
prep_mark_jf := monotonic_mtr & [ CONTEXT.RELS < [ PRED "~_p_", LBL #h0, ARG0 #e1 & e ] >, FILTER.RELS < [ PRED "prep_swap_mark", LBL #h0, ARG0 #e1 ] >, OUTPUT.RELS < [ PRED "prep_swap_mark", LBL #h0, ARG0 #e1 ] >, FLAGS.EQUAL < #e1 > ]. prep_swap_jf := monotonic_mtr & [ INPUT.RELS < [ LBL #h1, PRED #pred, ARG0 #e1, ARG1 #1, ARG2 #2 ], [ PRED "prep_swap_mark", LBL #h1, ARG0 #e1 ] >, OUTPUT.RELS < [ LBL #h1, PRED #pred, ARG0 #e1, ARG1 #2, ARG2 #1 ] > ].
A filter makes sure no special predicates remain:
mark_ditch_cf := elision_mtr & [ INPUT.RELS < [ PRED "~_mark$" ] > ].
Optional rules cause the transfer to fork. This produces one branch where the rule applied, and one where it didn't.
They are conventionally written as name_omtr and are defined as follows:
optional_mtr := mrs_transfer_rule & [ FLAGS.OPTIONAL + ].
The last rule in a set of transfer rules should be terminated. That is, the last rule for a word's translation should be a non-optional MTR. If this isn't done, then many spurious transfer outputs will be produced.
hoeru_v_1-bark_v_1_omtr := arg1_v_omtr & [ INPUT.RELS < [ PRED "_hoeru_v_1_rel" ] >, OUTPUT.RELS < [ PRED "_bark_v_1_rel" ] > ]. hoeru_v_1-roar_v_1_mtr := arg1_v_mtr & [ INPUT.RELS < [ PRED "_hoeru_v_1_rel" ] >, OUTPUT.RELS < [ PRED "_roar_v_1_rel" ] > ].
In MT, if you choose predicate names and definitions wisely, you can transfer some things without the need for rules. To do this, you list the predicates in *transfer-interlingua-predicates*.
(defparameter *transfer-interlingua-predicates* '(lkb::named_rel lkb::proposition_m_rel))
When you are transferring and then generating and get a message like this:
[10:59:24] translate(): read 1 MRS as generator input. [10:59:24] translate(): processing MRS # 0 (4 EPs). [10:59:24] translate(): error `Problem in create-liszt-fs-from-rels'.
The most likely cause is types in the MRS being read that aren't in the feature structure of the grammar used to generate. You need to transfer them or delete them using the VPM.
To ensure something is a noun
Check that its in the scope of a quantifier.
[ CONTEXT.HCONS < qeq & [ LARG #h0 ] >, INPUT.RELS < [ PRED #pred, LBL #h0, ARG0 #x1 & x & [ NUM pl ] ], [ PRED mass_noun_mark, LBL #h0, ARG0 #x1 ] > ]
Limit the effort in transfer
(setf mt::*transfer-edge-limit* 1000)
Loading the rules
Rules are loaded using mt:read-transfer-rules. For example, from JaEn:
(mt:read-transfer-rules (list (lkb-pathname (parent-directory) "snug.mtr") (lkb-pathname (grandparent-directory) "erg.mtr") (lkb-pathname (parent-directory) "erg.mtr") (lkb-pathname (grandparent-directory) "finale.mtr")) "TL accomodation phase" :out :out :post :erg :filter nil :after "postprocess")
- If at the start of transfer, for rule sets that were loaded with `:filter t', all input predicates are compared (as strings) against the `dictionary' of known INPUT predicates in that rule set. that test, currently, does not take into account regular expressions (though it probably should).
- This calls a function as a pre-process before the transfer takes place.
- This calls a function as a post-process after the transfer takes place.
no documentation here, move along
no documentation here, move along
Setting up an MT system
See MtSetup for instructions on how to set up an MT system.
Transfer rules are used in several other places.
Clean Up (post parsing)
An MTR file defining transfer rules to massage MRSes read off of TFSes. It must be
- ambiguity-free, i.e. must not contain optional rules.
cleanup-rules := "../cleanup.mtr".
Fix Up (pre-generation)
An optional transfer grammar invoked to massage MRSes generator inputs prior to lexical lookup. It must be
ambiguity-free, i.e. must not contain optional rules. See LkbGeneration for more on generation.
generation-fixup-rules := "../gen-fixup.mtr".
Trigger Rules (for generation)
Used to add lexical entries with empty semantics to the generator chart. See Trigger Rules for details.
MTR file defining idiom-checking rules for parsing (see IdiomTop).
These rules only license idioms, they do not have output.
Only supported by the LKB, not ACE (2017-03-15).
(list (lkb-pathname (parent-directory) "paraphraser.mtr") ) "Paraphraser" :filter nil :task :paraphrase)
Activated by the rephrase menu on the LKB: these rules allow simple paraphrasing (and can include optional rules). (See RmrsParaphrasing)