[Prev][Next][Index][Thread]

Re: the RM saga



> > My opting for decomposition as soon as possible is simply to make 
> > subsequent operations--Reattachment, Case Analysis, whatever JF and
> > Ken do--more tractable.  JF and Louis amongst others told us what
> > difficulties they had dealing with trees over a year ago; I certainly
> > have had my own since Christmas implementing (untested) Decomposition.
> > Reattachment comes after decomp simply because it is too hard to do
> > it before.
> Ok.  I'd have thought moving subtrees around the PT would be easier
> than moving them among decomp structures.  But then, I'm not coding
> decomp, am I.
The distributed rep gives a number of different known entry points
to the tree, each accessing a shallower structure.
  
> > ===KEN: I don't know about PPs modifying other PPs.  As I mentioned
> > ===KEN: above, I see PPs moving from a svoo_svoc_svoa() argument to a
> > ===KEN: np_postmodifiers() argument (or the other way round) only.
> > You're moving away from the 'the ((((hall end) office) desk) printer)'
> > view of noun semantics, then.  Okay, we go with a flat list in the
> > np_postmodifiers slot.
> OhNonononononononono.  The np_postmodifiers slot will be anything but
> flat.  My point was that PPs are attached to NPs (entity()'s), not to
> other PPs.  The object of the PP will usually be an entity() structure
> which may of course have a PP in its own np_postmodifier slot.
Well, in correct DIPETT trees, PPs don't modify each others' objects.
If you want the functionality in reattachment to permit this, you had
better make the argument, and better find some way to motivate the user 
to perform the nesting that DIPETT will never present him or her with
at the outset.
  
> Tokens schmokens!  Seriously.  Tokens are the only things in PTs that
> strike fear into my heart.  I've avoided them religiously to date, but
> I do have a comment at the top of HAIKU_NMRA.PL that reads:
> 
> /* ED: Hey, don't forget, this stuff will all have to be updated to handle  */
> /*     tokens wherever they might appear (it doesn't look too bad, though,  */
> /*     since there don't appear to be tokens inside the head_noun() struct).*/

Not too bad for you perhaps, but I spent two days on token list appearances
or disappearances--they were the bulk of the changes in v3.0 from the
decomposition point of view.

-- 
Terry Copeck (terry@csi.uottawa.ca)


References: