[Prev][Next][Index][Thread]
Re: the RM saga
===KEN: I think this is a bit of a sticky point. Theoretically, I
===KEN: agree that the RM should be as unobstrusive as possible. But
===KEN: (as is suggested by Terry's comment below) there are two
===KEN: things going on here: reattachment and decomposition.
===KEN: Reattachment should come before decomposition because it will
===KEN: undoubtedly render the decomposed structures invalid. But I
===KEN: believe it's Terry's idea (correct me please) that
===KEN: decomposition might as well proceed as soon as the user's
===KEN: reattachment decisions are available... *before* (re)assembling
===KEN: a complete parse tree for the input. So the output from the
===KEN: Reattachment/Decomposition module would be like a perfectly
===KEN: valid DIPETT PT with certain embedded elements stripped out
===KEN: and replaced with symbolic placeholders.
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.
===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.
===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.
--
Terry Copeck (terry@csi.uottawa.ca)
References: