<?xml version="1.0" standalone="yes"?>
<Paper uid="W05-1626">
  <Title>Chart generation using production systems</Title>
  <Section position="3" start_page="0" end_page="2" type="metho">
    <SectionTitle>
2 Chart algorithms and production
</SectionTitle>
    <Paragraph position="0"> systems Knowledge-based expert systems consist of rules (or 'productions') and a knowledge base of facts (KB). Rules express logical implications and facts contingent truths. Facts match (possibly partially defined) fact descriptions, or 'conditions', in the antecedent of rules, and if all conditions required in a rule antecedent are satisfied, the consequent follows. In a production system, this means the production is 'activated.' All activated rules are collected in a 'conflict set.' After this, a decision is made about what rule to fire according to the search strategy (breadth-first and depth-first are usually built-in strategies). Processing can be thought of as a sequence of cycles where each cycle is defined as adding one fact to the KB, matching it against the rules, and computing what rules to fire next. This may result in new facts, and a new cycle begins.</Paragraph>
    <Paragraph position="1"> The basic outline of knowledge-based expert systems is similar in spirit to declarative rule systems based on the logic programming paradigm in NLP in which the order of rule execution does not affect the result. The knowledge base serves as a store for proven facts and is hence comparable to the chart data structures in NLP.</Paragraph>
    <Paragraph position="2"> More precisely, the knowledge base corresponds to a passive chart since it only contains completed chart edges. Executing a rule consequent can involve the assertion or retraction of facts to/from the KB. Since a chart is monotonically accumulating, grammar rules only assert new edges in our implementations.</Paragraph>
    <Paragraph position="3"> Another way of thinking about production systems is in terms of a blackboard architecture: the KB serves as a blackboard and rules/productions are triggered by new facts that are added to it.</Paragraph>
    <Paragraph position="4"> Probably the most distinctive property of production systems is the compilation of the productions into a network. The Rete networks of production systems ('rete' is Latin for 'net') exploit structural similarities between rule antecedents by creating a network that allows facts to match antecedents in several rules at once. The idea is to create tests for conditions in rule antecedents and to share the results between rules [Forgy, 1982]. Matching a fact against the Rete network can partially 'activate' a whole set of rules that share that node. This avoids cycling over possibly large numbers of rules in turn and repeatedly matching the same elements.</Paragraph>
    <Paragraph position="5"> Standardly, a forward chaining interpreter is used to execute productions. This corresponds to bottom-up tree traversal algorithms in computational linguistics terminology. The 'conflict resolution strategy' addresses the above mentioned question which of the activated rules should fire. It corresponds to the agenda strategy in chart parsing/generation. The following table relates the terminologies:  productions in grammar rules Rete network working memory/ passive chart knowledge base facts in knowledge base passive edges partially activated active edges productions (inside Rete network) conflict resolution agenda with strategy ordering function Since the partially activated productions are part of the Rete network, they are more difficult to observe in practice than the active edges of a chart. However, production systems such as JESS provide means to inspect the network.</Paragraph>
    <Paragraph position="6"> 3 Case study 1: realization with automatically derived rules The first project involves overgeneration (and ranking) with rules that were extracted from a semantically annotated subset of the Penn Treebank II. The input to the realizer consists of a bag of semantic tags with associated values in the management succession domain, for example PERSON=Piere Vinken, AGE=61 or POST=chairman.  We use structured (or 'unordered') facts of attribute-value pairs to define chart edges. Figure 1 shows a slightly simplified production that, given two facts with heads NP-POST DESCR ADJ and PP-POST NODET generates a new fact with head VP-POST DESCR ADJ:</Paragraph>
    <Paragraph position="8"> This production effectively results in the bottom-up traversal of a local tree. The names of the fact heads combine syntactic and semantic information. The facts have slots such as idx, a unique edge identifier, and deriv, which represents the derivation tree. Slot values are mainly only picked up by variables (prefixed by ? and $?) and passed on to the rule consequent. However, there is an exception: the condition matching the second edge with head PP-POST NODET performs a test in order to prevent combinations of edges that express overlapping semantics, based on semantic indices associated with the attribute-value pairs of the input. These are stored in the consumes slot.</Paragraph>
    <Paragraph position="9"> Typically, the facts matched on the left-hand side of the production shown above provide realizations such as 'the additional post' and 'of chief executive officer.' The newly generated edge combines this into 'was named to the additional post of chief executive officer.' Phonological forms are handled in the terms slot where they are represented in combination with semantic tags, for example 'the [POST DESCR ADJ additional] post.' These  These semantic labels are slightly simplified. For reasons of space we cannot discuss the semantic annotation and rule construction here. See [Varges, 2003] for more details.</Paragraph>
    <Paragraph position="10"> rules/productions encode a phrasal generator with shallow syntax: they only use syntactic categories. However, other simple syntactic features, for example for modeling number/gender/person agreement, could be incorporated by adding the appropriate slots and values.</Paragraph>
    <Paragraph position="11"> The instances slot provides an example of the tight integration of the production system JESS with Java. The slot contains references to Java objects that are relevant to the ranker. Furthermore, combine-instance-tables on the right-hand side of the production is a function call that is simply passed on to the ranker written in Java.</Paragraph>
    <Paragraph position="12"> The left-hand side of the example production also contains a condition that matches a simple unique fact for the name of the rule (phrasal-rule-83). In this way, rules can be dynamically blocked and unblocked. Only those rules are able to fire whose name has been asserted into the KB. Matching the name fact last in the rule antecedent allows the Rete compiler to identify possible common prefixes of match patterns across rules. This would not be possible if a unique match condition was placed first.</Paragraph>
    <Paragraph position="13"> The realizer uses 476 automatically constructed productions. Sharing in the Rete network is mostly limited to the 'pattern network.' In contrast, the 'join network' is not able to reduce the number of match computations substantially because most grammar rules are binary (see [Varges, 2003] for more details). The realizer is capable of generating several hundred sentences within a few seconds. Averaged over 40 inputs taken from a test set, it produced 350 sentences within 5 seconds.</Paragraph>
    <Paragraph position="14">  The second use of a production system for NLG is for a manually written referring expression generator developed in the TUNA  project [Varges, 2004]. Conceptually, it consists of two modules: a reasoner that produces logical forms (descriptions of domain objects) from a domain representation and a realizer for those logical forms. Both modules are interleaved in the sense that the reasoner 'marks' logical forms that it is able to realize, and the domain reasoner is only allowed to combine simpler logical forms into more complex ones if they have been realized successfully. One way to describe this processing architecture is in terms of two interleaved chart algorithms that exchange chart items. The other is in terms of a blackboard architecture - in fact, the KB almost acts as whiteboard [Cahill et al., 1999]. This is particularly intuitive here, and also closer to the implementation: the reasoner automatically responds to the marking of a logical form fact as being realized since productions are activated whenever a matching fact is added to the KB (or changed). In other words, the productions of the modules communicate via the KB.</Paragraph>
    <Paragraph position="15"> The modules of the referring expression generator, i.e. reasoner and realizer, are implemented by means of namespaces for the facts and productions they contain.</Paragraph>
    <Paragraph position="16">  EPSRC grant GR/S13330/01 In addition, we define namespaces for facts representing the domain model and for the lexicon. We show some facts of the domain model since this is the starting point of the computation:  Facts define object types, attribute-values pairs and relations between the objects. In the example above, they describe a musician with black hair holding an instrument. The facts are defined in namespace DOMAIN and are related by means of the indices held in the index and other slots. The use of vertex facts indicates that the representation is inspired by the Graph approach to referring expression generation [Krahmer et al., 2003].</Paragraph>
    <Paragraph position="17"> At the first stage of processing, content determination rules produce logical forms paired with a list containing the vertices of the domain objects they describe:  jects of type 'musician', which is only v1 in our example. The second fact contains the vertices of all objects that are not of type instrument, which again is v1. The facts contain the logical form as a sequence of atoms and strings. However, the fact heads are more important for matching since the logical forms (and many other slot values) are just passed on to the right-hand side.</Paragraph>
    <Paragraph position="18"> Facts can contain slots that are only relevant to their particular type, for example negated for facts with head neq-type-extension.</Paragraph>
    <Paragraph position="19"> The namespace of the realization module is populated with facts that contain syntactic information and surface forms: (REALIZER::np (phon not an instrument) (id 35) (dtr-left 5) (dtr-right 11) (num sing) (pers 3) (form neq-indefinite)) (REALIZER::syntax-semantics-mapping (sem-id 17) (syn-id 35)) The REALIZER::np fact above is the realization of a corresponding description fact in the LF namespace.</Paragraph>
    <Paragraph position="20"> The separate REALIZER::syntax-semantics-mapping fact records which description fact in the LF namespace is realized by which fact in the REALIZER namespace, again by means of indices. An alternative to using a mapping fact is to modify the REALIZER::np fact directly.</Paragraph>
    <Paragraph position="21"> The implementation currently consists of 95 productions and 71 additional functions that are invoked on the right-hand sides of the productions. These functions perform tasks such as counting domain objects and relations between objects, and computing the agenda ordering of the chart generator.</Paragraph>
  </Section>
class="xml-element"></Paper>