\section{Transfer Rules and Training} 
 
Other transfer engines may have separate rules for analysis, transfer, 
and generation.  Due to the training constraints, this system combines 
all such information into a single rule, but uses it in several 
stages.  The transfer rules formalism must be simple enough to be 
learned by an automatic process, but also powerful enough to allow 
manual rule additions and changes to improve the automatically learned 
rules. 
 
\subsection{Training Overview} 
 
The transfer rule formalism is influenced by the rule training 
process.  The first resource required for training is a bilingual 
corpus of specially selected sentences.  The source (or elicitation) 
language sentences, written in a language such as Spanish or English, 
are specially selected to exhibit a variety of possible linguistic and 
syntactic phenomenon.  Using a specially designed elicitation tool, 
one or more native informants who may or may not have linguistic 
training translate each sentence into their own language and then 
indicate alignments between each of the words of the sentence pairs, 
if any alignments exist. 
 
Also necessary is a parser for the elicitation sentences, an example 
being LCFlex for English \cite{rose2001}.  The training process uses 
the parser's output and the word alignments to produce seed rules, 
which are then generalized or made more specific depending on the 
accuracy of the translations they produce. 
 
\subsection{Transfer Rules} 
 
These transfer rules embody all three stages of translation: analysis, 
transfer and generation.  All rules have a unique identifier, usually 
a constituent name plus an index into all rules with that constituent 
name.  Following that are the production rules for the source and 
target sides, with the source production rule used in analysis and the 
target in transfer.  In the body of the rule are constituent 
alignments, indicating the reordering (if any) necessary for source 
(also referred to as the X-side) constituents to be transfered to the 
target side (also referred to as the Y-side).  Figure \ref{rule1} 
shows an example transfer rule. 
 
Following the constituent alignments are a set of feature unification 
equations.  Unification equations can be included for the analysis 
stage and the combined transfer and generation stage.  Features may be 
unified up the constituent hierarchy, from the source side across to 
the target side, and distributed down the target side.  Transfer is 
done from top to bottom. 
 
\begin{figure}[t] 
\begin{verbatim} 
{S,1} ; Unique identifier 
S::S : [NP VP] -> [NP VP]  
; Source and target production rules 
( 
  ; Constituent alignments 
  (X1::Y1) 
  (X2::Y2) 
 
  ; Analysis unification equations 
  ; (x-side constraints)
  ((x0 subj) == x1) 
  (x0 = x2) 
 
  ; Transfer Equations 
  ; (xy-constraints)
  (y0 = x0) 
 
  ; Generation equations 
  ; (y-side constraints)
  (y1 == (y0 subj)) 
  (y2 = y0)      
) 
\end{verbatim} 
\caption{\label{rule1}  Sample Transfer Rule} 
\end{figure} 
 
 
\section{Transfer Algorithm} 
\subsection{Analysis} 
Analysis is the first stage of the translation process.  During 
parsing, each word is looked up in the transfer lexicon and, if not 
found, run through a morphological analysis which returns a word stem 
and feature structure for the word.  The stem is then looked up in the 
transfer lexicon.  The eventual goal is for this morphological 
analysis itself to be automatically learned also.  After lexical 
analysis, the parsing is done with a pseudo-unification chart parser 
with ambiguity packing.  In addition to packing normal syntactic 
ambiguities in the structure of the source sentence, the parser can 
also pack two rules where the parse would be identical but the 
transfer to the target language different. 
 
The constituent that the source text should parse to can be set to any 
value, meaning that the transfer engine can be used to translate whole 
sentences or just phrases such as noun or verb phrases.  Initial 
system testing will be on noun phrases.  The end result of the 
analysis is this ambiguity packed chart of constituents, along with a 
set of arcs detailing how the constituents relate to each other and 
the rules from which they were derived. 
 
\subsection{Transfer and Generation} 
Transfer involves a walk through the chart of arcs and constituents 
created during parsing.  Transfer and generation are done side by 
side, reflecting the fact that a separate generation grammar is not 
available.  Starting at the top constituent for the source parse the 
transfer and generation unification equations are run, creating target 
language constituents.  Features are moved from the source to the 
target side and then moved down among target constituents, as governed 
by the equations. 
 
Following the transfer and distribution of features, the engine then 
continues its walk down the parse tree, but in an order determined by 
the x and y side alignments listed in the rule.  For example, if the 
sentence subject came last in English but first in another language, 
this would be reflected in the constituent alignments.  The object 
constituent would consequently be explored and transfered next, with 
the subject and verb coming after.  If at any time any of the 
unification rules fails, the walk is halted and the system updates 
what paths have been explored so far.  The system then tries a 
different path through the chart.  This continues down to the lexical 
level until a complete target tree has been created. 
 
Transfer at the lexical level is also done with feature unification. 
Features passed down to the lexical level are checked against the 
unification equations of rules whose source side match the source word 
or word stem.  If unification is successful the corresponding target 
word is inserted into the target structure along with any target side 
feature structure included in the rule.  Figure \ref{lexrules} shows 
two lexical transfer rules where one Chinese word is translated in two 
different ways.  During parsing, the Chinese word (represented by its 
pinyin pronunciation ``wo3'') would be tagged as having nominative or accusative 
case.  This case feature would then be passed down during transfer and 
generation until it reached the lexical level.  At that point the 
translation with the appropriate case would be selected. 
 
\begin{figure}[t] 
\begin{verbatim} 
N::N |: [wo3] -> [I] 
( 
(x1::y1) 
((x0 form) = wo3) 
((x0 py) = wo3) 
 
((y0 case) = nom) 
((y0 agr) = 1sg) 
) 
 
