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

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: 
%%%TER: DIPETT returns the single PP in "I printed the file on the printer":
%%%TER: 
%%%TER: 	svoo_svoc_svoa([ entity( ... ), pp( ... ) ]) 
%%%TER: 
%%%TER: and parses "I printed the file on the printer by the desk in the 
%%%TER: office" as:
%%%TER: 
%%%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: 	
%%%TER: These are the raw materials.
%%%TER: 
%%%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: 
%%%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
===KEN: on.

%%%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.

Ken
Follow-Ups: