キーワード索引機能

[akinomyoga]

索引機能についてです。PR #493 で議論 (by @akinomyoga, @saki7 ) が出ていたので、実際に実装するかはともかくとしてここに議論の経緯を記録としてまとめておこうと思います。

@saki7 さんは既に去ってしまったので、かなり私本位の内容になっているということ予め御承知下さい。

---

背景

cpprefjp のサイト中で "未定義の動作" や "処理系定義" などのキーワードが出てきたときに、(Google で検索することなく) その解説が載っているページ (標準規格と処理系) に移動できるようにすると便利。

またキーワードの定義箇所での見た目(装飾)を簡単な方法で統一したい (現状は執筆者に任せられている。例えば、特に装飾なく記述されている場合、鉤括弧で囲まれている場合、太字にする場合がある)。

方法: 索引情報

キーワードとそれが定義されているページ・節のデータベース (索引情報) を生成。生成方法は半自動・全自動など色々考えられる。この索引情報を利用して以下の機能を提供することができる。

• 検索 (キーワードジャンプ) 機能: 右上の検索窓に入力した単語が、索引情報にあるキーワードに一致しているとき、その定義箇所 (ページ・節) に直接ジャンプする。
• 自動リンク機能: 任意の記事の本文中に現れるキーワードについて、自動でその定義箇所へのリンクを貼る (Hatena Blog や Weblio がやっているような、点線の下線で控えめに表示されるリンク)。
• 索引ページ; 索引ページ (キーワードを 50 音順に並べたページ) を自動生成する。
• 定義語の装飾: キーワードの定義箇所は HTML 生成時に特別な class 属性などを付加し、cpprefjp 全体の CSS で見た目を制御できるようにする。

詳細に関して以下のような提案があった。

• 自動リンクを貼るのは、そのキーワードがページで最初に登場したときだけで良い。 by @saki7
• 検索・自動リンクでジャンプする先は、そのキーワードではなく、そのキーワードを含む節の先頭に移動するべき。 by @saki7

(個人的にはこれらの提案についてはもう少し議論が必要と感じている)

議論: 索引情報の生成方法について

マークアップ案 by @akinomyoga

キーワードの定義箇所で <dfn>～</dfn> などの専用のマークアップを行う (因みに、現在 HTML の <dfn> タグを使っている記事は cpprefjp にはない)。索引情報の生成は <dfn></dfn> で囲まれた語を収集するだけで良い。

• 補足: 索引ページのためには読みを <dfn yomi="みていぎのどうさ">未定義の動作</dfn> などの記法で提供する必要がある (勿論、実際の HTML 生成の際にはこれらの非標準属性は排除するか data-cpprefjp-yomi などに置換する必要がある)。
• 類例: C++ の規格 PDF では、\defn{...} などの TeX コマンドで指定されたキーワードを集めて索引を生成している。
• 類例: Microsoft Compiled HTML Help (.chm) では、人がキーワードとページの対応を登録する (GUI が用意されているが、XML ソースを直接編集することも可能)。

※以降、簡単のため専用のマークアップを仮に <dfn>～</dfn> とすることにする。実際には別の形のマークアップにする余地は残っている。

• → @saki7: 新しい記法・規則を導入して、キーワード定義箇所を <dfn></dfn> で囲まなければならないとするのは、編集者の負担になる。
  • → @akinomyoga: キーワードを囲むことを強要するものではない。索引に登録すると便利そうなキーワードから少しずつ <dfn></dfn> で囲んでいけば良いのではないか^[注1]
• → @saki7: 形態素解析の枠組みが必要
  • → @akinomyoga: (自動リンクを貼るのは) 単に正規表現なりで一致させれば良いだけのはずで、形態素解析までする必要があるとは思われない (有用性が伝わっていないかもしれないので、念のため書くと chm や C++ 規格 PDF でも索引の枠組みがある)。
    • → @saki7: 「chm とか Adobe Readerとかは内部で形態素解析に準じる何かの自然言語処理を自動でやっていてそういう機能が見えているはず」
      • → @akinomyoga: .chm も Adobe Reader もそんなことはやっていない (上記類例を参考のこと)

形態素解析案 by @saki7

(記事中に何のマークアップもなくても) 形態素解析によって何がキーワードであるかを判定 (特徴語抽出) し、更に何処で定義されているかを検出することができる。

