デジタル語彙目録における“管理された名前”〈managed name〉は、何らかの対象物を一意非曖昧に名付けるために使う人工的な名前です。通常のコミュニケーション内で管理された名前を直接使うことは意図してません。通常のコミュニケーション内で使う用語〈テクニカルターム〉を統制するメカニズムとして管理された名前を使います。
デジタル語彙目録のWeb公開の実験をしてみて、管理された名前の構造と管理方法に関して再考の必要に迫られました。そのことをこの記事に記します。
内容：
ハブ記事：
再考に至る経緯
「デジタル語彙目録:: Obsidian Publish によるWeb公開」に書いたように、ローカルに作った語彙目録をWebに公開してみました。Webから語彙エントリーにアクセスしてみて、次のことを感じました。
- 管理された名前〈managed name〉が、URLそのものだと具合がいいのに。（そうはなってない。）
- ページの目次に何の情報もない。これじゃ、あってもなくても同じ。
管理された名前とURLが別なのは、「別なほうがいい」という判断のもとにそうしました。が、実際に使ってみて、この判断は間違ってたかも？ と思いました。
ページの目次に情報がないのは、メカニズム上致し方なくて、そうなっています。メカニズムを変更して改善できる可能性はあります。
4種類の名付け方式
我々は、次の4種類の名付け方式を相手にして、名前の変換を考えなくてはなりません。
- コンピュータのOSが提供するファイルシステムの命名方式
- デスクトップ・アプリケーションである Obsidian が提供するフォルダーとノートの命名方式
- Web上のURLによる命名方式
- 概念的・抽象的な“管理された名前”の命名方式
OSファイルシステムと Obsidian アプリケーションのあいだの名前の対応は比較的に簡単です。
- Obsidian におけるパス区切り記号はスラッシュを使う。
- Obsidian 保管庫〈vault | ボルト〉からサブディレクトリへの相対パスをフォルダーパスとする。
- Obsidian 保管庫〈vault | ボルト〉内のMarkdownファイルへのファイル名から拡張子
.mdを除いた名前をノート名とする。
例えば、Windows PC における保管庫のパス名がC:\Users\m-hiyama\MyObsidianVault\ だとすると、OSのパス名と Obsidian のパス名は次のように対応します。
C:\Users\m-hiyama\MyObsidianVault\←→/C:\Users\m-hiyama\MyObsidianVault\Descriptions\←→/Descriptions/C:\Users\m-hiyama\MyObsidianVault\Descriptions\Semigroup.md←→/Descriptions/Semigroup
Obsidian Publish を使うと、ローカル保管庫のパス名がそのままURLに反映されます。Web上のサイトURL がhttps://publish.obsidian.md/chimairaだとすると、Obsidian のローカル保管庫パス名とURLは次のように対応します。
/←→https://publish.obsidian.md/chimaira/（https://publish.obsidian.md/chimaira/indexにリダイレクトされる）/Descriptions/←→https://publish.obsidian.md/chimaira/Descriptions/（都合により 404 Not found）/Descriptions/Semigroup←→https://publish.obsidian.md/chimaira/Descriptions/Semigroup（ページにアクセス可能）
なお、https://publish.obsidian.md/chimaira は現在実験に使っている実在のURLですが、将来変わる可能性があります（変わらないかも知れないけど）。
以上のように、OSのディレクトリ／ファイルのパス、Obsidian のフォルダー／ノート名、Obsidian Publish のURLの三者のあいだには機械的な変換ルールがあります。問題は、“管理された名前”との対応です。
管理された名前、主題名
ここで、デジタル語彙目録について語る用語法を、次のように変更します。
- 見出し語〈headword〉 → 主題名〈subject name〉
- 管理名〈managed name〉 → 管理された名前
- ネーム → 主題名
再度、用語を整理しましょう。
デジタル語彙目録〈digital lexicon〉は、Obsidian 保管庫として作成します。保管庫内のすべてのノートが語彙エントリーではありませんが、語彙エントリー〈lexical entry〉は必ずノート（Markdownファイル）です。
「同義語・多義語の問題： タグによる修飾と分類」においては、語彙エントリーで説明すべき語を見出し語〈headword〉と呼んでましたが、「見出し語」はやめて主題名〈subject name〉とします。
主題名は、語彙目録内で扱うべき主題〈サブジェクト | 件〉の名前なのですが、人工的な名前です。つまり、「デジタル語彙目録:: こんな感じ（中間報告）」で導入した管理名〈managed name〉です。
概念に付けられた名前/Basic/SurjInjDecompは、ソフトウェアで管理される管理名〈managed name〉です。「デジタル語彙目録:: 名前の管理」で述べたように、管理名はURIとします。ネームのパス名だけでなくて、名前空間ツリーに責任を持つ組織や個人を識別するプレフィックスを付けます。
例えば、
https://www.chimaira.org/hiyamaがプレフィックスの例です。
ただし「管理名」は、より分かりやすい日本語「管理された名前」に置き換えます。主題名だけが管理された名前ではなくて、プレフィックスや名前空間名〈namespace name〉も管理された名前です。基本的な“管理された名前”を組み合わせて長い“管理された名前”を作ります。
「主題名」とまったく同義である言葉は、「デジタル語彙目録:: こんな感じ（中間報告）」で使った「ネーム」です。
概念に付けられたASCII文字列の名前をネームと呼ぶことにします。漢字の「名前」とカタカナの「ネーム」は、ここでのテクニカル・タームとしては別な意味です。「名前」は一般的な識別子のことで、「ネーム」は語彙エントリーが主題として扱う概念に付けられたASCII文字列の名前です。
「ネーム」はさすがに混乱しそうなので、「ネーム → 主題名」と変更します。
主題名の完全修飾名〈fully qualified name〉は、例えば次のようです。
https://www.chimaira.org/hiyama:;/Algebra/LinearAlgebra/Kernel
ここで：
https://www.chimaira.org/hiyamaはプレフィックス- コロン＋セミコロンはプレフィックスと名前の区切り記号（今、とりあえずテキトーに決めただけ）
/Algebra/LinearAlgebra/は名前空間パス、Algebra、LinearAlgebraは名前空間名Kernelが主題名のローカル名（修飾されてない裸の名前）
短い名前 Kernel だけでは一意非曖昧になりません*1が、長い完全修飾名なら一意非曖昧に概念を指すことができるだろう、ということです。
長い完全修飾名によりあらゆる事物に名付けするという発想の起源は：
「デジタル語彙目録:: 名前の管理」より：
「現実世界の事物であれ概念的事物であれ、モノに一意的な名前を付ける」ことは、ティム・バーナーズ＝リーが提唱する大原則です。一意的な名前としてはURIを使います。
名前空間による主題名の修飾
当初僕は、語彙エントリー（である Obsidian ノート）のパス名と、主題名の修飾名〈qualified name〉は独立のほうがいいだろう、と考えました。フォルダーと名前空間とは別々に扱い、相互に関連させるメカニズムを作る方針でした。相互に関連させるメカニズムについては「デジタル語彙目録:: こんな感じ（中間報告） // 名前空間」に概要を書いています。
この方式は、ローカル環境ではまーまーうまくいくのですが、Webからの利用だと名前空間を認識できません*2。やはり、名前空間パスをURLに埋め込んだほうがいいな、と考え直しました。
そうなると、ローカル保管庫のフォルダー名がそのまま名前空間名になります。諸々の事情から、まったくそのままでは辛いので、/Entries/Algebra/LinearAlgebra/ が名前空間パス /Algebra/LinearAlgebra/ に対応すると決めます。保管庫で作業する段階で、名前空間パスに相当するフォルダーの下に語彙エントリーを作ることになります。
では、ノート名はそのまま主題名となるのか？ というと、それは厳しい。もちろん、ノート名＝主題名 だとハッピーなのですが、1つの語彙エントリー（ノート）に2つ、3つの主題を詰め込んだほうが分かりやすいときもあります。細切れの語彙エントリーのあいだをリンクでたどるのはけっこうウザい。
というわけで、ノート名＝主題名 は諦めて、ノート〈Markdownファイル〉内の見出し〈ヘディング〉に主題名を書きます。見出しテキストには、単に主題名だけでなくて、その主題の種別〈カインド〉も書きます。例えば、線形代数の「核」が主題なら、その主題を表す見出しテキストは次のようです。
type Kernel
typeは、Kernelと呼ばれる概念が、型理論の意味での型〈type〉として記述・定義されることを示します。
もし、線形代数の「核」と「像」を同じ語彙エントリー（ノート）Kernel Imageで説明しているとするなら、線形代数の「核」を表す主題名のURLは次のようになります（説明用の例なので、実在するとは限りません）。
https://publish.obsidian.md/chimaira/Entries/Algebra/LinearAlgebra/Kernel+Image#type%20Kernel
主題名はフラグメントIDの一部に埋め込まれます。
このURLのなかで、Entries、Kernel+Image、typeは、概念的・抽象的な完全修飾名としては不要なものなので、削り落とせば次のようになります。
https://publish.obsidian.md/chimaira:;/Algebra/LinearAlgebra/Kernel
Webページへのアクセスに使うURLと概念的・抽象的な完全修飾名は、まったく同じ名前ではないですが、容易に変換できるのでいいとしましょう。
ラベルとブロックID
「デジタル語彙目録:: 名前の管理」で半群の例を出しました。半群はSemigroupという主題名だとして、その主題〈サブジェクト〉にアクセスするためのURLが次だとします（説明用の例なので、実在するとは限りません）。
https://publish.obsidian.md/chimaira/Entries/Algebra/Semigroup#type%20Semigroup
主題を説明する語彙エントリーのなかで、さらに細かい名前が使われます。「デジタル語彙目録:: 名前の管理」の表を再掲すると：
| 管理された名前 | 用語 |
|---|---|
carr |
台集合〈underlying set | carrier〉 |
binOp |
二項演算〈binary operation〉 |
assoc |
結合律〈associative law〉 |
主題名の配下に出現する carr、binOp、assoc なども管理された名前であり、ラベル〈label〉と呼ぶことにします。
URLにより、ラベルの出現位置に直接リンクを張れるでしょうか？ なんと出来るのです。ただし、Obsidian と Obsidian Publish 固有の機能にベッタリ依存します。ラベル carr へのリンクは、次のような特殊なフラグメントIDを使います。
https://publish.obsidian.md/chimaira/Entries/Algebra/Semigroup#^carr
Obsidian では、ブロックと呼ばれる単位ごとにIDを付けられます。例えば、箇条書きの各箇条項目はひとつのブロックなので、IDをふれます。ラベルが出現するブロックにラベルと同名のIDを付けておけば、ラベルへの参照が作れます。ただし、ブラウザが特殊なフラグメントIDを理解できるわけではないので、Obsidian Publish サイト内部でだけ有効なリンクです。注意してください。
ラベル（のあるブロック）を参照するURLは、だいたいラベルの完全修飾名と考えていいでしょう。「だいたい」なのは、ラベルは主題名〈サブジェクト名〉の配下にあるんですが、ラベルのURLから主題名を知る手段がありません。ノート名と主題名が一致するときは、ラベルの完全修飾名を機械的に作れます。今のケースはノート名と主題名が一致しているので、ラベルの完全修飾名（ロケーションではなくて、概念的・抽象的な名前）は次のようになります。
https://publish.obsidian.md/chimaira:;/Algebra/Semigroup#carr
ちなみに、Obsidian では、ブロックIDにアンダースコアを許してないので、管理された名前に許される文字からアンダースコアは除外する必要があります。みずからベンダーロックインされにいってる*3ようですが、Obsidian 以外の道具が見当たらないので致し方ない。
ページ目次の問題
Obsidian Publish のページには目次が表示されます。見出し〈ヘディング〉テキストを抜き出しているのです。現状、語彙エントリーのページで見出しが自由に付けられず、したがって、まともな目次が出せません。これは、ローカル側のメカニズムに起因する問題です。
ローカル側のメカニズムとは、「デジタル語彙目録:: 野生の言葉達と索引」で紹介した用語索引を作る機能とかです。詳しい事情の説明は（めんどくさいから）省略します。
まともな目次を出すためには、ローカル側の仕掛けをすっかり作り直さないといけないのですが、やれば出来そうだし、一度やればいいことなので、作り直すつもりです。
用語はURLを持たない
デジタル語彙目録の語彙エントリーに出現する名前はニ種類あります。
- 管理された名前〈managed name〉： 対象物を一意非曖昧に名付けるために使う人工的な名前。主題名とラベル、それらの名前空間による修飾名。
- 用語〈テクニカルターム〉： 通常のコミュニケーションに使う自然言語由来の名前。
語彙エントリー（であるノート）、主題名、ラベルには、インターネット上で一意〈ユニーク〉なURLが付与されました。例えば次のように（説明用の例なので、実在するとは限りません）：
https://publish.obsidian.md/chimaira/Entries/Algebra/LinearAlgebra/Kernel+Imagehttps://publish.obsidian.md/chimaira/Entries/Algebra/LinearAlgebra/Kernel+Image#type%20Kernelhttps://publish.obsidian.md/chimaira/Entries/Algebra/Semigroup#^carr
では、「核」、「半群」、「台集合」などの用語〈テクニカルターム〉もURLを持つべきでしょうか？ 僕は不要だと思います。より具体的に言うと、用語の意味を知りたいときは、https://publish.obsidian.md/chimaira/ の検索機能で用語の文字列を全文検索すりゃいいだろう、と。
語彙エントリーや用語の数がすごく増えたときに、Obsidian Publish の全文検索がまともに動くのか？ ちょっと心配ではありますが、当面は小規模な検索なので問題ないでしょう。
おわりに
何度か同じ引用をしてますが：
「デジタル語彙目録:: 名前の管理」から：
ありていに言って、デジタル語彙目録作成は、
$`\qquad`$ひたすら名前との戦い
です。
戦いなのですが、戦いが一段落すれば、一意非曖昧な参照の体系を手に入れることが出来るでしょう。
*1:「核〈kernal | カーネル〉」という言葉は、線形代数だけでなく積分核やマルコフ核でも使います。統計で使う場合、Wikipedia項目「カーネル (統計学)」の冒頭に曰く「カーネル（英: kernel）は、統計学において複数の異なる意味に用いられる語である。」
*2:語彙エントリーの namespace リンクをたどった先のパス名から推測はできますが、まどろっこしい。
*3:Obsidian の設計思想は、ベンダーロックインとは対極的なのですが、そうはいっても独自機能に依存すれば他のソフトウェアでは処理できなくなります。
