Instead of looking for an exact match, as in the current implementation, we could allow the presence of other adjunctions (this could be useful with the current derivation paradigm, when only one adjunction can be made at one node).
let PT a parent node in the derivation tree for transfer
let ST a son node of PT
let DER the actual derivation tree
The same process is relevant to generation. If a complex structure is specified, and the link between two trees is adjunction, it is always possible to have other adjunction between the two, as long as the adjunctions are in the pattern described above.
Note: it seems quite complex to implement this, and is it really
Parent and son combination
While trying to combine a parent an a son derivations, sometimes no
possible combination can be found: there is no node in the target
derivation where the son could be attached. This can occur with the
current derivation paradigm (no two sons attached at the same node). A
root adjoined son in the source tree may be in fact a modifier of the
grand parent and not of its parent. In that case, it could be relevant
to try to attach the corresponding target node to the target grand
parent, as no possible attachment is found in the target parent.
General fsa for a lexical entry
Many of the above fsa do a similar work, and could be grouped in a single parameterized fsa:
<lex entry> <tree name> <features> <tree id> <address> <derivation>
The fsa allows free order between tree-id and address. It can be used in different contexts:
The fields allowed depend on the context where the fsa is used (yes: the field must appear, no: the field must not appear, opt: the field is optional, may or may not appear)
lex tree feature id address derivation
:lex yes opt opt no no no :tree no yes opt no no opt :global yes yes opt no no opt :derivation yes yes opt opt opt opt
The feature transfer in the current implementation is only defined between head nodes of corresponding trees. In some cases (examples to be found), it could be useful to allow feature transfer between arbitrary nodes in trees.
One idea to implement this, could be by defining node pairs for feature transfer (this is already allowed by the formalism) and defining different types of feature transfer (the only types defined now are head category pairs) to specify the feature transfer that has to be done at the given node pair.
Note that this kind of feature transfer should specify not only the
node pairs, but also the top/bottom position for transfer. In the
current paradigm for feature transfer, I have implicitly decided that
the feature transfer occurs between bottom features of heads.
Generation of new trees in the target derivation
In the actual transfer module, when a tree in the source derivation has no correspondent in the target derivation, the transfer is considered as valid. If we want to be totally correct (complete reversal of the transfer process), the reverse operation should be allowed, ie generating a new tree in the target derivation.
The question is which trees should be generated this way. I can imagine two different answers.
The first one is the generation of initial trees to fill some substitution nodes left empty by the transfer process (for example determiners, relative pronouns in the examples I use with the current data).
The second is the generation of auxiliary trees at some nodes in the derived tree. This can be useful to remove a feature clash, ie build a valid derivation tree simply by adding a new tree at the right place. But the problem that a rises when adding this kind of process is how to direct the new adjunctions with the source data, as it is probably true that many invalid trees could be made valid by adding the appropriate adjunction at the appropriate place.
A processing of this kind could be useful to simplify the transfer process, but I think it relies essentially on appropriate feature information to strictly constrain this generation.
An example is the transfer of negation. In the current implementation, the negation transfer is based on relevant tree transfers, which can be very numerous to take into account all possible configuration. An alternative way of transferring negation could be to transfer the relevant feature at relevant places, and using this feature to generate the appropriate tree in a given configuration.
It could be an elegant way of transferring this kind of information,
but this means to rely more on features, and have the grammars
designed with this purpose in mind.
Transfer and Bidirectionality
I think that it could be useful to include some notion of directionality in the transfer process.
For example let's suppose an idiom in language 1 is translated into a non idiomatic expression in language 2:
"manger ses mots" ==> "to speak unclearly"
The question is for the reverse transfer:
"to speak unclearly" ==> "manger ses mots " ??? or "ne pas parler clairement"
From English to French, the non-idiomatic translation seem better than the idiomatic one, which can be used only in certain contexts.
This page is a modified version of the original written by Gilles Prigent (email@example.com). The page is currently maintained by Anoop Sarkar (firstname.lastname@example.org).