ページを探す、文字列を探す † 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パターンになるように。

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

検索 † Edit

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

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