[developers] predicate naming in MRS

[Ann Copestake]

> 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 agree we should support the ignore case mode of behaviour, but if 
we're fixing predicate comparison, we may as well make sure we allow for:
a) current `official' behaviour - case insensitivity for simplex predicates
b) complex stuctured predicates (tripartite being one case)
and
c) case-sensitive unstructured predicates, since this could anyway just 
be a special case of b)

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

agreed, with the proviso that I would like to allow as much room as 
possible for experimentation here (with the understanding that the code 
may not be super-efficient with all options).

All best,

Ann