JP3724878B2 - キーワード抽出ルール生成方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、文字認識装置やワードプロセッサ等の手段によって入力された、文書の構造を明示的に表す情報を含まない文書（以下「非構造化文書」と呼ぶ）を、文書の構造を明示的に表す情報を含む構造化文書に変換する際に用いるキーワード抽出ルールを生成する方法に関するものである。
【０００２】
【従来の技術】
構造化文書の形式の一つに、論理構造を明示的に表す情報をテキスト中に埋め込む方法がある。一般にユーザが作成した構造化文書（以下「文書インスタンス」と呼ぶ）は、文書の論理構造を規定する論理構造定義を記述したファイルを指定する部分と、文書の内容を表す内容テキスト部からなることが多い。
論理構造定義には、その文書の論理構造と、その構成要素を表すマーク（以下、「タグ」と呼ぶ）が定義される。
また、内容テキスト部には、論理構造定義内で定義されたタグを、そのタグに対応する論理構造の内容となる文字列が一意に定まるように挿入し、文書の論理構造を明示的に表現する。
【０００３】
このようにして構造化された文書インスタンスを出力する際には、論理構造の各構成要素（以下「エレメント」と呼ぶ）をどのような書式で出力するかを規定する出力書式定義を記述したファイル参照し、出力すべきイメージを生成する。
この方法によると、文書インスタンスと出力書式定義とが独立しているために、出力に用いる個々の装置やシステムに関わらず文書インスタンスを交換することができる。
【０００４】
また、こうした構造化文書における文字列の内容は、例えば「＜著者名＞」や「＜タイトル＞」というような、エレメントと一対一に対応するタグの挿入によって明示的に表現されてるため、構造化文書に対応した全文検索システム等のツールと組み合わせることにより、文書インスタンスの集合をそのままデータベースとして利用することができる。構造化文書とその利用については、文献「ＳＧＭＬのススメ」（吉岡誠編著、オーム社）等において詳しく解説されている。
【０００５】
こうした利点から、大量の文書を蓄積，利用する文書処理システムにおける文書管理形式として、構造化文書形式の採用が進んでいる。
それと共に、既存の紙面文書やワープロ入力文書などの非構造化文書を構造化文書へと変換する手法について検討が行なわれている。
【０００６】
非構造化文書の構造化文書への変換に関する従来の技術としては、特開昭６２−２４９７０や、「文書画像のＯＤＡ論理構造化文書への変換方式（電子情報通信学会論文誌，Ｄ−ＩＩ，Ｖｏｌ．Ｊ７６−ＤＩＩ，Ｎｏ．１１，ｐｐ．２２７４−２２８４）」に見られる方法がある。
これは、非構造化文書から「第１章」や「１．１」等の論理構造を表現する特徴的な文字列（以下「キーワード」と呼ぶ）を抽出し、抽出したキーワードを手がかりとして文書の論理構造を認識することにより、構造化文書を生成するものである。
【０００７】
しかし、従来の技術においては、キーワードを抽出するためのルールの作成を支援するという観点が存在せず、その手段については未だ発表されていない。
そのため、キーワードとすべきエレメントの決定およびキーワードの抽出に必要なレイアウトや文字列に関する条件の設定を、全て人手によって行なう必要がある。
【０００８】
【発明が解決しようとする課題】
従来の方法の問題点として、
（１）キーワードとして抽出するエレメント（以下「キーワード対応要素」と呼ぶ）の決定を支援する手段がないことである。
文字列を内容とするエレメントを全てキーワードとして抽出するわけではない。
特にレイアウトや文字列に特徴のないエレメントについては、キーワードとして抽出せず、キーワードの間に挟まれる文字列、すなわち非キーワードとして扱う。
【０００９】
どのエレメントをキーワード対応要素とするかを決定する際には、「文書インスタンス中で非キーワードが隣接してはならない」という拘束条件が課せられる。
これは、非キーワードは「キーワードの間に挟まれる文字列」であることから、非キーワードは必ずキーワードと隣接する必要があるためである。
しかし、従来の方法には、キーワード対応要素と設定したエレメントの集合が、この拘束条件を満たすか否かを自動的に検定する手段が存在しない。
そのため、設定したキーワード対応要素の集合がこの拘束条件を満たさない場合、論理構造認識のためのルール作成時または論理構造認識時に不都合が生じ、その結果、再びキーワード対応要素を設定し直す必要がでてくる。そして、このサイクルを適切なキーワード対応要素の集合が設定されるまで繰り返す必要がある。
【００１０】
（２）キーワードの抽出に必要なレイアウトや文字列に関する条件の設定を支援する方法が存在しないことである。
そのため、キーワードの抽出に必要な情報は、対象とする非構造化文書そのものや、非構造化文書の記述様式を定めた規則集等から人手で抽出する必要があり、これには多大な労力を要する。
【００１１】
本発明の目的は、上記問題点を解決し、非構造化文書から構造化文書を生成する際に、非構造化文書からキーワードを抽出するためのキーワード抽出ルール生成方法を提供することにある。
【００１２】
【課題を解決するための手段】
上記目的を達成するため、本発明は、
文書の論理構造の構成要素を表わす特徴的な文字列すなわちキーワードを非構造化文書から抽出するためのルールであり、非構造化文書から構造化文書を生成する際に用いられるキーワード抽出ルールを生成するためのキーワード抽出ルール生成方法であり、
対象とする文書に与えられた論理構造定義から論理構造情報を抽出し文字列対応要素情報を生成する文字列対応要素情報生成ステップと、前記対象とする文書に与えられた出力書式定義から出力書式情報を抽出し出力書式情報を生成する出力書式情報生成ステップと、前記生成した文字列対応要素情報と出力書式情報に基づきキーワード抽出ルールを生成するキーワード抽出ルール生成ステップからなるようにしている。
【００１３】
さらに、前記文字列対応要素情報生成ステップは、文字列対応要素情報として文字列対応要素と該文字列対応要素に後接しうる文字列対応要素とを対として生成し、前記出力書式情報生成ステップは、出力書式情報として文書の論理構造の構成要素を出力する際のレイアウトと文字列に関する情報抽出するようにしている。
【００１４】
さらに、前記キーワード抽出ルール生成ステップは、前記出力書式情報をキーワード抽出に必要な項目毎にユーザに対して表示し、ユーザの入力に従い、非構造化文書上の出力様式に沿うように前記出力書式情報を修正し、かつ欠如している情報を前記出力書式情報に補うようにしている。
【００１５】
さらに、前記キーワード抽出ルール生成ステップは、前記出力書式情報から前記論理構造の構成要素のどれをキーワードとして抽出するかをユーザが決定するとき、前記文字列対応要素情報に基づき抽出すべき前記論理構造の構成要素を指示、表示してユーザの決定を支援するようにしている。
【００１６】
【発明の実施の形態】
図面を参照して本発明の一実施例を説明する。
本実施例においては、構造化文書形式の一例としてＳＧＭＬ（Ｓｔａｎｄａ−ｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式を採用し、論理構造定義としては、対象とする文書に対して設定されたＳＧＭＬの文書型定義であるＤＴＤ（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ）を用いる。
ＳＧＭＬ及びＤＴＤの処理内容や記述規則は、ＩＳＯ（国際標準化機構）の標準規約であるＩＳＯ８８７９において規定されており、その詳細は文献「ＳＧＭＬ入門」（Ｍａｒｔｉｎ Ｂｒｙａｎ著、アスキー出版局）において解説されている。
【００１７】
本実施例は、図１に示す「キーワード抽出ルール生成方法」に関するものであるが、まず構造化文書生成方法の流れについて説明し、本発明の位置付けを具体的な例を示しながら述べる。
【００１８】
図２は、構造化文書生成方法の流れを示すブロック図である。この流れ自体は、特願平７−２２３０１７や特開昭６２−２４９７０、あるいは「文書画像のＯＤＡ論理構造化文書への変換方式（電子情報通信学会論文誌，Ｄ−ＩＩ，Ｖｏｌ．Ｊ７６−ＤＩＩ，Ｎｏ．１１，ｐｐ．２２７４−２２８４）」といった従来技術で共通して採用されている。
【００１９】
２０１は、文字認識装置やワードプロセッサ等の手段によって入力された、文書の構造を明示的に表す情報を含まない文書、すなわち非構造化文書である。
非構造化文書の例を図３に示す。これは、法規を例に紙面文書に対して文字認識を行なった結果であり、論理構造を示す明示的な表記は存在しないが、文書の各構成要素はスペース等を用いて読み易いようにレイアウトされている。
【００２０】
このようなテキスト形式の電子化文書を文書処理システムで活用するために、論理構造定義（図２の２０７）が設定されている。
図３の非構造化文書に対応する論理構造定義（ＤＴＤ）の例を図４に示す。
冒頭の４０１は、この論理構造定義が「条例」という名称であることを示す。４０２〜４１５はエレメントの定義であり、「！ＥＬＥＭＥＮＴ」の次にエレメントの名称が記述され、その後に「（」と「）」で挟む形式で、そのエレメントを構成する要素の集まりであるモデルグループが記述される。
例えば、モデルグループは、（公布年月日，例規番号，公布文？）、（＃ＰＣＤＡＴＡ）等であり、題名は「＃ＰＣＤＡＴＡ」をモデルグループの要素とするエレメントであり、条例は「題名」，「公布」，「本則」をモデルグループのそれぞれの要素とするエレメントである。
モデルグループは、一個以上のエレメントや、「＃ＰＣＤＡＴＡ」などデータを表す内容トークンを要素とする集合であり、入れ子状にモデルグループ自身を要素とすることもできる。
【００２１】
４０２は、エレメント「条例」が、「題名」「公布」「本則」といったエレメントの並びによって構成されることを示す。
また、４０９は、エレメント「条」が「見出し？」「条番号」「条規定」「号＊」といったエレメントの並びによって構成されることを示す。
アスタリスク（”＊”）の付いた要素は、その要素が０回以上複数回出現可能であることを意味し、クエスチョン（”？”）の付いた要素は、その要素が存在してもしなくてもよいことを意味する。例えば、４０９は、「見出し」が存在しなくてもよく、また「号」が０回以上複数回出現可能であることを表現している。
モデルグループの内容が（＃ＰＣＤＡＴＡ）である４０３、４０５〜４０７等は、それぞれ「題名」「公布年月日」「例規番号」「公布文」といったエレメントが、そのモデルグループの内容を表す文字列を保持することを意味する。
【００２２】
４０１から４１６までの論理構造をツリー状に表現したものを図５に示す。
図５では、図４の４０２〜４１５に定義された各エレメントをそれぞれノードとして表現しており、上位のノードに対応するエレメントが、下位のノードに対応するエレメントから構成されていることを示している。「＃ＰＣＤＡＴＡ」を下位にもつノードは、対応するエレメントがモデルグループとして文字列を保持すること意味している。
【００２３】
図３の非構造化文書の内容を、図４の論理構造定義に従って構造化した構造化文書を図６に示す。
図４の中で定義されたエレメント（例えば４０４の「公布」）の内容は、図６の構造化文書中において、その要素の始まりを表す記号（ここでは６０１の＜公布＞）と終りを表す記号（ここでは６０２の＜／公布＞）に挟まれる記号と文字列によって表現されている。
このような構造化文書を、図３に示すような非構造化文書から生成することが、図２に示した構造化文書生成処理の目的である。
【００２４】
図２の構造化文書生成処理は、大きく二つに分けられる。一つは２０２のキーワード抽出処理であり、もう一つは２０４の論理構造認識処理である。
キーワード抽出処理２０２は、キーワード抽出ルール２０３を参照して、非構造化文書の中から「第１条」や「２．１．１」のような、論理構造を表す特徴的な文字列であるキーワードを抽出する処理である。
論理構造認識処理２０４は、論理構造認識ルール２０５を参照して、キーワード抽出処理２０２で抽出されたキーワードを手がかりとして論理構造認識を行ない、図５に示したようなツリー状の論理構造を文書に割り当てることにより、図６のような構造化文書２０６を生成する処理である。
【００２５】
以下、キーワード抽出処理２０２について詳細に説明する。
キーワード抽出ルール２０３の例を図７に示す。
キーワード抽出ルールは、キーワードとして抽出すべきエレメント名と、それを抽出するためのレイアウト及び文字列に関する条件である書式条件とを組合せたルールの集合である。
図７における書式条件の記述要素の説明を図８に示す。
図７においては、各行の先頭の項目がキーワードの名称であり、二番目以降の項目が書式条件である。
図７における７０１は、キーワード「題名」の書式条件が、「センタリングされている行であり、最初に文字『○』が存在し、それに任意長の文字列が続き、最後に文字列『条例』または文字列『規則』で行が終る。」という条件であることを意味する。
また、７０２については、キーワード「公布年月日」の書式条件が、「行頭から任意個のスペースを置いて文字列『大正』または文字列『昭和』が存在し、その後は順に整数，『年』，整数，『月』，整数，『日』と続き、行が終る」という条件であることを意味する。
【００２６】
図２のキーワード抽出処理２０２では、キーワード抽出ルールの書式条件に適合する文字列が非構造化文書中に存在するか否かを判定し、適合する場合にはその文字列をキーワードとして抽出する。図３の非構造化文書キーワードの抽出例を図９に示す。
図２の論理構造認識処理２０４では、抽出されたキーワードを手がかりにして論理構造認識を行なうことにより構造化文書を生成するが、この処理の詳細については、特願平７−２２３０１７や特開昭６２−２４９７０、あるいは「文書画像のＯＤＡ論理構造化文書への変換方式（電子情報通信学会論文誌，Ｄ−ＩＩ，Ｖｏｌ．Ｊ７６−ＤＩＩ，Ｎｏ．１１，ｐｐ．２２７４−２２８４）」に開示されている。
【００２７】
本実施例で詳述するキーワード抽出ルール生成方法は、図２のキーワード抽出ルール２０３の作成を支援するものである。
キーワード抽出ルールは、従来全て人手で生成していたが、本システムは、与えられた論理構造定義と出力書式定義とを用いて、キーワード抽出ルールの作成支援を行なう。
【００２８】
図１は、キーワード抽出ルール生成方法の構成を示すブロック図である。まず、図１を用いて本システムの処理概要を説明する。
１０１は、対象文書に対して設定された論理構造定義であり、構造化文書中に現われるエレメントと、エレメント間の関係とが定義されている。
論理構造情報抽出部１０２では、論理構造定義１０１を参照して、文字列に直接対応する論理構造要素であるエレメント（以下「文字列対応要素」と呼ぶ）と、それらの間の隣接情報とを記述した文字列対応要素情報１０３を生成する。
上記の文字列対応要素は、図５における「＃ＰＣＤＡＴＡ」を下位に持つノードのエレメントであり、題名、公布年月日、例規番号、・・・、号番号、号規定がこれにあたり、図４の場合には、４０３、４０５、４０６、４０７、４１０、４１１、４１２、４１４、４１５のエレメントがこれにあたる。
１０４は、対象文書に対して設定された出力書式定義であり、各エレメントをどのような書式で出力するのかが定義されている。
出力書式情報抽出部１０５では、出力書式定義１０４を参照して、各エレメントの出力時のレイアウトや出力文字列に関する情報の中から、キーワード抽出ルールの作成に必要な項目を可能な限り抽出する。
以下、この項目自体を「要件項目」と呼び、各項目について抽出された情報を「要件項目内容」と呼ぶ。出力書式情報１０６は、各文字列対応要素についての要件項目内容を記述したものである。
【００２９】
キーワード抽出ルール作成部１０７では、各文字列対応要素に関する出力書式情報１０６内の要件項目内容を、入出力装置１１２を通じてユーザに提示する。そして、ユーザが入力する情報を受理して要件項目内容の修正を行ない、修正後の要件項目内容を基にキーワード抽出ルール１１３を生成する。
【００３０】
キーワード抽出ルール作成部１０７における処理をより具体的に述べる。
キーワード情報表示部１０８では、文字列対応要素情報１０３に記述された文字列対応要素の名称をユーザに対して表示する。
ある文字列対応要素がキーワード対応要素として設定され、書式条件が付与されている場合には、その書式条件を、文字列対応要素の名称に併せて表示する。
各文字列対応要素に対する書式条件の設定は、補完情報入力部１０９において行なう。補完情報入力部１０９では、出力書式情報１０６を参照して、ユーザの選択した文字列対応要素についての要件項目内容を表示する。
ユーザは、表示された要件項目内容が、非構造化文書上のレイアウト及び文字列と異る場合にはこれを修正する。また、出力書式情報抽出部１０５で抽出できなかった要件項目について内容を付与する。
このようにして、全ての要件項目内容が、非構造化文書上のレイアウトおよび文字列に適合した内容になるように、要件項目内容の編集を行なう。
１１０は、要件項目内容の一つである文字列条件をユーザが編集する際に、その編集を支援する文字列条件入力部である。
補完情報入力部１０９では、全ての要件項目の編集が終了すると、その要件項目内容からキーワード抽出に用いる書式条件を生成する。そして、書式条件を返り値として処理をキーワード表示部に戻す。
キーワード情報表示部１０８では、補完情報入力部１０９において書式条件を生成した文字列対応要素をキーワード対応要素として設定し、その要素名に併せて書式条件を表示する。
【００３１】
以上の手続きによってキーワード対応要素を定めていくが、ある時点において定められたキーワード対応要素の集合が、「非キーワードが隣接してはならない」という拘束条件を満たすか否かを、要素隣接検定部１１１によって検定する。
要素隣接検定部１１１は、文字列対応要素情報１０３に記述された文字列対応要素間の隣接情報を参照して、キーワード対応要素以外の文字列対応要素（以下「非キーワード対応要素」と呼ぶ）が隣接するか否かを検定する。
非キーワード対応要素同士が隣接しうる場合には、そのどちらかに対して書式条件の生成を行ない、キーワード対応要素として設定する。 逆に、非キーワード対応要素同士が隣接する可能性のない場合には、その時点で十分なキーワード対応要素が設定できていることになる。このとき、各キーワード対応要素の名称と書式条件との組み合わせの集合を、キーワード抽出ルール１１３とする。
以上が、キーワード抽出ルール生成方法の処理概要である。以下、図１における各処理の詳細な説明を行なう。
【００３２】
論理構造情報抽出部１０２では、図４および図５に具体例を示したような論理構造定義１０１を参照して、文字列対応要素と、文字列対応要素間の隣接可能性についての情報を抽出し、文字列対応要素情報１０３として出力する。
文字列対応要素とは、論理構造定義において、文字列を意味する（＃ＰＣＤＡＴＡ）をモデルグループの要素とするエレメントのことである。
図４の論理構造定義における文字列対応要素を図１０に示す。図１０の例では、エレメント「題名」「公布年月日」「例規番号」「公布文」「見出し」「条番号」「条規定」「号番号」「号規定」が文字列対応要素として抽出される。
【００３３】
論理構造情報抽出部１０２では、文字列対応要素間での隣接の可能性を調べる。具体的には、以下の二つの処理を行なう。
１．各エレメント毎に、その冒頭及び末尾に現われうる文字列対応要素の集合を求める。
例えば図６の構造化文書において、エレメント「公布」の冒頭に文字列対応要素「公布年月日」が現われており、またエレメント「公布」の末尾には文字列対応要素「公布文」が現われている。
ここでの処理は、このようなエレメントの冒頭及び末尾に現われうる要素を、 図４に示すような論理構造定義から導くものである。
２．論理構造定義のモデルグループ内で隣接するエレメントの組み合わせを求める。
各組み合わせについて、前側のエレメントの最後に現われうる文字列対応要素と、後ろ側のエレメントの最初に現われうる文字列対応要素とが、隣接する可能性を有することになる。
【００３４】
本実施例においては、この二つの処理を容易にするための準備として、図４に示した論理構造定義をＢＮＦ（Ｂｕｃｋｕｓ Ｎａｕｒ Ｆｏｒｍ）記法を用いた表現に変換する。
ＢＮＦは「生成規則」と呼ばれるルールの集合である。各生成規則は「Ａ ：Ｂ Ｃ」というようにコロン’：’によって区切られた左辺と右辺から成り、左辺の要素が、右辺に記述された要素の並びによって成り立つことを意味する。「Ａ ： ＢＣ」という生成規則の例では、要素Ａが、「Ｂ Ｃ」という要素の並びによって構成されることを意味する。
また、記号’｜’は並列を表す記号であり、例えば「Ａ ： Ｂ ｜ Ｃ」という生成規則は、要素Ａが要素Ｂまたは要素Ｃから成り立つことを意味する。
ＢＮＦの詳細については、文献「ｙａｃｃとｌｅｘの使い方」（斉藤 孝著、ＨＢＪ出版局）等において解説されている。
【００３５】
図１１に、図４に示した論理構造定義（ＤＴＤ）をＢＮＦ記法を用いて表現する際の変換規則を示し、図１２にＢＮＦ記法で表現した論理構造定義の例を示す。
例えば、図４における４０４の定義は、図１２の１２０３および１２０４に示した生成規則に変換される。
ここでは、図４の「公布文」が、図１１の変換規則１１０１によって、図１２の１２０３の「ｏｐｔ０」に置き換えられている。そして、「ｏｐｔ０」の定義が１２０４に記述されている。
以下、本実施例においては、ＢＮＦ記法によって表現した論理構造定義の各生成規則における右辺を、左辺のエレメントの「内容モデル」と呼ぶことにする。
【００３６】
ＢＮＦ記法によって表現した論理構造定義から、各エレメント毎にその冒頭と末尾に現われうる文字列対応要素の集合を求める手続きについて説明する。
この手続きのアルゴリズムを図１３に示す。
図１３においてＡから始まる手続きは、エレメントを入力引数とし、そのエレメントの冒頭に現われうる文字列対応要素の集合を返り値とする手続きであり、再帰呼び出しを含む。
ここで、この手続き内で用いられている変数ｍｇ及びｅｌｅｍは、Ａに手続きが進むごとに新たに生成される局所的な変数である。
また、Ｆｉｒｓｔ［××］は、エレメント××の冒頭に現われうる文字列対応要素の集合を表す大域的な変数である。
【００３７】
あるエレメントの冒頭に現われうる文字列対応要素の集合を求めるには、そのエレメントを引数（図１３中のｎｔ）として手続きＡを実行する。
手続きＡでは、まずｎｔの冒頭に現われうる文字列対応要素の集合を表すＦｉｒｓｔ［ｎｔ］を空集合にセットする（１３０１）。
また、ｎｔの内容モデルにおいて、並列記号’｜’で区切られたエレメント列のうち、最初のエレメント列を変数ｍｇに代入する（１３０２）。
並列記号が存在しない場合は、内容モデル全体をｍｇとする。そして、変数ｅｌｅｍに、ｍｇの最初のエレメントを代入する（１３０３）。
次に、１３０４において、ｅｌｅｍが文字列対応要素であるか否かを調べる。
ｅｌｅｍが文字列対応要素である場合には、Ｆｉｒｓｔ［ｎｔ］にｅｌｅｍを加え（１３０５）、１３０９に進む。
逆にｅｌｅｍが文字列対応要素でない場合には、Ｆｉｒｓｔ［ｅｌｅｍ］が設定されていれば（１３０６）Ｆｉｒｓｔ［ｅｌｅｍ］の内容をＦｉｒｓｔ［ｎｔ］に加え（１３０８）、１３０９に進む。
また、１３０６においてＦｉｒｓｔ［ｅｌｅｍ］が設定されていない場合には、ｅｌｅｍを引数として、手続きＡを再帰的に実行する（１３０７）。そして、その返り値すなわちＦｉｒｓｔ［ｅｌｅｍ］の内容をＦｉｒｓｔ［ｎｔ］に加え（１３０８）、１３０９に進む。
１３０９では、ｎｔの内容モデルにおいてｍｇが並列記号で区切られた最後のエレメント列であるか否かを調べる。
ｍｇが最後のエレメント列でない場合には、変数ｍｇに次のエレメント列を代入し（１３１０）、１３０３に戻る。逆にｍｇが最後のエレメント列である場合には、Ｆｉｒｓｔ［ｎｔ］を返り値として、この手続きを呼び出した手続きに処理を戻す（１３１１）。
【００３８】
以上、図１３に示した手続きを、全てのエレメントについてＦｉｒｓｔ［］が設定されるまで実施することにより、各エレメントについて、冒頭に現われうる文字列対応要素の集合を求めることができる。
また、末尾に現われうる文字列対応要素の集合Ｌａｓｔ［］を求めるには、図１３に対して以下の２つの置換を行なう事により、図１３と同様の手順で求めることが出来る。
ａ．図１３中のＦｉｒｓｔ［ＸＸＸ］をＬａｓｔ［ＸＸＸ］に置き換える。
ｂ．１３０３の「最初のエレメント」を「最後のエレメント」に置き換える。
【００３９】
図１４に、図４に示した論理構造定義中のエレメントについて、冒頭及び末尾に現われうる文字列対応要素の集合、すなわちＦｉｒｓｔ［］とＬａｓｔ［］とを求めた結果を示す。
以上の手続きにより、各エレメントについて冒頭に現われうる文字列対応要素の集合Ｆｉｒｓｔ［］と、末尾に現われうる文字列対応要素の集合Ｌａｓｔ［］を求めることができる。
【００４０】
次に、論理構造定義の内容モデル内で隣接するエレメントの組み合わせを求める。
各組み合わせについて、前側のエレメントのＬａｓｔ［］の要素と、後ろ側のエレメントのＦｉｒｓｔ［］の要素とが、隣接する可能性を有することになる。
この処理例を図１５に示す。本図は、図１２の１２０１の「条例 ： 題名 公布 本則」という生成規則についての処理例である。
この生成規則では、エレメント「条例」の内容モデルにおいて、題名と公布が隣接し、また公布と本則が隣接している（１５０１）。
そのため、Ｌａｓｔ［題名］の要素にＦｉｒｓｔ［公布］の要素が後接しうる（１５０２）。
すなわち、文字列対応要素「題名」には、文字列対応要素「公布年月日」が後接しうる（１５０４）。
また、Ｌａｓｔ［公布］の要素にＦｉｒｓｔ［本則］の要素が後接しうる（１５０３）。
すなわち、文字列対応要素「公布文」と「例規番号」には、どちらも文字列対応要素「見出し」及び「条番号」が後接しうる（１５０５）。
この手続きを、ＢＮＦ記法で表現した論理構造定義中の全ての生成規則に対して適用することにより、全ての文字列対応要素について後接しうる文字列対応要素の集合を求めることができ、これがすなわち文字列対応要素情報（図１の１０３）になる。
文字列対応要素情報１０３の例を図１６に示す。
以上、図１１〜図１５に示した手続きによって、図１の論理構造情報抽出部１０２において文字列対応要素情報１０３が生成される。
【００４１】
次に、図１の出力書式情報抽出部１０５において、出力書式定義１０４から出力書式情報１０６を抽出する処理について説明する。
１０４は、対象文書に対して設定された出力書式定義であり、各エレメントをどのような書式で出力するのかが定義されている。
図１７に、図４の論理構造定義に沿った構造化文書のために用意された出力書式定義の例の一部を示す。
１７０１は、１７０１〜１７１１がエレメント「題名」の出力書式に関する定義であることを示す。
［フォント種類］１７０２は、「題名」を出力する際のフォントの種類がゴシック体であることを示し、［フォントサイズ］１７０３は、そのフォントのサイズが１２ｐｔであることを示す。ｐｔ（ポイント）は長さの単位であり、１ｐｔ＝１／７２インチである。
［文字ピッチ］１７０４は、「題名」の文字ピッチが１４ｐｔであることを示す。１７０５の［オフセット１］と１７０６の［オフセット２］は、それぞれこの文書を出力する領域の左端および右端から、最低どれくらいのスペースを空けて「題名」の内容を出力するかを表すものである。
１７０７の［冒頭変位］は、他の行と比べて特殊なオフセットを取ることが多い第一行目の、［オフセット１］との差を表す。
１７０８の［前要素との接続］は、直前に現れる要素との間にどのような文字列を出力するかを表す。１７０８の例では、直前に現れる要素を出力した後、改行して「題名」を出力することを示している。
１７０９の［文字列情報］は、どのような文字列を出力するかを記述するものであり、１７０９の例では、題名に相当する文字列（ＣＯＮＴＥＮＴ）、つまり構造化文書においてタグ＜題名＞とタグ＜／題名＞に挟まれる文字列をそのまま出力することを意味している。
１７１０の［配置］は、［オフセット１］と［オフセット２］によって指定された区間内に、内容文字列をどのように配置するかを示すものである。左寄せ、右寄せ、センタリング、均等割り付けの４種類の割り付け方法に応じて、それぞれｓｔａｒｔ、ｅｎｄ、ｃｅｎｔｅｒ、ｊｕｓｔｉｆｙの４つの値をとる。１７１０の例では、「題名」の内容文字列をセンタリングして出力することを表している。
【００４２】
このような出力書式定義は、本来構造化文書を出力するためのものであり、非構造化文書の書式を表現するためのものではない。
しかし、例えば法規文書のように記述様式に規則性のある文書については、出力書式定義がその規則に即して定義されていることが多い。
このような文書については、出力書式定義中のレイアウトや文字列に関する情報の多くを、非構造化文書からキーワードを抽出するための情報として利用することができる。
【００４３】
出力書式情報抽出部１０５では、出力書式定義１０４を参照して、各エレメントの出力時のレイアウトに関する情報と出力文字列に関する情報の中から、キーワードの抽出に必要な項目を可能な限り抽出する。
前述したように、この項目自体を「要件項目」と呼び、各項目について抽出される情報を「要件項目内容」と呼ぶ。
【００４４】
図１８に、図７に示したキーワード抽出ルールを作成する際に、各キーワード毎に必要な要件項目の例を示す。
［論理構造要素名］１８０１は、対象とする文字列対応要素の名称であり、文字列を値とする。
１８０２の［左スペース］と１８０３の［右スペース］は、このエレメントを出力する領域に対して、それぞれ左端および右端から最低何文字分のスペースを空けて内容文字列が記述されているかを表す条件である。
１８０４の［第一行スペース］は、他の行と比べて特殊なオフセットを取ることが多い第一行目が、左側に何文字分のスペースを空けて始まるかを表す。
１８０５の［文字列条件］は、このキーワードがどのような文字列によって記述されているかを示す。
１８０６の［割り付け］は、左スペース１８０２と右スペース１８０３によって定まる領域において、キーワードがどのように割り付けられているかを示す項目であり、右寄せ、左寄せ、センタリング、均等、の４種類の値をとる。
１８０７の［前接文字列］および１８０８［後接文字列］は、それぞれ注目しているキーワードの前後に現われる文字列対応要素との間に、どのような文字列が挟まれるのかを表す文字列である。
【００４５】
出力書式情報抽出部１０５では、出力書式定義１０４を参照して、図１８に示したような要件項目に関する情報、すなわち要件項目内容を可能な限り抽出する。
以下、図１７に示した出力書式定義から、要件項目内容を抽出する例を図１９に示す。
ある文字列対応要素についての要件項目内容を抽出するには、出力書式定義中の、その文字列対応要素に関する定義を利用する。例えば、条番号に関する要件項目は、図１７の１７１２〜１７２２の条番号に関する定義から抽出する。
要件項目［左スペース］及び［右スペース］は、それぞれ出力書式定義中の［オフセット１］および［オフセット２］と同じ内容を表す項目であるため、長さの単位をｐｔから文字数へと変換するだけでよい。具体的には、［オフセット１］および［オフセット２］の値を［文字ピッチ］の値で割ればよい（１９０１および１９０２）。
要件項目［第一行スペース］は、出力書式定義中の［オフセット１］に［冒頭変位］を加えたものに相当する。そこで、その両者の和を［文字ピッチ］で割った値を内容とする（１９０３）。
要件項目［文字列条件］は、出力書式定義中の［文字列情報］を参照して作成する（１９０４）が、図１７の例では全ての要素について［文字列情報］が”ＣＯＮＴＥＮＴ”、つまり文書インスタンス中の内容文字列をそのまま出力することになっているため、出力書式定義から文字列に関する具体的な情報は得られない。
要件項目［割り付け］は、出力書式定義中の［配置］と同じ概念を表す項目であるため、１９０５の規則に従って値を変換する。
要件項目［前接文字列］は、出力書式定義中の［前要素との接続］の内容をそのまま代入する（１９０６）。
要件項目：［後接文字列］は、文字列対応要素情報と、出力書式定義中の他の要素の［前要素との接続］を利用して求める（１９０７）。
具体的には、まず文字列対応要素情報を用いて、注目する文字列対応要素に後接する文字列対応要素（以下、「後接要素」と呼ぶ）を求める。
次に、全ての後接要素について、その要素の［前要素との接続］を調べ、その内容がどの後接要素についても同じであれば、その内容を注目する文字列対応要素の［後接文字列］として設定する。
後接要素によって［前要素との接続］の内容が異る場合には、［後接文字列］は設定しない。例えば条番号については、図１６の文字列対応要素情報の１６０６より、条番号の後接要素は条規定だけであることが分る。従って、条規定の［前要素との接続］である「” ”」が条番号の［後接文字列］の内容となる。
以上の手続きを全ての文字列対応要素に対して適用することにより、図１の出力書式情報１０６が生成される。
【００４６】
図１のキーワード抽出ルール作成部１０７では、文字列対応要素情報１０３と出力書式情報１０６の情報を、入出力装置１１２を通じてユーザに提示する。そして、ユーザから補完情報の入力を受け、要件項目情報の追加，修正を行なうことにより、キーワード抽出ルール１１３を生成する。
以下、キーワード抽出ルール作成部１０７における具体的な処理について説明する。
キーワード情報表示部１０８では、ユーザに対して、文字列対応要素名と、ある時点でどの文字列対応要素がキーワード対応要素として設定されているかを示す情報を提示する。
そして、ある文字列対応要素をキーワード対応要素として設定するようユーザから指示された場合には、補完情報入力部１０９を起動し、その文字列対応要素の要件項目内容を補完して書式条件を生成する。
また、その時点において「非キーワードが隣接してはならない」という拘束条件を満たすのに十分なキーワード対応要素が設定されているか否か検定するようユーザから指示された場合には、要素隣接検定部１１１を起動し、検定を行なう。
【００４７】
キーワード情報表示部１０８が入出力装置１１２を通じてユーザに表示するインタフェースの例を図２０に示し、処理フローを図２１に示す。
この二つの図を用いて、キーワード情報表示部１０８の動作を説明する。
キーワード情報表示部１０８は、起動時に文字列対応要素情報１０３を読み込み、各文字列対応要素の名称を得る（２１０１）。
２００１は、キーワード情報表示窓であり、文字列対応要素名を全て表示する要素名表示領域２００２と、キーワード対応要素として設定された文字列対応要素について、その書式条件を表示する書式条件表示領域２００３から構成される。
処理２１０２において、文字列対応要素名と、その時点においてキーワード対応要素として設定された要素の書式条件とを表示するが、最初はどの要素についても書式条件が設定されていないため、書式条件表示領域２００３には何も表示されない。
ある文字列対応要素に対して書式条件を付与し、その要素をキーワード対応要素として設定するには、ユーザが例えばマウスを用いて要素名表示領域２００２中の要素名をダブルクリックすることにより、補完情報入力部（図１の１０９）を起動する（２１０４）。
補完情報入力部１０９の動作については後述するが、文字列対応要素名を補完情報入力部１０９に渡し、その書式条件を返り値として受けとる。そして、ユーザの指示した文字列対応要素をキーワード対応要素として設定し（２１０５）、その書式条件を書式条件表示領域２００３に表示する（２１０２）。
図２０の例は、ある時点におけるインタフェースの表示例を示したものである。
この時点では、２００６の題名と２００７の項番号の二つの文字列対応要素に書式条件が付与されており、これはこの二つの文字列対応要素がキーワード対応要素として設定されていることを意味する。
【００４８】
２００４は隣接チェックボタンであり、このボタンをクリックすると、その時点で設定されているキーワード対応要素の集合が「非キーワードが隣接してはならない」という拘束条件を満たすのに十分であるか否かを検定する要素隣接検定部（図１の１１１）が起動される（２１０６）。
要素隣接検定部１１１の動作については後述するが、その検定を行ない、拘束条件を満たすのに十分なキーワード対応要素が設定されていることが判明した場合、ユーザは終了ボタンをクリックし、キーワード情報表示部１０８の処理を終了することを指示する。
キーワード情報表示部１０８は、キーワード対応要素名とその書式条件とを、キーワード抽出ルール（図１の１１３）として出力し、処理を終了する（２１０７）。
以上がキーワード情報表示部１０８の処理内容である。
【００４９】
次に、キーワード情報表示部１０８において、要素名をダブルクリックした際に起動される補完情報入力部１０９のインタフェースを図２２に示し、その処理フローを図２３に示す。
補完情報入力部１０９では、キーワード情報表示部１０８から渡された、キーワード対応要素として書式条件を設定すべき要素名を読み込み（２３０１）、その要素に対応する要件項目内容を出力書式情報（図１の１０６）から読み込む（２３０２）。そして、要件項目内容を要件項目編集窓２２０１に表示する（２３０３）。
要件項目編集窓２２０１は、表示内容を編集できる窓であり、表示内容が非構造化文書上の記述様式と異なる場合は、ユーザがその内容を変更する。
また、出力書式情報抽出部１０５において抽出できなかった要件項目内容（例えば、図１８および図１９の抽出例における「文字列条件」）については要件項目編集窓が空白になっているため、ユーザはその編集窓に要件項目内容を入力する（２３０４→２３０３）。
文字列条件についても要件項目編集窓上で編集してもよいが、文字列条件入力ボタン２２０２をクリックして文字列条件入力部（図１の１１０）を起動することにより（２３０５）、より容易に入力することができる。
文字列条件入力部１１０の処理については後述する。文字列条件を入力した後の表示例を図２２中の「文字列条件入力後」に示す。
【００５０】
要件項目内容の編集が終了し、全ての要件項目内容が非構造化文書上の記述様式に適合すると、ユーザは終了ボタン２２０３をクリックし、補完情報入力部１０９の処理を終了することを指示する。
補完情報入力部１０９は、要件項目を編集した文字列対応要素の要件項目内容から書式条件を生成し（２３０６）、その書式条件を返り値として処理をキーワード情報表示部１０８に戻す（２３０７）。要件項目内容から書式条件を生成する処理フローを図２４に示す。
図２２の「文字列条件入力後」に示した条番号の要件項目内容を書式条件に変換する例を、点線枠で囲む形で処理フローに付与する。
まず、要件項目［文字列条件］の内容（例えば「”第” ＮＵＭ１ ”条”」）を書式条件に代入する。
そして、要件項目［前接文字列］の内容が改行であるか否かを調べる（２４０１）。改行であれば、２４０３へ進む。改行でなければ、書式条件を’［’と’］’とで挟み、その直前に’＋’と［前接文字列］の内容を付加する（２４０２）。その際、空白についてはＳＰＣ｛整数｝に変換する。
次に、処理２４０３において、要件項目［後接文字列］の内容が改行であるか否かを調べる。改行であれば、書式条件の末尾に’＄’を付加して（２４０５）、処理２４０６へ進む。改行でなければ、書式条件中に’［’と’］’が存在しない場合には’［’と’］’とで挟み、直後に［後接文字列］の内容と’ ＋’とを付加する（２４０４，例えば「［”第” ＮＵＭ１ ”条”］ ＳＰＣ１ ＋」）。
処理２４０６では、要件項目［割り付け］の内容がセンタリングであるか否かを調べる。センタリングである場合には、書式条件の冒頭に’Ｃ’を付加し（２４０７）、書式条件の生成を終了する。逆にセンタリングでない場合には、処理２４０８に進み、［割り付け］の内容に従ってＡおよびＢの処理を行なう。
［割り付け］の内容が左寄せならばＡ、右寄せならばＢ、均等ならばＡとＢの両方の処理を実行し、書式条件の生成を終了する。
Ａでは、書式条件の冒頭部に’＾ＳＰＣｘ’を付加する（２４０９）。ただしｘは［冒頭インデント］の内容である（例えば「＾ＳＰＣ０ ［”第” ＮＵＭ１ ”条”］ ＳＰＣ１ ＋」）。
Ｂでは、まず書式条件の末尾部に’ＳＰＣｙ＄’を付加する（２４１０）。ここで、ｙは［右スペース］の内容である。
次に、書式条件の冒頭に’＾’または’＋’が存在しなければ、冒頭に’！’を付加する（２４１１）。
補完情報入力部１０９は、以上の手続きによって得られる書式条件を返り値として、処理をキーワード情報表示部１０８に戻す（図２３の２３０７）。以上が、補完情報入力部１０９の処理内容である。
【００５１】
次に、補完情報入力部１０９において、文字列条件入力ボタンをクリックした際に起動する文字列条件入力部１１０のインタフェースを図２５に示し、その処理フローを図２６に示す。
文字列条件入力部１１０は、文字列条件においてよく用いられる文字列の入力をボタン化することにより、入力の手間を削減することを目的とする。
２５０１は文字列条件表示窓であり、この窓上でユーザが文字列条件の編集を行なう。
２５０２は文字列条件表示窓内のカーソルであり、このカーソルの位置する箇所にユーザの挿入する文字を挿入することを表す。
２５０３〜２５０８は編集ボタンであり、これらをクリックすると、それぞれ図２６の表に示した処理を行なう（２６０２）。
このボタンでは入力できない文字、例えばＮＵＭやＳＰＣの後に続く文字等については、ユーザがキーボードから入力する。
２５０９はクリアボタンであり、ユーザがこのボタンをクリックすると、文字列条件表示窓内の内容がクリアされる（２６０３）。
２５１０は終了ボタンであり、ユーザがこのボタンをクリックすると、文字列条件入力部１１０は、文字列条件表示窓２５０１内の内容を返り値として、処理を補完情報入力部１０９に戻す（２６０４）。
以上が、文字列条件入力部１１０の処理内容である。
【００５２】
次に、キーワード情報表示部（図１の１０８）において、隣接チェックボタンをクリックした際に起動する要素隣接検定部１１１の処理フローを図２７に示し、その処理例を図２８に示す。
要素隣接検定部１１１では、まずキーワード情報表示部１０８から与えられるキーワード対応要素名を読み込む（２７０１，例えば２８０１）。
次に、文字列対応要素情報（図１の１０３）を読み込む（２７０２）。
そして、全ての文字列対応要素からキーワード対応要素を差し引いた集合として、非キーワード対応要素群を求める（２７０３，例えば２８０２）。
処理２７０４では、文字列対応要素情報を参照して、非キーワード対応要素の後接要素中に非キーワード対応要素が存在するか否かを調べる（例えば２８０３）。
存在する場合には、隣接する非キーワード対応要素をユーザに提示して（２７０５，例えば２８０４）処理を終了する。
また、存在しない場合には、非キーワードが隣接しないことをユーザに提示して（２７０６）、処理を終了する。
以上が要素隣接検定部１１１の処理内容である。
【００５３】
以上、本実施例に示した形態によって、キーワード抽出ルールの作成を支援することができる。
【００５４】
【発明の効果】
以上のように、本発明によれば、与えられた論理構造定義から抽出した文字列対応要素間の隣接情報を用いて、キーワードとして抽出する文字列対応要素の決定を支援し、またキーワードを抽出する際のレイアウトや文字列に関する条件を、与えられた出力書式定義から抽出することにより、キーワード抽出ルールの作成に要する労力を大幅に軽減することができる。
【図面の簡単な説明】
【図１】本発明の実施例に係わるキーワード抽出ルール生成方法の概要を説明するブロック図である。
【図２】構造化文書生成の全体的な流れを示した図である。
【図３】非構造化文書の例を示した図である。
【図４】図３に示した文書に対して設定されたＳＧＭＬ形式の論理構造定義であるＤＴＤを示した図である。
【図５】図４に示したＤＴＤをツリー状に表現した図である。
【図６】図２に示した非構造化文書を、図４に示した論理構造定義に沿う構造化文書に変換した例である。
【図７】キーワード抽出ルールの例を示した図である。
【図８】図７に示したキーワード抽出ルールにおける書式条件の記述要素を示した図である。
【図９】キーワードの抽出例を示した図である。
【図１０】文字列対応要素の抽出例を示した図である。
【図１１】ＤＴＤをＢＮＦ記法によって記述する際の変換規則の例を示した図である。
【図１２】図４のＤＴＤをＢＮＦ記法によって記述した例である。
【図１３】エレメントの冒頭に現われうる文字列対応要素を求める手続きを示した図である。
【図１４】図１２の論理構造定義について、各エレメントの冒頭と末尾に現われうる文字列対応要素を示した図である。
【図１５】図１２の論理構造定義について、文字列対応要素間の隣接関係を求める処理の例を示した図である。
【図１６】文字列対応要素情報の例を示した図である。
【図１７】出力書式定義の例を示した図である。
【図１８】キーワードを抽出するために必要な要件項目の例を示した図である。
【図１９】出力書式定義から要件項目の内容を抽出する処理の例を示した図である。
【図２０】キーワード情報表示部のインタフェース例を示した図である。
【図２１】キーワード情報表示部の処理フローを示した図である。
【図２２】補完情報入力部のインタフェース例を示した図である。
【図２３】補完情報入力部の処理フローを示した図である。
【図２４】書式条件生成の処理フローを示した図である。
【図２５】文字列条件入力部のインタフェースを示した図である。
【図２６】文字列条件入力部の処理フローを示した図である。
【図２７】要素隣接検定部の処理フローを示した図である。
【図２８】要素隣接検定部の処理例を示した図である。
【符号の説明】
１０１ 論理構造定義
１０２ 論理構造情報抽出部
１０３ 文字列対応要素情報
１０４ 出力書式定義
１０５ 出力書式情報抽出部
１０６ 出力書式情報
１０７ 要素隣接検定部
１０８ キーワード情報表示部
１０９ 補完情報入力部
１１０ 文字列条件入力部
２０１ 非構造化文書
２０２ キーワード抽出処理
２０３ キーワード抽出ルール
２０４ 論理構造認識処理
２０５ 論理構造認識ルール
２０６ 構造化文書
２０７ 論理構造定義

