[developers] predicate naming in MRS

[Michael Wayne Goodman]

On Wed, Jan 6, 2016 at 1:17 PM Stephan Oepen <oe at ifi.uio.no> wrote:

> hi mike and all,
>
> > I've created a wiki page for the specification of predicates:
> > http://moin.delph-in.net/PredicateRfc .
>
> many thanks for putting this together; lots of useful information!
>
> i have a couple of comments and suggestions for revisions:
>
> (0) a technicality: in my view, the ‘_rel’ suffix is part of the TFS
> description of MRSs but not the MRSs proper; in other words,
> _foo_n_1_rel is a type name in the grammar, but the MRS predicate (as
> declared in the SEM-I) should be _foo_n_1.  i.e. the optional ‘_rel’
> is part of the grammar-specific configuration (and in principle a
> grammar could pick a different suffix to carve out a name space in its
> type hierarchy for MRS predicates).
>

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...


> at present, some MRS serializations strip the suffix but others still
> keep it (crucially including the ‘simple’ format).  my suggestion,
> thus, is to make the serialization formats for MRSs (and derived
> variants) consistent in this respect and always strip the suffix, if
> present.  this
>

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.

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.

(1) still regarding the type vs. string contrast: you suggest that
> ‘string’ predicates cannot stand in hierarchical relations, which is
> technically true of course in the TFS universe.  however, we have just
> agreed that _foo_n_1 and "_foo_n_1" name the same relation (i.e.
> compare equivalent as predicates).  thus, one should expect that
> "_afterwards_p" (from the 1214 ERG) have the same position in the
> (SEM-I) predicate hierarchy as its counterpart _afterwards_p, e.g. is
> accepted as a specialization of prep_mod (if exposed through the
> SEM-I) for the purposes of generator initialization of MRS subsumption
> testing.
>

You're right, this is a contradiction. So is the following what we want
from our processors?

1. a type-pred must be defined as a type elsewhere in the grammar (e.g.
_my-new-pred_n_1_rel := predsort.)

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)?)

again, some current MRS serializations expose the type vs. string
> distinctions, while others omit it.  i suggest we standardize further
> and always drop quote marks (if present in the TFS description of an
> MRS) in the MRS universe.  the provider of an input MRS for generation
> should not need to know about the (grammar-internal) distinction, so
> why expose it at the MRS layer?
>

this sounds good, assuming we do coordinate the string/type equivalence
throughout our tools


> —the above proposals put a little more weight on the SEM-I:
> hierarchical relations among predicates need to be spelled out there,
> such that the grammar-internal type hierarchy is not needed for MRS
> comparison.  that has always been the intended design, and i am
> currently working on the code changes required (in generator
> initialization, transfer, and MRS comparison) to support that mode of
> operation.
>

Good. We discussed this some time ago, and that discussion resulted in a
very small RFC wiki: http://moin.delph-in.net/SemiRfc. Let's get that wiki
up to speed with current developments.

finally, i made a few edits to your PredicateRfc page where i felt
> they were obvious typos (but please double-check).


Not a typo, but I didn't know what to call it. I'm happy with your changes.
Thanks!


>   and, why do you
> feel like discouraging the duality of closely related surface and
> abstract predicates, e.g. _place_n_1 and place_n_1?  dan uses place_n
> in the decomposition of ‘somewhere’, and assuming he wanted that to be
> as parallel as humanly possible to ‘at some place’, i see no immediate
> reason why place_n_1 would be illegitimate in the decompositon?
>

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."

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.

best wishes, oe
>

Thanks for the detailed comments!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160106/3511d49b/attachment-0001.html>