[developers] SEM-I question: properties on 'i' variables

[Dan Flickinger]

Hi Mike,


I think having properties appear on an `i' variable should be considered a bug in the grammar.  Looking now at the trunk gold profiles, I find two kinds of examples where the relevant lexical type failed to constrain a quantifier's ARG0 to be an `x', and I have now fixed those errors.  I also see that in the file erg/etc/core.smi, the ARG0 for quantifier predicates is uniformly presented as an `i' (with properties), but these should also be `x'.  I'll see if I can get this correction into the 2018 release, which I aim to freeze and announce this week.


 Dan



________________________________
From: developers-bounces at emmtee.net <developers-bounces at emmtee.net> on behalf of Michael Wayne Goodman <goodman.m.w at gmail.com>
Sent: Monday, November 12, 2018 10:57 AM
To: developers
Subject: [developers] SEM-I question: properties on 'i' variables

Hi all,

What does it mean when variable properties are specified on 'i'? The
following example is taken from http://moin.delph-in.net/SemiRfc, which
comes from the ERG:

     _a+little_q : ARG0 i { NUM sg }, RSTR h, BODY h.

In the "variables" section of the ERG's SEM-I, no properties are defined
on 'i', and 'NUM' is only on 'x':

     u.
     i < u.
     p < u.
     h < p.
     e < i : PERF bool, PROGR bool, MOOD bool, TENSE tense, SF sf.
     x < i & p : DIV bool, IND bool, GEND gender, PERS person, NUM
number, PT pt.

So why is 'i' the value of 'ARG0' on the predicate synopsis above? Why
not 'x'?

When I looked through through all the .smi files of the ERG (trunk), 'i'
was the only underspecified variable type that took properties, and
every instance specified 'x' properties such as NUM or IND (not 'e'
properties like TENSE or SF). Perhaps something in the grammar could be
more tightly constrained so the SEM-I generation code doesn't enumerate
apparent redundancies such as the following?

     def_explicit_q : ARG0 x { NUM sg }, RSTR h, BODY h.
     def_implicit_q : ARG0 i { NUM sg }, RSTR h, BODY h.

Or am I mistaken in thinking these are erroneous?

-mwg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20181112/5745b79c/attachment.html>