ParisDefeasibleConstraints

LKB defeasible constraints:

same-local-by-default-lex-rule := lex-rule &
  [ SYNSEM.LOCAL [ CAT /l #cat,
                   AGR /l #cont,
                   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 had to implement it from scratch, so I mirrored what it did in 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...? And then we can look....