The Constituent Likelihood Automatic Word-tagging System (CLAWS) was originally designed for the low-level grammatical analysis of the million-word LOB Corpus of English text samples. CLAWS does not attempt a full parse, but uses a firat-order Markov model of language to assign word-class labels to words. CLAWS can be modified to detect grammatical errors, essentially by flagging unlikely word-class transitions in the input text. This may seem to be an intuitively implausible and theoretically inadequate model of natural language syntax, but nevertheless it can successfully pinpoint most grammatical errors in a text. Several modifications to CLAWS have been explored. The resulting system cannot detect all errors in typed documents; but then neither do far more complex systems, which attempt a full parse, requiting much greater computation. A number of ~rcbers have experimented with ways to cope with grammatically ill-formed English input (for example, [Carboneil and Hayes 83] [Weischedel and Sondheimer 83]). However, the majority of these systems are designed for Natural Language interfaces to software systems, and so can assume a restricted vocabulary and syntax; for example, the system discussed by [Fass 83] had a vocabulary of less than 50 words. This may be justifiable for a NL front-end to a computer system such as a Database Query system, since even an artificial subset of English may be more acceptable to users than a formal command or query language. However, for automated text-checking in Word Processing, we cannot reasonably ask the WP user to restrict their English text in this way. This means that WP text-checking systems must be extremely robust, capable of analysing a very wide range of lexical and syntactic constructs. Otherwise, the grammar checker is liable to flag many constructs which are in fact acceptable to humans, but happen not to be included in the system's limited grammar. A system which not only performs syntactic analysis of text, but also pinpoints grammatical errors, must be assessed along two orthogonal scales rather than a single 'accuracy' measure: It is easy to optimise one of these performance measures at the expense of the other, flagging (nearly) ALL words in a text will guarantee optimal recall (i.e. (nearly) all actual errors will be flagged) but at a low precision; and conversely, reducing the number of words flagged to nearly zero should raise the precision but lower the recall. The problem is to balance this trade-off to arrive at recall AND precision levels acceptable to WP users. A system which can accept a limited subset of English (and reject (or flag as erroneous) anything else) may have a reasonable recall rate; that is, most of the 'true' errors will probably be included in the rejected text. However, the precision rate is liable to be unacceptable to the WP user:, large amounts of the input text will effectively be marked as potentially erroneous, with no indication of where' within this text the actual errors lie. One way to deal with this problem is to increase the size and power of the parser and underlying grammar to deal with something nearer the whole gamut of English syntax; this is the approach taken by IBM's EPISTLE project (see [Heidorn et al 82], [Jensen et al 83]). Unfortunately, this can lead to a very large and computationally expensive system: [Heidorn et al 82] reported that the EPISTLE system required a 4Mb virtual machine (although a more efficient implementation under development should require less memory). The UNIX Writer's Workbench collection of programs (see [Cherry and Macdonald 83], [Cherry et ai 83]) is probably the most widely-used system for WP text-checking (and also one of the most widely-used NLP systems overallsee [AtweU 86], [Hubert 85]). This system includes a number of separate programs to check for different types of faults, including misspellings, cliches, and cee, ain stylistic infelicities such as overly long (or short) sentences. However, it lacks a general-purpose grammar checker, the nearest program is a tool to filter out doubled words (as in "I signed the the contract"). Although there is a program PARTS which assigns a part of speech tag to each word in the text (as a precursor to the stylistic analysis programs), this program uses a set of localized heuristic rules to disambiguate words according to context; and these roles are based on the underlying assumption that the input sentences are grammatically well-formed. So, there is no clear way to modify PARTS to flag grammatical errors, unless we introduce a radically different mechanism for disambiguating word*tags according to contexu CLAWS was originally implemented in Pascal, but it is currently being recoded in C and in POPLOG Prolog. CLAWS can deal with Unrestricted English text input including "noisy" or ill-formed sentences, because it is based on Constituent Likelihood Grammar, a novel probabilistic approach to grammatical description and analysis described in [Atwell 83]. A Constituent Likelihood Grammar is used to calculate likelihoods for competing putative analysis; not only does this tell us which is the 'best' analysis, but it also shows how 'good' this analysis is. For assigning word-tags to words, a simple Markovian model can be used instead of a probabilistic rewrite-role system (such as a prohabilistic context-free grammar); this greatly simplifies processing. CLAWS first uses a dictionary, sufflxlist and other default routines to assign a set of putative tags to each word; then, for each sequence of ambiguously-tagged words, the likelihood of every possible combination or 'chain' of tags is evaluated, and the best chain is chosen. The likelihood of each chain of tags is evaluated as a product of all the 'links' (tag-pair-likelihoods) in the sequence; tag-pair likelihood is a function of the frequency of that sequence of two tags in a sample of tagged text, compared to the frequency of each of the two tags individually. An important advantage of this simple Markovian model is that word-tagging is done without parsing: there is no need to work out higher-level constituent-structure trees before assigning unambiguous word-tags to words. Despite its simplicity, this technique is surprisingly robust and successful: CLAWS has been used to analyse a wide variety of Unrestricted English, including extracts form newspapers, novels, diaries, learned journals, E.E.C. regulations, etc., with a consistent accuracy of c96%. Although the system did not have parse trees available in deciding word-classes, only cA% of words in the LOB Corpus had to have their assigned wordtag corrected by manual editing (see [Atwell 81, 82]). Another important advantage of the simple Markovian model is that it is relatively straightforward to transfer the model from English to other Natural Languages. The basic statistical model remains, only the dictionary and Markovian tag-pair frequency table need to be replaced. We are experimenting with the possibility of (partially) automating even this process -see [Atweli 86a, 86b, which means <possessive personal pronoun>, <comparative adverb>, <past singular BE>. This analysis is then passed to the checking module, which uses tag-pair frequency statistics extracted from copious samples of errorfull texts. These should show that tag-pairs <PP$ RBR> and <RBR BEDZ> often occur where there is a typing error, and rarely occur in grammatically correct constructs; so an error can be flagged at the corresponding point in the text. Although the adjustment to the model is theoretically simple, the tag-pair error likelihood frequency figures required could only be gleaned by human analysis of huge amounts of error-full text. Our initial efforts to collect an Error Corpus convinced us that this approach was impractical because of the time and effort required to collect the necessary data. In any case, an alternative technique which managed without a separate table of tag-pair error likelihoods turns out to be quite successful. This alternative technique involved using CLAWS unmodified to choose the best tag for each word, as before, and then measuring ABSOLUTE LIKELIHOODS of tagpairs. Instead of a separate tag-pair error likelihood table to assess the grammaticality, the same tag-pair frequency table is used for tag-assignment and error-detection. The tag-pair frequency table gives frequencies for grammatically wellformed text, so the second module simply assumes that if a low-likelihood tag pair occurs in the input text, it indicates a grammatical error. In the example above, tag-pairs <PP$ RBR> and <RBR BEDZ> have low likelihoods (as they occur only rarely in grammatically well-formed text), so an error can be diagnosed. Figure 1 is a fuller example of this approach to error diagnosis. This shows the analysis of a short text; please note that the text was constructed for illustration purposes 39 only, and the characters mentioned bear no resemblance to real living people! The text contains many mis-typed words, but these mistakes would not be detected by a conventional spelling-checker, since the error-forms happen to coincide with other legal English words; the only way that these errors can be detected is by noticing that the resultant phrases and clauses are ungrammatical. The granunarchecking program first divides the input text into words. Note that this is not entirely trivial: for example, enclitics such as I'll, won't are split into two words I ÷ 'II, will + n't. The left-hand column in Figure I shows the sequence of words in the sample text, one word per line. The second column shows the grammatical tag chosen using the Constituent Likelihood model as best in the given context. The third column shows the absolute likelihood of the chosen grammatical tag; this likelihood is normalised relative to a threshold, so that values greater than one constitute "acceptable" grammatical analyses, whereas values less than one am indicative of unacceptably improbable grammar. Whenever the absolute likelihood value falls below this acceptability threshold, the flag ERROR? is output in the fourth column, to draw visual attention to the putative error. Thus, for example, the first word in the text, my, is tagged PP$ (possessive personal pronoun), and this tag has a normalisad absolute likelihood of over 15, which is acceptable; the second word, farther, is tagged RBR (comparative adverb), but this time the absolute likelihood is below one (0.264271), so the word is flagged as a putative This technique is extremely primitive, yet appears to work fairly well. There is no longer any need to gather error-likelihoods from an Error Corpus. However, the definition of what constitutes a "low" likelihood is not straightforward. On the whole, there is a reasonably clear correlation between words marked ERROR? and actual mistakes, so clearly low values can be taken as diagnostic of errors, once the question of what constitutes "lowness" has been defined rigorously. In the example, the acceptability level is defined in terms of a simple threshold: likelihoods are normalised so values below 1.000000 are deemed too low to be acceptable. The appropriate normalisetion scaling factor was found empirically. Unfortunately, a threshold at this level would mean some minor troughs would not be flagged, e.g. clever in I stole a meat clever .... (which was tagged JJ (adjective) but should have been the noun cleaver ) has a normalised likelihood of 4.516465; tame in the gruesome tame ofEroc Attwell... (which was also tagged JJ (adjective) but should have been the noun tale ) also has a normalised likelihood of 4.516465; and the phrase won day (which should have been one day ) involves a normalised likelihood of 4.060886 (although this is, strictly speaking, associated with day rather than won, an error flag would be sufficiently close to the actual error to draw the user's attention to it). However, if we raised the threshold (or alternatively changed the normalisation function so that these normalised likelihoods are below 1.000000), then more words would be flagged, lowering the precision of error diagnosis. In some cases, error diagnosis would be "blurred", since sometime-'~ words immediately before and/or after the error also have low likelihoods; for example, was in my farther vms very crawl.., has a likelihood of 1.216545. Worse, some error flags would appear in completely inappropriate places, with no true errors in the immediate context; for example, the exclamation mark at the end of he won't get away with this! has a likelihood of 4.185351 and so would probably be flagged as an error if the threshold were raised. Mother way to define a trough would be as a local minimum, that is, a point on where points immediately before and after have higher likelihood values, even a trough with a quite high value is flagged this way so long as surrounding points are even higher. This would catch clever, tame and won day mentioned above. However, strictly speaking several other words not currently flagged in Figure  1 are also local minima, for example my in perhaps my friends would ... and ~ in he ba/d at me /f [ ... So, this definition is liable to cause a greater number of 'red herring' valid words to be erroneously flagged as putative mistakes, again leading to a worse precision. Once an optimal threshold or other computational definition of low likelihood has been chosen, it is a simple matter to amend the output routine to produce output in a simplified format acceptable to Word Processor users, without grammatical tags or likelihood ratings but with putative errors flagged. However, even with an optimal measure of lowness, the success rate is unlikely to be perfect. The model deliberately incorporates only rudimentary knowledge about English: a lexicon of words and their wordtags, and a tag-pair frequency matrix embodying knowledge of tag cooccurrence likelihoods. Certain types of error are unlikely to be detected without some further knowledge. One limited augmentation to this simple model involves the addition of error tags to the analysis procedure. A rather more sophisticated technique for taking syntactic context into account involves adding ERROR-TAGS to lexical entries. These are the tags of any similar words (where these are different from the word's own tags). In the analysis phase, the system must then choose the best tag (from error-teg(s) and 'own' tag(s)) according to syntactic context, still using the unmodified CLAWS ConstituentLikelihood model. For example, in the sentence l am very hit. an error can be diagnosed if the system works out that the tags of input word hit ( NN, VB, VBD, and VBN<singular cormnon noun>, <verb infinitive>, <verb past tense>, <verb past participle>) are all much less likely in the given context than J3 (<adjective>), known to be the tag of a similar word ( hot ). So, a rather more soph/sticated errordetection system includes knowledge not just about tags of words, but also about what alternative word-classes would be plausible if the input was an error. This information consists in an additional field in lexicon entries: each dictionary entry must hold (i) the word itself, (ii) the word's own tags, and (iii) the error-tags associated with the word. For example: .  Note that error-tags are marked with # to distinguish them from own tags. CLAWS then chooses the best tag for each word as usual. However, in the final output, instead of each word being marked with the chosen word-tag, words associated with an ERROR TAG are flagged as potential errors. To illustrate why error-tags might help in error diagnosis, notice that dense in I maid several dense in h/s ... does not have a below-threshold absolute likelihood, and so is not flagged as a putative error. An error-tag based system could calculate that the best sequence of tags (allowing error-tags) for the word sequence several dense in his ... is [AP NNS~ IN PP$] (<post-determiner>, <plural common noun>, <preposition>, <possessive personal pronoun>). Since NNS is an error-tag, an error is flagged. However, the simpler absolute likelihood based model does not allow for the option of choosing NNS as the tag for dense, and is forced to choose the best of the 'own' tags; this in turn causes a mistagging of /n as NNU (<abbreviated unit of measurement>, since [JJ NNU] (<adjective> <abbreviated unit of measurement>) is likelier than [JJ IN] (<adjective> <preposition>). Furthermore, [JJ NNU] turns out not to be an exceptionally unusual tag cooccurrence. The point of all this is that, without error-tags, the the system may mistag words immediately before or after error-words, and this mistagging may well distort the absolute likelihoods used for error diagnosis. This error-tag-based technique was originally proposed and illustrated in [Atwell 83]. The method has been tested with a small test lexicon, but we have yet to build a complete dictionary with error-tags for all words. Adding error tags to a large lexicon is a non-trivial research task; and adding error-tags to the analysis stage increases computation, since there are more tags to choose between for each word. So far, we have not found conclusive evidence that the success rate is increased significantly; this requires further investigation. Also to be more fully investigated is how to take account of other relevant factors in error diagnosis, in addition to error-tags. In theory at least, the Constituent-Likelihood method could be generslised to take account of all relevant contextual factors, not just syntactic bonding. This could be done by generating COHORTS for each input word, and then choosing the cohort-member word which fits the context best. For example, if the sentence you were very hit were input, the following cohorts would be generated: you yew ewe were where wear very vary veery hit hot hut hat (the term "cohort" is adapted from with a slight modification of meaning). Cohorts of similar words can be discovered from the spelling-check dictionary using the same algorithm employed to suggest corrections for misspellings in current systems; these techniques are fairly well-understood (see, for example, [Yannakoudekis and Fawthrop] i) the degree of similarity to the word actually typed (this measure would be available anyway, as it has to be calculated during cohort generation; the actual word typed gets a similarity factor of 1, and other members of the cohort get appropriate lower weights) ii) the 'degree of fit' in the given syntactic context (measured as the syntactic constituent likelihood bond between the tag(s) of each cohort member and the tag(s) of the words before and after, using the CLAWS constituent likelihood formulae); iii) the frequency of usage in general English (common words like "you" and "very" get a high weighting factor, rare words like "ewe", "yew", and "veery" get a v) domain-dependent lexical preferences should ideally be taken into account, for example in an electronics manual current should get a higher domain weighting than currant. All these factors are multiplied (using appropriate weightings) to yield a relative likelihood rating for each member of the cohort. The cohort-member with the highest rating is (probably) the intended word; if the word actually tylied is different, an error can be diagnosed, and furthermore a correction can be offered to the user. Unfortunately, although this approach may seem sensible in theory, in practice it would require a huge R&D effort to gather the statistical information needed to drive such a system, and the resulting model would be computationally complex and expensive. It would be more sensible to try to incorporate only those features which contribute significantly to increased error-detection, and ignore all other factors. This means we must test the existing error-detection system extensively, and analyse the failures to try to discover what additional knowledge would be useful to the system. The error-likelihoud and full-cohort techniques would appear to give the best error-detection rates, but require vast computations to build a general-purpose system from scratch. The error-tag technique also requires a substantial research effort to build a large general-purpose lexicon. A version of the Constituent Likelihood Automatic Word-tagging System modified to use the ABSOLUTE LIKELIHOOD method of error-detection has been more extensively tested; this system cannot detect all grammatical errors, but appears to be quite successful with certain classes of errors. To test alternative prototypes, we are building up an ERROR CORPUS of texts containing errors. The LOB Corpus includes many errors 41 which appeared in the original published texts; these are marked SIC in the text, and noted in the Manual which comes with the Corpus files, [Johansson et al 78]. The initial Error Coqms consisted in these errors, and it is being added to from other sources (see Acknowledgements below). The errors in the Error Corpus can be (manually) classified according to the kind of processing required for detection (the examples below starts with a LOB line reference number): A: non-word error-forms, where the error can be found by simple dictionary-lookup; for example, A21 115 As the news pours in from around the world, beleagared (SIC) Berlin this weekend is a city on a razor's edge.
REF used a language model of a language to represent correct usage for that language.
How To Detect Grammatical Errors In A Text Without Parsing IT
Conference Of The European Association For Computational Linguistics
Computer Science