[developers] predicate naming in MRS

[Ann Copestake]

see earlier message - it's fine with me, as long as there's some way of 
making the change invisible to everyone who is using the existing semantics

On 31/12/2015 01:29, Francis Bond wrote:
> G'day,
>
> I would like to see all grammatical preds also have a pos, even if it
> is not theoretically necessary.   It makes it much easier to used
> trigger rules/MT rules that use regular expressions to look for POS.
>
> On Thu, Dec 31, 2015 at 11:16 AM, Michael Wayne Goodman
> <goodmami at u.washington.edu> 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'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
>
>