LKB defeasible constraints:

same-local-by-default-lex-rule := lex-rule &
  [ SYNSEM.LOCAL [ CAT /l #cat,
                   AGR /l #agr,
                   CTXT /l #ctxt ],
    C-CONT.HOOK /l #hook,
    DTR.SYNSEM.LOCAL [ CAT /l #cat,
                       CONT.HOOK /l #hook,
                       AGR /l #agr,
                       CTXT /l #ctxt ]].

acc-to-dat-lex-rule := same-local-by-default-lex-rule &
  [ SYNSEM.LOCAL.CAT.VAL.COMPS.FIRST.LOCAL.CAT.HEAD.CASE dat,
    DTR.SYNSEM.LOCAL.CAT.VAL.COMPS.FIRST.LOCAL.CAT.HEAD.CASE acc ].

Result has mother’s SYNSEM.LOCAL.CAT unconstrained except for FIRST..CASE.

Intended result was for the defeasible constraints to be pushed down (as in Sag, Wasow & Bender 2003):

[ SYNSEM.LOCAL [ CAT [ HEAD /l #head,
                       VAL [ SUBJ /l #subj,
                             COMPS [ FIRST [ NON-LOCAL /l #non-loc,
                                             ... ],
                                     REST /l #rest ]]],
                 AGR /l,
                 ... ],
  DTR.SYNSEM.LOCAL [ CAT [ HEAD /l #head,
                           VAL [ SUBJ /l #subj,
                                 COMPS [ FIRST [ NON-LOCAL /l #non-loc,
                                             ... ],
                                         REST /l #rest ]]],
                 AGR /l,
                 ... ].

This would allow us to define lexical rule types that copy up whatever isn’t changed, even without knowing what features a customization system user might decide to add, either in the customization system or later.

Notes from discussion (to be edited!)

Defeasible constraints: at the moment, if one feature is changed: defeasible features around it are lost

Valia: Emily looking from implementation point of view. German passivization with Gertjan van Noord: couldn’t make it work. They excluded one feature from unifying.

Emily: what do you mean? Adding auxiliary lisp files?

Valia: it’s a function…

Emily: ideally, the grammar should be just what is in the .tdl files (without adding lisp files)

Ann: it depends what you want the grammar to do exactly. We could have a special marker, that would state what to do at a specific point. This should be feasible within the LKB (but this depends on the details).

PET: not in flop, but a preprocessing step

Bernd: in PET, I’d have to implement it from scratch, so I’d probably end up mirroring what is done in the LKB.

Dan: fully instantiated for every object: this would not work for bigger grammar, it would be bigger

Emily+Ann: only for lexical rules.

Dan: conscience of Bulgarian grammar which has 260? lex-rules…

Emily: additional annotation, if you are testing, you’d not only have to flop but also do this additional pre-coding step…

Ann: I don’t think the space would be too big an issue, but I’m not sure: test it on smaller grammar

E: Bulgarian

Ann: in no language (unless really rich inflection), you’ll have thousands of rules, except for Mohawk…

E: I do worry about those, but not all rules will take advantage of this: assume most rules are well-behaved, but just have this available for the handful that does it

D: this is providing opium to the people…if it’s there, people will use it.

E: it would only be for lexical rules

Ann: I could even make sure it is only localized to lexical rules

D: is there a real need, better to work around it…

E: for other languages, it is…

D: it is never the case that you can only describe a phenomenon by using defeasible constraints.

A: there is also the issue of maintainability of the grammar (where there’s room for improvement)

S: conclusion: Emily and Ann continue their discussion and look at the formalization of this, and someone understanding defaults looks at the implementation of this, time permitting …? And then we can look….

Last update: 2010-07-04 by StephanOepen [edit]