(57)【要約】【課題】  複数の構造化文書を結合する場合に、繰り返し記述の冗長性をさらに低減することが可能な技術を提供する。【解決手段】  複数の構造化文書を結合する情報処理装置は、複数の構造化文書の各々について、構造化文書を構成するボキャブラリ情報とトークン情報との対応関係を示す対応情報と、構造化文書に含まれる各ボキャブラリ情報が該対応情報に基づき対応するトークン情報で置き換えられた符号化情報と、を取得する取得手段と、第１の対応情報に含まれるボキャブラリ情報と、第２の対応情報に含まれるボキャブラリ情報とが共通する場合、該第１の対応情報に含まれる該共通するボキャブラリ情報を、該第２の対応情報に含まれる該共通するボキャブラリ情報への参照で置き換える置換手段と、複数の構造化文書の各々の、共通するボキャブラリ情報が置き換えられた対応情報と、符号化情報と、を結合して結合情報を生成する結合手段と、を備える。【選択図】  図４
2009140470.tif 000002
【特許請求の範囲】
【請求項１】
複数の構造化文書を結合する情報処理装置であって、
前記複数の構造化文書の各々について、構造化文書を構成するボキャブラリ情報とトークン情報との対応関係を示す対応情報と、構造化文書に含まれる各ボキャブラリ情報が該対応情報に基づき対応するトークン情報で置き換えられた符号化情報と、を取得する取得手段と、
第１の対応情報に含まれるボキャブラリ情報と、第２の対応情報に含まれるボキャブラリ情報とが共通する場合、該第１の対応情報に含まれる該共通するボキャブラリ情報を、該第２の対応情報に含まれる該共通するボキャブラリ情報への参照で置き換える置換手段と、
前記複数の構造化文書の各々の、共通するボキャブラリ情報が置き換えられた前記対応情報と、前記符号化情報と、を結合して結合情報を生成する結合手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記構造化文書を識別する文書識別情報と、該構造化文書の前記結合情報における位置とを、前記複数の構造化文書の各々について示すマッピング情報を生成する生成手段を更に備え、
前記置換手段が置き換える前記参照は、前記文書識別情報を用いて前記ボキャブラリ情報を特定し、
前記結合手段は、前記結合情報に対して前記マッピング情報を更に結合する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記生成手段は、他の対応情報から参照されているボキャブラリ情報を有する前記対応情報と、該他の対応情報とを関連付けて前記マッピング情報に記載する
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記結合情報から、指定された構造化文書に相当する箇所を削除する削除手段を更に備え、
前記指定された構造化文書に対応する前記対応情報が、他の対応情報から参照されているボキャブラリ情報を有する場合、
前記置換手段は、前記他の対応情報においてボキャブラリ情報から前記参照に置換されていた箇所を、置換前のボキャブラリ情報に復元し、
前記削除手段は、前記置換手段が前記ボキャブラリに復元した後に、前記結合情報から前記指定された構造化文書に相当する箇所を削除する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記対応情報に含まれる同一のボキャブラリに対して同一のトークン情報を割り当て、割り当てた該トークン情報に基づき、前記符号化情報に含まれるトークン情報を書き換える手段をさらに備える
ことを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
【請求項６】
前記構造化文書が構造化されたテキスト文書である場合、前記取得手段は、該テキスト文書を前記対応情報に基づいて符号化することにより前記符号化情報を取得する
ことを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
【請求項７】
前記構造化文書が前記対応情報と前記符号化情報とを有するバイナリ情報である場合、前記取得手段は、該バイナリ情報から分離して前記符号化情報を取得する
ことを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
【請求項８】
前記構造化文書は、ＸＭＬ文書と、Fast Infoset文書と、バイナリＸＭＬ文書とのいずれかである
ことを特徴とする請求項１から７のいずれか１項に記載の情報処理装置。
【請求項９】
前記結合手段は、ＺＩＰフォーマット、又は、MIME Multipart/Relatedフォーマットに基づいて、前記複数の構造化文書のそれぞれの前記対応情報と前記符号化情報とを結合する
ことを特徴とする請求項１から８のいずれか１項に記載の情報処理装置。
【請求項１０】
複数の構造化文書を結合する情報処理装置の制御方法であって、
前記複数の構造化文書の各々について、構造化文書を構成するボキャブラリ情報とトークン情報との対応関係を示す対応情報と、構造化文書に含まれる各ボキャブラリ情報が該対応情報に基づき対応するトークン情報で置き換えられた符号化情報と、を取得する取得工程と、
第１の対応情報に含まれるボキャブラリ情報と、第２の対応情報に含まれるボキャブラリ情報とが共通する場合、該第１の対応情報に含まれる該共通するボキャブラリ情報を、該第２の対応情報に含まれる該共通するボキャブラリ情報への参照で置き換える置換工程と、
前記複数の構造化文書の各々の、共通するボキャブラリ情報が置き換えられた前記対応情報と、前記符号化情報と、を結合して結合情報を生成する結合工程と、
を有することを特徴とする情報処理装置の制御方法。
【請求項１１】
コンピュータを請求項１から９のいずれか１項に記載の情報処理装置として機能させるためのプログラム。
【請求項１２】
請求項１１に記載のプログラムを格納したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置及びその制御方法、プログラム、記録媒体に関し、特に、構造化文書を処理するための技術に関する。
【背景技術】
【０００２】
従来、Ｗ３Ｃで策定されたＸＭＬ言語仕様では、データをＸＭＬ言語で記述する場合、ＵＴＦ−８、ＵＴＦ−１６などの文字符号化方式で符号化するのが一般的である。この場合、データ構造や整数、小数値なども文字として記述されるため、データサイズが大きくなるという問題があった。
【０００３】
これに対して、ＩＳＯで策定されたＦａｓｔ ｉｎｆｏｓｅｔ（ＩＳＯ／ＩＥＣ  ２４８２４−１）仕様などバイナリＸＭＬ技術が知られている。バイナリＸＭＬ技術では、整数や小数値を本来のデータ型でエンコーディングしたり、繰り返し記述されるデータ構造や値をデータ長の短いトークンで置き換えたりする。このため、データサイズの縮小を行うことができた。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記の手法は、ワープロ文書などの複数の構造化文書を結合した場合に次のような課題が生じる。即ち、バイナリＸＭＬでは、一つの構造化文書に対し、繰り返し現われる記述を共通化するが、ワープロ文書では、構造化文書毎に記述を使いまわすため、構造化文書間に跨って繰り返される記述を共通化することができない。このため、ワープロ文書にバイナリＸＭＬを適用しても、繰り返し記述に冗長性が生じてしまい、全体として繰り返し記述が多いにも関わらず十分サイズを縮小することができない。
【０００５】
これに対して、スキーマ情報より、予め共通トークンを用意し、複数の構造化文書間で使いまわす手法が考えられる。しかしこの手法は、予めスキーマを定義することができない場合や、複数の構造化文書を統合する場合においては適用することができない。また、スキーマ情報から予め共通トークンを用意する手法では、実際の構造化文書データであまり使われないデータについてまでトークンを用意しなければならない。さらに、スキーマ情報からでは、要素の値や属性値まで共通トークンを用意するのは難しい。
【０００６】
本発明は上記課題に鑑みなされたものであり、複数の構造化文書を結合する場合に、繰り返し記述の冗長性をさらに低減することが可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明による情報処理装置は以下の構成を備える。即ち、
複数の構造化文書を結合する情報処理装置であって、
前記複数の構造化文書の各々について、構造化文書を構成するボキャブラリ情報とトークン情報との対応関係を示す対応情報と、構造化文書に含まれる各ボキャブラリ情報が該対応情報に基づき対応するトークン情報で置き換えられた符号化情報と、を取得する取得手段と、
第１の対応情報に含まれるボキャブラリ情報と、第２の対応情報に含まれるボキャブラリ情報とが共通する場合、該第１の対応情報に含まれる該共通するボキャブラリ情報を、該第２の対応情報に含まれる該共通するボキャブラリ情報への参照で置き換える置換手段と、
前記複数の構造化文書の各々の、共通するボキャブラリ情報が置き換えられた前記対応情報と、前記符号化情報と、を結合して結合情報を生成する結合手段と、
を備える。
【０００８】
また、本発明による情報処理装置の制御方法は以下の構成を有する。即ち、
複数の構造化文書を結合する情報処理装置の制御方法であって、
前記複数の構造化文書の各々について、構造化文書を構成するボキャブラリ情報とトークン情報との対応関係を示す対応情報と、構造化文書に含まれる各ボキャブラリ情報が該対応情報に基づき対応するトークン情報で置き換えられた符号化情報と、を取得する取得工程と、
第１の対応情報に含まれるボキャブラリ情報と、第２の対応情報に含まれるボキャブラリ情報とが共通する場合、該第１の対応情報に含まれる該共通するボキャブラリ情報を、該第２の対応情報に含まれる該共通するボキャブラリ情報への参照で置き換える置換工程と、
前記複数の構造化文書の各々の、共通するボキャブラリ情報が置き換えられた前記対応情報と、前記符号化情報と、を結合して結合情報を生成する結合工程と、
を有する。
【発明の効果】
【０００９】
本発明によれば、複数の構造化文書を結合する場合に、繰り返し記述の冗長性をさらに低減することが可能な技術を提供することができる。
【発明を実施するための最良の形態】
【００１０】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、本発明の範囲をそれらのみに限定する趣旨のものではない。また、本実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
【００１１】
＜＜実施形態１＞＞
（ハードウェア構成）
本実施形態の情報処理装置としての文書データ符号化装置のハードウェア構成について、図１を参照して説明する。図１は文書データ符号化装置のハードウェア構成を示すブロック図である。
【００１２】
文書データ符号化装置は単一のコンピュータ装置で実現してもよいし、必要に応じた複数のコンピュータ装置に各機能を分散して実現するようにしてもよい。複数のコンピュータ装置で構成される場合は、互いに通信可能なようにLocal Area Network(ＬＡＮ)などで接続される。
【００１３】
情報処理装置としての文書データ符号化装置はパーソナルコンピュータ（ＰＣ）により実現されるが、これに限られない。例えば、ワークステーション（ＷＳ）、携帯情報端末（ＰＤＡ）、携帯電話、デジタルカメラ、プリンタ等の、情報処理を行う任意の機器により実現可能である。
【００１４】
図１において、１０１は文書データ符号化装置１００全体を制御するCentral Processing Unit（ＣＰＵ）である。１０２は変更を必要としないプログラムやパラメータを格納するRead Only Memory（ＲＯＭ：読出専用メモリ）である。１０３は外部装置などから供給されるプログラムやデータを一時記憶するRandom Access Memory（ＲＡＭ：書込可能メモリ）である。
【００１５】
１０４は外部記憶装置であり、本実施形態では文書データ符号化装置１００に固定して設置されたハードディスクにより実現される。ただし、文書データ符号化装置１００に固定して設置されたメモリカード、あるいは文書データ符号化装置１００から着脱可能なＦＤやＣＤ等の光ディスク、磁気や光カード、ＩＣカード、メモリカードなどにより実現しても構わない。なお、ＦＤはフレキシブルディスク（Flexible Disk）の略称であり、ＣＤはコンパクトディスク（Compact Disk）の略称である。
【００１６】
１０５は、ユーザの操作を受ける入力デバイス１０９とのインターフェイスである。入力デバイス１０９は、例えば、データを入力するポインティングデバイスやキーボード等により実現される。
【００１７】
１０６はインターネットなどのネットワーク回線１０８に接続するためのネットワークインタフェイスである。１０７は１０１〜１０６の各ユニットを通信可能に接続するシステムバスである。
【００１８】
（バイナリＸＭＬ例）
携帯電話、デジタルカメラ、プリンタなどハードウェアリソースの少ない機器では、ＸＭＬデータのサイズ縮小が求められている。このような要求を実現する技術として、従来よりバイナリＸＭＬが用いられている。バイナリＸＭＬでは、バイナリ情報に変換されたＸＭＬ文書であり、ＸＭＬの繰り返し記述の部分に対し、データ長がより短いトークンを割り当てることでデータ量の削減を行う。
【００１９】
バイナリＸＭＬの例について図２を参照して説明する。図２は、バイナリＸＭＬの一つであるISO/ITU-T標準のFast Infoset文書の一例を示す図である。
【００２０】
図２において、ＸＭＬ文書２１０中の"dataroot"、"Employees"、"LASTNAME"の各ボキャブラリには、トークンテーブル２２０においてトークンとしてindexが割り振られている。バイナリＸＭＬの符号化器は、このトークンテーブル２２０を元に符号化データ２３０を作成する。ただし、トークンテーブルは、構造化文書を構成するボキャブラリ情報とトークン情報との対応関係を示す対応情報を提供する。
【００２１】
例えば、要素datarootは、要素を表す"００"、整数の型を表す"０"、整数値を表す"０００００"に符号化される。整数の型"０"のときは、バイアス１の５ビット整数なので、整数の値は１となり、index １のdatarootを指すことになる。他の要素に対しても同様の符号化を行うと、２３０のような符号化データが作成される。４ビットの１１１１は要素の終了タグを示している。バイナリＸＭＬに符号化することで、繰り返し現われるボキャブラリが短いバイト数で表現され、全体のデータ量が小さくなる。なお、図２において、符号化データ２３０中の"(ｉｎｄｅｘ＝１)"〜"(ｉｎｄｅｘ＝３)"はそれぞれ左隣の８ビット列で表される内容を示している。
【００２２】
しかし、ワープロ文書のような同じフォーマットを複数の文書データで繰り返し用い、各文書データを一つのデータに結合して保存する場合には問題がある。このことを図３を参照して説明する。図３は、表データ作成ソフトウェア（例えば、Microsoft Access等）を使って作成した表データをexportしてＸＭＬデータにする様子を例示する図である。
【００２３】
図３では、表データ３１０、３３０、３５０は、それぞれＸＭＬ文書３２０、３４０、３６０に対応づけられている。図３では、dataroot、LASTNAME、Koizumi、Yamamotoというボキャブラリは、複数のＸＭＬ文書で使われている。
【００２４】
こうして別々に作成された表データを、一つの文書データに結合して保存したい場合がある。従来のバイナリＸＭＬでは、各ＸＭＬ文書についてトークンテーブルと符号化データが作成される。図７はＸＭＬ文書、トークンテーブル、符号化データの対応を例示する図である。図７の例では、ＸＭＬ文書３２０に対してトークンテーブル７１０と符号化データ７２０が作成される。同様に、ＸＭＬ文書３４０に対してはトークンテーブル７３０と符号化データ７４０が作成され、ＸＭＬ文書３６０に対してはトークンテーブル７５０と符号化データ７６０が作成される。
【００２５】
これらの表データを結合する際には、各バイナリＸＭＬを結合文書データの各パートに挿入するだけである。このような手法では、図３のような表データを多く結合したい場合、結合データ（結合情報）中に繰り返し記述が多く現れるため、サイズ縮小効果があまり得られない。例えば、図７の例では、ＸＭＬ文書３２０、３４０には、dataroot、LASTNAME、Koizumiのボキャブラリが共通しているが、トークンテーブル７１０、７３０ではそれぞれ別個にｉｎｄｅｘが割り振られており、冗長である。
【００２６】
（バイナリＸＭＬ結合処理）
そこで、本実施形態では、全体サイズを縮小可能なようにバイナリＸＭＬの結合を行う。即ち、本実施形態では、文書データを結合して結合データを生成する際に、各文書データから取得されたトークンテーブルにおいて、共通するボキャブラリに対しては同一のｉｎｄｅｘを割り振って使用する。これにより、結合データのサイズを削減可能である。
【００２７】
図４は、バイナリＸＭＬ（例えば、図７）を複数結合する際に実行される、本実施形態における結合処理のフローを示すフローチャートである。以下、図４のフローに沿って説明する。なお、図４の各ステップは、ＣＰＵ１０１が文書データ符号化装置１００を制御することによって実行される。
【００２８】
先ず、結合する構造化文書データを順次、文書データ符号化装置１００に入力する。
【００２９】
そして、ステップＳ４０１において、文書データ符号化装置１００は、入力された文書データの形式を判定する。文書データ形式の判定は、アプリケーションから明示的に指定してもらっても良い。
【００３０】
或いは、図５のような対応表を予め登録しておき、ファイルヘッダやファイル拡張子、メディアタイプからデータ形式を判定してもよい。ただし、図５は、データ形式の対応表を例示する図である。データフォーマットごとに、ファイルヘッダ、ファイル拡張子、メディアタイプなどが決まっている場合があるので、ファイルの拡張子やメッセージヘッダを見て、入力された文書データの形式を自動判定することができる。例えば、文書データのファイル拡張子がｆｉｎｆの場合、図５の対応表から、当該文書ファイルのデータ形式をFast Infosetと判定することができよう。
【００３１】
次に、ステップＳ４０２において、ステップＳ４０１で判定したデータ形式が、ＸＭＬ又はバイナリＸＭＬであるか否かを判定する。ＸＭＬ又はバイナリＸＭＬの場合（ステップＳ４０２でＮＯ）はステップＳ４０３へ進み、処理をリターンして従来通りの結合処理を行う。ＸＭＬやバイナリＸＭＬの場合（ステップＳ４０２でＹＥＳ）は、ステップＳ４０３へ進む。
【００３２】
ステップＳ４０３においては、対応するプロセッサを用い、文書データをトークンテーブルと符号化データ（符号化情報）に分離し、トークンテーブルと符号化データとを取得する。対応するプロセッサは、文書データ符号化装置１００内に（ハードウェア、又はソフトウェアを問わず）実装されても良いし、インタフェースだけ保持し別々の装置に実装されても良い。
【００３３】
文書データがバイナリＸＭＬ文書である場合は、バイナリＸＭＬのデコーダとして動作するプロセッサを用いて、符号化データとトークンテーブルとを分離して取得する。ＸＭＬ文書がテキスト文書の場合は、バイナリＸＭＬ・エンコーダとして動作するプロセッサを用い、ＸＭＬ文書中の各ボキャブラリ情報を対応するトークン情報で置換し、バイナリＸＭＬへ符号化すると共に、トークンテーブルを取得する。ここで取得したトークンテーブルをトークンテーブルＡとする。例えば、文書データが図７の３２０で表される場合は、当該文書データを解析してトークンテーブル７１０を取得する。この処理は、入力した複数の構造化文書の各々について実行する。
【００３４】
ステップＳ４０４〜ステップＳ４０６において、トークンテーブルの冗長性をチェックする。即ち、ステップＳ４０３で分離されたトークンテーブル（トークンテーブルＡ）と、これまでの処理で結合データ中に結合された各トークンテーブルとを比較して、共通するボキャブラリが存在するかどうかをチェックする。そこで、まずステップＳ４０４において、トークンテーブルＡとまだ比較していないトークンテーブルが結合データ中に存在するか否かを判定する。存在する場合（ステップＳ４０４でＹＥＳ）はステップＳ４０５へ進み、存在しない場合（ステップＳ４０４でＮＯ）はステップＳ４０７へ進む。
【００３５】
なお、本実施形態では、チェック対象となるテーブルは図６のようなマッピング情報としてのテーブルマップに記録されている。ここで図６は、これまでの処理により生成されたバイナリＸＭＬの結合データの例と、バイナリＸＭＬのパート毎に結合データの先頭からのオフセット等が記載されたテーブルマップの例を示す模式図である。
【００３６】
ここで、結合データの先頭からのオフセットは、結合データにおける構造化文書の位置を示している。図６のように、テーブルマップは、構造化文書を識別する文書名等の文書識別情報と構造化文書の位置とを、構造化文書の各々について示している。文書データ符号化装置１００は、処理対象の複数の構造化文書について、このようなテーブルマップを生成する。
【００３７】
図６の例では、パート名がemployee_table1、employee_table2、employee_table3の３つの文書が既に結合データに結合されている。図６のように、各文書はトークンテーブルと符号化データから構成される。図６の例では、パート名がemployee_table2の文書パートのオフセットは３００Byteであり、パート名がemployee_table3の文書パートのオフセットは７００Byteである。
【００３８】
テーブルマップには、既に結合データに入れられたトークンテーブルを参照するための情報が記述されている。本実施形態では、テーブルマップに、既に保存したパートのパート名、先頭からオフセット、indexを記録している。
【００３９】
そこで、本実施形態では、テーブルマップに、未チェックのトークンテーブルの参照があるか否かを判定し、存在する場合は、まだ比較していないトークンテーブルが結合データ中に存在すると判定して、ステップＳ４０５へ進む。存在しない場合は、ステップＳ４０７へ進む。
【００４０】
ステップＳ４０５では、未チェックのテーブルと、トークンテーブルＡとを比較する比較処理を行う。このときの未チェックのトークンテーブルをトークンテーブルＢとする。そして、トークンテーブルＡとトークンテーブルＢの間で同じエントリ（ボキャブラリ情報のエントリ）がないかどうかチェックする。
【００４１】
同じものがなければ（ステップＳ４０５でＮＯ）、ステップＳ４０４に戻り、テーブルマップ内に未チェックのトークンテーブルが残っていないか確認する。同じものがあれば（Ｓ４０５でＹＥＳ）、トークンテーブルＡの同一エントリを、トークンテーブルＢにおける同一のエントリへの参照に書き換える。本実施形態では、図７に示すように、dataroot、LASTNAME、Koizumi、Yamamotoが同じエントリになる。このため、employee_table2、employee_table3のこれらのエントリを、employee_table1の対応するエントリへの参照に書き換える。
【００４２】
トークンテーブルのエントリは、データ型と値の対で記述される。例えば、datarootであれば、文字列型で"dataroot"の文字列値が記述される。そこで、他のテーブルへの参照を記述するために、図８のような新たな型定義を行う。図８は、データ型の定義例を示す図である。本実施形態では、index＝１５（１６進数でｆ）としてtokenref型を定義している。トークンテーブルの書き換えはtokenref型を利用して行う。
【００４３】
書き換えを行ったトークンテーブルは図９のようになる。図９は、トークンテーブルの書き換えを例示する図である。employee_table2のindex＝１はemployee_table１のindex＝１を参照する。このため、tokenref型のindexである０x０f、employee_table１のindexである０x０１を記述する。また、employee_table2のindex＝５はemployee_table１のindex＝４を参照する。このため、tokenref型のindexである０x０f、employee_table１のindexである０x０１、さらにtable内のindexである０x０４を記述する。"Koizumi"の場合はtable内のindexがお互い異なるので、table内のindex（０４）も記述している。同様に、その他のエントリの書き換えも行う。
【００４４】
このように、Ｓ４０４〜Ｓ４０６では、第１のトークンテーブル（第１の対応情報）に含まれるボキャブラリ情報と、第２のトークンテーブル（第２の対応情報）に含まれるボキャブラリ情報とが共通する場合は、これらのトークンテーブルを統合する。具体的には、第１のトークンテーブルに含まれる該共通するボキャブラリ情報を、該第２のトークンテーブルに含まれる該共通するボキャブラリ情報への参照で置き換える処理を行っている。
【００４５】
全ての同じエントリに対し書き換え終えたならば、ステップＳ４０４に戻り、テーブルマップ内に未チェックのトークンテーブルが残っていないか確認する。未チェックのトークンテーブルがなくなったならば（ステップＳ４０４でＮＯ）、ステップＳ４０７において、トークンテーブルＡを結合文書データ（結合データ）に結合する。
【００４６】
次に、ステップＳ４０８において、図６のように、トークンテーブルＡを保存（結合）した場所の参照を、テーブルマップに記述する。テーブルマップのindexはトークンテーブルへの参照を記述するときに使われる。例えば、トークンテーブルへの参照は、構造化文書を識別する文書識別情報を用いてボキャブラリ情報を特定することができる。また、offsetはトークンテーブルを読み出すときに使われる。
【００４７】
次に、ステップＳ４０９において、符号化データがトークンテーブルＡを参照できるように、図１０のように、トークンテーブルＡを保存した場所への参照を符号化データに記述する。図１０は、結合データの構造を例示する図である。バイナリＸＭＬでは、トークンテーブルを外部参照する場合に、符号化データに参照先を記述することができる。この部分に、図６のテーブルマップを元に、トークンテーブルへの参照を記述する。
【００４８】
次に、ステップＳ４１０において、符号化データを結合データの一つのパートとして保存する。なお、データの結合は、例えば、ＺＩＰフォーマット、MIME Multipart/Relatedフォーマット等に基づいて行うことができる。
【００４９】
以降、結合したい文書データに対して、ステップＳ４０１〜Ｓ４１０の処理を繰り返し実行する。結合処理が終了したら、テーブルマップを保存する。テーブルマップは、結合データの一つのパートに入れて保存しても良いし、別のファイルに保存して参照するようにしても良い。
上記のように、本実施形態に係る構成では、各トークンテーブルに含まれるボキャブラリ情報が共通する場合は、これを統合するため、結合データ全体のサイズを小さくし、繰り返し記述の冗長性をさらに低減することができる。
【００５０】
また、以上のように本提案を実施することで、冗長部分を極力回避して結合したデータ全体のサイズを小さくすることができる。
【００５１】
＜＜実施形態２＞＞
本実施形態では、結合したデータの一部を削除した場合を考える。本実施形態に係る構成では、あるトークンテーブルが他のトークンテーブルのエントリを参照している。しかし、この場合、他から参照されているトークンテーブルを削除してしまうと、結合文書内のデータが読めなくなってしまう。そこで、次のようにしてデータの一部を削除できるようにする。
【００５２】
実施形態２に係る構成も、実施形態１と同様に図４のフローに沿って処理を実行する。実施形態２では、ステップＳ４０６において、エントリの書き換えを行う際に、図１１のようなテーブルマップへの書き込みを行う。図１１は、テーブルマップを例示する図である。本実施形態では、employee_table１はemployee_table2、employee_table3から参照されるので、これらのテーブルへの参照(０x０２,０x０３)を参照テーブルの項目に書き込む。employee_table2はemployee_table3から参照されるので、参照(０x０３)を参照テーブルの項目に書き込む。
【００５３】
つまり、テーブルマップを生成する際は、他のトークンテーブルから参照されているボキャブラリ情報を有するトークンテーブルと、該他のトークンテーブルとを関連付けてテーブルマップに記載する。本実施形態ではトークンテーブルの関連づけを、対応する構造化文書の文書識別情報によって行う。
【００５４】
結合したデータの一部を削除するときは、結合データに付随する図１１のテーブルマップを確認する。本実施形態における２番目の表データを削除したい場合は、employee_table2が削除される。employee_table2はテーブルマップを見ると、employee_table3から参照されている。そこで、eployee_table3を検索し、index＝６が参照を行っているので、employee_table2への参照から"Yamamoto"に置き換える。
【００５５】
つまり、指定された構造化文書に対応するトークンテーブルが、他のトークンテーブルから参照されているボキャブラリ情報を有する場合は以下の処理行う。まず、この他のトークンテーブルにおいてボキャブラリ情報から参照に置換されていた箇所を、置換前のボキャブラリ情報に復元する。次に、ボキャブラリに復元した後に、結合データから指定された構造化文書に相当する箇所を削除する。
【００５６】
このように、本実施形態に係る構成では、他のトークンテーブルから参照されているトークンテーブルに対応する構造化文書に相当する箇所を削除する際は、他のトークンテーブルにおける参照をボキャブラリ情報に復元してから削除する。このため、削除処理の後も、トークン情報とボキャブラリ情報との対応関係が維持されるため、この「他のトークンテーブル」に対応する符号化データから構造化文書を復元することができる。
【００５７】
＜＜実施形態３＞＞
本実施形態では、ある文書データのトークンテーブルが、他方の文書データのトークンテーブルを包含している場合を考える。この場合、実施形態１のように、一方のテーブルが他方のテーブルのエントリを参照することで、結合時のデータサイズを小さくすることができる。しかし次のようにすることで、片方のトークンテーブル自体を不要にし、さらにデータサイズを小さくすることができる。
【００５８】
本実施形態に係る構成も、実施形態１と同様に図４のフローに沿って処理を実行する。但し実施形態３では、ステップＳ４０６において、図１２のフローに沿った処理を実行する。図１２は、不要なトークンテーブルを削除する処理の流れを示すフローチャートである。
【００５９】
ステップＳ１２０１において、トークンテーブルのエントリを削除できるかどうか判定する。判定方法としては、各トークンテーブル間のボキャブラリを比較し一方のテーブルに含まれるボキャブラリが他方のテーブルに含まれるボキャブラリを完全に包含していれば削除できるとみなす。また、完全ではなくても、ある一定エントリ数以上であれば削除できるとみなすこともできる。削除できると判定した場合はステップＳ１２０２へ進み、そうでない場合はステップＳ４０６へ戻る。
【００６０】
図１３は、本実施形態で結合する文書データの一例を示す図である。employee_table5のトークンテーブルはemployee_table4のトークンテーブルにボキャブラリ情報が包含されている。そこでステップＳ１２０１において削除できると判定しステップＳ１２０２へ進む。
【００６１】
次にＳ１２０２において、符号化データの書き換えが必要かどうかを判定する。片方のトークンテーブルのエントリを削除するには、両方のテーブルでボキャブラリに対するトークンが一致していなければならない。一致していない場合は、一致させるために符号化データの書き換えを行う。本実施形態ではトークンはindexである。図１３において、両方のテーブルのボキャブラリ”Saitoh”は同じindexではないので、符号化データの書き換えが必要と判定しステップＳ１２０３へ進む。
【００６２】
ステップＳ１２０３において、符号化データの書き換えを行う。先ず、既存のトークンに対し、テーブル間で一致させるトークンを決定する。次に、テーブル内の他のトークンに対し、決定したトークンによって衝突が発生していないかどうかを確認する。発生している場合は、重複しない一意なトークンを割り振り衝突を回避する。割り当てが完了したならば、符号化データをデコードし、新しいトークンに置き換えエンコードする。
本実施例では、“Saito”にindex=5というトークンを割り当てる。既存の他のトークンとの衝突は発生していなので、この時点で割り当て完了になる。割り当てに従い再エンコードしたデータを図１４に示す。indexが3から5に変わったことで、符号が0x83から0x85に変わっている。
【００６３】
そしてステップＳ１２０４において、不要になったテーブルエントリを削除し文書データを結合する。結合した結果を図１５に示す。employee_table5のトークンテーブルは不要なので全て削除される。employee_data5は、employee_table4のトークンテーブルを参照するように記述される。
【００６４】
上記のように、本実施形態では、複数のトークンテーブルが存在するときに、不要なトークンテーブルを特定して削除することによって、データ全体のサイズをさらに小さくすることができる。
【００６５】
＜＜その他の実施形態＞＞
なお、上記の構成では、ボキャブラリ情報が共通する場合は常にトークンテーブルを統合したが、必要がない場合は統合を行わなくても構わない。例えば、参照情報のビット長が置換前のボキャブラリ情報のビット長よりも長い場合にも参照への置換を行うと、置換によってかえって結合データのサイズが大きくなってしまう。このため、参照情報のビット長が置換前のボキャブラリ情報のビット長よりも長い場合や、参照情報のビット長が一定の長さを超える場合は、トークンテーブルにおけるボキャブラリ情報の置換を行わないようにしてもよい。
【００６６】
また、結合データにおいて、トークンテーブルの参照先の位置と、参照元の位置とが離れている場合は、結合データを復号する際にトークンテーブルを閲覧する処理に時間がかかる場合がある。このため、結合データ内における参照先の位置と参照元の位置との間の距離が一定以上の場合は、ボキャブラリ情報の置換を行わないようにしてもよい。
【００６７】
以上、本発明の実施形態例について詳述したが、本発明の目的は、前述した実施形態の機能を実現するソフトウエアのプログラムコードをシステムあるいは装置で実行することによっても達成されることは言うまでもない。この場合、プログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードは本発明の技術的範囲に含まれる。
【００６８】
プログラムコードは、例えば、コンピュータ読み取り可能な記録媒体に記録してシステムあるいは装置に供給することができる。そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）は、記録媒体に格納されたプログラムコードを読み出し実行することによっても、本発明の目的を達成することができる。従って、そのプログラムコードを記憶した記録媒体も本発明の技術的範囲に含まれる。
【００６９】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【００７０】
なお、プログラムコードは、コンピュータが当該プログラムコードを読み出し実行することにより前述した実施形態の機能を実現するための、全ての要素を備えたものに限られない。即ち、プログラムコードには、コンピュータに組み込まれたソフトウェア及びハードウェアの少なくともいずれかと協働することにより目的を達成するプログラムコードも含まれる。
【００７１】
例えば、プログラムコードの指示に基づき、コンピュータに挿入又は接続された機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合がある。このような場合も、そのプログラムコードは本発明の技術的範囲に含まれる。なお、機能拡張ボードや機能拡張ユニットは、それらが備えるメモリにプログラムコードを読み込み、実行することでこのような処理を行うことができる。
【００７２】
上述の構成によれば、複数の構造化文書を一つに結合した文書データにおいて、各構造化文書で作成されたトークンテーブルの重複を共通化する。このため、構造化文書間での繰り返し記述の冗長性を低減でき、ワープロ文書などのサイズ縮小を実現することができる。
【図面の簡単な説明】
【００７３】
【図１】文書データ符号化装置のハードウェア構成を示すブロック図である。
【図２】ISO/ITU-T標準のFast Infosetの一例を示す図である。
【図３】表データをexportしてＸＭＬデータにする様子を例示する図である。
【図４】複数のバイナリＸＭＬを結合する結合処理のフローを示すフローチャートである。
【図５】データ形式の対応表を例示する図である。
【図６】結合データとテーブルマップの例を示す模式図である。
【図７】ＸＭＬ文書、トークンテーブル、符号化データの対応を例示する図である。
【図８】データ型の定義例を示す図である。
【図９】トークンテーブルの書き換えを例示する図である。
【図１０】結合データの構造を例示する図である。
【図１１】テーブルマップを例示する図である。
【図１２】不要なトークンテーブルを削除する処理の流れを示すフローチャートである。
【図１３】結合する文書データの一例を示す図である。
【図１４】割り当てに従い再エンコードしたデータの一例を示す図である。
【図１５】不要になったテーブルエントリを削除し文書データを結合した結果の一例を示す図である。
【図１】
2009140470.tif 000003
【図２】
2009140470.tif 000004
【図３】
2009140470.tif 000005
【図４】
2009140470.tif 000006
【図５】
2009140470.tif 000007
【図６】
2009140470.tif 000008
【図７】
2009140470.tif 000009
【図８】
2009140470.tif 000010
【図９】
2009140470.tif 000011
【図１０】
2009140470.tif 000012
【図１１】
2009140470.tif 000013
【図１２】
2009140470.tif 000014
【図１３】
2009140470.tif 000015
【図１４】
2009140470.tif 000016
【図１５】
2009140470.tif 000017