昨日の記事「同義語・多義語にホトホト困っている」の続きです。
内容：
名前空間の階層構造
昨日の記事で、見た目・字面では区別できない用語も、分野で修飾すればいい、と言いました。次の事例を挙げました。
- フィールド @ 物理
- フィールド @ 代数
- フィールド @ データベース
これは次のような書き方もできます。
- /物理/フィールド
- /代数/フィールド
- /データベース/フィールド
ファイルシステムのフォルダ〈ディレクトリ〉／ファイルと同じことです。同じ名前のファイルでも、異なるフォルダにあるなら問題ない、ということです。フォルダに相当するのものが名前空間〈namespace〉で、ファイルに相当するのが用語〈専門用語〉です。
名前空間がいわゆる“分野”である必要はありません。例えば、圏論に関して、オックスフォード大学のグループとMIT〈マサチューセッツ工科大学〉のグループは違う用語法を使っています。組織や地域による方言があるのです。となると、次のような名前空間を作るのがよいかも知れません。
- /圏論/オックスフォード/
- /圏論/MIT/
実際のところ、本／論文／人により用語法は違ってしまうので、個別の名前空間を準備すべきかも知れません。
- /圏論/教科書A/
- /圏論/論文X/
- /圏論/人物P/
昨日の記事で、データベースの用語に関して、/データベース/RDB/原理主義 という名前空間を使いましたが、あの用語法はクリス・デイト（人物）のものです。なので、次の名前空間を設けるほうが適切そうです。
- /データベース/クリス・デイト/
名前空間のパス名もまた用語であるので、同義なパス名が生じます。例えば：
- /データベース/RDB/原理主義/ ≡ /データベース/クリス・デイト/
分野の名前であっても、同義となることがあります。
- /型理論/圏論的/ ≡ /圏論/型理論への応用/
「包括圏」「C-システム」などの用語は、型理論の下にも、圏論の下にも配置されます。
- 包括圏 @ 型理論/圏論的 ≡ 包括圏 @ 圏論/型理論への応用
- C-システム @ 型理論/圏論的 ≡ C-システム @ 圏論/型理論への応用
名前空間パスの同義性は、（知っているなら）ファイルシステムのディレクトリ間のハードリンクだと思えばいいでしょう。
どこの誰がどんな言葉使いをしているか？ に興味がないなら、本／論文／人などで名前空間（用語のフォルダ）を作る必要はありません。例えば、ある集団内で使う用語法の規範を決めるのであれば「俺達はこれを使うぞ」でいいわけで、出典・ソースは不要です。決めた約束を集団内で守ればいいだけです。
「同義語・多義語にホトホト困っている」より：
分野／コミュニティ／流儀や用法で用語を修飾するということは、用語を収納する名前空間の構造を決めるということです。多くの人が納得するような、名前空間の組織化は難しいですね。
ひとつの名前空間ツリーを決めるのは無理です。目的・用途ごとに名前空間ツリーを準備する、ということになりますね。
用法と用語のクラスタ
昨日の記事で、名前空間ツリーだけではうまく処理できない例として「要素」と「インスタンス」の同義性の問題を挙げました。用法というのは、単一の用語だけで済む話ではなくて、複数の用語達のあいだの同義性とかデフォルト規則に関わることです。
用語の集まりを用語のクラスタ〈cluster〉と呼ぶことにします。例えば、次の3つの用語のクラスタを考えます。
- 環 @ 代数
- 可換環 @ 代数
- 非可換環 @ 代数
分野「代数」の修飾は省略して、クラスタ（有限集合です）を {環, 可換環, 非可換環} と略記します。用法の違いのひとつの定式化は、同義関係が違うことです。
用法1 :
- 環 ≡ 非可換環
- 環 =✗= 可換環
用法2 :
- 環 ≡ 可換環
- 環 =✗= 非可換環
圏論で出てくる集合のサイズも、似た事情です。
- 小さい集合 @ 圏論
- 大きい集合 @ 圏論
- 小さくない集合 @ 圏論
- 小さくないかも知れない集合 @ 圏論
用法1 :
- 大きい集合 ≡ 小さくないかも知れない集合
- 大きい集合 =✗= 小さくない集合
用法2 :
- 大きい集合 ≡ 小さくない集合
- 大きい集合 =✗= 小さくないかも知れない集合
当然ながら、異なる用法を前提している二人の人のあいだではコミュニケーションがうまくいきません。
クラスタと同義性の別な利用法があります。次の2つのクラスタを考えます。
- {フィールド @ データベース, レコード @ データベース}
- {属性 @ データベース/クリス・デイト, タプル @ データベース/クリス・デイト}
これらのクラスタは、一緒に使われることが多い用語達を表します。「フィールドとレコード」「属性とタプル」という組み合わせはよく使われますが、「フィールドとタプル」「属性とレコード」はほぼ使われないのです。しかし、名前空間をまたがった同義性はあります。
- フィールド @ データベース ≡ 属性 @ データベース/クリス・デイト
- レコード @ データベース ≡ タプル @ データベース/クリス・デイト
クリス・デイトは「レコード」と「タプル」は違う（同義ではない）と主張してます。それは、レコードのフィールドのあいだには順序があるが、タプルの属性のあいだには順序がない、という根拠です。しかし、レコードのフィールドに順序を入れるかどうかは流儀の違いです。流儀の違いは用法の違いで表しましょう。
用法1 :
- レコード ≡ フィールド順序付きレコード
- レコード =✗= フィールド順序無しレコード
用法2 :
- レコード ≡ フィールド順序無しレコード
- レコード =✗= フィールド順序付きレコード
用法2のもとでの「フィールド」「レコード」は、クリス・デイトの「属性」「タプル」と確実に同義です。
- 用法2.フィールド @ データベース ≡ 属性 @ データベース/クリス・デイト
- 用法2.レコード @ データベース ≡ タプル @ データベース/クリス・デイト
これでいいのか？
名前〈ラベル | 記号〉達をツリー状に階層化された名前空間で分類することは、よく使われる伝統的な方法です。すべての名前の集合の一部（ここではクラスタと呼んだ）に注目して、その一部にだけ通用するルール（同義性やデフォルト規則）を考えるのもよく使われる方法です。
同義語・多義語の処理に関して、無難な方法を採用したのですが、それが最良かどうかは分かりません。もっと良い方法があるかも知れません。例えば、ツリー状の分類は難点もあります。代わりにタギングによる分類を試してみる価値はありそうです。
いずれにしても、たくさんの用語達を、無構造に寄せ集めただけでは破綻することは分かっているので、構造化・組織化は必要です。構造化・組織化の決定版はないのが実情です。
