[developers] predicate naming in MRS

[Stephan Oepen]

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

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

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

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?

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

finally, i made a few edits to your PredicateRfc page where i felt
they were obvious typos (but please double-check).  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?

best wishes, oe