情報検索では検索結果集合演算をしたい

【まだ書きかえます。どこをいつ書きかえたか、かならずしもしめしません。】

- 1 -
文献データベースのようなものをつくるプロジェクトに参加している。文献自体がはいっているのではなく、文献についての記事がはいっている。書誌情報データベースといったほうがよいかもしれない。ただし、図書館の目録のように書誌と所蔵の情報をふくむだけでなく、その文献に記述された内容のうち研究者の観点からみて重要なことがらや、その文献についての研究者によるコメントなどをふくむ。

そこで、どんな検索機能が必要になるか、要件をだしている。そういう場で、わたしは、ちょっと過激にいうと、
「検索結果集合の AND, OR, NOT 演算ができなきゃデータベースじゃない!」
と主張したくなる。

• [注1] 「検索結果集合の...」としたところは、わたしの口をついて出たことばでは「文献集合の...」だったのだが、それは、考えてみると、わたしがわかいころに経験した(あとでのべる) TOOL-IR というシステムのマニュアルの用語に由来するくせなので、なるべく一般的な表現をえらびなおした。
• [注2] 「AND, OR, NOT」が集合演算だというのも、わたしにとってはすなおに出てきてしまう表現なのだが、考えてみると変だ。あとで表現しなおすことにする。

わたしは、コンピュータを使うといえばキーボードからコマンドをうちこむことだった世代だから、AND, OR, NOTなどの文字列でコマンドを入れるほうがらくだと思ってしまう。しかし、そういうインタフェースでは、いまどきの人にはつかってもらえないようだ。AND, OR, NOTと感覚的に対応がつくようなグラフィカル インタフェースをつくればよいのかもしれないが、どうすればそれができるかも、むずかしい。また、ユーザーインタフェースを別にしても、いまどきのデータベースのなかで検索結果集合演算を実装するのは、むかし(1970-80年代)のデータベースよりも、かえってむずかしくなってしまったらしい。

考えてみると、検索結果集合演算でできることは、検索条件の論理演算でもできることのはずなのだ。ちがいは、検索条件集合演算をつかえると、検索条件の論理式として書こうとすると複雑になりすぎてやる気がおこらないような検索もできる、ということなのだ。

進行中のプロジェクトでは、検索結果集合演算はあきらめて、検索条件の論理演算を組みこんでもらうことをねらうことにした。しかも、あらゆる検索条件間の論理演算を可能にするのではなく、よく使いそうな条件について機能を用意することになる。だいたい次のようになりそうだ。

• 同じ検索項目内でコンマくぎりで列挙したキーワード間では、ORをとる。(このため、検索キーワードはコンマをふくまないという約束にしておく。)
• ちがった検索項目を同時に指定したら、検索条件間の AND をとる。
• 検索条件に NOT をつけることは、その需要のある検索項目については可能にし、この検索システム特有の約束を読んで使う人むけのオプションにする。

そこまで実現できれば、わたしにとって、大満足ではないが、ちかごろの図書館システムと同じ程度に満足できるシステムになるだろうとは思う。

- 2 -
1節の注2に書いたように、AND, OR, NOT は、集合演算の演算子ではない。論理 (記号論理) 演算の演算子だ。

【集合について「 A and B 」という表現をすなおにとらえると、つぎの3節でいう「合併集合」のことと思いやすいのだが、わたしの議論での AND は共通集合に対応する。これは、論理との対応をもちださなければ、わからないだろう。しかし、集合の用語「共通集合」「合併集合」「補集合」や「intersection」「union」「complement」は、検索システム上の操作の名まえとしては、感じをつかみにくい気がする。】

わたしは、検索条件の論理演算と、検索結果集合の集合演算は、事実上 おなじことであるような感覚をもっている。それはわたしの特殊性なのかもしれない。思いかえしてみると、そういう発想になる原因は、ふたつある。