Claims (3)

1. 処理装置と、記憶装置と、入出力装置を備える情報処理システムにおける構造化文書生成のためのキーワード抽出ルール生成方法であって、
   前記処理装置は、
   前記記憶装置から該記憶装置に格納されている構造化対象文書に対応付けられた論理構造定義を読み込み、該論理構造定義から文字列対応要素と該文字列対応要素に後接しうる文字列対応要素を抽出し、抽出した文字列対応要素と該文字列対応要素に後接しうる文字列対応要素の対から構成される文字列対応要素情報を生成する文字列対応要素情報生成ステップと、
   前記記憶装置から該記憶装置に格納されている前記構造化対象文書に対応付けられた出力書式定義を読み込み、該出力書式定義から文書の論理構造の構成要素を出力する際のレイアウトおよび出力文字列に関する情報を抽出し、該抽出した情報のうちの前記文字列対応要素に関する情報を出力書式情報として生成する出力書式情報生成ステップと、
   前記生成した文字列対応要素情報と出力書式情報に基づいてキーワード抽出ルールを生成するキーワード抽出ルール生成ステップとを実行することを特徴とする情報処理システムにおける構造化文書生成のためのキーワード抽出ルール生成方法。
2. 請求項１記載のキーワード抽出ルール生成方法において、
   前記キーワード抽出ルール生成ステップにおいて前記処理装置は、前記出力書式情報をキーワード抽出に必要な項目毎に入出力装置に出力することによりユーザに対して表示し、前記入出力装置によりユーザが入力した入力情報に従い、非構造化文書上の出力様式に沿うように前記出力書式情報を修正し、かつ欠如している情報を前記出力書式情報に補うことを特徴とするキーワード抽出ルール生成方法。
3. 請求項１記載のキーワード抽出ルール生成方法において、
   前記キーワード抽出ルール生成ステップにおいて、前記入出力装置により表示された前記出力書式情報から前記論理構造の構成要素のどれをキーワードとして抽出するかをユーザが決定するとき、前記処理装置は前記文字列対応要素情報に基づき抽出すべき前記論理構造の構成要素を前記入出力装置に出力することによりユーザに対して指示、表示してユーザの決定を支援することを特徴とするキーワード抽出ルール生成方法。

Images