JP3707133B2 - 文書データベース管理装置および文書データベース管理方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は文書データベース管理装置に関し、特に電子文書を保持管理しかつ複数の文書型にまたがって行われる文書の検索を効率化した文書データベース管理装置および文書データベース管理方法に関する。
【０００２】
【従来の技術】
文書を表現する際には、表現対象の種類ごとに文書型を定義することが行われている。ここで、文書型とは、対応する文書が従うべき構文規則である。
【０００３】
また、章や節、段落や図表などの文書構成要素とそれらの間の接続関係とで文書を表現する構造化文書が広く用いられている。構造化文書の表現形式の一つであるＳＧＭＬ（Ｓｔａｎｄａｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）（ＩＳＯ／ＩＥＣ ８８７９：１９８９；ＪＩＳ Ｘ４１５１）では、文書型（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ、以下ＤＴＤと略称する）を表現するための形式が定められている。ＳＧＭＬについては、例えばＭａｒｔｉｎ Ｂｒｙａｎ著「ＳＧＭＬ入門」、株式会社アスキー、１９９１年３月３１日発行、を参照されたい。
【０００４】
さて、ＳＧＭＬ文書のような構造化文書の文書型では、対応する文書がどのような論理構造を持ち得るのか、すなわち、文書構造中に現われる要素の種類、各要素が持ち得る属性、各要素が持ち得る下位構造が定められていることが一般的である。
【０００５】
ところで、実際の組織では、上で説明したような複数の文書型の構文規則に従う文書が管理されることになる。以下、組織で扱われる文書型の性質について説明する。
【０００６】
組織で作成される文書の文書型は、文書管理を行う組織の要求を反映して定義される。このような文書型を定義する場合、複数の文書型で図表や数式などを表現するための構文規則を共通して定めることが広く行われている。図表や数式などの構文規則は一般に複雑なので、既知の構文規則が文書型の一部として参照されることが多い。このように、組織においては、図表や数式などを表現する構文規則が複数の文書型で共有されている。
【０００７】
さて、このような文書型を文書データベース管理システムに導入する場合、何らかの方法でデータベースのスキーマと文書型とを対応付けることになる。この対応付けの方法としては、以下の二通りの方法が知られている。
【０００８】
第一の方法は、任意の文書型と対応する単一のスキーマをデータベースで提供する方法である。この方法では、どんな文書型の文書も、単一のスキーマのインスタンスとして格納される。この方法の例として、特開平７−４４５７９号公報に記載の論理構造文書検索方式が挙げられる。
【０００９】
第二の方法は、文書型と一対一に対応するスキーマをデータベースで提供する方法である。この方法では、ある文書を格納する時、その文書はその文書の文書型に対応する文書スキーマのインスタンスとして格納される。
【００１０】
ところで、文書要素に関する条件や文書要素間の接続条件を含む問い合わせに対する検索効率を向上させるための方法として、インデックスを用いることが知られている。このインデックスは、文書要素の名称や文書構造における文書要素のパスを保持するエントリの集合から構成され、個々のエントリには対応する文書要素へのポインタが保持されている。
【００１１】
このようなインデックスの例として、特開平７−４４５７９号公報記載の論理構造文書検索方式におけるエレメントパス（文書構造におけるルートから文書要素へのパス）を利用したパスインデックスが挙げられる。パスインデックスは、文書要素間の接続条件を満たす要素の組を効率的に検索するために提供されるもので、エレメントパスを保持するエントリから構成される。検索処理では、個々のパスインデックスエントリが問い合わせの接続条件を満足するか否かのチェックがなされ、接続条件を満足するエントリからポインタが張られている文書要素が接続条件を満足する要素として得られる。
【００１２】
一方、上に挙げた文書型と一対一に対応するスキーマをデータベースで提供する第二の対応付け方法では、文書スキーマごとにインデックスを作成することができる。文書スキーマに対応するインデックスを用いることにより、ある文書スキーマの指すエントリがその文書スキーマの文書のすべての要素を指し、他の文書スキーマの文書の要素を全く指さないことを保証できる。このため、問い合わせと共に文書スキーマが特定されると、特定された文書スキーマに対応するインデックスエントリだけをチェックすることで検索処理が行えるので、検索効率が向上する。
【００１３】
【発明が解決しようとする課題】
ここで、複数の文書型で共有されている図表や数式などを表現する構文規則に現われる要素に関する条件を満足する文書要素の検索方法について、検索処理の効率と文書利用者の負担という二つの観点から評価する。
【００１４】
まず、任意の文書型と対応する単一のスキーマをデータベースで提供する第一の対応付け方法を利用した場合を考える。この場合には、文書利用者がデータベース中の文書に対する問い合わせを一つだけ発行すればよいので文書利用者の負担は小さい。一方、要素を特定する処理では、文書型ごとのインデックスを提供することができないので、インデックス中の全エントリについて、エントリに対応する要素が要素に関する条件を満足するか否かのチェックをしなくてはならない。このため、検索効率は低い。
【００１５】
一方、文書型と一対一に対応するスキーマをデータベースで提供する第二の対応付け方法を採用した場合を考える。この場合には、文書利用者が構文規則を共有する文書型に対応する文書スキーマごとに問い合わせを発行する必要があるので文書利用者の負担は大きい。一方、個々の問い合わせは文書スキーマごとに発行されるので、個々の問い合わせにおける要素特定処理では、文書スキーマに対応するインデックスを利用することで、問い合わせを発行していない文書スキーマに対応するインデックスエントリをチェックせずにすむ。このため、検索効率は高い。
【００１６】
このように、文書データベース管理装置において、複数の文書スキーマで共有される構文規則に現われる要素に関する条件や要素間の接続関係に関する条件を満たす文書を検索する場合には、従来は上記の２通りの方法のいずれかを選択せねばならず、それぞれ対応するデメリットを受け入れなければならないという問題点があった。
【００１７】
本発明はこのような点に鑑みてなされたものであり、複数の文書スキーマで共有される構文規則に現われる要素に関する条件や要素間の接続関係に関する条件を満たす文書を単一の問い合わせで、かつ効率良く検索できる文書データベース管理装置および文書データベース管理方法を提供することを目的とする。
【００１８】
【課題を解決するための手段】
本発明では上記問題を解決するために、電子文書を管理対象とする文書データベース管理装置において、文書の構文規則である文書スキーマを複数保持しているスキーマ保持手段と、前記スキーマ保持手段中の文書スキーマの構文規則を満たした複数の文書が検索対象として保持されている文書保持手段と、前記スキーマ保持手段に保持された文書スキーマを文書利用者に提示してひとつを選択させるとともに前記選択された文書スキーマに基づいて前記文書利用者に前記文書保持手段に格納された文書検索の問い合わせを作成させる問い合わせエディタと、前記選択された文書スキーマおよび前記スキーマ保持手段に保持されている文書スキーマ群を入力とし、前記選択された文書スキーマの構文規則を自らの構文規則の部分集合とする文書スキーマを前記文書スキーマ群から特定するスキーマ特定手段と、前記スキーマ特定手段にて特定された前記文書スキーマ群および前記問い合わせを入力とし、前記文書スキーマ群に対応する前記文書保持手段中の文書から前記問い合わせの条件を満足する文書を検索する文書検索手段と、を具備することを特徴とする文書データベース管理装置が提供される。
このような文書データベース管理装置によれば、スキーマ特定手段は、問い合わせエディタを用いて選択された文書スキーマと、スキーマ保持手段中の文書スキーマ群とを入力することにより、文書スキーマの構文規則を自らの構文規則の部分集合とする文書スキーマを文書スキーマ群から特定し、特定された文書スキーマ群を検索対象の文書群に対応する文書スキーマとして得る。その後、文書検索手段による検索処理では、検索対象の文書の文書スキーマが明らかになっているので、複数の文書型に跨がった文書が単一の問い合わせで検索される。さらに、検索条件を満たし得ない文書要素を検索対象から除外することによって、検索効率が向上される。
また、本発明によれば、電子文書を管理対象とする文書データベース管理方法において、問い合わせエディタがスキーマ保持部に保持された文書スキーマを文書利用者に提示してひとつを選択させるとともに前記選択された文書スキーマに基づいて前記文書利用者に問い合わせを作成させ、スキーマ特定部が前記文書利用者による検索指示により、前記文書利用者によって選択された前記文書スキーマからその文書スキーマをフラグメントとする前記スキーマ保持部中の文書スキーマを特定し、文書検索部が特定された前記文書スキーマと前記文書利用者によって作成された問い合わせとを基にして文書保持部の中の文書に対する検索を行い、出力部が検索によって得られた前記文書保持部の中の文書を出力する、ことを特徴とする文書データベース管理方法が提供される。
この文書データベース管理方法によれば、まず、問い合わせエディタがスキーマ保持部の中の文書スキーマを文書利用者に提示する。提示された文書スキーマからフラグメントとなる文書スキーマを文書利用者が選択すると、問い合わせエディタはその選択された文書スキーマに基づいて問い合わせを作成する。この問い合わせは、フラグメントとなる文書スキーマを文書利用者が選択した時点で、選択された文書スキーマをフラグメントとするすべての文書スキーマの文書を検索結果として得る可能性を持つものとなる。次に、文書利用者により検索指示が出されると、スキーマ特定部により選択された文書スキーマからその文書スキーマをフラグメントとするスキーマ保持部中の文書スキーマが特定され、特定された文書スキーマと文書利用者によって作成された問い合わせとを基にして、文書検索部による文書保持部の中の文書に対する検索が行われる。そして、検索によって得られた文書保持部の中の文書を出力部が出力する。これにより、文書保持部の中の文書に対する検索では、検索対象の文書の文書スキーマが明らかになっているので、複数の文書型に跨がった文書が単一の問い合わせで検索され、しかも、選択された文書スキーマからその文書スキーマをフラグメントとするスキーマ保持部中の文書スキーマが特定されているので、検索条件を満たし得ない文書が検索対象から除外されており、検索効率が向上される。
【００１９】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明するが、まず、本発明の原理構成について先に説明する。
【００２０】
図１は本発明の文書データベース管理装置の原理構成図である。電子文書を管理対象とする本発明の文書データベース管理装置は、文書の構文規則である文書スキーマを保持しているスキーマ保持手段１と、この文書データベース管理装置で管理される電子文書を保持している文書保持手段２と、問い合わせ作成時に使用された文書スキーマとスキーマ保持手段１に保持されている文書スキーマ群とを受けるように接続されたスキーマ特定手段３と、スキーマ特定手段３の出力および文書スキーマの構文規則を満たす文書を対象とした問い合わせを受けるように接続された文書検索制御手段４と、文書検索制御手段４の出力を受けて文書保持手段２に保持されている文書に対して検索を実行するように接続された文書検索手段５とから構成されている。
【００２１】
ここで、作用の説明に入る前に、説明で用いる用語を定義しておく。まず、スキーマを構文規則の集合と考える。あるスキーマの構文規則の集合が他のスキーマの構文規則の集合の部分集合となっている時、前者のスキーマを、後者のスキーマのフラグメントと呼ぶ。
【００２２】
フラグメントという概念はスキーマの包含関係に基づいて定義されているため、単一の文書スキーマのみに着目し、その文書スキーマがフラグメントであるか否かを判断することはできない。
【００２３】
図１に示した文書データベース管理装置には、文書スキーマ保持手段１中の文書スキーマ群のフラグメントとなる文書スキーマと、その文書スキーマに現われる要素に関する条件や要素間の接続条件からなる問い合わせとが入力される。これらの情報が本発明の文書データベース管理装置に入力されると、入力されたフラグメント文書スキーマと、スキーマ保持手段１中の文書スキーマ群とがスキーマ特定手段３に入力される。ここで、スキーマ特定手段３は、入力された文書スキーマをフラグメントとする文書スキーマ群をスキーマ保持手段１より入力された文書スキーマ群から特定する。文書検索制御手段４はスキーマ特定手段３で特定された文書スキーマ群に対応する文書群を検索対象の文書群に対応する文書スキーマとして得る。その後、文書検索手段５による検索処理が行われる。この検索処理では、検索対象の文書の文書スキーマが明らかになっているので、それぞれの文書スキーマに対応するインデックスを利用することができ、高い検索効率を実現できる。
【００２４】
また、文書検索制御手段４は、入力の文書スキーマをフラグメントとする文書スキーマの文書が入力の問い合わせの条件を満足し得るか否かを検証する機能を備えることができる。これに対応して、入力の文書スキーマをフラグメントとする文書スキーマの文書が入力の問い合わせの条件を満足し得ることが検証された場合にのみ、文書検索制御手段４は検索対象の文書に対応する文書スキーマを得ることになる。これにより、問い合わせの作成を誤まるなどして、検索結果の文書が存在し得ないような問い合わせが入力された場合でも、文書に対する検索を行う前に問い合わせの欠陥を検出できるので、問い合わせにヒットし得ない文書スキーマの文書を検索する無駄を事前に防止できることになる。
【００２５】
さらに、文書検索制御手段４が上記検証する機能を備える文書データベース管理装置であって、文書要素と文書要素間の接続関係で表現される構造化文書が文書保持手段２で保持されており、入力される問い合わせが文書要素型に関する条件と文書要素型の間の接続条件とからなる状況では、文書検索制御手段４で出力される文書スキーマの条件は以下のように具体化される。
【００２６】
まず、文書データベース管理システムの文書検索制御手段４で出力される文書スキーマの条件は、条件１として入力された文書スキーマの構文規則の集合が該文書スキーマの構文規則の部分集合であること、および条件２として該文書スキーマの文書が問い合わせの条件を満足し得ることである。
【００２７】
条件１を検証するためには、前者の文書スキーマの構文規則と後者の文書スキーマの構文規則とを比較すればよい。この条件については、上の状況を考慮した具体化は必要ないと考える。
【００２８】
したがって、以下に、上の状況において条件２を検証するための具体的な方法について検討する。
命題（１）：本発明の文書データベース管理装置における文書保持手段中の文書が構造化文書であり、その文書に対する問い合わせが文書要素に関する条件と文書要素間の接続関係に関する条件とで表現される場合を考える。このとき、ある文書スキーマと問い合わせに関して、以下の条件（１）が成立するならば、その文書スキーマの文書はその問い合わせの条件を満足し得ない：
条件（１）：文書スキーマにおける文書要素型間の接続関係を組み合わせることで、問い合わせで用いられている文書要素間の接続条件が表現できない。
【００２９】
ここで、文書要素型間の接続関係を組み合わせて文書要素間の接続関係を生成する処理について説明する。
文書要素型はある種の文書要素が保持すべき性質を記述したものである。一方、個々の文書要素は、ただ一つの文書要素型に対応し、その文書要素型の性質を継承している。文書要素型と文書要素との間には、このような対応関係が存在する。
【００３０】
一方、文書スキーマを木構造と見たとき、木構造における個々のアークは文書要素型間の親子関係を表している。そして、各々のアークの両端にはノードとして文書要素型が一つずつ存在することになる。
【００３１】
そして、文書要素型間の親子関係が階層的に存在する場合には、ある文書要素型Ａの子供である文書要素型Ｂが他の文書要素型Ｃの親になるという状況が発生する。この場合には、上に挙げた親子関係以外に「文書要素型Ａは文書要素型Ｃの祖先である」という接続関係も表現されていることになる。本明細書では、この祖孫間の接続関係を「文書要素型Ａと文書要素型Ｂとの間の接続関係と、文書要素型Ｂと文書要素型Ｃとの間の接続関係とを組み合わせたことによる文書要素型Ａと文書要素型Ｃとの接続関係」と呼ぶ。
【００３２】
以上の説明では、文書要素型間の接続関係を組み合わせても文書要素間の接続関係を表現することにはならないが、すでに述べた文書要素型と文書要素の対応関係を利用して、接続関係の組み合わせにより生成された接続関係に関わる文書要素型ごとにその文書要素型と対応する文書要素と置き換えることで、文書要素間の接続関係を表現できる。
【００３３】
さて、命題（１）が真であることは自明であると考えられる。
命題（２）：ある文書スキーマとある問い合わせについて、以下の条件（２）が成立するならば、その文書スキーマの文書はその問い合わせの条件を満足し得ない：
条件（２）：前記文書スキーマのフラグメントとなる文書スキーマにおける文書要素型間の接続関係を組み合わせることで、問い合わせで用いられている文書要素間の接続条件が表現できない。
【００３４】
以下、命題（１）が真であることを利用して、命題（２）が真であることを証明する。
ある文書スキーマにおける文書要素型のすべての接続関係を要素とする集合は、その文書スキーマをフラグメントとする文書スキーマにおける文書要素間のすべての接続関係を要素とする集合の部分集合である。
【００３５】
このため、命題（１）が真であるなら命題（２）が真であることは明らかである。よって、命題（２）は真である。
もし、文書スキーマと問い合わせとが上記の条件（２）を満足してしまう場合には、その問い合わせでその文書スキーマの文書を検索してもヒットする可能性はない。このため、本発明の文書データベース管理装置の文書検索制御手段４においては、フラグメントとなる文書スキーマおよび問い合わせが入力されると、先に示した条件１に加えて上記の条件（２）を満足しないことが明らかになった場合のみ、入力された文書スキーマをフラグメントとする文書スキーマを出力する。これにより、ヒットする文書が存在し得ない問い合わせの発行を減少させることができ、検索効率がさらに向上することになる。
【００３６】
次に、本発明の文書データベース管理装置の具体例について説明する。
図２は文書データベース管理装置の構成例を示すブロック図である。図２に示した文書データベース管理装置１０は、スキーマ保持部１１、文書保持部１２、スキーマ特定部１３、文書検索制御部１４、文書検索部１５から構成される。また、スキーマ特定部１３には、スキーマ共有関係テーブル１３ａ、要素セット１３ｂおよび接続関係テーブル１３ｃを保持している。文書データベース管理装置１０は入出力装置２０を通じて文書利用者３０によって操作される。
【００３７】
スキーマ保持部１１は、文書保持部１２の中の文書に対応する文書スキーマを保持する。スキーマ保持部１１は、メモリ、磁気ディスクといった計算機の記憶領域上に実現される。文書保持部１２は、この文書データベース管理装置１０で管理される電子文書を保持する。文書保持部１２は、スキーマ保持部１１と同様、計算機の記憶領域上に実現される。スキーマ特定部１３は、文書検索制御部１４を介して入出力装置２０からの文書スキーマとスキーマ保持部１１からの文書スキーマ群とを入力とし、前者の文書スキーマをフラグメントとする文書スキーマを後者の文書スキーマ群から特定して出力する。スキーマ特定部１３は、このような動作を実行するための手続きを記述した計算機プログラムで実現される。なお、スキーマ特定部１３が保持するスキーマ共有関係テーブル１３ａと、要素セット１３ｂおよび接続関係テーブル１３ｃとについては後述する。文書検索制御部１４は、入出力装置２０からの問い合わせと文書スキーマとを入力とし、入力された文書スキーマとスキーマ保持部１１の中の文書スキーマ群をスキーマ特定部１３に入力する。そしてスキーマ特定部１３から得られた文書スキーマ群および入力された問い合わせを検索対象の文書に対応する文書スキーマとして文書検索部１５に渡す。文書検索制御部１４は、このような動作を実行するための手続きを記述した計算機プログラムで実現される。そして、文書検索部１５は、文書検索制御部１４からの問い合わせと文書スキーマ群とを入力とし、文書保持部１２の中の文書のうち入力された文書スキーマに対応する文書から入力された問い合わせの条件を満足する文書を検索して出力装置に出力する。文書検索部１５は、このような動作を実行するための手続きを記述した計算機プログラムで実現される。文書検索部１５では、前述したインデックスを利用して、検索処理を高速に実行することが実現可能である。
【００３８】
入出力装置２０は、文書利用者３０から、問い合わせおよび他の文書スキーマのフラグメントとなる文書スキーマを特定する指示を得て、文書検索制御部１４に出力する入力装置と、文書検索部１５から検索の結果得られた文書を得て可視化表示する出力装置とから構成される。入力装置は、例えば、マウス、キーボード、計算機プログラムなどを利用して容易に実現できる。また、出力装置は、例えば、印刷装置、ディスプレイ、ディスプレイ制御用の計算機プログラムなどを利用して容易に実現できる。
【００３９】
なお、文書データベース管理装置１０および入出力装置２０で用いられる構成要素は、パーソナルコンピュータやワークステーションなどといった計算機上の資源および周辺機器を用いて実現することが可能である。
【００４０】
上記構成の文書データベース管理装置１０の全体的な処理の流れについて説明する。
図３は文書データベース管理装置の動作の一例を説明する流れ図である。なお、Ｓに続く数字はステップ番号を示している。
〔Ｓ１〕スキーマ保持部１１の中の文書スキーマが入出力装置２０を介して文書利用者３０に提示される。
〔Ｓ２〕フラグメントとなる文書スキーマが文書利用者３０によって選択され、選択された文書スキーマに基づいて問い合わせを作成する。この時作成される問い合わせが満足すべき条件について、以下に説明する。まず、文書利用者３０は、フラグメントとなる文書スキーマを選択した時点で、その文書スキーマをフラグメントとするすべての文書スキーマの文書を検索対象にしようと考えているはずである。このため、作成される問い合わせは、選択された文書スキーマをフラグメントとするすべての文書スキーマについて、その文書スキーマの文書を検索結果として得る可能性を持つものでなくてはならない。
〔Ｓ３〕文書利用者３０により検索指示が文書データベース管理装置１０に出され、文書利用者３０によって選択された文書スキーマが文書データベース管理装置１０の中のスキーマ特定部１３に入力される。
〔Ｓ４〕スキーマ特定部１３が起動し、入力された文書スキーマからその文書スキーマをフラグメントとするスキーマ保持部中の文書スキーマが特定される。
〔Ｓ５〕文書検索制御部１４および文書検索部１５が起動し、ステップＳ４で特定された文書スキーマと文書利用者によって作成された問い合わせを基にして、文書保持部１２の中の文書に対する検索が行われる。
〔Ｓ６〕文書検索部１５によって得られた文書保持部１２の中の文書が出力装置を介して文書利用者３０に示される。以上で、文書データベース管理装置１０の一連の動作が終了する。
【００４１】
ここで、構文規則である文書スキーマが文書属性の型のみからなる場合を例にした第１の実施の形態について説明する。具体例として、スキーマ保持部１１に保持される文書スキーマは「報告書スキーマ」、「論文スキーマ」、「基本文書スキーマ」、「技術文書スキーマ」、および「特殊文書スキーマ」の５つであるとする。
【００４２】
図４はスキーマ保持部における文書スキーマの一例を示す説明図である。図４には、スキーマ保持部１１に保持されている文書スキーマ「報告書スキーマ」、「論文スキーマ」、「基本文書スキーマ」、「技術文書スキーマ」、および「特殊文書スキーマ」を示している。
【００４３】
図４における文書スキーマの表記方法について説明する。まず、各行には、文書スキーマに属する文書が保持すべき属性に関する情報が記述される。ただし、行頭に”＊”がある行は、”＊”直後の文字列の名称を持つスキーマフラグメントを文書スキーマの一部として含むことを意味する。”＊”を行頭に持たない個々の行においては、”：”の前までが属性の名称を表し、”：”の後が属性の値の型（”（”および”）”で囲まれている場合）、または、値として取り得る候補（”［”および”］”で囲まれている場合）を表している。
【００４４】
したがって、図示の記述例によれば、報告書スキーマの文書は「評価」という名称の管理属性を持ち、その値は”Ａ”、”Ｂ”、”Ｃ”のいずれかである。同様に、論文スキーマの文書は「学会名」および「採録の可否」という名称の管理属性を持ち、「学会名」属性の値は任意の文字列であり、「採録の可否」属性の値は”ＯＫ”または”ＮＧ”のいずれかである。また、報告書スキーマおよび論文スキーマは共に文書スキーマ「技術文書スキーマ」をフラグメントとしているので、上に挙げた属性に加えて技術文書スキーマで定義される属性をも文書スキーマの一部として含む。技術文書スキーマの文書は、「技術分野」という名称の属性を持つ。「技術分野」属性の値は”ハード”または”ソフト”のいずれか一方である。技術文書スキーマは文書スキーマ「基本文書スキーマ」をフラグメントとしているので、基本文書スキーマで定義される属性をも文書スキーマの一部として含む。基本文書スキーマの文書は「文書表題」、「著者名」、「発行日」という名称の属性を持つ。「文書表題」属性の値は任意の文字列であり、「著者名」属性の値は人名型のデータを要素とするリストであり、「発行日」属性の値は日付型のデータである。特殊文書スキーマの文書は「文書表題」、「著者名」、「有効期限」、「配布範囲」という名称の属性を持つ。「文書表題」属性の値は任意の文字列であり、「著者名」属性の値は人名型のデータを要素とするリストであり、「有効期限」属性の値は日付型のデータであり、「配布範囲」属性の値は”研究所”または”研究グループ”のいずれかである。
【００４５】
次に、文書保持部１２に保持される文書の具体例として、文書保持部１２に保持される文書は「報告書Ａ」、「報告書Ｂ」、「報告書Ｃ」、「論文Ａ」、「論文Ｂ」、「特殊文書Ａ」、「特殊文書Ｂ」、および「特殊文書Ｃ」の８つであるとする。
【００４６】
図５ないし図７は文書保持部における文書の一例を示す説明図である。図５ないし図７には、文書保持部１２に保持される文書「報告書Ａ」、「報告書Ｂ」、「報告書Ｃ」、「論文Ａ」、「論文Ｂ」、「特殊文書Ａ」、「特殊文書Ｂ」、および「特殊文書Ｃ」を示している。
【００４７】
図５ないし図７における文書の表記方法について説明する。個々の文書における最初の空行の前には、属性名と属性値との組が”：”を区切り子として各行に記述されている。最初の空行の後には、文書の内容が記述される。なお、各文書の先頭の属性「文書スキーマ」は、文書スキーマでは定義されていないものであるが、文書格納時に本発明の文書データベース管理装置が自動的に付与する属性であるものとする。
【００４８】
次に、第１の実施の形態においては、スキーマ特定部１３は、フラグメントとなる文書スキーマから対応する文書スキーマを特定するため、内部的にスキーマ共有関係テーブル１３ａを保持するものとする。
【００４９】
図８はスキーマ共有関係テーブルの一例を示す説明図である。図８におけるスキーマ共有関係テーブル１３ａの表記方法について説明する。” ”（空白）以外の文字で始まる行はフラグメントとなる文書スキーマの名称を表す。また、空白で始まる行は、テーブルを先頭から辿った時、その空白で始まる行に到達するすぐ前に見出されたフラグメントの文書スキーマを一部とする文書スキーマの名称を表す。よって、図８のテーブルは、技術文書スキーマが報告書スキーマおよび論文スキーマのフラグメントであること、および、基本文書スキーマが技術文書スキーマのフラグメントであることを表している。
【００５０】
このスキーマ共有関係テーブル１３ａは、文書利用者３０による検索指示がなされる前に、あらかじめスキーマ特定部１３によって作成されるものとする。そのスキーマ共有関係テーブル１３ａの作成処理の一例を以下に示す。
【００５１】
図９および図１０はスキーマ共有関係テーブル作成の処理の一例を説明する流れ図である。このスキーマ共有関係テーブル作成処理では、一時ファイルが利用される。このため、ステップＳ１１では、処理の前準備としてこの一時ファイルがクリアされる。
〔Ｓ１２〕スキーマ保持部１１の中の文書スキーマのうち、ステップＳ１４以降で評価されていないものが存在するか否かがチェックされ、もし存在する場合は処理をステップＳ１３に進め、存在しない場合は処理をステップＳ１６に進める。
〔Ｓ１３〕ステップＳ１４以降で評価されていないスキーマ保持部１１の中の文書スキーマを一つ特定し、処理をステップＳ１４に進める。
〔Ｓ１４〕ステップＳ１３で特定された文書スキーマの記述を参照し、行頭に”＊”が与えられている行をすべて特定し、その行の文字列から先頭の”＊”を除いたものをステップＳ１３で特定された文書スキーマのフラグメントとなる文書スキーマ名称として得て、処理をステップＳ１５に進める。
〔Ｓ１５〕ステップＳ１３で特定した文書スキーマと、ステップＳ１４で特定したフラグメントである文書スキーマとの組を、参照元の文書スキーマと参照先の文書スキーマが明示される形式で一時ファイルに追加し、処理をステップＳ１２に進める。
〔Ｓ１６〕一時ファイルが空であるか否かがチェックされ、もし空であれば処理を終了し、空でない場合は処理をステップＳ１７に進める。
〔Ｓ１７〕一時ファイルで参照先として記述されている文書スキーマを一つ特定し、処理をステップＳ１８に進める。
〔Ｓ１８〕一時ファイルから、ステップＳ１７で特定された文書スキーマが参照先としてステップＳ１５で書き込まれている組すべてを特定し、処理をステップＳ１９に進める。
〔Ｓ１９〕ステップＳ１７で特定された文書スキーマ名称からなる行をスキーマ共有関係テーブル１３ａの末尾に追加し、処理をステップＳ２０に進める。
〔Ｓ２０〕ステップＳ１８で特定された組の参照元の文書スキーマごとに、その名称の先頭に” ”（空白）一つを加えた文字列からなる行をスキーマ共有関係テーブル１３ａの末尾に追加し、処理をステップＳ２１に進める。
〔Ｓ２１〕ステップＳ１８で特定された組を一時ファイルから削除し、処理をステップＳ１６に戻す。
【００５２】
次に、上で示した文書スキーマが保持されている状況でスキーマ共有関係テーブル１３ａを作成した場合に、ステップＳ１２からステップＳ１６に処理が進んだ時点での一時ファイルの内容例を以下に示す。
【００５３】
図１１はスキーマ共有関係テーブル作成時の一時ファイルの内容例を示す図である。図１１の一時ファイルでは、各行に参照元と参照先が組として記述されている。各行では、”：”を区切り子とし、前に参照元の文書スキーマの名称、後に参照先の文書スキーマの名称が記述される。
【００５４】
なお、上に示したスキーマ共有関係テーブル作成処理は、スキーマ特定部１３が起動する図３のステップＳ４において実行されてももちろん構わない。
以下、上述した文書データベース管理装置１０の動作の一例について、具体例を基に詳細に説明する。以下の説明は、図３で示した文書データベース管理装置１０の全体的な処理の流れに従って説明する。
【００５５】
まず、ステップＳ１における文書スキーマの提示では、スキーマ保持部１１の中の文書スキーマをリストアップした問い合わせエディタがディスプレイ上に表示されて、文書利用者３０に選択を促す。その問い合わせエディタの一例を以下に示す。
【００５６】
図１２は問い合わせエディタの一例を示す図である。図１２の問い合わせエディタ４０には、文書スキーマリスト表示領域４１、スキーマ表示領域４２、問い合わせ作成領域４３、および”適用”ボタン４４が備えられている。文書スキーマリスト表示領域４１には、スキーマ保持部１１の中の文書スキーマの名称が一覧表示される。
【００５７】
続いて、ステップＳ２では、文書利用者３０は問い合わせ作成時に利用する文書スキーマを一つだけ選択する。ここでは、文書スキーマ「基本文書スキーマ」が選択されたものとする。選択された文書スキーマを基に、文書利用者３０が問い合わせを作成する。ここでは、選択された文書スキーマの表現を参照したり、問い合わせを作成するために、図１２の問い合わせエディタ４０を用いる。先に文書スキーマ「基本文書スキーマ」が選択されているので、それに対応してスキーマ表示領域４２には「基本文書スキーマ」の記述が表示される。文書利用者３０はこの表示を参照したり、記述の一部を再利用することで問い合わせを作成していく。
【００５８】
図１３は問い合わせが作成された時点での問い合わせエディタの表示例を示す図である。図１３に示した問い合わせエディタ４０で表現されている問い合わせの表記方法について説明する。問い合わせは、各行に記された検索条件の連言標準形として解釈される。個々の行では、行頭に属性名が示され、関係子および直後の属性値によって属性値に関する検索条件が与えられる。このため、問い合わせ作成領域４３に表示されている問い合わせは、「文書表題」属性の値に”異種混合”という文字列を含み、かつ、「発行日」属性の日付型の値が”１９９６年３月１日”以前であるような文書の問い合わせを意味する。
【００５９】
続いて、ステップＳ３の検索指示では、文書利用者３０によって文書データベース管理装置１０に検索指示が出され、ステップＳ２で選択された文書スキーマがスキーマ特定部１３に入力される。本実施の形態においては、文書利用者３０による検索指示は、問い合わせエディタ４０の下部の”適用”ボタン４４を押下することでなされ、スキーマ特定部１３には、問い合わせエディタ４０で選択された「基本文書スキーマ」が入力されることになる。
【００６０】
ステップＳ４の文書スキーマの特定では、スキーマ特定部１３が起動し、ステップＳ３で入力された文書スキーマをフラグメントとするスキーマ保持部１１の中の文書スキーマを特定する。ここで、文書スキーマを特定する処理の一例を以下に示す。
【００６１】
図１４はスキーマ特定部の処理の一例を示す流れ図である。文書スキーマを特定する処理に先立ち、ステップＳ３１では、内部的に保持する展開対象リストおよび出力リストをクリアする。
〔Ｓ３２〕入力された文書スキーマを展開対象リストおよび出力リストの末尾に追加する。
〔Ｓ３３〕展開対象リストが空であるか否かを判断する。その結果、空である場合は処理をステップＳ３６に進め、文書スキーマの名前が入っている場合は処理をステップＳ３４に進める。
〔Ｓ３４〕スキーマ特定部１３の内部に保持するスキーマ共有関係テーブル１３ａを参照し、ステップＳ３２での展開対象リスト先頭の文書スキーマをフラグメントとする文書スキーマを特定する。そして、特定された文書スキーマが出力リストに記述されていない場合には、その文書スキーマを出力リストおよび展開対象リストの末尾に追加する。
〔Ｓ３５〕展開対象リスト先頭の文書スキーマを削除し、処理をステップＳ３３に戻す。
〔Ｓ３６〕出力リスト中の文書スキーマを出力して処理を終了する。
【００６２】
本実施の形態では、フラグメントとなる文書スキーマとして基本文書スキーマが入力されたので、基本文書スキーマをフラグメントとする技術文書スキーマ、技術文書スキーマをフラグメントとする報告書スキーマと論文スキーマ、および基本文書スキーマ自身の合計４つの文書スキーマが出力されることになる。
【００６３】
次に、図３のステップＳ５の文書の検索では、文書検索部１５において、ステップＳ４で出力された文書スキーマの文書が特定され、それらの文書のみを対象にして、問い合わせの条件を満たす文書が検索される。本実施の形態では、文書の「文書スキーマ」属性を参照することで、文書の文書スキーマを容易に特定することができ、ここでは、文書保持部１２の中の８つの文書のうち、報告書スキーマに対応する報告書Ａ、報告書Ｂ、報告書Ｃと、論文スキーマに対応する論文Ａ、論文Ｂの合計５つの文書が検索の対象となる。
【００６４】
文書検索部１５での文書検索処理は、既存の文書検索システムの機能を用いて実現できるので、具体的な処理手順の説明は省略する。本実施の形態においては、文書検索部１５における文書検索処理の結果得られる文書は、報告書Ａおよび論文Ａの合計２つである。
【００６５】
そして、ステップＳ６の検索結果の表示では、ステップＳ５で得られた文書がディスプレイなどの出力装置を介して文書利用者３０に示される。検索の結果得られた文書を文書利用者３０に示す文書ホルダを図１５に示す。
【００６６】
図１５は検索結果を表示する文書ホルダの表示例を示す図である。図１５の文書ホルダ５０には、文書リスト表示領域５１および文書表示領域５２が備えられている。文書リスト表示領域５１には、検索の結果得られた文書の文書表題属性の値が一覧表示されている。文書リストの項目を選択すると、対応する文書の内容が文書表示領域に表示される。図１５は、報告書Ａが選択された様子を示している。この文書ホルダ５０を利用して、文書利用者３０は問い合わせエディタを通じて指示した検索処理の結果を得ることができる。
【００６７】
以上の一連の処理の結果、文書利用者３０は、報告書スキーマと論文スキーマという、異なる文書スキーマの文書を単一の問い合わせで検索することができた。しかも、問い合わせに適合する可能性のない特殊文書スキーマの文書をあらかじめ検索対象から除外して検索処理を行うことができた。
【００６８】
なお、この第１の実施の形態では、文書利用者による検索指示が出されてから、文書スキーマをフラグメントとする文書スキーマを特定した。しかし、検索指示の前にスキーマ保持部中のすべての文書スキーマについて、その文書スキーマを一部として含むすべての文書スキーマを挙げ、それらの対応関係を内部的に保持しておく一方、検索指示の後の処理では、内部的に保持されている対応関係を基にして検索対象の文書スキーマを決定するよう構成することももちろん実現可能である。
【００６９】
次に、文書型を持つ構造化文書であるＳＧＭＬ文書に適用した第２の実施の形態について説明する。
第２の実施の形態では、スキーマ保持部１１の中の文書スキーマおよび文書保持部１２の中の文書が第１の実施の形態で使用したものと異なるので、これら文書スキーマおよび文書の例を以下に示す。
【００７０】
第２の実施の形態における文書スキーマは、文書要素の型に関する規則と、文書要素型の間の接続関係に関する規則とから構成されるもので、スキーマ保持部１１に、たとえば「ｒｅｐｏｒｔ」、「ｍｅｍｏ」、「ｓｅｃｔ」、および「ｍｉｓｃ」の４つの文書スキーマが保持されているものとする。
【００７１】
図１６は文書スキーマの一例の説明図である。図１６には、スキーマ保持部１１に保持されている文書スキーマ「ｒｅｐｏｒｔ」、「ｍｅｍｏ」、「ｓｅｃｔ」、および「ｍｉｓｃ」を示している。図１６における文書スキーマの表記方法は、ＳＧＭＬの参照具体構文に基づくＤＴＤの構文の表記方法であるので、詳細な表記方法の説明は省略する。ここでは、各文書スキーマのうち、「ｒｅｐｏｒｔ」スキーマが意味する構文規則を書き下すこととする。
【００７２】
ｒｅｐｏｒｔスキーマは、ｒｅｐｏｒｔスキーマの文書に対し、以下の構文規則を満足することを要求する。すなわち、文書全体を表すｒｅｐｏｒｔ要素の直下に１つのｆｒｏｎｔ要素、１つ以上のｃｈａｐ要素、１つのｂａｃｋ要素がこの順序で保持されなくてはならない。ｆｒｏｎｔ要素の直下に１つのｔｉｔｌｅ要素、１つのａｕｔｈｏｒ要素、１つのｎｏｔｅ要素がこの順序で保持されなくてはならない。ａｕｔｈｏｒ要素、ｎｏｔｅ要素はいずれも直下に他の要素を持たず、内容として内容データを保持しなくてはならない。ｃｈａｐ要素の直下に１つのｔｉｔｌｅ要素、０個以上のｐａｒａ要素、１つ以上のｓｅｃｔ要素がこの順序で保持されなくてはならない。システム識別子”ｓｅｃｔ”で識別される外部実体の内容として表現される構文規則を満足しなくてはならない。ｂａｃｋ要素の直下に１つのｂｉｂｌｉｏ要素、１つのｉｎｄｅｘ要素がこの順序で保持されなくてはならない。ｂｉｂｌｉｏ要素、ｉｎｄｅｘ要素はいずれも直下に他の要素を持たず、内容として内容データを保持しなくてはならない。
【００７３】
上の構文規則の説明で示したように、ｒｅｐｏｒｔはｓｅｃｔをフラグメントとしている。同様に、ｍｅｍｏもｓｅｃｔをフラグメントとしている。
一方、第２の実施の形態において文書保持部１２に保持される文書は、たとえば「ｒｅｐｏｒｔ１」、「ｒｅｐｏｒｔ２」、「ｒｅｐｏｒｔ３」、「ｍｅｍｏ１」、「ｍｅｍｏ２」、「ｍｉｓｃ１」、「ｍｉｓｃ２」、および「ｍｉｓｃ３」の８つであるとし、以下にその内容例を示す。
【００７４】
図１７ないし図２０は第２の実施の形態における文書の一例を示す図である。図１７ないし図２０には、文書保持部１２に保持される「ｒｅｐｏｒｔ１」、「ｒｅｐｏｒｔ２」、「ｒｅｐｏｒｔ３」、「ｍｅｍｏ１」、「ｍｅｍｏ２」、「ｍｉｓｃ１」、「ｍｉｓｃ２」、および「ｍｉｓｃ３」を示している。
【００７５】
図１７ないし図２０における文書の表記方法は、ＳＧＭＬの参照具体構文に基づくＳＧＭＬ文書の構文の表記方法であるので、表記方法の説明は省略する。
このような文書スキーマおよび文書が保持されているため、スキーマ特定部１３の内部で保持されるスキーマ共有関係テーブル１３ａは図２１のように表現される。
【００７６】
図２１は第２の実施の形態におけるスキーマ共有関係テーブルの一例を示す説明図である。図示のスキーマ共有関係テーブルによれば、ｓｅｃｔスキーマがｒｅｐｏｒｔスキーマおよびｍｅｍｏスキーマによって共有されていることを表している。
【００７７】
第２の実施の形態における文書データベース管理装置１０の基本的な動作の流れは、図３で示した動作の流れと同一であるので、以下、文書データベース管理装置１０の動作例を図３の流れに従って説明する。
【００７８】
まず、ステップＳ１の文書スキーマの提示では、第１の実施の形態の場合と同様に、スキーマ保持部１１の中の文書スキーマをリストアップした問い合わせエディタ４０がディスプレイ上に表示され、文書利用者３０に文書スキーマの選択を促す。このときの問い合わせエディタ４０の表示例を図２２に示す。
【００７９】
図２２は問い合わせエディタの表示例を示す図である。図２２に示した問い合わせエディタ４０によれば、文書スキーマリスト表示領域４１には、スキーマ保持部１１に保持されている文書スキーマの名称（文書構造の根となる要素型の名称）が一覧表示される。すなわち、「ｒｅｐｏｒｔ」、「ｍｅｍｏ」、「ｓｅｃｔ」、「ｍｉｓｃ」が一覧表示される。
【００８０】
続いて、ステップＳ２では、文書スキーマリスト表示領域４１に表示されているリストに対して、文書利用者３０は問い合わせ作成時に利用する文書スキーマを一つだけ選択する。ここでは、文書スキーマ「ｓｅｃｔ」が選択されたものとする。選択された文書スキーマを基に、文書利用者３０が問い合わせを作成する。選択された文書スキーマの参照や問い合わせの作成には図２２の問い合わせエディタ４０が用いられる。文書スキーマ「ｓｅｃｔ」が選択されているので、それに対応してスキーマ表示領域４２では「ｓｅｃｔ」の記述が表示される。文書利用者３０はこの表示を参照したり、記述の一部を再利用することで問い合わせを作成していく。
【００８１】
図２３は問い合わせが作成された時点での問い合わせエディタの表示例を示す図である。図２３に示した問い合わせエディタ４０で表現されている問い合わせの表現方法について説明する。問い合わせは、文書スキーマの文書要素型に関する条件および文書要素タイプ間の接続関係で表現される。問い合わせ作成領域４３においては、文書要素タイプに関する条件は領域中の個々の矩形領域に示される。また、文書要素タイプ間の接続条件は、矩形領域を結ぶアークで示される。問い合わせ作成領域４３における矩形領域内の表記の意味は、
＜要素型名＞（”＜要素が含むべき文字列＞”）
である。また、矩形領域間が実線の矢印で接続されている場合、矢印の元の矩形領域に対応する要素型が、矢印の先の矩形領域に対応する要素型の親にあたることを意味する。同様に、矩形領域間が破線の矢印で接続されている場合、矢印の元の矩形領域に対応する要素型が、矢印の先の矩形領域に対応する要素型の祖先にあたることを意味する。
【００８２】
このため、問い合わせ作成領域４３の中で表示されている問い合わせは、内容に文字列”異種”を含むｔｉｔｌｅ要素を子供に持ち、内容に文字列”混合”を含むｐａｒａ要素を子孫に持つｓｅｃｔ要素を持った文書の問い合わせを意味している。
【００８３】
続いて、ステップＳ３の検索指示では、文書利用者３０によって文書データベース管理装置１０に検索指示が出され、ステップＳ２で選択された文書スキーマがスキーマ特定部１３に入力される。文書利用者３０による検索指示は、問い合わせエディタ４０の下部にある”適用”ボタン４４を押下することでなされ、スキーマ特定部には、問い合わせエディタで選択された「ｓｅｃｔ」が入力されることになる。
【００８４】
ステップＳ４の文書スキーマの特定では、スキーマ特定部１３が起動し、ステップＳ３で入力された文書スキーマをフラグメントとするスキーマ保持部１１の中の文書スキーマを特定する。第２の実施の形態におけるスキーマ特定部１３の処理の流れは、第１の実施の形態において図１４で示された流れと同一であるので、説明を省略する。ここでは、スキーマ特定部１３は、フラグメントとなる文書スキーマとしてｓｅｃｔが入力されたので、ｓｅｃｔをフラグメントとするｒｅｐｏｒｔとｍｅｍｏ、そしてｓｅｃｔ自身の合計３つの文書スキーマを文書検索制御部１４に出力することになる。
【００８５】
ステップＳ５では、文書検索部１５において、ステップＳ４で出力された文書スキーマの文書が特定されて、特定された文書のみを対象にして問い合わせの条件を満たす文書が検索される。ここでは、文書先頭行のｄｏｃｔｙｐｅ宣言に記載されているＤＴＤ名を参照することで、文書が従う文書スキーマを特定することができる。すなわち、文書保持部１２の中の８つの文書のうち、ｒｅｐｏｒｔスキーマに従うｒｅｐｏｒｔ１、ｒｅｐｏｒｔ２、ｒｅｐｏｒｔ３、および、ｍｅｍｏスキーマに従うｍｅｍｏ１およびｍｅｍｏ２の合計５つの文書が検索の対象となる。
【００８６】
文書検索部１５での処理は、文書要素型間の接続関係による問い合わせを扱う構造化文書検索システムの機能を用いて実現出来るので、具体的な処理手順の説明は省略する。ここでは、文書検索部１５における検索処理の結果得られる文書は、ｒｅｐｏｒｔ１、ｒｅｐｏｒｔ２、およびｍｅｍｏ１の３つである。
【００８７】
ステップＳ６の検索結果の表示では、ステップＳ５で得られた文書がディスプレイを介して文書利用者３０に示される。検索の結果得られた文書を文書利用者に表示する文書ホルダは図１５に示した文書ホルダ５０と同一であるので、説明を省略する。
【００８８】
以上の一連の処理の結果、文書利用者３０は、ｒｅｐｏｒｔとｍｅｍｏという、異なる文書スキーマの文書を単一の問い合わせで検索することができた。しかも、問い合わせに適合する可能性のないｍｉｓｃの文書をあらかじめ検索対象から外して検索処理を効率よく行うことができた。
【００８９】
次に、第３の実施の形態として、実際にＳＧＭＬ文書の検索を行う前に、入力の文書スキーマをフラグメントとする文書スキーマの文書が入力の問い合わせの条件を満足し得ないか否かを検証する機能を備えている場合を例にして、以下に説明する。
【００９０】
ただし、文書データベース管理装置１０のスキーマ特定部１３は、文書保持部１２の中の文書に対する問い合わせとスキーマ保持部１１の中の文書スキーマとを入力とし、以下の条件すべてを満足するスキーマ保持部１１の中の文書スキーマを出力するものとする。すなわち、条件１：入力された文書スキーマの構文規則の集合が該文書スキーマの構文規則の部分集合であること、条件２：問い合わせで用いられるすべての文書要素が、フラグメントとなる文書スキーマで文書要素型として定められていること、および条件３：フラグメントとなる文書スキーマにおける文書要素型間の接続関係を組み合わせることにより問い合わせで用いられている文書要素間の接続条件が表現できることである。
【００９１】
したがって、スキーマ特定部１３は、このような動作を実行するための手続きを記述した計算機プログラムで実現される。また、スキーマ特定部１３は、図２に示したように、スキーマ共有関係テーブル１３ａに加え、スキーマ保持部１１の中の個々の文書スキーマに対応した要素セット１３ｂと接続関係テーブル１３ｃとを内部的に保持しているものとする。
【００９２】
要素セット１３ｂには、文書スキーマで定義された文書要素型の集合が保持される。また、接続関係テーブル１３ｃには、個々の文書要素に関し、その要素の子供となる文書要素型の集合と、その要素の子孫となる文書要素型の集合とが保持される。この要素セット１３ｂおよび接続関係テーブル１３ｃは、スキーマ特定部１３の処理において、上記の条件３を検証する際に用いられる。
【００９３】
要素セット１３ｂを作成するためには、文書スキーマ中の個々の要素宣言について、宣言されている要素をすべて要素セット１３ｂに格納すればよい。この処理は、既存の文字列処理言語を用いることで容易に実現可能である。作成された要素セット１３ｂの例を以下に示す。
【００９４】
図２４は要素セットの保持内容を示す図である。図２４に示した要素セット１３ｂには、スキーマ保持部１１に保持されている文書スキーマ「ｒｅｐｏｒｔ」、「ｍｅｍｏ」、「ｓｅｃｔ」、および「ｍｉｓｃ」の中でそれぞれ宣言されているすべての要素が記述されており、文書スキーマごとにどのような要素があるかを示している。
【００９５】
次に、接続関係テーブル１３ｃの作成処理について以下に説明する。
図２５は接続関係テーブル作成の処理の一例を示す流れ図である。接続関係テーブル１３ｃを作成する以下の処理では、キューを保持する変数Ｑと、集合を保持する変数Ｓが内部的に用いられる。
〔Ｓ４１〕作成対象の文書スキーマのルートが選択され、処理をステップＳ４２に進める。
〔Ｓ４２〕選択した要素型を起点として、親から子を辿って到達できる要素型の集合を求め、処理をステップＳ４３に進める。
〔Ｓ４３〕ステップＳ４２で得た要素型の集合にルートを加えた集合を変数Ｓに保持させ、処理をステップＳ４４に進める。
〔Ｓ４４〕変数Ｓに未処理の要素型があるかどうかを検査する。未処理の要素型がなければ処理を終了する。未処理の要素型があれば処理をステップＳ４５に進める。
〔Ｓ４５〕変数Ｓ中の要素型を一つ選択し、処理をステップＳ４６に進める。
〔Ｓ４６〕選択した要素型の子供となる要素型の集合を求め、処理をステップＳ４７に進める。ある要素型の子供の要素型を得るためは、文書スキーマ中でその要素型の要素定義を特定し、その内容モデル中に子供として出現し得る要素型をすべて取り出せばよい。この処理は、既存の文字列処理言語を組み合わせることで容易に実現可能である。
〔Ｓ４７〕選択した要素型を起点にして、親から子を辿って到達できる要素型の集合を求め、処理をステップＳ４８に進める。
〔Ｓ４８〕選択中の要素型、ステップＳ４６で得られた要素型の集合、ステップＳ４７で得られた要素型の集合を３つ組として接続関係テーブル１３ｃの末尾に追加し、処理をステップＳ４４に進める。
【００９６】
図２６は選択要素型の到達可能要素特定処理の一例を示す流れ図である。
〔Ｓ５１〕変数Ｓを空集合とする。
〔Ｓ５２〕選択要素型の子供である要素型を変数Ｑに保持させる。
〔Ｓ５３〕変数Ｑの要素型数が０か否かを判定し、０の場合は処理を戻す。要素型数が１以上の場合は、変数Ｑの先頭要素型を取り出す。
〔Ｓ５４〕取り出した要素型が変数Ｓに含まれているかどうかを判定し、含まれている場合はステップＳ５３に処理を進める。含まれていない場合にはステップＳ５５に処理を進める。
〔Ｓ５５〕変数Ｓに取り出した要素型を加える。
〔Ｓ５６〕取り出した要素型の子供である要素型を変数Ｑの末尾に追加し、処理をステップＳ５３に進める。
【００９７】
上の処理の結果、生成される接続関係テーブルは以下のようになる。
図２７は接続関係テーブルの例を示す図である。図２７に示した接続関係テーブル１３ｃには、文書スキーマごとにある要素に対して子供として、および子孫として出現し得るすべての要素が記述されている。たとえば、接続関係テーブル１３ｃの中のｒｅｐｏｒｔというスキーマにおいて、最初の１行は、ｒｅｐｏｒｔという要素が子供に持ち得る要素はｆｒｏｎｔ，ｃｈａｐ，ｂａｃｋであり、ｒｅｐｏｒｔが子孫として持ち得る要素はｆｒｏｎｔ，ｃｈａｐ，ｂａｃｋ，．．．ｉｎｄｅｘであることを記述している。次の行は、ｆｒｏｎｔという要素に関する記述となる。なお、要素の中で、区切り子”：”しか持たない、たとえばｔｉｔｌｅという要素があるが、ここでの記述はｔｉｔｌｅ要素が子供にも子孫にも要素を持ち得ないことを意味している。
【００９８】
なお、接続関係テーブル１３ｃの作成処理は、文書利用者３０による検索指示が出される前に行われてもよいし、検索指示の後でスキーマ特定部１３にて接続関係テーブル１３ｃが参照される直前に行われても構わない。
【００９９】
また、スキーマ保持部１１および文書保持部１２に保持されている文書スキーマおよび文書や、スキーマ特定部１３に内部的に保持されているスキーマ共有関係テーブル１３ａは、第２の実施の形態の場合と同一であるので、説明を省略する。
【０１００】
本実施の形態における動作の流れは、図３で示した動作の流れと基本的には同一である。ただし、ステップＳ４の文書スキーマの特定処理において、本発明の文書データベース管理装置１０が個々の文書を検索する前に入力された問い合わせにヒットする文書が存在し得ないことを検知した場合には、文書利用者３０にその旨が示され、ステップＳ２に処理が戻される。この場合の処理の流れを以下に示す。
【０１０１】
図２８は第３の実施の形態での文書データベース管理装置の動作の一例を説明する流れ図である。以下の説明は、図２で示した構成要素がすべて用意されていることを前提とする。
〔Ｓ６１〕文書利用者３０に示される問い合わせエディタや、文書利用者３０の操作は第２の実施の形態と同一であるので説明を省略する。問い合わせエディタで選択される文書スキーマも第２の実施の形態と同じ文書スキーマ「ｓｅｃｔ」であるとする。
〔Ｓ６２〕ここで利用される問い合わせエディタも第２の実施の形態と同一であるが、文書利用者３０によって作成された問い合わせは第２の実施の形態における問い合わせとは異なる。問い合わせが作成された時点での問い合わせエディタを以下に示す。
【０１０２】
図２９は問い合わせが作成された時点での問い合わせエディタの表示例を示す図である。図２９の問い合わせエディタで表現されている問い合わせの表現方法は、図２３で示した表現方法と同一であるので説明を省略する。図２９の問い合わせ作成領域４３で表示されている問い合わせは、内容に文字列”異種”を含むｔｉｔｌｅ要素を子供に持つｓｅｃｔ要素を含む文書であって、このｔｉｔｌｅ要素は内容に文字列”混合”を含むｐａｒａ要素を子孫に持つような文書を対象としていることを表している。
〔Ｓ６３〕文書利用者３０によって文書データベース管理装置１０に検索指示が出され、ステップＳ６２で選択された文書スキーマがスキーマ特定部１３に入力される。文書利用者３０による検索指示は、問い合わせエディタ４０の下部にある”適用”ボタン４４を押下することでなされる。また、スキーマ特定部１３には、問い合わせエディタ４０で選択された「ｓｅｃｔ」が入力されることになる。
〔Ｓ６４〕スキーマ特定部１３が起動し、ステップＳ６２で作成された問い合わせとステップＳ６２で選択された文書スキーマとを入力とし、入力された文書スキーマの構文規則の集合が該文書スキーマの構文規則の部分集合であり（条件１）、問い合わせで用いられるすべての文書要素がフラグメントとなる文書スキーマで文書要素型として定められていて（条件２）、しかも、フラグメントとなる文書スキーマにおける文書要素型間の接続関係を組み合わせることにより問い合わせで用いられている文書要素間の接続条件が表現できること（条件３）、の３つの条件をすべて満足した、スキーマ保持部１１の中の文書スキーマが特定され、出力される。
〔Ｓ６５〕ステップＳ６４の判定において、条件２または条件３が満足されない場合には、問い合わせにヒットする文書は存在し得ないとしてステップＳ６２に戻り、問い合わせの作成をやり直す。また、条件２および条件３が満足された場合には、問い合わせにヒットする文書は存在し得るとしてステップＳ６６に進む。
〔Ｓ６６〕文書が存在し得る問い合わせで実際に文書の検索処理を行う。
〔Ｓ６７〕検索の結果得られた文書が文書ホルダ５０を通じて文書利用者３０に示される。
【０１０３】
次に、上記のステップＳ６４における文書スキーマの特定処理の詳細について以下に説明する。
図３０は第３の実施の形態におけるスキーマ特定部の処理の一例を示す流れ図である。
〔Ｓ７１〕条件２が満足されたか否かの判断を行う。
〔Ｓ７２〕ステップＳ７１で条件２が満足された場合は処理をステップＳ７３に進める。満足されなかった場合は処理を終了し、出力装置を介して問い合わせ中の要素型に関する条件に不備がある旨指摘する。
〔Ｓ７３〕条件３が満足されたか否かの判断を行う。
〔Ｓ７４〕ステップＳ７３で条件３が満足された場合は処理をステップＳ７５に進める。満足されなかった場合は処理を終了し、出力装置を介して問い合わせ中の要素型間の接続条件に不備がある旨指摘する。
〔Ｓ７５〕第２の実施の形態で示された図１４の一連の処理が行われ、得られた文書スキーマが出力されて処理が終了する。なお、ステップＳ７５の処理は、条件１を満足する文書スキーマを特定する処理に相当する。
【０１０４】
以上の一連の処理を行うことで、上に挙げた条件１、条件２、および条件３のすべてを満足する文書スキーマが特定され、出力されることになる。
次に、上記のステップＳ７１の条件２が満足されたかどうかを判断する処理の詳細を以下に示す。
【０１０５】
図３１は条件２判定処理の一例を示す流れ図である。以下の処理では、文書要素のキューを保持する変数Ｑが内部的に用いられる。
〔Ｓ８１〕問い合わせで用いられているすべての文書要素を変数Ｑに格納する。
〔Ｓ８２〕変数Ｑが空であるか否かが判定され、空の場合は条件２が満足されたという結果を返し、ステップＳ７１の処理を終了する。空でない場合はステップＳ８３へ処理を進める。
〔Ｓ８３〕変数Ｑの先頭要素を取り出す。
〔Ｓ８４〕取り出された要素が対応する文書スキーマの要素セットに含まれているか否かを判定する。含まれている場合は処理をステップＳ８２に進め、含まれていない場合は条件２が満足されなかったという結果を返し、ステップＳ７１の処理を終了する。
【０１０６】
次に、上記のステップＳ７３の条件３が満足されたかどうかを判断する処理の詳細を以下に示す。
図３２は条件３判定処理の一例を示す流れ図である。以下の処理では、２つの文書要素と接続関係とからなる３つ組のキューを保持する変数Ｑ'が内部的に用いられる。
〔Ｓ９１〕問い合わせで用いているすべての要素間接続関係を、第１要素（親または祖先）の要素名、第２要素（子供または子孫）の要素名、および関係（親子関係または祖孫関係）の３つ組で表現し、変数Ｑ'に格納する。
〔Ｓ９２〕変数Ｑ'が空であるか否かが判定され、空の場合は条件３が満足されたという結果を返し、ステップＳ７３の処理を終了する。空でない場合はステップＳ９３に処理を進める。
〔Ｓ９３〕変数Ｑ'の先頭の３つ組を取り出す。
〔Ｓ９４〕取り出された３つ組と対応する文書スキーマの接続関係テーブルのエントリとを照合し、処理をステップＳ９２に進める。
【０１０７】
次に、上記のステップＳ９４の照合処理の詳細を以下に示す。
図３３は３つ組と接続関係テーブルのエントリとの照合処理の一例を示す流れ図である。
〔Ｓ１０１〕３つ組の第１要素と同一の第１要素を持つエントリを接続関係テーブルから特定する。
〔Ｓ１０２〕３つ組の第３要素が親子関係である場合は処理をステップＳ１０３に進め、祖孫関係である場合は処理をステップＳ１０４に進める。
〔Ｓ１０３〕３つ組の第２要素がステップＳ１０１で特定されたエントリの第２要素に含まれるか否かが判断される。含まれていた場合にはステップＳ９４の処理を終了する。含まれていなかった場合は条件３が満足されなかったという結果を返し、ステップＳ７３の処理を終了する。
〔Ｓ１０４〕３つ組の第２要素がステップＳ１０１で特定されたエントリの第３要素に含まれるか否かが判断される。含まれていた場合にはステップＳ９４の処理を終了する。含まれていなかった場合は条件３が満足されなかったという結果を返し、ステップＳ７３の処理を終了する。
【０１０８】
上に示した処理を行うスキーマ特定部１３に、図２９で示した問い合わせおよび文書スキーマ「ｓｅｃｔ」が入力された場合の、スキーマ特定部１３の具体的な動きについて説明する。
【０１０９】
まず、図３０のステップＳ７１において、条件２が満足されるか否かが判断される。問い合わせに含まれる要素型はｓｅｃｔ、ｔｉｔｌｅ、ｐａｒａの３種類であり、ｓｅｃｔスキーマに対応する要素セットもｓｅｃｔ、ｔｉｔｌｅ、ｐａｒａの３つの要素型を保持するので、条件２は満足される。ステップＳ７２では、ステップＳ７３に処理が進められる。
【０１１０】
ステップＳ７３では、条件３が満足されるか否かが判断される。問い合わせに対応して図３２のステップＳ９１で作成され、変数Ｑ'に格納される３つ組は以下の２つである。
ｓｅｃｔ：ｔｉｔｌｅ：親子関係
ｔｉｔｌｅ：ｐａｒａ：祖孫関係
最初の３つ組を対象とした照合では、対応する接続関係テーブルのエントリとして、『ｓｅｃｔ：ｔｉｔｌｅ、ｓｅｃｔ、ｐａｒａ：ｔｉｔｌｅ、ｓｅｃｔ、ｐａｒａ』が特定される。
【０１１１】
そして、図３３のステップＳ１０３では、３つ組の第２要素がエントリの第２要素に含まれるか否かが判定される。この場合、３つ組の第２要素（ｔｉｔｌｅ）はエントリの第２要素（ｔｉｔｌｅ、ｓｅｃｔ、ｐａｒａ）に含まれているので、次の３つ組を対象とした照合が行われる。
【０１１２】
二つ目の３つ組を対象とした照合では、対応する接続関係テーブルのエントリとして以下のものが特定される。
ｔｉｔｌｅ：：
そして、ステップＳ１０４では、３つ組の第２要素がエントリの第３要素に含まれるか否かが判定される。この場合、３つ組の第２要素（ｐａｒａ）はエントリの第３要素（空）に含まれないので、図３０のステップＳ７４でスキーマ特定部の処理が終了し、出力装置を介して問い合わせ中の要素型間の接続条件に不備がある旨が指摘される。
【０１１３】
図３４は接続条件エラー報告ウインドウの表示例を示す図である。文書利用者３０は、出力装置を介して表示される接続条件エラー報告ウインドウ６０を参照することで、図２８のステップＳ６２において作成した問い合わせの接続条件に不備があることを知る。
【０１１４】
問い合わせに不備があることを知った文書利用者３０が、問い合わせを図２３で示したものに修正し、再度検索指示を出したものとすると、この場合には、図３０のステップＳ７１において問い合わせの修正前と同様に条件２が満足すると判断され、処理がステップＳ７３に進められる。
【０１１５】
ステップＳ７３では、条件３が満足されるか否かが判断される。問い合わせに対応して図３２のステップＳ９１で作成され、変数Ｑ'に格納される３つ組は以下の２つである。
ｓｅｃｔ：ｔｉｔｌｅ：親子関係
ｓｅｃｔ：ｐａｒａ：祖孫関係
最初の３つ組を対象とした照合では、問い合わせ修正前と同様の結果が得られる。二つ目の３つ組を対象とした照合では、対応する接続関係テーブルのエントリとして、『ｓｅｃｔ：ｔｉｔｌｅ、ｓｅｃｔ、ｐａｒａ：ｔｉｔｌｅ、ｓｅｃｔ、ｐａｒａ』が特定される。
【０１１６】
そして、図３３のステップＳ１０４では、３つ組の第２要素がエントリの第３要素に含まれるか否かが判定される。この場合、３つ組の第２要素（ｐａｒａ）はエントリの第３要素（ｔｉｔｌｅ、ｓｅｃｔ、ｐａｒａ）に含まれるので、条件３は満足される。そして、処理は図３０のステップＳ７５に進み、結果的に第２の実施の形態にて示した結果とまったく同様の結果が文書利用者３０に示される。
【０１１７】
以上の一連の処理の結果、文書利用者３０は、文書を得る可能性のない問い合わせを誤って作成し、その問い合わせに基づく検索指示を出してしまっても、本発明の文書データベース管理装置１０が誤りを指摘するので、その指摘に基づいて問い合わせを修正できる。さらに、本発明の文書データベース管理装置１０は、実際に文書を検索する前に誤りを指摘できるので、文書利用者が誤りに気づくまでの時間を短縮でき、文書利用者による作業を効率化できる。また、計算機による無駄な検索処理を未然に防ぐことができる。
【０１１８】
なお、第２および第３の実施の形態では、文書の表現形式としてＳＧＭＬの参照具体構文で定められているものを採用したが、これにより本発明が限定されるものではない。文書保持部中の文書が文書要素と文書要素間の接続関係からなる構造化文書で、文書型を定義可能なものであれば、文書の表現形式によらず同様の文書データベース管理装置を構成することができる。
【０１１９】
また、上の各実施の形態では、文書スキーマのフラグメントは文書スキーマの外部ファイルとして実現されているものとした。一方、フラグメントが文書スキーマと同一ファイル上に実現されている状況も考えられる。この状況においても、スキーマ特定部がフラグメントとなる文書スキーマを特定できれば、上の各実施の形態で示した処理の流れとまったく同じ流れで同様の結果を得ることが可能である。
【０１２０】
さらに、上の各実施の形態では、スキーマ特定部に入力された文書スキーマをフラグメントとするスキーマ保持部中のすべての文書スキーマがスキーマ特定部で特定されていた。しかし、スキーマ特定部で特定された文書スキーマを文書利用者に示して選択させ、文書利用者に選択された文書スキーマをスキーマ特定部で特定される文書スキーマ群とするように構成することも可能である。
【０１２１】
【発明の効果】
以上説明したように本発明では、複数の文書スキーマで共有される構文規則に現われる要素に関する条件や要素間の接続関係に関する条件を満たす文書の検索を単一の問い合わせで実現し、かつ、検索条件を満たし得ない文書を検索対象から除外することで検索効率を向上できるという効果がある。
【図面の簡単な説明】
【図１】本発明の文書データベース管理装置の原理構成図である。
【図２】文書データベース管理装置の構成例を示すブロック図である。
【図３】文書データベース管理装置の動作の一例を説明する流れ図である。
【図４】スキーマ保持部における文書スキーマの一例を示す説明図である。
【図５】文書保持部における文書の一例を示す説明図（その１）である。
【図６】文書保持部における文書の一例を示す説明図（その２）である。
【図７】文書保持部における文書の一例を示す説明図（その３）である。
【図８】スキーマ共有関係テーブルの一例を示す説明図である。
【図９】スキーマ共有関係テーブル作成の処理の一例を説明する流れ図（その１）である。
【図１０】スキーマ共有関係テーブル作成の処理の一例を説明する流れ図（その２）である。
【図１１】スキーマ共有関係テーブル作成時の一時ファイルの内容例を示す図である。
【図１２】問い合わせエディタの一例を示す図である。
【図１３】問い合わせが作成された時点での問い合わせエディタの表示例を示す図である。
【図１４】スキーマ特定部の処理の一例を示す流れ図である。
【図１５】検索結果を表示する文書ホルダの表示例を示す図である。
【図１６】文書スキーマの一例の説明図である。
【図１７】第２の実施の形態における文書の一例を示す図（その１）である。
【図１８】第２の実施の形態における文書の一例を示す図（その２）である。
【図１９】第２の実施の形態における文書の一例を示す図（その３）である。
【図２０】第２の実施の形態における文書の一例を示す図（その４）である。
【図２１】第２の実施の形態におけるスキーマ共有関係テーブルの一例を示す説明図である。
【図２２】問い合わせエディタの表示例を示す図である。
【図２３】問い合わせが作成された時点での問い合わせエディタの表示例を示す図である。
【図２４】要素セットの保持内容を示す図である。
【図２５】接続関係テーブル作成の処理の一例を示す流れ図である。
【図２６】選択要素型の到達可能要素特定処理の一例を示す流れ図である。
【図２７】接続関係テーブルの例を示す図である。
【図２８】第３の実施の形態での文書データベース管理装置の動作の一例を説明する流れ図である。
【図２９】問い合わせが作成された時点での問い合わせエディタの表示例を示す図である。
【図３０】第３の実施の形態におけるスキーマ特定部の処理の一例を示す流れ図である。
【図３１】条件２判定処理の一例を示す流れ図である。
【図３２】条件３判定処理の一例を示す流れ図である。
【図３３】３つ組と接続関係テーブルのエントリとの照合処理の一例を示す流れ図である。
【図３４】接続条件エラー報告ウインドウの表示例を示す図である。
【符号の説明】
１ スキーマ保持手段
２ 文書保持手段
３ スキーマ特定手段
４ 文書検索制御手段
５ 文書検索手段
１０ 文書データベース管理装置
１１ スキーマ保持部
１２ 文書保持部
１３ スキーマ特定部
１３ａ スキーマ共有関係テーブル
１３ｂ 要素セット
１３ｃ 接続関係テーブル
１４ 文書検索制御部
１５ 文書検索部
２０ 入出力装置
３０ 文書利用者

