The information maintained by an application typically differs both in kind and in granularity from the literal semantic information entailed by most of the natural language texts produced to express that content. This means that the `input' provided by an application system for the purposes of natural language generation will generally be of a form quite distant from any particular set of natural language expressions imaginable as the `output'. Knowledge-based systems and data bases need to organize their information for efficient access and for maintenance of consistency; these requirements naturally lead to a higher degree of abstraction in the representation.
As an example, Figure 5 shows a simplified extract from the `input' information available in the history of art information system from which our Albers texts above were generated. This representation is realistic for current knowledge-based systems that require large-scale information representation; it is shown here in an object-centered form with each object defined as belonging to some type that has a certain specified set of attributes. Some of these attributes concern the information represented, others are for bookkeeping within the representation. Three `objects' are present in the extract shown in the figure: one corresponding to the artist in question, one standing for a particular kind of `event'--that of someone settling somewhere, and one representing a period of study. The information contained between angled brackets are labels for further linked objects; thus, for example, the studyPeriods slot of the `Anni Albers' object contains a list of four distinct studyPeriod objects, only one of which is also present in the figure. This information could naturally be represented in various other ways--as data fields in a database, or as XML-annotated content, and so on. Further examples of input forms are given widely in the literature [Meteer: 1992,Hovy: 1991,Horacek: 1990,Paris: 1993,Reiter and Dale: 2000] and most complete system descriptions. The design rationale for such representations is usually to be found in the needs of an application, which leads to the addition of various objects, types and slots as required. And this, crucially, may not be at all compatible with the needs of a natural language generation system.
Anni Albers settleEvent: Albers
places: <place: USA>
subject: <Anni Albers>
time: <1933>
studyPeriod: Albers
disciplines: <'art'>
institution: <institution: Kunstgewerbeschule>
subject: <Anni Albers>
time: <1919 - 1920>
|
Example
application program representations taken from the Art History information
system |
The primary task that an NLG system faces is how to turn such more or less appropriate input representations into natural language texts that meet specified communicative goals--such as, for example, informing about an artist's biography, comparing entities, or giving a weather forecast for shipping. It is in principle possible for application terms to be mapped directly onto specific lexical and syntactic patterns, or even onto particular sentence templates, but this has the consequence that only rigid, stereotyped expressions will be possible for the information represented. As we have seen, the exact form of a generated text normally has to depend on many more factors than the basic informational content that an application system might maintain and direct mappings make it virtually impossible for the generation process to be receptive to such factors. It is therefore more usual for an NLG component to bring application objects into correspondence with a more abstract level of representation that is maintained by the NLG system and which is still supportive of varied textual realization.
In the previous section, we showed how this can correspond to the problem of providing a linguistic semantics that is capable of describing alternative form of expressions. However, since semantic specifications are motivated on grounds very different to those motivating application information such as that represented in Figure 5, NLG systems are left with the problem of constructing a mapping between these quite different levels of representation. The information to be selected for generation may also need to be grouped differently (i.e., aggregated) by the NLG system than it is by the application. With reference to the concrete example in the figure, for example, how is a generation system to `know' that the internal representation slot birthPlace can be related to the slot lifeSpan by means of the bearing relation used in the semantic specification? Unless such information is made available explicitly, the slots remain mnemonic labels useless for further processing.
To solve this problem, NLG usually breaks the required mapping down into two further related subtasks: