[developers] Roots in ACE output

Francis Bond bond at ieee.org
Fri Aug 29 10:46:39 CEST 2014


> I believe that in the ERG I'm only making use of subsumption whenever one root structure is not disjoint from the others in a particular group of multiple roots.  So a set of disjoint subsumption hierarchies should cover the current intended use cases for the ERG.
> I think it will have to be consumers of those roots who indicate what behavior is desirable in treating the root structure as part of the derivation.

I would like to report for a corpus what % of roots of which type (in
which case the most specific possible is the most informative).  I
think it may be an interesting measure.  If I have them, I was
planning to allow you to browse examples with the LTDB.  If it is not
possible to do, I can just ignore them.

>  Dan
> ----- Original Message -----
> From: "Ann Copestake" <Ann.Copestake at cl.cam.ac.uk>
> To: "Dan Flickinger" <danf at stanford.edu>
> Cc: "Woodley Packard" <sweaglesw at sweaglesw.org>, "Delph-in developers list" <developers at delph-in.net>
> Sent: Wednesday, August 20, 2014 5:50:28 AM
> Subject: Re: [developers] Roots in ACE output
> Probably mainly a question for Dan - are there any cases where you
> need overlapping root structures other than the case where there's a
> subsumption hierarchy between them?  And, if so, why?  (and what
> behaviour do you expect with respect to treating the root structure as part
> of the derivation, given that it's non-deterministic which root to
> choose?)
> I can formalise the case where there are disjoint root structures (i.e.,
> they are all mutually non-unifiable). I believe I can also formalise the
> case where there are
> subsumption relationships between all the root structures.  The
> way I'm doing this relies on the assumption that this corresponds to
> multiple grammars (sharing rules and lexical entries) and for this case it
> does make sense to record the root structure used in the derivation
> (formally it's a way of recording which grammar you're using at the time).
> I could also deal with disjoint subsumption hierarchies with that trick -
> i.e., there are a set of `top' root structures r1,0 to rn,0 which are
> mutually disjoint, and any other root structure has to be subsumed by one
> of those structures.
> I'll happily write the squiggles if this does cover all the use cases, and
> then we can talk about whether this corresponds to a desirable behaviour or
> not.
> Best,
> Ann
> On Tue, Aug 19, 2014 at 6:19 PM, Dan Flickinger <danf at stanford.edu> wrote:
>> Hi Woodley and all -
>> It would be worthwhile to consider having grammarians refactor the
>> workload of their set of root symbols to minimize the overlap.  I'll give
>> that a little thought for the ERG, but in the meantime I could also be
>> content with an interpretation of the set of root symbols as an ordered
>> list, as another way to `resolve' the ambiguity where more than one root
>> symbol would admit an analysis.
>>  Dan
>> ----- Original Message -----
>> From: "Woodley Packard" <sweaglesw at sweaglesw.org>
>> To: "Michael Wayne Goodman" <goodmami at u.washington.edu>
>> Cc: "Delph-in developers list" <developers at delph-in.net>
>> Sent: Tuesday, August 19, 2014 8:32:42 AM
>> Subject: Re: [developers] Roots in ACE output
>> Hi Michael,
>> This has long been a difference between PET on the one hand and ACE and
>> the LKB on the other hand.  There is (at least currently) no way to ask ACE
>> to include root symbols in the derivations it prints.
>> I'm not sure I'm prepared to agree with your assessment that this is a
>> problem.  In the past I've resisted adding root symbols to derivations
>> because their difference in formal status compared to the rest of the
>> derivation raises some uncomfortable questions.  For instance, do two
>> read-outs with identical sequences of rules and lexemes but different root
>> conditions constitute different derivations or the same derivation?  Since
>> root conditions cannot add information, the two (or more) derivations would
>> not differ e.g. in MRS.  This situation occurs all the time, since for the
>> ERG for example, any derivation that matches root_strict also matches
>> root_informal.  To me it feels like intentionally introducing spurious
>> ambiguity.  The way around that is to sacrifice a degree of declarativity,
>> i.e. make the ordering of root symbols important, and never acknowledging
>> some of what would otherwise be considered the set of valid derivations.
>> That's what PET does, I believe.
>> I can see that for the purposes of training parse disambiguation models,
>> the root symbol(s) that licensed a derivation may be a helpful feature --
>> although to my knowledge that has not been demonstrated in the literature.
>> A less vexed solution might be to list *all* the root symbols that match a
>> derivation -- either all together on the top node for the (single)
>> derivation, or recorded as a separate field in the tsdb profile.
>> Curious to hear others thoughts on this (somewhat sore for me) question,
>> Woodley
>> On Aug 18, 2014, at 10:22 PM, Michael Wayne Goodman <
>> goodmami at u.washington.edu> wrote:
>> > Hi Woodley (and Developers on the CC),
>> >
>> > We are noticing that ACE is not giving us the roots in derivation
>> > trees. This problem came up before for PET and the LKB nearly 6 years
>> > ago (see http://lists.delph-in.net/archives/developers/2008/001057.html
>> ).
>> > I see this behavior both when I use the `ace` command directly and
>> > when I batch process with `art`. Is there some way to make sure the
>> > root nodes show up in the derivations?
>> >
>> > Here is the value of parsing-roots in Jacy's ace/config.tdl:
>> >
>> > ;;;|| parsing-roots || list of root instances enabled for parsing ||
>> > parsing-roots             := utterance-root.
>> >
>> > And we are not using the -r option of ACE.
>> >
>> > Any suggestions?
>> >
>> > --
>> > -Michael Wayne Goodman

Francis Bond <http://www3.ntu.edu.sg/home/fcbond/>
Division of Linguistics and Multilingual Studies
Nanyang Technological University

More information about the developers mailing list