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).

Algorithm:

let PT a parent node in the derivation tree for transfer let ST a son node of PT
let DER the actual derivation tree

• if ST is combined to PT by substitution, the subtree PT+ST has to be exactly present in DER
• if ST is combined to PT by adjunction, at a node N, we will say that the pattern is present in DER if :
  • either ST is adjoined to PT at the same node (exact subtree)
  • or ST is adjoined at the root node of an other tree that is adjoined at the rigth node in PT (recursively)

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 useful ?

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:

<general-entry> ::=

<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:

• :lex
  • from a lexical transfer definition
• :tree
  • from a tree pair in a family definition
  • from a tree transfer definition
• :global
  • from a global transfer definition
• :derivation
  • from the description of sons in a derivation tree

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.