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

[Michael Wayne Goodman]

(forgive me for replying to both of our subthreads in this one)

Regarding the redundant synopses: Oops. Thanks for pointing out the 
difference in the predicate symbols. My mistake.

Regarding square-bracket-optionality: Thanks for sharing. I'm trying to 
write code to use SEM-Is to validate and fill out partial MRSs, but all 
I have to go on is the SemiRfc wiki, the LKB's source code, and the 
ERG's SEM-I as an example. I'd be happy to see any additional notes or 
documentation about the implementation.

It seems like developing a coherent strategy for marking 
optional/unexpessed arguments in our grammars would make a good SIG at 
the next summit.


On 11/12/18 2:08 PM, Stephan Oepen wrote:
> i have come to think of the optionality marking by square brackets in
> the SEM-I as theoretically ill-founded.  at present, those brackets
> indicate, if anything, an incomplete notion of syntactic optionality.
> there are many valid usages of ERG predicates where arguments not
> marked as optional in the SEM-I can remain unexpressed.  from static
> inspection of the lexicon and rules it seems practically impossible to
> predict an actual notion of semantic optionality in ERSs, if such a
> notion could in fact be made theoretically consistent :-).
>
> personally, i would caution against reading much if anything into
> those square brackets, and i would probably not be sad to outright
> ditch them.
>
> oe
>
> On Mon, Nov 12, 2018 at 10:56 PM Michael Wayne Goodman
> <goodman.m.w at gmail.com> wrote:
>> 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
>>>>