アーリーパーサーの前に適用されるタガー(またはレクサー)ステージを使用していると仮定します。つまり、入力文字列をトークンに分割し、各トークンを辞書で検索して品詞(POS)タグを決定するアルゴリズムです。 (s):
John --> PN
loves --> V
a --> DT
woman --> NN
named --> JJ,VPP
Mary --> PN
ある種の近似文字列ルックアップ(別名ファジー文字列ルックアップ)をそのステージに組み込むことができるはずです。そのため、「loves」ではなく「lobes」などのスペルミスのトークンが提示された場合、タグを識別するだけではありません。正確な文字列照合(「lobes」は「lobe」の複数形の名詞)だけでなく、形状が類似しているトークン(「loves」は動詞「love」の3人称単数形)によって検出されます。
これは、通常、トークンごとに多数の候補タグを取得することを意味します。したがって、解析中に可能な解析結果の数が多くなります。これが望ましい結果を生成するかどうかは、文法がどれほど包括的であるか、および多くの可能な解析ツリーが提示されたときにパーサーが正しい分析を識別するのにどれだけ優れているかによって異なります。確率的パーサーは、すべての候補解析ツリーに確率(または信頼スコア)を割り当てるため、これに適している可能性があります。これは、最も可能性の高い(または最良の)分析を選択するために使用できます。
これがあなたが試したい解決策である場合、いくつかの可能な実装戦略があります。まず、トークン化とタグ付けが単純な辞書ルックアップとして(つまり、レクサーのスタイルで)実行される場合、近似文字列マッチングを可能にする辞書のデータ構造を使用することができます。近似文字列比較の一般的な方法は、近似文字列マッチングアルゴリズムで説明されていますが、より大きな辞書での近似文字列ルックアップの方法は、Javaのコレクションと文字列をすばやく比較するで説明されています。
ただし、レクサーではなく実際のタガーを使用する場合、つまり単なる辞書ルックアップに加えてPOSの曖昧性解消を実行する場合は、おおよその辞書ルックアップをそのタガーに組み込む必要があります。タガーのどこかに、曖昧性解消が適用される前に候補タグを生成するために使用される辞書ルックアップ関数が必要です。その辞書ルックアップは、おおよその文字列ルックアップを可能にするものに置き換える必要があります。