JP3605941B2 - 文書構造作成装置及び文書構造作成方法 - Google Patents
文書構造作成装置及び文書構造作成方法 Download PDFInfo
- Publication number
- JP3605941B2 JP3605941B2 JP12437996A JP12437996A JP3605941B2 JP 3605941 B2 JP3605941 B2 JP 3605941B2 JP 12437996 A JP12437996 A JP 12437996A JP 12437996 A JP12437996 A JP 12437996A JP 3605941 B2 JP3605941 B2 JP 3605941B2
- Authority
- JP
- Japan
- Prior art keywords
- document
- node
- state
- transition
- automaton
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/151—Transformation
- G06F40/154—Tree transformation for tree-structured or markup documents, e.g. XSLT, XSL-FO or stylesheets
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/14—Tree-structured documents
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Document Processing Apparatus (AREA)
Description
【発明の属する技術分野】
本発明は、文書構造を作成する文書構造作成装置及び文書構造作成方法に関し、特に所定の文書クラスの構造制約を満たした文書構造を作成する文書構造作成装置及び文書構造作成方法に関する。
【0002】
【従来の技術】
構成要素として章、節、項などに代表される論理的な構造を持つ文書を構造化文書と呼ぶが、この文書の構造の統一を図ることで、文書の共有や変換が容易となることが知られている。SGML(Standard Generalized Markup Language)や、ODA(Office Document Architecture)などの国際規格の普及もあり、構造化文書は電子的な文書の主流となりつつある。
【0003】
この構造化文書は通常、文書の構造及び構成要素を定義した文書クラスと呼ばれる分類に従って構造化されている。ODAでは共通論理構造が文書クラスに該当し、SGMLではDTD(Data Type Definition)が文書クラスの役割を担っている。
【0004】
構造化文書において文書構造が文書クラスの制約に従っていることには、重要な意味がある。例えば、構造化文書をレイアウトするための規則は、文書構造やその構成要素が特定の文書クラスの制約を満たしていることを前提に決められることが多い。そのため、文書構造が文書クラスの制約から逸脱している場合には正しいレイアウトでの出力ができない。
【0005】
また、報告書群からの抄録リスト作成のような、多くの構造化文書を処理するためのプログラムには、対象となる文書が特定の文書クラスに従って作成されていることを利用したものが多い。このようなプログラムを利用する際、所定の文書クラスに従わない文書の存在は、プログラム実行の障害となり得る。さらに、構造化文書を対象にしたデータベースでは文書クラスをスキーマとして利用することが多く、スキーマから逸脱したデータの存在はデータベースの信頼性を大きく損なうこととなる。
【0006】
こういった観点から、文書を文書クラスに適合させ、構造化文書の利点を有効に活用したいという要求が生じている。文書の再利用のために、文書クラスAに適合した構造化文書を別の文書クラスBに適合した構造化文書に変換したい、また、特定の文書構造を持たないフラットなテキストで作成された文書を特定の文書クラスに適合した構造化文書に変換したい、といった要求も存在する。
【0007】
また、文書を流通させる媒体として、紙は依然として多くの場面で使用されている。そのため、紙面上の文書画像を、特定の文書クラスに従った構造化文書に変換して構造化の恩恵を受けようとするニーズも多い。
【0008】
ところが、文書の構造を特定の文書クラスに適合させる作業は、時にユーザにとって大きな負担となる。
新しい文書を作成する際に特定の文書クラスに従って文書を作成することは、さほど難しいことではない。だが、既存の文書を特定の文書クラスに変換することは、大きな問題を含んでいる。
【0009】
変換の対象となる文書データや文書画像は、これまでの活動の蓄積の結果である。その量は膨大である場合が多く、変換を全て人手で行うのは困難である。しかも、変換によって新たな情報の生産を行うわけではないので、多くのコストはかけられない。
【0010】
このような問題を解決し、任意の文書を自動的に構造化文書に変換する技術がいくつか存在している。文書の構造は全て木構造で表わせるものとして、以下に説明を行う。
【0011】
まず、文書クラスAに従った構造化文書を別の文書クラスBに従った構造化文書に変換する方法は、Fred Cole , Heather Brown 著のEditing Structured Documents−Problem and solutions (Electronic Publishing,vol.5,No.4,pp.209−216)に記載されている「fall back class」の概念を応用するこ とにより容易に考えられる。つまり、文書クラスAで規定されたノードのタイプが、文書クラスBで規定されたどのタイプのノードに変換されるかを規則として定義しておく。変換を実行する際には、予め定義されている規則に基づいて、文書クラスAに従った文書構造に含まれる各ノードを、文書クラスBに従った文書構造に含まれるノードに逐一変換する。
【0012】
フラットなテキストで作成された文書を構造化文書に変換する方法は、特開昭63−286963号公報に記載されている。すなわち、フラットなテキストの文字列の特徴から、章、節、項の見出しや本文の段落などの構造を決定し、それらを基に構造化文書を作成することが可能である。
【0013】
文書画像を構造化文書に変換する場合には、特開平6−214983号公報に記載されている方法が利用できる。つまり、レイアウト上の特徴から、章、節、項の見出しや本文の段落、ヘッダ、フッタなどの構造を決定し、それをもとに構造化文書を作成することが可能である。
【0014】
ところが、上記の技術ではいずれも、種々の文書クラスに従った構造化を行う場合に、所望の文書クラスの構造制約上必要なノードや部分木を補うことが困難であることが問題になる。
【0015】
fall back classを応用した変換では、変換後の文書構造は、必ずしも文書クラスBの制約に従っているとは言いきれない。変換後の文書構造に存在するノードは、変換前の文書構造に、対応するノードが存在したものだけである。つまり、変換前の文書構造に存在しないノードの変換は不可能であり、変換後の文書構造には、変換前の文書構造に対応するノードのなかったノードが不足している。ノードの不足は文書クラスの制約を満たさない原因になることが多く、この方法が実用に堪えないことは容易に予想できる。
【0016】
特開昭63−286963号公報の文書変換では、作成できるノードは、テキスト中に存在し、構造を決定できるような特徴ある文字列に対応するノードと、それらを連結するために必要な、予め決められた(すなわち、補完されるノードと補完位置が決まっており、処理プログラムにコーディング済みの)ノードとだけである。
【0017】
また、特開平6−214983号公報の文書変換では、作成できるノードは、文書画像中に存在し、構造を決定できるような特徴あるレイアウトに対応するノードと、それらを連結するために必要な、予め決められた(すなわち、補完されるノードと補完位置が決まっており、処理プログラムにコーディング済みの)ノードとだけである。
【0018】
つまり、上記のような文書変換では、フラットなテキストや文書画像を所望の文書クラスの構造制約を完全に満たした構造化文書に変換することは、実際には不可能である。
【0019】
所望の文書クラスに合わせてノードや部分木を補うものとしては、特公平6−12542号公報がある。特公平6−12542号公報では、構造化文書の一部を他の部分にコピーする場合に、文書クラスの定義に照らし合わせた上で必要なノードが不足しているときには自動的に補う機能をもっている。
【0020】
【発明が解決しようとする課題】
しかし、文書クラスの定義に照らし合わせて自動的に文書構造にノードや部分木を補うことには、次の点で大きな問題がある。
【0021】
第1の点は、文書構造中のある領域における補完は、文書構造の他の領域が文書クラスに適合するかどうか、他の領域でどういう補完を行うべきか、という問題と相互に影響し合うことを考慮に入れていない点である。すなわち、文書構造の補完の仕方は文書構造上の特定の局所領域を見ただけで決められるものではなく、文書全体の構造から決定されるべきである。
【0022】
第2の点は、任意の文書クラスに適合するような補完の仕方は、一般に複数(時には無限に)存在するにも拘わらず、ユーザにその選択権がないことである。つまり、補完の仕方を選択できないため、ユーザには質の悪い補完結果の出現を防ぐ術がないことになる。
【0023】
上記の問題点を解決する方法としては、ユーザ自身が文書構造を編集し、所望の文書クラスの制約に適合させるという方法も当然考えられる。しかし、文書全体の構造を把握した上で、ノードを補う部分を決定することは、負荷の大きい作業である。首尾よく補完する箇所を見つけられたとしても、文書クラスの制約を満たすように適切な補完を行うことは大変な困難を伴う。また、長い文書、多くの文書に対してこの方法を適用するのは、事実上不可能である。
【0024】
本発明はこのような点に鑑みてなされたものであり、文書構造にノードや部分木を補う場合に、常に所望の文書クラスに適合するような補完を行うことにより、ユーザの求める文書構造の作成を可能とする文書構造作成装置及び文書構造作成方法を提供することを目的とする。
【0025】
【課題を解決するための手段】
本発明では上記課題を解決するために、所定の文書クラスの構造制約を満たした文書構造を作成する文書構造作成装置において、所定の手続きに従って作成された、目的とする文書構造を完全には満たしていない被補完文書構造を前記文書クラスに適合させるにあたり、補完が必要なことが予測される要素の構成要素タイプに対するユーザにより指定される補完指定を記憶する補完指定記憶手段と、前記被補完文書構造を前記文書クラスの構造制約と前記補完指定とに基づいて解析し、前記被補完文書構造に不足している要素を補った文書構造を作成する補完手段と、を有することを特徴とする文書構造作成装置が提供される。
【0026】
この文書構造作成装置によれば、補完指定記憶手段は、所定の手続きに従って作成された文書構造を完全には満たしていない被補完文書構造を文書クラスに適合させるにあたり、補完が必要なことが予想される要素の構成要素タイプに対するユーザに指定される補完指定を記憶している。補完手段は、被補完文書構造を文書クラスの構造制約と補完指定とに基づいて解析し、被補完文書構造に不足している要素を補った文書構造を作成する。
【0027】
この構成によれば、文書構造にノードや部分木を補う場合に常に所望の文書クラスに適合するような補完を行うことができ、ユーザの求める構造化文書の作成が可能となる。
【0028】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。図1は本発明の文書構造作成装置の原理構成図である。
【0029】
本発明の文書構造作成装置は、文書に対する補完の指定を記憶する補完指定記憶手段1と、被補完文書を補完して構造化文書を作成する補完手段2と、異なる文書クラス間の構成要素タイプの対応規則を記憶している対応規則記憶手段3と、特定の文書クラスの構造制約を満たした原文書を、対応規則に従って別の文書クラスにほぼ従った構造になるように変換する文書構造変換手段4とから構成される。
【0030】
図において、原文書とは変換前の文書クラスの構造制約を満たした文書であり、フラットなテキストで構成された文書や文書画像も含む。また、被補完文書とは原文書を希望の文書クラスの構造制約に従うよう変換したものである。但し原文書の構成要素タイプと希望の文書クラスの構成要素タイプが必ず1対1で対応しているとは限らず、この被補完文書を希望する文書クラスに従った構造とするためには補完処理が必要である。被補完文書の文書構造を補完して希望の文書クラスに適合する文書構造としたものが構造化文書である。
【0031】
ここで補完指定記憶手段1には、ユーザが行った補完の指定が記憶される。
補完手段2は、補完指定と希望文書クラスの定義とから補完のための状態遷移機械を作成する状態遷移機械作成手段2aと、作成した状態遷移機械を被補完文書に適用して構造化文書を作成する状態遷移機械適用手段2bとから構成されている。
【0032】
対応規則記憶手段3は、様々な文書クラスの定義及び各文書クラスの構成要素タイプの対応規則を記憶しており、要求があれば、必要な定義や対応規則を出力する。
【0033】
文書構造変換手段4は、まず原文書を解析し、原文書の持つ構成要素及び文書構造を認識する。その後、希望する文書クラスに適合するよう対応規則に基づいて文書構造の変換を行う。
【0034】
次に、本発明の第1の実施の形態の詳しい構成を説明する。図2は文書構造作成装置の第1の実施の形態の構成を示すブロック図である。なお、図1に示す構成と図2に示す構成との対応関係は、図2の説明を行った後に述べる。
【0035】
本発明の文書構造作成装置20は、ユーザから入出力i/f10を介して構造化文書の作成に必要なデータを入力され、入力されたデータから構造化文書を作成し、作成した構造化文書を入出力i/f10を介してユーザに出力する。
【0036】
ここで必要になるデータとは、変換を希望する原文書データと、原文書データの現在の文書クラス名(入力文書クラス名)と、どの文書クラスに変換することを希望するのかを示す別の文書クラス名(出力文書クラス名)とである。また、詳しくは後述するが、補完指定も同時に行うことができる。
【0037】
文書構造作成装置20は、入力データを受け付ける入力データ受付部21と、文書クラスの定義情報を管理している文書クラス管理部22と、入力された原文書データを解析する文書構造解析部23と、異なる文書クラス間の変換規則を管理している変換規則管理部24と、文書構造の変換を行う文書構造変換部25と、補完指定を管理している補完指定管理部26と、補完処理を行う補完処理部27と、構造化文書を文書データにして出力する文書データ生成部28とから構成されている。
【0038】
入力データ受付部21は、入出力i/f10を介してデータの入力を受け付けると、原文書データを文書構造解析部23へ、入力文書クラス名を文書構造解析部23、変換規則管理部24、補完指定管理部26へ、出力文書クラス名を変換規則管理部24、補完指定管理部26、補完処理部27内のオートマトン作成部27aへ、それぞれ入力する。
【0039】
文書クラス管理部22は、この文書構造作成装置20で扱える文書クラスの定義情報を全て記憶・管理しており、各部の要求に応じて定義情報の供給を行う。なお、この図における文書クラス管理部22への文書クラス定義情報の要求、及び文書クラス管理部22からの文書クラス定義情報の供給の流れは、破線で示してある。
【0040】
文書構造解析部23は、入力された入力文書クラス名を認識し、文書クラス管理部22に該当する文書クラスの定義情報を要求する。定義情報の供給を受けた後、原文書データを定義情報と照合し、論理的な構造を調べ、原文書データの構成要素と入力文書クラスの構成要素タイプとの対応関係を文書構造変換部25へ送る。
【0041】
変換規則管理部24は、この文書構造作成装置20で扱える複数の文書クラスの各々に対し、該文書クラスを入力文書クラスとして文書クラスの変換を行う際、該文書クラスの構成要素タイプを、出力文書クラスとされた文書クラスの構成要素タイプにどのように変換するかを定めた変換規則を全て記憶、管理している。そして、入力文書クラス名と出力文書クラス名とが入力されると、2つの文書クラス名に対応する変換規則を文書構造変換部25に供給する。
【0042】
文書構造変換部25は、文書構造解析部23からは原文書データの構成要素と入力文書クラスの構成要素タイプとの対応関係を、変換規則管理部24からは入力文書クラスから出力文書クラスへの変換規則を、それぞれ供給される。その後、供給された変換規則に基づいて原文書データの変換を行い、被補完文書データを作成する。被補完文書データは補完処理部27へ送られる。
【0043】
補完指定管理部26は、この文書構造作成装置20で扱える文書クラスの構成要素タイプに対し、入力文書クラス名と出力文書クラス名とに基づいて、どのような補完を行うかを指定する補完指定を記憶、管理している。そして、入力文書クラス名と出力文書クラス名とが入力されると、2つの文書クラス名に対応する補完指定を補完処理部27に供給する。なお、ユーザはこの補完指定を必要に応じて作成、更新することができる。この場合ユーザは、入力データとして原文書データや入力文書クラス名、出力文書クラス名と併せて、補完指定も入力することになる。
【0044】
補完処理部27は、オートマトン作成部27aとオートマトン適用部27bとから構成されており、オートマトンと呼ばれる状態遷移機械を利用して被補完文書の補完処理を行う。オートマトン作成部27aは、入力データ受付部21から入力された出力文書クラス名に基づいて、文書クラス管理部22に出力文書クラスの定義情報を要求し、この情報と補完指定管理部26から供給された補完指定とを基に補完オートマトンを作成する。オートマトン適用部27bは、オートマトン作成部27aで作成した補完オートマトンを利用して被補完文書を補完し、出力文書クラスに従った文書構造を作成する。
【0045】
文書データ生成部28は、補完処理部27で作成された文書構造を構造化文書データに変換し、入出力i/f10を介してユーザに出力する。
なお、図1に示した構成と図2に示した構成の対応関係をあげると、図1の補完指定記憶手段1が図2の補完指定管理部26に、補完手段2が補完処理部27に、対応規則記憶手段3が変換規則管理部24に、文書構造変換手段4が文書構造変換部25に、それぞれ相当している。また、状態遷移機械作成手段2aはオートマトン作成部27aに、状態遷移機械適用手段2bはオートマトン適用部27bに、各々対応している。
【0046】
次に、この文書構造作成装置20を用いて構造化文書の作成を行う手順を説明する。図3は構造化文書の作成手順を示すフローチャートである。以下、図中のステップ番号に沿って説明を行う。
[S1]入力データ受付部21は、入出力i/f10を介して入力データを受け付ける。入力データとなるものは、構造化を希望する原文書データと、原文書データの現在の文書クラス名(入力文書クラス名)と、どの文書クラスへの構造化を希望するのかを示す別の文書クラス名(出力文書クラス名)とである。また、ユーザの希望があれば補完指定も受け付ける。
[S2]文書構造解析部23において、原文書データを入力文書クラスの定義情報に基づいて解析し、文書構造を抽出する。文書解析にあたり必要となる定義情報は、入力データ受付部21から入力された入力文書クラス名を基に文書クラス管理部22に要求して得られたものである。
[S3]変換規則管理部24は、入力文書クラス名及び出力文書クラス名より変換規則を決定し、文書構造変換部25に供給する。文書構造変換部25は、供給された変換規則に基づいて原文書の文書構造を変換し、被補完文書を作成する。この変換の手順に関してはこの後に詳しく説明する。
[S4]補完指定管理部26は、補完指定を決定し、補完処理部27に供給する。補完指定には、ユーザからの指定が入力データに含まれていればその補完指定を、含まれていなければ入力文書クラス名及び出力文書クラス名より選択される補完指定を、利用する。
[S5]補完処理部27内のオートマトン作成部27aは、出力文書クラスの定義情報と供給された補完指定とを基に、補完オートマトンを作成する。この補完オートマトン作成の手順については後で詳しく説明する。
[S6]補完処理部27内のオートマトン適用部27bは、補完オートマトンを実際に動作させ、被補完文書に補完を行って希望する文書クラスに従った文書構造を作成する。作成した文書構造は文書データ生成部28へ送る。この文書構造作成の手順については後で詳しく説明する。
[S7]文書データ生成部28は送られた文書構造から構造化文書データを生成し、入出力i/fを介してユーザに出力してこの処理を終了する。なお、構造化文書を正しく作成できなかった場合は、その旨ユーザに通知を行う。
【0047】
次に、文書クラス及びその定義情報について詳しく説明する。文書クラス管理部22では、1つの文書クラスをその文書クラスの名称と、その文書クラスの定義情報とのペアで記憶している。なお、文書クラス管理部22には複数の文書クラスが記憶されるが、個々の文書クラスの名称は、この文書構造作成装置20内で一意である。
【0048】
文書クラスの定義情報は、文書構造を構成するノードのタイプ定義と、定義されたノードの接続関係を規定する構造制約とから構成される。特定の文書クラスの定義情報を満たした文書構造を、その文書クラスの文書構造、と呼ぶ。また、その文書クラスの文書構造を持つ文書データを、その文書クラスの文書データ、と呼ぶ。
【0049】
文書構造を構成する要素(ノード)のタイプ定義は、次の2つの要素からなっている。すなわち、ノードのタイプを識別するための文字列であるタイプ名と、ノードの持つ内容の種類を示す内容型指定とである。ここでこの内容型指定は、「内容を持たない」か、「文字列型の内容を持つ」か、「幾何図形型の内容を持つ」かの3種類の内の1つである。なお、タイプ名が「A」であるタイプのことを「Aタイプ」と呼び、「Aタイプのノード」のことを「Aノード」と呼ぶ。
【0050】
定義されたノードの接続関係を規定する構造制約は、次に示す構造制約子と、上記ノードのタイプ定義とから作られる木構造によって定義される。構造制約子にはSEQ、REP、CHOの3種類があり、それぞれ次のような意味を持つ。
【0051】
構造制約子SEQは、複数の下位構造をとり、その下位構造で規定された構造が、規定された順序で出現することを示す。
構造制約子REPは、単一の下位構造をとり、その下位構造で規定された構造が、1回以上繰り返し出現することを示す。
【0052】
構造制約子CHOは、複数の下位構造をとり、その下位構造で規定された構造の内のどれかが出現することを示す。
ここで、本発明の文書構造作成装置20は文書クラス管理部22において、「技術メモ」という名称のものと、「Technical Report 」という名称のものとを含む複数の文書クラスを記憶しているとする。
【0053】
図4は、「技術メモ」という名称を持つ文書クラスの定義情報のうち、ノードのタイプ定義を示したものである。文書クラス「技術メモ」のノードのタイプ定義101によると、この文書クラスは、内容を持たない「技術メモ」ノードと、内容を持たない「文頭」ノードと、文字列型の内容を持つ「表題」ノードと、文字列型の内容を持つ「著者」ノードと、文字列型の内容を持つ「メールアドレス」ノードと、内容を持たない「節」ノードと、文字列型の内容を持つ「見出し」ノードと、文字列型の内容を持つ「段落」ノードと、内容を持たない「図形部」ノードと、文字列型の内容を持つ「図見出し」ノードと、幾何図形型の内容を持つ「図形」ノードとを持っている。
【0054】
また、図5は、「技術メモ」という名称を持つ文書クラスの定義情報のうち、定義されたノードの接続関係を規定する構造制約を示す。文書クラス「技術メモ」の構造制約102によると、この文書クラスは、「技術メモ」ノードの下に、1つの「文頭」ノードと、1つ以上繰り返し出現する「節」ノードとを持つ。また、「文頭」ノードは下位構造として、「表題」ノードと、「著者」ノードと、「メールアドレス」ノードとを各々1つずつ持つ。「節」ノードは、1つの「見出し」ノードと、1つ以上繰り返し出現する「段落」ノードと、1つ以上繰り返し出現する「図形部」ノード或は「図形」ノードを持つ。「図形部」ノードは、「図見出し」ノードと、「図形」ノードとを各々1つずつ持つ。
【0055】
図6は、「Technical Report 」という名称を持つ文書クラスの定義情報のうち、ノードのタイプ定義を示したものである。文書クラス「Technical Report 」のノードのタイプ定義501によると、この文書クラスは、内容を持たない「Report 」ノードと、内容を持たない「Header 」ノードと、文字列型の内容を持つ「Report −Title」ノードと、内容を持たない「Author 」ノードと、文字列型の内容を持つ「Name 」ノードと、文字列型の内容を持つ「Address」ノードと、内容を持たない「Revision −Dates」ノードと、文字列型の内容を持つ「Date 」ノードと、内容を持たない「Section」ノードと、文字列型の内容を持つ「Title」ノードと、文字列型の内容を持つ「Paragraph」ノードと、内容を持たない「Artwork」ノードと、文字列型の内容を持つ「Caption」ノードと、幾何図形型の内容を持つ「Figure 」ノードとを持っている。
【0056】
また、図7は、「Technical Report 」という名称を持つ文書クラスの定義情報のうち、定義されたノードの接続関係を規定する構造制約を示す。文書クラス「Technical Report 」の構造制約502によると、この文書クラスは、「Report 」ノードの下に、1つの「Header 」ノードと、1つ以上繰り返し出現する「Section」ノードとを持つ。また、「Header 」ノードは下位構造として、「Report −Title」ノードと、「Author 」ノードと、「Revision −Dates」ノードとを各々1つずつ持つ。更に「Author 」ノードは、「Name 」ノードと、「Address」ノードを1つずつ持ち、「Revision −Dates」ノードは1つ以上繰り返し出現する「Date 」ノードを持つ。また、「Section」ノードは、1つの「Title」ノードと、1つ以上繰り返し出現する「Paragraph」ノード或は「Artwork」ノードを持つ。「Artwork」ノードは、「Caption」ノードと、「Figure 」ノードとを各々1つずつ持つ。
【0057】
ここで文書クラス「技術メモ」を以上のように定義、記憶している文書構造作成装置に、実際に文書クラス「技術メモ」の定義を満たした文書データを原文書として入力した場合、どのように解析されるのかを説明する。ここで解析処理を行うのは図2に示した文書構造作成装置20内の文書構造解析部23であり、入力文書クラス名として「技術メモ」という名称を入力してあるものとする。また、この解析処理は図3に示した構造化文書作成の手順を示すフローチャートのステップS2にあたる。
【0058】
図8は、「技術メモ」の文書データを定義情報に基づいて解析し、文書構造を抽出した結果の例を示す。「技術メモ」の文書データの文書構造解析結果110において、ノードは楕円で表わしてあり、楕円の中の文字列はそのノードのタイプ名を表わす。また、ノードの内容はノードの直下に矩形で表わしてあり、文字列型の内容を持つノードには文字列が、幾何図形型の内容を持つノードには幾何図形が、そのノードの内容として付随している。
【0059】
この例では、原文書の文書構造は「技術メモ」ノードをルートとする木構造である。「文頭1」ノードには「表題1」ノード「構造化文書の... 」と、「著者1」ノード「TaroFuji」と、「メールアドレス1」ノード「fuji@xxx.xxx」とが含まれている。また、「節1」ノードには、「見出し1」ノード「はじめに」と、「段落1」ノード「このメモは... 」と、「段落2」ノード「確かに... 」と、「図見出し1」ノード「文書変換の... 」と「図形1」ノードを含む「図形部1」ノードとが含まれている。また、「節2」ノードには、「見出し2」ノード「自動補完とは... 」と、「段落3」ノード「この節では... 」と、「図形2」ノードと、「図形3」ノードとが含まれている。
【0060】
次に図3のステップS3で述べた文書構造変換について詳しく説明するが、その前に、文書構造変換に利用する変換規則について説明を行う。変換規則管理部24には、文書構造作成装置20で認識可能な文書クラス全てに関する変換規則が、入力文書クラス名及び出力文書クラス名とセットで記憶されている。従って、ユーザから入出力10、入力データ受付部21を介して入力文書クラス名、出力文書クラス名の入力を受けた変換規則管理部24は、該当する2つの文書クラス名から、セットになっている変換規則を呼び出し、文書構造変換部25へ供給する。
【0061】
変換規則自体は、入力文書クラスの定義に含まれるタイプ定義のタイプ名(入力タイプ名)と、出力文書クラスの定義に含まれるタイプ定義のタイプ名(出力タイプ名)とをペアにしたものの集合である。個々のペアは、入力タイプ名で指定されたタイプのノード(入力ノード)が、出力タイプ名で指定されたタイプのノード(出力ノード)に変換されることを示している。また、この時入力ノードに付随している内容は、そのまま出力ノードの内容となる。
【0062】
この変換規則には以下に示す3つの制約がある。
第1に、同じ入力タイプ名を持つペアは、同一変換規則中に複数存在してはならない。つまり、1つの入力ノードを複数の出力ノードに変換するような変換規則は認められない。
【0063】
第2に、ペアになっているタイプはその内容型指定が一致していなければならない。これは、文字列型の内容を持っている入力ノードは、文字列型の内容を持つと定義された出力ノードにしか変換できないためである。同様に、幾何図形型の入力ノードは幾何図形型の出力ノードにしか、内容を持たない入力ノードは内容を持たない出力ノードにしか変換できない。よって、内容型指定の一致していないペアを含む変換規則は、認められない。
【0064】
第3に、入力文書クラス定義に含まれる全てのタイプに対するペアが、変換規則に含まれていなければならない。これはつまり、全ての入力ノードは何らかの形で出力ノードに変換されなければならないということである。
【0065】
以上の制約に留意し、先にあげた文書クラス「技術メモ」を入力文書クラス、文書クラス「Technical Report 」を出力文書クラス、として作成された変換規則を、具体的にあげてみる。
【0066】
図9は、入力文書クラス名「技術メモ」、出力文書クラス名「Technical Report 」の変換規則を示す。この変換規則200は, 入力文書クラス名「技術メモ」及び出力文書クラス名「Technical Report 」とセットで変換規則管理部24に記憶されており、両文書クラス名の入力に伴って文書構造変換部25へ供給される。
【0067】
この変換規則によれば、文書クラス「技術メモ」の文書データを文書クラス「Technical Report 」の文書データに変換する場合、入力ノード「技術メモ」は出力ノード「Report 」に変換することになる。以下同様に、入力ノード「文頭」は出力ノード「Header 」に、入力ノード「表題」は出力ノード「Report −Title」に、入力ノード「著者」は出力ノード「Name 」に、入力ノード「メールアドレス」は出力ノード「Address」に、入力ノード「節」は出力ノード「Section」に、入力ノード「見出し」は出力ノード「Title」に、入力ノード「段落」は出力ノード「Paragraph」に、入力ノード「図形部」は出力ノード「Artwork」に、入力ノード「図見出し」は出力ノード「Caption」に、入力ノード「図形」は出力ノード「Figure 」に、変換することになる。
【0068】
以上のような変換規則を実際に利用して文書構造の変換を行う場合、どのような手順で処理を行うのかを次に説明する。
図10は、文書構造変換の詳しい手順を示したフローチャートである。この処理は図3のステップS3にあたり、変換規則の供給を受けた文書構造変換部25において実行される。以下、図中のステップ番号に沿って説明を行う。
【0069】
なお、この文書構造変換処理では、入力される文書構造中のノードの1つを currentノード、変換によって作成された出力ノードの1つを親ノードとして処理を進める。処理を開始する時点においては、入力される文書構造のルートノードを currentノードとする。また、その場合、親ノードは未定としておく。
[S31] currentノードのタイプ名を入力タイプ名として持つ変換規則ペアを変換規則200から検索し、対応する出力タイプ名を得る。
[S32]ステップS31で得られた出力タイプ名に基づいて、出力ノードを作成する。ここで currentノードに内容が付随していた場合は、その内容をコピーして、生成した出力ノードの内容とする。
[S33] currentノードがルートであるか否か判断する。ルートであるならばステップS35へ、ルートでないならばステップS34へ進む。
[S34] currentノードがルートでないということは、この処理は既に少なくとも2つ以上の出力ノードを作成し、親ノードにあたるものを持っているということである。よって、この時点で親ノードとされている出力ノードに、ステップS32で作成した出力ノードを末子として連結する。
[S35]ステップS32で作成した出力ノードを新しい親ノードとする。
[S36] currentノードが子供を持つか否か判断する。子供を持つならばステップS37へ進み、子供を持たないならばこの処理を終了する。
[S37] currentノードの長子を新しい currentノードとする。
[S38]ここまでの処理で新しい親ノードと新しい currentノードとが決定しているので、この2つを用いて、改めて文書構造変換処理を実行する。つまり、この時点で決定している親ノードと currentノードとに基づいて、このフローチャートのステップS31から終了に至るまでの処理を行う。この処理が終了したならば、次のステップS39へ進む。
[S39] currentノードが弟を持つか否か判断する。弟を持つならばステップS40へ進み、弟を持たないならばこの処理を終了する。
[S40] currentノードの直後の弟を新しい currentノードとする。
【0070】
ここで、図8に示した「技術メモ」の文書データを、図9に示した変換規則に200基づいて、文書クラス「Technical Report 」の文書データに変換した例を示す。
【0071】
図11は、「技術メモ」の文書データを、文書クラス「Technical Report 」の文書データに変換した被補完文書の構造である。被補完文書構造210は、図8に示した「技術メモ」の文書データの文書構造解析結果110のノードの持つ内容を全て持っており、なおかつ文書クラス「Technical Report 」にほぼ従った構成となっている。
【0072】
しかし、被補完文書構造210は、図7に示した構造制約502を完全には満たしていない。「Header 」ノードのみを見ても、「Author 」ノード、「Revision−Dates」ノード、「Date 」ノードが不足しており、この文書構造210を文書クラス「Technical Report 」の文書データと呼ぶことはできない。
【0073】
このような被補完文書構造を希望の文書クラスに従った文書構造にするために、本発明では補完処理を行う。ここで言う補完処理とは、被補完文書構造に不足しているノードや部分木を補う処理のことである。この補完処理に用いるための状態遷移機械として補完オートマトンを作成する手順について次に説明を行うが、その前に、補完オートマトン作成にあたり必要となる補完指定について、及び補完オートマトンについて、説明を行う。
【0074】
補完指定管理部26には、文書構造作成装置20で認識可能な文書クラス全てに関する補完指定が、入力文書クラス名及び出力文書クラス名とセットで記憶されている。従って、ユーザから入出力10、入力データ受付部21を介して入力文書クラス名、出力文書クラス名の入力を受けた補完指定管理部26は、該当する2つの文書クラス名から、セットになっている補完指定を呼び出し、補完オートマトン作成部27aへ供給する。また、この文書構造作成装置20では、ユーザの希望に応じて補完指定を新たに作成・更新することができる。ユーザから新たな補完指定の入力を受けた補完指定管理部26は、この補完指定を記憶し、オートマトン作成部27aに供給することになる。
【0075】
補完指定自体は、出力文書クラスの定義に含まれるタイプ定義のタイプ名(補完タイプ名)と、補完の種類(補完アクション)をペアにしたものの集合である。個々のペアは、補完タイプ名で指定されたタイプのノード(補完ノード)が、補完アクションに示された方法で補完されることを示している。
【0076】
ここで補完アクションには「追加」「追加可」「差し込み」「差し込み可」の4種類があり、それぞれ次のような意味を持つ。
補完アクション「追加」は、ペアになっている補完タイプ名を持つノードをルートとする部分木が被補完文書構造において不足しており、その部分木を出力文書クラスの構造制約に従って追加しなければならないことを示す。
【0077】
補完アクション「追加可」は、ペアになっている補完タイプ名を持つノードをルートとする部分木が被補完文書構造において不足している場合があり、その部分木を出力文書クラスの構造制約に従って追加することを示す。
【0078】
補完アクション「差し込み」は、ペアになっている補完タイプ名を持つノードが被補完文書構造の途中で抜けており、そのノードを出力文書クラスの構造制約に従って差し込まなければならないことを示す。
【0079】
補完アクション「差し込み可」は、ペアになっている補完タイプ名を持つノードが被補完文書構造の途中で抜けている場合があり、そのノードを出力文書クラスの構造制約に従って差し込むことを示す。
【0080】
補完指定には、同じ補完タイプ名を持つペアは同一補完指定中に複数存在してはならないという制約がある。つまり、1つの補完ノードに対して複数の補完アクションを行うような補完指定は認められない。
【0081】
上記の制約に留意し、先にあげた文書クラス「技術メモ」を入力文書クラス、文書クラス「Technical Report 」を出力文書クラスとして作成された補完指定を、具体的にあげてみる。
【0082】
図12は、入力文書クラス名「技術メモ」、出力文書クラス名「Technical Report 」の補完指定を示す。この補完指定300は入力文書クラス名「技術メモ」及び出力文書クラス名「Technical Report 」とセットで、補完指定管理部26に記憶されており、両文書クラス名の入力に伴って補完処理部27内のオートマトン作成部27aへ供給される。
【0083】
この補完指定300によれば、文書クラス「技術メモ」の文書データを文書クラス「Technical Report 」の文書データに変換した後、構造化文書を作成するための補完オートマトンを作成する際に、次のような補完処理を行う必要がある。すなわち、補完ノード「Author 」に対しては補完アクション「差し込み」を、補完ノード「Revision −Dates」に対しては補完アクション「追加」を、補完ノード「Artwork」に対しては補完アクション「差し込み可」を、補完ノード「Caption」に対しては補完アクション「追加可」を行わなければならない。
【0084】
ここで補完オートマトンとは、有限個の内部状態を持ち、入力と入力時の状態とにより次の状態に遷移していく有限オートマトンの一種である。なおオートマトンとは、初期状態を持ち、内部状態とそれに加えられる入力列とにより次の内部状態が定まる機械の数学的モデルの総称である。本発明では補完処理部27で行われる補完処理にあたって、出力文書クラスの構成要素タイプのうち下位構造を持つ全ての構成要素タイプに対して補完オートマトンを作成、適用して構造化文書を作成する。
【0085】
ここで作成される補完オートマトンは、次のような特徴を持っている。すなわち、この補完オートマトンでは入力として被補完文書のノードを読み込み、そのノードのタイプ名に基づいて次に遷移する状態を決定する。また、ノードを読まずに遷移を決定するε遷移や、読み込むノードがなくなった場合に遷移を行うω遷移を利用することができる。
【0086】
この補完オートマトンを構成する状態には、「初期状態」「通常状態」「追加状態」「開始状態」「終止状態」の5つが存在する。以下、この5つの状態について説明を行う。
【0087】
「初期状態」とはオートマトンによる処理の開始点である。全ての補完オートマトンの処理は常にこの状態から始まる。
「通常状態」とは、出力文書クラスにおいて補完処理の必要のないノードに対応する状態である。以後、タイプ名「A」を持つノードがこの状態であることを、「A状態」と呼ぶ。
【0088】
「追加状態」とは、出力文書クラスにおいて部分木の追加が必要なノードの補完処理に対応する状態である。以後、タイプ名「A」を持つノードがこの状態であることを、「A追加状態」と呼ぶ。
【0089】
「開始状態」とは、出力文書クラスにおいて、中間ノードとして差し込みが必要なノードの補完処理の開始に対応する状態である。以後、タイプ名「A」を持つノードがこの状態であることを、「A開始状態」と呼ぶ。
【0090】
「終止状態」とは、出力文書クラスにおいて、中間ノードとして差し込みが必要なノードの補完処理の終了に対応する状態である。以後、タイプ名「A」を持つノードがこの状態であることを、「A終止状態」と呼ぶ。
【0091】
なお、ここで説明した補完オートマトンを構成する5つの状態には、補完指定においてノードのタイプ名とペアになっている補完アクションが付随している。状態の遷移に伴って補完アクションを実施することにより、ノードや部分木の補完処理が行われることになる。
【0092】
ここで、先にあげた文書クラス「Technical Report 」を出力文書クラスとして作成される補完オートマトンを具体的にあげてみる。
図13は、出力文書クラス名「Technical Report 」のルートノードである「Report 」ノードの、下位構造に対する補完オートマトンを示す。この補完オートマトン310aは補完処理部27内のオートマトン作成部27aにおいて作成される。また、補完オートマトン310aは、この後に示すデータ構造310bに従って形成されている。
【0093】
補完オートマトン310aは、初期状態Initと、Header 状態と、Section状態とから構成されている。初期状態InitからHeader 状態への遷移は「Header 」ノードを読み込むことによって行われ、Header 状態からSection状態への遷移は「Section」ノードを読み込むことによって行われる。また、Section状態にある時に「Section」ノードを読み込むことで、再度Section状態へ遷移する。これは、「Section」ノードには構造制約子「REP」が付随しており、1回以上繰り返し読み込まれる可能性があるためである。
【0094】
また、Section状態は終了状態でもある。これは図7に示したように、「Report 」ノードの持つ下位構造が「Header 」ノード及び1つ以上繰り返し出現する「Section」ノードのみであることによる。
【0095】
なお、補完オートマトンを図示する場合、初期状態は「Init」の楕円で、終了状態は2重の楕円で、その他の状態は通常の楕円で表わすこととする。また、ある状態から遷移を行うときに読み込む入力ノードのタイプ名を、ラベルと呼ぶ。図13に示した補完オートマトン310aについて例をあげると、「Header 」ノードは、補完オートマトン310aの状態を初期状態InitからHeader 状態へ遷移させるラベルである。
【0096】
次に、この補完オートマトンのデータ構造について説明する。図14は、図13に示した「Report 」ノードの下位構造に対する補完オートマトン310aのデータ構造を示す。
【0097】
図に示すように、補完オートマトン310aのデータ構造310bは、出力文書リストに含まれるノードのタイプ名と、補完オートマトンを構成する各状態のリストとのペアである。
【0098】
ここで状態リストは,各状態のタイプ、対応するタイプ名、終了状態フラグ及び遷移リストから構成されている。各状態のタイプには、初期状態、通常状態、追加状態、開始状態、終止状態のいずれかが記載される。また、対応するタイプ名には、各状態に対応している出力タイプ名が1つ記載される。終了状態フラグには「T」もしくは「N」が記載され、このフラグが「T」であった場合、その状態は終了状態である。
【0099】
遷移リストは、その状態からの遷移条件のリストである。各遷移条件は遷移する時に読み込むタイプ名を示すラベルと、εフラグと、遷移先の状態へのポインタとのセットで構成されており、1つの状態リストには必ず1つ以上の遷移条件が遷移リストとして含まれている。
【0100】
この遷移条件の構成要素のうち、ラベルには、出力文書クラスに含まれるノードのタイプ名が記載されるか、ε遷移であることを示す「ε」が記載されるか、ω遷移であることを示す「ω」が記載されるか、のいずれかである。またεフラグには「T」もしくは「N」が記載されるが、このεフラグについては後で説明する。
【0101】
補完オートマトンのデータ構造の具体例であるデータ構造310bによると、文書クラス「Technical Report 」のルートノードである「Report 」ノードの下位構造に対する補完オートマトンは、3つの状態から構成されている。すなわち、対応タイプ名の存在しない初期状態と、「Header 」ノードに対応する通常状態と、「Section」ノードに対応する通常状態とである。このうち、「Section」ノードに対応する通常状態は同時に終了状態でもある。
【0102】
初期状態には遷移条件が1つだけ存在し、「Header 」ノードを読み込んだ場合にHeader 状態に遷移する。また、Header 状態には遷移条件が1つだけ存在し、「Section」ノードを読み込んだ場合にSection状態に遷移する。Section状態には遷移条件が1つだけ存在し、別の「Section」ノードを読み込んだ場合に再度Section状態に遷移する。ここで、読み込む「Section」ノードが存在しなければ、この補完オートマトンは終了する。
【0103】
ここで、補完オートマトン作成の手順について説明する。補完オートマトンを作成するということは、基礎オートマトン及び基礎オートマトンのデータ構造を作成した後、ε遷移の置き換えを行って、補完オートマトン及び補完オートマトンのデータ構造を完成させるということである。
【0104】
ここで、ε遷移について説明を行う。ε遷移とは、ノードを読み込まずに状態を遷移することを示す遷移条件である。補完処理を行うにあたっては、ノードを読み込まずに状態を遷移して補完アクションを実行する必要があり、ε遷移はこのために欠かすことのできない遷移条件である。だが一方、ε遷移の存在は、ε遷移とその他の遷移条件とが同時に存在した時や、ε遷移が複数存在した時に、遷移先が一意に決定できない原因ともなり得る。
【0105】
そのため、まずε遷移を含んだ基礎オートマトン及び基礎オートマトンのデータ構造を作成し、その後、作成した基礎オートマトン及び基礎オートマトンのデータ構造のε遷移を、別の遷移条件に置き換えて、補完オートマトン及び補完オートマトンを作成する。ε遷移を含まない補完オートマトンは基礎オートマトンと同一の形状を持つが、補完オートマトン310aはこの具体的な例である。なお、基礎オートマトンのデータ構造の遷移リストにおいてε遷移は、ラベルにεを、εフラグに「T」を記載することで表わされる。
【0106】
図15は、補完オートマトン作成の大まかな手順を示したフローチャートである。この処理は図3に示したフローチャートのステップS5にあたり、補完指定管理部26から補完指定の供給を受けた補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S51]出力文書クラスの定義情報から出力文書クラスを構成するノードのタイプ名のリストを作成する。ここで用いる定義情報は、入力データ受付部21から入力された出力文書クラス名に基づいて文書クラス管理部22に要求して得られたものである。
[S52]得られたリストからタイプ名を1つ取り出す。取り出したタイプ名はリストから削除する。
[S53]取り出したタイプ名のノードが、出力文書クラスの構造制約において下位構造を持っているか否か判断する。なお、ノードに内容が存在していても、これを下位構造とは考えない。下位構造を持っているならばステップS54へ、持っていないならばステップS57へ進む。
[S54]取り出したタイプ名を持つノードの下位構造に対する基礎オートマトンを、補完指定に基づいて作成する。この処理の詳しい手順については、この後説明する。
[S55]作成した基礎オートマトンに含まれるε遷移の置き換え処理を行い、補完オートマトンを作成する。この処理の詳しい手順については、後に説明する。
[S56]作成した補完オートマトン中に、同一ラベルを持つ遷移条件を、複数持っている状態が存在するか否か判断する。存在しなければステップS57へ、存在すればステップS58へ進む。
[S57]タイプ名を記載したリストが空であるか否か判断する。空でなければステップS52へ進む。空であれば補完オートマトンの作成は終了したということなので、この処理を終了する。
[S58]同一ラベルを持つ遷移条件を複数持っているということは、そのラベルを読み込んだとき、遷移先が一意に定まらないということである。このような状態が存在する場合、補完処理は不可能であるので、補完処理部27に補完処理不能のメッセージを出して処理を終了する。
【0107】
次に、リストから取り出したタイプ名を持つノードの、下位構造に対する基礎オートマトンを、補完指定に基づいて作成する手順について説明する。
図16は、ノードの下位構造に対する基礎オートマトン作成の手順を示したフローチャートである。この処理は図15に示したフローチャートのステップS54にあたり、補完指定管理部26から補完指定の供給を受けた、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S61]対象となっているノードの下位構造に構造制約子が付随しているか否か判断し、構造制約子REPが付随していればステップS62へ、構造制約子SEQが付随していればステップS63へ、構造制約子CHOが付随していればステップS64へ進む。また、構造制約子が付随していない場合にはステップS65へ進む。
[S62]構造制約子「REP」に対する基礎オートマトンを作成する。作成の手順についてはこの後説明するが、作成が終了したらこのフローチャートから出て図15のステップS55へ進む。
[S63]構造制約子「SEQ」に対する基礎オートマトンを作成する。作成の手順についてはこの後説明するが、作成が終了したらこのフローチャートから出て図15のステップS55へ進む。
[S64]構造制約子「CHO」に対する基礎オートマトンを作成する。作成の手順についてはこの後説明するが、作成が終了したらこのフローチャートから出て図15のステップS55へ進む。
[S65]出力文書クラスの構造制約において、対象となっているノードの下位構造に、補完が指定されているタイプ名が存在するか否か判断する。補完が指定されているタイプ名が存在しなければ、ステップS66へ進む。また、補完が指定されているタイプ名が存在した場合は、ペアになっている補完アクションを調べる。「追加」が指定されていればステップS67へ、「追加可」が指定されていればステップS68へ、「差し込み」が指定されていればステップS69へ、「差し込み可」が指定されていればステップS70へ進む。
[S66]補完アクションのない基礎オートマトンを作成する。作成の手順についてはこの後説明するが、作成が終了したらこのフローチャートから出て図15のステップS55へ進む。
[S67]補完アクション「追加」を行う基礎オートマトンを作成する。作成の手順についてはこの後説明するが、作成が終了したらこのフローチャートから出て図15のステップS55へ進む。
[S68]補完アクション「追加可」を行う基礎オートマトンを作成する。作成の手順についてはこの後説明するが、作成が終了したらこのフローチャートから出て図15のステップS55へ進む。
[S69]補完アクション「差し込み」を行う基礎オートマトンを作成する。作成の手順についてはこの後説明するが、作成が終了したらこのフローチャートから出て図15のステップS55へ進む。
[S70]補完アクション「差し込み可」を行う基礎オートマトンを作成する。作成の手順についてはこの後説明するが、作成が終了したらこのフローチャートから出て図15のステップS55へ進む。
【0108】
次に、構造制約子「REP」に対する基礎オートマトンを作成する手順について説明する。図17は、構造制約子「REP」に対する基礎オートマトン作成の手順を示したフローチャートである。この処理は図16に示したステップS62にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S81]構造制約子「REP」の下位構造に対する基礎オートマトンの作成処理を行う。つまり、処理の対象となっているノードの下位に存在する構造制約子「REP」の下位構造に対して、図16に示したフローチャートのステップS61から終了に至るまでの処理を行う。
[S82]ステップS81で作成した基礎オートマトンの全ての終了状態の遷移リストに、ステップS81で作成した基礎オートマトンの初期状態が持っている遷移リストを追加して処理を終了する。
【0109】
次に、構造制約子「SEQ」に対する基礎オートマトンを作成する手順について説明する。図18は、構造制約子「SEQ」に対する基礎オートマトン作成の手順を示したフローチャートである。この処理は図16に示したステップS63にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S91]構造制約子「SEQ」の付随している下位構造の長子にあたる構造に対する基礎オートマトン(result automaton)の作成処理を行なう。つまり、処理の対象となっているノードの下位に存在する構造制約子「SEQ」の付随している構造のうち、長子にあたる構造に対して、図16に示したフローチャートのステップS61から終了に至るまでの処理を行う。
[S92]構造制約子「SEQ」の付随している構造において、ここまでの処理で基礎オートマトンが作成されている構造に、更に弟にあたる構造が存在するか否か判断する。弟にあたる構造が存在すればステップS93へ進み、存在しなければこの処理を終了する。
[S93]ステップS92で存在を確認した構造に対する基礎オートマトン(temporal automaton)の作成処理を行う。つまり、処理の対象となっているノードの下位に存在する構造制約子「SEQ」の付随している構造のうち、ステップS92で存在を確認した構造に対して、図16に示したフローチャートのステップS61から終了に至るまでの処理を行う。
[S94]result automatonの全ての終了状態の遷移リストにtemporal automatonの初期状態が持つ遷移リストを追加する。
[S95]temporal automatonの初期状態が終了状態であるか否か判断する。終了状態であればステップS97へ、終了状態でなければステップS96へ進む。
[S96]今までresult automatonの終了状態であった状態の終了状態フラグを「N」にする。
[S97]result automatonの状態リストにtemporal automatonの初期状態以外の状態リストを追加する。
【0110】
次に、構造制約子「CHO」に対する基礎オートマトンを作成する手順について説明する。図19は、構造制約子「CHO」に対する基礎オートマトン作成の手順を示したフローチャートである。この処理は図16に示したステップS64にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S101]構造制約子「CHO」の付随している下位構造の長子にあたる構造に対する基礎オートマトン(result automaton)の作成処理を行う。つまり、処理の対象となっているノードの下位に存在する構造制約子「CHO」の付随している構造のうち、長子にあたる構造に対して、図16に示したフローチャートのステップS61から終了に至るまでの処理を行う。
[S102]構造制約子「CHO」の付随している下位構造において、ここまでの処理で既に基礎オートマトンが作成されている構造に、更に弟にあたる構造が存在するか否か判断する。弟にあたる構造が存在すればステップS103へ進み、存在しなければこの処理を終了する。
[S103]ステップS102で存在を確認した構造に対する基礎オートマトン(temporal automaton)の作成処理を行う。つまり、処理の対象となっているノードの下位に存在する構造制約子「CHO」の付随している構造のうち、ステップS102で存在を確認した構造に対して、図16に示したフローチャートのステップS61から終了に至るまでの処理を行う。
[S104]result automatonの初期状態の遷移リストに、temporal automato n の初期状態の持つ遷移リストを追加する。
[S105]temporal automatonの初期状態以外の状態リストをresult automatonの状態リストに追加する。その後、再度ステップS102に進む。
【0111】
次に、特に補完アクションのないノードに対する基礎オートマトンを作成する手順について説明する。図20は、補完アクションのない基礎オートマトン作成の手順を示したフローチャートである。この処理は図16に示したステップS66にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S111]初期状態を作成し、状態リストに、作成した初期状態を追加する。
[S112]通常状態を作成し、状態リストに、作成した通常状態を追加する。この通常状態の「対応するタイプ名」には、現在基礎オートマトン作成の対象となっているノード或は構造制約子の下位構造において、子にあたるノードのタイプ名が記載されている。
[S113]ステップS111で作成した初期状態に、ステップS112で作成した通常状態への遷移条件を追加する。この遷移条件のラベルには、ステップS112で作成した通常状態の「対応するタイプ名」に記載されているタイプ名が記載される。また、この遷移条件のεフラグには「N」が記載され、遷移先を示すポインタは作成した通常状態へ接続される。
[S114]ステップS112で作成した通常状態の終了状態フラグを「T」にする。
【0112】
次に、補完アクション「追加」を行う基礎オートマトンを作成する手順について説明する。図21は、補完アクション「追加」を行う基礎オートマトン作成の手順を示したフローチャートである。この処理は図16に示したステップS67にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S121]初期状態を作成し、状態リストに、作成した初期状態を追加する。
[S122]追加状態を作成し、状態リストに、作成した追加状態を追加する。この追加状態の「対応するタイプ名」には、現在基礎オートマトン作成の対象となっているノードの下位構造に追加するよう指定されているノードのタイプ名が記載されている。
[S123]ステップS121で作成した初期状態に、ステップS122で作成した追加状態への遷移条件を追加する。この遷移条件のラベルにはεが記載され、εフラグには「T」が記載される。また、この遷移条件の遷移先を示すポインタは作成した追加状態へ接続される。
[S124]ステップS122で作成した追加状態の終了状態フラグを「T」にする。
【0113】
次に、補完アクション「追加可」を行う基礎オートマトンを作成する手順について説明する。図22は、補完アクション「追加可」を行う基礎オートマトン作成の手順を示したフローチャートである。この処理は図16に示したステップS68にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S131]初期状態を作成し、状態リストに、作成した初期状態を追加する。
[S132]通常状態を作成し、状態リストに、作成した通常状態を追加する。この通常状態の「対応するタイプ名」には、現在基礎オートマトン作成の対象となっているノードの下位構造に追加することが可能である、と指定されているノードのタイプ名が記載されている。
[S133]ステップS131で作成した初期状態に、ステップS132で作成した通常状態への遷移条件を追加する。この遷移条件のラベルには、ステップS132で作成した通常状態の「対応するタイプ名」に記載されたタイプ名が記載される。である。また、この遷移条件のεフラグには「N」が記載され、遷移先を示すポインタはステップS132で作成した通常状態へ接続される。
[S134]ステップS132で作成した通常状態の終了状態フラグを「T」にする。
[S135]追加状態を作成し、状態リストに、作成した追加状態を追加する。この追加状態の「対応するタイプ名」には、現在基礎オートマトン作成の対象となっているノードの下位に追加することが可能である、と指定されているノードのタイプ名が記載されている。
[S136]ステップS131で作成した初期状態に、ステップS135で作成した追加状態への遷移条件を追加する。この遷移条件のラベルにはεが記載される。また、この遷移条件のεフラグには「T」が記載され、遷移先を示すポインタはステップS135で作成した追加状態へ接続される。
[S137]ステップS135で作成した追加状態の終了状態フラグを「T」にする。
【0114】
次に、補完アクション「差し込み」を行う基礎オートマトンを作成する手順について説明する。図23は、補完アクション「差し込み」を行う基礎オートマトン作成の手順を示したフローチャートである。この処理は図16に示したステップS69にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S141]差し込みを指定されているタイプ名のノードの下位構造に対する基礎オートマトンの作成処理を行う。つまり、処理の対象となっているノードの下位構造に差し込むよう指定されているタイプ名に対して、図16に示したフローチャートのステップS61から終了に至るまでの処理を行う。
[S142]開始状態を作成し、状態リストへ、作成した開始状態を追加する。この開始状態の「対応するタイプ名」には、差し込みを行うよう指定されているノードのタイプ名が記載されている。
[S143]初期状態の持つ遷移リストを、ステップS142で作成した開始状態の遷移リストにコピーする。
[S144]初期状態の持つ遷移リストをクリアする。
[S145]初期状態の持つ遷移リストに、ステップS142で作成した開始状態への遷移条件を追加する。この遷移条件のラベルにはεが記載される。また、この遷移条件のεフラグには「T」が記載され、遷移先を示すポインタはステップS142で作成した開始状態へ接続される。
[S146]終止状態を作成し、状態リストへ、作成した終止状態を追加する。この終止状態の「対応するタイプ名」には、差し込みを行うよう指定されているノードのタイプ名が記載されている。
[S147]全ての終了状態に、ステップS146で作成した終止状態への遷移条件を追加する。この遷移条件のラベルにはεが記載される。また、この遷移条件のεフラグには「T」が記載され、遷移先を示すポインタはステップS146で作成した終止状態へ接続される。
[S148]全ての終了状態の終了状態フラグを「N」にする。
[S149]ステップS146で作成した終止状態の終了状態フラグを「T」にする。
【0115】
次に、補完アクション「差し込み可」を行う基礎オートマトンを作成する手順について説明する。図24は、補完アクション「差し込み可」を行う基礎オートマトン作成の手順を示したフローチャートである。この処理は図16に示したステップS70にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S151]差し込み可を指定されているタイプ名のノードの下位構造に対する基礎オートマトンの作成処理を行う。つまり、処理の対象となっているノードの下位構造に差し込むことが可能である、と指定されているタイプ名に対して、図16に示したフローチャートのステップS61から終了に至るまでの処理を行う。
[S152]開始状態を作成し、状態リストに、作成した開始状態を追加する。この開始状態の「対応するタイプ名」には、差し込み可と指定されているノードのタイプ名が記載されている。
[S153]初期状態の持つ遷移リストを、ステップS152で作成した開始状態の遷移リストにコピーする。
[S154]初期状態の持つ遷移リストをクリアする。
[S155]初期状態の持つ遷移リストに、ステップS152で作成した開始状態への遷移条件を追加する。この遷移条件のラベルにはεが記載される。また、この遷移条件のεフラグには「T」が記載され、遷移先を示すポインタはステップS152で作成した開始状態へ接続される。
[S156]終止状態を作成し、状態リストに、作成した終止状態を追加する。この終止状態の「対応するタイプ名」には、差し込み可、と指定されているノードのタイプ名が記載されている。
[S157]全ての終了状態に、ステップS156で作成した終止状態への遷移条件を追加する。この遷移条件のラベルにはεが記載される。また、この遷移条件のεフラグには「T」が記載され、遷移先を示すポインタはステップS156で作成した終止状態へ接続される。
[S158]全ての終了状態の終了状態フラグを「N」にする。
[S159]ステップS157で作成された終止状態の終了状態フラグを「T」にする。
[S160]通常状態を作成し、状態リストに、作成した通常状態を追加する。この通常状態の「対応するタイプ名」には、差し込み可、と指定されているノードのタイプ名が記載されている。
[S161]初期状態の持つ遷移リストに、ステップS160で作成した通常状態への遷移条件を追加する。この遷移条件のラベルにはステップS160で作成した通常状態の「対応するタイプ名」に記載されたタイプ名が記載される。また、この遷移条件のεフラグには「N」が記載され、遷移先を示すポインタはステップS160で作成した通常状態へ接続される。
[S162]ステップS160で作成した通常状態の終了状態フラグを「T」にする。
【0116】
本発明では以上のような手順で基礎オートマトンを作成する。
ここで、図11に示した被補完文書構造210を補完する補完オートマトンの原形となる基礎オートマトンを作成してみる。この被補完文書構造210は元々、図8に示すように文書クラス「技術メモ」に従った文書構造110であったが、図9に示した変換規則200に基づいて文書クラス「Technical Report 」に従うよう変換を行った結果、図7に示す文書クラス「Technical Report 」の構造制約502にほぼ従った文書構造となったものである。なお、基礎オートマトンを作成するにあたって必要となる補完規則には、図12に示した補完規則300を利用する。
【0117】
図25は、出力文書クラス名「Technical Report 」の「Report 」ノードの下位構造に対する基礎オートマトンを示す。この基礎オートマトン320は、「Author 」ノードの差し込みと、「Revision −Dates」ノードの追加とを行う。なお、この基礎オートマトン320は図2に示す補完処理部27内のオートマトン作成部27aにおいて作成される。
【0118】
基礎オートマトン320は、初期状態Initと、Report −Title状態と、Author 開始状態と、Name 状態と、Address状態と、Author 終止状態と、Revision −Dates追加状態とから構成されている。
【0119】
ここで、初期状態InitからReport −Title状態への遷移は「Report −Title」ノードを読み込むことによって行われ、Report −Title状態からAuthor 開始状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0120】
また、Author 開始状態からName 状態への遷移は「Name 」ノードを読み込むことによって行われ、Name 状態からAddress状態への遷移は「Address」ノードを読み込むことによって行われる。
【0121】
更に、Address状態からAuthor 終止状態への遷移と、Author 終止状態からRevision −Dates追加状態への遷移とは、ε遷移、すなわち何も読み込まれずに行われる。
【0122】
Revision −Dates追加状態はまた、終了状態でもある。これは図7に示したように、「Report 」ノードの持つ下位構造が、「Report −Title」ノードと、「Author 」ノードと、「Name 」ノードと、「Address」ノードと、「Author 」ノードと、「Revision −Dates」ノードとから構成されていることによる。
【0123】
また、図26は、出力文書クラス名「Technical Report 」の「Artwork」ノードの下位構造に対する基礎オートマトンを示す。この基礎オートマトン330は、「Caption」ノードの「追加可」の補完を行う。なお、この基礎オートマトン330は図2に示す補完処理部27内のオートマトン作成部27aにおいて作成される。
【0124】
基礎オートマトン330は、初期状態Initと、Caption状態と、Caption追加状態と、Figure 状態とから構成されている。
ここで、初期状態InitからCaption状態への遷移は「Caption」ノードを読み込むことによって行われ、Caption状態からFigure 状態への遷移は「Figure 」ノードを読み込むことによって行われる。また、初期状態InitからCaption追加状態への遷移はε遷移、すなわち何も読み込まず行われ、Caption追加状態からFigure 状態への遷移は「Figure 」ノードを読み込むことによって行われる。
【0125】
Figure 状態はまた、終了状態でもある。これは図7に示したように、「Artwork」ノードの持つ下位構造が「Caption」ノード及び「Figure 」ノードのみであることによる。
【0126】
更に、図27は、出力文書クラス名「Technical Report 」の「Section」ノードの下位構造に対する基礎オートマトンを示す。この基礎オートマトン340は、「Artwork」ノードの「差し込み可」、及び「Caption」ノードの「追加可」の補完を行う。ここで、「Artwork」ノードは図26にて基礎オートマトン330に示したように「Caption」ノードの「追加可」の補完を含んでいる。なお、この基礎オートマトン340は図2に示す補完処理部27内のオートマトン作成部27aにおいて作成される。
【0127】
基礎オートマトン340は、初期状態Initと、Title状態と、Artwork状態と、Paragraph状態と、Artwork開始状態と、Caption状態と、Caption追加状態と、Figure 状態と、Artwork終止状態とから構成されている。
【0128】
ここで、初期状態InitからTitle状態への遷移は「Title」ノードを読み込むことで行われる。
Title状態からの、Artwork状態への遷移は「Artwork」ノードを読み込むことで、Paragraph状態への遷移は「Paragraph」ノードを読み込むことで行われる。また、Title状態からArtwork開始状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0129】
Artwork状態からの、Paragraph状態への遷移は「Paragraph」ノードを読み込むことで、Artwork状態への遷移は「Artwork」ノードを読み込むことで行われる。また、Artwork状態からArtwork開始状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0130】
Paragraph状態からの、Paragraph状態への遷移は「Paragraph」ノードを読み込むことで、Artwork状態への遷移は「Artwork」ノードを読み込むことで行われる。また、Artwork開始状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0131】
Artwork開始状態からの、Caption状態への遷移は「Caption」ノードを読み込むことで行われ、Caption追加状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0132】
Caption状態からFigure 状態への遷移は「Figure 」ノードを読み込むことで行われる。Caption追加状態からFigure 状態への遷移もまた、「Figure 」ノードを読み込むことで行われる。Figure 状態からArtwork終止状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0133】
Artwork終止状態からの、Artwork状態への遷移は「Artwork」ノードを読み込むことで、Paragraph状態への遷移は「Paragraph」ノードを読み込むことで行われる。また、Artwork終止状態からArtwork開始状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0134】
Paragraph状態、Artwork状態はまた、終了状態でもある。これは図7に示したように、「Section」ノードの持つ下位構造が「Title」ノード及び、1つ以上繰り返し出現する「Paragraph」ノードもしくは「Artwork」ノードのみから構成されていることによる。つまり、「Paragraph」ノードもしくは「Artwork」ノードの出現が、「Section」ノードの構造制約を満たすことになる。
【0135】
Artwork終止状態もまた、終了状態でもある。これは、Artwork状態が終了状態であることから、「Artwork」ノードの差し込みもまた、「Section」ノードの構造制約を満たすことになるためである。
【0136】
次に、作成した基礎オートマトンに含まれるε遷移の置き換え処理の手順について説明する。
これまでに説明した手順で作成した基礎オートマトンにはε遷移、すなわち何も読み込まずに遷移する場合が数多く含まれている。このままでは、ε遷移と他の遷移との、あるいはε遷移同士の競合が起こり、効率的な補完ができない。そこで、読み込まれたノードのタイプ名に基づいて、ε遷移を行うべきか、それ以外の遷移を行うべきか、もしくは複数のε遷移の中でもどの遷移を行うべきかを決定できるよう、ε遷移に次に示すような置き換え処理を施し、補完オートマトンを作成する。
【0137】
図28は、ε遷移の置き換え処理の手順を示したフローチャートである。この処理は図15に示したフローチャートのステップS55にあたり、補完処理部27内のオートマトン作成部27aにおいて基礎オートマトン作成に続いて実行される。以下、図中のステップ番号に沿って説明を行う。
[S201]作成した基礎オートマトンのデータ構造から、ε遷移を持つ(ラベルがεであり、εフラグが「T」である遷移リストを持つ)状態を選び出し、εリストを作成する。
[S202]作成した基礎オートマトンのデータ構造から、ε遷移を持たない状態を選び出し、non−εリストを作成する。
[S203]εリストが空であるか否か判断する。空でなければステップS204へ、空であればステップS208へ進む。
[S204]non−εリストが空であるか否か判断する。空でなければステップS205へ、空であればステップS208へ進む。
[S205]non−εリストによるεリストの要素が持つε遷移の置き換え処理を行う。この処理の手順についてはこの後で説明する。
[S206]εリストの要素から、ε遷移が無くなった(遷移条件の全てのラベルに、ε以外の記載がされている)状態を選び出し、新たな non− εリストとする。
[S207]εリストの要素から、まだε遷移を持つ状態を選び出し、新たなεリストとする。ステップS203へ進み、新たなεリストと、新たな non− εリストとについて、ε遷移の置き換え処理を行う。
[S208]作成した補完オートマトンに、ω遷移を持つ終了状態が存在するか否か判断する。存在すればステップS209へ進み、存在しなければε遷移の置き換えは正常に終了しているので、このフローチャートを出て図15のステップS56へ進む。
[S209]ω遷移を持つ終了状態が存在するとき、もしくはεリストが空でないのに non− εリストが空であるとき、ε遷移の置き換えは失敗である。補完処理不能のメッセージを出力し、図15のステップS56へ進む。
【0138】
次に、non−εリストによるεリストの要素が持つε遷移の置き換え処理の手順を説明する。図29は、non−εリストによるεリストの要素が持つε遷移の置き換えの手順を示すフローチャートである。この処理は図28に示したフローチャートのステップS205にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S211]εリストの最初の要素を current状態とする
[S212] current状態の遷移リストが空であるか否か判断する。空であればステップS214へ、空でなければステップS213へ、進む。
[S213]non−εリストによる、 current状態が持つε遷移の置き換え処理を行う。この処理の手順についてはこの後で説明する。
[S214] current状態がεリストの最後尾であるか否か判断する。最後尾であればこの処理は終了である。最後尾でなければステップS215へ進む。
[S215]εリストの current状態の次の状態を、新たな current状態としてステップS212へ進む。
【0139】
次に、non−εリストによる current状態が持つε遷移の置き換え処理の手順を説明する。図30は、non−εリストによる current状態が持つε遷移の置き換えの手順を示すフローチャートである。この処理は図29に示したフローチャートのステップS213にあたり、補完処理部27内のオートマトン作成部27aにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S221] current状態の遷移リストの先頭の遷移条件を、 current遷移とする。
[S222] current遷移がε遷移であるか否か判断する。ε遷移であればステップS223へ進み、ε遷移でなければステップS228へ進む。
[S223] current遷移の遷移先である状態が、non−εリストの要素であるか否か判断する。non−εリストの要素であればステップS224へ、non−εリストの要素でなければステップS228へ進む。
[S224] current遷移の遷移先の状態が持つ遷移リストをコピーして、 current状態の遷移リストに追加する。その際、εフラグを「T」に変更し、遷移先を示すポインタは current遷移の遷移先へ接続する。
[S225] current遷移の遷移先の状態が終了状態である(終了状態フラグが「T」である)か否か判断する。終了状態であればステップS226へ、終了状態でなければステップS227へ進む。
[S226] current状態の遷移リストにω遷移を追加する。このω遷移は、ラベルにω、εフラグに「T」を持ち、遷移先を示すポインタが current遷移の遷移先に接続されている遷移条件である。
[S227] current遷移を current状態の遷移リストから削除する。
[S228]遷移リスト内に次の遷移条件が存在するか否か判断する。次の遷移が存在しなければ、この処理は終了する。また、次の遷移が存在すればステップS229へ進む。
[S229]ステップS228で存在が確認された遷移条件をcurrent 遷移とし、ステップS222へ進む。
【0140】
以上のような手順で、ε遷移が置き換えられる。つまりε遷移は、そのε遷移から到達可能な状態の持つ遷移条件に置き換えられ、タイプ名のラベルを得る。置き換えられた遷移条件は、元々ε遷移であったことが判別できるようεフラグを「T」にしてある。また、そのε遷移から到達可能な状態が終了状態であった場合、読み込むノードが存在しなくても遷移を行えるよう、ω遷移も遷移リストに加えられる。
【0141】
ここで、基礎オートマトンにε遷移の置き換え処理を施した例をあげる。
図31は、図25にて示した基礎オートマトン320にε遷移の置き換え処理を施して作成した補完オートマトン420を示す。
【0142】
補完オートマトン420は、初期状態Initと、Report −Title状態と、Author 開始状態と、Name 状態と、Address状態と、Author 終止状態と、Revision −Dates追加状態とから構成されている。
【0143】
ここで、基礎オートマトンではε遷移であったReport −Title状態からAuthor 開始状態への遷移は、「Name 」ノードを読み込むことによって行われる。また、Address状態からAuthor 終止状態への遷移と、Author 終止状態からRevision −Dates追加状態への遷移とは、ω遷移によって行われる。このω遷移の存在によって、読み込むノードが存在しなくてもRevision −Dates開始状態への遷移が可能となり、「Revision −Dates」ノードの追加が行える。
【0144】
なお、ε遷移の置き換え処理を行った際、元々ε遷移であった遷移条件のεフラグを「T」にすることで、置き換え処理の対象であったか否かを判断できるようにした。元々ε遷移であった遷移条件による遷移を、この図ではラベルに下線を引くことで表わしている。また、これ以降の補完オートマトンを示す図においても同様に、ラベルの下線でε遷移からの置き換え処理を表わす。
【0145】
図32は、図26にて示した基礎オートマトン330にε遷移の置き換え処理を施して作成した補完オートマトン430を示す。
補完オートマトン430は、初期状態Initと、Caption状態と、Caption追加状態と、Figure 状態とから構成されている。
【0146】
ここで、基礎オートマトンではε遷移であった初期状態InitからCaption追加状態への遷移は、「Figure 」ノードを読み込むことによって行われる。
図33は、図27にて示した基礎オートマトン340にε遷移の置き換え処理を施して作成した補完オートマトン440を示す。
【0147】
補完オートマトン440は、初期状態Initと、Title状態と、Artwork状態と、Paragraph状態と、Artwork開始状態と、Caption状態と、Caption追加状態と、Figure 状態と、Artwork終止状態とから構成されている。
【0148】
ここで、基礎オートマトンではε遷移であった、Title状態からArtwork開始状態への遷移は、「Caption」ノードを読み込むか、又は「Figure 」ノードを読み込むか、どちらかの場合に行われる。また、Artwork状態からArtwork開始状態への遷移は「Caption」ノードを読み込むか、又は「Figure 」ノードを読み込むか、どちらかの場合に行われる。
【0149】
Paragraph状態からArtwork開始状態への遷移は「Caption」ノードを読み込むか、又は「Figure 」ノードを読み込むか、どちらかの場合に行われる。Artwork開始状態からCaption追加状態への遷移は「Figure 」ノードを読み込むことで行われる。
【0150】
Figure 状態からArtwork終止状態への遷移は「Caption」ノードを読み込むか、「Figure 」ノードを読み込むか、「Artwork」ノードを読み込むか、「Paragraph」ノードを読み込むか、何れかによって行われる。また、Figure 状態からArtwork終止状態への遷移は、ω遷移、すなわち、読み込むノードが存在しない時にも行われる。このω遷移の存在によって、Figure 状態において読み込むノードが無くてもArtwork終止状態への遷移が可能となり、この補完オートマトンの終了状態へ到達できる。
【0151】
更に、Artwork終止状態からArtwork開始状態への遷移は「Caption」ノードを読み込むか、又は「Figure 」ノードを読み込むか、どちらかの場合に行われる。
【0152】
次に、作成した補完オートマトンを利用して,被補完文書の文書構造に補完処理を施す手順について説明する。図34は、補完処理の大まかな手順を示したフローチャートである。この処理は図3に示したフローチャートのステップS6にあたり、図2に示した補完処理部27内のオートマトン適用部27bにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S231]被補完文書の文書構造においてルートノードの子として存在しているノードの列を、入力ノード列とする。また、作成する文書構造において対応するルートノードに子として追加していくノードの列を、出力ノード列とする。
[S232]作成した補完オートマトンのうち、ルートノードの下位構造に対する補完オートマトンの状態リストにある初期状態を current状態とする。
[S233]入力ノード列が空であるか否か判断する。空でなければステップS234へ、空であればステップS240へ進む。
[S234]入力ノード列の先頭のノードを currentノードとする。
[S235] current状態にある時に、 currentノードを読み込むことで状態が遷移するか否か判断する。遷移するならばステップS236へ、遷移しないならばステップS243へ、進む。ここで currentノードを読み込んで遷移するか否かを判断するには current状態の遷移リストを調べれば良い。この場合、入力ノード列が空でないことは既に確認されており、ω遷移が行われることはない。よって、 current状態の遷移リストにcurrent ノードの持つタイプ名がラベルとして記載された遷移情報があれば、 current状態はその遷移情報に基づいて遷移することが判る。
[S236]ステップS235において存在を確認した、 currentノードを読み込んで遷移する遷移先の状態を新たな current状態として、ステップS237へ進む。
[S237]ここまでの処理で得られた current状態について current状態固有の処理を行う。この処理の手順については、この後で説明する。
[S238]ステップS237に至るまでの手順において、新しい current状態へ遷移するために使用した遷移条件のεフラグが「T」であるか否か判断する。「T」でなく「N」であればステップS239へ、「T」であればステップS233へ、進む。
[S239]遷移条件のεフラグが「N」であったということは、 currentノードの持つタイプ名を、この後の処理において、遷移条件のラベルとして使用する必要がないということである。よって、入力ノード列から currentノードを削除する。
[S240] current状態が終了状態であるか否か判断する。終了状態であればこの補完処理は正常に終了したということなので、このフローチャートを出て、図3のステップS7へ進む。終了状態でなければステップS241へ進む。
[S241] current状態の遷移リストに、ω遷移が存在するか否か判断する。ω遷移が存在すればステップS242へ進む。ω遷移が存在しなければ、ステップS243へ進む。
[S242]ステップS241で存在を確認した、ω遷移に基づいて遷移した時の遷移先の状態を、新たな current状態として、ステップS237へ進む。
[S243]まだ終了状態に至っていないにも拘わらず状態遷移ができなくなってしまったので、補完処理不能のメッセージを出力して、処理を終了する。
【0153】
ここで、 current状態固有の処理の手順について説明する。図35は、 current状態固有の処理の手順を示したフローチャートである。この処理は図34に示したフローチャートのステップS237にあたり、図2に示した補完処理部27内のオートマトン適用部27bにおいて実行される。以下、図中のステップ番号に沿って説明を行う。
[S251] current状態がどんな状態であるか判断する。すなわち、通常状態であるか、追加状態であるか、開始状態であるか、終止状態であるかを current状態の状態タイプを調べて判断する。 current状態が、通常状態であればステップS252へ、追加状態であればステップS253へ、開始状態であればステップS254へ、終止状態であればステップS255へ進む。
[S252] currentノードのコピーを作成し、現在の出力ノード列の最後尾に追加する。
「S253]追加される部分木を作成し、その部分木のルートノードを出力ノード列の最後尾に追加する。ここで作成する部分木は、補完指定において補完アクション「追加」とペアで記憶されていたタイプ名を持つノードをルートとする、出力文書クラスの構造制約を満たした部分木である。
[S254]現在の出力ノード列をノード列スタック(ノード列を一時的に記憶しておく領域であって、LIFO、すなわち最後に記憶させたデータが最初に取り出される性質を持つ)に push (スタックにデータを入れること)し、空のノード列を作成して、出力ノード列とする。
[S255]差し込むノードを作成して、出力ノード列を、作成されたノードの子ノード列とする。ここで作成するノードは、終止状態に対応するタイプ名を持つノードである。
[S256]ノード列スタックからノード列を1つ pop(スタックからデータを取り出すこと)し、出力ノード列とする。
[S257]ステップS255において作成したノードを出力ノード列の最後尾に追加する。
【0154】
以上のような手順で補完処理を行うことで、被補完文書の文書構造を希望の文書クラスに従った文書構造とすることができる。図36は、図11にて示した被補完文書構造210に、図31にて示した補完オートマトン420、図32にて示した補完オートマトン430、図33にて示した補完オートマトン440を適用して作成した文書構造を示す。
【0155】
文書構造509は、図8に示した「技術メモ」の文書データの文書構造解析結果110のノードの持つ内容を全て持っており、なおかつ文書クラス「Technical Report 」に完全に従った構成となっている。なお、この図において点線で示した部分は被補完文書構造210に含まれていた部分であり、実線で示した部分が補完処理によって補う部分である。原文書に含まれていないデータを新たに作成することは本発明の目的ではないので、補完したノードが内容を持つものであった場合には空欄を設けてある。
【0156】
次に、完成させた構造化文書がどのような文書構造を持つか示す。図37は、図8に示した文書クラス「技術メモ」の文書データの文書構造解析結果110を、文書クラス「Technical Report 」に適合するように変換した適合文書構造である。
【0157】
適合構造化文書510は、図6にて示した文書クラス「Technical Report 」のノードのタイプ定義501と、図7にて示したノードの接続関係を規定する構造制約502とを完全に満たす。
【0158】
以上に示したような文書構造作成装置を用いることにより、文書全体の構造から補完の仕方が決定でき、適切な構造化文書を得ることができる。すなわち、補完処理にあたる補完オートマトンは、被補完文書のノードの接続関係を全て把握しており、個々の関係を確認した上で補完処理を行うので、文書構造の一部の補完が他の部分に悪影響を及ぼすことはない。また、大規模な文書や複雑な構造を持つ文書等への、人手で行うことの困難な補完処理も可能である。
【0159】
更に、この文書構造作成装置ではユーザが補完指定を行うこともできるので、質の悪い補完結果が出現した場合に補完指定をやり直すことができる。補完の仕方は一般に複数存在するので、ユーザは補完の仕方を選択し、質の良い構造化文書を得ることができる。
【0160】
次に、本発明の第2の実施の形態の詳しい構成を説明する。図38は文書構造作成装置の第2の実施の形態の構成を示すブロック図である。なお、この第2の実施の形態の構成は、図2に示す第1の実施の形態の構成と基本的には同じである。
【0161】
本発明の文書構造作成装置30は、ユーザから入出力i/f10を介して構造化文書の作成に必要なデータを入力され、入力されたデータから構造化文書を作成し、作成した構造化文書を入出力i/f10を介してユーザに出力する。
【0162】
ここで必要になるデータは、第1の実施の形態の文書構造作成装置で必要になったデータ同様、原文書データと、入力文書クラス名と、出力文書クラス名とである。また、補完指定も行うことができる。
【0163】
文書構造作成装置30は、入力データを受け付ける入力データ受付部31と、文書クラスの定義情報を管理している文書クラス管理部32と、入力された原文書データを解析する文書構造解析部33と、異なる文書クラス間の変換規則を管理している変換規則管理部34と、文書構造の変換を行う文書構造変換部35と、補完指定を管理している補完指定管理部36と、補完処理を行う補完処理部37と、補完処理の施された文書構造を構造化文書データに変換して出力する文書データ生成部38と、補完指定の検査を行う補完指定検査部39とから構成されている。
【0164】
入力データ受付部31は、入出力i/f10を介してデータの入力を受け付けると、原文書データを文書構造解析部33へ、入力文書クラス名を文書構造解析部33、変換規則管理部34、補完指定管理部35へ、出力文書クラス名を変換規則管理部34、補完指定管理部36、補完処理部37内のオートマトン作成部37a、補完指定検査部39へ、それぞれ入力する。
【0165】
文書クラス管理部32は、この文書構造作成装置30で扱える文書クラスの定義情報を全て記憶・管理しており、各部の要求に応じて定義情報の供給を行う。なお、この図における文書クラス管理部32への文書クラス定義情報の要求、及び文書クラス管理部32からの文書クラス定義情報の供給の流れは、破線で示してある。
【0166】
文書構造解析部33は、入力された入力文書クラス名を認識し、文書クラス管理部32に該当する文書クラスの定義情報を要求する。定義情報の供給を受けた後、原文書データを定義情報と照合し、論理的な構造を調べ、原文書データの構成要素と入力文書クラスの構成要素タイプとの対応関係を文書構造変換部35へ送る。
【0167】
変換規則管理部34は、この文書構造作成装置30で扱える複数の文書クラスの各々に対し、該文書クラスを入力文書クラスとして文書クラスの変換を行う際、該文書クラスの構成要素タイプを、出力文書クラスとされた文書クラスの構成要素タイプにどのように変換するかを定めた変換規則を全て記憶、管理している。そして、入力文書クラス名と出力文書クラス名とが入力されると、2つの文書クラス名に対応する変換規則を文書構造変換部35に供給する。
【0168】
文書構造変換部35は、文書構造解析部33からは原文書データの構成要素と入力文書クラスの構成要素タイプとの対応関係を、変換規則管理部34からは入力文書クラスから出力文書クラスへの変換規則を、それぞれ供給される。その後、供給された変換規則に基づいて原文書データの変換を行い、被補完文書データを作成する。被補完文書データは補完処理部37へ送られる。
【0169】
補完指定管理部36は、この文書構造作成装置30で扱える文書クラスの構成要素に対し、入力文書クラス名と出力文書クラス名とに基づいて、どのような補完を行うかを指定する補完指定を記憶、管理している。そして、入力文書クラス名と出力文書クラス名とが入力されると、2つの文書クラス名に対応する補完指定を補完処理部37に供給する。なお、ユーザはこの補完指定を必要に応じて作成、更新することができる。この場合ユーザは、入力データとして原文書データや入力文書クラス名、出力文書クラス名と併せて、補完指定も入力することになる。
【0170】
補完指定検査部39は、補完指定管理部36にて管理されている補完指定が、出力文書クラスの定義情報と照らし合わせて矛盾していないかどうか、検査を行う。すなわち、入力データ受付部31から入力された出力文書クラス名に基づいて文書クラス管理部32に出力文書クラスの定義情報を要求し、この情報と補完指定との整合性を取る。また、後述する補完処理部37内のオートマトン作成部37aから補完オートマトンを読み出し、この補完オートマトンと出力文書クラスの定義情報との間に矛盾が生じていないかどうか判断する。ここでなされた補完指定及び補完オートマトンが正常であるか否かの判断の結果は、補完処理部37に通知される。また、補完指定もしくは補完オートマトンと出力文書クラスの定義情報との間に矛盾が生じている場合には、補完処理が正常に行えないことを入出力i/f10を介してユーザに通知する。
【0171】
補完処理部37は、オートマトン作成部37aとオートマトン適用部37bとから構成されており、オートマトンと呼ばれる状態遷移機械を利用して被補完文書の補完処理を行う。オートマトン作成部37aは、入力データ受付部31から入力された出力文書クラス名に基づいて、文書クラス管理部33に出力文書クラスの定義情報を要求し、この情報と補完指定管理部36から供給された補完指定とを基に補完オートマトンを作成する。オートマトン適用部37bは、補完指定検査部39から補完指定及び補完オートマトンが正常であるとの通知を受けると、オートマトン作成部37aで作成した補完オートマトンを利用して被補完文書を補完し、出力文書クラスに従った文書構造を作成する。また、補完指定もしくは補完オートマトンが正常でないとの通知を受けた場合には、補完処理を行わずに構造化文書の作成を中止する。
【0172】
文書データ生成部38は、補完処理部37で作成された構造化文書を文書データにし、入出力i/f10を介してユーザに出力する。
次に、この文書構造作成装置30を用いて構造化文書の作成を行う手順を説明する。図39は構造化文書の作成手順を示すフローチャートである。以下、図中のステップ番号に沿って説明を行う。
[S301]入力データ受付部31は、入出力i/f10を介して入力データを受け付ける。入力データとなるものは原文書データと、入力文書クラス名と、出力文書クラス名とである。また、ユーザの希望があれば補完指定も受け付ける。[S302]文書構造解析部33において、原文書データを入力文書クラスの定義情報に基づいて解析し、文書構造を抽出する。文書解析にあたり必要となる定義情報は、入力データ受付部31から入力された入力文書クラス名を基に文書クラス管理部32に要求して得られたものである。
[S303]変換規則管理部34は、入力文書クラス名及び出力文書クラス名より変換規則を決定し、文書構造変換部35に供給する。文書構造変換部35は、供給された変換規則に基づいて原文書の文書構造を変換し、被補完文書を作成する。ここで行われる変換処理は、第1の実施の形態で行った変換処理と同一のものである。
[S304]補完指定管理部36は、補完指定を決定し、補完指定検査部39と補完処理部37とに供給する。補完指定には、ユーザからの指定が入力データに含まれていればその補完指定を、含まれていなければ入力文書クラス名及び出力文書クラス名より選択される補完指定を、利用する。
[S305]補完指定の供給を受けた補完指定検査部39は、入力された出力文書クラス名に基づいて出力文書クラスの定義情報を文書クラス管理部32に要求し、得られた定義情報から補完指定が正常であるか否か検査を行う。つまり、補完の指定されているノードのタイプが全て、出力文書クラスの定義情報中に含まれているか否かを判断する。
[S306]ステップS5における検査の結果は、補完指定検査部39から補完処理部37内のオートマトン作成部37aへ通知される。ここで補完指定が正常であると判断されれば、処理はステップS307へ進む。また、補完指定が正常でないと判断されれば、処理はステップS312へ進む。
[S307]補完処理部37内のオートマトン作成部37aは、出力文書クラスの定義情報と供給された補完指定とを基に、補完オートマトンを作成する。ここで行われれる補完オートマトン作成処理は、第一の実施の形態で行った補完オートマトン作成処理と同一のものである。
[S308]補完指定検査部39は、ステップS307においてオートマトン作成部37aの作成した補完オートマトンを読み出し、正常であるか否か検査を行う。つまり、補完するノードや部分木及びその位置が一意に決まらないような指定がされていないか否かを判断する。
[S309]ステップS308における検査の結果は、補完指定検査部39から補完処理部37内のオートマトン適用部37bへ通知される。ここで補完オートマトンが正常であると判断されれば、処理はステップS310へ進む。また、補完オートマトンが正常でないと判断されれば、処理はステップS312へ進む。
[S310]補完処理部39内のオートマトン適用部37bは、補完オートマトンを実際に動作させ、被補完文書に補完を行って構造化文書を作成する。作成した構造化文書は文書データ生成部38へ送る。ここで行われる構造化文書作成処理は、第一の実施の形態で行った構造化文書作成処理と同一のものである。
[S311]文書データ生成部38は送られた構造化文書から文書データを生成し、入出力i/fを介してユーザに出力する。
[S312]補完指定もしくは補完オートマトンが正常でない場合、構造化文書を正しく作成することは不可能である。入出力i/f10を介してユーザに補完指定が正しくないことを通知して、この処理を終了する。
【0173】
ここで、補完指定管理部36が誤った補完指定を決定した場合にどのようなことが起こるのか説明する。
図40は、入力文書クラス名「技術メモ」、出力文書クラス名「Technical Report 」に対する誤った補完指定である。この補完指定600は入力文書クラス名「技術メモ」及び出力文書クラス名「Technical Report 」とセットで、補完指定管理部36に記憶されており、両文書クラス名の入力に伴って補完処理部37内のオートマトン作成部37aへ供給される。
【0174】
この補完指定600によれば、文書クラス「技術メモ」の文書データを文書クラス「Technical Report 」の文書データに変換した後、構造化文書を作成するための補完オートマトンを作成する際に、次のような補完処理を行う必要がある。すなわち、補完ノード「Section」に対しては補完アクション「差し込み」を、補完ノード「Title」に対しては補完アクション「追加可」を行わなければならない。
【0175】
ここで、図40に示した補完指定600に基づいて補完オートマトンを作成する。図41は、図40に示した補完指定600に基づいて作成した、文書クラス「Technical Report 」のルートノードである「Report 」ノードの下位構造に対する基礎オートマトンである。この基礎オートマトン610は、「Section」ノードの差し込みと、「Title」ノードの追加可とを行う。なお、この基礎オートマトン610は図38に示す補完処理部37内のオートマトン作成部37aにおいて作成される。 基礎オートマトン610は、初期状態Initと、Header 状態と、Section開始状態と、Title状態と、、Title追加状態と、Paragraph状態と、Artwork状態と、Section終止状態とから構成されている。
【0176】
ここで、初期状態InitからHeader 状態への遷移は「Header 」ノードを読み込むことで行われ、Header 状態からSection開始状態への遷移はε遷移、すなわち何も読み込まずに行われる。また、Section開始状態からの、Title状態への遷移は「Title」ノードを読み込むことで行われ、Title追加状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0177】
Title状態からの、Paragraph状態への遷移は「Paragraph」ノードを読み込むことで、Artwork状態への遷移は「Artwork」ノードを読み込むことで、行われる。また、Title追加状態からの、Paragraph状態への遷移は「Paragraph」ノードを読み込むことで、Artwork状態への遷移は「Artwork」ノードを読み込むことで、行われる。
【0178】
Paragraph状態からの、Paragraph状態への遷移は「Paragraph」ノードを読み込むことで、Artwork状態への遷移は「Artwork」ノードを読み込むことで、行われ、Section終止状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0179】
また、Artwork状態からの、Paragraph状態への遷移は「Paragraph」ノードを読み込むことで、Artwork状態への遷移は「Artwork」ノードを読み込むことで行われ、Section終止状態への遷移はε遷移、すなわち何も読み込まずに行われる。
【0180】
さらに、Section終止状態からSection開始状態への遷移はε遷移、すなわち何も読み込まずに行われる。
Section終止状態はまた、終了状態でもある。これは図7に示したように、「Report 」ノードの持つ下位構造が「Header 」ノード及び、1つ以上繰り返し出現する「Section」ノードのみであることによる。つまり、「Section」ノードの出現が、「Report 」ノードの構造制約を満たすことになる。
【0181】
次に、基礎オートマトンにε遷移の置き換え処理を施して、補完オートマトンを作成する。図42は、図41に示した基礎オートマトンにε遷移の置き換え処理を施して作成した補完オートマトンである。この補完オートマトン710は、「Section」ノードの差し込みと、「Title」ノードの追加可とを行う。なお、この補完オートマトン710は図38に示す補完処理部37内のオートマトン作成部37aにおいて作成される。
【0182】
補完オートマトン710は、初期状態Initと、Header 状態と、Section開始状態と、Title状態と、Title追加状態と、Paragraph状態と、Artwork状態と、Section終止状態とから構成されている。
【0183】
ここで、基礎オートマトンではε遷移であったHeader 状態からSection開始状態への遷移は「Paragraph」ノードか、「Artwork」ノードか、「Title」ノードか、何れかを読み込むことで、行われる。また、Section開始状態からTitle追加状態への遷移は「Paragraph」ノードか、「Artwork」ノードか、何れかを読み込むことで、行われる。
【0184】
Paragraph状態からSection終止状態への遷移は「Paragraph」ノードか、「Artwork」ノードか、「Title」ノードか、何れかを読み込むことで行われる。また、この遷移はω遷移、すなわち読み込むノードが存在しない時にも行われる。このω遷移の存在によって、Paragraph状態において読み込むノードが無くてもSection終止状態への遷移が可能となり、この補完オートマトンの終了状態へ到達できる。
【0185】
Artwork状態からSection終止状態への遷移は、「Paragraph」ノードか、「Artwork」ノードか、「Title」ノードか、何れかを読み込むことで行われる。また、この遷移はω遷移、すなわち読み込むノードが存在しない時にも行われる。このω遷移の存在によって、Artwork状態において読み込むノードが無くてもSection終止状態への遷移が可能となり、この補完オートマトンの終了状態へ到達できる。
【0186】
更に、Section終止状態からSection開始状態への遷移は「Paragraph」ノードか、「Artwork」ノードか、「Title」ノードか、何れかを読み込むことで行われる。
【0187】
だが、この補完オートマトン710では、Artwork状態とParagraph状態とが、同じラベルによる別の状態への遷移を持つ。すなわち、Artwork状態にある時「Paragraph」ノードを読み込むと、遷移先としてParagraph状態とSection終止状態とが存在してしまう。また、やはりArtwork状態にある時に「Artwork」ノードを読み込むと、遷移先としてArtwork状態とSection終止状態とが存在してしまう。Paragraph状態に関しても、同様の現象が起きている。
【0188】
よって、補完オートマトン710は実用に適さず、ユーザには補完指定検査部39によってその旨通知が行われて、構造化文書の作成は中止される。
このように、第2の実施の形態では補完検査部を設けて、補完指定及び補完オートマトンが出力文書クラスの定義情報と適合しているかどうか調べられる。これによって、時間のかかる補完処理に入る前に、補完指定及び補完オートマトンが正常な補完処理を行えるかどうか判断でき、誤った補完指定を実行してしまうことを防ぐことができる。
【0189】
【発明の効果】
以上説明したように本発明では、所定の文書クラスへの構造化を希望する原文書の構造を、希望する文書クラスの構造制約にほぼ従った構造に変換した後に、不足している構成要素を原文書の定義情報と希望する文書クラスの定義情報とに基づいて自動的に補完することが可能である。また、ユーザの希望に基づいて補完の仕方を決定することができるので、ユーザの希望に沿った構造化文書を作成することができる。
【図面の簡単な説明】
【図1】本発明の文書構造作成装置の原理構成図である。
【図2】文書構造作成装置の第1の実施の形態の構成を示すブロック図である。
【図3】構造化文書の作成手順を示すフローチャートである。
【図4】「技術メモ」という名称を持つ文書クラスの定義情報のうち、ノードのタイプ定義を示したものである。
【図5】「技術メモ」という名称を持つ文書クラスの定義情報のうち、定義されたノードの接続関係を規定する構造制約である。
【図6】「Technical Report 」という名称を持つ文書クラスの定義情報のうち、ノードのタイプ定義を示したものである。
【図7】「Technical Report 」という名称を持つ文書クラスの定義情報のうち、定義されたノードの接続関係を規定する構造制約である。
【図8】「技術メモ」の文書データを定義情報に基づいて解析し、文書構造を抽出した結果の例である。
【図9】入力文書クラス名「技術メモ」、出力文書クラス名「Technical Report 」の変換規則を示す。
【図10】文書構造変換の詳しい手順を示したフローチャートである。
【図11】「技術メモ」の文書データを、文書クラス「Technical Report 」の文書データに変換した被補完文書の構造である。
【図12】入力文書クラス名「技術メモ」、出力文書クラス名「Technical Report 」の補完指定である。
【図13】出力文書クラス名「Technical Report 」のルートノードである「Report 」ノードの、下位構造に対する補完オートマトンである。
【図14】図13に示した、「Report 」ノードの下位構造に対する補完オートマトンの持つデータ構造である。
【図15】補完オートマトン作成の大まかな手順を示したフローチャートである。
【図16】ノードの下位構造に対する基礎オートマトン作成の手順を示したフローチャートである。
【図17】構造制約子「REP」に対する基礎オートマトン作成の手順を示したフローチャートである。
【図18】構造制約子「SEQ」に対する基礎オートマトン作成の手順を示したフローチャートである。
【図19】構造制約子「CHO」に対する基礎オートマトン作成の手順を示したフローチャートである。
【図20】補完アクションのない基礎オートマトン作成の手順を示したフローチャートである。
【図21】補完アクション「追加」を行う基礎オートマトン作成の手順を示したフローチャートである。
【図22】補完アクション「追加可」を行う基礎オートマトン作成の手順を示したフローチャートである。
【図23】補完アクション「差し込み」を行う基礎オートマトン作成の手順を示したフローチャートである。
【図24】補完アクション「差し込み可」を行う基礎オートマトン作成の手順を示したフローチャートである。
【図25】出力文書クラス名「Technical Report 」の「Report 」ノードの下位構造に対する基礎オートマトンである。
【図26】出力文書クラス名「Technical Report 」の「Artwork」ノードの下位構造に対する基礎オートマトンである。
【図27】出力文書クラス名「Technical Report 」の「Section」ノードの下位構造に対する基礎オートマトンを示す。
【図28】ε遷移の置き換え処理の手順を示したフローチャートである。
【図29】non−εリストによるεリストの要素が持つε遷移の置き換えの手順を示すフローチャートである。
【図30】non−εリストによる current状態が持つε遷移の置き換えの手順を示すフローチャートである。
【図31】図25にて示した基礎オートマトンにε遷移の置き換え処理を施して作成した補完オートマトンである。
【図32】図26にて示した基礎オートマトンにε遷移の置き換え処理を施して作成した補完オートマトンである。
【図33】図27にて示した基礎オートマトンにε遷移の置き換え処理を施して作成した補完オートマトンである。
【図34】補完処理の大まかな手順を示したフローチャートである。
【図35】current状態固有の処理の手順を示したフローチャートである。
【図36】図11にて示した被補完文書構造に、図31、図32、図33にて示した補完オートマトンを適用して作成した文書構造である。
【図37】図8に示した文書クラス「技術メモ」の文書データの文書構造解析結果を文書クラス「Technical Report 」に適合するよう変換した適合文書構造である。
【図38】文書構造作成装置の第2の実施の形態の構成を示すブロック図である。
【図39】第2の実施の形態の文書構造作成装置を用いて構造化文書を作成する手順を示すフローチャートである。
【図40】入力文書クラス名「技術メモ」、出力文書クラス名「Technical Report 」に対する誤った補完指定である。
【図41】図40にて示した補完指定に基づいて作成した、文書クラス「Technical Report 」に対する基礎オートマトンである。
【図42】図41に示した基礎オートマトンにε遷移の置き換え処理を施して作成した補完オートマトンである。
【符号の説明】
1 補完指定記憶手段
2 補完手段
3 対応規則記憶手段
4 文書構造変換手段
Claims (4)
- 所定の文書クラスの構造制約を満たした文書構造を作成する文書構造作成装置において、
所定の手続きに従って作成された、目的とする文書構造を完全には満たしていない被補完文書構造を前記文書クラスに適合させるにあたり、補完が必要なことが予測される要素の構成要素タイプに対するユーザにより指定される補完指定を記憶する補完指定記憶手段と、
前記被補完文書構造を前記文書クラスの構造制約と前記補完指定とに基づいて解析し、前記被補完文書構造に不足している要素を補った文書構造を作成する補完手段と、
を有することを特徴とする文書構造作成装置。 - 変換前文書クラスに定義された構成要素タイプと、前記文書クラスに定義された構成要素タイプとの対応関係を定義した対応規則を記憶する対応規則記憶手段と、
前記変換前文書クラスに適合した原文書の構造を解析し、得られた解析結果に前記対応規則に基づいた変換を行い、前記文書クラスに定義された構成要素タイプの要素で構成された前記被補完文書構造を作成する文書構造変換手段と、
をさらに有することを特徴とする請求項1記載の文書構造作成装置。 - 前記補完指定には、前記文書クラスの構造に必要な要素を追加するものと、前記文書クラスの構造に要素を追加することを認めるものと、前記文書クラスの構造に必要な要素を差し込むものと、前記文書クラスの構造に要素を差し込むことを認めるもののいずれかであることを特徴とする請求項1記載の文書構造作成装置。
- 所定の文書クラスの構造制約を満たした文書構造を作成する文書構造作成方法において、
所定の手続きに従って作成された、目的とする文書構造を完全には満たしていない被補完文書構造を前記文書クラスに適合させるにあたり、補完が必要なことが予測される要素の構成要素タイプに対するユーザにより指定される補完指定を補完指定記憶手段に格納し、
補完手段により、前記被補完文書構造を前記文書クラスの構造制約と前記補完指定とに基づいて解析し、前記被補完文書構造に不足している要素を補った文書構造を作成する、
ことを特徴とする文書構造作成方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP12437996A JP3605941B2 (ja) | 1996-05-20 | 1996-05-20 | 文書構造作成装置及び文書構造作成方法 |
US08/856,399 US5920879A (en) | 1996-05-20 | 1997-05-14 | Document structure conversion apparatus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP12437996A JP3605941B2 (ja) | 1996-05-20 | 1996-05-20 | 文書構造作成装置及び文書構造作成方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH09305604A JPH09305604A (ja) | 1997-11-28 |
JP3605941B2 true JP3605941B2 (ja) | 2004-12-22 |
Family
ID=14883956
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP12437996A Expired - Lifetime JP3605941B2 (ja) | 1996-05-20 | 1996-05-20 | 文書構造作成装置及び文書構造作成方法 |
Country Status (2)
Country | Link |
---|---|
US (1) | US5920879A (ja) |
JP (1) | JP3605941B2 (ja) |
Families Citing this family (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0969101A (ja) * | 1995-08-31 | 1997-03-11 | Hitachi Ltd | 構造化文書生成方法および装置 |
US6658624B1 (en) * | 1996-09-24 | 2003-12-02 | Ricoh Company, Ltd. | Method and system for processing documents controlled by active documents with embedded instructions |
JPH10143403A (ja) | 1996-11-12 | 1998-05-29 | Fujitsu Ltd | 情報管理装置および情報管理プログラム記憶媒体 |
JPH10307799A (ja) * | 1997-02-28 | 1998-11-17 | Media Konekuto:Kk | コンピュータ通信網における身元確認方法及び身元確認装置 |
JPH10307816A (ja) * | 1997-05-08 | 1998-11-17 | Just Syst Corp | 構造化文書処理装置、構造化文書処理方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体 |
US6182092B1 (en) | 1997-07-14 | 2001-01-30 | Microsoft Corporation | Method and system for converting between structured language elements and objects embeddable in a document |
US6263332B1 (en) | 1998-08-14 | 2001-07-17 | Vignette Corporation | System and method for query processing of structured documents |
US6569207B1 (en) * | 1998-10-05 | 2003-05-27 | International Business Machines Corporation | Converting schemas to component models |
US8006177B1 (en) * | 1998-10-16 | 2011-08-23 | Open Invention Network, Llc | Documents for commerce in trading partner networks and interface definitions based on the documents |
US7039859B1 (en) * | 1998-11-12 | 2006-05-02 | International Business Machines Corporation | Generating visual editors from schema descriptions |
US7287219B1 (en) | 1999-03-11 | 2007-10-23 | Abode Systems Incorporated | Method of constructing a document type definition from a set of structured electronic documents |
KR100674796B1 (ko) * | 1999-12-30 | 2007-01-26 | 주식회사 케이티 | 문서 규칙 정보를 이용하여 전자 문서로부터 데이터파일을 생성하는 장치 및 그 방법 |
AU2929301A (en) * | 2000-01-07 | 2001-07-24 | Winlook Corporation | Method and apparatus for displaying, retrieving, filing and organizing various kinds of data and images |
US7073122B1 (en) * | 2000-09-08 | 2006-07-04 | Sedghi Ali R | Method and apparatus for extracting structured data from HTML pages |
US9742614B2 (en) | 2000-09-28 | 2017-08-22 | Wellogix Technology Licensing, Llc | Data-type definition driven dynamic business component instantiation and execution framework |
US8788931B1 (en) | 2000-11-28 | 2014-07-22 | International Business Machines Corporation | Creating mapping rules from meta data for data transformation utilizing visual editing |
US7028024B1 (en) * | 2001-07-20 | 2006-04-11 | Vignette Corporation | Information retrieval from a collection of information objects tagged with hierarchical keywords |
US20030061062A1 (en) * | 2001-09-26 | 2003-03-27 | Tucker Timothy J. | XML data switch |
JP2003150586A (ja) * | 2001-11-12 | 2003-05-23 | Ntt Docomo Inc | 文書変換システム、文書変換方法及び文書変換プログラムを記録したコンピュータ読み取り可能な記録媒体 |
US7107525B2 (en) * | 2002-07-23 | 2006-09-12 | Xerox Corporation | Method for constraint-based document generation |
US20040034613A1 (en) * | 2002-07-23 | 2004-02-19 | Xerox Corporation | System and method for dynamically generating a style sheet |
US7487445B2 (en) * | 2002-07-23 | 2009-02-03 | Xerox Corporation | Constraint-optimization system and method for document component layout generation |
US7603371B1 (en) | 2002-12-17 | 2009-10-13 | Vignette Corporation | Object based system and method for managing information |
US7428699B1 (en) | 2003-01-15 | 2008-09-23 | Adobe Systems Incorporated | Configurable representation of structured data |
US7797626B2 (en) * | 2003-02-12 | 2010-09-14 | Sap Ag | Managing different representations of information |
US7657832B1 (en) | 2003-09-18 | 2010-02-02 | Adobe Systems Incorporated | Correcting validation errors in structured documents |
US7165216B2 (en) * | 2004-01-14 | 2007-01-16 | Xerox Corporation | Systems and methods for converting legacy and proprietary documents into extended mark-up language format |
US7882119B2 (en) * | 2005-12-22 | 2011-02-01 | Xerox Corporation | Document alignment systems for legacy document conversions |
US9411781B2 (en) | 2006-01-18 | 2016-08-09 | Adobe Systems Incorporated | Rule-based structural expression of text and formatting attributes in documents |
US20090299813A1 (en) * | 2008-05-30 | 2009-12-03 | Thomas Cody | Sustainable performance information for a property |
US20110225482A1 (en) * | 2010-03-15 | 2011-09-15 | Wizpatent Pte Ltd | Managing and generating citations in scholarly work |
US10558679B2 (en) * | 2016-02-10 | 2020-02-11 | Fuji Xerox Co., Ltd. | Systems and methods for presenting a topic-centric visualization of collaboration data |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS63286963A (ja) * | 1987-05-20 | 1988-11-24 | Hitachi Ltd | 文書変換装置 |
US5181162A (en) * | 1989-12-06 | 1993-01-19 | Eastman Kodak Company | Document management and production system |
US5552982A (en) * | 1990-10-31 | 1996-09-03 | Microsoft Corporation | Method and system for processing fields in a document processor |
JPH06214983A (ja) * | 1993-01-20 | 1994-08-05 | Kokusai Denshin Denwa Co Ltd <Kdd> | 文書画像の論理構造化文書への変換方法および装置 |
US5438512A (en) * | 1993-10-22 | 1995-08-01 | Xerox Corporation | Method and apparatus for specifying layout processing of structured documents |
JP2618832B2 (ja) * | 1994-06-16 | 1997-06-11 | 日本アイ・ビー・エム株式会社 | 文書の論理構造の解析方法及びシステム |
-
1996
- 1996-05-20 JP JP12437996A patent/JP3605941B2/ja not_active Expired - Lifetime
-
1997
- 1997-05-14 US US08/856,399 patent/US5920879A/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JPH09305604A (ja) | 1997-11-28 |
US5920879A (en) | 1999-07-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3605941B2 (ja) | 文書構造作成装置及び文書構造作成方法 | |
JP4267336B2 (ja) | 構造パターン候補を生成する方法、システムおよびプログラム | |
US7210096B2 (en) | Methods and apparatus for constructing semantic models for document authoring | |
US5649218A (en) | Document structure retrieval apparatus utilizing partial tag-restored structure | |
AU2005225130B2 (en) | Management and use of data in a computer-generated document | |
US20020143818A1 (en) | System for generating a structured document | |
Schmidt | The role of markup in the digital humanities | |
US20090021767A1 (en) | Document processing device | |
JP3831085B2 (ja) | 文書管理装置,サーバ装置,クライアント装置およびそれらのプログラム記憶媒体 | |
US20080262993A1 (en) | Document Management Device and Document Management Method | |
EP1830274A1 (en) | Server device and name space issuing method | |
JPWO2006001392A1 (ja) | 文書処理方法および装置 | |
JPWO2006046665A1 (ja) | 文書処理装置及び文書処理方法 | |
JP3168829B2 (ja) | 検索式作成支援システム | |
JPWO2006001393A1 (ja) | 文書処理方法および装置 | |
JP4417384B2 (ja) | 文書処理装置および文書処理方法 | |
Meyer | aTool: Creating Validated XML Documents on the fly using MS Word | |
US20210011906A1 (en) | Document creation support system | |
US9069740B2 (en) | Computer implemented method for transformation between discussion documents and online discussion forums | |
JP3707133B2 (ja) | 文書データベース管理装置および文書データベース管理方法 | |
JP3508623B2 (ja) | 構造化文書管理システム及び方法並びに記録媒体 | |
EP2174238A2 (en) | Representation of multiple markup language files in one file for the production of new markup language files | |
Dobratz et al. | SGML/XML-based electronic theses and dissertations: Existing projects and standards | |
de Waard et al. | Metadata in science publishing | |
Tang et al. | Podwis: A personalized tool for ontology development in domain specific web information system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040914 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040927 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071015 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081015 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091015 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101015 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111015 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121015 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121015 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131015 Year of fee payment: 9 |
|
EXPY | Cancellation because of completion of term |