Default Inheritance in Constraint-based Frameworks Christof Rumpf Heinrich-Heine-Universität...
-
date post
18-Dec-2015 -
Category
Documents
-
view
217 -
download
0
Transcript of Default Inheritance in Constraint-based Frameworks Christof Rumpf Heinrich-Heine-Universität...
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
17.01.03 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
17.01.03 Default Inheritance 4
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, ...
17.01.03 Default Inheritance 6
Levels for Inheritance Mechanisms
• static type signature
• type constraints
• macros
• relational constrains
• lexical rules
17.01.03 Default Inheritance 7
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
17.01.03 Default Inheritance 8
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
17.01.03 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)
17.01.03 Default Inheritance 10
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)
17.01.03 Default Inheritance 11
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?
17.01.03 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
17.01.03 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)
17.01.03 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.
17.01.03 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
17.01.03 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).
17.01.03 Default Inheritance 18
Notation
• there is no homogeneous notation– top, bottom – subsumption – unification– default-Unification
• nonkommutative
vs. •vs.ð ô ñ õ
vs.ó ò
A B B Aó ó< <
Á
vs.ó ò< <
17.01.03 Default Inheritance 19
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
17.01.03 Default Inheritance 20
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?
17.01.03 Default Inheritance 21
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
17.01.03 Default Inheritance 22
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
17.01.03 Default Inheritance 23
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
•
17.01.03 Default Inheritance 24
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
17.01.03 Default Inheritance 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
17.01.03 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
17.01.03 Default Inheritance 28
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
17.01.03 Default Inheritance 29
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
17.01.03 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.