:i/検索のバックアップ(No.26)

to your Kindle

目次 †

目次
関連
検索周辺のタグ
検索
思い付き
実装
設計
1. アルゴリズム
2. 解釈
懸案
1. 処理とデータの型

検索周辺のタグ †

Array

検索 †

検索はページに書かれた情報を活用する機能。
ページには単純な構造で十分な情報を。その情報をつなぎ合わせるのが検索。
自動生成されるページは検索機能によって作られる。
動的に生成されるページは検索機能を使ったもの。

オブジェクト生成
検索/クエリー
評価
検索/フィルタリング
検索/スコアリング
ページ化
検索/ソート
検索/フォーマット

※いずれも検索/クエリーで作ったオブジェクトの機能で。

思い付き †

カタカナ語の「ー」を除いたものも検索。
:t/実現可/易[?]
ユーザーが定義した略語、用語も検索。
:t/実現可/難[?]
検索結果を利用してアクセス解析。
ページ構成を考えるときの参考に。
:t/実現可/易[?]
ページをページ名で指定、さらにその中を検索、最初の候補にジャンプするような検索もしたい。
柔軟なリンクとして。ページ名の一覧表示ではいけない。
内容が表示される検索。内容が表示される検索ではページを特定（ページ1つだけを表示）したほうが読みやすい。

使い方 †

閲覧と作成と検索の操作を統合。

入力欄に(見たい|書きたい)ページ名入力。Enter。
ページがあれば表示。（見ることができる）
ページがなければ「もしかして・・・」と新規作成リンク（または新規作成フォーム）を表示。（検索と書くことが両方できるし、書くときの参考資料も分かる）
新規作成フォームでは1行目がページ名。

「まとめておきました」 †

検索機能でWikiページをまとめると、その検索/クエリーは新しいページの名前のようなものになる。
このページを誰かの利用者ページや他サイト（ブログ、他のWiki）から参照できるようにすれば個人的な（読むだけ）Wikiを作ることができる。

「このWikiの再編後に残すページをまとめておいたので、意見があれば自分の利用者ページに「再編について」という見出しで書き込みしてください」
「Wikiに残っている履歴からこのアイテムの1月〜6月の相場価格を抜き出したところ、4月あたりから乱高下しているのが分かりました」
…などのように活用したい。

「同時に更新したページ」 †

条件を与えると一覧表示。（同じページにあるフォームで）
※URLクエリーに条件があればすぐに一覧表示。

条件はページ名（ということはディレクトリ名も）、章名、日時の範囲、関連付ける期間

編集の衝突も検索できる。

スコア加算条件を複数に †

「ホットな記事、クールな記事」の「ホット」は検索スコアに加味する要素のこと。
だから他の評価方法(これも加味する要素のこと)と併用できるように。

似ているページ報告 †

利用者がページ間のつながりを変える。
→これはページ内のリンクにタグを付けることで行う。
「関連項目」とでも書いておけばいい。

類似した情報を見つけることで利用者間のスケジュール調整とかアポイントメントに。

実装 †

AND、ORを使わない †

検索は検索クエリーをページ構造と同じ構造のオブジェクトに変換、類似度判定で実現。
そのため、ANDやORは使えない。代わりに必須かオプションかを検索キーワード毎に指定。

語1 語2 語3？

…で、語1と語2を含むページを指定、語3まで含むものを上位に表示。

語1 AND 語2 OR 語3

…などは表現できないので、代わりに

語1 語2

語3

…に分けることになる。

必須	（何もつけない）か、語頭か語尾に「！」
オプション	語頭か語尾に「？」
不要	語頭か語尾に「－」

インデックスを作るなら別プロセスで †

インデックスを作成・更新するなら別プロセスか、本体プロセスの余り時間に。
ページを更新するたびに必要、かつページの更新処理には不要なので。

インデックス再作成を要する操作→インデックス再作成完了までの間、更新されたページ（インデックスに入っていないドキュメント）はインデックスなしの全文検索の対象にする。

ヒットする対象は1オブジェクトだけ †

複数のオブジェクトにヒットしたら最も高いスコアになるものだけに。
継承ツリーとは無関係に。

100キロ

数字
重さ
距離
データ量

…などのいずれとしても解釈できるし、上下関係は無い。
Element系クラスは継承関係で表現できない。

たくさん合えばスコア増 †

RegExpのグループに合った数だけスコアを増やす。

/([0-9]+)(キロ)?/

…なら0〜2コのグループに合う。
→スコアを0〜2倍に。

こうして単位（キロ）を含めて合った場合に高スコアにできる。

検索 履歴 †

検索フォームで
利用者×ページ×検索ワード
を保存。
「自分が…というページを読んでいるとき検索したくなったこと」が…というページの検索フォームにリストアップされるように。

タグ付け、リンク付けの参考になる
:t/タグ :t/リンク
二度手間を減らすことにもなる
:t/手間を省く[?]

保存する領域は利用者。
利用者ページに記録する。
ということで、利用者自身が編集できる。(追加も削除も)

検索はフレームワークの機能 †

プラグインから呼び出すように。

用語集を使って関連語 検索 †

検索時、用語集（というページ）にある用語が見つかれば同義語・関連語も検索。
または同義語・関連語を検索するためのリンクを併せて表示。

→検索/クエリーがリンクに適合した場合、リンクをリンクのまま表示。というだけ。

個人用の用語集も作れて、それを検索でも利用できれば理想的。
利用者の下位にページを作って。

