• 一般的に検索はフィルタリングとソート。ここで考えるのはこれらを一段汎用化したもので、スコアリングとフォーマット。
  • 検索はページに書かれた情報を活用する機能。
    ページには単純な構造で十分な情報を。その情報をつなぎ合わせるのが検索。
  • 自動生成されるページは検索機能によって作られる。
    動的に生成されるページは検索機能を使ったもの。
  1. オブジェクト化
    検索/クエリー と ページ をElement化
  2. 類似度評価
    検索/スコアリング
    結果に出すものと順序が決まる。
  3. ページ化
    検索/フォーマット
    体裁を与える。

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

方法 † Edit

実装上は検索も機能。
組み込み済み機能。必ず存在する機能。
こうして、他の機能と連携できるように。

AND、ORを使わない † Edit

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

語1 語2 語3？

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

語1 AND 語2 OR 語3

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

語1 語2
語3

…に分けることになる。

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

OR検索と同時にAND検索 † Edit

複数キーワードを受けたとき、全てを含むページ、いずれかを含むページの順に高スコアを付ける。
手間を省き、情報の取りこぼしを防ぐ。

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

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

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

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

RegExpのグループに合った数だけスコアを増やす。
/([0-9]+)(キロ)?/
…なら0〜2コのグループに合う。
→スコアを0〜2倍に。

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

検索履歴 † Edit

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

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

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

主観検索のために。

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

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

記法から呼び出すように。

関連語検索 † Edit

関連語検索、あるいは多段検索、デリゲート検索。

検索→検索結果に出せるページに含まれるリンクを集計（リンク=ページ名）→多い順にリスト化。
出現頻度の高いページ名を検索語に追加して再検索すると関連語も検索できる。検索漏れ防止。

これをワンタッチで。

検索→検索結果表示、そのページから自動的に関連語を含む検索開始（「関連語検索中」表示）→関連語検索結果が画面上に追加される。
いつも関連語が必要とは限らないので、一度検索結果表示。表示後に関連語検索が始まるように。

どれくらい出現頻度があれば関連語に含めるか…。これは検索時に利用者が与える。しきい値を低くすると多くの関連語が含まれる。

関連語探し
あるリンクと同じページにあるリンクのリストを得る。
（共起しているリンクを複数得る）

検索を一時的ページと、そのページへのバックリンクとして実装すれば、リンク←ページ名←検索語、となる。
つまり、検索語入力→関連語リストを得ることもできる。

OR結合の結果はヒットした検索語を併記 † Edit

検索でOR結合がある場合、結果1件ごとにヒットした検索語を併記。
ORを含む場合、ヒットしていない語も生じるので、どの検索語にヒットしたかが分かりにくい。それを明示するため。

ORで切ったキーワード別に検索リンクを用意できるならそっちのほうがいい。
順序は全キーワードの結果を混ぜてソート。これを見るためにORを使うので。OR断片ごとにソートしたいなら検索リンクをクリック→そのOR断片だけで検索。

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

再利用しやすくなる。
orで切って、andはつなげて。それぞれを検索リンクにする。
ブラウザーのブックマークバーにドロップできるように。

リンク部分はヒットした部分の強調表示と同じく強調。

検索をリンクの仕組みで実装 † Edit

  1. 検索語入力
  2. 検索語を一時的なページ名として扱う
    このページが検索結果ページ。
  3. リンク、バックリンク
    リンクは結果、バックリンクはヒットした部分の強調にするため。

これは検索結果を共有・保存することになる。
個人利用ではデフォルトにしてもいい。
不特定多数利用ではバックリンク（トラックバック）を公開しているブログと一緒。検索結果からページを選んだ時点で保存。

検索ページ † Edit

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

検索はページ集約 † Edit

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

集約をさらに進めるために、
ページを一目見ただけでそのページを見る価値があるか判断できるようにするため、検索結果の冒頭にまとめを表示。

まとめ

  • 集まったタグのタグクラウド
  • ヒット数をorごとに
    andはつなげたままで
  • これまでの検索クエリーをorで切ってリストアップ
    ヒット数も添えて。 
    [検索 ページ](18), [検索 結果 ページ](8)

機能出力を機能のパラメーター（入力）にする仕組みで。
検索機能出力を検索機能の入力に。→何段でもDecorationできるように。

検索結果をRSS化 † Edit

検索/フォーマットで実現。

さらに他ページのリソースを取得する機能と、RSSを解析する機能でRSSをページ化。（検索結果（ページ）→RSS→ページ）
他サイトのリソースを取得する機能はあっても良いがRSS取得のためなら要らない。

1ページ、1ソート順 † Edit

ソート順が違う結果を出力するなら別のページに。
そうしないとAPIなどから自動処理しづらい。

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

ソート順は検索/クエリーが決める。

フィルタリング、変換 † Edit

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

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

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

→ソートは最後だけ（テンプレートに埋め込むときだけ）にする。その代わり、スコアを最後まで残す。

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

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

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

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

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

  • 要約表示
    ページ内容の内、該当部分も表示させたい。(ページ単位よりも小さい単位で)
    段落単位か行単位で。(文字/文節単位だと意味が分からない)
    ツリー形式の出力なら段落単位、表形式の出力なら行単位で。
全ページの一覧
	ページ1
		章1 [[編集:ページ1/章1]]
		該当部分(段落単位)
		--------
		章4 [[編集:ページ1/章4]]
		該当部分(段落単位)
	ページ3
		…

出力はHTML † Edit

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

時系列検索 † Edit

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

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

日時を指定して、その時点での全てのページを探すのもいい。
「タイムマシン検索」？

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

全ページの全バージョンを検索できればなおいい。

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

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

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

自動生成ページを検索対象にすることで特殊検索を † Edit

自動生成ページで特別な観点で集計した検索対象を作れば、いろいろな検索に対応できるはず。

検索のアルゴリズム † Edit

検索はページセットが制御。検索とはページセットが自身を縮小する処理のこと。→ページセット
呼び出された時に与えられた検索/クエリーと、自身が持つページを比較。

検索のアルゴリズム † Edit

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

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

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

解釈 † Edit

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

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

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

  • 20061231と20070101も近い。
  • 月と日も近く、水と火も近い。

それぞれに対応する記法が要る。
もし、特定のページで記法を定義できるような機能ができれば、それで間に合う。

 

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

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

RIGHT::t/！[?]

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

→つまり#数値記法や曜日記法、体重記法、日付記法、季節記法、二十四節気記法などを用意、それぞれの記法ごとに検索するということ。

データ型はページ主体 † Edit

すべてのページを得る → その中を検索 → ページを得る → その中を検索 → ページを得る → その一覧を検索結果とする。
というDecoratorパターンになるように。

機能出力を機能の入力にする仕組みで。