目次 † Edit

  1. 目次
  2. 関連
  3. 検索周辺のタグ
  4. 検索
  5. 思い付き
    1. 読み検索
    2. フィルタリングワードにはタグも
    3. 使い方
    4. 検索欄のデフォルト値
    5. 「まとめておきました」
    6. 同時に更新したページが分かるように
    7. スコア加算条件を複数に
    8. 似ているページ報告
    9. 用語集を使って関連語検索
  6. 方法
    1. 検索結果のソート順 #ui #wiki
    2. 各種検索時、100%マッチを特に強調、ページの見出し扱い
    3. 文字修飾系記法では部分一致可能に
    4. NarrowSearch, ExpandSearch
    5. フォーム生成機能呼び出しから開始
    6. 検索対象
    7. 検索結果にページ作成リンクを
    8. AND、ORを使わない
    9. OR検索と同時にAND検索
    10. インデックスを作るなら別プロセスで
    11. たくさん合えばスコア増
    12. 検索履歴
      1. 入力されたキーワードを関連付ける
    13. 検索はフレームワークの機能
    14. 関連語検索
    15. OR結合の結果はヒットした検索語を併記
    16. 検索キーワードをリンク化
    17. 検索をリンクの仕組みで実装
    18. 検索ページ
    19. 検索はページ集約
    20. 検索結果をRSS化
    21. 1ページ、1ソート順
    22. フィルタリング、変換
    23. 日記を特定のキーワードで検索して「その1日前に何をしていたか」を一覧したい
    24. 検索結果に要約と「編集」リンクを
    25. 出力はHTML
    26. 時系列検索
    27. ページを探す、文字列を探す
    28. 自動生成ページを検索対象にすることで特殊検索を
  7. 方法
    1. アルゴリズム
    2. アルゴリズム
    3. 解釈
    4. データ型はページ主体

関連 † Edit

検索:検索

検索周辺のタグ † Edit

Array

検索 † Edit

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

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

思い付き † Edit

読み検索 † Edit

「あかさたなはまやらわ」を同一視。
その他、発音したときに似ている言葉を同一視。

音声でタグ付け、音声で検索ワード入力、検索。

フィルタリングワードにはタグも † Edit

ページ内にある（サブセットWikiにある）タグでフィルタリング。

使い方 † Edit

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

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

検索欄のデフォルト値 † Edit

検索欄を設置できるならデフォルト値も設定可能に。
「ヘルプ」とか。ヘルプページ内に。汎用の検索欄とは別に。

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

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

  • 「このWikiの再編後に残すページをまとめておいたので、意見があれば自分の利用者ページに「再編について」という見出しで書き込みしてください」
    検索で「再編について」という見出しを集めた検索リンクも設置。
  • アイテムの価格相場を表から抜き出し、荒れた時期を探す。

同時に更新したページが分かるように † Edit

同じページ名が重複していても全て表示。
更新の衝突も分かるように。

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

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

似ているページ報告 † Edit

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

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

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

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

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

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

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

方法 † Edit

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

検索結果のソート順 #ui #wiki † Edit

文字列検索時のソート順は、単語や文字種の境界に多く接している順。次に辞書順。
これで完全一致がトップにくることになる。次に別の単語がハイフンでつながっているもの。そのあとに単語内での先頭/末尾一致、最後に単語内での部分一致。

さらにヒットしなかったのを辞書順で表示してもいい。ヒットしなかったことが区別できるようにして。

各種検索時、100%マッチを特に強調、ページの見出し扱い † Edit

検索するまでもなく利用者が知っていた訳なので「正解」という表示にする。

文字修飾系記法では部分一致可能に † Edit

文字修飾付きの検索クエリーを使うとき、修飾内部の文字列に一部でもヒットすれば見つけられるように。
打ち消し線の中の日付を範囲指定で探すと…「ToDoリストで去年あれをやったのはいつだったか」という検索に。

文字修飾系以外でもテキストを含むなら部分一致させたい。

NarrowSearch, ExpandSearch † Edit

  • NarrowSearch…絞り込み検索、and
  • ExpandSearch…拡げる検索、or

フォーム生成機能呼び出しから開始 † Edit

検索手順は検索フォーム機能呼び出しから始まる。→機能/UI[?]
検索処理の本体はそのフォームから「送信」したとき。

  1. 検索フォーム機能入りページ閲覧。検索フォーム機能は設定にある検索機能名を含んだ検索フォームと置き換わる。
    あるいは検索機能呼び出しになるようなURIを含むリンクなどで。こちらは特に工夫なし。ただのリンク。
  2. 利用者が検索フォームに入力、URI化してHTTPリクエスト。
  3. WikiEngineから指定された検索機能が呼び出される。
  4. HTTPレスポンスには検索結果ページの雛形と、1件あたりの雛形を組み合わせて作られたページ。
    検索機能が作る。2種類のうち、検索結果ページはWikiEngineが通常のページとして扱う。
    1件あたりのほうは検索結果機能（検索結果に置き換わるだけの機能）が扱う。
    1. 検索機能で検索処理、ページセットが作られる。
      検索はここまで。後はサブセットWikiと同じ。
      検索結果機能とはWikiのページセットを検索結果の雛形に埋め込んで閲覧時展開するもの。なので検索結果でなくてもページセットならなんでも整形出力できる。
    2. ページの閲覧時展開処理で検索結果機能が展開される。
      雛形ページに検索結果機能が含まれていなかったらこの処理は無い。検索結果としては出力されない。
    3. 検索結果機能が検索結果1件あたりの雛形を使って検索結果を生成、ページ上の自身と置き換わる。

検索時以外でも検索結果機能は機能する。検索結果機能の実体はページ一覧出力なので。検索時には検索に適合したページだけのページセットを対象にするだけ。
ということで検索時以外にこの機能が展開されると全てのページ一覧になる。機能側で全て…の場合は空文字列かコメントを出力するようにすれば、どんなページに検索結果を埋め込んでも邪魔にならない。

雛形2種類を選択可能にすれば、検索結果を選ぶこともできる。
グラフ表示とか、リストとか、テーブルとか。
雛形はページとして用意。

検索の雛形ページを通常のページ、FrontPageにもできる。
検索結果と置き換わる機能が設置されていれば。

検索機能も複数選択可能にすれば、アルゴリズムを選べる。
パラメーター形式が異なればフォームを分ける必要があるけど。

検索対象 † Edit

それぞれの区分で検索/スコアリングのルールを適用。

各区分での評価は重複して良い。
記法で評価したあと、テキストとして評価、その後閲覧用テキストとしても評価。

検索結果にページ作成リンクを † 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

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

アルゴリズム † Edit

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

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

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

解釈 † Edit

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

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

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

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

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

 

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

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

RIGHT::t/！[?]

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

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

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

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

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