• → @akinomyoga: そんなことができるとは思えない。例えば、抽出した単語 (例: "未定義の動作") が C++ 用語であるということをどうやって判定するのか。
  • → @saki7: "未定義の動作" は係り受け解析によって一つのまとまりであることを検出できる。
    • → @akinomyoga: 聞きたかったのは複数文節に跨るキーワードの取り扱いではなくて、抽出したキーワードが (1) 一般的な日本語なのか (2) 一般的な情報技術関連の単語なのか (3) C++の専用単語なのかについて、どう区別をつけるのかということ。事前に、(1) と (2) の「完全」な辞書が必要になるのではないか (そしてコーパスや専門用語まで含めると「完全」なものを用意するのは困難)。
• → @akinomyoga: 更に、そのキーワードが定義されている箇所はどうやって特定するのか^[注2]
  • → @saki7: 一番記述が多いものがそのキーワードが定義されている記事だとすれば良い。
    • → @akinomyoga: そうだろうか。
• → @akinomyoga: 精度がそんなに出るとは思えない (中途半端な自動化は機械翻訳と同様に煩わしい)
  • → @saki7: 「『だいたい合ってる』とかそういう世界観で良ければ、NLPに関してずぶの素人の僕でも出せる精度だと思います。」

折衷案

形態素解析の結果を人力でフィルタリングし形態素解析に対する補助情報としてマークアップを提供するという形で、形態素解析の精度を補うということも考えられるかもしれない。ただ、そこまでして形態素解析を使うことなのかという疑問は残る。

索引情報を手動で管理する案

現実的ではない気がするが一応1つの可能性として書いておく。キーワードとキーワードの定義位置 (ページ.md#id) の表を手動で管理。キーワードの定義位置と、索引情報の登録の記述位置が異なるので管理が面倒になりそう。

議論: 自動リンクの張り方: 静的 or 動的

• @akinomyoga: 動的に (ブラウザ側で) 行えば良いのでは。
  • → @saki7: ブラウザがダウンロードする索引情報が大きくなるので避けたい。静的に解決すれば良い。
    • → @akinomyoga: 確かにそうだ。

今改めて考えると、検索窓にキーワードを入れた時のジャンプに対応するためには、結局索引情報はダウンロードする (もしくは外部サイトでクエリを処理する) 必要があるので、微妙なところ。

あと、静的に処理するとすると、全記事について [(1) キーワードの抽出] が完了してから、[(2) 記事をHTML へ変換] するというように two phase の処理が必要になりそう (もしかすると、現状で既にそれに準じる複雑な処理になっていて余り気にしなくても良い、という状況かもしれませんが)。

---

1. ^ 先の議論では形態素解析の方に話が流れたので、これは明確に主張しなかった。つまり @saki7 さんに反論の機会が与えられなかったことに注意する。
2. ^ 定義箇所を特定するには、日本語の構文解析・意味解析まで実行しなければならないのではないか。特に「～を未定義の動作という」「未定義の動作を～とする」などの形をしている場合はまだ良いが「未定義の動作は～である」などの場合には文脈解析(?)まで行って、それが定義なのか叙述なのかを判定しなければならないのではないか。それが現在の自然言語処理の技術で実行できるのだろうか。

[faithandbrave]

私は作業リソースがなくて、この件について具体的な作業は当分できないと思いますが、設計案として。

• GLOBAL_QUALIFY_LIST.txt のようなデータベース用のファイルを用意して、それを用語集とする (JSONやYAMLのようなフォーマット)
• 用語集のファイルから、用語解説用のHTMLページを自動生成し、コードブロック以外の文章からキーワードを探して自動リンクする

これくらいなら、作業量として少なく済むのではないかと思います。任意の場所で用語定義できるようにするのは、機能としてリッチすぎるように思います。分野ごとに用語がたくさん定義されてきたら、分類すればいいのではないかと思います。

[akinomyoga]

ありがとうございます。そうですね。確かに、単純な仕組みでも十分ということになるかもしれないので、取り敢えずは簡単に実装していくというのが良さそうです。

[faithandbrave]

@akinomyoga こちら完了としてよいでしょうか？

[akinomyoga]

恐らく実装する必要性も出てこなそうなので閉じて大丈夫です!

完了かというと完了ではない気がしますが。#977 の冒頭にも書きましたように #977 は https://github.com/cpprefjp/site/issues/510#issuecomment-354239755 の更に部分実装に過ぎません。もともと考えていたのは <dfn> の収集と索引ページ (本の最後にあるようなキーワード & ページ番号の一覧表) の生成も含めてなのでした。