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

[Michael Wayne Goodman]

Sorry I replied to your other message before I saw this one.

On 11/12/18 1:34 PM, Stephan Oepen wrote:
> i was planning to watch attentively to see whether dan will be able to
> deliver on his intention to tighten up these values.
>
> i suspect that may turn out difficult in some cases, because my
> impression is that ‘i’ is often used as an arguably overly generous
> underspecification, where the actual intention is an ‘optional x’,
> i.e. a variable that will necessarily be of type ‘x’ if and when it is
> actually realized, but that can remain unexpressed.

That is a good point. The SEM-I can already specify that arguments are 
optional with square brackets, e.g., the ARG2 in the following:

     _vital_a_for : ARG0 e, ARG1 u, [ ARG2 i ].

However, I note that every optional argument in the ERG's SEM-I is an 
underspecified variable type and does not specify properties, so 
presumably the following is invalid:

     _tomorrow_a_1 : ARG0 i, [ ARG1 x { NUM sg } ].


>
> we have at times talked about inventing an additional mechanism to
> distinguish expressed from unexpressed variables (of a specific type,
> most importantly ‘x’) but so far we do not have such a mechanism.  so,
> it might just be necessary to formally allow some properties (e.g.
> NUM) to occur on the ‘i’ type already ...

Fine, but does that mean 'e' variables will inherit all 'x' properties? 
An alternative is to insert another variable type between 'i' and 'x', 
but that seems like a pretty drastic change to make a week before the 
next ERG release.


>
> oe
>
> On Mon, Nov 12, 2018 at 10:28 PM Michael Wayne Goodman
> <goodman.m.w at gmail.com> wrote:
>> Thank you, Dan!
>>
>>
>> Note that it's not just quantifiers. I also see in the gold profiles instances of pron, part_of, generic_entity, etc., with an 'i' variable for ARG0 with 'x' properties. And grepping 'i {' over the etc/*.smi files yields a lot more, and not always on ARG0:
>>
>>
>>      _tomorrow_a_1 : ARG0 i, ARG1 i { NUM sg }.
>>
>>
>> In case it's relevant, I'm looking at the ERG trunk SEM-I, so there is no core.smi file anymore, but it looks like the problem is the same. I'm sorry if these bugs delay the release!
>>
>>
>> On 11/12/18 1:10 PM, Dan Flickinger wrote:
>>
>> 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
>>