「同義語・多義語の問題（続き）」より：
同義語・多義語の処理に関して、無難な方法を採用したのですが、それが最良かどうかは分かりません。もっと良い方法があるかも知れません。例えば、ツリー状の分類は難点もあります。代わりにタギングによる分類を試してみる価値はありそうです。
タグを使って用語を修飾・分類する方法を考えてみます。ツリー状の階層による分類ではなく、かといってリレーショナルデータベースのような手法とも違うやり方で、用語の修飾と分類を試みます。事前にスキーマを決める必要がなく、安直お手軽で、それでも実用性は保てる方法を目指します。
内容：
語彙目録と語彙エントリー
辞書、索引、用語集のような“組織化された言葉達の集まり”を総称して語彙目録〈lexicon | レキシコン | レクシコン〉と呼びます。言語学などではもっと精密な「語彙目録」の定義があるようですが、ここでは大雑把な定義でもいいとします。
辞書／索引／用語集のいずれでも、見出し語〈headword〉があり、その見出し語に対する説明があります。ひとつの見出し語に対する情報／記述を語彙エントリー〈Lexical entriy | 語彙項目〉と呼びます。
今、実在するかどうかは置いといて、理想的な語彙目録を想像してみましょう。ひとつの語彙エントリーには、特定の用語〈専門用語〉の意味が説明されているか、的確な参照先がちゃんと書いてあります。語彙エントリーさえ見つけてしまえば、我々は用語の意味を直接に、あるいは参照をたどって知ることができます。
問題は、見出し語だけでは語彙エントリーを特定できないことです。例えば、「同義語・多義語にホトホト困っている」で例に出した「フィールド」という言葉を見出し語とする語彙エントリーは幾つもあるでしょう。語彙エントリーを特定するために、「フィールド @ 物理」「フィールド @ 代数」「フィールド @ データベース」のように分野で修飾すればよさそうだ、という話をしました。
修飾されてない裸の見出し語に対して、その言葉の語彙エントリーはひとつとは限りません。逆に、ひとつの語彙エントリーの見出し語は複数あります。「フィールド @ 物理」の語彙エントリーには、「場」とか「field」も見出し語になっています。
対応する語彙エントリーがたくさんある見出し語は多義語だし、ひとつの語彙エントリーに対する複数の見出し語達は同義語（の集合）になります。“見出し語 ←→ 語彙エントリー”の対応は、一対一対応からはひどくかけ離れています。にも関わらず人は、一対一対応であるかのごとくに反応して誤解・曲解・混乱をします。
“見出し語 ←→ 語彙エントリー”の対応は単純ではないのですが、それでも出来るかぎりわかりやすく構造化・組織化する方法を考えましょう。
ツリー状階層化の問題点
「同義語・多義語にホトホト困っている」と「同義語・多義語の問題（続き）」で提案した曖昧性を解消する方法は、裸の用語を名前空間パスで修飾する方法でした。例えば、「属性 @ データベース/クリス・デイト」とか「インスタンス @ 型理論/単純型理論/Sets-as-Types」とかです。裸の用語は、名前空間ツリーの末端〈リーフ〉に配置されます。
この方法は伝統的ですが、問題点があります。原則として、（裸の）用語は、ツリー内の一箇所にしか置けません。もし、ひとつの言葉を二箇所以上に置きたいなら、異なるパスを同一視するような仕掛けが必要です。
「同義語・多義語の問題（続き）」より：
名前空間パスの同義性は、（知っているなら）ファイルシステムのディレクトリ間のハードリンクだと思えばいいでしょう。
ハードリンク（あるいはシンボリックリンク）のような、異なるパスが同じ場所を指すという状況はあまり気持ちいいものではなく、使い勝手は悪いです。
そもそもの話として、ツリー状の階層に分類するという行為は難しいのです。ツリー全体を見渡して、どこに用語を置くべきか、あるいは新しい名前空間〈用語を置くフォルダ〉を作るべきか、と考えなくてはならず、お手軽じゃありません。
お手軽なプライベート語彙目録には
名前空間ツリーを使うべき場面は確かにあります*1が、ツリーによる分類がふさわしくない場面もあります。例えば、語彙目録を（辞書作成のプロが作るようなものではなくて）カジュアルなものと捉える場合、難しい分類法はダメです。学習目的でプライベートに語彙目録を作るとか、数人の集団の合意形成とローカルルールとして語彙目録を作るとか、そんな使用目的の場合、難しいのはダメ、お手軽でないと。
「同義語・多義語の問題（続き）」において、「/型理論/圏論的/」と「/圏論/型理論への応用/」という2つのパスを例に挙げましたが、これは型理論と圏論が交差する分野ってことです。型理論と圏論のどっちを上位に置くか？ と考えることが無駄な負担になります。
階層的分類とは別な、リレーショナル・データベースのような手法もあります。曖昧多義語の曖昧性を解決するために、幾つかのフィールド*2を設けるアプローチですね。例えば、「分野」「分野細分」「品詞」「言語」「出典」のようなメタデータ項目を事前にスキーマとして決めておきます。まー、これもダメですね*3。スキーマを決めるのも守るのも難しいし、スキーマを途中で変更したくなってゴタゴタ・グダグダが“落ち”でしょう。
タグによる検索条件
名前空間ツリーを使うアプローチは、曖昧な見出し語を名前空間ツリーのパスで修飾することによって一意性を確保する方法でした。修飾付き見出し語を、語彙エントリーのID〈一意識別子〉とするわけです。
ツリー状階層とは別な、モノを分類する方法としてタギング〈tagging〉があります。モノにタグ〈分類タグ〉をペタペタと貼り付ける方法です。ひとつのモノにたくさんのタグを付けてもかまいません。
「/データベース/RDB/原理主義/」というパスの代わりに、タグの集合「{データベース, RDB, 原理主義} 」を考えます。タグの集合による修飾は次のように書くことにします。
- タプル @{データベース, RDB, 原理主義}
- フィールド @{データベース}
- 包括圏 @{圏論, 型理論}
タギングは、タグ修飾によりID〈一意識別子〉を作る発想ではありません。語彙エントリーを検索するため検索条件〈絞り込み条件〉としてタグを使うのです。したがって、タグは見出し語に付くというより語彙エントリーに付くのです。
見出し語「フィールド」だけで語彙エントリーを検索すると、複数のエントリーがヒットします。絞り込みをするためにタグ「データベース」が付いた語彙エントリーだけにすると、おそらくひとつだけの語彙エントリーに絞り込めるでしょう。
クリス・デイトの意味の「タプル」を説明する語彙エントリーに、「{データベース, RDB, 原理主義, クリス・デイト}」とタギングしておけば、「タプル @{クリス・デイト}」でも当該語彙エントリーを特定できます。
タギングの欠点は、お手軽さの裏返しとして、タグ名の選択が個人の主観になり、秩序に欠けたずんべらぼうな分類になってしまうことです。「タグの標準化をしよう」とか言い出すと事前にスキーマを決める発想と同じで、堅苦しくなり、お気楽・お手軽から離れてしまいます。
これはトレードオフの問題なんで、“秩序・厳格さ”と“お気楽・お手軽さ”は両立しません。“お気楽・お手軽さ”を優先するなら、ずんべらぼうなタギング方式となります。
長い見出し語
曖昧性解決な別な方法として、見出し語そのものを長くする方法があります。実際に使われていなくても、便宜上・人為的に長い見出し語を使います。例えば、「フィールドのあいだの順序がないレコード」とかです。人為的に付け足した修飾部と本来の見出し語を区切るためにカンマを入れることにすれば、「フィールドのあいだの順序がない,レコード」です。
短い見出し語「レコード」を持つ語彙エントリーは曖昧多義語のエントリーだとして、曖昧性を持たない複数の語彙エントリーへのリンク〈参照〉を持たせればいいでしょう。Wikipediaなどは実際にそうなっています。
曖昧多義語「レコード」の語彙エントリーから、「フィールドのあいだの順序がない,レコード」と「フィールドのあいだの順序がある,レコード」へのリンクがあることになります。「レコード」にもっと別な意味があれば、リンクは増えます。
目的の語彙エントリーにたどり着く方法として、前節で述べた“検索条件による絞り込み”と、曖昧多義語を見出し語とするエントリーからの分岐の2つの方法を準備しておくのは良いだろうと思います*4。
用語クラスターと同義関係
2つの用語が「概念的・意味的には同義である」という情報は、語彙目録にとって重要です。例えば「フィールドのあいだの順序がない,レコード @{データベース}」と「オブジェクト @{JSON}」は概念的・意味的には同義です。同義性を示すのは、双方向リンクを張るのがひとつの方法です。双方向リンクの実現が困難なら、同義語の対応表を別に（アウトオブラインで）作ればいいでしょう。
同義語の対応は、ひとつの用語と別なひとつの用語のあいだの対応とするだけでは不十分です。用語クラスター（用語の集合）と別な用語クラスターのあいだに同義語対応があると考えるべきです。
例えば、次の2つの用語クラスターを考えます。
- {関係 @{クリス・デイト}, 属性 @{クリス・デイト}, タプル @{クリス・デイト}}
- {テーブル @{データベース}, カラム @{データベース}, ロー @{データベース}}
これらの用語クラスターに属する用語には同義関係がありますが、6つの用語のあいだに3つの同義関係と捉えるよりは、2つの用語クラスターのあいだに以下のような対応（表の横方向）があるとみなすほうが適切でしょう。
| 関係 @{クリス・デイト} | テーブル @{データベース} |
| 属性 @{クリス・デイト} | カラム @{データベース} |
| タプル @{クリス・デイト} | ロー @{データベース} |
このような、用語クラスターのあいだの同義対応の比較的大規模な例は、以下の過去記事にあります。
- カリー／ハワード／ランベック対応の辞書
- 続・カリー／ハワード／ランベック対応の辞書
- まだある、カリー／ハワード／ランベック対応の辞書
- カリー／ハワード／ランベック対応の辞書： 推論規則再論
- カリー／ハワード／ランベック対応： チートシート
誤認・思い込みも語彙エントリーにする
動物事典に、架空の動物である龍や一角獣を載せることはないかも知れません。が、龍や一角獣は実在しないんだよ、という情報を含めることには意義があるでしょう。語彙目録には、誤認・思い込みから生じる言葉や勘違いした意味も入れておくのも意義がありそうです。
例えば、現在の集合論では原子〈atom〉という概念を使いません。したがって、「原子」という言葉は使わないし、「原子」に言及することもないでしょう。にも関わらず、原子を想定してしまっている人はけっこういます（致し方ない気がしますが）。それに伴い、「要素」と「原子」を同義だと思い、「集合」と「非原子」を同義だと思い込んでいる人もいます。（「モノの種別とモノの相対役割り」参照。）
こういう誤認・思い込みを警告するためには、「原子 @{集合論}」「非原子 @{集合論}」という語彙エントリーも必要です。これらの語彙エントリーでは、その概念がほとんど使われない（むしろ使ってはいけない）ことと、どんな誤認・思い込みがあり得るかも説明することになります。
おわりに
僕は、個人あるいは小規模な集団におけるローカルルールとしての語彙目録の必要性を強く感じています。言葉の解釈の食い違いや、言葉の印象からの連想・妄想は実に侮れないもので、コミュニケーションをすっかり破綻させてしまいます。
世間話なら誤解や行き違いがあってもさして問題にはならないかも知れませんが、正確な話をしたいときに、共有されるべき語彙〈ボキャブラリー〉が不安定だと文字通り「ハナシニナラナイ」のです。お気楽・お手軽にローカル語彙目録を作って共有できる手法や環境は必要です。
