Re: the RM saga
==KEN: I'm not sure I get the last point. Terry, are you suggesting
==KEN: that we do away with subtleties like 'conj_pp', etc.? I'd be
==KEN: loath (or is that 'loathed'? ;-) to do it. As an example, I
==KEN: call 'You can print on the laser printer OR on the plotter' as
==KEN: my first witness. The disjunction would be lost.
%%%TER: No, just that in the 'the printer by ...' case, the PPs are on analysis
%%%TER: not conj-ed in the and/or manner you illustrate. Fact is, reattachment
%%%TER: here is pushing the envelope of DIPETT grammar-the user wants to create
%%%TER: a (correct) structure that DIPETT will not produce on its own, always
%%%TER: preferring to conj its PPs. What to do? I ask.
***SYL: wait a second! Correctness is defined by DIPETT's grammar.
===KEN: That's true. Whenever I can't remember what the third fork is
===KEN: for or what the latest name for the Museum of Man is, I consult
===KEN: DIPETT. (Sorry, I've been reading alt.religion.kibology again).
***SYL: It might
***SYL: be the case that for a specific string, DIPETT won't manage to
***SYL: find the right structure. However, it must be the case that whatever
***SYL: structure will be output by the RM, it must be a legal DIPETT parse
***SYL: tree that could have been produced by the parser if it had managed
***SYL: to parse "perfectly".
===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.
%%%TER: What structure is to be produced from reattachment of the conjoined PP
%%%TER: phrases 'on the printer by the desk in the office'? That's what I'm
%%%TER: trying to find out.
%%%TER: DIPETT returns the single PP in "I printed the file on the printer":
%%%TER: svoo_svoc_svoa([ entity( ... ), pp( ... ) ])
%%%TER: and parses "I printed the file on the printer by the desk in the
%%%TER: office" as:
%%%TER: svoo_svoc_svoa([ entity( ... ),
%%%TER: conj_pps( implicit_and,
%%%TER: [ pp( ... ),
%%%TER: p_asyndetic_conj_pp( pp( ... ) ),
%%%TER: p_asyndetic_conj_pp( pp( ... ) )] ) ])
%%%TER: These are the raw materials.
%%%TER: We are agreed that a correct tree for the second sentence would have its
%%%TER: second and third PPs modifying the first, either hierarchically or in
%%%TER: a flat list (Ken's question).
%%%TER: To remain entirely faithful to DIPETT, reattachment would modify the
%%%TER: second tree to resemble the first. The first PP, 'on the printer',
%%%TER: would remain on the entity level and the other two PPs would be tucked
%%%TER: into its object's (=entity's) np_postmodifiers slot (as Ken discerned).
%%%TER: The conj_pps( implicit_and, ... ) frame would be stripped away from
%%%TER: this first PP and shifted down as well, and the the p_asyndetic_conj_pp
%%%TER: wrapper removed from the second PP after down-shifting. A check that
%%%TER: this was not the only PP would be needed; if so, the conj_pps frame
%%%TER: would be dropped. Lotsa overhead.
===KEN: Yes, indeed. But I think that describes accurately the kind
===KEN: of RM (at least) I imagined. The trickiness with conj_pps is
===KEN: exactly one of the reasons we want to limit the RM to two
===KEN: operations: moving a PP from verb argument position to inside
===KEN: the entity() structure; and vice versa.
***SYL: let's not get into the quicksands of specific examples! The user
***SYL: will decide if this or that PP should be attached to the verb or
***SYL: the noun -- it's his business! The RM's business is to provide
***SYL: the reattachment fonctionality.
%%%TER: But we might not provide the functionality of allowing PPs to modify
%%%TER: other PPs, and instead insist that all PPs modifying a noun remain
%%%TER: one level below the noun. It is a theoretically defensible posture.
===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.
***SYL: ... And the latter must be able to
***SYL: deal with DIPETT parse trees on input and produce a legal DIPETT
***SYL: parse tree on output.
%%%TER: I thought we were in agreement on the sentence/4, clause/4, phrase/4
%%%TER: representation? While these are intended to be reversible back into
%%%TER: a single parse tree, everyone seems to feel that a single tree structure
%%%TER: is too multifarious to be worked with. As we leave syntax behind, why
%%%TER: not let the grammar evolve in the direction of simplicity & efficiency?
===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).
***SYL: (Aren't we going overboard with the current exchange!?)
===KEN: I don't mean to take the wind out of your sails, but I think
===KEN: this kind of detailed back-and-forth tacking keeps us on an
===KEN: even keel. If we don't batten down the hatches now, we're
===KEN: likely to find ourselves up the creek without a paddle later
%%%TER: Without any intention of being disagreeable, I thought Ken's observation
%%%TER: was quite acute,
===KEN: Why thanks... you're kind of acute too! ;-)
%%%TER: and it does affect us here in terms of what functions
%%%TER: we decide to implement. How NPs modify other NPs may be more important
%%%TER: to Ken than to others given his dissertation topic.
===KEN: And my stuff expects entity() structures as they are currently
===KEN: defined in DIPETT 3.0 (which is slightly different than
===KEN: version 2 entities, BTW). Of course, nothing is permanent.