画像やページ記述言語によるデータは文書の再現性がよく、特に紙にプリントア ウトしたときに原文のレイアウトに忠実な出力が得られるが、キーワードなどを 用いて直接検索するには適していない。このため、通常は検索用の二次情報を追 加してデータベースを構成する。
これに対し、マークアップ言語によるデータは文書の再現性は必ずしも良くない が、全文データに対して直接検索することが可能であると同時に、取得したデー タを用いて読書支援機能などの二次的な利用も容易にできる。容量があまり大き くないこともデータベースの運用上の利点である。
将来的には、執筆から印刷、流通まで一貫して電子的に文書データが作成される ようになるであろうが、現在は、まだまだ印刷物だけが最終的な出版物である場 合がほとんどである。また、過去の膨大な印刷資料も無視することはできない。
このような紙に印刷された大量の文書を電子化して電子図書館のデータを整備す るためには、コストと時間の制約から、印刷物をスキャナーで読み込んで画像と して蓄積するという手段をとらざるを得ないことが多い。しかし、このような場 合でも、上記のような理由のため、マークアップ言語によるデータを並行して作 成し蓄積することが望ましい。
紙に印刷された文書を電子化する場合は、コストと時間の制約のため、文書は画 像として入力し、検索のために必要最低限の二次情報を人手で付加することが多 い。画像から正確なマークアップテキストを自動的に生成することは非常に困難 であり、画像解析とOCRを用いて自動変換する試みも行われてはいるが、誤り率 を無視できるまでの精度は期待できない。そこで、このような方法で作られた電 子化文書を電子図書館で扱う場合は、予め自動的に生成された誤りを含むマーク アップテキスト（OCRデータなど）に対して全文検索を行い、文書の提供は画像 で行うという形態が現実的である。
一方、マークアップ言語によって記述された文書データが最終的な印刷物に対応 した形で利用可能な場合は、データベースの持ち方にも柔軟性が出てくる。マー クアップデータから印刷イメージを再現するメカニズムが利用可能でない場合は、 これとは独立に画像を入力して蓄積しておく必要があるかもしれない。しかし、 マークアップデータから印刷イメージの再現が可能な場合は、ページ記述言語に よるデータや画像データには、予め生成して蓄積したり、要求があったときに生 成して蓄積しておいたり、あるいは要求時に一時的に生成したり、といった選択 が可能であり、文書へのアクセスの特性やサーバシステムの処理能力や外部記憶 容量に応じて適切な方式を採用できる。
文書データにはさまざまなものがあり、電子図書館では上記のような、入力方法 が異なったさまざまな電子化文書を統合的に扱える必要がある。
マークアップテキストが印刷の工程に組み込まれて作成されている場合は、一般 にデータ形式の変換に必要な情報は含まれている。文書構造の検索への利用も、 きちんと構造を定義し、それにしたがってマークアップされている場合は可能で あるが、マークアップ言語の種類によってはこの定義に違反することが容易にで きてしまうため、データベースの構築時にさまざまな問題が発生する可能性があ る。
マークアップテキストが印刷とは別工程で作成されている場合は、必ずしも正確 に他のデータ形式に変換できるだけの情報を持っているとは限らない。このよう な場合には配布用に画像データを蓄積しておく必要が生じ、余計なコストが発生 する。文書構造の検索への利用については上の場合と同様である。
画像データからマークアップテキストを自動生成する場合は、データ形式の変換 の役割は最初から考える必要がないので、検索に有効な文書構造のみを抽出して マークアップテキストを作成することになる。
上記の役割を考慮すると、マークアップ言語として以下のような条件を満たす必 要がある。
(1) 論理構造のみを記述するようになっていること
- 余計な書式制御などが入っていると検索の邪魔になる
(2) 検索に必要な論理構造をすべて記述するようになっていること
- 記述が不揃いであったり不備があると見つかるべきものが見つからなくなる
(3) 構造が明確に定義されていること
- 構造が明確でないと、データベース構築時にフォーマットエラーや処理の 漏れが生ずる
LaTeXやTeXでもこのような条件を満たすように文書を作成することは可能だが、 著者や印刷所に強制することは難しい。例えば、著者が作成したLaTeXデータを 用いる場合、著者は刷り上がりの見栄えをよくするために改行やハイフネーショ ンなどの書式制御を行うことがあるため、この条件に違反することが多い。また、 階層構造などを定義することもできないため、論理的な構造上の誤りがあっても 自動的に検出する手段がない。このため、実際にデータベースにロードするとき にエラーになってデータベース管理者が苦労することになる。
その点、SGMLでは文書型定義(Document Type Definition: DTD)を適切に作成す ることで(1)と(3)を満たすようにすることができるし、その結果として(2)も自 然に満たされる。文書構造がDTDで明確に定義されているので、データの正当性 は編集や印刷の各段階でチェックできるため、データベース管理者は安心してデ ータを受け入れることができる。
SGMLは、いわば、著者や編集者の自由度を奪うことによりデータの整合性を高め、 データベース構築と検索に都合の良い電子化テキストを作成し、文書データを管 理するための手段として非常に有効であると言える。
SGMLによる全文データベースの検索には非常に強力なシステムが利用可能である [1]。現在のSGMLにかかわる問題点は、エディタなどのオーサリングツールや対 話的にテキストを表示するためのビューワに一般的なものがない点と、印刷品質 に耐える自動的なフォーマッティングを行うシステムが整備されていない点であ る。しかし、SGMLエディタのDynaTextの日本語化が進められたり、ワードプロセ ッサソフトウェアである一太郎などでSGMLのタグ付けが可能になるなど、オーサ リングツールは徐々に利用可能になりつつある。また、perlやsgmlsなどのツー ルとNetscape NavigatorなどのHTMLビューワを組み合わせることで、SGMLビュー ワの代替とすることができる[2]。印刷用のフォーマッタにはこれまでは（少な くとも日本語文書では）TeXを用いることが多く、どうしても人手をかける必要 があり、最終的な印刷物とSGMLデータとの間に不一致が生じやすかった。しかし、 日本語DTPの「OpenXPress」でSGML文書を処理できるようになるなど、印刷用の システムも利用可能になってくるものと思われる。SGMLをとりまくシステム環境 は全体的に改善の方向であり、より一層の整備が期待される。
そこで、学会や大学などでの学術雑誌のSGML化を容易にするために、学術情報セ ンターでは100以上におよぶ学会誌や論文誌を調査し、これらの多くに共通に適 用可能な汎用DTDを作成した[3]。学術情報センターではこのDTDを用いて、セン ターの研究論文集である「学術情報センター紀要」を年１回、定期的に刊行して いる[4]。実際の原稿の例は
URL: "http://www.rd.nacsis.ac.jp/~oyama/paper/kiyo-95/paper.sgml"
で見ることができる。
DTDが準備できたとして、SGMLテキストを実際に作成するための作業の流れを、 論文誌を例にとり図２に示す。理想としては著者が最初からSGMLで文書を執筆し、 編集・印刷・電子出版・データベースのすべての過程でデータを共通のフォーマ ットで統合的に扱えるようにしたい。しかし、実際にはまだほとんどこのような 形態は実現されていないようである。
学術情報センター紀要の刊行では、著者は基本的にプレインテキストの原稿を用 意し、それを外注作業でSGMLテキストに加工し、編集や校正を経て、TeXに変換 して印刷している。これまでは、タグ付けは通常のテキストエディタを用いて行 われており、これをパーザにかけてチェックとTeXへの変換を行っていた。しか し、オーサリングツールが何とか利用可能になってきたので、今後は、著者に直 接SGML原稿を執筆してもらうか、内部での編集の一貫としてタグ付けを行う方向 に変わってゆくと思われる。
このようにして作成されたSGMLテキストは、現在、プレインテキストに再変換さ れて学術情報センターのGopherサーバで提供されているほか、著者が実験的に運 用している全文データベース検索システムにおいて検索可能となっている[6]。
しかし、ある程度の頻度で刊行されている雑誌で、このように編集の段階から SGMLを適用している例には、日本化学会欧文誌など[6]があるが、全体からする とむしろ希である。電子的に編集・出版をしている雑誌ではTeXやLaTeXを用いる 例の方が多い。これらのデータをSGMLに変換する手法については調査中であり、 本格的に処理を行った経験は筆者にはないが、マクロないしはスタイルファイル が的確に作られており、定義されたものを適切に用いて記述されているテキスト であれば、数式などを除き、主要な文書構造はほぼ自動的にSGMLに変換が可能で あると考えられる。
さらに、現在でも多くの雑誌は電算写植機（CTS）などの専用システムにより印 刷されており、そのデータを変換してもプレインテキストが取得できる程度で ある。CTSデータを入手できない場合も多く、このようなときは印刷物を出発点 にしてSGMLデータを作成せざるを得ない。また、すでに刊行された印刷物につ いても同様である。このような場合には、OCR入力なりパンチ入力なりでプレイ ンテキストを作成した上でタグ付けを行うか、紙の上にタグ付けをしてからパ ンチ入力をするかしか、現状では方法がなく、コストと時間が大量にかかる。 文書画像解析により文書構造を識別した上でOCR読みとりをすることにより、タ グ付きテキストを自動作成する方法も研究されており[7]、早急に実運用に適用 できるようになることを期待したい。
また、逆に、学術情報センター紀要のように、編集・印刷過程でSGMLテキストが 作成されていて、印刷も含めて必要な情報がすべてタグ付けされている場合でも、 実際に情報検索のためによく使われる文書構造は主要な部分に限られる。
サーチのときに指定できることが必要な文書構造としては、標題や著者、キーワ ード、アブストラクトなどのいわゆる文献情報と、参考文献（各文献単位）、本 文中の章や節の見出し程度である。近接演算をサポートしていない検索システム では段落も必要になるかもしれない。これらの文書要素は検索対象としてデータ ベースに構造定義しておく必要がある。しかし、それより細かい部分のタグまで は定義する必要はあまりなく、検索文字列の一部として扱うだけで十分な場合が ほとんどである。
サーチ結果の中から取り出す文書を選択するためには、文献情報、標題と章節の 見出しを並べた目次、あるいは、サーチで見つかった文字列の周辺のテキストな どを表示すると有効であろう。これらはサーチの時に指定する文書要素の組み合 わせで作成できるので、二重に構造定義する必要はなく、表示データを組み立て るときに動的に構成すればよい。
文書表示を、画像ではなく、SGMLテキストをフォーマットして行う場合には、詳 細なタグ付けが必要である。フォーマット処理はいわば出力時のフィルタとして 行われる処理であり、データベースからテキストを抽出する際には文献単位、あ るいは章節単位のきわめて単純な構造が定義されているだけで十分である。後は フォーマッタがタグを見ながら処理をすることになる。
全文データベース検索システムにおいて、学術情報センター紀要データベースで 実際に構造定義してサーチに利用している文書要素は、<論文>、<題名>、<著者> （一人ずつ）、<要旨>、<本文>、<章節>、章節の<見出し>、<段落>、<参考文献> （一件ずつ）の各文書要素である。文書選択用にはサーチ用と基本的に同じ文書 要素を用いている。表示用としてはこれらに加えて、<文献情報>の文書要素と目 次（<標題>と章節の<見出し>の組み合わせ）を用いている（いずれも実際は英文 のタグ名）。
これはフリーキーワードによる検索の一般的な用途を考えて設定したものである。 用途によってはこれとは異なる構造定義が必要になる。例えば、引用関係を精密 に調べたければ、<参考文献>の中をさらに細かく分けて著者や題名、雑誌名など を構造定義する必要があろう。
リージョンとは、テキストデータ中の領域（区間）であり、通常は一つの（任意 のレベルの）文書要素に対応している。これに対して、キーワードなどの文字列 はその開始位置であるポイント（点）で表現される。
「著者」などの同一のタグ名を持つ文書要素は、データベースの構造定義におい て予めリージョンとして登録し、これらを要素とする静的リージョンセットを作 成しておく。また、「目次」のように複数のタグ名の文書要素を集めたものや、 特定の文書要素に含まれる見出しのように出現位置を限定したものは、通常は集 合演算やリージョン演算により動的リージョンセットとして作成する。一方、キ ーワードなどの文字列によって検索を行うと結果は動的ポイントセットとして作 成する。
開始点からなるポイントセットと終了点からなるポイントセットを組み合わせて 動的リージョンセットを作成することも可能である。これにより、例えばデータ ベースの構造定義にない文書要素を一時的にリージョンとして扱うことができる。
集合演算では、オペランドにはポイントセットとリージョンセットをとることが でき、リージョンセットは開始点だけからなるポイントセットとして演算を行う （リージョンセット同士の集合演算の場合は結果はリージョンセットとなる）。
リージョン演算には基本的に、including（含む）とwithin（含まれる）の２種 類の演算がある。``A including B''は、リージョンセットAの要素の内、リージ ョンセットまたはポイントセットBのある要素を（区間として）含むものの集合 である。また、``B within A''は、リージョンセットまたはポイントセットBの 要素の内、リージョンセットAのある要素に（区間として）含まれるものの集合 である。さらに、これらに否定を組み合わせたnot includingとnot withinがあ る。
以上からわかるように、文書要素をリージョンとして扱えば、リージョン演算に よって文書要素の包含関係を表現することができる。これをDTDによる定義と組 み合わせれば、SGML文書のたいていの階層構造は扱うことができる。ただし、 PATのリージョンセットでは、集合要素のリージョン間で重なり合うことを許し ていないため、SGMLで許されている再帰的定義だけはリージョンでうまく扱うこ とができない。このため、データベースにロードする前にタグ名を変更するなど して対処しておく必要がある。
実際の検索においては、いくつかの異なるタグ名を持つ文書要素を一括して検索 条件中で使用したい場合（例えば<author>と<translator>など）がある。また、 同じタグ名を持つ文書要素でも特定の場所に出てくるものだけを指定したい場合 （例えば見出しを意味する<t>の内、図<fig>や表<tbl>のキャプションとして出 てくるものだけ）もある。これらは検索のたびに集合演算やリージョン演算を組 み合わせて処理することもできるが、データベース構築時に特別な処理により静 的リージョンセットを作成しておくか、起動時に初期化コマンドの中で動的リー ジョンセットを作成しておくこともできる。こうすることで、異なるDTDを持つ 文書を統合検索する場合などでもユーザに意識させずにすむ。
また、実際の表示においても、いくつかの異なるタグ名を持つ文書要素を一括し て取り出したい場合（例えば目次に相当する文書要素や文献情報に相当する文書 要素）がある。これらも同様にデータベース構築時か起動時にリージョンセット を作成しておくと便利である。表示する際には、出力順序を出現順に指定してお いてから文書要素を取り出せば表示のための変換は簡単な後処理だけですむし、 長大な文書から一部分を取り出すような場合でも不要な部分を読み出す必要がな く効率的である。
このように、リージョン演算は単に個々の文書要素を組み合わせて検索条件を作 成するだけでなく、複数の文書要素をあたかも仮想的な文書要素のように扱うた めにも使えるし、出力を効率よく行うためにも効力を発揮する。
まず、検索対象として識別する必要がある文書要素（DTDごとに異なる可能性が ある）に共通のリージョン名を付ける。そして、各DTDごとにタグ名とリージョ ンの対応表を作り、静的リージョンセットを作成しておく。基本的な文書構造が ほぼ同じDTDであればこれで大体対処可能である。
しかし、DTD間で文書構造が単純な一対一の対応になっていない場合、同一のDTD にしたがう文書ごとに7.に述べたのと同様の方法により仮想的な文書要素に対応 するリージョンセットを作成しておけばよい。これを用いれば、検索のときは DTDの違いをほとんど意識することなく統合検索を行うことができる。具体的に は、データベース構築時には単純にDTDの名前と文書要素名とを組み合わせたよ うな名前の静的リージョンセットを作っておき、起動時にリージョン演算を行っ てそれぞれの仮想的な文書要素を表現する動的リージョンセットを作り、すべて のDTDに対応するものの和集合を作っておくのが適当であろう。
表示の際、テキストの抽出にはこのようにして作成しておいた動的リージョンセ ットを用いることができるが、テキストの形式変換のためには、出力フィルター をDTDにしたがって切り換えて処理させる必要がある。
PATにはこのように複数の文書構造からなるテキストを同時に扱うための文書グ ループの機能が用意されており、グループごとに独立したリージョンを作成した り、テキストとともに文書のグループ名を出力したりすることができる。この機 能を用いれば上記のような複数DTDを扱う方法が実現できる。
まず考慮しなければならないのは、WWWで使われているHTTPプロトコルではサー バに状態が存在しないという点である。このため、通常のシステム構成では、ユ ーザがそれまで行ってきた検索の履歴を保持するためには、すべての情報をFORM の中のデータに埋め込んでユーザ側に保持させる必要がある。単純な対話システ ムでは、検索条件をFORMに穴埋め式に書き込んでサーバに送り、サーバは検索を して結果を返して終わりとなる。結果に満足できない場合は、前とは関係なく、 あらためて検索条件を書き込んで検索し直す。これならば特別の工夫をしなくと もHTTP上に実現できる。
しかし、さまざまな条件で目的の文書を試行錯誤的に探す場合には、従来の情報 検索システムのように以前の検索結果を使って新たな検索を行うというように、 履歴を保持した対話システムが必要になる。この実現には、検索結果集合の代わ りに過去の検索条件をすべてFORMのデータに埋め込んでおく方法と、履歴を保持 する特別の仕組みをサーバ上に作り込む方法がある。幸いPATには途中経過も含 めて過去の検索結果をキャッシュしておく仕組みが備わっているので、PATを常 駐させておくようにすれば、同じ検索をやり直しても二回目はほとんど負荷にな らないため、前者の方法も十分現実的である。しかし、履歴が長くなり検索条件 が複雑になると、PATのキャッシュにヒットしないものが増え、FORM中に保持す るデータ量も指数関数的に増える。このため、従来の情報検索システムのような 使い方をするためには後者の方法の方が効率が良くなる。いずれにしろ、複数の 検索要求にまたがって検索サーバのプロセスを継続的に走らせておく必要がある。
次に考慮すべき点は、検索のシナリオに沿ったFORMの展開の仕方である。インタ ーネットの全文索引検索サービスであるOpen Text Index[8]では、まず単純なキ ーワードだけによる検索フォームを提示し、結果を見てから文書構造や論理演算 を組み合わせたより詳細な検索ができるフォームに展開するという方法をとって いる。これに対し、筆者らが開発しているシステム[5]では最初からすべての検 索機能を持つフォーム見せておくが、デフォルトを適切に設定しておくことで単 純な検索なら簡単に行えるようにしている。参考のため、このシステムの構成を 図3に示しておく。
さらに、さまざまなDTDやユーザの利用目的にどのように対応するかも重要な考 慮点である。データベースごと、検索シナリオごとにゲートウェイプログラムを 書き直すというのが最も直接的な方法であるが、データベースの提供者がプログ ラミングとHTMLにも精通していなければならず、また開発の手間もかかる。perl などのテキスト処理ツールを使ってプログラムすれば開発の手間はある程度省け るが、プログラムコードの中にHTMLテキストがちりばめられた形になり、見通し はあまり良くない。別のアプローチとして、筆者らのシステムではHTMLを生成す るためにゲートウェイプログラムに外部データとして与えるスクリプトを設計し、 これを用いて図４(a)の検索フォーム、(b)の文書表示、あるいはパラメータ設定 フォームなどのすべてのHTMLデータを生成させている。
[2] 大山 敬三: ``インターネットに適応した全文データベース検索システムの構成'', 情報処理学会研究報告（情報学基礎研究会）95-FI-37, vol.95,no.45,pp.15-22(1995).
[3] ``学術雑誌汎用DTD'',
URL: "http://www.rd.nacsis.ac.jp/~oyama/paper/kiyo-95/paper.dtd".
[4] ``学術情報センター紀要'',
URL: "http://www.nacsis.ac.jp/rd/bulletin/bulletin-j.html".
[5] ``全文情報検索システム'',
URL: "http://www.rd.nacsis.ac.jp/~oyama/giftir/index.html".
[6] 石塚 英弘ほか: ``日本化学会欧文誌のSGML形式全文データベースの構築・印刷そして検索'', 情報処理学会研究報告（情報学基礎研究会）93-FI-29, vol.93,no.39,pp.1-8(1993).
[7] 山岡 正輝, 岩城 修: ``文書画像のSGML文書への変換に関する一検討'', 電子情報通信学会技術研究報告（パターン認識・理解）PRU94-36, vol.94 No.241,242, pp.73-80(1994).
[8] ``The Open Text Index''
URL: "http://www.opentext.com:8080/".