<?xml version="1.0" standalone="yes"?>
<Paper uid="C94-2176">
  <Title>TOWARDS A MORE USER-FRIENDLY CORRECTION</Title>
  <Section position="7" start_page="1084" end_page="1087" type="evalu">
    <SectionTitle>
5. EXTENSIONS
</SectionTitle>
    <Paragraph position="0"> With these correction methods, the organisation of the correction system is less deterministic. By this, we mean that it is easier to modify its behaviour by updating the weights or the thresholds or by adding new verification rules. This flexibility should make it easier to process syntactic ambiguities due to the relaxation of constraints during the parsing process. For example the sentence: la maison de l'oncle que nous avons vu(e) (the house the uncle we have seen) produces two trees in French if we do not consider agreement rules in gender, but produces only one if we do, depending on the gender of the past participle vu(e). If it is feminine then we have seen the house, if it is masculine then we have seen the uncle. A correction system must then, whenever one of the two trees is correct, apply correction rules to both of them in order to detect a possible error. This implies that we imagine a ti:aversing method of all the trees of the same sentence at the same time. We are at present working on this question.</Paragraph>
    <Paragraph position="1"> The techniques presented above and the correction module which will result are designed for a complete correction system where many modules cooperate in a client/server architecture. We shall then extend the use of weights to the lexical level, for which we have implemented 3 correction techniques: similarity keys, phonetics and morphology (Courtin, 91; Genthial, 92). Each of these techniques proposes, for an incorrect word, a list of correction hypotheses which must be sorted in decreasing likelihood order so that we give the user only the more likely ones. We will weighting each technique and the values of weights will follow dynamically the types of errors of a given user, thus allowing an alternative implementation of the architecture proposed in (Courtin, 89).</Paragraph>
    <Paragraph position="2">  Some lexical errors can only be detected at superior levels (syntactic even semantic) like \[ to not want for I do not want or the doc barks for the dog barks. These errors, named hidden errors (Letellier, 93), lead to a blocking of the syntactic parsing. Here again, the use of prediction mechanisms (syntactic parser or statistical model based on Markov chains), coupled with a weighting of the proposed solutions must allow some automatic corrections below a given threshold.</Paragraph>
    <Paragraph position="3"> Finally, we think it is possible to implement a system making completely automatic corrections. The SS4 example is described in the framework of a computer aided writing system, able to deal with free texts for which it is very hard and even impossible to produce a complete semantico-pragmatic interpretation. On the other hand, if we try to build a robust man-machine interface, then we can hope for a completely automatic correction because: * in this type of applications, the lexicon is very limited, so the number of corrections for a lexical error will be small; * lexical ambiguities will also be less numerous and therefore the number of trees produced will be lower;, * we can use, to resolve syntactic ambiguities or to refine the above criteria, some semantic or pragmatic information which can be well defined because of the restricted domain.</Paragraph>
  </Section>
class="xml-element"></Paper>