ARG-ST as a head feature

Berthold Crysmann crysmann at dfki.de
Sat Jan 20 13:27:03 UTC 2001


Hi,

as this develops into a proper discussion thread, here's some remarks I
sent to Carl before (with a few additions).


> > > Why not?
> >
> > There's also the problem with constituent coordination identified by
> > Stefan Müller: if one wants to impose a likeness constraint at least on
> > head values, ARG-ST as a head feature will mess things up.
>
> Oh I see. Well, to me it doesn't matter whether ARG-ST is actually
> inside HEAD, as long as it propagates up the head path.

But where shall it go? The likeness restriction on constituent
coordination most probably not only involves identity of major category
plus head feature such as CASE or VFORM,[*]  it also requires identity
of
degree of saturation. To express this in a most general fashion, one
need
only coindex the SS|LOC|CAT  of the conjuncts with the mother and
everything is fine. If ARG-ST is embedded somewhere under CAT (quite
likely), one will lose exactly this generalisation.
(In essence, this was Stefan Müller's line of argumentation.)
CONT may be an option, at least you'll get some sort of percolation for
free. But with modifiers,
you probably still wouldn't get the desired results, unless you assume
that modifiers attract the ARG-ST value of the head.

Yet another point: what value will the ARG-ST of the mother-node have,
in
coordinated structures? Unification won't work, maybe
concatenation? But that'll give rise to strange implications concerning
binding. If, however, BT could only safely apply to word-level ARG-STs,
that'd be even more of an argument against percolation, wouldn't it.

Ooops, forgot, you could of course (partially) embed them à la Manning
and
Sag. But to me, that's quite an exotic data structure anyway:
list(synsem
v list(synsem)). Some ARG-STs already come in lexically nested (see
Manning & Sag), so that'll give you list(synsem v list(synsem) v
list(list(synsem))), wouldn't it?

Also, if something percolates up the head line, but does not do that in
the way other features do (e.g. HFP or Ivan's version of the SIP),
there's
definitely something fishy about it, don't you think? Plus the locality
considerations...



So, please correct me, if I'm missing something.

Berthold


[*] PP coordination may be a counter-argument (differing PFORM values).
However, as Jesse Tseng has suggested, semantically non-vacuous
prepositions will better be selected via CONT anyway. In the case of
prepositional objects, however, I strongly doubt that these can be
conjoined at all.

--
Berthold Crysmann
Deutsches Forschungszentrum Kuenstliche Intelligenz (DFKI) GmbH
Stuhlsatzenhausweg 3
D-66123 Saarbrücken



More information about the HPSG-L mailing list