Reentrancy in feature structures

[John Beavers]

Hi, Carl,

On Thu, 4 Jul 2002, Carl Pollard wrote:

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

Ok, I see the issue, and of course reentrancy gives you an additional
piece of information, namely that two things are coindexed not just if the
feature values are equivalent but also if the two indices are
coidentified.  That means that without reentrancy you'd have a hell of a
time telling if two things were coindexed without something like that
IDENT feature.  However, when you state your constraints in your feature
language, you're establishing an equivalence that's basically just like
reentrancy, so rather than introducing a new feature you could also
reformulate your binding theory to take pre-model constraints into
account, but that somehow seems like a very peculiar and otherwise
unmotivated thing to do.

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

Right, I guess that depends on your choice of intensional logic, though,
as presumably you could a use a logical representation that more closely
corresponded to the HPSG one, but I don't feel qualified enough to comment
on that!

Thanks,
John