<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks, Stephan,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 21, 2020 at 9:48 PM Stephan Oepen <<a href="mailto:oe@ifi.uio.no">oe@ifi.uio.no</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">[...]</span><br>
token mapping will allow the grammar to put virtually any character<br>
into its predicates, and by and large i would say rightly so (even if<br>
not all of the predicate and CARG examples in the above may ultimately<br>
be desirable :-). thus, MRS serialization may need to be sensitive to<br>
different escaping conventions we have (or may yet have to establish),<br>
as i have tried to summarize in our related M$ GitHub issue:<br>
<br>
<a href="https://github.com/delph-in/pydelphin/issues/302" rel="noreferrer" target="_blank">https://github.com/delph-in/pydelphin/issues/302</a><br>
<br></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I'm merging some of the more general discussion from the linked GitHub issue to this thread.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regarding the PredicateRfc wiki, I don't think we should read it too literally, as it was not written with the level of rigor as we put into, e.g., the [TdlRfc](<a href="http://moin.delph-in.net/TdlRfc">http://moin.delph-in.net/TdlRfc</a>) page, and I'd call it more descriptive than prescriptive. But we certainly could improve it to be such a reference document.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regarding the shape of predicates, we need to separate our design considerations for the predicate symbols themselves from any constraints of a particular serialization format, as they may be used, unquoted, in other formats beyond SimpleMRS (e.g. EDS 'native' format, PENMAN, Indexed MRS, etc.) which may have different sets of valid and invalid characters. In an earlier thread we established that predicates of some different forms are equivalent if they differ only along these dimensions:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* upper/lower case distinctions (_predicate_n_1 == _PREDICATE_n_1)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* surrounding quotes (_predicate_n_1 == "_predicate_n_1")</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* presence of _rel suffix (_predicate_n_1 == _predicate_n_1_rel)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">(Aside: I'm not fond of the last one because of the ambiguity with _rel as a sense field (place_n == place_n_rel?); I'd argue for *requiring* that any _rel suffix (that isn't a sense) be removed for grammar-external ("exported") MRSs)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I think we can go further and say that quoted predicates are not even part of the spec for predicates; rather, they are an encoding scheme used by several serialization formats for predicates that cannot legally be encoded otherwise. At least, this could be true for exported MRSs. I recognize the historical purpose of quoted predicates for those that don't have a type defined in the grammar.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Other serialization formats may use other schemes. In JSON, for instance, predicates are always quoted and they follow JSON escaping conventions. The XML formats allow for "real predicates" that separate the lemma, pos, and sense fields, but they are still bound by XML's encoding conventions.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> _output_string(”hello/JJ_u_unknown (ws202)<br>
> _employee_name/NN_u_unknown (ws203)<br>
><br>
> There are _ characters inside the lemma portion of the predicates, which is not allowed. I don't recall if we came up with a scheme for encoding literal underscores in lemmas.<br>
<br>
yes, i agree token mapping should not construct these predicates! the<br>
immediate solution that comes to my mind would be to backslash-escape<br>
underscores in the lemma (and sense) fields, which i believe would<br>
then bring along escaping of literal backslashes, i.e. in your first<br>
example: _output\_string(”hello/JJ_u_unknown.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I have a slight dispreference for backslash-escaping literal underscores, because it complicates parsing. We could no longer simply split on _ characters to get the <lemma, pos, sense> components, and must parse the predicates character-by-character to determine if the \ that precedes _ is itself escaped, etc. TSDB's strategy might work, using \s or similar. We'd still need to parse it to get the original form, but we can just split on _ to get the individual components.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
but before guarding against these invalid predicates in token mapping,<br>
it would be good to push a little further in terms of cross-platform<br>
agreement on these fine points of (simple) MRS serialization.<br>
<br>
best wishes, oe<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">-Michael Wayne Goodman</div></div>