[developers] predicate naming in MRS

[Michael Wayne Goodman]

Hi again, Stephan and all,

Sorry to focus more on the case-sensitivity issue when you were more
interested in the string-vs-type issue. For pyDelphin, type predicates are
equivalent to both double-quoted and single-open-quoted predicates. That
is,  _dog_n_1_rel == '_dog_n_1_rel == "_dog_n_1_rel". I think we've settled
on that being the correct behavior, but I'm prepared to reintroduce the
distinction (if we decide that we want string preds to maintain case
distinctions, for example).

I've created a wiki page for the specification of predicates:
http://moin.delph-in.net/PredicateRfc . I filled it out with what I know
from our conversations and from my own experience.

I would also like clarification on the status of grammar predicates. They
supposedly don't have internal structure, but I actually need to rely on
the POS value for determining if a pred is a quantifier pred (e.g.,
udef_q_rel). I've made pyDelphin decompose grammar preds in the same way as
regular (i.e. real- and string-) preds so that I can check POS.

Also, for grammar preds like compound_rel, I've been treating "compound" as
the lemma field (even if that's not entirely accurate), but
http://moin.delph-in.net/RmrsPos says it's the sense field. I can change
pyDelphin to call it the sense, but I see plenty of variation in
grammar-pred structure for the ERG (particularly the last two in this list):

; simple
addressee_rel

; multiple parts separated by _
abstr_deg_rel

; multiple parts separated by +
all+too_rel

; simple with POS
every_q_rel

; multiple parts with POS
free_relative_ever_q_rel

; POS followed by "sense"?
idiom_q_i_rel
interval_p_end_rel

The "POS followed by sense" preds also occur in Jacy (rareru_v_can_rel,
tai_v_want_rel).

There's some more discussion here (ERG-specific, perhaps):
http://moin.delph-in.net/ErgSemantics/Basics#Predicate_Types_.28And_Naming_Conventions.29

Thanks!

On Tue, Dec 29, 2015 at 6:33 AM Stephan Oepen <oe at ifi.uio.no> wrote:

> hi again, ann,
>
> > Anyway, I would prefer to make any changes to the main body of the Lisp
> MRS
> > code myself, since I am currently working on this.  I am, of course, not
> > going to touch the MT code ...
>
> glad to know you are coding!  i will of course try to not get in your way
> :-).
>
> as the ERG and other grammars are starting to introduce individual
> constraints, i had toyed with the idea of adding ICONS support to the
> MRS construction, visualization, input, and comparison.  but maybe you
> have that on your current ToDo list already?  if so, i would be happy
> to look into ICONS visualization in the non-CLIM browsers and ICONS
> interpretation in MRS comparison, once you add the basic support to
> the MRS structures.
>
> i had played with generation from EDS over the past few weeks, with
> promising results so far (see ‘EdsGeneration’ on the wiki).  thus, i
> had some pending local changes which included the periphery of core
> MRS code (e.g. bug fixes in the ‘debug’ serialization format and
> dispatching for various graphical browsers).
>
> i just checked these changes into the main LKB repository, so we can
> work on synchronized code.  in case you have started your own
> revisions already, i would recommend you ‘svn up’ as soon as possible,
> and i hope of course there will be no conflicts.  i attach a summary
> of my commit below, for your convenience.
>
> more soon, no doubt!  oe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20151231/26950606/attachment.html>