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.
> ===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.
> ===KEN: I agree on the sentence/4 etc. representation. But I see it
> ===KEN: as reversible by mere expansion (of the symbolic placeholders
> ===KEN: with the corresponding PT chunk).
> Be aware that for consistency in the distributed-tree sentence/4 rep,
> missing token lists are assembled from phrases (not from clauses,
> unfortunately) on the fly and superfluous ones discarded. So reversing
> decomp in an assembly operation would not produce the original tree.
> Token lists however seem to be a rather take-it-or-leave-it argument--
> I know from reworking decomp last week that Sylvain modified their
> locations in v3.0--so this is probably not an important caveat.
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). */