1 / 30

Default Inheritance in Constraint-based Frameworks

Default Inheritance in Constraint-based Frameworks. Christof Rumpf Heinrich-Heine-Universität Düsseldorf January 17, 2003 http://www.phil-fak.uni-duesseldorf.de/~rumpf/talks/DefaultInheritance.pdf. Overview. motivation monotonic inheritance nonmonotonic unification

perry
Download Presentation

Default Inheritance in Constraint-based Frameworks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Default Inheritance in Constraint-based Frameworks Christof Rumpf Heinrich-Heine-Universität Düsseldorf January 17, 2003 http://www.phil-fak.uni-duesseldorf.de/~rumpf/talks/DefaultInheritance.pdf

  2. Overview • motivation • monotonic inheritance • nonmonotonic unification • nonmonotonic inheritance Default Inheritance

  3. Motivation • for inheritance • compact representations (elimin. redundancies) • modelling of relations and generalizations • for default inheritance • systematic modelling of regularities, subregularities, and irregularities Default Inheritance

  4. Tweety bird no information at all monotonic eagle penguin arbitraryalternants can fly can not fly bird can fly nonmonotonic conflict resolution necessary eagle penguin can not fly Default Inheritance

  5. Monotonic Inheritance in Constraint-based Frameworks PATR, ALE, CUF, QType, ... GPSG, HPSG, LFG, UCG, ...

  6. Levels for Inheritance Mechanisms • static type signature • type constraints • macros • relational constrains • lexical rules Default Inheritance

  7. two sets: types T features F two relations: immediate subtypeT  T, azyclic appropriateness, without polyfeatures a partial functionF  T  T multiple inheritance of feature/value-pairs via subtype relation and unification type clashes possible no coindexation, since there are no variables in the description language Typical Static Type Signatures Default Inheritance

  8. top > a, b, x, y < f:top. a > c < g:x. b > c < g:y, f:x. x > z. y > z. z < h:top. Inheritance in a Type Signature subtype multipleinheritance weak relation to DATR: N1:<> == N2modulo othogonal inheritance appropriateness Default Inheritance

  9. Type Constraints • they add information to the types in a static type signature • their description language can be a feature logic with • variables  coindexation • disjunction nondeterminism • negation nondeterminism • recursion disables offline computability Descr (FSs) Default Inheritance

  10. a < f:x, g:x. a constr f:Var & g:Var. Persistent Local Coindexation subtype type identity type constraint token identity weak relation to DATR: N1:P1 == P2(only monotonic) Default Inheritance

  11. a constr f:Var & @true(b & h:Var). type constraint true(top) ::= top. relational constraint Nonlocal Coindexation top weak relation to DATR: N1:P1 == N2:P2(only monotonic) x y z like a nonpersistent copying operation orthogonal? Default Inheritance

  12. Inheritance with Type Constraints • type constraints • rely on the type hierarchy - they can not be named and therefore not build an additional hierarchy (like macros) • add information to the signature that is inherited top down • can introduce a kind of ‚orthogonal‘ inheritance Default Inheritance

  13. Macros • are abbreviations for feature logic expressions • can be named and create independent inheritance hierarchies • do not add anything new to the signature • can be used to refine and extend the classes of objects defined in the signature beyond the signature (creating new instances) Default Inheritance

  14. Relational Constraints • define a general CLP language over feature logic expressions (definite clauses). • are an extension of macros with recursion and, perhaps control operators like cut or negation by failure. • might be used within type constraints. • can not be computed offline in general. Default Inheritance

  15. Lexical Rules • build binary relations in the lexicon • Input • Output • help to avoid redundancies and express systematic relationships between lexical entries • desire nonmonotonic unification • copying of compatible input information into the output (no commutativity required) feature logic expressions that match/define lexical entries Default Inheritance

  16. Inheritance with Lexical Rules • Lexical rules establish two kinds of inheritance • Immediate inheritance between lexical entries that match the input/output specifications of a specific lexical rule (normally nonmonotonic inheritance). • Lexial rules define another implicit inheritance hierarchy: the output of one rule might unify with the input of another rule (normally monotonic inheritance). • Lexical rules can be replaced by relational constraints (Krieger 94, Bouma 96). Default Inheritance

  17. Default Unification Bouma, Carpenter, Lascarides, Copestake, Briscoe, ...

  18. Notation • there is no homogeneous notation • top, bottom • subsumption • unification • default-Unification • nonkommutative Default Inheritance

  19. Credulous Default Unification nondefault default nondeterministic result Lascarides/Copestake 1999 Default Inheritance

  20. Sceptical Default Unification Erjavec 1998 b? nondefault default deterministic result Default Inheritance

  21. Nonassoziative Operation nd d nd d nd d nd d Lascarides/Copestake1999 Default Inheritance

  22. Criteria for Default Unification Lascarides et al. 1996 • Nondefault information is marked. • DU can not fail. • DU behaves like MU if there is no conflicting information. • DU is deterministic. • DU is commutative und associative. • Defaults are ordered by specificity. Default Inheritance

  23. YetAnotherDefaultUnification (Lascarides/Copestake 1999) Default Inheritance

  24. YADU Inheritance (Lascarides/Copestake 1999) Default Inheritance

  25. Nonmonotonic Type Signatures Subrelex: Modelling Subregularitiesin the Lexikon (SFB 282 Project) QType: A Grammar Developement Environment with Nonmonotonic Inheritance in the Type Signature

  26. Subrelex Goals • nonmonotonic, but declarative representations for regularities, subregularities und irregularities in a constraint-based framework • tractable implementation • formalize and implement empirical linguistic results of other SFB 282 projects • reconstruct relevant NL phenomena treated by the nonmonotonicity community Default Inheritance

  27. Subrelex Methods • use of nonmonotonic inheritance in the type signature • allow type constraints to enrich the expressive power of signatures • transform nonmonotonic signatures to monotonic ones offline • use monotonic signatures and monotonic unification at parsetime Default Inheritance

  28. Subrelex Inheritance regular variant1 variant2 variantn subregular1 subregular2 ..... subregulari irregular1 irregular2 monotonicinheritance some ad hoc type signature transformation in monotonic inheritance network through insertion of additional types nonmonotonicinheritance leaves Default Inheritance

  29. Transformation of Nonmonotonic to Monotonic Signatures generalization of verb and pst-t-verb nonmonotonic monotonic Default Inheritance

  30. Consequences • Nonmonotonicity in the type signature only leads to different considerations concerning grammar development: • Almost all information of relevance would be placed in the type signature. • Other levels of representation (syntax rules, lexical entries, lexical rules) loose some of their importance. Default Inheritance

More Related