I have spoken to Jason about this off-line, but let me post a comment here for the record.
A major obstacle that I have encountered in writing various type-changing rules is that it is not possible to "spread" a feature structure specification across the instantiations of a dollar variable.
The desired effect is for the rule to take an argument which has a given feature shared across all the arguments of a complex category, and to change the value of each instance of this feature:
(Si\NPi)/NPi -> (Sj\NPj)/NPj
Currently, if I write a rule like the following:
Si$ -> Sj$
the output only changes the feature on the S, and does not apply to the instantiation of the $:
(Si\NPi)/NPi -> (Sj\NPi)/NPi
Thanks again,
Fred Hoyt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've also encountered this issue in implementing a version of Steedman's info structure constraints. What I would've liked is something like
LH% :- s[phr]$[phr]\s[th]$[th]
ie a boundary tone that changes all the info=th features to info=phr. Implementation-wise, this looked to be a lot of work. Consequently, I decided to add a somewhat quick-and-dirty capability that worked well enough for me, which was to allow features to be declared as "distributive", with the following effect: if a distributive feature appears in the result cat of a cat produced by some rule, then the value of that feature is propagated to all of the arg cats. Thus, if
LH% :- s[phr]$\s[th]$
is applied to
John_L+H* loves :- s[th]/np[th]
the result is
John_L+H* loves LH% :- s[phr]/np[phr]
where
the info=phr feature has been propagated from the s to the arg np.
A limitation of this approach is that you couldn't have a cat like
LH% :- s[phr]$\s[th]$/punct[,]
which takes an argument (like a comma) first, before becoming a distributive feature changing cat. The problem would be that after combining with a comma, the info=phr feature would get propagated, erasing info=th prematurely.
If this were a problem, one could still imagine refining the distributive feature approach, rather than trying to figure out how to deal with features on $ vars.
Also, I noticed that the slides GJ presented in Helskinki involved an approach where eg info=th is handled on the result cat, rather than distributively; it's not entirely clear to me whether this approach was successful though (at the least it seems to force the use of type-raising where it wouldn't otherwise be nec.).
-Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have spoken to Jason about this off-line, but let me post a comment here for the record.
A major obstacle that I have encountered in writing various type-changing rules is that it is not possible to "spread" a feature structure specification across the instantiations of a dollar variable.
The desired effect is for the rule to take an argument which has a given feature shared across all the arguments of a complex category, and to change the value of each instance of this feature:
(Si\NPi)/NPi -> (Sj\NPj)/NPj
Currently, if I write a rule like the following:
Si$ -> Sj$
the output only changes the feature on the S, and does not apply to the instantiation of the $:
(Si\NPi)/NPi -> (Sj\NPi)/NPi
Thanks again,
Fred Hoyt
I've also encountered this issue in implementing a version of Steedman's info structure constraints. What I would've liked is something like
LH% :- s[phr]$[phr]\s[th]$[th]
ie a boundary tone that changes all the info=th features to info=phr. Implementation-wise, this looked to be a lot of work. Consequently, I decided to add a somewhat quick-and-dirty capability that worked well enough for me, which was to allow features to be declared as "distributive", with the following effect: if a distributive feature appears in the result cat of a cat produced by some rule, then the value of that feature is propagated to all of the arg cats. Thus, if
LH% :- s[phr]$\s[th]$
is applied to
John_L+H* loves :- s[th]/np[th]
the result is
John_L+H* loves LH% :- s[phr]/np[phr]
where
the info=phr feature has been propagated from the s to the arg np.
A limitation of this approach is that you couldn't have a cat like
LH% :- s[phr]$\s[th]$/punct[,]
which takes an argument (like a comma) first, before becoming a distributive feature changing cat. The problem would be that after combining with a comma, the info=phr feature would get propagated, erasing info=th prematurely.
If this were a problem, one could still imagine refining the distributive feature approach, rather than trying to figure out how to deal with features on $ vars.
Also, I noticed that the slides GJ presented in Helskinki involved an approach where eg info=th is handled on the result cat, rather than distributively; it's not entirely clear to me whether this approach was successful though (at the least it seems to force the use of type-raising where it wouldn't otherwise be nec.).
-Mike