<?xml version="1.0" standalone="yes"?>
<Paper uid="W06-1807">
  <Title>Merging Stories with Shallow Semantics</Title>
  <Section position="4" start_page="0" end_page="0" type="metho">
    <SectionTitle>
3 Knowledge Refinement and Merging
</SectionTitle>
    <Paragraph position="0"> Once the clauses have been extracted from the text, each story becomes a list of predicates, representing verbs, each with a number of arguments (possibly zero), representing nouns. Two stories can thus be compared by considering how the clauses from one story relate to the clauses from another story. This is done both by considering how the predicates (verbs) from one story relate to those from another story and also by considering the arguments (nouns) that these related predicates connect. This allows us to consider not just the similarity of the words used in the story but also, to some extent, the structure of the sentences.</Paragraph>
    <Paragraph position="1"> The aim of merging is to build up, initially, a working merged story that includes all aspects of each story so far; then, when all stories have been merged, to refine the working merged story by removing aspects of it that are considered to be peripheral to the main core. The output is a single story in the same format as the inputs, and which reflects common elements from across the set of variants.</Paragraph>
    <Paragraph position="2"> If text is represented in such clause form, then the number of ways in which these clausal representations of the story can differ is strictly limited. Clauses have only two attributes: predicates and arguments. The predicates may find an exact match, an inexact match or no match. If the predicates find some kind of match, their arguments can then be examined. Each of these will find an exact, inexact, or no match with the corresponding ar- null gument in the related predicate; additionally, their ordering and number may be different. Thus it is possible to create an exhaustive list of the possible differences between clauses. We currently consider only WordNet information concerning synonyms, hypernyms and hyponyms when determining matches: we do not perform inference using antonyms, for example, nor do we consider implication cases.</Paragraph>
    <Paragraph position="3"> The techniques that are used in the merging process were inspired by work on dynamic ontology refinement (McNeill et al., 2004), which deals with the problem of reasoning failure caused by small inconsistencies between largely similar ontologies. This is achieved by analysing ontological objects that were expected to, but do not, match, and diagnosing and patching these mismatches through consideration of how they differ through reasoning. Examples of mismatches that are common between similar ontologies are changed names of predicates (often to sub- or super-types), changed arity, and changed types of arguments. These types of ontological mismatches are currently handled by our system, since in the domain of stories people often use different names or different levels of description for things. The application of these techniques for determining differences and similarities between the story representations therefore forms the basis of the merging process.</Paragraph>
    <Paragraph position="4"> In order to merge a new story with the current working merged story (WMS), the facts in the WMS are examined one by one in an attempt to match them to a fact in the story to be merged. Such a match may be exact (the predicates and all their arguments are identical), inexact (the predicates have the same name but their arguments differ), similar (the predicates are synonyms) or related (the predicates are hyponyms or hypernyms). Information about synonyms, hyponyms and hypernyms is extracted from WordNet and used as the type hierarchy for our refinement (see Section 5; for an explanation of our usage of WordNet, see the WordNet project (Miller, 1995) for general details). Another potential kind of match is where the arguments match but no link can be found between the predicates; however, this is not considered in the current system. If a match of any kind is found for a predicate from the WMS, the predicate from the new story with which it matches is appended to its entry in the WMS. Each entry in the WMS is annotated with a score to indicate in how many stories a match of some kind has been found for it. For example, an entry in the WMS, ([1] play(child)) may find an inexact match with cavort(child) in a new story, to create an entry of ([2] play(child), cavort(child)) in the new WMS.</Paragraph>
    <Paragraph position="5"> Once all the facts in the WMS have been examined and matched where possible, there will usually be some facts in the story to be merged that have not been found as a match for anything in the WMS. These should not be ignored; they have no match with anything thus far, but it may be that stories to be merged in future will find a match with them. Thus, they are added to the merged story with a score of 1. The initial merged story is found by simply annotating the first story to be merged so that each entry has a score of 1. It is possible, but not necessary, to provide a range value to the merging process, so that matches are only sought in the given vicinity of the fact in the WMS. If no range value is given, this is set to be arbitrarily large so that all of the story to be merged is examined.</Paragraph>
    <Paragraph position="6"> Once all of the stories to be merged have been examined, we have a complete WMS, which needs to be processed to produce the merged output. A threshold value is used to determine which of these should be immediately discarded: anything with a score less than the threshold. Those with a score of more than or equal to the threshold must be processed so that each is represented by a single fact, rather than a list of different versions of the fact. If all versions of the fact are identical, this single version is the output. Otherwise, both a 'canonical' name and 'canonical' arguments for a fact must be calculated. In the current system, a simple approach is taken to this. For the predicate, if there is more than one version, then the most commonly occurring one is chosen as the canonical representative. If there are two or more that are jointly the most commonly occurring, then the most specific of the names is chosen (i.e., the one that is lowest in the class hierarchy). When choosing the arguments for the merged predicate, any argument that has a match in at least one other version of the predicate is included. If the match is inexact -i.e., the arguments are not of the same class, but are of related classes -- then the most specific of the classes is chosen.</Paragraph>
  </Section>
  <Section position="5" start_page="0" end_page="0" type="metho">
    <SectionTitle>