ひとつは少年時代に受けた教育だ。1970年代前半の中学のとき受けた数学の授業は、当時の教科書どおりではなく、「集合」の考えかたを強調するものだった。先生が教材づくりの実験をしていたのだと思う (その中学校は国立大学の付属校だった)。そこで、集合と論理とを(混同したわけではないが)一連のものとして意識するようになった。下に書く「集合と論理の関係」は、(記号はすこし変えたところがあるが) 中学のときからわたしのあたまにはいっていることなのだ。(わたしは遠山 啓 (1963)『新数学勉強法』[読書メモ]の本の記号論理の章の影響もうけたが、その本と中学でうけた教育とは、話があっていた。)

もうひとつは最初にであった具体的な文献データベース検索システムだ。1980年代前半の大学院生のとき、東京大学大型計算機センター([2010-07-30 昔、大型計算機センターというものがあった])のユーザーとして、そこの計算機で動いていたTOOL-IRというシステムを見た。そこに、検索結果の集合を操作するコマンドとして、AND, OR がつかわれていたのだ。

東京大学大型計算機センターでTOOL-IRをつくる中心になったのは、山本毅雄さんだった。いまウェブ検索してみると、2008年の時点で1980年ごろまでをふりかえった回顧録がみつかった。

• 山本 毅雄, 2008: 日本最初のオンライン情報検索サービス TOOL-IR: 研究・開発・サービス提供。情報の科学と技術, 58(5): 254-259. https://doi.org/10.18919/jkg.58.5_254

山本毅雄さんは、1981年に図書館情報大学に異動していたが、東京大学の情報科学の非常勤講師として「情報検索特論」(だったと記憶している)の講義を担当されていたので、他のコースの大学院生だったわたしは、聴講した。

【大量の書誌情報データ本体を順次に読むのでは遅くなりすぎるので、書誌情報からキーワードを抽出すると同時にそれと本体上の位置とをむすびつける索引データを切り出し、それをキーワードの辞書順に整列した索引ファイルをつくっておく、というような実装技法の要点の話が印象にのこっている。わたしは実際、だいぶ小規模ながらその技法を応用したことがあるが、いまの話題には直接関係ない。】

- 3 -
集合演算と論理演算の関係を、情報検索のユーザーの観点で必要になることにかぎって、整理しておきたい。

ここで、集合どうしのかさなりあいを、平面上の まる のかさなりあいでしめす図解をしたい。

• [注] そのような図は、1970年代にはよく「ベン図」とよばれていた。しかし、その名まえは Venn という人に由来するのだが、Venn が使った図はもっと限定された特徴をもつものなので、その名まえはよくないということになったそうだ。 「オイラー図」という人もいるが、Euler はとてもたくさんの概念をだした人だから、それもうまくないと思う。

わたしはわかいころ手がきでそのような図をかくのはいつものことだったのだが、コンピュータ上で図をかくのはにがてになってしまった。そういう図と演算記号とを関連づけた解説ページをウェブ上でさがしたら、ニッセイ基礎研究所のサイトに中村亮一さんによるページがあった。集合演算だけでなく論理演算のページもあった。

• 中村 亮一 (2020年01月07日) 数学記号の由来について (3) --集合論で使用される記号 (⊃、⊂、∩、∪等)-- https://www.nli-research.co.jp/report/detail/id=63317 [2020-06-18 閲覧]
• 中村 亮一 (2020年04月30日) 数学記号の由来について (4) --論理記号 (∀、∃、∴、∵等)-- https://www.nli-research.co.jp/report/detail/id=64337 [2020-06-18 閲覧]

集合演算としては、つぎのものを考える。(中村 亮一さんの「(3)」の記事の図を参照。)

• A ∩ B ... AとBの共通集合 (intersection)。Aの要素でもBの要素でもあるものを要素とする。
• A ∪ B ... AとBの合併集合 (union)。AとBのすくなくともどちらかの要素であるものを要素とする。
• A^c (記号はいろいろな流儀がある) ... Aの補集合 (complement)。全体集合の要素のうち、Aの要素でないもの。

