[developers] Trigger rules still being requested
aac10 at cam.ac.uk
Thu Feb 11 00:00:21 CET 2016
Hmm - does anyone find the TDL output for the trigger rules helpful?
because, having looked at the code, I would prefer to remove that
facility completely unless it has support, since it's hardwiring type
and feature names into the code. i.e., I would rather go back to the
original behaviour which meant that warning messages were output (if
there were no appropriate existing trigger rules) without the TDL being
suggested. I believe oe may feel the same way.
The trigger rule mechanism is a mess, in fact. Learning trigger rules
from parsed/treebanked data is feasible, but too big a project for me
to take on.
On 10/02/2016 18:47, Dan Flickinger wrote:
> Hi Emily -
> I ran into this behavior too when doing the SWB-oriented grammars for
> the grammar engineering course I taught with Tom last quarter. The
> culprit turns out to be the function index-lexicon(), which right at
> its end cheerfully emits those warning/advice messages for all
> semantically empty entries regardless of whether trigger rules have
> been defined. Since the same shortcoming is repeated in the separate
> function reindex-lexicon(), it proved to be easier for me to correct
> this by changing the function make-trigger-tdl() which they both call,
> so that the global mt::*transfer-triggers* is checked before emitting
> the warning for each semantically empty lexical entry. Here is the
> patched version of this function analogous to what I added to my
> grammars' user-fns.lsp file:
> (defun make-trigger-tdl (empty-semantics-lexical-entries)
> (let ((empty-no-trigger-entries
> (loop for id in empty-semantics-lexical-entries
> unless (or #+:mt
> (gethash id mt::*transfer-triggers*)
> collect id)))
> (loop for x in empty-no-trigger-entries
> (format t "~%~%~a_gr := generator_rule &
> [ CONTEXT.RELS <! [ PRED \"non_existing_rel\" ] !>,
> FLAGS.TRIGGER \"~a\" ]."
> (string-downcase x)
> (string-downcase x)))))
> I expect that Ann or Stephan could see a more elegant way to achieve
> this effect, but this patch might be a useful temporary expedient.
> *From:* developers-bounces at emmtee.net <developers-bounces at emmtee.net>
> on behalf of Emily M. Bender <ebender at uw.edu>
> *Sent:* Wednesday, February 10, 2016 7:43 AM
> *To:* developers
> *Subject:* [developers] Trigger rules still being requested
> Dear all,
> In the Matrix derived grammars, we have the following in lkb/script:
> ;;; SSH 2012-03-27 This invokes trigger rules for semantically empty
> ;;; lexical entries. The trigger rules themselves should be in
> ;;; trigger.mtr in the grammar directory. The documentation on trigger
> ;;; rules: http://moin.delph-in.net/LkbGeneration
> ;;; SSH 2013-05-23 The semi.vpm file needs to be loaded *before* the
> ;;; trigger.mtr file in lkb/script for correct interaction.
> (lkb-pathname (parent-directory) "trigger.mtr"))
> "Generation trigger rules"
> :filter nil :task :trigger :recurse nil :edges 200 :subsume nil)
> ;;; Matrix-derived grammars often have stable enough semantic
> ;;; representations that the grammar can usefully be tested
> ;;; by generating from them. The function index-for-generator()
> ;;; must be called for generation to be enabled. In grammars with
> ;;; small lexica, this takes a trivial amount of time. If
> ;;; generation is not being used regularly, and the indexing
> ;;; is taking too long, comment out the following. index-for-generator()
> ;;; can also be run from the expanded LKB top menu, under
> ;;; Generate.
> It is my understanding that (index-for-generator) is what is behind
> the messages
> suggesting trigger rules for semantically empty lexical entries, but
> even though
> we call it after loading the trigger rules, we still get messages such
> as the following:
> Is there something else we're supposed to do so that we only see those
> when an entry truly lacks a trigger rule?
> Emily M. Bender
> Professor, Department of Linguistics
> Check out CLMS on facebook! http://www.facebook.com/uwclma
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the developers