Re: the RM saga
> > 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.
> I thought this was the whole point of reattachment: to be able to
> move PPs from modifying verbs to modifying nouns (wherever the noun
> might be). I can't imagine what use reattachment would be without
That obfuscates a bit. I suggest that flat and hierarchical NP post-
modification are both legitimate treatments of 'the printer on the desk
in the office at the end of the hall', and that DIPETT at the moment
with its conj_pps(implicit_and) structure is predisposed to the flat rep.
We are all in agreement that we need to be able to move PPs out of this
structure as delivered by DIPETT, into one where they can modify a Case
marking prep's entity object as a post-modifier. But we may not want to
allow the user to nest PP post-modification below this one level, ie to
enforce the flat rep. Or we may allow it, in which case the user will
have to intervene more often, given the starting point of a flat conj of
_pps (a more dscriminating rep requiring a more discerning user).
This might be a good point to introduce a theme that was brought up a
year ago and which Sylvain touched on earlier today--correctness. As I
recall, people last year thought that the reattacher should not be able
to produce wrong trees, ie the functionality to do so not be implemented.
I think we need to decide whether we will allow PPs to modify each other
to indefinite depth or not.
> "Not bad" is my hope. In reality, I expect tokens to be the bane of
> my existence. I have yet to think of a way to avoid duplicating every
> predicate (one for the token-free structs, one for the tokened).
Tokens were put in only to facilitate user interaction. Will you be
interacting with the user to the point where you'll need to show phrases?
Terry Copeck (firstname.lastname@example.org)