File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/88/c88-1042_metho.xml
Size: 30,910 bytes
Last Modified: 2025-10-06 14:12:05
<?xml version="1.0" standalone="yes"?> <Paper uid="C88-1042"> <Title>If (CN has Ancestor ( A ((CAT QUES)) has First Son F ((CAT NP PRON)(WH l)))) Then < If (F ((P +))) Then < Return(True);> Else < Return(False); > ; > ; @ Who is competent? @ Who does John expect to seem old? @ What does John expect to seem old? If (CN has Ancestor B((CAT INFCL</Title> <Section position="3" start_page="205" end_page="207" type="metho"> <SectionTitle> Start RETURN VERB </SectionTitle> <Paragraph position="0"> 1 If (call OBJECT) Then < Put (HEB &quot;&quot;l~tl'l,&quot;l&quot; );end;> ; @ Example: Ron returned the book.</Paragraph> <Paragraph position="1"> @ Example: The book was returned.</Paragraph> <Paragraph position="2"> 2 Put (ItEB &quot;'tin&quot; ); @ (this is the default translation) @ Example: Ron returned early.</Paragraph> <Section position="1" start_page="205" end_page="207" type="sub_section"> <SectionTitle> Finish </SectionTitle> <Paragraph position="0"> Ideally, the feature OBJECT could be defined as part of the information provided by the parser. However, if for some reason the parser does not identify such relations, it can be defined as a function, written in the lexicon specification language described in this paper, which will evaluate the parse tree during Transfer. An example of such a function, which is included as a utility function in the active bilingual lexicon system, is given in \[Golan 88\], an extended version of this paper. This function tests a tree for the presence of a constituent which is the direct object of a given verb. If the verb appears in the passive voice, it assumes existence of a direct object (note that the active voice is selected for the ltebrew equivalent even in the passive case; passivization is done later in Generation).</Paragraph> <Paragraph position="1"> It may be necessary to define functions which identify more complex grammatical relations than the direct object of a given verb. It is, for example, necessary to refer to the relation 'head noun argument, with property P, of an adjective', when formulating the rule for an adjective like &quot;available&quot;: The algorithm N-of-AD.I, given in detail in section 6 below, characterizes a parameterized function which identifies the head noun argument, with property P, of a given adjective.</Paragraph> <Paragraph position="2"> This algorithm is written in the lexicon specification language and is also included as a utility function in the lexicon system. Rules which employ this function can render the translation of an adjective dependent upon the modified noun phrase having specific attributes. It should also be noted that the function N-of-ADJ identifies the noun when the adjective acts as a pronominal modifier as well as when it appears in the VP predicative form.</Paragraph> <Paragraph position="3"> It is important to recognize that functions of this kind are useful to the extent that they can be employed in a significant number of lexical rules. There are, however, many cases in which the translation rules must be formulated directly as search procedures on trees. There are no obvious general grammatical functions which can be used to define the syntactic relations that must be tested in order to determine translation in these cases. Consider, for example, the set of rules for the adverb &quot;precisely&quot;: The disjunctive relation of being the descendent of either an NP or a PP does not seem to be the sort of grammatical relation which one would wish to encode in a general grammatical function.</Paragraph> <Paragraph position="4"> Similarly, consider the set of rules below, which are part of the definition of the verb &quot;allow&quot;. The case where this verb appears in an active voice and forms part of the verb-particle construction &quot;allow for&quot; are identified by searching the tree for the preposition &quot;for&quot; which may be the head of a possibly non-adjacent PP: 1 If ( CN has First Postbrother (name-l((CAT PP)) @ for the results.</Paragraph> <Paragraph position="5"> In fact, the basic need to look for a nonoadjacent particle is rather common. It may justify inclusion of generalized relations in the lexicon formalism. A generalized notion of &quot;postbrother&quot; will enable the statement of the sense distinction above as one rule. However, the detailed design of such generalized relations is very complex and is not yet included in our model.</Paragraph> <Paragraph position="6"> The &quot;allow for&quot; example presents yet another problem for translation. The Ilebrew translation &quot;llaton3. tlptJ &quot; consists of two words which have individual verb and noun entries in the TL lexicon. If the target translation is a recognized collocation or idiom it can be specified as such in the TL lexicon. But there are cases where an SL entry must be rephrased in the 'FL as an ad-hoc combination of words which does not form a lexical entity. In that case the lexical rule must mark words with corresponding parts of speech, or provide alternative information which will serve later in Generation to properly decide on the required morphological manipulation.</Paragraph> <Paragraph position="7"> Generally, our experiments with actual lexical entries lead us to believe that the most efficient strategy for formulating lexical rutes is to use a combination of general functions and rule-specific search procedures. A formal description of the specification language and a detailed example of its expressive power am given in sections 5 and 6 below.</Paragraph> <Paragraph position="8"> Tire creation of a large scale full-fledged BL lexicon is a very heavy tar;k, impeding development of product level systems.</Paragraph> <Paragraph position="9"> There is no way to avoid it, but there are ways to facilitate the practical development of the lexicon by making the process more modular. The scheme presented in this paper enables the system lexicographers - and each individual user - to proceed in steps. As a first, rough, approximation, one may sinrply define one &quot;default translation&quot;; e.g., for the verb &quot;type&quot;: Start TYPE VERB Put (\[IEB &quot;'o~9&quot;r~&quot; ); Finish This will account for the use of &quot;type&quot; in the sense of &quot;typewrite&quot;. Later, other senses can be defined (e.g. &quot;),ll~ro&quot;, for &quot;classify&quot;), going from the most frequent in a given context to the relatively rare ones, thus achieving an increasingly refined level of sense specification. The optimal level of detail may depend on user needs and on specific text domains. In fact, different sense distinctions may be required for different domains. The user can modify the lexicon accordingly, or define his/her own private addenda lexicon, overriding identical entries in the main lexicon.</Paragraph> <Paragraph position="10"> The lexicon of the system is accessible to revision by users.</Paragraph> <Paragraph position="11"> l-lowevel, users cannot modify the global transformations which map syntactic structures in tile St. into those of the TL, nor can they interfere with morphological aspects of Generation (TL values in the bilingual lexicon are given in a canonical form; e.g. for ttebrew verbs: 3rd person - singular - past tense - active voice). Consequently, user influence is constrained in such a way that it cannot disrupt the functioning of the large scale architecture of the system, but can at most affect loC/al changes of a lexically based nature.</Paragraph> <Paragraph position="12"> This is one obvious advantage of the strict separation between bilingual lexical transfer and general phrase structure transformations. Another benefit of this approach is the restriction of the structures that must be considered for transformations to standard, non-distorted SL phrase structures, as provided by the SL parser. This eliminates complications and loss of generality of the structural transformations. Also, from a software engineering perspective, it is clearly advantageous to keep the two sub-processes independent of each other.</Paragraph> <Paragraph position="13"> llowew~r, the extent to which this separation can be maintained is not evident. In certain cases, e.g. when there is no simple way to preserve tire part of speech in translation, lexicon-driven modifications of the phrase structure could facilitate the process. In such cases, which are fortunately not very common, we will consider attachment of &quot;transformation triggers&quot; to nodes, based on the bilingual lexicon processing. Technically, this can be easily done in our specification forrealism. The lexical phase itself will not make any changes in phrase structure, and only one pass of structural transformations will still be required.</Paragraph> <Paragraph position="14"> Indeed, as \[Melby 86\] points out, the whole issue of lexical transfer and in particular the effect lexical transfer has on the overall quality of translation deserves further study.</Paragraph> <Paragraph position="15"> 3. Sense Distinction Characteristics The highest level of distinction in the bilingual lexicon is the part of speech. Within each part of speech one may distinguish different senses (and specify lexical rules) as required in light of TL sense distinctions. According to one initially plausible view, it is possible to make use of the subcategorization information present in standard monoliugual dictionaries to obtain the necessary syntactic information for disambiguating diftcrent senses of words in the SL. In fact, we have found this view to be untenable. Thus, for example, among the 13 senses that \[l.ongman 78\] distinguishes for the verb &quot;hold&quot;, many are mapped to the ltebrew verb &quot;p~trl,-l&quot;, even when they belong to diffelent syntactic categories as defined in l.ongmans system. On the other hand, consider the different uses of &quot;hold&quot; in the following sample sentences: - She is holding tile baby - We held our breath in fear We were holding a meeting Although l.ongman makes a distinction between the three senses (cases 1,3, and 13, respectively), all of them are classi-tied as TI verbs according to Longman's coding system, which is the only feasible instrument for cornputer reference, h-t l lebrew, different w.qbs nmst be used (&quot;p~tlnW, &quot;'1t1~&quot;, &quot;t3~rF)&quot; , respectively). Moreover, even under the same sense (10), tw~ sample sentences are given, which in ltebrew require differc~lt verbs: What he said still holds (&quot;qprr') - Can the good weather hold'? (&quot;'l~Nr3n &quot;) As a second example of the inadequacy of standard monolingual subcategorization, consider l.ongman's class of T3 verbs .verbs which take infintival complements with &quot;to&quot; and NP objects. E.g.: want Ron to win ask Ron to leave tell Ron to come llowever, each of the corresponding \[lebrew verbs has a dis. tinct subeategorization frame: - &quot;lnSll~ l~l~ n~2tl deg (want that Ron will win) - &quot;:a~tg~ \]Ytt3 ~p:at3&quot; (ask from Ron to leave) - &quot;R~ttt~ lrtt~ lrJlR&quot; (tell to Ron to come) Note that the form -. &quot;a~ty, I13~9 ~par3&quot; (ask that Ron will leave) is also valid ill Ilebrew, but as a translation of &quot;ask that Ron leaves&quot; rather than &quot;ask Ron to leave&quot;. Therefore, Transfel and not Generation seems to us the natural place to decide on the appropriate form.</Paragraph> <Paragraph position="16"> These, examples illustrate the lack of isomorphism between subcategorization patterns for specific verbs in English and their counterparts in Hebrew. It is reasonable to expect that, generally, subcategorization is not invariant under translation between most SL-TL pairs (cf e.g. \[Warwick 87\]). As \[Nagao 86\] points out, &quot;it is not exceptional, but rather usual, that a verb of SL has to be translated into different target lexical items, even though the native speakers of SL cannot clearly realize the meaning difference&quot;. Consequently, we have found it useful to construct algorithms which map lexical items, considering subcategorization properties and sense distinctions of both SL and TL. This is especially useful for verbs, but the same specification formalism is used for all other lexical categories, making use of syntactic information in different ways. We anticipate that the construction of a large scale lexicon will be facilitated by the existence in the SL of subclasses of items, in each lexical category, which have identical or highly similar subcategorization frames, and which correspond to items in the TL with similar frames. The entries for the elements of such subclasses can be handled by algorithms whose statements have more or less the same selection conditions.</Paragraph> <Paragraph position="17"> In constructing the BL lexicon of our system we have followed a lexicalist view of syntax. In particular, our view of the interaction of the syntactic component and the lexicon in Transfer is inspired by the projection principle \[Chomsky 1981\]. This principle states that the syntactic structure of a phrase (at any level of representation) !s a projection of the argument structure imposed by the lexical entry of the head of the phrase. Mapping of a lexical item in the SL onto a counterpart in the TL depends upon a matching of the subcategorization frames of the two items. This matching requires recognition of an SL item in a tree as the head of a sub-phrase which satisfies the argument structure specified by the antecedent conditions of one of the statements in its lexical entry. Translation of any sub-clause begins with its head, as this determines the argument structure of the clause.</Paragraph> <Paragraph position="18"> It is necessary to qualify this characterization of our approach in an important respect. Although our algorithms are stated primarily in terms of the syntactic information provided by the parser, we have found it necessary to supplement this information with a restricted list Of general semantic features. For example, consider the verb &quot;run&quot;. On its intransitive use, it translates into llebrew as &quot;p~&quot;, while its transitive use corresponds to the ttebrew causative verb &quot;~,&quot;1&quot;. llowever, intransitive &quot;run&quot; allows certain NP adverb complements, as in &quot;run a mile&quot;. To identify these NPs as adverbial phrases and so preserve the intransitive sense of &quot;run&quot;, we attach attributes Time or Distance to the entries of nouns like &quot;time&quot; and &quot;mile&quot; in the SL lexicon. The algorithm for &quot;run&quot; can then recognize it as having its intransitive sense when it takes only one complement and the head N of this NP contains one of these attributes. Features such as 1 luman/Non-human, Concrete/Abstract, etc., and a small number of domain specific features (e.g. hardware device, software component, state, etc., for the domain of computer manuals) are also included.</Paragraph> <Paragraph position="19"> There is yet another kind of feature marker that we include in the SL lexicon, and which we call &quot;list marker&quot;. These markers assist disambiguation in cases where a few nouns can be grouped together, usually for computational efficiency, although their common denominator has no obvious name.</Paragraph> <Paragraph position="20"> For example, in the sense distinction for the verb &quot;assume&quot;, if the complement is an NP with a noun in the set \[office, chairmanship, position,...\], then the ttebrew verb-equivalent is different from other sub-cases of &quot;assume&quot;. We give this group of nouns a name and mark the nouns in the group accordingly. Then one can refer to this name as a feature. Indeed, nouns in such groups have semantic similarities, and in principle, they are equivalent to traditional semantic markers. The point is that list markers can be formed in an ad-hoc fashion, without worrying about the generality of the group, or finding an appropriate label for it.</Paragraph> <Paragraph position="21"> The different mechanisms presented above provide, in fact, various levels of characterization of the relation between a given verb and a noun (or an NP) to which it refers: subcategorization requirement for the very existence of a noun (NP) in a given position (e.g. as a direct object); a more constricting requi~ement for the existence of a noun with specified semantic features (defined as such, or by means of lists, in the SL lexicon); and a particular requirement for the existence of a specific noun (or group of nouns).</Paragraph> <Paragraph position="22"> The sense distinction for multi-sense nouns (homonyms and polysemes) and other parts of speech is done according to basically the same strategy which we use for verbs; namely application of context-sensitive differentiating rules. Generally, nouns and adjectives are less ambiguous for translation, but the ambiguity, when it exists, is more difficult to resolve at the sentence level without extensive semantic and pragmatic knowledge. Still, many cases can be resolved by rules of the kind shown above. For example, although nouns, unlike most verbs, do not require complement structures, disambiguation in the source language can sometimes be facilitated by rules which refer to the presence of optional N complements. Consider, for example, the noun &quot;statement&quot;. When it has a 'that' S' complement (&quot;a statement that Rina has been promoted&quot;) it translates to llebrew &quot;~9~ra~ &quot; when it occurs with a PP complement headed by &quot;of&quot; with an NP object headed by an inanimate noun (&quot;statement of the theory&quot;), it translates to &quot;tq~Xg~:l&quot;. When sense distinction cannot be expressed in terms of our system (e.g. for the homonymous noun &quot;bank&quot;), we specify only the more common sense in the given text domain. In the future, we may mark such cases so that the information about the lexical ambiguity can be made available to an interactive disambiguation module.</Paragraph> <Paragraph position="23"> For adjectives, the characterization is done in most cases by reference to semantic features of the noun(s) they modify. In some cases different translations will be required for an adjective when it appears as a prenominal modifier or in the VP predicative form: - My old friend is not old &quot;lpt '0~R ~9~9 p~ln &quot;1:lrlW The syntactic distinction between the two forms of &quot;old&quot;, and the selection of the different \[lebrew equivalents (&quot;IPt&quot;, &quot;p~rn'), are easy to specify in our formalism (cf. the definition of N-of-ADJ in section 6 below).</Paragraph> </Section> </Section> <Section position="4" start_page="207" end_page="208" type="metho"> <SectionTitle> 4. Some Methodological Aspects </SectionTitle> <Paragraph position="0"> From the discussion and examples above, it is apparent that our lexicon specifies bilingual information in great detail. This may seem to conflict with certain modern approaches to Transfer methodology, where the guiding view is &quot;small (and simple) is beautiful&quot;. \[lsabelle 86\], \[Arnold 87\], and others, advocate an approach where the BL lexicon states only facts like: know -> wissen (in German; or &quot;savoir&quot; in French; or &quot;n9~9&quot; in I lebrew, when the verb takes a sentential object) know -> kennen (ill German; or &quot;conaitre&quot; in French; or &quot;'1~3,'19&quot; in t lebrew, when the verb takes a nominal object) The selection of the correct translation is then done in the Generation t/hase, based on restrictions on tile target language. We claim that this approach is problematic for the following reasons.</Paragraph> <Paragraph position="1"> First, the &quot;know&quot; example, although widely quoted in the literature, is rather simplistic. Even in the monolingual subcategorization for &quot;know&quot; in \[Longman 78\], there are 15 different frames, re:my of which require a different verb, or verb-form, use of a preposition, or even a completely different syntactic structure in I lebrew. Ill addition, there are verb-particle and other collocations which would be quite difficult (and unnatural) to handle if decisions were postponed to the monolingual Generation (&quot;know of&quot;, &quot;know better&quot;, &quot;know X to be Y&quot;, are some examples which hold not only for 1 lebrew). It is not single words but patterns and structures that must be handled sirnuitaneously.</Paragraph> <Paragraph position="2"> Second, one should note that the mechanism presented in this paper may also, ill principle, be applied to Generation rather than TransDr; the conditions will then be stated in terms of tile target language. By the same token, certain differentiating rules may be also applied as part of Analysis (or post-Analysis), tlowever, we feel that the right place for this kind of processing is in Transfer. At least when the target and source languages are linguistically renlote (as, for example, in the case of English and l lehrew), severely restricting the scope of BL operatimls may result in loss of information vital for translation on the way to Generation; e.g. dependence on tense or voice, when tile structural expressions of these properties are different irt the SL and TL. Alternatively, such information could be carried forward to Generation, but then Generation loses its primarily monolingual nature.</Paragraph> <Paragraph position="3"> Allowing Transfer to pass forward alternative translations for SI~ lexical entries, may result in a large number of possible sentence t~anslations which must be handled by Generation.</Paragraph> <Paragraph position="4"> Even if conceptually viable, this strategy is computationally highly unattractive. A similar comment is often made in other contexts (e.g. Analysis - cf. \[Stallard 87\]).</Paragraph> <Paragraph position="5"> Finally, it ~&ould be enlphasized that keeping Transfer small is not, in itself, the crucial issue. More important, it seems to us, is the isolation of bilingual considerations. (Isolation should not be mistaken for serialization of SI,-BL-TL operations, which is not at all required. Ideally, isolated modules could even work in parallel, as suggested by \[Isabelle 86\]). In fact, trying to minimize bilingual Transfer at any cost may yield unnecessarily complex Generation and/or Analysis, which are forced to handle problems that are not inherently within their scope. If, for example, Generation has to consider patterns that were .nly created by phenomena ill a certain source language but were not fully resolved in Transfer, then minimizing Transfer represents no real gain in nmdularity or language independence. Nor does it save lexicographic effort, as in any case, the linguistic classification and judgement process re,nains b:~.sically tile same, even if shifted to other system components.</Paragraph> <Paragraph position="6"> A remark is in order concerning multi-target generality. In principle, it is technically possible to add tags at tile put statement, along with the ItEB tag, to define multilingual translations (cf. e.g. Boitet g6\]). llowever, from our discussion of ttre difference between monolingual subcategorization patterns and the sense distinctions needed for translation, it follows that the algorithms in the lexicon must be further refined in order to cove,&quot; all sub-senses needed for a set of given target languages. For any one language in the set, many of the differentiating rules will be redundant (see &quot;voir trad n&quot; definitions in \[Boitet 86\]). In practice, it would be better to construct distinct variants of the lexicon for different target languages. This need not significantly increase the lexicographic work required, as it is possible to use an existing lexicon as the basis for constructing new variants. The linguistic re-evaluation of senses is required anyway. What is important is that all target languages use the same structure and formalism.</Paragraph> </Section> <Section position="5" start_page="208" end_page="210" type="metho"> <SectionTitle> 5. The Specification Language </SectionTitle> <Paragraph position="0"> \[Slocum 87\] claims (correctly, ill our view) that &quot;lexical entries for computer use tend to be \[ormally stated, compact, and thus cryptically encoded&quot;. While the formal style is inevitable, we have tried to avoid compactness and cryptical expression by allowing the lexicographer to state the lexical facts and the effects they have on processing in terms that are directly related to the logic of the linguistic process. Therefore, tile set of available instructions is rather simple and intuitive. We have tried to allow enough expressive power to support a variety of requirenlents for bilingual lexical mapping, while restricting the scope of operations as much as possible, to reduce complexity and avoid undesired side effects on other entries or suhsystems. We have also emphasized ease of maintenance and testing, and strict isolation of the lexical subsystem from other parts of the translation system.</Paragraph> <Paragraph position="1"> Each entry in tile bilingual lexicon is in fact a mini-program.</Paragraph> <Paragraph position="2"> Although executable declarations may look complicated at first glance, they have, in our view, many advantages over a rigid data structure. The specification formalism may be less neat and &quot;natural&quot; than ttre metalanguage \[Isabelle 86\] hopes for, but it call be made more &quot;user friendly&quot; through the introduction of higher level abbreviations on top of the basic language, as required by users. Some functions for abbreviated writing were mentioned in section :2 above. Other mechanisms (e.g.</Paragraph> <Paragraph position="3"> macros) can be used to tailor the specification style to individual tastes.</Paragraph> <Paragraph position="4"> The program which comprises a lexical entry is initiated by reference to a lexical item that appears on tile Sl. parse tree.</Paragraph> <Paragraph position="5"> The program ternlinates when an end instruction is reached, or when the last instruction in the program is executed. A function is terminated by a return instruction.</Paragraph> <Paragraph position="6"> The instructions allow the lexicographer to check for the existence of a |)articular condition or pattern on the parse tree by an appropriate /_f instruction; control tile seqnencing of instructions by using a goto instruction; and decide on a particular translation for a word by using a put instruction (this is not allowed in the case of a function).</Paragraph> <Paragraph position="7"> The following represents tile current inventory of lexieal operations supported by the specification formalism. It may be necessary to extend this formalism as more experience is gained with actual lexical entries.</Paragraph> <Paragraph position="8"> The syntax of the specification language is given below. Bold letters denote non-terminal constructs, normal letters denote terminals (keywords). The notation used is as follows: symbol description symbol description = = a meta-symbol. \[term\] I a meta-symbol denoting choice. (term) + nil a representation of the null string or list. (term)*</Paragraph> <Paragraph position="10"> uric or no appearance of term.</Paragraph> <Paragraph position="11"> one or more appearances of term.</Paragraph> <Paragraph position="12"> zero or more appearances of term.</Paragraph> <Paragraph position="13"> instruction = = end; I goto(label); I put \[in u-name\] (allowed-attribute value); I call function-name(parameter-list); I if (condition)then < instruction + > \[else < instruction + > \];</Paragraph> <Paragraph position="15"> if (condition)then < \[n-instructio n + > \[else < \[n-instruction + > \]; condition = = call fimction-name I simple-pattern \[ not (condition) L (condition) and (condition) I (condition) or (condition) simple-pattern = = n-name(attribute-pair +) I n-name has \[ no \] relation pattern pattern-condition = = node has \[ no \] relation pattern node : = \[n-name\](attribute-pair +) I n-name relation : = \[first\] prebrother I \[first\] postbrother I \[first\] son i father I ancestor \[ \[last\] prebrother \[ \[last\] postbrother \[ \[last\] son I descendent I relative pattern = = simple-pattern-condition { (pattern-condition) I (pattern \[not\] before pattern) I (pattern \[not\] after pattern) simple-pattern-condition = = node I (node,) + node \[ (node or node) \] (node and node) u-name = = main I cn \] name parameter-list = = nil i parameter + attribute-pair = = (attribute-name value +) value = = string \[ key I ( value + ) label : = Ilanle access-key = = lexical item followed by part of speech.</Paragraph> <Paragraph position="16"> attribute-name = = name allowed-attribute = = an attribute-name the user is allowed by the system to change. pre-defincd-function-name = = a name of a function defined by the system. user-defined-function-name = = name name = = a string of letters and digits starting with a letter.</Paragraph> <Paragraph position="17"> parameter = = a parameter passed to a function.</Paragraph> <Paragraph position="18"> comment = = each line starting with @ is a comment.</Paragraph> <Paragraph position="19"> The programs and functions in the dictionary include names for various entities. The scope of these names is limited as much as possible in order to facilitate debugging and maintenance (e.g. a name of a label or of a particular pattern (node) is recognized only within the program in which it appears).</Paragraph> <Paragraph position="20"> The user's ability to define variables and names is also intentionally restricted. There are two special names: MAIN, the name of the root of the parse tree; and CN (Current Node), the name of the leaf node representing the word for which the program wa:; invoked.</Paragraph> <Paragraph position="21"> Additional information about the semantics Of names, a formal definition of the relations between nodes (e.g. prebrother, first prebrother, descendent, relative, etc.) and the keywords Before and After, etc., are provided in \[Golan 88\], an extended version of this paper.</Paragraph> </Section> class="xml-element"></Paper>