<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Well, yes - as far as I can tell, Song and Bender 2012 does
    underspecify in a way that allows a very fine-grained control with
    ICONS in a way which makes sense formaly. I've just (re)skimmed the
    paper and haven't looked at the associated grammar, but I raised the
    question I did because I'm not sure whether the ERG analysis is
    intended to be the same or not.  There is a difference between
    having an ICONS element with an underspecified info-str relation and
    not having an ICONS element at all.  We might be able to get the
    fine-grained control using the ERG analysis but possibly only with a
    different interpretation of ICONS.<br>
    <br>
    Ann<br>
    <br>
    <div class="moz-cite-prefix">On 05/02/2016 21:01, Stephan Oepen
      wrote:<br>
    </div>
    <blockquote
cite="mid:CA+_Fm6JtexCotvenH7DAdWpWVSMmH4xaB2BgwwBN7qD50h_Utg@mail.gmail.com"
      type="cite">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><br>
          <br>
          On Friday, February 5, 2016, Woodley Packard &lt;<a
            moz-do-not-send="true"
            href="javascript:_e(%7B%7D,'cvml','sweaglesw@sweaglesw.org');"
            target="_blank"><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"><a class="moz-txt-link-abbreviated" href="mailto:aac10@cl.cam.ac.uk">aac10@cl.cam.ac.uk</a></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>
    </blockquote>
    <br>
  </body>
</html>