File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/97/p97-1050_metho.xml
Size: 14,928 bytes
Last Modified: 2025-10-06 14:14:39
<?xml version="1.0" standalone="yes"?> <Paper uid="P97-1050"> <Title>Efficient Construction of Underspecified Semantics under Massive Ambiguity</Title> <Section position="4" start_page="387" end_page="389" type="metho"> <SectionTitle> ND </SectionTitle> <Paragraph position="0"> that the grammar associates with each local tree a 'semantic rule' that specifies how to construct the mother node's semantics from those of its children.</Paragraph> <Paragraph position="1"> Hence, input to the algorithm is * a parse forest * an associated semantic rule for every local tree (AND-node together with its children) therein * and a semantic representation for each leaf (coming from a semantic lexicon).</Paragraph> <Paragraph position="2"> To be more precise, we assume a constraint language C over a denumerable set of variables X, that is a sublanguage of Predicate Logic with equality and is closed under conjunction, disjunction, and variable renaming. Small greek letters C/, C/ will henceforth denote constraints (open formulae) and letters X, Y, Z (possibly with indeces) will denote variables. Writing C/(X1,..., Xk) shall indicate that X1 .... , Xk are the free variables in the constraint ~. Frequently used examples for constraint languages are the language of equations over first-order terms for DCGs, 4 PATR-style feature-path equations, or typed feature structure description languages (like the constraint languages of ALE (Carpenter 92) or CUF (D6rreDorna 93)) for HPSG-style grammars.</Paragraph> <Paragraph position="3"> Together with the constraint language we require a constraint solver, that checks constraints for satisfiability, usually by transforming them into a normal form (also called 'solved form'). Constraint solving in the DCG case is simply unification of terms.</Paragraph> <Paragraph position="4"> The semantic representations mentioned before are actually not given directly, but rather as a constraint on some variable, thus allowing for partiality in the structural description. To that end we assume that every node in the parse forest u has associated with it a variable Xv that is used for constraining the (partial) semantic structure of u. The semantics of a leaf node # is hence given as a constraint C/,(X,), called a leaf constraint.</Paragraph> <Paragraph position="5"> A final assumption that we adopt concerns the nature of the 'semantic rules'. The process of semantics construction shall be a completely monotonous process of gathering constraints that never leads to failure. We assume that any associated (instantiated) semantic rule r(u) of a local tree (AND-branching) u(ul,...,u~) determines u's semantics Z(u) as follows from those of its children:</Paragraph> <Paragraph position="7"> The constraint Cr(v)(Xv, Xvl,..., X~) is called the rule constraint for ~,. It is required to only depend on the variables X~, X~I,..., X~,. Note that if the same rule is to be applied at another node, we have a different rule constraint.</Paragraph> <Paragraph position="8"> Note that any F,(~,) depends only on Xv and can be thought of as a unary predicate. Now, let us consider semantics construction for a single parse tree for the moment. The leaf constraints together with the rules define a semantics constraint Z(~,) for every node u, and the semantics of the full sentence is described by the T-constraint of the root node, ~,(root). In the T-constraints, we actually can suppress the existential quantifiers by adopting the convention that any variable other than the one of the current node is implicitly existentially bound on the formula toplevel. Name conflicts, that would force variable renaming, cannot occur. Therefore ~(root) is (equivalent to) just a big conjunction of all rule constraints for the inner nodes and all leaf constraints. null Moving to parse forests, the semantics of an OR-node u(~,l,..., uk) is to be defined as</Paragraph> <Paragraph position="10"> sion, Definite Clause Grammars based on pure PROLOC, involving no nonlogical devices like Cut, var/1, etc.</Paragraph> <Paragraph position="11"> specifying that the set of possible (partial) semantic representations for u is the union of those of u's children. However, we can simplify this formula once and for all by assuming that for every OR-node there is only one variable Xu that is associated with it and all of its children. Using the same variable for ul ... uk is unproblematic, because no two of these nodes can ever occur in a tree reading. Hence, the definition we get is ~&quot;\](IJ) : Z(I\]I) V... V Z(lYk).</Paragraph> <Paragraph position="12"> Now, in the same way as in the single-tree case, we can directly &quot;read off&quot; the T-constraint for the whole parse forest representing the semantics of all readings. Although this constraint is only half the way to the packed semantic representation we are aiming at, it is nevertheless worthwhile to consider its structure a little more closely. Fig. 3 shows the structure of the F,-constraint for the OR-node B in the example parse forest.</Paragraph> <Paragraph position="13"> In a way the structure of this constraint directly mirrors the structure of the parse forest. However, by writing out the constraint, we loose the sharings present in the forest. A subformula coming from a shared subtree (as Z(18) in Fig. 3) has to be stated as many times as the subtree appears in an unfolding of the forest graph. In our PP-attachment example the blowup caused by this is in fact exponential.</Paragraph> <Paragraph position="14"> On the other hand, looking at a T-constraint as a piece of syntax, we can represent this piece of syntax in the same manner in which trees are represented in the parse forest, i.e. we can have a representation of Z(root) with a structure isomorphic to the forest's graph structure, s In practice this difference becomes a question of whether we have full control over the representations the constraint solver employs (or any other process that receives this constraint as input).</Paragraph> <Paragraph position="15"> If not, we cannot contend ourselves with the possibility of compact representation of constraints, but rather need a means to enforce this compactness on the constraint level. This means that we have to introduce some form of functional abstraction into the constraint language (or anything equivalent that allows giving names to complex constraints and referencing to them via their names). Therefore we enhance the constraint language as follows. We allow to our disposition a second set of variables, called names, and two special forms of constraints 1. def(<name>, <constraint>) name definition 2. <name> name use with the requirements, that a name may only be used, if it is defined and that its definition is unique. Thus, the constraint Z(B) above can be written as The packed semantic representation as constructed by the method described so far still calls for an obvious improvement. Very often the different branches of disjunctions contain constraints that have large parts in common. However, although these overlaps are efficiently handled on the representational level, they are invisible at the logical level. Hence, what we need is an algorithm that factores out common parts of the constraints on the logical level, pushing disjunctions down. 6 There are two routes that we can take to do this efficiently.</Paragraph> <Paragraph position="16"> In the first we consider only the structure of the parse forest, however ignore the content of (rule or leaf) constraints. I.e. we explore the fact that the parts of the E-constraints in a disjunction that stem from nodes shared by all disjuncts must be identical, and hence can be factored out/ More precisely, we can compute for every node v the set must-occur(v) of nodes (transitively) dominated by v that must occur in a tree of the forest, whenever u occurs. We can then use this information, when building the disjunction E(u) to factor out the constraints introduced by nodes in must-occur(v), i.e., we build the fac-</Paragraph> <Paragraph position="18"> constraint E(ui)\~ for each disjunct.</Paragraph> <Paragraph position="19"> The other route goes one step further and takes into account the content of rule and leaf constraints. For it we need an operation generalise that can be characterised informally as follows.</Paragraph> <Paragraph position="20"> For two satisfiable constraints C/ and ~, generalise(C/, !b) yields the triple ~, C/', ~3', such that ~ contains the 'common part' of C/ and 19 and C/' represents the 'remainder' 6\~ and likewise 19' represents 19\~.</Paragraph> <Paragraph position="21"> 6Actually, in the E(B) example such a factoring makes the use of the name N superfluous. In general, however, use of names is actually necessary to avoid exponentially large constraints. Subtrees may be shared by quite different parts of the structure, not only by disjuncts of the same disjunction. In the PP-attachment example, a compression of the E-constraint to polynomial size cannot be achieved with factoring alone.</Paragraph> <Paragraph position="22"> 7(Maxwell IIIKaplan 93) exploit the same idea for efficiently solving the functional constraints that an LFG grammar associates with a parse forest.</Paragraph> <Paragraph position="23"> The exact definition of what the 'common part' or the 'remainder' shall be, naturally depends on the actual constraint system chosen. For our purpose it is sufficient to require the following properties: If generalise(~. 19) ~-~ (~, ~', ~b'), then ~ IandOf-~ando=~AC/'and~b-=~A~b'. null We shall call such a generalisation operation simplifying if the normal form of ~ is not larger than any of the input constraints' normal form.</Paragraph> <Paragraph position="24"> Example: An example for such a generalisation operation for PROLOG'S constraint system (equations over first-order terms) is the so-called anti-unify operation, the dual of unification, that some PROLOG implementations provide as a library predicate, s Two terms T1 and T2 'anti-unify' to T, iff T is the (unique) most specific term that subsumes both T1 and T2. The 'remainder constraints' in this case are the residual substitutions al and a2 that transform T into T1 or T2, respectively.</Paragraph> <Paragraph position="25"> Let us now state the method informally. We use generalise to factor out the common parts of disjunctions. This is, however, not as trivial as it might appear at first sight. Generalise should operate on solved forms, but when we try to eliminate the names introduced for subtree constraints in order to solve the corresponding constraints, we end up with constraints that are exponential in size. In the following section we describe an algorithm that circumvents this problem.</Paragraph> </Section> <Section position="5" start_page="389" end_page="390" type="metho"> <SectionTitle> 3 The Algorithm </SectionTitle> <Paragraph position="0"> We call an order < on the nodes of a directed acyclic graph G = (N, E) with nodes N and edges E bottom-up, iff whenever (i, j) E E (&quot;i is a predecessor to j&quot;), then j < i.</Paragraph> <Paragraph position="1"> For the sake of simplicity let us assume that any nonterminal node in the parse forest is binary branching. Furthermore, we leave implicit, when conjunctions of constraints are normalised by the constraint solver. Recall that for the generalisation operation it is usually meaningful to operate on Input: * parse'forest, leaf and rule constraints as described above * array of variables X~ indexed by node s.t. if v is a child of OR-node v', then Xv = Xv, Data structures: * an array SEM of constraints and an array D of names, both indexed by node * a stack ENV of def constraints Output: a constraint representing a packed semantic representation Method: ENV := nil process nodes in a bottom-up order doing with node u: if u is a leaf then</Paragraph> <Paragraph position="3"> push def(D\[v\], REM1 A D\[vl\] V REM2 A D\[v2\]) onto ENV end return SEM\[root\] A D\[root\] A ENV solved forms. However, at least the simplifications true A C/ -- C/ and C/ A true =-- C/ should be assumed. The Packed Semantics Construction Algorithm is given in Fig. 4. It enforces the following invariants, which can easily be shown by induction.</Paragraph> <Paragraph position="4"> 1. Every name used has a unique definition. 2. For any node v we have the equivalence ~(v) -SEM\[u\] A \[D\[v\]\], where \[D\[u\]\] shall denote the constraint obtained from D\[v\] when recursively replacing names by the constraints they are bound to in ENV.</Paragraph> <Paragraph position="5"> 3. For any node u the constraint SEM\[v\] is never larger than the ~-constraint of any single tree in the forest originating in u.</Paragraph> <Paragraph position="6"> Hence. the returned constraint correctly represents the semantic representation for all readings.</Paragraph> </Section> <Section position="6" start_page="390" end_page="391" type="metho"> <SectionTitle> 4 Complexity </SectionTitle> <Paragraph position="0"> The complexity of this abstract algorithm depends primarily on the actual constraint system and generalisation operation employed. But note also that the influence of the actual semantic operations prescribed by the grammar can be vast, even for the simplest constraint systems. E.g., we can write a DCGs that produce abnormal large &quot;semantic structures&quot; of sizes growing exponentially with sentence length (for a single reading). For meaningful grammars we expect this size function to be linear. Therefore, let us abstract away this size by employing a function fa(n) that bounds the size of semantic structures (respectively the size of its describing constraint system in normal form) that grammar G assigns to sentences of length n.</Paragraph> <Paragraph position="1"> Finally, we want to assume that generalisation is simplifying and can be performed within a bound of g(m) steps, where m is the total size of the input constraint systems.</Paragraph> <Paragraph position="2"> With these assumptions in place, the time complexity for the algorithm can be estimated to be (n = sentence length, N = number of forest nodes) O(g(fc(n) ) &quot; N) <_ O(g(fa(n) ) . n3), since every program step other than the generalisation operation can be done in constant time per node. Observe that because of Invariant 3. the input constraints to generalise are bounded by fc as any constraint in SEM.</Paragraph> <Paragraph position="3"> In the case of a DCG the generalisation operation is anti_unify, which can be performed in o(n. log(n)) time and space (for acyclic structures). Hence, together with the assumption that the semantic structures the DCG computes can be bounded linearly in sentence length (and are acyclic), we obtain a O(n. log(n). N) < O(n41og(n)) total time complexity.</Paragraph> </Section> class="xml-element"></Paper>