<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I should correct my prior...  <br>
      <br>
      It is not that the native LEs are taking precedence, but that
      native LEs that are not consistent with the input PoS are still
      being added to the chart.  <br>
      <br>
      For example, if I pass in "array" with "NN", I'm still getting
      array_v1 in the chart.  I want array_n1 in the chart.  So, what
      I'm after is pruning the native LEs to those that are consistent
      with the input PoS (or living with the generics in the case of no
      natives).<br>
      <br>
      Does that sound like what you called super-tagging?<br>
      <br>
      Paul<br>
      <br>
      On 9/18/2013 10:04 AM, Paul Haley wrote:<br>
    </div>
    <blockquote cite="mid:5239B2F0.2050804@haleyai.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">I had that fear, too!  Which is why I
        asked.<br>
        <br>
        I gave it a try with no default LEs.  To my surprise, the native
        lexical entries are still taking precedence!  (So I must be
        missing something.)<br>
        <br>
        On 9/18/2013 9:42 AM, Bec Dridan wrote:<br>
      </div>
      <blockquote
cite="mid:CAKRPO=Mpawkuey18GNE5x=ZgNHiugKAi6FzpnKhpghSfnZ57yA@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div>
            <div>
              <div>Hi Paul,<br>
                <br>
              </div>
              The POS input to PET is only designed for unknown word
              handling (ie when there are no corresponding ERG LEs, as
              you noticed).  It sounds like what you are after is more
              like supertagging, restricting the lexical types used
              according to some tags on the input? I've played around a
              bit with different methods to do that, but none of them
              are currently in the main branch of PET.  <br>
              <br>
            </div>
            What you propose with the filtering rule will, I think,
            force the grammar to use generic types everywhere, rather
            than use what's in the lexicon. I very much doubt that is
            what you want to do?<br>
            <br>
          </div>
          Rebecca<br>
        </div>
        <div class="gmail_extra"><br>
          <br>
          <div class="gmail_quote">On Wed, Sep 18, 2013 at 3:26 PM, Paul
            Haley <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:paul@haleyai.com" target="_blank">paul@haleyai.com</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <div>Hello,<br>
                  <br>
                  I may be making some conceptual progress on this...<br>
                  <br>
                  I went back to the chart mapping tutorial (<a
                    moz-do-not-send="true"
                    href="http://moin.delph-in.net/Chart_Mapping"
                    target="_blank">http://moin.delph-in.net/Chart_Mapping</a>)
                  and found myself looking at the following lexical
                  filtering rule from the ERG's lfr.tdl:<br>
                  <blockquote> ;; throw out generic whenever a native
                    entry is available, unless the token is<br>
                    ;; a named entity (which now includes names
                    activated because of mixed case or<br>
                    ;; non-sentence-initial capitalization).<br>
                    ;;<br>
                    generic_non_ne+native_lfr := lexical_filtering_rule
                    &amp;<br>
                    [ +CONTEXT &lt; [ SYNSEM.PHON.ONSET con_or_voc ]
                    &gt;,<br>
                      +INPUT &lt; [ SYNSEM.PHON.ONSET unk_onset,
                    ORTH.CLASS non_ne ] &gt;,<br>
                      +OUTPUT &lt; &gt;,<br>
                      +POSITION "I1@C1" ].<br>
                    <br>
                  </blockquote>
                  Is it the case that I want the +CONTEXT and +INPUT to
                  be exactly reversed with NO_DEFAULT_LES or
                  DEFAULT_LES_POSGAPS_LEXGAPS?<br>
                  <br>
                  Thank you,<br>
                  Paul
                  <div>
                    <div class="h5"><br>
                      <br>
                      On 9/17/2013 4:54 PM, Paul Haley wrote:<br>
                    </div>
                  </div>
                </div>
                <div>
                  <div class="h5">
                    <blockquote type="cite">Hi, <br>
                      <br>
                      It seems that when I send FSC w/ TNT tags for some
                      but not all tokens I get ERG LEs that do not
                      satisfy the provided tags when using any of
                      NO_DEFAULT_LES, DEFAULT_LES_ALL, or
                      DEFAULT_LES_POSGAPS_LEXGAPS.  It does respect
                      these tags when there are no corresponding ERG
                      LEs, however, which is good. <br>
                      <br>
                      Is there a way that I can get PET w/ the ERG to
                      respect the TNT tags when provided but otherwise
                      use the ERG LEs? <br>
                      <br>
                      Thank you, <br>
                      Paul <br>
                      <br>
                    </blockquote>
                    <br>
                  </div>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>