Linguistics 187/287 Week 2 Engineering and Linguistic Generalizations

Homework: –Due Friday »Can discuss in class or via or ask us for office hours –Last assignment: »How much time? »Trouble: access, procedure? »Issues: XLE, LFG, grammar?

Topics for this week Notation in LFG (more background) Templates Lexical rules Configurations Feature declaration Metarulemacro

Grammar engineering for deep processing Draws on theoretical linguistics, software engineering –Theoretical linguistics => papers »Generalizations, universality, idealization (competence) –Software engineering => programs »Coverage, interface, QA, maintainability, efficiency, practicality Grammar engineering –Grammar::Theory = Program::Programming language –Reflect linguistic generalizations –Respect special cases of ordinary language –Deal with large-scale interactions –Theory/practice trade-offs

Grammar Engineering and Linguistic Theory Description vs. representation –Program vs. data Expressiveness of notation –Regular predicates for c-structure –Boolean combinations (esp. disjunction) –Equality, set-membership Defaults and marking conventions –Constraining vs. defining, existentials, defaults Abbreviation and factoring –Templates, macros, lexical rules Configuration management –Combining rules, templates, lexicons… –Priority of core/specializations/extensions

Description vs. Representation Complexity trades (program vs. data) –Simplify descriptions but complicate representations –Complicate descriptions but simplify representations Example: Arguments and adjuncts –Different behavior »Arguments selected by predicate, unique »Adjuncts modify predicate, multiple instances –Similar behavior: Can both be questioned –Representation solution (HPSG) ARG ADJ DEP = ARG  ADJ (new type) –Description solution (LFG) ARG ADJ ARG | ADJ

Description vs. Representation External constraints on representation –Linguistic theory –Applications –Multilingual/cross-grammar similarity

Expressiveness of notation Regular predicates for c-structure NP --> (Det) N optionality NP --> N NP --> Det N NP --> { N | Pron} disjunctionNP --> N NP -> Pron NP --> N NP --> Det N NP --> Pron NP --> { (Det) N | Pron } Simple context-free rulesCompact notation

Expressiveness of notation and Representation Equality: attribute values Set-membership: sets and elements –Adjuncts: PP: (^ ADJUNCT)=! PP*: ! $ (^ ADJUNCT) –Coordination (more next week) NP --> NP: ! $ ^; CONJ NP: ! $ ^. Semantic forms –(^ PRED)=‘kick ’ –Semantic relations, instantiation, subcategorization

Defaults and Marking Conventions Constraining vs. defining –Must be assigned nom: (^ SUBJ CASE)=c nom –Is nom: (^ SUBJ CASE)=nom Existentials –Must have case: (^ CASE) Defaults –NTYPE proper pronoun common –{ (^ NTYPE) (^ NTYPE)~=common | (^ NTYPE)=common } (make choices disjoint)

Abbreviations and Factoring Templates –Capture generalizations of annotations –Maintainability: changes, mistakes –Compare: HPSG type hierarchy Macros –Capture generalizations of rules Lexical Rules –Theoretical proposal to manipulate predicates –Implemented to expand lexicons consistently

Example: The verb bakes Belongs to several classes –Third-person, singular, present-tense verb –Transitive or intransitive Shares –Some properties with falls –Other properties with cooked

The lexicon à la Kiparsky A dumping ground for exceptions “A kind of appendix to the grammar, whose function is to list what is unpredictable and irregular about the words of a language”

The lexicon à la Bresnan A repository of linguistic generalizations Active and passive forms are related by lexical rules, not syntactic transformations (^ SUBJ)  (^ OBL-AG) (^ OBJ)  (^ SUBJ) Rules relating lexical items are a prime locus of syntactic generalizations

The lexicon à la Flickinger A hierarchical structure of classes Each class represents some piece of syntactic information bakes belongs to: –the third-person singular present-tense class (like appears) –the transitive/intransitive class (like cooked) –and others Classes may be subclasses of other classes Classes may partition other classes along several dimensions

LFG: Relations between descriptions LFG functional description is a collection of equations These can be named This name can stand for those equations in linguistic descriptions Named descriptions are referred to as templates Interpretation: Simple substitution Template-description is substituted for template-name that appears in (is invoked by) another description LFG can encode linguistic generalizations as relations between descriptions of structures

