10 thoughts on “David Gyorfi (University of Surrey): Challenges in Kazakh Auxiliary selection”
Thank you for your talk! Fascinating data!
Have you considered the middle way between a lexical approach and a phrasal constructional approach, i.e., using a lexical rule (or a unary-branching word-level construction) that would take the lexical version of the verbs as its input and output the auxiliary?
Thank you for the comment, Prof Sailer!
Yes, I suppose, if it is possible to specify disjunct LID values in INPUT, OUTPUT could have all the necessary specifications. However, if a type would be necessary to encompass this set of auxiliaries, it would not be as economical of a solution as the one I preferred in the talk. I had the intuition that this analysis fits better the assumptions in SBCG, but at the moment I can’t think of any other particular factor to make this decision.
That is interesting, Olga!
It would definitely predict the data adequately, but if I understand your idea correctly, it would require a ‘complicated type hierarchy’ as opposed to the single construction I had in mind. In addition, I think it is essential to encode that the values in question as truly optional, and I’m not sure how your idea would end up reflecting this fact – but I guess it would just be another case of underspecification and it would predict correctly. Thanks for the idea, it is a good argument for a lexicalist treatment.
From a “sentence generation” point of view, both subtypes of adp1 would be equally possible, so I think the optionality that you mention is met in Olga’s proposal.
Thank you for the interesting talk!
I’m puzzled by why you think disjunction is an issue – straightforward examples of logical “or” in the way you use it can be found e.g. in Pollard & Sag (1994: 89); they don’t use “xor”, but their sort hierarchy gives them the same effect. Moreover, as the have both negation and disjunction (see the preceding page 88 of the above reference for an example of negation), “xor” can be added as syntactic sugar if desired.
In short, I think your proposal there is classical HPSG without the need to add anything.
A second, purely notational follow-up remark:
When you write “{¬ go, come}”, you explain that as “the set that does not contain go or come”. From this explanation, and from how you use your notation, I believe what you mean is relative set complement. The most common notation in mathematics for this would be “{go, come}” with an overline and the set with respect to which this is supposed to be the complement as a superscript. In Latex:
$\overline{ \{ go, come \} }^U$
where U is the relevant universe.
(that construct is uncommon in HPSG, as far as I know, but once you assume set values as Pollard and Sag do, there’s nothing unusual about it)
The mathematics behind sets in HPSG is special. David, have a look at Pollard & Moshir about this. Honestly: I would avoid sets. The Pollard & Moshier sets do funny things, which were used for nonlocal dependencies. I think you would not want this. I guess types are better for you anyway. They can replace disjunctions and sets.
As long as the sets are finite, they are harmless, and I haven’t seen infinite set values yet. Harmless in the sense that a precise story can be told. In that sense, I don’t see any issue with their use here, like anywhere else where you find them (rather frequently) in theoretical HPSG papers.
What remains then is the fact that, behind the technical scenes, the story that needs to be told is very long and always complicated. But the single point where you notice this as every-day-HPSG-linguist is when you want to implement your grammar. For various good technical reasons, implementation platforms for HPSG grammars will not support sets directly – in contrast to elaborate type hierarchies, which are among the strengths of the systems.
Still, the fact that computer scientists haven’t figured out how to provide what linguists really want is not sufficient reason not to use it 🙂
Thank you for your talk! Fascinating data!
Have you considered the middle way between a lexical approach and a phrasal constructional approach, i.e., using a lexical rule (or a unary-branching word-level construction) that would take the lexical version of the verbs as its input and output the auxiliary?
Thank you for the comment, Prof Sailer!
Yes, I suppose, if it is possible to specify disjunct LID values in INPUT, OUTPUT could have all the necessary specifications. However, if a type would be necessary to encompass this set of auxiliaries, it would not be as economical of a solution as the one I preferred in the talk. I had the intuition that this analysis fits better the assumptions in SBCG, but at the moment I can’t think of any other particular factor to make this decision.
???
Thank you for a very engaging talk, David!
How would this approach relate to having a hierarchy of items which have different orthographies but share one FORM value, for example?
adp1 [FORM adp1]
/ \
on. about
< information, [ COMPS [ FORM adp1 ] ] >
That is interesting, Olga!
It would definitely predict the data adequately, but if I understand your idea correctly, it would require a ‘complicated type hierarchy’ as opposed to the single construction I had in mind. In addition, I think it is essential to encode that the values in question as truly optional, and I’m not sure how your idea would end up reflecting this fact – but I guess it would just be another case of underspecification and it would predict correctly. Thanks for the idea, it is a good argument for a lexicalist treatment.
From a “sentence generation” point of view, both subtypes of adp1 would be equally possible, so I think the optionality that you mention is met in Olga’s proposal.
Thank you for the interesting talk!
I’m puzzled by why you think disjunction is an issue – straightforward examples of logical “or” in the way you use it can be found e.g. in Pollard & Sag (1994: 89); they don’t use “xor”, but their sort hierarchy gives them the same effect. Moreover, as the have both negation and disjunction (see the preceding page 88 of the above reference for an example of negation), “xor” can be added as syntactic sugar if desired.
In short, I think your proposal there is classical HPSG without the need to add anything.
Dear Prof Richter,
Yes, Stefan also commented that this part is not novel. I will acknowledge this later today.
A second, purely notational follow-up remark:
When you write “{¬ go, come}”, you explain that as “the set that does not contain go or come”. From this explanation, and from how you use your notation, I believe what you mean is relative set complement. The most common notation in mathematics for this would be “{go, come}” with an overline and the set with respect to which this is supposed to be the complement as a superscript. In Latex:
$\overline{ \{ go, come \} }^U$
where U is the relevant universe.
(that construct is uncommon in HPSG, as far as I know, but once you assume set values as Pollard and Sag do, there’s nothing unusual about it)
The mathematics behind sets in HPSG is special. David, have a look at Pollard & Moshir about this. Honestly: I would avoid sets. The Pollard & Moshier sets do funny things, which were used for nonlocal dependencies. I think you would not want this. I guess types are better for you anyway. They can replace disjunctions and sets.
As long as the sets are finite, they are harmless, and I haven’t seen infinite set values yet. Harmless in the sense that a precise story can be told. In that sense, I don’t see any issue with their use here, like anywhere else where you find them (rather frequently) in theoretical HPSG papers.
What remains then is the fact that, behind the technical scenes, the story that needs to be told is very long and always complicated. But the single point where you notice this as every-day-HPSG-linguist is when you want to implement your grammar. For various good technical reasons, implementation platforms for HPSG grammars will not support sets directly – in contrast to elaborate type hierarchies, which are among the strengths of the systems.
Still, the fact that computer scientists haven’t figured out how to provide what linguists really want is not sufficient reason not to use it 🙂