要約

  • CiteSeerの実演用データベースでは、検索要求の約20％に著者のイニシャルが含まれていた。
  • 1999年の実験では、文字の位置をキャッシュし文書別に引く仕組みにより、その組の平均処理時間が1.91秒から0.26秒になった。

参考文献で名前を一文字に縮めるのは簡単だ。あとでその著者を探す人は、残された一文字を頼ることになる。初期の学術検索システムCiteSeerは、その手掛かりをきちんと受け付けた。すると、コンピューターのほうが待ち時間を請求してきた。

Steve Lawrence、Kurt Bollacker、C. Lee Gilesによる1999年の論文には、m jordanやm i jordanという検索例が載っている。姓の近くにイニシャルがある文献を探したい。ささやかな注文なのに、しばしば数秒かかった。学術図書館の仕事が、アルファベット一文字で渋滞していた。

省略された名前にも居場所を

検索索引では、頻出語を登録対象から外すことがある。CiteSeerはそうした語も残した。引用文献には著者のフルネームがなく、姓とイニシャルしか書かれていない場合が多い。よくある姓を探すとき、その短い文字が範囲を狭める助けになる。語句検索や近接検索を使えば、名前の断片が互いに近い位置にあることまで指定できた。

もともとCiteSeerは、ウェブ上に散らばった論文を引用関係でつなごうとしていた。1998年の報告は、論文から参考文献を取り出し、同じ研究を指す異なる書き方の引用をまとめる仕組みを説明している。文末の一覧が、次の論文へ進む道になる。

その前には地味な片付けが必要だった。1999年6月のComputer論文によると、PostScriptやPDFをテキストに変換し、参考文献の箇所を探し、番号や行間、字下げを使って個々の引用を区切っていた。ページが逆順になったPostScript文書は並べ直す。未来の図書館にも、まず紙の束を正しい向きにそろえる仕事があった。

イニシャルの難しさは、その先にある。一文字は膨大な数の引用に登場する。姓の近くにあるかを確かめるために、長い文書一覧や位置情報を調べることになる。実演用データベースの検索要求の約20％が著者のイニシャルを含んでいた。例外扱いするには、ずいぶん長い行列だった。

文字を消さずに、探す手間を減らす

1999年の実験では、約20万文書、250万件を超える引用を収めたデータベースを使った。研究者はイニシャルを含まない検索要求を25件、含むものを25件、無作為に選んだ。平均処理時間は前者が0.28秒、後者が1.91秒。論文は約7倍の差と説明している。

そこで、語の位置情報の一覧をキャッシュに置き、各イニシャルについて文書の識別子で引ける表を用意した。候補文書が決まれば、その中で一文字が現れる場所へ直接進める。近さを比較する処理では、通常、文書一覧全体を調べずに済むようになった。

改良後、イニシャルを含む組の平均は0.26秒になった。この50件の実験では、もう一方の組をわずかに上回る速さだった。検索の条件を削らず、情報の置き場所を変えることで、厄介な一文字を扱いやすくしたのである。

結果を受け取った読者にも、確かめる手段があった。Contextのリンクでは引用周辺の文章を読み、Checkでは同じ論文としてまとめられた引用表記を個別に見られた。論文がどう使われたか、まとめ方に根拠があるかを調べられる。イニシャルで近づいた先に、判断の材料が残っていた。