<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <div> <div>Begin forwarded message:</div> <blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;">From: Yi Zhang <<a href="mailto:yizhang@dfki.de">yizhang@dfki.de</a>> </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;">Subject: Re: [developers] Partial Parsing </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;">Date: December 9, 2011 12:02:35 PM GMT+01:00 </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;">To: Francis Bond <<a href="mailto:bond@ieee.org">bond@ieee.org</a>> </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;">Cc: <a href="mailto:developers@delph-in.net">developers@delph-in.net</a> </div> <div>hi Francis, as various robust/partial parsing methods seem to create a lot of confusions over the years, let me try to explain the currently available options in this mail, for i think i'm guilty for creating most of the confusion without proper documentation of the functionalities. <blockquote type="cite">(a) what is the recommended way of calling this.  My best guess is </blockquote><blockquote type="cite">'cheap -robust=1 -mrs -partial japanese'  i am loading a generative </blockquote><blockquote type="cite">model "gm := "tc.gm"." I am not sure if this model is the right one </blockquote><blockquote type="cite">for robust=1. </blockquote><blockquote type="cite"> </blockquote>first, -partial and -robust are two different ways of building partial analyses in cases where a full hpsg analysis is not available. -partial tries to paste together fragmented analyses without trying to build a complete derivation tree. -robust on the other hand, consults a PCFG to build a complete pseudo derivation according to the probabilistic model. therefore -partial and -robust options should NOT be used together. <blockquote type="cite">(b) When we turn partial and MRS on, what exactly gets output?  I was </blockquote><blockquote type="cite">expecting MRSs from edges that combine to form a spanning non-parse, </blockquote><blockquote type="cite">but it seems that we get more than that (e.g. some words appear more </blockquote><blockquote type="cite">than once in the output).  I append an example to this mail.  Is this </blockquote><blockquote type="cite">the expected result?  Is there any combinations of settings that will </blockquote><blockquote type="cite">get a single spanning non-parse (I am sure there is a better name for </blockquote><blockquote type="cite">it). </blockquote><blockquote type="cite"> </blockquote>the current implementation of the -partial mode in the main branch of the PET implements a shortest-path algorithm which finds ALL paths (of fragments connecting the complete sentence) with the equal weights. then each fragment of every path goes through MRS extraction to build fragmented MRSes. since ALL paths are returned, having duplicated words for certain spanning position will happen frequently. as alternative to this shortest-path algorithm, in our (Zhang et al. 2007b) paper (ACL workshop on deep linguistic processing), we discussed various ways of getting one best partial parse (path). several models were implemented then, but was not merged back into the main for the lack of feedback from actual usage of such mode. much later, in April 2010, i added a simplified version of such algorithm for Bart's experiment into then the `nep' branch of PET (r704). this was not picked up later when the merge happened. i suppose it is still trivial to apply the changes of revision r704 to the main branch (with some minor modification), then you will get non-duplicated partial parsing results by just using -mrs -partial options. moreover, if we can get a feeling about the actual usage of the -partial mode, we can probably change the default behavior to, say, only print one fragment-path instead of all of them? <blockquote type="cite">(c) has anyone anywhere done something that stitches the MRS fragments </blockquote><blockquote type="cite">together?  For our purposes almost anything would do (e.g. </blockquote><blockquote type="cite">lump(e,h1,h2)) with as many lump_rels as needed to fix the bits </blockquote><blockquote type="cite">together, ...  this would allow us to pass the fragments to the MT </blockquote><blockquote type="cite">module and get candidate fragment translations for alignment. </blockquote><blockquote type="cite"> </blockquote>one thing to be careful about when stitching the MRS fragments is that, strictly speaking each fragment has it's own variable namespace, i.e. variables with the same name in different fragments are not meant to be coindexed. i hope this explanation helped. cheers, yi </div></blockquote></div> </body></html>