<div dir="ltr"><div class="gmail_quote"><div>On Wed, Jan 6, 2016 at 1:17 PM 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">hi mike and all,<br>
<br>
> I've created a wiki page for the specification of predicates:<br>
> <a href="http://moin.delph-in.net/PredicateRfc" rel="noreferrer" target="_blank">http://moin.delph-in.net/PredicateRfc</a> .<br>
<br>
many thanks for putting this together; lots of useful information!<br>
<br>
i have a couple of comments and suggestions for revisions:<br>
<br>
(0) a technicality: in my view, the ‘_rel’ suffix is part of the TFS<br>
description of MRSs but not the MRSs proper; in other words,<br>
_foo_n_1_rel is a type name in the grammar, but the MRS predicate (as<br>
declared in the SEM-I) should be _foo_n_1. i.e. the optional ‘_rel’<br>
is part of the grammar-specific configuration (and in principle a<br>
grammar could pick a different suffix to carve out a name space in its<br>
type hierarchy for MRS predicates).<br></blockquote><div><br></div><div>In the wiki, I tried to make clear that the suffix is just to avoid name collisions in the type hierarchy, but we could probably revise it more to show that it is otherwise meaningless. But see below...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
at present, some MRS serializations strip the suffix but others still<br>
keep it (crucially including the ‘simple’ format). my suggestion,<br>
thus, is to make the serialization formats for MRSs (and derived<br>
variants) consistent in this respect and always strip the suffix, if<br>
present. this<br></blockquote><div> </div><div>In principle I don't mind stripping the "_rel" suffix in *MRS serialization formats, and I do this when the representation is meant for human-consumption (e.g., Demophin). However I won't make pyDelphin do that by default until there's support from the main processors for mapping back to grammar-internal types. I'm worried that output from pyDelphin wouldn't work with tasks that use *MRS as input, like generation and transfer.</div><div><br></div><div>Also, I'm afraid that remapping _rel-less predicates to their _rel-ful types would not be trivial if the suffix is user-definable. For one, it would require yet another grammar configuration (in mrsglobals.lisp or similar). Secondly, there's no guarantee that a grammar is consistent. Jacy, for instance, has predicates with and without the suffix (e.g. "coord"), and what if there were both ("coord_rel" and "coord")? Perhaps we can avoid the second problem if grammar processors warned of malformed predicates.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(1) still regarding the type vs. string contrast: you suggest that<br>
‘string’ predicates cannot stand in hierarchical relations, which is<br>
technically true of course in the TFS universe. however, we have just<br>
agreed that _foo_n_1 and "_foo_n_1" name the same relation (i.e.<br>
compare equivalent as predicates). thus, one should expect that<br>
"_afterwards_p" (from the 1214 ERG) have the same position in the<br>
(SEM-I) predicate hierarchy as its counterpart _afterwards_p, e.g. is<br>
accepted as a specialization of prep_mod (if exposed through the<br>
SEM-I) for the purposes of generator initialization of MRS subsumption<br>
testing.<br></blockquote><div> </div><div>You're right, this is a contradiction. So is the following what we want from our processors?</div><div><br></div><div>1. a type-pred must be defined as a type elsewhere in the grammar (e.g. _my-new-pred_n_1_rel := predsort.)</div><div><br></div><div>2. a string-pred has the same place in the type hierarchy as it's non-string equivalent if it exists, otherwise it creates a new atomic type (inheriting from string? or *top-semantic-type* (predsort)?)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
again, some current MRS serializations expose the type vs. string<br>
distinctions, while others omit it. i suggest we standardize further<br>
and always drop quote marks (if present in the TFS description of an<br>
MRS) in the MRS universe. the provider of an input MRS for generation<br>
should not need to know about the (grammar-internal) distinction, so<br>
why expose it at the MRS layer?<br></blockquote><div><br></div><div>this sounds good, assuming we do coordinate the string/type equivalence throughout our tools</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
—the above proposals put a little more weight on the SEM-I:<br>
hierarchical relations among predicates need to be spelled out there,<br>
such that the grammar-internal type hierarchy is not needed for MRS<br>
comparison. that has always been the intended design, and i am<br>
currently working on the code changes required (in generator<br>
initialization, transfer, and MRS comparison) to support that mode of<br>
operation.<br></blockquote><div> </div><div>Good. We discussed this some time ago, and that discussion resulted in a very small RFC wiki: <a href="http://moin.delph-in.net/SemiRfc">http://moin.delph-in.net/SemiRfc</a>. Let's get that wiki up to speed with current developments.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
finally, i made a few edits to your PredicateRfc page where i felt<br>
they were obvious typos (but please double-check).</blockquote><div><br></div><div>Not a typo, but I didn't know what to call it. I'm happy with your changes. Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and, why do you<br>
feel like discouraging the duality of closely related surface and<br>
abstract predicates, e.g. _place_n_1 and place_n_1? dan uses place_n<br>
in the decomposition of ‘somewhere’, and assuming he wanted that to be<br>
as parallel as humanly possible to ‘at some place’, i see no immediate<br>
reason why place_n_1 would be illegitimate in the decompositon?<br></blockquote><div> </div><div>I think you're referring to this line: "An abstract predicate and a surface predicate with the same apparent values (e.g., place_n_rel and a hypothetical _place_n_rel) are not equivalent, and grammar writers should avoid creating such similar predicates."</div><div><br></div><div>This is under the section on "Predicate Equivalence", and unless I'm mistaken we do, in fact, want to treat those as different predicates. The suggestion at the end was meant to help avoid confusion and/or subtle bugs where a developer expects those to be equivalent because they didn't know the difference between abstract and surface predicates. Aside from being potentially confusing, I don't see anything wrong with having both predicates in a grammar, so feel free to remove or reword the suggestion.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
best wishes, oe<br></blockquote><div><br></div><div>Thanks for the detailed comments!</div><div> </div></div></div>