Type-checking in Formally Non-typed Systems

Software Engineering, Testing, and Quality Assurance for Natural Language Processing, pages 3–4, Columbus, Ohio, USA, June 2008. c⃝2008 Association for Computational Linguistics Type-checking in Formally non-typed Systems Dick Crouch Powerset, Inc. San Francisco, USA crouch@powerset.com Tracy Holloway King Palo Alto Research Center Palo Alto, USA thking@parc.com Abstract Type checking defines and constrains system output and intermediate representations. We report on the advantages of introducing multi- ple levels of type checking in deep parsing sys- tems, even with untyped formalisms. 1 Introduction Some formalisms have type checking as an inherent part of their theory (Copestake (2002)). However, many formalisms do not require type checking. We report on our experiences with a broad-coverage sys- tem for mapping English text into semantic repre- sentations for search applications. This system uses the XLE LFG parser for converting from text to syn- tactic structures and the XLE ordered-rewriting sys- tem to convert from syntax to semantic structures. Neither component formally requires type checking. However, type checking was introduced into the syn- tactic parser and at multiple levels in the semantics in response to the engineering requirements on a large- scale, multi-developer, multi-site system. 2 Syntactic Typing The syntactic parser outputs a tree and an attribute value matrix (f(unctional)-structure). Meaning- sensitive applications use the f-structure which contains predicate argument relations and other semantically relevant dependencies. A feature declaration (FD) requires every f- structure attribute to be declared with its possible values. These values are typed as to whether they are atomic or are embedded f-structures. (1) shows the FD for NUM(ber) and SPEC(ifier). NUM takes an atomic value, while SPEC takes an f-structure containing the features ADJUNCT, AQUANT, etc. (1) a. NUM: - b. SPEC: -$ pl sg . [ADJUNCT AQUANT DET NUMBER POSS QUANT SPEC-TYPE]. XLE supports overlay grammars where a gram- mar for an application uses another grammar as its base. The FDs form part of the overlay system. For example, there is an FD used by the Parallel Gram- mar project (Butt et al. (2003)); the standard English FD adds and modifies features; then domain specific FDs overlay this. (2) gives the number of features in the ParGram FD and the standard English overlay. (2) atomic f-structure English 76 33 ParGram 34 11 The grammar cannot be loaded if there is a feature or value that is not licensed by the FD (to type check the lexicon, the generator is loaded). The command print-unused-feature-declarations can be used after a large parse run to determine which features never surfaced in the analysis of the corpus and hence might be candidates to be removed from the grammar. As LFG does not have type checking as part of its theory (Dalrymple et al. (2004)), XLE originally did not implement it. However, in grammar engineering, type checking over features speeds up the develop- ment process and informs later processes and appli- cations what features to expect since the FD serves as an overview of the output of the grammar. 3 3 Semantic Typing The syntactic output is …

Content truncated to 500 words