3SG and P RESENT templates 3SG = (^ SUBJ PERSON ) = 3 (^ SUBJ NUM ) = SG. “ 3SG names (^ SUBJ PERSON )=3 (^ SUBJ NUM )= SG” P RESENT = (^ TENSE ) = marks invocation (in lexicon, rules, templates) Substitute (^ TENSE)=PRES RESENT in other descriptions

Templates enable hierarchical generalizations Template definitions can refer to other templates by name –E.g. further divide 3SG into: 3P ERS = (^ SUBJ PERSON ) = 3. S ING = (^ SUBJ NUM ) = SG. then 3SG ING. Hierarchy of references represents inclusion hierarchy of named descriptions Frequently repeated subdescriptions –specified in one place –effective in many

Hierarchy of template invocations Sharing in verb agreement P RES 3SG P RESENT 3SG S ING 3P ERS P RES N OT 3SG P RES N OT 3SG RESENT. ⇒ ~ PERS ] ⇒ ~ [(^ SUBJ NUM)=SG (^ SUBJ PERS=3 ] Boolean combinations of template references (just like ordinary descriptions) Sharing is distinct from mode of combination

Functional description for bakes {(^ PRED )=‘bake ’ | (^ PRED )=‘bake ’ } (^ TENSE ) =PRES (^ SUBJ PERS )=3 (^ SUBJ NUM ) =SG With agreement template: { (^ PRED )=‘bake ’ | (^ PRED )=‘bake ’ RES 3SG Agreement template invoked by other verbs

Templates with parameters: Valency T RANS - OR -I NTRANS (_p) = { (^ PRED) = ‘_p ’ | (^ PRED) = ‘_p ’ }. PRED value as a parameter of the RANS - OR -I NTRANS (bake) ⇒ { (^ PRED) = ‘bake ’ | (^ PRED) = ‘bake ’ } Arguments can substitute for any part of an f-description –Attributes –Values –Semantic relation-names –Descriptions Pargram convention: Parameters begin with _

Valency hierarchy T RANS - OR -I NTRANS (p) = NTRANSITIVE (p) RANSITIVE (p) }. I NTRANSITIVE (p) = (^ PRED )=‘p T RANSITIVE (p) = (^ PRED )=‘p ’. T RANS - OR - INTRANS I NTRANSITIVE T RANSITIVE

Templates and generalizations: bakes RANS - OR - INTRANS RES 3SG T RANS - OR -I NTRANS (p): shared by eat, cooked,… P RES 3SG: shared by appears, goes, cooks,… P RESENT : –used by P RES 3SG template –shared by bake, laugh, etc.

Lexical sharing T RANS - OR - INTRANS I NTRANSITIVE T RANSITIVE P RES 3SG P RESENT 3SG 3P ERS S ING bakescookedfalls

Type hierarchy vs. templates Templates can play the same role as hierarchical type systems in theories like HPSG A notational device for factoring descriptions –Interpreted as simple substitution –Not part of a formal ontology –Do not require an elaborate mathematical characterization

Templates also invoked by Rules Rule annotations can also call templates –Global changes, typo prevention Example: adjunct annotation PP: ! $ (^ ADJUNCT) (! ADJ-TYPE)=VP ADVP: ! $ (^ ADJUNCT) (! ADJ-TYPE)=VP ADJ(_T) = ! $ (^ ADJUNCT) (! ADJ-TYPE)=_T. VP) NP) VP) S)

Templates: Rules Example: null pronouns Push it! They left (in order) to be on time. NULL-PRON(_P) = (_P PRED)=‘pro’ (_P PRON-TYPE)=null. VPimp --> (^ SUBJ)). VPimp --> VP: (^ SUBJ PRED)=‘pro’ (^ SUBJ PRON-TYPE)=null.

Templates: Extend notation DEFAULT(D V) = { D D~=V | D=V }. (^ NTYPE) common) IF(P1 P2) = { ~P1 | P2 } IFF(P1 P2) = { P1 P2 | ~P1 ~P2 }.

