<div dir="ltr">Hi Stephan, developers,<div><br></div><div>As you've noted, we've discussed this in previous summits (<a href="http://moin.delph-in.net/SofiaMrsRfc?highlight=%28case+sensitive%29">http://moin.delph-in.net/SofiaMrsRfc?highlight=%28case+sensitive%29</a>) and email threads (e.g., <a href="http://lists.delph-in.net/archives/developers/2007/000804.html">http://lists.delph-in.net/archives/developers/2007/000804.html</a>) . It would be nice to make our different codebases more consistent.<div><br></div><div>From the pyDelphin side, I try, as much as possible, to retain the original form of preds, but comparisons normalize the values. Thus, if pyDelphin reads in "_Cat_n_1_rel" it will output "_Cat_n_1_rel", but a comparision with "_cat_n_1_rel" should return True (see below). This is because pyDelphin relies on external tools like the LKB and ACE, and therefore it tries hard to speak their respective MRS dialects. For example, StringPreds (both single- and double-quoted) and RealPreds are equivalent:</div><div><br></div><div>```python</div><div><div>>>> from delphin.mrs import Pred</div><div>>>> Pred.stringpred('_cat_n_1_rel') == Pred.realpred(lemma='cat', pos='n', sense='1')</div><div>True</div><div style="line-height:15.6px">>>> Pred.stringpred('"_cat_n_1_rel"') == Pred.stringpred('_cat_n_1_rel')</div><div style="line-height:15.6px">True</div><div style="line-height:15.6px">>>> Pred.stringpred('"_cat_n_1_rel"') == Pred.stringpred('\'_cat_n_1_rel')</div><div style="line-height:15.6px">True</div><div>>>> Pred.stringpred('_cat_n_1_rel') == '"_cat_n_1_rel"' # compare to regular strings, for convenience</div><div>True</div><div>```</div><div><br></div><div>However, Preds in the current version of pyDelphin are case-sensitive:</div><div><br></div><div>```python</div><div>>>> Pred.stringpred('_cat_n_1_rel') == Pred.stringpred('_Cat_n_1_rel')</div><div>False</div><div><span style="line-height:1.5">```</span><br></div></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I've filed a bug for this (</span><a href="https://github.com/delph-in/pydelphin/issues/45">https://github.com/delph-in/pydelphin/issues/45</a>) and implemented a fix. I'll hold off checking in the fix until we've reached consensus in this thread.</div><div><br></div><div>(Also, in investigating this, I found that pyDelphin was not robustly dealing with other case differences: <a href="https://github.com/delph-in/pydelphin/issues/44">https://github.com/delph-in/pydelphin/issues/44</a>)</div><div><br></div><div>Perhaps you can confirm the following:</div><div> * Predicates (string or otherwise) are always case-insensitive</div><div> * Other strings (CARG and surface values) are case-sensitive</div><div> * Ev<span style="line-height:1.5">erything else in SimpleMRS (rargnames, variables, variable property names and values, HCONS/ICONS relations, things like "LTOP" and "RELS", etc.) are case-insensitive</span></div><div><div> * The XML format of MRS may have case-sensitive things (tag names, etc), following the rules for XML</div></div><div><br></div><div>Thanks for bringing this up. It helped me find some issues with pyDelphin that I thought I'd already addressed.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 28, 2015 at 9:17 AM Stephan Oepen <<a href="mailto:oe@ifi.uio.no">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">dear colleagues,<br>
<br>
in these days of reflection, i would like to ask for opinions on an<br>
aspect of the DELPH-IN informalism where dan and i recently discovered<br>
that we held conflicting opinions. thus, we are looking for folks<br>
with a deeper understanding of the issue.<br>
<br>
for MRS predicate symbols, we have long established that we do not<br>
want case differences or type vs. string distinctions to be<br>
meaningful, i.e. we do not expect foo, Foo, or "foo" to name different<br>
relations (see ‘MrsRfc’ on the wiki). from this, i had concluded that<br>
no grammar would ever use both foo and "foo", whereas dan has found it<br>
convenient in the ERG to use comparable type names and strings (across<br>
lexical entries of different syntactic categories) in the expectation<br>
that they would be treated as equivalent MRS predicate symbols, e.g.<br>
_downtown_a_1_rel and "_downtown_a_1_rel".<br>
<br>
my assertation that the above was an undesirable property for a<br>
DELPH-IN grammar is supported by currrent software: MRS comparison,<br>
transfer, and generation do not treat types and strings as equivalent;<br>
a creator of input semantics for generation, for example, needs to<br>
know about the distinction and make a choice.<br>
<br>
what dan beliefs, however, arguably makes good sense (to me at least).<br>
i believe i can see how the various pieces of MRS manipulation<br>
software could be extended to yield the interpretation of equivalence.<br>
i would volunteer to make these changes in the Lisp implementation of<br>
MRS-related code.<br>
<br>
before suggesting a course of forward action, i would like to ask (a)<br>
whether anyone has strongly held positions (and supporting arguments)<br>
on the general question and (b) whether woodley and mike would be<br>
prepared to make software changes in ACE and pyDelphin, respectively,<br>
regarding this choice?<br>
<br>
with thanks in advance, oe<br>
<br>
</blockquote></div></div>