<div dir="ltr"><div class="gmail_extra">Thanks Stephan.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 3:30 PM, Stephan Oepen <span dir="ltr"><<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-:yn" class="gmail-a3s gmail-aXjCH gmail-m15acef1efa18a362">please take a look at the 1214 ‘etc/erg.smi’. i believe all top-level<br>
abstractions in the list above were preserved (possibly under new<br>
names: ‘unspec_loc’, ‘nn’, and ‘can_able’). but some of the<br>
sub-hierarchies, e.g. below ‘unspec_loc’ are no longer exposed; they<br>
appeared all too difficult to explain (i.e. document) or interpret<br>
semantically—at least to dan, emily, and myself last year.<br></div></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-:yn" class="gmail-a3s gmail-aXjCH gmail-m15acef1efa18a362">
when designing the predicate hierarchy for quantifiers in the external<br>
interface, we aimed for simplicity and generalizations that we might<br>
hope to explain to a semanticist. e.g. the new ‘existential_q’<br>
subsumes what i believe was activated by the old ‘def_udef_a_q’, plus<br>
a few additional quantifiers.<br></div></blockquote><div><br></div><div>‘def_udef_a_q’ I think is defensible, I would be happy to write an explanation (and I do in my book :-)). It is also used by multiple MT systems, so I think removing it perhaps would need stronger motivation (and it sounds as though Dan is happy to put it back in). Sorry I was not able to test this earlier.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-:yn" class="gmail-a3s gmail-aXjCH gmail-m15acef1efa18a362">
it is an interesting question to try and decide which generalizations<br>
to provide in the external interface, and how to encode relevant<br>
distinctions. emily, for example, has long argued that dimensions<br>
like definiteness and proximity should be moved to variable<br>
properties, which would reduce the inventory of distinct quantifier<br>
predicates and make strong predictions about which ‘natural’ groupings<br>
one can obtain via underspecification. i am sympathetic to that<br>
perspective, and i believe we had plans to experiment in this<br>
direction in the ERG ‘trunk’.<br></div></blockquote><div><br></div><div>I think I am in broad agreement with Emily here, but until we reach this brave new world, it would be nice to have the functionality of the old one.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-:yn" class="gmail-a3s gmail-aXjCH gmail-m15acef1efa18a362">
much more practically, a key goal in the new SEM-I set-up was better<br>
modularity: a user should be able to take advantage of the added<br>
flexibility in 1214 and augment its SEM-I according to what they need.<br>
in other words, the default SEM-I should be easy to explain and by and<br>
large correspond to distinctions that are grammaticized and ‘make<br>
sense’ semantically. but it should also be easy to further refine the<br>
SEM-I, e.g. link predicates to an external hierarchy, be it WordNet or<br>
what is useful in a transfer-based MT set-up (for a specific language<br>
pair or groups of languages, maybe).<br>
<br>
i just played around with adding the old ‘def_udef_a_q’ on top of the<br>
stock 1214 SEM-I: dropping the file attached below into ‘etc/’ and<br>
adding the following to the end of ‘erg.smi’:<br>
<br>
include: jaen.smi<br>
<br>
that much appears to be enough to make the LKB generate the variation<br>
i believe you want:<br>
<br>
MRS(172): (lkb::generate-from-mrs (read-mrs-from-file "/tmp/transfer.debug.oe"))<br>
("A dog barks." "The dogs bark." "The dog barks." "Dogs bark.")<br>
<br>
—you were maybe the most immediate beneficiary we had in mind when<br>
introducing this new flexibility, i.e. to a large degree de-coupling<br>
the hierarchy of semantic predicates from grammar internals. in other<br>
words, the interface to generation is now highly configurable by the<br>
user. the above SEM-I extension should work equivalently in ACE, i<br>
expect; could someone easily confirm that?<br></div></blockquote><div><br></div><div>Thank you very much for investigating this fix. </div></div><br>We confirmed that this does not work :-). ACE seems to not like the hierarchy being redefined (if I am interpreting the error messages correctly). <br><div class="gmail_extra">type: `def_explicit_q' already declared, go away!</div><div class="gmail_extra">type: `def_implicit_q' already declared, go away!</div><div class="gmail_extra">type: `udef_q' already declared, go away!</div><div class="gmail_extra">type: `_the_q' already declared, go away!</div><div class="gmail_extra">type: `_a_q' already declared, go away!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Note that even without jaen.smi we get some similar error messages when we compile the ERG in the logon tree (rev 25417).</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">type: `compound' already declared, go away!</div><div class="gmail_extra">type: `existential_q' already declared, go away!</div><div class="gmail_extra">type: `of_p' already declared, go away!</div><div class="gmail_extra">type: `temp_loc_sp' already declared, go away!</div><div class="gmail_extra">type: `universal_q' already declared, go away!</div></div><div><br></div>-- <br><div class="gmail_signature">Francis Bond <<a href="http://www3.ntu.edu.sg/home/fcbond/" target="_blank">http://www3.ntu.edu.sg/home/fcbond/</a>><br>Division of Linguistics and Multilingual Studies<br>Nanyang Technological University<br></div>
</div></div>