論理演算。ここではひとまず命題論理で考える。命題は「真」か「偽」かの値をとる。

• a ∧ b ... a AND b、 a かつ b [注]、aとbが両方とも真のときにかぎって真。
  • [注] 「かつ」は、わたしの感覚では現代日本語ではなく古語で、わたしはつかいたくないのだが、「しかも」ではおちつかないので、慣例にしたがう。
• a ∨ b ... a OR b、a または b、aとbのどちらかが真ならば真。
• ￢a (記号はいろいろな流儀がある) ... NOT a、a でない。aが真なら偽、aが偽なら真。

論理演算と集合演算との関係。ここでは述語論理で考える。述語 a(x), b(x) は x がさす対象を具体的にきめると命題になる。

• A = { x | a(x) } ... 「A は、a(x) という条件をみたす x を要素とする集合である。」　
• A ∩ B = {x | a(x) ∧ b(x)}
• A ∪ B = {x | a(x) ∨ b(x)}
• A^c = {x | ￢a(x)}

わたしはこのような対応づけはつねになりたつような気がしてしまうのだが、もしかすると、要素数が無限になると、このような単純な対応づけをしてはいけないのかもしれない。しかし、全体集合の要素数が、たとえ現実的に列挙できない規模であっても、有限個ならば、対応づけてよいと思う。情報検索に即していえば、つぎのような対応がある。

• 検索条件の論理式中の AND と、検索結果の集合の共通集合
• 検索条件の論理式中の OR と、検索結果の集合の合併集合
• 検索条件の論理式中の NOT と、検索結果の集合の補集合。

- 4 -
TOOL-IRの検索操作は、わたしは東京大学大型計算機センターの『センターニュース』の記事で知った。その出版物をわたしはまだ持っているはずだが、すぐ手のとどくところにない。ウェブ検索をすると、その後身である東京大学情報基盤センターの『スーパーコンピューティングニュース』(1999年度から)のPDF版はそのセンターのウェブサイトにあるのだが、大型計算機センター時代のものはウェブ公開されていないようだ。ウェブ検索でみつかったTOOL-IRのマニュアルは、金沢大学でつくられたものが、金沢大学のリポジトリにあった。

• 寺崎 哲也, 1986: 文献情報検索 (東京大学大型計算機センター): CAS (Chemical Abstracts Service) を利用した文献検索から出力まで。金沢大学情報処理センター広報, 10(2): A1-51. http://hdl.handle.net/2297/5866

わたしの記憶からひきだしたことを、金沢大学のマニュアルで確認しながら、要点だけのべてみる。

TOOL-IRでは、SEARCHコマンドのパラメータとして、検索キーワードからなる論理式を書くこともできる。ただし、

• コンマをはさんで検索キーワードを列挙すれば、OR とみなされる。
  • [注] キーワードはコンマをふくまないようにつくられている。なお、キーワードは空白(space)をふくんでもよい。(キーワードとして、英語の単語だけでなく連語を使う需要は考慮されているのだが、"x, y, and z" などというコンマをふくむ連語は考えないのだ。)
• AND は「.AND.」、NOT は「 .NOT. 」と、両側にピリオドをつけてかく。
  • [注] これは1960年代からあるFortran言語の論理演算子と同じ形だ。英語のテキストには and, or はあたりまえに出現するので、演算子はそれと区別する必要がある。

原理的には論理式でもできるはずなのだが、別の機能として、検索結果の記事集合[注]どうしの演算があった。検索結果の記事集合は、データベースに含まれている記事の集合の部分集合である。

• [注] TOOL-IRのマニュアルでは「文献集合」という表現をしていたが、ここでは「記事集合」と書くことにした。

