Feature Matching

In the previous subsections we have considered only the aspects of a metarule involving the structural part of the XTAG trees. In a feature based grammar such as XTAG, accounting for features is essential. A metarule must account for the proper change of feature equations^27.8 from the input to the output tree. The aspects that have to be considered here are:

• Which feature equations should be required to be present in inp in order for the match to succeed.
• Which feature equations should be generated in the output tree as a function of the feature equations in the input tree.

Based on the combinations of these aspects the user may specify for a feature equation to be considered in the following ways:

• Require & Retain: The feature equation is required to be in inp in order for matching to succeed. Upon matching, the equation will be copied to the output tree. To achieve this behaviour, the equation must be placed in the lhs tree of the metarule preceded by a plus character (e.g. +V.t:<trans>=+).^27.9
• Require & Don't Copy: The equation is required to be in inp for matching, but should not be copied to the output tree. To have this behavior, the equation must be in lhs preceded by the minus character (e.g. -NP₁:<case>=acc).
• Negative Requirement: In order for matching to succeed the equation should not be found in inp. This is achieved by including the equation in lhs preceded by a caret (e.g., <tex2html_verb_mark>1<tex2html_verb_mark>V.b:<passive>=-).
• Optional & Don't Copy: The equation is not required for matching, but we have to make sure not to copy it to the output tree set of equations, regardless of it being present or not in inp. Those equations must be in lhs in raw form, i.e., neither preceded by a plus nor minus character (e.g. S_r.b:<perfect>=VP.t:<perfect>).
• Optional & Retain: The equation is not required for matching, but in case it is found in inp it must be copied to the output tree. This is the default case, and hence these equations should not be present in the metarule specification.
• Add: The equation is not required for matching but we want it to be put in the output tree anyway. These equations are placed in raw form in the rhs (notice in this case it is the right hand side tree).

There are also some directives available to handle feature equations. For convenience and conformance with the pre-existing interface functions, these directives were defined to be included in the lhs tree as feature equations among the equations for requirement/copy defined above. The equations/directives will be interpreted and executed in the order they appear in the feature equations list definition of the lhs tree. The general format of a directive is:

Dname1 dummy1 name2

where ``D'' is a single character that specifies the directive, as listed below; name1 and name2 are parameters of the directive; and dummy1 (which may literally be the word ``dummy'') is required only to conform to the pre-existing format for feature equations in XTAG. There must be no blank space between the directive symbol and name1. The currently implemented directives are:

replace name1 with name2 in all equations from the input tree.

|:

exchange name1 and name2 in all equations from the input tree.

!:

remove all equations where name1 appears (here, name2 is also dummy).

Notice that the equations are executed in order. Hence, for instance, if there is a directive to remove equation E before an equation that requires E to be present for matching, matching will always fail. Similarly replacing and exchanging feature names will affect and be affected by the behavior of surrounding equations. In the rest of this subsection we define the role of the meta-variables in the feature equations. Importantly, we will overload the notation used up til now in this chapter and use the terms ``left'' and ``right hand side'' (lhs and rhs for short) to refer to the sides of a feature equation from a tree, and not only to the sides of the metarule. Non-typed variables don't play any role in the manipulation of feature equations by the metarules. Typed variables can be used in feature equations in both lhs and rhs side of the equation. They are intended to represent the nodes of the input tree with which the variables have been instantiated. For each resulting match from the structural matching process the following is done:

• The (typed) variables in the equations at lhs and rhs are substituted by the names of the nodes they have been instantiated to.
• The requirements concerning feature equations are checked, according to the above rules.
• If the match survives feature equation checking, the proper output tree is generated, according to Section C.2.3 and to the rules described above for the feature equations.

Finally, a new kind of metavariable, which is not used at the nodes, can be introduced in the feature equations part. It has the same form of the non-typed variables, i.e., a question mark followed by a number, and is used in place of feature values and feature names. Hence, if the equation NP_r.b:<?2> = ?3 appears in lhs, then all feature equations of inp that equate a certain bottom attribute(?2) of node NP_r to a certain feature value (?3) (but not to a feature path) will not be copied to the output. Notice that before the first time the variables ?2 and ?3 match an equation from inp, they are free and can match any feature value/name. But after a match occurs, they become bound to the matched values, and henceforth they will only match these values.