N::N |: [wo3] -> [me] 
( 
(x1::y1) 
((x0 form) = wo3) 
 
((y0 case) = acc) 
 
) 
\end{verbatim} 
\caption{\label{lexrules} Sample lexical rules } 
\end{figure} 
 
\subsection{Constraint Checking} 
Once this transfer walk has found a possible target tree, two more 
phases are needed.  In many cases, the target language will enforce 
constraints that are not found in the source language.  One such 
example happens when translating Chinese to English.  Chinese does not 
have agreement between the subject and the verb of a sentence.  The 
verb remains the same for all subjects.  However, in English subject 
verb agreement must be enforced.  Since the transfer pass goes from 
the top constituent down to the lexical level and not the other way 
around, the necessary agreement information is not available until the 
target word translations have been selected.  An example of this is in 
Figure \ref{constraintlex} where the information needed to check the 
constraint higher up the target structure is only available in these 
lexical rules.  In order to resolve that problem, before 
inter-constituent constraints are checked on the target side, a 
``feature filling'' pass is added.  This pass runs equations that can 
pass feature values from lexical nodes up the generated target tree. 
One this pass is complete, the constraint checking pass is then run, 
guaranteeing that all the information the constraint checking needs 
will be available. 
 
\begin{figure} 
\begin{verbatim} 
V::V |: [chi1] -> [eat] 
( 
(x1::y1) 
((x0 form) = chi1) 
 
((y0 tense) = pres) 
((y0 agr) = (*not* 3sg)) 
) 
 
V::V |: [chi1] -> [eats] 
( 
(x1::y1) 
((x0 form) = chi1) 
 
((y0 tense) = pres) 
((y0 agr) = 3sg) 
) 
\end{verbatim} 
\caption{\label{constraintlex} Sample lexical rules used in constraint checking} 
\end{figure} 
 
A rule can also insert a target constituent that is not aligned with a 
source constituent.  Currently only lexical-level constituents may be 
added.  This insertion is done when the system detects a target side 
constituent that has no corresponding source constituent.  The 
unification equations for the rule may add in feature value pairs to 
be stored in the constituent.  During lexical transfer, lexical 
transfer entries for matching that constituent type are searched and 
their unification rules run against the features already inserted by 
the previous rule.  The target word from the first lexical transfer 
entry that matches is then used as the value of the inserted word. 
 
If all phases have completed successfully, the lexical leaves of the 
target tree are read in a depth-first search, concatenated into a 
string and returned.  The system can either stop at the first 
translation found or continue to find all translations allowed by the 
translation rules.  The system also returns the feature structure for 
the target sentence along with the feature structures for each 
individual translated word. 
 
\begin{figure}[h] 
\begin{verbatim} 
{S,2} 
S::S : [NP VP] -> [NP VP] 
( ; Alignments 
  (x1::y1) ; NP goes with NP 
  (x2::y2) ; VP goes with VP 
  ; Analysis 
  ((x0 subj) == x1) 
  ((x0 subj case) = nom) 
  (x0 = x2) 
 
  ; Transfer 
  (y0 = x0) 
 
  ; Generation 
  (y1 == (y0 subj)) 
  (y2 = y0) 
  ; Feature passing 
  ((y0 agr) = (y2 agr)) 
  ; Constrain checking 
  ((y1 agr) = (y2 agr)) 
) 
\end{verbatim} 
\caption{\label{rule2}  Sample Transfer Rule Showing Constraint Checking} 
\end{figure} 
 
 
\section{Training Adaptations} 
 
Several specific functions needed to be added for the transfer engine 
to incorporated into the training process.  First of these was a way 
to add rules dynamically to the system.  Also needed were ways of 
turning rules off for a run of the system.  Another unique feature was 
the ability to turn off all rules but one for a specific type of 
constituent.  In this way it could be seen if how that particular rule 
affected the translation outcome, and if it could be replaced with a 
more general rule that could handle a broader range of similar 
structures or needed to be replaced with a more specific rule. 
 
The system also had to be able to return detailed information about 
the results of the translation.  Since an important part of the 
training involves word-aligned phrases or sentences, it was necessary 
to be able to return the resulting feature structure for each 
translated word, to see what features were eventually passed down to 
the lexical level.  The final feature structure for the translated 
sentence as a whole also needed to be stored and returned. 
 
\section{Future Work} 
 
To date the system has only been tested by manually writing a small 
set of rules for translating Chinese to English, but the transfer 
engine and rule learning program should be fully integrated soon, 
allowing for the creation and testing of the automatically learned 
rules.  It is expected the integration process will uncover more 
necessary changes to the transfer engine for training.  \textbf{this is done, and it works! :)}
 
Currently the system tries transfer rules in the order in which they 
are loaded into the system.  Consequently, it is best to put more 
specific rules first to be followed by more general rules that could 
act as defaults if none of the others succeed.  In the future it would 
be useful to find more ways of more effectively choosing which rules 
to apply earlier on in order to avoid needless backtracking and to 
produce better translations first.  Perhaps some time of limited 
language modeling would help. 
 
The system also currently can only deal with input that can be 
completely parsed, failing if a needed word is missing or the input is 
ungrammatical is \textbf{in} another way.  Work needs to be done for the transfer 
engine to find ``best case'' \textbf{`best case'} translations of the input, perhaps 
piecing together multiple contiguous constituents in the text.  Even 
if the system were only able to identify and translate certain types 
of phrases in the input, such as noun phrases, this might still be a 
useful contribution to a multi-engine MT system. 

\textbf{well, it's too long like all our sections.  I would suggest that we can have a `global' future work section, as I included in the main file, but that would mean that we say less about each module's future improvements.  What do you think?}