(57)【特許請求の範囲】
【請求項１】
要素間のつながりを定義する構文規則によって取り得る構造が規定されている構造化文書を管理対象とし、この構造化文書を構成する要素に関する条件と、前記要素間の親子関係及び祖孫関係に関する条件とを用いた検索式により検索対象を指定する文書データベース管理装置において、
文書データベース管理装置内に格納されている構文規則と与えられた検索式を照合する検索式検証手段を備え、
前記検索式検証手段が、前記構文規則に基づいて、前記構造化文書を構成する要素のうち親となる出発要素と、前記出発要素の子として出現し得る隣接要素と、前記出発要素の子孫として出現し得る到達可能要素を一つの組とし、すべての出発要素についての前記の組を備えた対応表を生成する対応表生成手段と、前記与えられた検索式における出発要素と隣接要素と到達可能要素に基づき、前記与えられた検索式における前記出発要素について前記隣接要素と前記到達可能要素が出現し得るか否かを前記対応表を走査して検証し、前記検索式が妥当であるか否かを検証する手段とを備えていることを特徴とする文書データベース管理装置。
【請求項２】
検索式検証手段及び対応表生成手段を備え、要素間のつながりを定義する構文規則によって取り得る構造が規定されている構造化文書を管理対象とし、この構造化文書を構成する要素に関する条件と、前記要素間の親子関係及び祖孫関係に関する条件とを用いた検索式により検索対象を指定する文書データベース管理装置において、
前記検索式検証手段が、文書データベース管理装置内の前記構文規則に基づいて、前記構造化文書を構成する要素のうち親となる出発要素と、前記出発要素の子として出現し得る隣接要素と、前記出発要素の子孫として出現し得る到達可能要素を一つの組とし、すべての出発要素についての前記の組を備えた対応表を対応表生成手段により生成し、与えられた検索式における出発要素と隣接要素と到達可能要素に基づき、前記与えられた検索式における前記出発要素について前記隣接要素と前記到達可能要素が出現し得るか否かを前記対応表を走査して検証し、前記検索式が妥当であるか否かを検証することを特徴とする文書データベース管理方法。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、電子文書を管理対象とする文書データベース管理装置と文書データベース管理方法に関わる。
【０００２】
【従来の技術】
ワードプロセッサ等により作成された電子文書は、デジタルデータとして表現されるので、追加、削除、変更等の編集を容易に行なうことができ、文書作成効率を高めることができる。また、複数の電子文書を大容量の記憶装置に蓄積して文書データベース装置を構築することにより、キーワード検索等により目的とする文書を電子的に検索することができる。
【０００３】
従来の電子文書を管理対象とする文書データベース管理装置では、文書の検索を行なう場合には、ワードプロセッサ等で作られた文書データそのものを蓄積し、そのデータを使って検索を行なっていた。
【０００４】
一方、電子文書の作成や編集作業を容易に行なえるようにするために、電子文書を構造化することが行なわれている。文書の構造は、たとえば、文書を構成する章、見出し、段落などの要素と、その要素間の関係についての情報、たとえば、章は、下位構造として見出しと段落を持つなどについての情報により表される。
【０００５】
【発明が解決しようとする課題】
本発明が解決しようとする課題を、文書構造の国際規格であるＯＤＡ（Ｏｆｆｉｃｅ  Ｄｏｃｕｍｅｎｔ  Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＩＳＯ  ８６１３）とＳＧＭＬ（Ｓｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｚｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）（ＩＳＯ  ８８７９；  ＪＩＳ  Ｘ４１５１）を例にとって説明する。
【０００６】
先ず、本明細書で使用する用語について説明する。
【０００７】
「文書構造」という用語は、文書を表現する情報構造とする。たとえば、ＯＤＡが定める情報構造は文書構造である。ＳＧＭＬのサブセッティング（機能の制限）を行ない、使用する文字コードや図表などに用いる情報構造を定めたものも文書構造である。なお、ＳＧＭＬについては、たとえば、Ｍａｒｔｉｎ  Ｂｒｙａｎ著，「ＳＧＭＬ入門」，株式会社アスキー，１９９１年３月３１日発行を参照されたい。
【０００８】
「文書型」という用語は、文書のテンプレートを示すものとする。文書型は、そこから作られる文書がどのような論理構造をもち得るか、すなわち、論理構造中に現われるノードの種類、各ノードがもち得る属性、各ノードがもち得る下位構造を定める。ＯＤＡの共通論理構造（ｇｅｎｅｒｉｃ  ｌｏｇｉｃａｌ  ｓｔｒｕｃｔｕｒｅ）や、ＳＧＭＬをサブセッティングした文書アーキテクチャにおけるＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）は、文書型である。
【０００９】
次に、上述したような、構造化された文書を検索する場合の問題点について説明する。
【００１０】
構造化文書では、文書の内容は論理構造と呼ばれ、章、節、図などの複数の文書構成要素からなる木構造で表現される。論理構造の例を図１０に示す。
【００１１】
論理構造はまったく自由に作成してよいのではなく、上述した文書型と呼ばれる構文規則に沿って作成される。文書型の例を図１１に示す。矩形のノードは要素の型（要素型）を定義している。ノードのラベルは、要素型の名前を示している。同一の名前をもつノードの実体は同一の要素型である。したがって、図１１の「節」という名前の要素型は、再帰的に定義されていることになる。楕円で示したノードは要素のつながりを定義する。このノードを構築子と呼ぶ。ＳＥＱノードは、それにつながるノードのインスタンスがその順に生成されることを示している。ＲＥＰノードは、それにつながるノードのインスタンスが１回以上生成されることを示す。ＯＰＴノードは、それにつながるノードのインスタンスが、出現してもしなくてもよいことを示す。ＣＨＯノードは、それにつながるいずれか１つのノードのインスタンスが生成されることを示す。図１０の論理構造は、図１１の文書型の制約を満たしている。
【００１２】
構造化文書を管理対象とする文書データベース管理装置では、検索を記述するための問合せ言語を提供している。問合せ言語は、テキストで記述されるものもあるが、グラフィカルユーザインタフェースで記述されるものもある。グラフィカルユーザインターフェースで記述された検索式の例を図１２に示す。ノードの文字列は要素型を示している。ノードの傍に示した文字列は、そのノードがもつテキストがその文字列を含むことを示す。実線で示されたアークは、両端のノードが親子関係にあることを示す。破線で示されたアークは、両端のノードが祖孫関係（先祖と子孫の関係）にあることを示す。ひとつのノードから複数のアークが出ている場合、すべての条件を満すものが検索結果となる。つまり、連言として指定されたことになる。図１２の検索式は、「見出しに”文書”という文字列を含み、”データベース”という文字列を含む段落をもつ章」の検索を指定している。
【００１３】
検索式は、文書の要素に関する条件と、要素間の接続関係に関する条件を用いて指定される。図１２の例では、前者は要素型に関する条件、後者は祖孫関係を用いた条件である。
【００１４】
図１３は、上述したような検索を行なう従来のデータベース管理装置の模式図である。問合せエディタ１で作成された検索式は、検索式生成部２により、検索式評価部３で実行可能な形式の検索式に変換される。この検索式は、文書型管理部５に渡され指定された条件を満たす要素をもつ文書を検索する。なお、６はデータ辞書、７はデータベースである。上記検索式評価部３においては検索式が文法的に正しいかどうかの検査も行なわれ、文法的に正しくない場合には、その旨が操作者に通知されると共に処理が中止される。
【００１５】
図１３に示す従来の電子文書を管理対象とする文書データベース管理装置では、検索式が文法的に正しいかどうかの検査だけを行なっていた。このため、解が存在し得ない検索式を与えても、正しい検索式として扱われる。たとえば、図１４に示すような「段落に”データベース”という文字列を含み、その段落の下位に繋がった見出しに”文書”という文字列を含む」という検索式は、文法的には正しいが、これを満す要素をもつ文書は存在しない。即ち、図１１に示す文書例の構造の場合、段落の下位に見出しが存在することは有り得ない。
【００１６】
このような、妥当でない検索式を検索した結果は、条件を満すものが存在しないので、何も得られない。ユーザの視点からは、検索式が文法的にも意味論的にも正しいが、条件を満たすものがデータベースに存在しなかったのか、そもそも検索式が妥当でなかったかは容易には判断できず、検索式を構成する際のユーザの負担になっていた。また、条件を満す要素をもつ文書が存在し得ないにもかかわらず検索処理を行なうので、無意味にシステムの計算時間を浪費する結果となっていた。図１４に示す検索式の評価は、典型的には、見出しのインスタンスと段落のインスタンスをすべて走査し、その後、親子関係を満すものがあるかどうかを調べるが、そもそも図１４の条件を満すものは存在し得ないので、評価する必要はない。
【００１７】
そこで本発明は、検索式の妥当性を容易に判断できるようにすることを目的とする。また、本発明の他の目的は、妥当でない検索式に対しては検索を行なわないようにして計算時間の浪費を防止することである。
【００１８】
【課題を解決するための手段】
前記問題点を解決するため、本発明の文書データベース管理装置は、要素間のつながりを定義する構文規則によって取り得る構造が規定されている構造化文書を管理対象とし、この構造化文書を構成する要素に関する条件と、前記要素間の親子関係及び祖孫関係に関する条件とを用いた検索式により検索対象を指定する文書データベース管理装置において、文書データベース管理装置内に格納されている構文規則と与えられた検索式を照合する検索式検証手段を備え、前記検索式検証手段が、前記構文規則に基づいて、前記構造化文書を構成する要素のうち親となる出発要素と、前記出発要素の子として出現し得る隣接要素と、前記出発要素の子孫として出現し得る到達可能要素を一つの組とし、すべての出発要素についての前記の組を備えた対応表を生成する対応表生成手段と、前記与えられた検索式における出発要素と隣接要素と到達可能要素に基づき、前記与えられた検索式における前記出発要素について前記隣接要素と前記到達可能要素が出現し得るか否かを前記対応表を走査して検証し、前記検索式が妥当であるか否かを検証する手段とを備えていることを特徴とする。
【００１９】
また本発明の文書データベース管理方法は、検索式検証手段及び対応表生成手段を備え、要素間のつながりを定義する構文規則によって取り得る構造が規定されている構造化文書を管理対象とし、この構造化文書を構成する要素に関する条件と、前記要素間の親子関係及び祖孫関係に関する条件とを用いた検索式により検索対象を指定する文書データベース管理装置において、前記検索式検証手段が、文書データベース管理装置内の前記構文規則に基づいて、前記構造化文書を構成する要素のうち親となる出発要素と、前記出発要素の子として出現し得る隣接要素と、前記出発要素の子孫として出現し得る到達可能要素を一つの組とし、すべての出発要素についての前記の組を備えた対応表を対応表生成手段により生成し、与えられた検索式における出発要素と隣接要素と到達可能要素に基づき、前記与えられた検索式における前記出発要素について前記隣接要素と前記到達可能要素が出現し得るか否かを前記対応表を走査して検証し、前記検索式が妥当であるか否かを検証することを特徴とする。
【００２０】
【作用】
本発明によれば、構造化文書を検索するに際し、文書型と、検索式で指定された、親子関係および祖孫関係を用いた条件が照合され、検索式が妥当か否か判断される。
【００２１】
本発明においては、検索を実行する前に文書型が調べられ、構造化文書を構成する要素のうち親となる出発要素と、前記出発要素の子として出現し得る隣接要素と、前記出発要素の子孫として出現し得る到達可能要素を一つの組とし、すべての出発要素についての前記の組を備えた対応表が生成される。検索式が入力されるとこの検索式に基づいて前記対応表が走査され、検索式が対応表の条件を満足しているか否かが判別され、条件が満足されないときには、検索式が妥当でないと判断される。
【００２２】
【実施例】
図１は、本発明の文書データベース管理装置のブロック図である。問合せエディタ１は、検索条件を入力するためのもので図２に示すような問合せエディタ画面を使用して入力される。問合せエディタ１で作成された検索式は、検索式生成部２により、検索式評価部３で実行可能な形式の検索式に変換される。この検索式は、検索式検証部４に渡され、妥当か否か判定される。検索式検証部４における処理の詳細については後述する。妥当な検索式であれば検索式評価部３に渡され、指定された条件を満たす要素をもつ文書を検索する。なお、５は文書型管理部、６はデータ辞書、７はデータベースである。
【００２３】
検索式検証部４は、検証制御部８、対応表保持部９、対応表生成部１０、到達可能性判定部１１をもつ。
【００２４】
検証制御部８は、全体を統轄する要素で、対応表保持部９、対応表生成部１０、到達可能性判定部１１を適宜呼び出す。
【００２５】
対応表保持部９は、要素（出発要素）、出発要素の子として出現し得る要素（隣接要素集合）、および出発要素から到達可能な要素の集合（到達可能要素集合）の３つ組をエントリとする対応表を保持する。ここで、ある要素Ａからある要素Ｂに到達可能であるとは、要素Ａのインスタンスの下位（子孫）として要素Ｂが出現し得ることを言う。図１１の文書型から生成した対応表を図３に示す。たとえば、要素「記事」に対しては、下位要素として「節」が隣接しており、要素「記事」からは、要素「節」，「見出し」，「段落」の何れにも到達可能であることを示している。
【００２６】
対応表生成部１０は、指定された文書型について文書型の構造を参照して上記した対応表を生成する。
【００２７】
到達可能性判定部１１は、ソースとデスティネーションの２つの要素が与えられたとき、対応表保持部９に保持されている対応表（図３参照）を走査し、ソースを出発要素とするエントリの隣接要素集合または到達可能要素集合にデスティネーションが含まれるか検査する。デスティネーションが隣接要素集合に含まれるときには、デスティネーションはソースの子として出現し得る。デスティネーションが到達可能要素集合に含まれるときには、デスティネーションはソースの子孫として出現し得る。
【００２８】
図４〜図９に、検索式検証部４において実行される与えられた検索式を検証する処理のフローを示す。このフローに沿って、本実施例について説明する。
【００２９】
図４は、検索式の検証の全体のフローである。この処理の入力は、検索式生成部２で生成された検索式である。検証制御部８は、文書型管理部５を呼び出し、入力された検索式の検索対象となるスキーマ（文書型）の情報を取得する（ステップ６−１）。続いて、対応表生成部１０を呼び出し、そのスキーマの対応表を作成する（ステップ６−２）。
【００３０】
図５は、対応表の作成処理（図４のステップ６−２参照）のフローである。この処理は対応表生成部１０で行なわれる。入力は、スキーマの情報である。スキーマの情報は、図６に示すような有向グラフで表現される。まず、入力されたスキーマのルートを選択する（ステップ７−２）。次に、ルートから到達可能な要素型の集合を求める（ステップ７−３）。変数Ｓに、ルートから到達可能な要素型の集合にルートを加えて集合を保持させる（ステップ７−４）。なお、ステップ７−４における戻り値とは直前の処理により得られた結果を示す  次いで、変数Ｓに未処理のノードがあるか検査する（ステップ７−５）。未処理のノードがなければ終了である（ステップ７−１０）。未処理のノードがあれば、ノードをひとつ選択する（ステップ７−６）。選択したノードと隣接する要素型の集合を求める（ステップ７−７）。さらに、選択したノードから到達可能な要素型の集合を求める（ステップ７−８）。選択中のノード（要素型）、ステップ７−７で得られた隣接要素型集合、およびステップ７−８で得られた到達可能要素型集合を３つ組として対応表保持部９に渡し、対応表にエントリを登録する（ステップ７−９）。この後、ステップ７−５に戻る。
【００３１】
図７は、到達可能要素型集合を求める処理（図５のステップ７−３参照）のフローである。この処理も対応表生成部１０で行なわれる。この処理の入力は要素型で、出力は入力された要素型から到達可能な要素型の集合である。このフローでは、要素型の集合を保持する変数Ｓと、要素型のキューを保持する変数Ｑを用いる。変数Ｓの初期値は空集合である（ステップ８−２）。変数Ｑの初期値は、入力ノードに隣接するノードすべてからなるキューである（ステップ８−３）。まず、変数Ｑの長さが０かどうか判定する（ステップ８−４）。変数Ｑの長さが０であれば、入力された要素型から到達可能な要素の集合が変数Ｓに格納されているので、これを戻り値として制御を戻す（ステップ８−１０）。変数Ｑの長さが１以上であれば、変数Ｑの先頭要素を取り出す（ステップ８−１１）。取り出した要素が変数Ｓに含まれていれば、ステップ８−４に戻る。取り出した要素がＳに含まれていなければ、それが要素型かどうか検査する（ステップ８−７）。要素型であれば、Ｓにその要素型を加える（ステップ８−８）。取り出した要素に隣接するノードすべてを変数Ｑの末尾に追加し（ステップ８−９）、ステップ８−４に戻る。
【００３２】
図８は、隣接要素型集合を求める処理（図５のステップ７−７参照）のフローである。この処理も対応表生成部１０で行なわれる。この処理の入力は要素型で、出力は入力された要素型と隣接する要素型の集合である。到達可能要素型集合を求める処理と同様、このフローでも、要素型の集合を保持する変数Ｓと、要素型のキューを保持する変数Ｑを用いる。変数Ｓの初期値は空集合である（ステップ９−２）。変数Ｑの初期値は、入力ノードに隣接するノードすべてからなるキューである（ステップ９−３）。まず、変数Ｑの長さが０かどうか判定する（ステップ９−４）。変数Ｑの長さが０であれば、入力された要素型から到達可能な要素の集合が変数Ｓに格納されているので、これを戻り値として制御を戻す（ステップ９−８）。変数Ｑの長さが１以上であれば、変数Ｑの先頭要素を取り出す（ステップ９−５）。取り出した要素が要素型かどうか検査する（ステップ９−６）。要素型であれば、変数Ｓにその要素型を加え（ステップ９−７）、ステップ９−４に戻る。要素型でなければ、取り出した要素に隣接するノードすべてを変数Ｑの末尾に追加し（ステップ９−９）、ステップ９−４に戻る。
【００３３】
図９は、検索式のノードの検証処理（図４のステップ６−４参照）のフローである。この処理は、到達可能性判定部１１で行なわれる。この処理の入力は検索式のノード、出力はそのノードが妥当か否かを示す真理値である。まず、対応表保持部９に保持されている対応表を走査し、入力されたノードを出発要素型とするエントリを求めておく（ステップ１０−２）。次に、未処理の隣接ノードがあるかどうか検査する（ステップ１０−３）。すべて処理が済んでいれば戻り値を真とし、制御を戻す（ステップ１０−１２）。未処理の隣接ノードがあれば、ノードをひとつ選ぶ（ステップ１０−４）。選択したノードが、入力されたノードの子として指定されているかどうか判定する（ステップ１０−５）。子として指定されていれば、選択したノードが、エントリの隣接要素型集合に含まれるかどうか検査する（ステップ１０−７）。含まれていなければ、戻り値を偽として制御を戻す（ステップ１０−７）。含まれていれば、選択したノードを検証する（ステップ１０−８）。ステップ１０−５で、選択したノードが子として指定されていなければ、つまり子孫として指定されていれば、選択したノードが、エントリの到達可能要素型集合に含まれるかどうか検査する（ステップ１０−１１）。含まれていなければ、戻り値を偽として制御を戻す（ステップ１０−１３）。含まれていれば、ステップ１０−８に行く。ステップ１０−８での検証結果が偽であれば、戻り値を偽として制御を戻す（ステップ１０−１０）。真であれば、ステップ１０−３に戻る。
【００３４】
本実施例では、検索式の検証を行なう度に対応表を構成しているが、文書型をデータベースに登録する時点で対応表を構成し、検証時はその表を走査するようにしてもよい。
【００３５】
【発明の効果】
以上のように、本発明によれば、文書型と、検索式で指定された、親子関係および祖孫関係を用いた条件が照合され、妥当か否か判断される。
【００３６】
これにより、検索式の意味的な誤りにより検索結果が得られなかったのか、条件に該当するインスタンスがなかったのかを判別するのが容易になる。また、システムが、検索結果があり得ない検索式を評価しなくて済むようになり、計算時間の浪費を防ぐことができる。
【図面の簡単な説明】
【図１】本発明の文書データベース管理装置の実施例の構成である。
【図２】問合せエディタのグラフィカルユーザインターフェースの例である。
【図３】対応表の例である。これは図１２に示した文書型の対応表である。
【図４】検索式の検証のフローである。
【図５】対応表の作成処理のフローである。
【図６】図１１の文書型を有向グラフで表現したものである。
【図７】ある要素型から到達可能な要素型の集合を求める処理のフローである。
【図８】ある要素型に隣接する要素型の集合を求める処理のフローである。
【図９】検索式のノードの検証処理のフローである。
【図１０】文書インスタンスの例である。
【図１１】文書型の例である。これは図１０の文書インスタンスの文書型である。
【図１２】検索対象の指定の例である。
【図１３】従来の文書データベース管理装置の構成である。
【図１４】妥当でない検索式の例である。この検索式で用いている文書型は図１１のものである。
【符号の説明】
１…問い合わせエディタ、２…検索式生成部、３…検索式評価部、４…検索式検証部、５…文書型管理部、６…データ辞書、７…データベース、８…検証制御部、９…対応表保持部、１０…対応表生成部、１１…到達可能性判定部
【図１】
0003568062.tif 000002
【図２】
0003568062.tif 000003
【図３】
0003568062.tif 000004
【図４】
0003568062.tif 000005
【図５】
0003568062.tif 000006
【図６】
0003568062.tif 000007
【図７】
0003568062.tif 000008
【図８】
0003568062.tif 000009
【図９】
0003568062.tif 000010
【図１０】
0003568062.tif 000011
【図１１】
0003568062.tif 000012
【図１２】
0003568062.tif 000013
【図１３】
0003568062.tif 000014
【図１４】
0003568062.tif 000015