File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/05/w05-1614_metho.xml
Size: 39,892 bytes
Last Modified: 2025-10-06 14:09:57
<?xml version="1.0" standalone="yes"?> <Paper uid="W05-1614"> <Title>Computational Mechanisms for Pun Generation</Title> <Section position="4" start_page="0" end_page="0" type="metho"> <SectionTitle> 3 Two classes of puns </SectionTitle> <Paragraph position="0"> There are various ways in which puns, or jokes in general, could be classified, depending on the aspects which are of interest. For the discussion here, we wish to make a distinction between two loose groupings (not usually distinguished in the literature): Self-contained puns: These are pieces of text which can be used as humorous items in a wide variety of circumstances. Any semantic links which they might have to the context are not directly part of the joke structure, and their only preconditions for use are general knowledge (of the surrounding culture, etc.) and a social situation in which joke-making is acceptable. Example (1) (from [Binsted, 1996]) is a self-contained pun, as are all of the puns ((5) - (13)) shown in Section 4.1 below.</Paragraph> <Paragraph position="1"> (1) What do you get when you cross a murderer with a breakfast food? A cereal killer.</Paragraph> <Paragraph position="2"> Contextually integrated puns: This type of pun occurs within some broader discourse, with the use of a text which, in addition to conveying some information or emotion, has further linguistic properties which make it a pun (and may thereby augment the effects of the text, either emotionally, persuasively or otherwise). Also, the status of the text as a pun may depend on contextual (possibly non-linguistic) factors. Ritchie [2004, p.115] offers (2) and (3) as puns; both of these, when first delivered, were contextually integrated puns.</Paragraph> <Paragraph position="3"> (2) A shopper is walking along, and a leek falls from his shopping bag to the ground, unnoticed. Another shopper calls out, &quot;Hey! Your bag's leaking!&quot; (3) A minor football team known informally as 'Caley Thistle' (where Caley rhymes with alley) soundly defeats Celtic (then the top team in the country) in a major competition. The next day, a newspaper headline reads: &quot;Super Caley Go Ballistic, Celtic Are Atrocious&quot;. (The Sun, 9 February 2000) In (2), the pun status depends upon the substring leak being phonetically similar (identical) to the word leek, and the latter word being directly related to the surrounding context. In (3) the whole headline has some phonetic similarity to the song-title Supercalifragilisticexpialidocious. In both cases, the utterance conveys contextually appropriate information.</Paragraph> <Paragraph position="4"> For both these types of puns, the text's status as a pun is in addition to a full set of normal linguistic properties: the punning texts are usually syntactically well formed texts which have an internally consistent semantics.</Paragraph> <Paragraph position="5"> The difference between the two classes can be viewed as follows: in self-contained puns the semantic content is arbitrary, and of secondary importance to the features that make the text a pun, whereas in contextually integrated puns the semantic message is non-arbitrary, and the pun features have to be compatible with it.</Paragraph> <Paragraph position="6"> There are some puns which might seem to be borderline examples. In everyday social situations, someone may make a remark simply in order to make a pun, which might seem therefore to count as a self-contained pun, but such an utterance is very rarely completely unconnected to the context, even if its sole purpose is humour. For example, someone who moves their position in a room to avoid cold air from an open window might make the remark in (4), punning on the USA expression draft-dodger, 'someone who avoids military conscription'.</Paragraph> <Paragraph position="7"> (4) I'm just a draught-dodger.</Paragraph> <Paragraph position="8"> Although this remark may communicate little useful information, and is made solely as an attempt at humour, it is still a contextually integrated pun, in the sense that what it conveys relates to the context, and it would not be a pun without this connection - if the speaker had not moved to avoid cold air, it would not be felicitous, and if someone later recounted the remark alone, with no account of the context, that would not count as a joke.</Paragraph> </Section> <Section position="5" start_page="0" end_page="0" type="metho"> <SectionTitle> 4 Previous work: self-contained puns </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.1 The programs </SectionTitle> <Paragraph position="0"> Since 1992, there have been a small number of programs which created puns (cf. [Ritchie, 2004, Ch 10]). (Jokes depend on cultural knowledge, and puns rely heavily on linguistic knowledge, so some of these examples may be puzzling to readers from other cultural or linguistic backgrounds.) Lessard and Levison [1992] devised a program which created a type of pun, the Tom Swifty, exemplified by (5).</Paragraph> <Paragraph position="1"> (5) &quot;Turn up the heat,&quot; said Tom coldly.</Paragraph> <Paragraph position="2"> The form consists of a quoted utterance, and an adverbially modified attribution of this remark to Tom. The meaning of the utterance, or some subpart of it, is semantically linked to the adverb. The generation is based on finding a configuration of a root word (e.g. cold) which can be made into an adverb (coldly) and a sentence somehow linked to the root word.</Paragraph> <Paragraph position="3"> The JAPE program [Binsted, 1996; Binsted and Ritchie, 1997] generated punning riddles of certain types, illustrated by (1), (6), (7), (8) (cf. [Lessard and Levison, 1993]).</Paragraph> <Paragraph position="4"> (6) How is a nice girl like a sugary bird? Each is a sweet chick.</Paragraph> <Paragraph position="5"> (7) What is the difference between leaves and a car? One you brush and rake, the other you rush and brake (8) What do you call a strange market? A bizarre bazaar.</Paragraph> <Paragraph position="6"> This was achieved by various rules which specified allowable combinations of lexical entries and surface words; more details are given in Section 4.2 below.</Paragraph> <Paragraph position="7"> The HCPP [Venour, 1999] could create two-utterance texts, where the second part was always a short noun phrase, as in (9) (punning on doc/dock) and (10) (carrel/carol).</Paragraph> <Paragraph position="8"> (9) The surgeon digs a garden. A doc yard.</Paragraph> <Paragraph position="9"> (10) Joan hears wailing in the booth. Carrel singing.</Paragraph> <Paragraph position="10"> Venour describes his method in terms which borrow both from Binsted and from Lessard and Levison.</Paragraph> <Paragraph position="11"> The puns produced by the WISCRAIC program [McKay, 2002] came in three forms, exemplified by (11), (12), (13). (11) Who broke the woman's hart? The cruel deer-keeper.</Paragraph> <Paragraph position="12"> (12) The performing lumberjack took a bough.</Paragraph> <Paragraph position="13"> (13) Your mate Johnny is a hard-up deer-keeper. He really needs doe! Like the earlier programs, WISCRAIC operated by finding sets of items (e.g. take a bow, bough, lumberjack, performing) which were related in specific ways, then slotting them into stock textual forms.</Paragraph> <Paragraph position="14"> The output of all these programs consists of self-contained puns in the sense given in Section 3 above.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.2 An architecture for self-contained puns </SectionTitle> <Paragraph position="0"> Some of the pun-generators (Lessard and Levison, Venour) reviewed above were implemented using the Vinci language generator [Levison and Lessard, 1992], others (Binsted, McKay) using various Prolog facilities, including definite clause grammars [Pereira and Warren, 1980]. However, the general flow of processing in these systems is broadly the same, and can be described using the model used by [Binsted, 1996] (see also [Ritchie, 2003]). We will look at it in more detail, partly to make more concrete some aspects of these puns, and partly to show how these mechanisms relate to more conventional NLG.</Paragraph> <Paragraph position="1"> The JAPE processing falls into three stages: content selection, constituent building, surface string construction, each of which is controlled by particular types of symbolic rule.</Paragraph> <Paragraph position="2"> (Binsted calls the constituent-building stage SAD generation, where 'SAD' stands for small adequate description, because in JAPE it leads to short descriptive noun phrases.) We shall describe each of these stages in turn.</Paragraph> <Paragraph position="3"> Content selection In this phase, a small number of items are selected from the lexicon as the core of the pun. The generator has rules about suitable combinations of lexical items and/or surface words, and uses these to search for a cluster of workable items.</Paragraph> <Paragraph position="4"> Binsted calls the content selection rules schemas. A pungenerator program would have a number of schemas (JAPE3 had 15), each corresponding to some subclass of pun. A schema contains two rather different types of information: Precondition. A schema has a condition which a sequence of lexical entries or surface strings (intuitively, the parameters for the schema) must meet in order for this type of pun to be generated. The precondition consists of a conjunction of terms, where each term is a predicate (e.g. homophone) applied to variable arguments, and all variables are existentially quantified. (None of the programs appear to need constant values as arguments to predicates.) For example, one schema (from [Ritchie, 2003]) has the precondition: noun_phrase(NPLex), component_lexemes(NPLex, LexA, LexB), written_form([LexA], WordA), homophone(WordA, HomWord), written_form([HomLex], HomWord) where some of the variables (NPLex, LexA, LexB, HomLex) are to be matched against lexemes (abstract identifiers for lexical entries) and others (WordA,HomWord) are matched against surface strings. One possible set of bindings is NPLex = serial killer, LexA= serial,LexB= killer,WordA = 'serial', HomWord = 'cereal', HomLex = cereal.</Paragraph> <Paragraph position="5"> Although many examples can be produced using predicates which are computable using standard lexical information (e.g. homophone), some of the puns (particularly those in McKay's system) need semantic relationships which, while not seriously problematic, might not be standard lexical relations; for example an action - take a bow - which is &quot;typical&quot; of an entity with a particular property - performing. Covering these might need a more encyclopaedic knowledge base.</Paragraph> <Paragraph position="6"> Interface to later stages. This part of a schema specifies what is to be done with (some or all of) the values which satisfy the preconditions. It contains a formula indicating how further processing of the items is to be carried out, specifically what sorts of constituents they are to be built into. For example, the JAPE schema illustrated immediately above has the output specification (taking some liberties with notation to save space): <same, sad(share_properties, [HomLex, NPLex]), sad(make_phrase, [HomLex, LexB]) > This (rather obscurely) indicates that the values HomLex, NPLex are to be used to create a phrase which, semantically, has some mix of their properties (e.g. a murderer with fibre), and that HomLex, LexB, are to be made directly into a phrase (hence cereal killer). Also, the final text should convey that the abstract relation same holds between these two constituents. That is, the output specification of a schema provides a recipe for producing a structure which, while not actually a text, is much closer to the eventual surface form. The various building procedures (e.g. share properties) have a certain amount of non-deterministic freedom (see below), so that there may be more than one way in which the linguistic form of the phrase can be constructed, without affecting the basic joke; for example, share properties might create a crunchy murderer.</Paragraph> <Paragraph position="7"> Constituent building Given the items found in content selection, it may be necessary to form constituents (noun phrases, verb phrases, sentences) which either contain these items or bear some systematic relationship to them. In this stage, linguistic representations of these chunks are constructed, following the output specification of the schema.</Paragraph> <Paragraph position="8"> The constituent building stage is a relatively arbitrary mapping from the formulae provided by the schema to something which is more of a surface semantic structure. This is done by pattern-action rules which match against the various 'output specifications' that can be come from the schema handler, and produces something either in surface linguistic form (e.g. a string of words) or some skeletal linguistic item whose exact details (e.g. person, number) are left to the final (surface string) stage. Thus some variation is possible in the linguistic form of phrases, within the limits set by the initial schema match. That is why Binsted introduced this middle stage (not present in an earlier version of JAPE): to allow some linguistic variety where this does not alter the underlying joke. For example, (14) requires the same schema (and surface template) as (8), but uses a different constituent for the question; this difference would occur in the constituent-building phase. (14) What do you call an odd mall? A bizarre bazaar.</Paragraph> <Paragraph position="9"> Surface string construction In the third and final stage, a complete surface text is built by transforming the semantic constituents into surface strings and concatenating them, in some order, with various fixed strings of words. Minor adjustments such as number agreement, or choosing between a and an, are carried out. All this is driven by templates, which are like DCG rules with some pre-conditions attached.</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.3 Discussion of the mechanisms </SectionTitle> <Paragraph position="0"> The mechanisms summarised here were designed solely to produce puns, but the notions of &quot;schema&quot; and &quot;template&quot; are not radically (or interestingly) different from those established within mainstream NLG (e.g. [McKeown, 1985], [Kukich, 1983]). However, the way that this whole architecture is deployed is unusual. Normally in NLG, we can reasonably make a distinction between some background knowledge base (e.g. linguistic rules, lexicon, general facts about the domain) and some message which is to be conveyed. A typical schema-based system then matches its schemas against the message to determine applicability, with the background knowledge being called upon only as needed in the match.</Paragraph> <Paragraph position="1"> In contrast, the pun generators have only a knowledge base, and do not start from a message to be conveyed: they are random generators of arbitrary puns. Hence the schemas are tested against the whole lexical knowledge base, to see if any sequence of items will meet the stated preconditions.</Paragraph> <Paragraph position="2"> Rather than asking, as in informative NLG, 'is the message of this general shape?', the pun generator asks 'are there any items which can be put together in this way?'. Thus content selection (which, conventionally, would precede schemamatching) is inherent in this search for matching items.</Paragraph> <Paragraph position="3"> Also, the remits passed from the schema-instantiator to the constituent builder may be extremely vague, and not directly related to any communicative goals. For example, generating &quot;Tom Swifties&quot; requires, for the utterance part of the text, a constituent to be constructed which is, roughly speaking, 'any sentence which uses this specific word'.</Paragraph> <Paragraph position="4"> These processing characteristics follow naturally from the fact that the pun generators produce self-contained puns, and hence have no communicative goals: any text will do, regardless of content, providing it constitutes a pun.</Paragraph> <Paragraph position="5"> Hence, although schemas and templates are standard NLG notions, the freedom allowed to the processing model is less normal. Is this model of wider use? One possible application where this arrangement (arbitrary content but constrained form) might be of use is a language-teaching tool in which the illustrative examples are not all pre-programmed by hand but are machine-generated (either in advance or in response to the interaction with the human learner). It is conceivable that a such a system might need to create phrases or sentences which are not embedded in any real context, and for which the information conveyed is not critical, but whose linguistic structure must manifest some particular property (e.g. using some specific word, or being in passive voice). In that case, the unusual priorities embodied in the JAPE-style architecture (linguistic form over content) might be relevant.</Paragraph> <Paragraph position="6"> The three-stage pun generation architecture allows quite efficient processing, but the initial lexicon search could be costly if done crudely. However, given the well-defined nature of that search, it can be optimised in various ways; preliminary unpublished results on the STANDUP project [Waller et al., 2005] suggest that fast schema-instantiation from a realistically large lexical database is quite feasible.</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 4.4 Usefulness of self-contained puns </SectionTitle> <Paragraph position="0"> Although a self-contained pun is of use only where it would be helpful to interject a joke for its own sake, it could have a limited degree of contextual connection, in the following way. The status of the text as a pun is not context-dependent (otherwise it would be a contextually integrated pun), but it could mention topics which are currently salient. For example, Loehr [1996] describes a very small prototype system in which the user interface occasionally tells the user a (JAPEgenerated) joke. Loehr explores limited contextual linking, based on keywords (for example, using a joke involving the word aid when help was needed).</Paragraph> <Paragraph position="1"> Such loose subject matter links do not require computer joke-generation, but could be achieved from an database of jokes which had been thoroughly cross-indexed. This might be a viable way to add humour to a user-interface. Some investigation would be needed of what types of semantic links give rise to the most appropriate jokes, and the crossindexing, to be automated, would have to depend on well-defined mechanisable relations (e.g. from a lexical database). The main weakness of using self-contained puns in practical applications (such as those suggested by writers cited in Section 2) is the lack of a subtle connection to what is going on at the moment of delivery. Nevertheless, isolated or random jokes could still play a role in some applications: Virtual agents: If a life-like image is to have a facetious &quot;personality&quot;, then producing the occasional joke (even a bad one) might be fitting (as in Loehr's system).</Paragraph> <Paragraph position="2"> Teaching language: An interactive system for assisting language learners might use jokes as subject matter to be studied or played with (as proposed by McKay, or by [Manurung et al., 2004]). In such cases, the jokes might not need to be tightly related to context.</Paragraph> <Paragraph position="3"> Again, both these applications could meet the joking requirements using a database of jokes, although proponents of the educational application might argue that the effect will be enhanced if the learner can experiment with joke-building using an interactive system; cf. [Waller et al., 2005].</Paragraph> <Paragraph position="4"> Notice that even a witty advertising slogan, although typically used in an isolated, context-independent fashion, is more sophisticated than the types of self-contained pun that have so far been computer generated, in that the content of a slogan is not arbitrary: it has to convey a particular message.</Paragraph> <Paragraph position="5"> In contrast, the systems reviewed in Section 4.1 above give no regard to the communicative content of the output text.</Paragraph> </Section> </Section> <Section position="6" start_page="0" end_page="0" type="metho"> <SectionTitle> 5 A general definition </SectionTitle> <Paragraph position="0"> From (2), (3) and other examples, Ritchie [2004] argues that there is a relatively well-defined, but large, subclass of puns which can be summarised thus: (i) part of the utterance is phonetically similar (perhaps identical) to some other string not present in the utterance; null (ii) either the utterance, or the utterance with that other string substituted in, is contextually appropriate; (iii) if the two substrings are identical, then they should be lexically analysable in different ways, and the lexical analysis of the one not in the utterance should either be linked semantically to the context, or should involve grouping together words which are separate within the utterance; (iv) if the two substrings are merely similar, then the unspoken one should form a complete and recognisable linguistic unit (e.g. a complete word or an established phrase). [Ritchie, 2004, pp.125-126] This is probably the best available formal definition of this kind of pun (see [Davies, 2004]), but it has some limitations (which Ritchie documents) and some weaknesses: (i) This covers only paradigmatic puns, where the comparison is between two strings, only one of which actually appears in the text. There are also syntagmatic puns where both the similar/identical strings appear in the text; (7) and (8) are very simple examples.</Paragraph> <Paragraph position="1"> (ii) Where a sequence of words is involved in the pun, even the unspoken sequence must &quot;make sense&quot; in some way; that is, a pun is not formed when a contextually appropriate remark has a portion which is phonetically identical to some random sequence of words (unless the individual words qualify as puns separately). We shall assume this further condition in our discussions.</Paragraph> <Paragraph position="2"> (iii) In the case where the two strings are merely similar (but not identical) the definition puts no restriction on which should appear in the actual text (providing the non-present text forms a well-known phrase). However, consider an example like (3), above. The headline would not have worked as a pun had it simply read 'Supercalifragilisticexpialidocious', as this would not have allowed recovery of the contextually-appropriate message (even though it would still conform to Ritchie's definition). The correct condition may be better stated in terms of the ease with which the absent string can be summoned up or reconstructed, although this is not an unproblematic notion [Hempelmann, 2003]. It may be that there is a trade-off between the degree of phonetic similarity and the extent to which the string outside the text is a well-known phrase. Ritchie also cites the headline (15), but this may work because un-bolivia-ble is not a valid word, which may draw attention to the possibility that another word or phrase should be considered.</Paragraph> <Paragraph position="3"> (15) Some South American stamps are un-bolivia-ble The word unbelievable is not a well-known item in the sense of being famous, but it is cohesive as a morphologically complex word.</Paragraph> <Paragraph position="4"> (iv) The previous point suggests that the condition stipulating that either one of the two similar strings should form a contextually appropriate part of the utterance may, in some cases, be too loose.</Paragraph> <Paragraph position="5"> (v) Ritchie adopts the widespread assumption that puns are defined on phonetic strings, as this allows a natural description of the central relationship (phonetic similarity). However, many puns are conveyed in written text, and most NLG systems produce textual rather than spoken output. When a pun involves two phonetically identical strings, the question of which string appears in the actual utterance is moot when all the representations are phonetic; when the text is orthographically represented, the choice of string may affect whether the pun is noticeable to the reader. It is arguable that (2) would be more obviously a pun if the final sentence were Your bag's leeking! That is, it may improve the effectiveness of the pun to use the textual form which is not completely linguistically appropriate (here, there is no verb to leek). Ritchie [2004, p. 199] gives a more formal version of his definition, which makes it clearer what primitive concepts it depends upon. These are: Phonetic similarity. Study of an extensive range of puns (e.g. [Sobkowiak, 1991]) shows that the degree (and nature) of similarity required for punning is not obvious. Contextually appropriate. Puns are part of a text which &quot;makes sense in context&quot;. Although this is not unproblematic, it is a condition which an NLG system should aim for, even if no punning is intended; that is, it is not a further condition imposed by the aim of punning.</Paragraph> <Paragraph position="6"> Linked to the context. This is a looser notion than 'contextually appropriate'. The linking just means that some concepts which are salient in the context are somehow related to the concept(s) mentioned in the word or phrase; e.g. in a situation where cooking is being discussed, words like grill or baste would be linked to the context.</Paragraph> <Paragraph position="7"> Forming a recognisable word/phrase. Puns can depend on a sequence of words being matched against a single word, or a well-known idiom, motto or quotation. It is not clear when a phrase is sufficiently established to qualify.</Paragraph> <Paragraph position="8"> The above definition covers contextually integrated puns relatively naturally - see (2), (4) and the examples in [Ritchie, 2004, Ch 9] - and is therefore directly relevant to the possible generation of such puns. Less obviously, the definition could be seen as covering self-contained puns (and hence the puns in Section 4), as follows. The early part of the text (e.g. the question in a riddle) can be treated as the &quot;context&quot;, and the latter part (e.g. the answer to a riddle) as forming the pun utterance proper. That is, self-contained puns can be seen as puns with their own &quot;context&quot; built in, rather than linking to some context outside the text.</Paragraph> </Section> <Section position="7" start_page="0" end_page="0" type="metho"> <SectionTitle> 6 Computing contextually integrated puns </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 6.1 The usefulness of contextually integrated puns </SectionTitle> <Paragraph position="0"> Many of the advocates of useful computational humour seem to have in mind some form of &quot;wit&quot; by the computer system, rather than the mere spouting of jokes. The hypothetical illustrations given by Binsted[1995], for example, involve droll observations by the computer about what is happening at the moment. Such goals take us in the direction of contextually integrated puns. More concretely, if puns delivered within a quasi-natural dialogue are not contextually appropriate in a non-trivial way, there is little point in wasting time with computer generation; as noted earlier, a large and well-indexed database of jokes would be much more straightforward.</Paragraph> <Paragraph position="1"> Let us consider what would be needed for a system to produce a text which met all the pun conditions given in Section 5. We assume that the NLG system will already be striving for a text which makes sense (in context), so we need only consider how the further pun conditions might be achieved. All of these requirements are decidable in principle, although (as noted above) there are non-trivial problems in defining what should count as sufficient phonetic similarity, what counts as an established phrase, and what counts as linkage to a context.</Paragraph> </Section> <Section position="2" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 6.2 Detecting puns </SectionTitle> <Paragraph position="0"> Suppose some communicative system is to enhance its verbal output with puns. It seems reasonable to propose that such a system (particularly in cases where this behaviour is to be part of a life-like &quot;personality&quot;) should be &quot;aware&quot; of having made a pun. That is, if the system makes a pun, it should have some record of that having happened, so that it can respond appropriately to, or even anticipate, the user's reaction. Ideally, the system should also be able to avoid humour when this would be socially inappropriate.</Paragraph> <Paragraph position="1"> This suggests that the most minimal form of puncomputation would be checking textual output to see if it contains accidental puns. The system would then be in the position to make sense of any reaction by the user to the pun (or to eliminate any accidental but undesirable humour). This would not involve any special-purpose text construction - the system would merely check the output it had designed to meet its current (non-punning) goals. If unwanted humour is to be eliminated, this is more difficult, as it would require some form of revision component, which is not trivial.</Paragraph> <Paragraph position="2"> Such a scheme could be seen as a special case of a more general post-checking approach, which tests for other desirable or undesirable properties, such as accidental ambiguity. (General ambiguity might even constitute a form of fortuitous humour, but that goes beyond the basic punning we are currently considering.) As we shall discuss below, the full pun definition might lead to complex computations. A simplification which should be more tractable (but might miss more complex puns) would be merely to check each lexical item in the text to determine whether it had a homophone which was linked to the context.</Paragraph> <Paragraph position="3"> In order to ensure that the user was aware of the pun, the homophone might have to be substituted into the text (as in our method below, Substitution with identity).</Paragraph> <Paragraph position="4"> Notice that incomplete coverage is something of a flaw in a checking mechanism like this, as the aim is for the system to spot every occasion on which it makes a pun; if it misses some, then the user might respond to a pun in a way which the system cannot easily interpret (or an unwanted joke might slip through). On the other hand, a pun-production mechanism, like those discussed below, need not be comprehensive, as long as it can produce some puns (and does not cause the text to become faulty in other respects).</Paragraph> </Section> <Section position="3" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 6.3 The search problem </SectionTitle> <Paragraph position="0"> Our working definition (Section 5) involves a combination of conditions, some of which result in considerable search: finding some substring of the utterance, finding some string not in the utterance (a very large set!), finding some lexical analysis of the non-utterance string which meets certain conditions, finding some well-known word or phrase which is similar. The definition also has a few disjunctions, to further increase the search. Hence, even a non-constructive check (Section 6.2) would involve a significant amount of searching, particularly if na&quot;ively implemented.</Paragraph> <Paragraph position="1"> Some of the simpler cases considered below (e.g. substituting a contextually-linked homophone) might fit naturally into a NLG system based on constraint-satisfaction (CS) (cf.</Paragraph> <Paragraph position="2"> [Power, 2000]). However, CS methods would not completely remove the complexity problems involved in implementing the entire definition from Section 5. CS reduces processing in cases where the possible values of the variables are well-defined and easily enumerable, and evaluating individual constraints is relatively cheap; i.e. where the main computational load is in testing compatibility among chains of values. Here, the main work is elsewhere. Conditions such as testing whether some substring of some possible output string is similar to some well-known phrase would require computationally expensive enumeration of the basic values (possible substrings of possible output texts), and non-trivial conditions (phonetic similarity) involving very large sets (all words and well-known phrases). CS might be slightly better than a na&quot;ive search, but it would not be a panacea.</Paragraph> <Paragraph position="3"> One complicating factor is that the pun criteria are largely surface constraints which apply to what, in a conventional pipeline NLG architecture [Reiter and Dale, 2000], would be the final output of the generator. Hence, it may be difficult for high-level (early) stages of a pipeline generator to make syntactic or lexical decisions which will result in puns, nor is it simple to effect &quot;revisions&quot; to a surface text which has been the outcome of much high-level processing. There is not space here to explore the large issue of surface-level constraints and their consequences for NLG architecture, but see [Reiter, 2000] for some discussion.</Paragraph> <Paragraph position="4"> Puns are not the only forms in which surface constraints are central: poetry generation [Manurung et al., 2000; Gerv'as, 2002] makes comparably awkward demands.</Paragraph> </Section> <Section position="4" start_page="0" end_page="0" type="sub_section"> <SectionTitle> 6.4 Some possible devices </SectionTitle> <Paragraph position="0"> We can consider some possible ways in which an NLG system might include contextually integrated puns.</Paragraph> <Paragraph position="1"> Substitution with identity. The crudest approach to actual pun-generation would be to attach a punning module as a final stage. This module would review the entire text as generated and see whether it could be edited to form a pun, while making as few revisions as possible - preferably none - to previous higher-level decisions. The simplest tactic here would be the substitution of a phonetically similar (and internally coherent) string for some subpart of the message, where the substituted string does not represent the same lexical items as those in the original message, and either the content of the substituted string is somehow linked to the context or the substituted version should represent a finer segmentation of the material into words. Even for this very basic method, the search is considerable. A simplified version could be limited to looking for homophones of words in the message, and substituting these providing they were contextually linked; this is probably the most tractable option.</Paragraph> <Paragraph position="2"> Substitution with similarity. A slight extension of the previous method would be to relax the condition from phonetic identity to phonetic similarity. However, some care would be needed in deciding under what conditions this should be permitted, in view of the point raised earlier about the &quot;recoverability&quot; of the contextually appropriate string. (This extension worsens the search problem.) Minor rephrasing. It is conceivable that a surface-based editing component could detect that a minor re-wording would fulfil the pun conditions. However, such changes should not impair the overall message of the text, which means that this is not an easy solution.</Paragraph> <Paragraph position="3"> Lexical preference. Rather than using a post-editing stage, we could build the pun facilities into a higher level of the NLG system. One possibility would be some form of amended lexical choice, within the NLG process (i.e. not post-editing as in the above mechanisms). The system could, when choosing a lexical item, give preference (if it would not distort the intended message) to a word which has a homophone which is in some way linked to the context. It might also be helpful to use that homophone in the text, to make the pun obvious to the reader, as noted previously. An extension would be to have the lexical choice system seek a phonetically similar item (not a strict homophone) which is associated with the context. In this case, inserting that other word in the text (in place of the more directly correct one) would be not just helpful but necessary.</Paragraph> <Paragraph position="4"> Rephrasing for lexical preference. The previous device could perhaps be generalised, depending on how the generator organises lexical choice, to giving preference to a phrasing (not just the choice of a single word in isolation) which contains a word with a homophone/similar word which meets the pun conditions. This increases the amount of searching that the NLG system would require.</Paragraph> <Paragraph position="5"> Matching against phrases. A further generalisation would be for the system to seek not an identical/similar word, but a phrase (similar/identical to a valid wording of the intended message) which met the pun conditions (perhaps, as in example (3), matching one word against several). These conditions (Section 5) for a phrase are slightly different from those for a word. To consider matching all possible well-known phrases (assuming such a database were available) when constructing a sentence would lead to high search costs.</Paragraph> <Paragraph position="6"> Some of these processes could be quite open-ended, as puns (human-constructed) sometimes involve quite global rephrasing in order to achieve the punning effect. The subeditor who created (3) must have planned the entire headline with the word Supercalifragilisticexpialidocious in mind.</Paragraph> <Paragraph position="7"> The later tactics (Rephrasing for lexical preference, Matching against phrases) would be more easily incorporated into a generator which was opportunistic about what material to include. For example, the ILEX text generator [Oberlander et al., 1998] has a content selection stage in which the knowledge base is traversed to gather facts to be expressed. This is not as free as the process in Section 4.2 above, as ILEX starts from a particular knowledge base object which is to be described, and the search is for facts relevant to that object.</Paragraph> <Paragraph position="8"> The STREAK system [Robin, 1994] can produce variants of a text in which different amounts of supporting information (for the central proposition) are included. The choice of this additional information could allow more freedom to a pundevising algorithm (although still with significant search).</Paragraph> <Paragraph position="9"> Even if any of these pun-creating schemes were implemented, it is quite likely that in many cases no suitable match would be found, and text realisation would have to proceed as normal. That is, the pun-condition checking might be wasted effort, just adding to the generation time for the text.</Paragraph> </Section> </Section> class="xml-element"></Paper>