<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thanks!<br>
    <br>
    <div class="moz-cite-prefix">On 05/02/2016 21:30, Emily M. Bender
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAMype6c-U4iTcVm_G4r6RuDgNvtm-VoTnQ2jeWwq=Amr4K8z+Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">Not sure if this answers the question, but a couple
        of comments:
        <div><br>
        </div>
        <div>(a) I do think that written English is largely
          underspecified for information structure.</div>
        <div>It's part of what makes good writing good that the
          information structure is made apparent</div>
        <div>somehow.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    OK.  should I understand you as saying that composition (as in, what
    we do in the grammars) leaves it mostly underspecified, but that
    discourse level factors make it apparent?  or that it really is
    underspecified?<br>
    <br>
    <blockquote
cite="mid:CAMype6c-U4iTcVm_G4r6RuDgNvtm-VoTnQ2jeWwq=Amr4K8z+Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>(b) I think the "I want only the unmarked form back" case
          might be handled by either</div>
        <div>a setting which says "no ICONS beyond what as in the input"
          (i.e. your ICONS { }) or</div>
        <div>a pre-processing/generation fix-up rule that takes ICONS {
          ... } and outputs something</div>
        <div>that would be incompatible with anything but the unmarked
          form.  Or maybe the</div>
        <div>subsumption check goes the wrong way for this one?</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    Yes, I think the ICONS {} might be a possible way of thinking about
    it.  I should make it clear - I don't think there's a problem with
    constructing an implementation that produces the `right' behaviour
    but I would much prefer that the behaviour is specifiable cleanly in
    the formalism rather than as another parameter to the generator or
    whatever.<br>
    <br>
    <blockquote
cite="mid:CAMype6c-U4iTcVm_G4r6RuDgNvtm-VoTnQ2jeWwq=Amr4K8z+Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>I hope Sanghoun has something to add here!</div>
        <div><br>
        </div>
        <div>Emily</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Fri, Feb 5, 2016 at 1:01 PM, Stephan
          Oepen <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">colleagues,
            <div><br>
            </div>
            <div>my ideal would be a set-up where the provider of
              generator inputs has three options: (a) request
              topicalization (or similar), (b) disallow it, or (c)
              underspecify and get both variants.
              <div><br>
              </div>
              <div>we used to have that level of control (and
                flexibility) in the LOGON days where there were still
                messages: in the message EPs, there were two
                optional ‘pseudo’ roles (TPC and PSV) <span></span>to
                control topicalization or passivization of a specific
                instance variable.  effectively, when present, these
                established a binary relation between the clause and one
                of its nominal constituents.  if i recall correctly,
                blocking topicalization was accomplished by putting an
                otherwise unbound ‘anti’-variable into the TPC or PSV
                roles.</div>
              <div><br>
              </div>
              <div>could one imagine something similar in the ICONS
                realm, and if so, which form would it have to take?</div>
              <div><br>
              </div>
              <div>best wishes, oe</div>
              <div>
                <div class="h5">
                  <div><br>
                    <br>
                    On Friday, February 5, 2016, Woodley Packard &lt;<a
                      moz-do-not-send="true"><a class="moz-txt-link-abbreviated" href="mailto:sweaglesw@sweaglesw.org">sweaglesw@sweaglesw.org</a></a>&gt;
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">I
                      can confirm that under ACE, behavior is what you
                      indicate, i.e. generating from parsing the
                      topicalized feline-canine-playtime I get just the
                      topicalized variant out, but when generating from
                      parsing the ordinary word order I get all 5
                      variants out.<br>
                      <br>
                      I believe this was designed to imitate the
                      long-standing condition that the MRS of generation
                      results must be subsumed by the input MRS.  The
                      observed behavior seems to me to be the correct
                      interpretation of the subsumption relation with
                      ICONS involved.  Note that an MRS with an extra
                      intersective modifier would also be subsumed, for
                      example, but such MRS are never actually generated
                      since those modifier lexical entries never make it
                      into the chart.<br>
                      <br>
                      It’s certainly reasonable to ask whether (this
                      notion of) subsumption is really the right test. 
                      I’ve met lots of folks who prefer to turn that
                      subsumption test off entirely.  I guess it’s also
                      possible that the subsumption test is right for
                      the RELS portion of the MRS but not for the ICONS,
                      though that seems a bit odd to consider.  However,
                      given that we don’t have many ideas about
                      truth-conditional implications of ICONS, maybe not
                      so odd.<br>
                      <br>
                      I don’t really have much to offer in terms of
                      opinions about what the right behavior should be. 
                      I (believe I) just implemented what others asked
                      for a couple years ago :-)<br>
                      <br>
                      -Woodley<br>
                      <br>
                      &gt; On Feb 5, 2016, at 8:03 AM, Ann Copestake
                      &lt;<a moz-do-not-send="true">aac10@cl.cam.ac.uk</a>&gt;
                      wrote:<br>
                      &gt;<br>
                      &gt; I'm part way through getting ICONS support
                      working in Lisp, testing on the version of the ERG
                      available as trunk. I have a question about
                      generation.  If I implemented the behaviour
                      described in <a moz-do-not-send="true"
                        href="http://moin.delph-in.net/IconsSpecs"
                        target="_blank">http://moin.delph-in.net/IconsSpecs</a>
                      there doesn't seem to be a way of specifying that
                      I want a `normal' ordering for English.<br>
                      &gt;<br>
                      &gt; e.g., if I take the MRS resulting from<br>
                      &gt;<br>
                      &gt; that dog, the cat chased.<br>
                      &gt;<br>
                      &gt; without ICONS check, there are 5
                      realizations, including the `null ICONS' case `The
                      cat chased that dog.'  With an exact ICONS check,
                      I can select realizations with the same ICONS
                      (modulo order of ICONS elements, of course, in the
                      case where there's more than one element).  But
                      with the <a moz-do-not-send="true"
                        href="http://moin.delph-in.net/IconsSpecs"
                        target="_blank">http://moin.delph-in.net/IconsSpecs</a>
                      behaviour, there's no way of specifying I want a
                      `normal' order - if I don't give an ICONS, I will
                      always get the 5 realisations. In fact, as I
                      understand it, I can always end up with more icons
                      in the realisation than in the input, as long as I
                      can match the ones in the input.<br>
                      &gt;<br>
                      &gt; So:<br>
                      &gt; - is the IConsSpec behaviour what is desired
                      for the ERG (e.g., because one can rely on the
                      realisation ranking to prefer the most `normal'
                      order)?<br>
                      &gt; - or does the ERG behave differently from
                      Emily and Sanghoun's grammars, such that different
                      generator behaviour is desirable? and if so, could
                      we change things so we don't need different
                      behaviours<br>
                      &gt;<br>
                      &gt; Ann<br>
                      &gt;<br>
                      &gt;<br>
                      &gt;<br>
                      <br>
                      <br>
                    </blockquote>
                  </div>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div class="gmail_signature">
          <div dir="ltr">Emily M. Bender<br>
            Professor, Department of Linguistics<br>
            Check out CLMS on facebook! <a moz-do-not-send="true"
              href="http://www.facebook.com/uwclma" target="_blank">http://www.facebook.com/uwclma</a><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>