[developers] generation/224: additional generator trigger rule facility

[Stephan Oepen]

howdy,

we received a feature request within our LOGON project that i now think
could be of wider interest.  i forward the original message and a first
reply from ann below.  comments will be welcome!

the underlying notion of dependencies that hold between lexical entries
(or EPs in MRSs) reminds me of the chart dependencies discussion, which
i admit i have yet to read in full detail.

ann, i believe what you are proposing can be conceived as caching the
results of running FS-based trigger rules, e.g. once i provide this way
of spelling out dependency patterns in a declarative manner, there is
the choice of having these invoked off-line and recording the resulting
dependencies in one form or another.  for me, it remains important that
ERG users (e.g. people with a LOGON installation) can generate without
their own lexical database.

--- i think i will go back to the chart dependencies discussion now and
hope to follow up with an enlightened version eventually ...

                                                        cheers  -  oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (ILN); Boks 1102 Blindern; 0317 Oslo; (+47) 2285 7989
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at csli.stanford.edu; oe at hf.uio.no; stephan at oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


[--- start of forwarded message ---]

Date: Tue, 28 Jun 2005 17:06:14 +0200
From: oe at csli.Stanford.EDU
To: oe at csli.Stanford.EDU, gnats at emmtee.net
Subject: generation/224: additional generator trigger rule facility
Cc: mrs at emmtee.net

>Number:         224
>Notify-List:    mrs at emmtee.net
>Category:       generation
>Synopsis:       additional generator trigger rule facility
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    oe
>State:          open
>Class:          feature
>Submitter-Id:   remote
>Arrival-Date:   Tue Jun 28 17:06:14 +0200 2005
>Originator:     oe at csli.stanford.edu
>Release:        
>Organization:
>Environment:
>Description:
both the ERG and JaCY, it seems, would benefit from an additional way of
triggering semantically empty lexical entries for generation (in the LKB):
rather than having to enumerate the sets of predicates that, say, require
an expletive argument or a specific selected-for preposition (where these
are about to turn semantically empty in the upcoming ERG), it would seem
straightforward to write trigger rules that fire against the initial set
of lexical entries (as activated in the current set-up) and activate more
entries as needed.  a generic implementation would allow trigger rules in
this second stage where the LHS of the rule is a partial FS that is checked
under subsumption (or optionally unifiability, maybe) against the FSs from
already activated lexical entries.  specific selected-for particles, for
example, could then easily be activated using the existing LKEYS.--COMPKEY
et al. properties.
>How-To-Repeat:
>Fix:
>Unformatted:

[--- end of forwarded message ---]


[--- start of forwarded message ---]

To: LOGON MRS Design Committee <mrs at emmtee.net>
Cc: oe at csli.stanford.edu, gnats at emmtee.net
Subject: Re: [lm] generation/224: additional generator trigger rule facility
Date: Tue, 28 Jun 2005 17:38:24 +0100
From: Ann Copestake <Ann.Copestake at cl.cam.ac.uk>

fine up to the `triggered by subsumption' ... The assumption I've been making
is that we should have a general notion of lexical dependancy which can be
specified in terms of the lexical ids.  e.g., wash_up_v1 would be dependent on
up_p1 (or whatever it is).  The advantage of this is for the non-empty
semantics guys is that it can be checked before expanding FSs.

In the case of non-empty semantics lexical entries, we have dependency
relationships between MRS relations which can be derived from the lexical
entries.  These can be used for checking an MRS for well-formedness against the
SEM-I.

What this requires is that the lexical dependencies are systematically stored
in the lexicon, which doesn't seem hard.  This would also allow developers to
more easily inspect dependencies.

Ann

[--- end of forwarded message ---]