Default Inheritance in Constraint-based Frameworks Christof Rumpf Heinrich-Heine-Universität Düsseldorf January 17, 2003 rumpf/talks/DefaultInheritance.pdf.

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

17.01.03 Default Inheritance 2

Overview

• motivation

• monotonic inheritance

• nonmonotonic unification

• nonmonotonic inheritance


Motivation

• for inheritance– compact representations (elimin. redundancies)– modelling of relations and generalizations

• for default inheritance– systematic modelling of regularities,

subregularities, and irregularities


Tweety

bird

eagle penguincan fly can not fly

bird

eagle penguin

can fly

can not fly

monotonic

nonmonotonic

no information at all

conflict resolution necessary

arbitraryalternants

Monotonic Inheritance in Constraint-based Frameworks

PATR, ALE, CUF, QType, ...

GPSG, HPSG, LFG, UCG, ...


Levels for Inheritance Mechanisms

• static type signature

• type constraints

• macros

• relational constrains

• lexical rules


Typical Static Type Signatures

• two sets: – types T– features F

• two relations: – immediate subtype

T 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


Inheritance in a Type Signature

top > a, b, x, y < f:top.

a > c < g:x. b > c < g:y, f:x. x > z. y > z. z < h:top.

top:ftop

x :gtop:f

a

c

f:x

zg:

h:top

y:gx:f

b

subtype

appropriateness

multipleinheritance

weak relation to DATR: N1:<> == N2modulo othogonal inheritance


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)


Persistent Local Coindexation

a < f:x, g:x.

a constr f:Var & g:Var.

x:gx:f

a

1:g

x1:f

a

token identity

type identity

subtype

type constraint

weak relation to DATR: N1:P1 == P2(only monotonic)


Nonlocal Coindexation

a constr f:Var & @true(b & h:Var). type constraint

true(top) ::= top. relational constraint

a

f: 1

g:y

b

h: 1 x

g:z

x y z

top

like a nonpersistent copying operation

weak relation to DATR: N1:P1 == N2:P2(only monotonic)

orthogonal?


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


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)


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.


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


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 Unification

Bouma, Carpenter, Lascarides, Copestake, Briscoe, ...


Notation

• there is no homogeneous notation– top, bottom – subsumption – unification– default-Unification

• nonkommutative

vs. •vs.ð ô ñ õ

vs.ó ò

A B B Aó ó< <

Á

vs.ó ò< <


Credulous Default Unification

where t´ t:

t´ t´t t´

F:a F: 1 b F:a , F: 1 a

G: G:bG: 1 G: 1

ð t

ó•

c

<

nondefault default nondeterministic result

Lascarides/Copestake 1999


Sceptical Default Unification

s

s

F: F:F:aG: G:b G:H: H:c H:c

F: bF:a F:aG: G: G:H: H:c H

1 1

1 1

1

1:c

ò

ò

<

<

nondefault default deterministic result

Erjavec1998

b?


Nonassoziative Operation

Lascarides/Copestake1999

a b ó

a c óc

c b ó

F:c F:a F: F: c

G:c G

1

:b G: G

1

1 1:

ó ó< <

F:c F:a F: F:c

G:c G:b G:cG

1

1:

ó ó< <

nd d

nd d

nd d

nd d


Criteria for Default Unification

• 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.

Lascarides et al. 1996


YetAnotherDefaultUnification

(Lascarides/Copestake 1999)

: : 1 : 1/ , , ,

: 2 : 1 : 1

: 2

verb

PAST PAST PASTverb verb

PASTP PASTP PASSP

PASSP

•

/ : ,:

regverbPAST ed regverb

PAST

•

/ : ,:

pst t verbPAST t pst t verb

PAST

•


YADU Inheritance

(Lascarides/Copestake 1999)

: : 1 : 1/ , , ,

: 2 : 1 : 1

: 2

verb

PAST PAST PASTverb verb

PASTP PASTP PASSP

PASSP

•

: 1 : 1: , , , ,

/ : 1 : 1: 2

: ,: 2

regverbPAST PAST

PAST verb verbPASTP PASSP

PASTPPAST ed regverb

PASSP

•

: 1 : 1: , , , ,

/ : 1 : 1: 2

: , , : ,: 2

pst t verbPAST PAST

PAST verb verbPASTP PASSP

PASTPPAST ed regverb PAST t pst t verb

PASSP

•

: 1

: 1

: 1

verb

PAST

PASTP

PASSP

: 1

: 1

: 1

regverb

PAST ed

PASTP

PASSP

: 1

: 1

: 1

pst t verb

PAST t

PASTP

PASSP

Nonmonotonic Type Signatures

Subrelex: Modelling Subregularitiesin the Lexikon (SFB 282 Project)

QType: A Grammar Developement Environment with Nonmonotonic Inheritance in the Type Signature


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


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


Subrelex Inheritance

regular

variant1 variant2 variantn

subregular1 subregular2 .....

subregulari irregular1 irregular2

transformation in monotonic inheritance network through insertion of additional types

some ad hoc type signature

leaves

monotonic

inheritance

nonmonotonic

inheritance


Transformation of Nonmonotonic to Monotonic Signatures

1:

1:

1:

PASSP

PASTP

edPAST

verb

tPASTverbtpst

:

1:

1:

1:

/

PASSP

PASTP

PAST

verbtpstverb

edPASTverb

:

tPASTverbtpst

:

nonmonotonic monotonic

generalization of verb and pst-t-verb


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 in Constraint-based Frameworks Christof Rumpf Heinrich-Heine-Universität Düsseldorf January 17, 2003 rumpf/talks/DefaultInheritance.pdf.

Documents

othogonal inheritance

monotonic slide

type hierarchy

type constraint truetop

description language

default inheritance13

default inheritance6

constr f