Claims (6)

1. 電子文書を管理対象とする文書データベース管理装置において、
   文書の構文規則である文書スキーマを複数保持しているスキーマ保持手段と、
   前記スキーマ保持手段中の文書スキーマの構文規則を満たした複数の文書が検索対象として保持されている文書保持手段と、
   前記スキーマ保持手段に保持された文書スキーマを文書利用者に提示してひとつを選択させるとともに前記選択された文書スキーマに基づいて前記文書利用者に前記文書保持手段に格納された文書検索の問い合わせを作成させる問い合わせエディタと、
   前記選択された文書スキーマおよび前記スキーマ保持手段に保持されている文書スキーマ群を入力とし、前記選択された文書スキーマの構文規則を自らの構文規則の部分集合とする文書スキーマを前記文書スキーマ群から特定するスキーマ特定手段と、
   前記スキーマ特定手段にて特定された前記文書スキーマ群および前記問い合わせを入力とし、前記文書スキーマ群に対応する前記文書保持手段中の文書から前記問い合わせの条件を満足する文書を検索する文書検索手段と、
   を具備することを特徴とする文書データベース管理装置。
2. 前記スキーマ保持手段は、文書属性の型のみからなる文書スキーマを保持していることを特徴とする請求項１記載の文書データベース管理装置。
3. 前記スキーマ保持手段は、文書要素の型に関する規則と文書要素型の間の接続関係に関する規則とから構成される文書スキーマを保持していることを特徴とする請求項１記載の文書データベース管理装置。
4. 前記スキーマ特定手段は、前記スキーマ特定手段によって特定された文書スキーマ群の各々の文書スキーマのうち、入力された前記問い合わせの条件を満たし得る文書に対応する文書スキーマだけを前記文書検索手段に出力することを特徴とする請求項３記載の文書データベース管理装置。
5. 前記スキーマ特定手段は、入力された文書スキーマのうちその文書要素型間の接続関係を組み合わせることで前記問い合わせで用いられている文書要素間の接続関係を表現できる文書スキーマのみ、前記スキーマ特定手段で特定された文書スキーマ群を前記文書検索手段に出力することを特徴とする請求項４記載の文書データベース管理装置。
6. 電子文書を管理対象とする文書データベース管理方法において、
   問い合わせエディタがスキーマ保持部に保持された文書スキーマを文書利用者に提示してひとつを選択させるとともに前記選択された文書スキーマに基づいて前記文書利用者に問い合わせを作成させ、
   スキーマ特定部が前記文書利用者による検索指示により、前記文書利用者によって選択された前記文書スキーマからその文書スキーマをフラグメントとする前記スキーマ保持部中の文書スキーマを特定し、
   文書検索部が特定された前記文書スキーマと前記文書利用者によって作成された問い合わせとを基にして文書保持部の中の文書に対する検索を行い、
   出力部が検索によって得られた前記文書保持部の中の文書を出力する、
   ことを特徴とする文書データベース管理方法。

Images