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

[Stephan Oepen]

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
> >>