[developers] predicate naming in MRS

[Ann Copestake]

Hi all,

On 31/12/2015 01:16, Michael Wayne Goodman wrote:
> 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 thought we'd agreed not to use the single quote syntax sometime around 
the turn of the millenium ...  Anyway, I definitely do not think the 
user should need to be aware of the string/non-string distinction, so if 
that's the main point of the discussion, all seem to be in agreement.

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

quantifiers are treated specially in the MRS Lisp code and that actually 
predates the tripartite structure.  But e.g., my scoping code does not 
rely on the _q_rel but uses the presence of a feature which is 
specifiable by the grammar writer and defaults to BODY. Or a grammar 
writer can define a list of quantifiers.  Incidentally, you can check 
stuff like this by looking at the mrsglobals.lisp file, which has some 
documentation.

I don't think we at any point decided the gpreds in general could or 
should have POS.  In fact, it should be possible, because they are all 
supposed to mimic real lexical predicates - e.g., compound_rel behaves 
like a preposition.  But making that change would be a pain for everyone 
who is using the *MRS output (perhaps unless a convertor was also 
supplied to back-convert *MRS to the existing gpred vocabulary).

>
> 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 was surprised that you said this - I looked at the wiki page and I 
think the use of `sense' in the description of the gpred format is an 
inadvertent repetition rather than being meaningful.  All it's supposed 
to say is there is some string of characters followed by _rel.  Thinking 
of it as corresponding to any of the fields is a mistake - gpreds should 
just be treated differently, as they are in the .dtd

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

I'd say that's ok because we've never defined any structure for the 
gpreds ...

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

My problem with this document is not so much that it's ERG-specific but 
that it is in contradiction to the MRS paper in various places. Which is 
unfortunate.

All best,

Ann

>
> Thanks!
>
> On Tue, Dec 29, 2015 at 6:33 AM Stephan Oepen <oe at ifi.uio.no 
> <mailto: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/e3b27689/attachment-0001.html>