[developers] Roots in ACE output

[Dan Flickinger]

Hi Ann -

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.

 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
>
>
>
>
>