[developers] predicate naming in MRS

Francis Bond bond at ieee.org
Thu Dec 31 02:29:22 CET 2015


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



-- 
Francis Bond <http://www3.ntu.edu.sg/home/fcbond/>
Division of Linguistics and Multilingual Studies
Nanyang Technological University



More information about the developers mailing list