File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/84/p84-1066_metho.xml
Size: 12,153 bytes
Last Modified: 2025-10-06 14:11:44
<?xml version="1.0" standalone="yes"?> <Paper uid="P84-1066"> <Title>REFERENCES</Title> <Section position="2" start_page="0" end_page="328" type="metho"> <SectionTitle> 2. The Sentence Planner </SectionTitle> <Paragraph position="0"> The module which creates the overall clausal structure of each sentence works on a list of numbers representing the course of a game (complete or unfinished), where each square is represented by a number between i and 9. The processing carried out by the sentence planner can be seen as occurring in three logical phases: i. move annotation 2. sentence segmentation 3. case-frame linking Although these stages are logically distinct, they need not occur wholly in temporal sequence. However, the abstract model is clearer if viewed in separate stages.</Paragraph> <Section position="1" start_page="0" end_page="327" type="sub_section"> <SectionTitle> 2.1. Move Annotation </SectionTitle> <Paragraph position="0"> The system has a set of heuristic rules which enable it to play noughts-and-crosses to a reasonable standard. (A non-optimal set of rules helps to introduce some variety into the play).</Paragraph> <Paragraph position="1"> It uses these move-generating rules to work through the history of the game, computing at each position which move it would have made for that situation and which move-generating rule gives rise to the move actually made at that point. This allows it to mark the actual move in the given history with certain tactical details, using the implicit assumption that whoever made the moves had the same knowledge of the game as the system itself does.</Paragraph> <Paragraph position="2"> The five move-generators are totally ordered to reflect a &quot;priority&quot; or &quot;significance&quot; with respect to the game, and each move-generator is labelled with one of three categories - &quot;defensive&quot; (e.g. blocking the third square in an opponent's near-complete line), &quot;offensive&quot; (e.g. creating a near-complete line, which thus threatens the opponent) or &quot;neutral&quot; (e.g. taking a square to start the game). In addition to basic organisational entries (square taken, name of player, pointer to preceding move, pointer to following move), the annotation of the moves contains the following information: (a) generating heuristic(s) - there is a list, in priority order, of the heuristics which could have given rise to that move.</Paragraph> <Paragraph position="3"> (b) tactically equivalent alternatives - for each heuristic listed in (a), there is a list of the other squares which could also have resulted from that heuristic.</Paragraph> <Paragraph position="4"> (c) lines involved - for each square mentioned in the various entries, there is a note of which lines (if any) were (or would have been) tactically involved in that move.</Paragraph> <Paragraph position="5"> (d) better move - if there is a higher priority heuristic that would give rise to a different choice of square, an annotated description of that &quot;better&quot; move is attached.</Paragraph> <Paragraph position="6"> For example, the game described by the discourse in Section 1 above would initially be just a sequence of square-numbers, together with the name of the first player: user 1 2 3 After annotation, the third move (square 3) would have the following information attached:</Paragraph> </Section> <Section position="2" start_page="327" end_page="327" type="sub_section"> <SectionTitle> 2.2 Sentence Segmentation </SectionTitle> <Paragraph position="0"> The sentence segmentation process involves grouping the annotated moves into clusters so that each cluster contains an appropriate amount of information for one sentence. This uses the following guidelines, in the following order, to determine the number of moves within a sentence: i. If there is just one move left in the sequence, that must be a single sentence.</Paragraph> <Paragraph position="1"> 2. If there are just two moves left, they form a single sentence.</Paragraph> <Paragraph position="2"> 3. If a move is a &quot;mistake&quot; (i.e. there is a tactically better alternative) then start a new sentence to describe it. This is quite a dominant principle, in that the system will perform &quot;look-ahead&quot; of two (actual) moves in the annotated chain to check if there is a mistake looming up.</Paragraph> <Paragraph position="3"> 4. If a move is a combined attack and defenc~ give it a sentence to itself.</Paragraph> <Paragraph position="4"> 5. If this move is an attack, and the next move successfully thwarts that attack, then put these two moves into a sentence on their own.</Paragraph> <Paragraph position="5"> 6. Put the next three moves in a sentence. (No more than three moves may occur in a single sentence structure).</Paragraph> <Paragraph position="6"> As well as segmenting the moves, this module attaches to each move a tag indicating its overall tactical relationship to the preceding moves. This is a gross summary of some of the tactical information provided by the annotator, and encodes much of the information needed by the next stage (case-frame linking). There are four tag-values used - &quot;consequence&quot; (the move is a result of the preceding one), &quot;thwart&quot; (the move prevents an attack by the preceding one), &quot;mistake&quot; (the move is a failure to make the best possible move), and &quot;null&quot; (an all-purpose default).</Paragraph> </Section> <Section position="3" start_page="327" end_page="328" type="sub_section"> <SectionTitle> 2.3 Case-frame Linkin$ </SectionTitle> <Paragraph position="0"> Once the moves have been annotated, grouped and tagged, their descriptions can be constructed and linked together, to form the internal structure of the sentence. In this process, various case-frame structures are computed from the information attached to each move, and are placed in order, linked by various relationships. There may be, within a sentence, several descriptions associated with a single move, since it is possible for more than one aspect of a move to be mentioned. In each case-frame structure, the other roles will contain suitable fillers - e.g. the square taken (for a &quot;take&quot; description), or the other player (for a &quot;threat&quot;) - which are computable from the annotations. Each such case-frame description will eventually give rise to a full tensed clause. In addition, some of these case-frames will have, embedded within them on the &quot;method&quot; case-role, further simple case-frames which will eventually give rise to adjuncts to the tensed clause in the form of verb phrases (e.g. &quot;...by taking a corner..&quot;). Hence the linking process involves selecting those descriptive structures (from the annotations) which are to be expressed linguistically, formulating these as filled case-frame~, and labelling the relationships between these descriptions. Relationships between case-frame descriptions are indicated by attaching to each case-frame a &quot;link&quot; symbol indicating its relation to the surrounding discourse (either within that sentence, or across the preceding sentence boundary). This process is non-deterministic in the sense that there are usually several equally good ways of expressing a given move or sequence of moves within a sentence. The program contains rules for all such possibilities, and works through all the possible combinations using a simple depth-first search. The case-frame construction also determines the clausal structure of the sentence, in that the nesting or conjoining of clauses is fixed at this stage. The clausal structure does not allow recursive levels - there are, for example, no verbs with sentential complements. The case-frame construction and tagging depends on the links inserted by the sentence-segmenter, together with three items of information from the annotations on the moves - whether the move has two aspects, defensive and offensive; any &quot;better&quot; move that has been attached; and whether the tactic-name uniquely defines, within the context, which square must have been taken. The case-frame construction and linking proceeds according to certain guidelines: I. if the move is a &quot;mistake&quot;, indicate that by describing both the better move and the actual move.</Paragraph> <Paragraph position="1"> 2. if a move has two possible descriptions, one &quot;offensive&quot; and the other &quot;defensive&quot;, describe both aspects.</Paragraph> <Paragraph position="2"> 3. if a move has two possible descriptions which have the same classification within the set {neutral, offensive, defensive}, then choose the most significant (as determined by the priority ordering of tactics).</Paragraph> <Paragraph position="3"> 4. if two consecutive (actual) moves are such that the second one prevents an attack made by the first, then select the tactics corresponding to these aspects to describe them.</Paragraph> <Paragraph position="4"> 5. if there are no &quot;offensive&quot; or &quot;defensive&quot; aspects listed, use the simple &quot;take&quot; form.</Paragraph> <Paragraph position="5"> The following rule is also applied to all moves described: if the square taken is not uniquely determined by the tactic-name, and the tactic-name is not &quot;take&quot;, then create a &quot;take&quot; case-frame describing the move, and either make it into a separate conjoined clause (if the move has a sentence to itself) or attach it to the main case-frame as the &quot;method&quot;.</Paragraph> <Paragraph position="6"> Since the aim of the current project is to use this discourse domain as a &quot;back-end&quot; for experimenting with functional unification grammar (Kay (1979)), the sentence planner has to produce &quot;fuctional descriptions&quot; to indicate the underlying grau~natical form for each sentence. The linked case-frames are therefore reformulated into functional descriptions, with the links attached to the front of each clause determining two aspects of the syntactic structure - the lexical item (if any) to be used as &quot;binder&quot; or &quot;connective&quot; at the front of the clause (again, a non-deterministic choice), and the grammntical features (e.g. modality, aspect) to be added to the clause in addition to those default settings programmed into the system. The ten possible &quot;links&quot;, with their possible surface realisations as a result In addition, the first four of the above links cause the clause to have perfect aspect, &quot;hypothetical&quot; and &quot;altho&quot; cause the presence of the modality &quot;can&quot;, and &quot;condconse&quot; results in the modality &quot;will&quot;. (Notice that &quot;could&quot; is regarded as the past tense of &quot;can&quot;, and &quot;would&quot; as the past tense of &quot;will&quot;).</Paragraph> </Section> </Section> <Section position="3" start_page="328" end_page="328" type="metho"> <SectionTitle> 3. Possible Generalisations </SectionTitle> <Paragraph position="0"> After establishing a suitably implementation independent description of the processing necessary to achieve the behaviour of Proteus, the next step should be to try to extract some general notion of how to describe a sequence of events. The domain used here (tic-tac-toe) has the unusually convenient feature that there is a basic canonical form for representing (in a relatively neutral, primitive form) what the sequence of events was. That is, the original list of moves is a non-grammatical representation of the world events to be described. It is not realistic to make such an assumption in general, so a more abstract model may have to take up the planning process at a slightly later stage, when moves already have some form of &quot;descriptions&quot;.</Paragraph> </Section> class="xml-element"></Paper>