Reentrancy in feature structures

[Carl Pollard]

Hi John,

>
On Wed, 3 Jul 2002, Carl Pollard wrote:

> I hope not, since in my current research I have foresaken the
> graphical implementation of feature structures in favor of a treatment
> in terms of higher order logic. In the models this means feature
> structure types are indexed product types and the feature structures
> themselves are members of those types.  Thus there is only plain old
> equality (EQ), nothing corresponding to EQUAL. This makes some things
> (such as formalizing set values and distinguishing neutralization from
> ambiguity) much easier, but also means that coindexing cannot be
> handled the same way as in HPSG.

Maybe I missed something, but why would coindexing be that much different?
I agree the mechanism will be different for determining when two things
are "coindexed" but considering the entire mechanism of determing when two
things are EQUAL has been replaced with EQ, then that's expected.  But it
seems that once you nail a mechanism for coindexing things could work much
the same as in HPSG.  Or maybe I did miss something.
>>

But in the higher-order setting, if _index_ were treated as a "feature
structure type" i.e. as an indexed product with (say) the "features"
(= labels for the factors of the product) PER, NUM, GEN, then there
will only be one index for each choice of values for the three
features (since an element of a product is uniquely determined by its
projections onto the factors). There is no way to get two distinct
indices that have the same value for each of the three features;
or to put it another way, the labelled triple

  [PER 3rd, NUM plu, GEN fem]

IS an index. If you wanted a denumerable infinity of indices that were
all 3rdplufrem, then you'd have to introduce another basic type of
"identifiers" and make indices a fourfold product type instead of
a threefold one, so that now a 3rdplufem index would look like

  [PER 3rd, NUM plu, GEN fem, IDENT i]

where now the type _ident_ has a denumerable infinity of members (of
which on is i). (For example, one way to do this would be to have
_ident_ be the natural number type, in which case there would actually
be a natural number term of the logic corresponding to each possible
value of the feature IDENT.)

Another big difference is that in HPSG the indices also serve as the
variables in the (feature-struxture encodings of the) logical terms
which occur as CONTENT values, whereas in the higher-order treatment
the thing that corresponds to an HPSG content value is just a term in
(a certain) intensional logic, and there is no straightforward way I
know of to get the variables in those terms to also be the values of
the INDEX feature. For example, the meaning of EVERY BOY is just (the
intension denoted by) an expression of intensional logic, say
every'(boy'), and there is no variable in sight, to say nothing of the
problem of connecting variables with indices. In HPSG of course,
the content of EVERY BOY would be

    [DET every RESTIND [IND i RESTR [boy i]]

and the index of the NP EVERY BOY would be got from the path
SYNSEM|LOCAL|CONTENT|IND.

Carl