Templates and “Principles” Subject principle: every verb has a subject. Implementaton: VERB = (^ SUBJ). in every verbal entry. or in the templates called by the verbal entries.

Lexical Rules Theoretical construct Templates can often achieve the same result –Disjunction of several templates –Parameterization of a complex template

Lexical Rules: Example Active: They ate the cake. (^ PRED)=‘eat ' Passive: The cake was eaten. (^ PRED)='eat ' Could have VTRANS have two disjuncts Or: manipulate PRED with lexical rule

Lexical Rules: Example Passive lexical rule _SCHEMA is a subcategorization frame PASSIVE(_SCHEMA) = { _SCHEMA (^ PASSIVE)=- | _SCHEMA (^ SUBJ) --> NULL (^ OBJ) --> (^ SUBJ) (^ PASSIVE)=c +}. Example calls –TRANS(_P) (^ PRED)='_P '). –DITRANS(_P) (^ PRED)='_P ').

Lexical Rules: Summary Lexical rules manipulate arguments of predicates –capture systematic alternations like active-passive Rename and remove roles No good implementation for adding roles –causative –complex predicates –benefactives

Configuration Management Combining rules, templates, lexicons, … –System needs to know where everything is –For large grammars, need modularization (multiple grammar rule files, multiple lexicons) Priority of core/specializations/extentions –Want to specialize a grammar »No questions in instruction manuals »Loosen subj-V agreement –Have lexicons of varying quality

Combining Rules, Templates, Lexicons XLE: configuration section –Specify what files are called –Specify which rule, template, and lexicon sections are used RULES (TOY ENGLISH). RULES (CORE ENGLISH) (SPECIAL ENGLISH). –Other grammar information

Configurations and Declarations Configurations –File management –Priority Declarations –Governable relations and semantics –Features Global Operators –METARULEMACRO

Files Priority ordered; rules/entries in later files override those in earlier ones Example: FILES standard-english-rules.lfg eureka-english-rules.lfg standard-english-lexicon.lfg eureka-english-lexicon.lfg.

Eureka vs. Standard rules STANDARD ENGLISH RULES (1.0) N --> NOUN-COMMON -> … NOUN-PROPER -> … EUREKA ENGLISH RULES (1.0) N --> | N PL }. NOUN-EUREKA --> { EUR-PART | EUR-NUM }.

Sections Used All lexicon, rule, and template sections have names and versions*. These are called in priority order in the config. Use with the file order to create overrides. RULES (STANDARD RULES) (EUREKA RULES). LEXENTRIES (all all). *Versions allow for future XLE upgrades

Multiple Lexicon Sections LEXENTRIES (AUTOMATIC ENGLISH) (CORRECTED ENGLISH). AUTOMATIC ENGLISH LEXICON (1.0) appear V XLE appear) appear)}. CORRECTED ENGLISH LEXICON (1.0) appear V XLE appear) appear)}.

Other Configuration Information ROOTCAT: default top level category –Standard: ROOT, Eureka: FIELD Nondistributives for coordination External attributes for applications Character encoding Reparse category and Optimality order for robustness See XLE documentation for complete list

Declarations Must declare grammatical and semantic functions for each grammar. –Used for completeness and coherence GOVERNABLERELATIONS –Functions (features) that must be subcategorized for in the PRED –SUBJ OBJ OBL-?* ?COMP etc. SEMANTICFUNCTIONS –Functions that must have a PRED –ADJUNCT NMOD

Feature Declaration List of all the features –GGF and semantic functions need not be listed –all other features must be listed List of their possible values –atomic –f-structure Multiple feature declarations –multilingual setting –grammar specialization

Why a feature declaration? Good engineering practice Catch typos and old analyses Grammar easier to read NB: Theory doesn’t have typos

Declaration format STANDARD LANGUAGE FEATURES (1.0) feature1: -> $ { val1 val2 val3 }. feature2: -> $ {val4 val 5 }. feature3: -> << [ feature1 feature2 ]. feature

