Features in Glue

Avery D Andrews u7600202 at LEONARD.ANU.EDU.AU
Thu Nov 21 05:30:54 UTC 2002


Another glue logic issue I've been wondering about is what to do
about what would be traditionally regarded as semantically
interpreted features, such as number and tense.  It is my impression
that the current implementations work by co-introducing the features
and their associated meaning-constructors in the lexcion, but it
seems to me that the relation between morphological irregularity
and multiple semantics of lexical stems creates problems for
such an approach.  For example, the irregular verb 'go' with its
past form 'went' has a wide range of meanings, especially in
combination with various particles and prepositions:

    John went to Paris
    John went crazy
    John went 'waddidya do that for??'
      (recent colloquial)
    The bomb went off
    The chicken salad went off
    Mary went off at John for not washing all of the dishes
      (perhaps only Australian?)
    The lights went out

Perhaps there are other ways of handling this kind of thing, but
a natural approach seems to me to be to say that there's a lexical
form GO and a grammatical feature TENSE PAST, and that the past
grammatical feature causes (normally) a meaning-constructor for
past tense to be introduced, and that the lexical form GO
introduces a variety of different meaning-constructors, depending
on the context.  And finally, of course, the morphology spells out
GO+PAST irregularly as 'went' rather than 'go' (this is
similar to some of Jackendoff's proposals in _The Architecture
of the Language Faculty_).

In fact, I think we can integrate the interpretation of grammatical
features, lexical items, and idiomatic combinations, as follows.
Suppose first that there are no PRED features, only FORM features,
so rather than PRED `Go(SUBJ)' we'll have FORM GO.  Next, all of the
'semantically interpretable' features, including FORM, will have an
empty position in their values, when introduced from the syntactic-
morphological lexicon.  E.g. what we really have is FORM GO[ ] and
TENSE PAST[ ].

And finally, in order for a setence-structure structure to be well-
formed, the slot must be filled by something, and what it is filled by
is constructor-introduction rules, which might look like this:

   [TENSE PAST] => lm(S, Past(S)) : *_sig -o *_sig

     or

   FORM GO
   PART OFF      => lm(Y, lm(X, (X angrily critizes Y))) :
   AT [PCASE AT]      (* AT)_sig -o (* SUBJ)_sig -o *_sig

When a rule like this applies,the slot position in the values it
refers to must be empty, and then get filled, and are so not
available for the application of other rules.  So the expression-of-
anger rule for 'go off at' will preclude the application of other
possiblities, such as motion or actual explosions.  This should
be seen as a specific implementation strategy for an idea that could
be implemented in various other ways, and is also rather similar to
various other ideas floating around in the literature, such as
Kaplan/Wedekind restriction, Minimalist feature-checking, RLFG and other
resource-based proposals for syntax etc, some of which could be used as
implementations.  One way of thinking of it is a rather limited form of
resource processing in which all resources of one type (interpetable
grammatical features) must be consumed by rules that produce other
resources of a different type (meaning-constructors).
It's not RLFG because the resources of the first type are
produced by a regular LFG, which is not subject to resource-accounting.

Something I see as a merit is that pluralia tanta and other
not-strictly-semantic use of grammatical features that are
normally semantically interpreted can be straightforwardly
accounted for:

   FORM UNDERPANT  => blah blah blah
   NUM  PL

What features are interpretable?  I would like to say `all of them',
but I haven't been able to work out a sensible story about case;
anaphoric features might also be problematic.

Nonsemantic arguments such as expletives and idiom chunks are
likewise straightforward.

One point worth mentioning is that FORM features will have to
be indexed, for the same reason that PRED features were (very likely,
FORM features have to be indexed under Classic LFG anyway, although
I can't think of any knock-down evidence examples at the moment).

As usual, alternatives welcome.



More information about the LFG mailing list