[developers] predicate naming in MRS

[Stephan Oepen]

hi again, woodley and all, thanks for the quick replies!

good: i realize i mis-represented the current state of affairs in ACE
and pyDelphin: so they both support the predicate equivalences dan
wants to some degree, albeit not fully.

> [...] never quote, and expect good results.

and would such inputs activate lexical entries for either variant of
the predicate, i.e. those with a type as their PRED value and those
with a string?

i am inclined to conclude that no-one is prepared to embrace my point
of view that the duality of _downtown_a_1 and "_downtown_a_1" shall be
disallowed in the ERG.  this is good news for the forthcoming 1214 ERG
release, and i suggest we provide coherent software support in the
various platforms as quickly as possible.

i had started to play with code changes to give dan what he wants
before sending my message yesterday, and i hope to release these for
public testing before too long.  not to worry ann, so far mostly ‘my’
MRS code is affected (transfer, comparison, and generator
initialization)!  i will post an update against the LOGON tree once i
get there.

> I welcome proposals for improvements to the above behavior.

from what you describe for ACE, it sounds as if you could push a
little further in consistently ignoring the string vs. type (quoted
vs. unquoted) distinction on predicate names.  we could of course
consider outlawing quoting of predicates in the simple MRS format, but
unless we take that step, arguably, quoted generator inputs should be
treated just like unquoted ones, in my view.  likewise, transfer rules
should not be sensitive to the distinction, i.e. every time we compare
MRS predicates we should apply the same comparison semantics (which
entails taking a consistent approach to case distinctions, i would
say).

as regards case distinctions on predicate names, i actually did not
intend to re-open that discussion :-).  since 2007 or so, i had
assumed we had settled on treating predicates as case-insensitive (and
CARGs as case-sensitive).  i suspect that assumption (often
implemented via vicious downcasing) is currently baked into several
pieces of code and wiki pages, i.e. could be somewhat costly to
revert.

i suggest we decouple the two questions, i.e. just settle on the type
vs. string contrast (which is the question i wanted resolved) in this
thread, along the lines i suggest above.  and should dan or ann
conclude that it seems desirable to introduce case distinctions on
predicates, that should become a separate discussion.

ann, incidentally: i believe i see the potential benefits in
separating more clearly the lemma–pos–sense components in surface
predicates, both for grammars (i.e. their TFS descriptions of MRSs)
and for at least part of the MRS manipulation software.  but again, i
consider that an orthogonal (if technically) related design decision.
abstractly, MRS predicate symbols are (possibly composite) objects for
which we should be able to spell out comparison semantics independent
of implementation.

best wishes, oe