Sample feature declaration TOY ENGLISH FEATURES (1.0) NUM: -> $ { sg pl }. PERS: -> $ { }. TNS-ASP: -> << [ TENSE MOOD ASPECT ]. TENSE. MOOD: -> $ { indicative subjunctive }. ASPECT: -> << [ PERF PROG ]. PERF: -> $ { + - }. PROG: -> $ {+ - }.

XLE and the feature declaration XLE will not load a grammar with a violation of the feature declaration. To catch violations in the lexicon, the generator must be loaded. –regenerate “some-sentence-to-parse” –parse, then choose “generate” in f-str window –create-generator grammar-name.lfg print-unused-feature-declarations

Multiple feature declarations List in priority order in the configuration –FEATURES (STANDARD COMMON) (STANDARD ENGLISH). –New features are listed as usual –Changes to features use edit operators + add a new value & intersect the values ! replace the feature entirely

Multiple feature declarations STANDARD COMMON FEATURES (1.0) NUM: -> $ { sg pl dual }. CASE: -> $ { nom acc }. TENSE: -> << [ PAST FUTURE ]. PAST: -> $ { + - }. FUTURE: -> $ { + - }. STANDARD ENGLISH FEATURES (1.0) PERS: -> $ { }. PERS: -> $ { }. &NUM: -> $ { sg pl }. NUM: -> $ { sg pl }. +CASE: -> $ { gen }. CASE: -> $ { nom acc gen }. !TENSE: -> $ { pres past fut }. TENSE: -> $ {pres past fut }. !PAST: -> $ { }. !FUTURE: -> $ { }.

Using Multiple Feature Decl. Multilingual contexts –Language universal features –Customize to particular language Grammar specialization –Add new features for odd constructions –Remove unused choices

Global Operations: METARULEMACRO System defined function –Operates on every category Global statements –Linguistic: subject condition SUBJ < OBJ coordination –Engineering: quotes bracketing

METARULEMACRO Right-hand side of each grammar rule is the result of applying the macro to the rule METARULEMACRO(_CAT _BASECAT _RHS) = _RHS.

Punctuation and METARULEMACRO Surround any constituent with quotes METARULEMACRO( _CAT _BASECAT _RHS) = { _RHS | L-QT _CAT R-QT |L-DQT _CAT R-DQT}.

Punctuation cont. `Mary and John’ left them there. We saw them “in the garden”. They `appeared and then disappeared.' NP L-QTNPR-QT CONJNP MaryandJohn

Punctuation: Problem Vacuous branching results in many analyses NP Nzero N bagels NP NPzero Nzero N bagels L-QTR-QT NP NPzero N N bagels L-QTR-QT etc.

Solution: PUSHUP If non-branching, push up to highest node. METARULEMACRO(_CAT _BASECAT _RHS) = { _RHS | L-QT R-QT }. How to define PUSHUP? –Need to test existence of sister nodes: * MOTHER SISTER PUSHUP = { (* MOTHER LEFT_SISTER) |(* MOTHER RIGHT_SISTER) ~(* MOTHER LEFT_SISTER) |~(* MOTHER MOTHER) }.

Summary Lexical rules allow for generalizations over predicate alternations Configurations and declarations allow management of large-scale grammars –readability and consistency –maintenance –specialization Global operators allow for cross-grammar generalizations –coordination

The HPSG lexicon: a type hierarchy More specific types inherit information from less specific Types and subtypes: –A mathematical relation between structures: AND/OR lattice –Different subtypes represent alternatives/disjunction –Multiple supertypes represent conjunction … but type inheritance is not the only (best?) way to express generalizations LFG does not use typed feature structures for lexical generalizations head noun relational c-noun gerundverb AND OR (Malouf)

Coordination without METARULEMACRO Want to coordinate any constituent Coordination macro SCCOORD(_CAT) = [ _CAT: ! $ ^; COMMA]* _CAT: ! $ ^; CONJ _CAT: ! $ ^. Put call in each rule: NP: { (DET) AP* N PP* NP)}. Engineering problem: –forget to call –put in wrong category

Coordination with METARULEMACRO Call SCCOORD as part of MRM METARULEMACRO(_CAT _BASECAT _RHS) = { _RHS _CAT)}. NP rule now: NP: (DET) AP* N PP*. Effectively: NP: { (DET) AP* N PP* NP}.