File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/94/a94-1001_metho.xml
Size: 27,662 bytes
Last Modified: 2025-10-06 14:13:34
<?xml version="1.0" standalone="yes"?> <Paper uid="A94-1001"> <Title>References</Title> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> CLIENT-SERVICE RESULTS </SectionTitle> <Paragraph position="0"> * Procurement of military aircraft and airframes for the Department of National Defense.</Paragraph> <Paragraph position="1"> KEY ACTIVITIES * Issuing invitations to tenders and requests for proposals.</Paragraph> <Paragraph position="2"> * Conducting negotiations with sole-source suppliers. null * Preparing and issuing contracts within own authority and recommending approval of contracts in excess of own authority.</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> SUBSTANTIATING DATA </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> Environment </SectionTitle> <Paragraph position="0"> * The work involves an office environment, resulting in frequent use of computers and occasional exposure to noise. Some travel is required. null * We are grateful to Ehud Reiter for his valuable comments on an earlier version of this paper, which greatly influenced its present form.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> Results and Key Activities are expressed in point </SectionTitle> <Paragraph position="0"> form; Results as nominal phrases, and Key Activities as gerunds. Substantiating Data statements are sometimes multi-sentential, but tend to follow fairly rigid templates. null A comprehensive analysis of user requirements for the JDM was conducted, during which it became clear that users favoured more explicit control over all aspects of the content of a job description, even if it came at the expense of convenience of composition. The idea of prepackaged templates as a basis for conceptual job descriptions-for example, classifications of Key Activities likely to be associated with department heads, middle management, clerical staff, etc.---met with some resistance, since it might prejudice the outcome of job evaluation. Users also expressed a desire for a convenient means of adding to the collection of concepts available, in the event that they did not find what they needed for a particular job description.</Paragraph> </Section> </Section> <Section position="6" start_page="0" end_page="0" type="metho"> <SectionTitle> 3. Functionality </SectionTitle> <Paragraph position="0"> The EXCLASS JDM comprises two modules: the Job Description Builder (JDB) and the Job Description Generator (JDG). The JDB supports composition and editing of conceptual representations, which take the form of trees of concepts drawn from a structured conceptual dictionary. The JDG produces text from these representations, by combining realization templates associated with each concept. The next three sections describe the conceptual dictionary, conceptual forms, and the structure of the generator.</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.1 Knowledge Representation </SectionTitle> <Paragraph position="0"> The dictionary of concepts used in the JDB to compose conceptual representations comprises several disjoint hierarchies of entities which figure in job descriptions.</Paragraph> <Paragraph position="1"> The current dictionary covers a sample of some 30 job descriptions in English and French, although the analysis on which it was based encompassed at least twice that number.</Paragraph> <Paragraph position="2"> In order to determine just what the entities represented in the conceptual dictionary should be, we began with the following criteria, which derive from the func- null tional requirements: 1. In order to provide a basis for suitable input to the Job Evaluation Module and the Job Description Generator, concepts should be free of the ambiguities observed in textual job descriptions. These ambiguities have three main sources: * multiple word senses; * attachment of dependent phrases; * scope of conjunction.</Paragraph> <Paragraph position="3"> 2. In order to allow managers, who have little or no training in knowledge representation, to work with conceptual representations at the most detailed level, concepts should introduce as little specialized notation as possible.</Paragraph> <Paragraph position="4"> The first criterion calls for concepts which are abstracted from surface linguistic forms, while the second says that they should be close to surface forms, since that is what managers are accustomed to working with when they write job descriptions.</Paragraph> <Paragraph position="5"> In order to satisfy these conflicting criteria, concepts were designed to correspond to surface words or phrases as closely as possible, while remaining free of ambiguities. Concepts corresponding to different senses of the same word are annotated with distinguishing labels---e.g, negotiation \[activity\] (as in negotiating price and cost elements for multi-phase contracts) vs. negotiations \[process\] (as in conducting negotiations with solesource suppliers). Concepts corresponding to surface forms which take dependent phrases are associated with semantic roles (see below). And concepts contain only irreducible conjunctions (e.g. The Banff National Park and region).</Paragraph> <Paragraph position="6"> With regard to the appropriate granularity of concepts, again there were conflicting criteria: 3. Concepts should be fine-grained enough to permit users to express the distinctions that are important to them.</Paragraph> <Paragraph position="7"> 4. Concepts should be coarse-grained enough that edit null ing of conceptual representations is not more burdensome than editing text.</Paragraph> <Paragraph position="8"> Again, the approach adopted was to make concepts just fine-grained enough to account for collocational patterns observed in the corpus (through analysis of concordances).</Paragraph> <Paragraph position="9"> The conceptual dictionary is structured using a representation similar to KL-ONE (Woods & Schmolze, 1992). Concepts are arranged in hierarchies from most general to most specific, and associated with semantic roles and &quot;structural conditions&quot; on those roles. For example, the concept negotiations \[process\] is a child of (&quot;a kind of&quot;) the concept interactions, and has roles for the action involved (e.g. conducting, leading), what is being negotiated (e.g. contracts, agreements), and who is being negotiated with (e.g. suppliers, foreign government representatives).</Paragraph> <Paragraph position="10"> The structural conditions on a concept's roles are expressed partly in terms of a division of the set of concepts into subsets of different types: * Object concepts (e.g. resources, systems for secure storage, special inventory counts), which can serve as roots of conceptual forms (see the next section). * Domain concepts (e.g. asset management, warehousing, custodial warehousing), which correspond to occupational groupings.</Paragraph> <Paragraph position="11"> * Body concepts (e.g. Canadian Parks Service, industry sales representatives, other service providers), which denote types of individuals or corporate entities. null I-I * Location concepts (e.g. Prairie Region, National Capital Region Supply Centre).</Paragraph> <Paragraph position="12"> * Purpose concepts (e.g. to ensure adequate service, to ensure that all aspects of contracts have been completed).</Paragraph> <Paragraph position="13"> * Action concepts (e.g. developing, maintaining, ap- null proving).</Paragraph> <Paragraph position="14"> Object concepts form a hierarchy descending from the most general concept of service (they are also referred to as &quot;aspects of service&quot;). There are separate hierarchies for domains, bodies, and locations; purposes and actions are not hierarchically structured. In general, it is object concepts that have roles, which are filled by concepts of appropriate other types. The structural conditions on roles taking values from one of the hierarchies list a default (most typical) value for the filler, as well as a most-general possible value. When values come from a non-structured set, such as actions, the structural conditions consist of a list of possible values.</Paragraph> <Paragraph position="15"> The conceptual dictionary is also structured according to occupational domains. Concepts peculiar to certain domains are marked with features corresponding to those domains--for example, contracts is a procurement concept; materiel handling equipment is a warehousing concept.</Paragraph> <Paragraph position="16"> The &quot;aspects of service&quot; hierarchy is based not just on &quot;kind of&quot; relations, but also &quot;aspect of&quot; relations-for example, multi-phase contracts are a &quot;kind of&quot; contracts, whereas operational costs are an &quot;aspect of&quot; operations. Inheritance of concept roles and attributes through &quot;kind of&quot; links is used as the basis of the concept acquisition interface (see the last section), although it is not used for retrieving concept data. The exact nature and implementation of inheritance on &quot;aspect of&quot; links is a topic for future research.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.2 Conceptual Forms </SectionTitle> <Paragraph position="0"> In order to compose and edit representations of job descriptions, the user works with conceptual forms. A conceptual form is a Fee of concepts, whose arcs correspond to semantic roles associated with concepts.</Paragraph> <Paragraph position="1"> Visually, concepts in trees are presented as frames with slots named for semantic roles, into which the user can insert other concepts. This was seen as the best way of giving users control over the most detailed aspects of conceptual representations, while keeping their visual presentation relatively simple.</Paragraph> <Paragraph position="2"> An example of the conceptual form of a Key Activity is shown in Figure 2. The MAIN CONCEPT slot of the Key Activity frame takes one or more &quot;aspect of service&quot; concepts as values. The frame for a Result statement corresponds to the central concept service, with slots for NATURE OF SERVICE and</Paragraph> </Section> </Section> <Section position="7" start_page="0" end_page="0" type="metho"> <SectionTitle> CLIENT OF SERVICE. </SectionTitle> <Paragraph position="0"> The basic editing operation for constructing conceptual forms is to highlight a slot, then select a concept to go in that slot. For slots taking values from hierarchically-structured subsets of the vocabulary, such as objects or locations, the user can browse through the relevant hierarchy, subject to the conditions described earlier (Figure 3). The concept browser shows a &quot;focused&quot; concept, together with its parents and children; the user moves up or down by shifting the focus to a parent or child (a Find Concept function is also available). When values are from a non-structured subset (e.g. actions), selection is from a flat list of possible values.</Paragraph> <Paragraph position="2"> Editing of existing conceptual forms is supported by cut, copy and paste functions, which operate on sub-trees of conceptual forms. The same operations are defined for whole statements, so that users can move conceptual structures of any size within the same job description, or between different ones.</Paragraph> <Paragraph position="3"> A notable feature of conceptual forms is that, contrary to usual linguistic practice, object concepts (which in general correspond to grammatical direct objects) are the roots, while action concepts are the dependents. The rationale behind this is that it is relatively straightforward to structure objects into a reasonably deep, exhausfive, and intuitive hierarchy, whereas this would be very difficult for actions. The set of actions can be implicitly structured, however, by constructing lists of actions appropriate for use with any given object. The reason for structuring sets of concepts is to aid the user in composition, so that s/he only has to choose from a small number of alternative concepts at any one point. So the implicit structuring of actions according to whether they can occur with a given object is only useful if the user selects the object first, and then the actions.</Paragraph> <Paragraph position="4"> Above the level of conceptual forms for individual statements of various types, there is currently no meaningful representation of a job description as a whole, except that the domains listed under NATURE OF SERVICE in Result statements are used to &quot;trim&quot; the concepts displayed in the browser when composing the rest of the job to only those relevant to those domains.</Paragraph> <Paragraph position="5"> How to represent links or enforce consistency between different statements--in particular between Results/Key</Paragraph> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> Activities and Substantiating Data--is a topic of ongo- </SectionTitle> <Paragraph position="0"> ing research by the developers, and discussion by potential users.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 3.3 Linguistic Realization </SectionTitle> <Paragraph position="0"> Given the close correspondence between conceptual forms and surface linguistic forms, we decided to re-examine our initial assumption that the Job Description Generator would be implemented by adapting CoGenTex's existing text-generation shell.</Paragraph> <Paragraph position="1"> Versions of this generator, based on Meaning-Text Theory (Mel'~alk & Pertsov, 1987), have been used in other applications, including the generation of bilingual weather forecasts (Goldberg et al., to appear) and statistical reports (Iordanskaja et al., 1992). In order to produce text suitable to these applications, the generator starts with deep conceptual representations, successively deriving deep-syntactic, surface-syntactic, morphological, and surface representations. It also incorporates sophisticated mechanisms for text planning and paraphrase. null For several reasons, the existing generator was considered unsuitable for this application. The main rationale was that, since concepts already resembled pieces of surface text, those pieces should not be reconstructed by the generator unless this was necessary to produce text of acceptable quality. If the words and phrases corresponding to concepts could be given just enough linguistic structure that a simplified generator could combine them more or less directly to produce text, then it would be a waste of effort to decompose them to the level of detail on which the existing generator operated, only to regenerate aspects of surface form that were already present in concept labels.</Paragraph> <Paragraph position="2"> Another factor favouring a simplified generator design was the decision, following the design of the conceptual forms, to include a &quot;continuous text feedback&quot; function in the JDM interface. Again, since users were unaccustomed to working with conceptual representations, it would be useful if they could confirm their choices on the conceptual level with textual feedback from the JDG. The JDM's conceptual editor (Figure 2 above) incorporates a text preview area, which is updated every time a change is made to the conceptual form. It also has the feature of displaying text even for incomplete conceptual forms. The existing generator did not have the level of real-time performance demanded by this feature (on a 386-PC platform), or the ability to generate incomplete phrases.</Paragraph> <Paragraph position="3"> A simplified generator design was facilitated by certain linguistic properties of job descriptions: * When statements are not simple clauses, they follow fairly rigid templates. All conjunctions except and and or can be treated as parts of concepts (e.g.</Paragraph> <Paragraph position="4"> the purpose concept to ensure that all aspects of contracts have been completed).</Paragraph> <Paragraph position="5"> * Referring expressions are always either generic or proper noun phrases (no pronouns or deftnite/indefinite distinctions).</Paragraph> <Paragraph position="6"> * There is very little morphology to deal withwthere is no agreement, due to the lack of subjects, and the fact that adjectives and articles can always be treated as part of the same concept as the noun they modify. null Given these facts, all the generator has to do is select different alternatives for realization of concepts in some cases, concatenate phrases, and perform ellipsis resulting from conjunctions. Text planning is performed manually by users--they can order clauses in a Key Activity, or actions for an object, in the same way that they order Key Activities in a job description.</Paragraph> <Paragraph position="7"> The generator is in the spirit of a Montague-style categorial grammar (Dowty et al., 1981), except that operations of function application and composition, rather than operating on semantic objects in parallel with the concatenation of surface elements, operate in effect on the surface elements themselves. In order to illustrate its operation, consider the conceptual form in</Paragraph> </Section> </Section> <Section position="8" start_page="0" end_page="0" type="metho"> <SectionTitle> ACTION FOR ACTIVITIES OF OTHERS: supewising MAIN CONCEPT OF ACTIVITIES OF OTHERS: </SectionTitle> <Paragraph position="0"> routine assignments</Paragraph> </Section> <Section position="9" start_page="0" end_page="0" type="metho"> <SectionTitle> ACTION FOR ROUTINE ASSIGNMENTS: </SectionTitle> <Paragraph position="0"> performing PURPOSE OF PERFORMANCE: ensure adequate service special assignments</Paragraph> </Section> <Section position="10" start_page="0" end_page="0" type="metho"> <SectionTitle> ACTION FOR SPECIAL ASSIGNMENTS: </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> Activity statement </SectionTitle> <Paragraph position="0"> Each concept in the dictionary is associated with one or more realization templates, which are complex expressions built up from surface words or phrases, cer- null &quot; to&quot; , (&quot; ensure&quot; , (&quot; adequate&quot; , 'O service&quot;)) (ACTION: gerund)* (&quot; special&quot;* ,w assignments&quot;) .... , .... , , .... , .... , .... ,o, &quot; &quot; * ..... * ..... 11 ...... * ~x(( performance ( of x)) ( to (ensure (~dequate service ))))(routine asstgnments ) superwsmg | 2x(( performance ( of x)) ( to (ensure (adequate servtce )))) ( spectal ass,gnments ) II ........ * ........ .... .... * .... * ..... )))1 performance* ( of ( routine* ass,gnme ))) ( to ( ensure ( adequate serv,ce ) ol * * iv, superwsmg (I .... * .... * ..... * ..... * .... * .... * .... * ..... )))J performance ( of (spectal assignments )))(to ( ensure ( adequate servtce) &quot;supervising&quot;* I (&quot; performance&quot; * (&quot;of&quot;* ( (&quot; routine&quot; & &quot; special&quot;)* &quot; assignments&quot;)) )* (&quot; to&quot;* (&quot;ensure&quot; * (O' adequate&quot;*&quot;service&quot;) ) ) l concepts in Figure 4 are shown in Figure 5a.</Paragraph> <Paragraph position="1"> Expressions of the form <SLOT:type> specify how the contents of a slot are to be realized i.e., using which of the available templates. For example, a Key Activity frame is realized by realizing the contents of its MAIN CONCEPT slot as a gerund. The activities of others frame, which essentially represents a Key Activity embedded within another, is realized by concatenating the gerundive form of its action with the nominal realization of the embedded frame. The first step the generator performs is to instantiate these expressions to the correct forms, and conjoin multiple fillers of a single slot with the & (and) operator, resulting in the form in Figure 5b. The next step is to reduce lambda expressions, which gives 5c. Ellipsis is then performed, giving the form in 5d. Finally, occurrences of the & operator are lexicalized as either commas or and, as appropriate.</Paragraph> <Paragraph position="2"> The operators used in realization templates, other than 2 and &, serve to represent structure which is consulted by the rules for lambda reduction and ellipsis.</Paragraph> <Paragraph position="3"> Lambda reduction of an expression Lr.(A)*B gives a copy of A in which all occurrences of x (usually one) are replaced with B. This is used for a &quot;wrap&quot; effect in 1 There are rules in some cases for deriving variant templates for a concept from a basic template. For example, the gerundive (basic) template for an object concept in general has the form <ACTlON:gerund>* ...; the nominal form is derived from this simply by specifying the nominal form of the action.</Paragraph> <Paragraph position="4"> cases where actions have dependents, as well as in nominalizations--in these cases the dependence of actions on objects in conceptual forms cannot be undone simply by concatenating the action to the left of the object.</Paragraph> <Paragraph position="5"> The lambda notation is also used to specify connecting phrases (usually prepositions) which are associated with the slots of certain concepts, and introduced by the generator-for example, in realizing the phrase negotiations with contractors, the preposition with is introduced by concatenating the connecting-phrase expression gx(&quot; with&quot;* x) associated with the NEGOTIATIONS WITH WHOM slot to the left of the slot's realization, &quot;contractors&quot;. When slots are empty, the connecting phrase is omitted--this is mainly what accounts for the generator's ability to produce incomplete phrases (in some cases, conceptual forms with empty slots can produce acceptable phrases).</Paragraph> <Paragraph position="6"> The basic rules for ellipsis are (A*B)&(A*C) =~ A*(B&C) and (A*C)&(B*C) ~(A&B)*C. There are other rules which optimize conjunctions to some degree by reordering conjuncts, but the overall approach is to let users control the order manually. An operator # is used in place of * to block ellipsis, and an operator \ handles cases in French where an OR is introduced during ellipsis, according to the rules (A \ B)& (A k C) unique et d dtapes multiples or les contrats d fournisseur unique ou dtapes multiples.</Paragraph> <Paragraph position="7"> Grammatical differences between French and English are dealt with by assigning different structures, sometimes using different operators, to the English and French templates for a given concept, but there are also cases where the lexicalization of a concept depends on another concept in the context--for example, performing special assignments translates as executer les affectations spdciales, whereas performing post-contract cleanup translates as assurer le suivi des contrats. These cases are modelled using the MTT notion of lexical functions--in this example, the values in English and French of the Operl function (&quot;verb denoting the most typical action of the first actant&quot;) are performing and executer for the concept special assignments/affectations spdciales, and performing and assurer for the concept post-contract cleanuplsuivi des contrats. Lexical functions are implemented in the conceptual dictionary as &quot;virtual&quot; concepts, with pointers to actual concepts for each language. Users can switch the language in which conceptual forms are displayed (independently of the language in which text is generated), and when they do so, the appropriate actual concepts are displayed, with no explicit indication of the underlying virtual concept.</Paragraph> <Paragraph position="8"> This means, for example, that a user could copy the concept assurer from the ACTION slot of suivi des contrats, and paste it into the ACTION slot of affectations sp~ciales, whereupon its label would change to executer.</Paragraph> <Paragraph position="9"> The generator design described in this section has several advantages for this type of application: * It takes full advantage of the similarity of concepts to surface linguistic forms, which was dictated by the functional requirements. Phrases are generated as chunks wherever possible, while still being assigned enough linguistic structure to produce adequate text.</Paragraph> <Paragraph position="10"> * Given the large volumes of concepts anticipated, maintenance of realization templates will presumably be simplified if they do not refer to lexicai entries in a main dictionary, and if a constrained grammatical formalism is employed.</Paragraph> <Paragraph position="11"> * Incomplete phrases can be generated straightforwardly, in order to support the text preview function. null</Paragraph> </Section> </Section> <Section position="11" start_page="0" end_page="0" type="metho"> <SectionTitle> 4. Research Topics </SectionTitle> <Paragraph position="0"> The main concern for deployment of EXCLASS on a large scale is how to deal with the large volumes of concepts which will be required. A concept acquisition interface has been designed to support expansion of the dictionary.</Paragraph> <Paragraph position="1"> The acquisition interface is invoked from the concept browser, when the user has determined that the desired concept is not already available. The user selects a concept from the browser to be the parent of the new concept in the relevant hierarchy. The attributes of the new concept (label, slot types and possible values, realization templates) can then be edited, starting with default values. The defaults are inherited from the parent concept, on the assumption that the new concept is a &quot;kind of' the parent. The nature of inheritance through &quot;aspect of' links is a topic for future research.</Paragraph> <Paragraph position="2"> Another topic of research is how to possibly enrich representations of a job as a whole, as well as of individual concepts. The JEM developers are experimenting with comparisons of job descriptions based on fuzzy distance measures, which in turn are based on the positions of individual concepts in the hierarchy. Action concepts are difficult to compare, since they are currently unstructured. Adding some sort of structure, such as ranking the possible actions for a given object, could facilitate job comparison, as well as treating linguistic phenomena such as &quot;asymmetric&quot; conjunction (developing and implementing methods vs.</Paragraph> <Paragraph position="3"> *implementing and developing methods).</Paragraph> <Paragraph position="4"> Finally, research is being conducted on different usage modes for the JDM interface--in particular, an &quot;expert&quot; mode in which the user could enter the text of simple (non-conjoined) statements and have it parsed to some extent (using an elaborated &quot;fred&quot; function) into a conceptual form, rather than performing repetitive point-and-click operations.</Paragraph> </Section> class="xml-element"></Paper>