「あれ」→定義によって特定のページが表示される。

これで、公式のページ名以外のキーワードでページを指定できる。
検索機能の活用法が多彩になれば思いがけない使い方ができそう。

入力されたキーワードを関連付ける †

主観検索のために。

検索キーワードのOR結合を同義、AND結合を上下関係のある言葉として検索時に使用。
検索処理内で使うか、検索結果に関連語として表示するか。

OR結合の結果は切る †

検索でOR結合がある場合、結果1件ごとに合った検索ワードを併記。

検索キーワードをリンク化 †

再利用しやすくなる。

検索 ページ †

検索/クエリーを検索プラグイン呼び出しに書き入れると出力が（参照時の）検索結果になる。
例えばタグ[Wiki]のページを作ると、タグ[Wiki]を含むページの一覧になる。

検索は集約 †

検索はページを集約する機能でもある。
検索/クエリーに適合したページを1つのページにまとめる。
検索結果を検索すれば集約をさらに集約することになる。

検索結果をRSS化 †

検索/フィルタリングで実現。

他ページのリソースを取得するプラグインと、RSSを解析するプラグインでRSSをページ化。
他サイトのリソースを取得するプラグインはあっても良いがRSS取得のためなら要らない。

1ページ、1ソート順 †

ソート順が違うなら別のページに。
そうしないと自動処理しづらい。

→検索/クエリーのリスト1つあたり1ページに。

フィルタリング、変換 †

検索フォームからの入力
フィルタリング、変換→検索クエリー
ページ
フィルタリング、変換→検索用ページ
検索クエリーと適合した検索用ページのみ検索結果に追加する
検索結果をソートする

…を検索/クエリーの数だけ繰り返す。
フィルタリングルール、またはソートルールだけの検索/クエリーも可能。

UIでフィルタリング、変換のルールを指定したりしない。面倒になる。
プラグインを作ることで利用可能に。

日記を特定のキーワードで検索して「その1日前に何をしていたか」を一覧したい †

→検索結果1件ごとに「1日前」というリンクを辿って、その1件をリンク先と置き換える。
→検索結果からそれぞれの1日前のページ一覧を作れる。
…というのをフィルタリングルールで。

フィルタリング1回目
全ページからキーワードを含むページのみを得て、それを結果へ。
フィルタリング2
結果から「1日前」というリンクを得て、それを展開して、結果へ。
展開はリンク→リンク先のページをするプラグインを使って。
フィルタリング3
結果の見出しのみを得て、それを結果へ。

検索キーワードではAndAlso検索をするように指定。検索:AndAlso

検索結果に要約と「編集」リンクを †

ページ内容の内、該当部分も表示させたい。(ページ単位よりも小さい単位で)
段落単位か行単位で。(文字/文節単位だと意味が分からない)
ツリー形式の出力なら段落単位、表形式の出力なら行単位で。

全ページの一覧
	ページ1
		章1 [[編集:ページ1/章1]]
		該当部分(段落単位)
		--------
		章4 [[編集:ページ1/章4]]
		該当部分(段落単位)
	ページ3
		…

検索結果から編集を行うことは多い。「編集」リンクで直接編集したい。(章の実装をページにしておけば章単位の編集になって便利)
ページが存在しないなら「編集」は「ページ作成」と同じ機能になるので、この編集リンクだけでページ作成にもなるし。
→必ず「（検索キーワード）について書く」というリンクを検索結果に含める。

出力はHTML †

ページの一部分
ページに埋め込んで表示できる形式。
章ではない
章としての機能を持たないため。

2次元検索 †

1つのページのバージョンを検索。
新→旧の順に優先して表示。

ある言葉がいつ(加えられた|消された)かが分かる。

日時を指定して、その時点での前ページを探すのもいい。

これも全バージョンの一覧というページ内を検索することで実現。

ページを探す、文字列を探す †

全ページから条件に合うページを探す。
1ページ内の全テキストから条件に合う部分を探す。
行単位で。

→統一
これをページ内のテキストを探す方だけに統一できる。
「全ページの一覧ページ」を検索、このページには全ページが章として埋め込まれている。
で、章を含めて検索。
章を含めた検索は編集時のテキストを検索するのと同じ。章を展開して1つのWikiTextの形式にして処理。
章の展開を適切にすれば負荷を低減できる。

設計 †

アルゴリズム †

並べ替えをする
→複数の要素が必要

要素とは？
→Element
newとoutができるもの。

変換もする。
URL→ページ内容に。
その中の～月～日だけを（1つ）返す。

解釈 †

数値なら近い数にも高スコアを。

#000000、#000なら各桁ごとに近い数かどうか判断。

#309と#209は最も近い数ということになる。

20061231と20070101も近い。
月と日も近く、水と火も近い。
文字列ならページで辞書を定義。それで間に合う。

…これをページ/名前とリンクで定義できれば尚可。

特殊な数値もページで定義できる。
→マッピング。
1次元の値に写像すればいい。
x1〜x2→y5〜y6
クエリー作成に時間がかかりそうなので、クエリー作成と検索を分けてもいい。
操作不要、自動で続けるようにして。クエリー作成でマッピング後の表現にして。

定義はプラグインのクラスごとに。
解釈の仕方はプラグインの定義。
プラグインには2つのオブジェクト間の「近さ」を求める機能を。

懸案 †

処理とデータの型 †

検索処理から検索結果を得るとき
データの単位と処理繰り返しの単位