<div dir="ltr">Hi again, Stephan and all,<div><br></div><div><span style="line-height:1.5">Sorry to focus more on the case-sensitivity issue when you were more interested in the string-vs-type issue. For pyDelphin, type predicates are equivalent to both double-quoted and single-open-quoted predicates. That is, </span><span style="line-height:1.5"> _dog_n_1_rel == '_dog_n_1_rel == "_dog_n_1_rel". I think we've settled on that being the correct behavior, but I'm prepared to reintroduce the distinction (if we decide that we want string preds to maintain case distinctions, for example).</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I've created a wiki page for the specification of predicates: </span><span style="line-height:15.6px"><a href="http://moin.delph-in.net/PredicateRfc">http://moin.delph-in.net/PredicateRfc</a> . I filled it out with what I know from our conversations and from my own experience.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I would also like clarification on the status of grammar predicates. They supposedly don't have internal structure, but I actually need to rely on the POS value for determining if a pred is a quantifier pred (e.g., udef_q_rel). </span><span style="line-height:1.5">I've made pyDelphin decompose grammar preds in the same way as regular (i.e. real- and string-) preds so that I can check POS.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Also, for grammar preds like compound_rel, I've been treating "compound" as the lemma field (even if that's not entirely accurate), but </span><span style="line-height:15.6px"><a href="http://moin.delph-in.net/RmrsPos" target="_blank">http://moin.delph-in.net/RmrsPos</a></span><span style="line-height:1.5"> says it's the sense field. I can change pyDelphin to call it the sense, but I see plenty of variation in grammar-pred structure for the ERG (particularly the last two in this list):</span></div><div><br></div><div>; simple</div><div><span style="line-height:15.6px">addressee_rel</span><br></div><div><span style="line-height:15.6px"><br></span></div><div><span style="line-height:15.6px">; multiple parts separated by _</span></div><div>abstr_deg_rel<br></div><div><span style="line-height:15.6px"><br></span></div><div><span style="line-height:15.6px">; multiple parts separated by +</span><br></div><div>all+too_rel<br></div><div><br></div><div>; simple with POS</div><div>every_q_rel<br></div><div><br></div><div>; multiple parts with POS</div><div>free_relative_ever_q_rel<br></div><div><br></div><div>; POS followed by "sense"?</div><div>idiom_q_i_rel<br></div><div>interval_p_end_rel<br></div><div><br></div><div>The "POS followed by sense" preds also occur in Jacy (<span style="line-height:1.5">rareru_v_can_rel, </span><span style="line-height:1.5">tai_v_want_rel).</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">There's some more discussion here (ERG-specific, perhaps):</span></div><div><a href="http://moin.delph-in.net/ErgSemantics/Basics#Predicate_Types_.28And_Naming_Conventions.29" target="_blank">http://moin.delph-in.net/ErgSemantics/Basics#Predicate_Types_.28And_Naming_Conventions.29</a><br></div><div><br></div><div>Thanks!</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 29, 2015 at 6:33 AM Stephan Oepen <<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi again, ann,<br>
<br>
> Anyway, I would prefer to make any changes to the main body of the Lisp MRS<br>
> code myself, since I am currently working on this. I am, of course, not<br>
> going to touch the MT code ...<br>
<br>
glad to know you are coding! i will of course try to not get in your way :-).<br>
<br>
as the ERG and other grammars are starting to introduce individual<br>
constraints, i had toyed with the idea of adding ICONS support to the<br>
MRS construction, visualization, input, and comparison. but maybe you<br>
have that on your current ToDo list already? if so, i would be happy<br>
to look into ICONS visualization in the non-CLIM browsers and ICONS<br>
interpretation in MRS comparison, once you add the basic support to<br>
the MRS structures.<br>
<br>
i had played with generation from EDS over the past few weeks, with<br>
promising results so far (see ‘EdsGeneration’ on the wiki). thus, i<br>
had some pending local changes which included the periphery of core<br>
MRS code (e.g. bug fixes in the ‘debug’ serialization format and<br>
dispatching for various graphical browsers).<br>
<br>
i just checked these changes into the main LKB repository, so we can<br>
work on synchronized code. in case you have started your own<br>
revisions already, i would recommend you ‘svn up’ as soon as possible,<br>
and i hope of course there will be no conflicts. i attach a summary<br>
of my commit below, for your convenience.<br>
<br>
more soon, no doubt! oe<br>
</blockquote></div></div>