<?xml version="1.0" standalone="yes"?>
<Paper uid="P04-3030">
  <Title>Wysiwym with wider coverage</Title>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 Limitations in coverage
</SectionTitle>
    <Paragraph position="0"> For some applications, the above procedure works well, but it allows far too few variations to cope with real documents or queries of normal linguistic complexity. A single choice of event type ('take') is assumed by default to imply just one out of the thousands of possible clause patterns that could be obtained by varying mood, tense, polarity, modality, etc., or by adding adverbial modifiers: force does the patient take an aspirin? take an aspirin time the patient took an aspirin the patient will take an aspirin polarity the patient does not take an aspirin modality the patient may take an aspirin the patient must take an aspirin the patient might take an aspirin the patient should take an aspirin modifier the patient takes an aspirin [at some time] the patient takes an aspirin [somewhere] the patient takes an aspirin [in some manner] the patient takes an aspirin [with some frequency] By combining just the above features, we obtain over 300 combinations; these would multiply further if we included the semantic features controlling perfective, progressive, voice, and wh-questions. Such a large set of options challenges the feasibility of Wysiwym, or indeed any other approach to knowledge editing by domain experts.</Paragraph>
  </Section>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
4 Editing with complex types
</SectionTitle>
    <Paragraph position="0"> Our favoured (indeed, only) proposal for embracing these variations is based on an analogy with a drawing tool. In Wysiwym, choosing take from a menu of event types introduces an event entity, implicitly defaulted to present time, positive polarity, and so forth. In a drawing tool, choosing the rectangle icon from a palette of shapes introduces a rectangle entity, implicitly defaulted to a certain size, colour, and border (to name just three features). Having introduced a rectangle entity, however, the user can reconfigureit by changing these features one at a time. Why should an equivalent operation not be provided for the semantic features underlying a clause?  To add this extra editing operation we must replace the simple entity types employed in early Wysiwym systems by complex types, as illustrated in figure 2 (to simplify, just a few of the possible features are shown). To reconfigure an entity, the user selects the corresponding span in the feedback text (all such spans will be mouse-sensitive), and chooses from a menu of options, each corresponding to a change in just one feature.</Paragraph>
    <Paragraph position="1"> With this potentially huge increase in the number of editing operations for a given feed-back text, the idea of precomputing all possible menus and popping one up on demand becomes less attractive, both computationally and to the user. Instead, when the user selects a span of text, the menu of reconfigurations for that span is computed on the fly, and displayed in a static menu pane adjacent to the main text pane, which can be browsed and searched - see figure 3. At every stage during the interaction, the user sees a feedback text (right pane), with one span highlighted through a colour code, and a list of options for reconfiguring the currently selected unit (left pane). If the selected unit happens to be an anchor (square brackets), the operation will be one of choosing an initial entity type rather than reconfiguring an existing one, but the appearance of the interface will be the same. The user can continue the interaction in two ways: either by choosing an option from the menu pane, or by selecting a different current unit by mouse-clicking within the feedback text pane.</Paragraph>
    <Paragraph position="2"> To illustrate, we will suppose that the current A-box is as depicted in figure 2, and that the 'patient' entity is currently selected. Highlighting the selected span in bold face rather than a colour code, the feedback text and the menu of reconfiguration options might be as follows: The patient takes an aspirin.</Paragraph>
    <Paragraph position="3"> identifiability A patient multiplicity The patients The labels (identifiability etc.) could of course be replaced by more familiar words (e.g., article, number). Assuming that the user is happy with the subject of the sentence, he/she will ignore the reconfiguration options and instead click around the word 'takes' in the feed-back text, so selecting the whole event entity: The patient takes an aspirin.</Paragraph>
    <Paragraph position="4"> polarity The patient does not take an aspirin.</Paragraph>
    <Paragraph position="5"> time The patient took an aspirin.</Paragraph>
    <Paragraph position="6"> The patient will take an aspirin.</Paragraph>
    <Paragraph position="7"> modality The patient must take an aspirin.</Paragraph>
    <Paragraph position="8"> The patient may take an aspirin.</Paragraph>
    <Paragraph position="9"> The patient might take an aspirin.</Paragraph>
    <Paragraph position="10"> If the first reconfiguration option is chosen, setting polarity to negative, the revised options will conserve this new value throughout, except for the new polarity option, which will now be to change the value back to positive: The patient does not take an aspirin.</Paragraph>
    <Paragraph position="11"> polarity The patient takes an aspirin.</Paragraph>
    <Paragraph position="12"> time The patient did not take an aspirin.</Paragraph>
    <Paragraph position="13"> The patient will not take an aspirin.</Paragraph>
    <Paragraph position="14"> modality The patient must not take an aspirin.</Paragraph>
    <Paragraph position="15"> The patient may not take an aspirin.</Paragraph>
    <Paragraph position="16"> The patient might not take an aspirin.</Paragraph>
    <Paragraph position="17"> Figure 3 also shows the use of tags in the feed-back text, such as Leaflet, Section, Paragraph. These provide anchor points to select and reconfigure linguistic units which have no exclusive text of their own. Such tags would not form part of the final output text in a document authoring scenario.</Paragraph>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
5 Benefits of the approach
</SectionTitle>
    <Paragraph position="0"> These techniques make it possible to construct complex, fluent and expressive texts using a point-and-click interface, with no typing of text.</Paragraph>
    <Paragraph position="1"> The benefits of previous Wysiwym systems are also retained here: the text is guaranteed to have a coherent internal representation which can be constrained to conform to a controlled language or house style specification, or generated (and edited) in a different language. The internal representation can be used to monitor the document content, for example to provide authoring support, or it can be transformed into an alternative representation for further processing. null Although the motivation for this extension was to provide effective support for document authoring, the underlying model offers additional functionality in other knowledge creation scenarios as well. The examples in this paper use the complex types of the knowledge objects to represent linguistic variation, but might just  as easily represent other kinds of semantic detail, for example in an object-oriented program specifciation scenario.</Paragraph>
  </Section>
class="xml-element"></Paper>