[developers] Trigger rules still being requested
Ann Copestake
aac10 at cl.cam.ac.uk
Mon Feb 15 18:57:36 CET 2016
I just want to confirm that with a small grammar with a small number of
null semantics entries (five of them), trigger rules are not required to
generate with the LKB. So I think that no warnings about the `missing'
trigger rules should be produced by default with small grammars, though
I don't know what the criteria for switching on the warnings should be.
Ann
On 11/02/16 00:05, Ann Copestake wrote:
> The comment about construction from corpora was really about big
> grammars - i looked at the ERG trigger rules about a year ago, and was
> a bit horrified ...
>
> For small grammars, is it really hopelessly inefficient to just run in
> the mode where all the empty semantics items are added to the chart?
> Does it simply not work if you have no trigger rules? (I admit not
> having tried this for years.)
>
> However, if not, it seems to me that the extract from a corpus
> technique could work with small grammars assuming you've got a
> suitable set of test sentences before you start to generate. i.e.,
> you'd parse those and accumulate trigger rules automatically from the
> parsed set, repeating as you expand the grammar. It doesn't matter if
> the trigger rules are very liberal, after all.
>
> Ann
>
> On 10/02/2016 23:14, Emily M. Bender wrote:
>> The tdl output is helpful to the extent that it shows people what the
>> value of TRIGGER should
>> be, but that's about it. It's particularly unhelpful when the
>> trigger rules are actually there... Also,
>> learning trigger rules from parsed/treebanked data sounds
>> interesting, but won't help at all
>> in the case of starter grammars, which we *do* want to be able to
>> generate.
>>
>> Emily
>>
>> On Wed, Feb 10, 2016 at 3:00 PM, Ann Copestake <aac10 at cam.ac.uk
>> <mailto:aac10 at cam.ac.uk>> wrote:
>>
>> 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.
>>
>> Ann
>>
>>
>> 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*)
>>> nil)
>>> collect id)))
>>> (loop for x in empty-no-trigger-entries
>>> do
>>> (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.
>>>
>>>
>>> Dan
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* developers-bounces at emmtee.net
>>> <mailto:developers-bounces at emmtee.net>
>>> <developers-bounces at emmtee.net>
>>> <mailto: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>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.
>>> ;;;
>>>
>>> (mt:read-transfer-rules
>>> (list
>>> (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.
>>> ;;;
>>>
>>> (index-for-generator)
>>>
>>> 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 messages
>>> when an entry truly lacks a trigger rule?
>>>
>>> Thanks,
>>> Emily
>>>
>>> --
>>> Emily M. Bender
>>> Professor, Department of Linguistics
>>> Check out CLMS on facebook!
>>> <http://www.facebook.com/uwclma>http://www.facebook.com/uwclma
>>
>>
>>
>>
>> --
>> Emily M. Bender
>> Professor, Department of Linguistics
>> Check out CLMS on facebook! http://www.facebook.com/uwclma
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160215/805260a9/attachment.html>
More information about the developers
mailing list