4 Worked Example
</SectionTitle>
    <Paragraph position="0"> We now work through a simplified example to illustrate the merging process. Consider the following three lists of facts, which are drawn from different retellings of our example story:  This is then merged with the second story. The first fact of Story 1, come(child), matches exactly with the fourth fact of the Story 2; the fifth fact matches inexactly with the fourth fact of the Story 2, and so on. The resulting WMS is:  We then proceed to merge all the automatically extracted knowledge representations of the three stories. To create the output merged story, those predicates with a score of 1 are ignored. The others are each merged to produce a single predicate. For example, ([3] come(child), come(child), come(giant)) becomes come(child): giant does not match with any other argument and is dropped. ([2] yell(child), bellow(child,anger,giant)) becomes yell(child) because yell is a subclass of bellow, and thus preferred, and child is the only argument that has a match in both facts. Thus the resulting merged story is: come(child), play(garden), visit(friend), yell(child), be(giant) It is clear from this example that our current approach is, at times, naive. For example, the decisions about which arguments to include in output facts, and how to order facts that are unmatched in working merged stories could be made significantly more effective. We view this current system as a proof of concept that such an approach can be useful; we certainly do not consider the system to be complete approach to the problem. Further work on the system would result in improved performance. null</Paragraph>
  </Section>
  <Section position="6" start_page="0" end_page="0" type="metho">
    <SectionTitle>
5 Extracting Ontological Information
from WordNet
</SectionTitle>
    <Paragraph position="0"> In order to perform some of the tasks involved in merging and matching, it is necessary to have information about how words are related. We extract this information from WordNet by getting the ontology refinement engine to call WordNet with a word and retrieve both its synset (i.e., synomym set) and its hyponyms and hypernyms. We collect these for every sense of the word, since our natural language pipeline currently does not include word-sense disambiguation. When it is necessary during the merging process to obtain information about whether two words are related (i.e., when two words do not match exactly), we extract synonym and hyper/hyponym information from WordNet for these words and examine it to discover whether an exact match exists or not. We treat synonyms as equivalent, and we treat hypernym and hyponym synsets as the super- and sub-type of a word respectively, and then traverse the type hierarchy for exact matches. To avoid spurious equivalence we use a bound to restrict the search, and from our experience a bound of two type-levels in either direction and a stop-list of 'upper ontology' types yields good results.</Paragraph>
  </Section>
  <Section position="7" start_page="0" end_page="0" type="metho">
    <SectionTitle>
6 Related Work
</SectionTitle>
    <Paragraph position="0"> This work breaks some new ground by being the first to use dynamic refinement to compare and merge information from natural language texts. In general, recent work in natural language processing has currently relied heavily on 'purely statistical' methods for tasks such as text similarity and 39 KRAQ06 summarization. However, there is also a rich logical tradition in linguistic semantics, and work in this vein can bring the two closer together.</Paragraph>
    <Paragraph position="1"> Current work in story understanding is focusing on the use of logical forms, yet these are not extracted from text automatically (Mueller, 2003).</Paragraph>
    <Paragraph position="2"> The natural language processing and story conversion pipeline are improvements over a pipeline that was shown to successfully compare stories in a manner similar to a teacher (Halpin et al., 2004).</Paragraph>
    <Paragraph position="3"> The merging task is a more logic-based approach than similar techniques like information fusion used in multi-document summarization (Barzilay et al., 1999). Our approach has some features in common with (Wan and Dale, 2001), however, we have chosen to focus exclusively on merger at the semantic level, rather than trying to also incorporate syntactic structure.</Paragraph>
    <Paragraph position="4"> There has also been a revival in using weighted logical forms in structured relational learning, such as Markov Logic Networks (Domingos and Kok, 2005), and this is related to the scoring of facts used by the current system in merging texts. As mentioned at the beginning of this paper, the conversion of unrestricted text to some logical form has experienced a recent revival recently (Bos et al., 2004). Although our approach deliberately ignores much semantic detail, this may be compensated for by increased robustness due to the reliance on finite-state methods for semantic translation and chunking.</Paragraph>
  </Section>
  <Section position="8" start_page="0" end_page="0" type="metho">
    <SectionTitle>
7 Further Work
</SectionTitle>
    <Paragraph position="0"> The work we have done thus far suggests many avenues for further work. One obvious improvement would be to enable the system to deal with more complex input, so that stories could be represented with nested predicates and with a more complex notion of time. Time can be conceived of ontologically in a number of differing manners with highly differing properties, and relating these notions of time to the extraction of tense (which the lxtransduce-based chunker currently does automatically) would be a fruitful task (Hayes, 1996). Making decisions about what to include in a merged story is currently done in a fairly naive manner. Further research into what constituted a good merged story and under what circumstances it is advantageous to be sceptical or generous as to what should be included in the merged story, would allow this to become much more effective. Once the system has been suitably improved, it should be tested on a more complex domain, such as news stories. Finally, the primary benefit of the use of knowledge representation is the possibility of using inference.</Paragraph>
    <Paragraph position="1"> The current system could easily take advantage of an external knowledge-base of domain-specific facts and rules to aid refinement and merging.</Paragraph>
    <Paragraph position="2"> We have not implemented a baseline for the system using purely word-based statistical features, such as reducing the words to the their morphological stem and then using WordNet synsets to compare the stories without any predicate structure. This is because at this stage in development the extraction of the correct clauses is itself the goal of the task. If connected to larger system, comparison with a purely statistical model would be useful. However, we would hazard a guess that in the domain of computational story understanding, it is unlikely that purely statistical methods would work well, since stories by their nature consist of events involving the actions of characters in a particular temporal order, and this type of structural complexity would seem to be best accounted for by some structure-preserving features that attempt to model and extract these events explicitly.</Paragraph>
  </Section>
class="xml-element"></Paper>