The main contribution of ATNs is to introduce the notion of registers, assignment and tests into network notations. Registers can be used to keep track of pieces of text, pieces of output structure or features (like gender) of lexical items. Using registers, general tests can be made on acceptability (for example, gender agreement) and output can be built in a flexible order. The use of registers enables what would be different paths through an RTN to be merged into one, and search to be avoided by storing information before its exact significance is known. In addition, the use of global registers provides a technique for handling phenomena like the non-local dependencies found in some English relative clauses and questions.
A few words on the history of ATNs. We have noted that there are consistent structural relations between, for instance, a statement and the corresponding yes-no question, and a yes-no question and the corresponding WH question. In linguistics in the 1960s, the development of Chomsky's transformational grammar was largely motivated by observations like these. Chomsky and his co-workers described a set of transformations that could be used to derive more complex sentences (for example, WH questions) from simpler ones (for example, very simple declarative sentences). Unfortunately, it proved computationally infeasible
to undo or reverse these transformations in a principled way, so as to build a language analyzer that would take arbitrary sentences and understand them in terms of their putative source representations. Woods and others
developed ATNs essentially as a programming language for writing analyzers where the undoing of transformations could be carried out during processing. Unfortunately, it is not in general easy to translate any given transformation into ATN code. Nevertheless, ATNs, typically running in a left-to-right mode and using depth-first search, were probably the most prominent framework for natural language syntactic analysis in the 1970s.
Readers will hopefully have noticed how the flavour of ATNs is different from all the other formalisms we have discussed so far. Writing an ATN is much more like writing a computer program than writing either an FSTN or an RTN. When we write programs in conventional programming languages, a program will only do the task it is designed for. Similarly, our ATN for translating from English into French cannot be used (straightforwardly) for generating random English sentences or translating from French to English, say. With FSTNs and RTNs, we were writing specifications that could in principle be used for a number of tasks. To summarize, although they are based on the same network-traversing metaphor, ATNs are a procedural formalism, whereas FSTNs and RTNs are essentially declarative.
Although ATNs still get used, there are a number of trends in NLP that are now leading to their decline. The original theory of transformational grammar whose operations they sought to embody has changed out of all recognition. Furthermore, many linguists have begun to recognize the advantages of simpler formal frameworks. The importance of declarative formalisms is becoming increasingly realized in Computer Science, an issue we will examine further in Chapter 4. Finally, as we will see in Chapter 6, the rise of charts as an efficient basis for parsing makes it clear that the depth-first search strategy adopted by most ATN implementations leaves something to be desired.
There would be something thoroughly perverse about seeking to program an ATN in Prolog: the native inhabitant would look at you with a puzzled frown and says "if I wanted to go there, I would not start from here". ATNs represent an unavoidably procedural approach to the representation of syntactic facts about natural language, whereas the whole ethos of logic programming favours declarative representations.
Our consideration of network-based language processors has led us to special-purpose programming languages for language analysis. Indeed, it can be shown that ATNs have the basic power to be used as a language for arbitrary programming tasks. Is there anything, then, that we can say theoretically about natural language analysis, apart from the fact that a general programming language is required for the job? Is there a future for declarative notations? In the next chapters we hope to show that both of these questions can be answered affirmatively.
Send us a comment.