たとえば、つぎのような操作ができた。(例文の左側の「1/」などは、コマンド待ちのプロンプト文字列であるとともに、そこで検索操作をするとできる記事集合の番号の予告でもある。)

1/ SEARCH x ... 記事集合1として、xをふくむ記事の集合ができる。
2/ SEARCH y ... 記事集合2として、yをふくむ記事の集合ができる。
3/ AND 1,2 ... 記事集合3として、xとyの両方をふくむ記事の集合ができる。
4/ OR 1,2 ... 記事集合4として、xとyのすくなくとも一方をふくむ記事の集合ができる。
5/ DIF 1-2 ... 記事集合5として、xをふくむがyをふくまない記事の集合ができる。

ここで、「NOT 1」のようなコマンドをつくらなかったのは、「xをふくまない記事の集合」は、膨大なものになりやすいからだと思う。実際に否定文の条件をつかいたくなるのは、なんらかの条件 (ここの例では xをふくむこと)でしぼりこんだうえで、そのうちで、ある条件にあてはまるもの(ここの例では yをふくむもの)を、すでに検討ずみであるとか、今回の関心の外であるとかいう理由で、とりのぞきたい、という状況が多いので、集合演算の用語でいえば(「補集合」ではなく)「差集合」を計算できるという形にしたのだろう。

- 5 -
集合演算というしくみによって、1回の検索コマンドで記事数を実際に人が読めるところまでしぼりこまなくても、複数の検索コマンドを実行したあと共通集合や差集合をとることによって、検索コマンドを単純な形にしながら、検索結果を人が読める数にしぼりこむことを可能にしている。

検索結果の記事集合として、もし記事内容まで記憶すると、情報システムの記憶容量がかさむが、記事IDのようなものだけを記憶しておけば、あまりかさばらない。

ただし、検索と並行して、データベースの内容の更新がおこなわれていると、記事集合としてたくわえられた記事IDの集まりがしめす実際のデータベース上の記事の集まりの内容が変わってしまうおそれがある。記事集合演算を有効にするためには、検索操作と更新操作とのあいだの排他制御があるシステムにする必要があるだろう。データベース更新の前後にまたがった記事集合演算を不可能にしておくか、そのばあいの結果は保証できないことを利用者に周知しておくのだ。TOOL-IRはそのような運用がされていたと記憶している。

- 6 -
いまどきの、公開されているデータベース検索システムでは、同類の検索項目どうしの AND, OR ならば、サポートされていることは多い。書誌情報でいえば、

• 「著者名に a, b の両方の文字列をふくむもの」
• 「著者名に a または b の文字列をふくむもの」

などの検索はできることが多い (どちらか一方になってしまうことが多いのだが)。

しかし、わたしは、異質な検索項目どうしでも、集合演算をやりたいのだ。書誌情報でいえば、

• 「著者名に a, b の両方の文字列をふくみ、かつ、書名に x または y の文字列をふくむが、z はふくまず、出版年が 1981年以後、1990年以前のもの」

などという検索をやらせてくれるシステムは少ない。

図書館関係の目録データベース (CiNii Books や、大学の図書館、大きな公共図書館などの目録システム)では、いまでは検索コマンドではなく、検索メニューに記入して送信という形がふつうだが、かなり複雑な組み合わせ検索ができるし、しぼりこみ検索の形で、AND演算は実質的にできるので、わたしがやりたいと思う検索の半分以上はできている。

それにくらべると、本の通信販売サイトの目録は、入り口が手軽なのはよいのだが、検索機能が貧弱で、わたしが指定した検索キーでわたしが想定していなかったものが大量にかかってしまったばあい、のぞむものにたどりつくために、関心のないものを排除したくても、その方法がわからなくて、行きづまることがある。そこにある豊富な書誌情報への期待が高いほど、不満がたまってしまう。(つねに更新があって排他制御がむずかしい状況のなかで動かす必要があるという事情はわかるのだが。)