JP2007293698A - 文書管理システムおよび文書管理プログラム - Google Patents

Abstract

【課題】文書に含まれる部分文書の文書間の引用履歴を管理可能な技術を提供すること。
【解決手段】ユニークな識別子である文書ＩＤが付与された文書と前記文書中にあらかじめ定義された範囲の文書片であり、ユニークな識別子である部分文書ＩＤが付与された部品文書とを管理する手段０１０１と、前記部分文書がある文書から他の文書へ引用された場合に、当該引用履歴を記録する手段０１０２と、前記文書間で前記部品文書のコピー・ペースト操作を許可し、それ以外の範囲の文書片のコピー・ペースト操作を禁止する手段０１０３とを備えた。
【選択図】 図１

Description

本発明は、文書の格納、編集、及び引用管理を行うための技術に関する。

文書管理システムとして、例えば特許文献１（特開２００４−１４５７４３号公報）及び特許文献２（米国特許第６，４９３，７３１号）に記載されたものが知られている。これらの文献には、管理している文書を自由に編集することができることが記載されている。また、そのような引用操作が行われた場合には、どの文書からどの文書へ引用が行われたかという情報を履歴として蓄積することが記載されている。しかし、特許文献１及び特許文献２に記載されたシステムでは、どの文書からどの文書へ引用が行われたかという履歴を蓄積しているが、文書中のどのような文書片が引用されたかを記録していない。

なお、特許文献３（特開２００４−１４５７４３号公報）には、蓄積された引用履歴を表や有効グラフなどの形式で表示する機能を有するシステムも知られている。

また、特許文献４（特開２００４−４６３５７号公報）には、構造化文書の中に含まれるコンテンツを、それよりさらに細かい操作単位としてのサブコンテンツ単位で容易に編集することができる技術を開示している。この技術では、構造化文書に一致または含まれる、少なくとも１つの要素からなる予め操作単位として定められた部分文書に、少なくとも当該部分文書が操作単位であることを表す情報が含まれており、この情報を基に、少なくとも当該部分文書と当該部分文書の位置情報とを含む部分文書毎の部品データを作成して、構造化文書を部品データの集合として記憶しておき、操作対象として選択された前記部分文書に対する操作内容に応じて、当該操作対象の部分文書に対応する部品データを更新することにより構造化文書を編集するようにしている。しかし、特許文献３には、文書片の文書間の引用に関する記載はない。
特開２００４−１４５７４３号公報 米国特許第６，４９３，７３１号 特開２００４−１４５７４３号公報 特開２００４−４６３５７号公報

本発明は、文書に含まれる部分文書の文書間の引用履歴を管理可能な技術を提供することを目的とする。

本発明では、文書編集機能を限定する代わりに、引用履歴として、どの文書からどの文書へどのような文書片が引用されたかという情報を記録することに特徴がある。
具体的には、本発明の局面に係る発明は、ユニークな識別子である文書ＩＤが付与された文書と前記文書中にあらかじめ定義された範囲の文書片であり、ユニークな識別子である部分文書ＩＤが付与された部品文書とを管理する手段と、前記部分文書がある文書から他の文書へ引用された場合に、当該引用履歴を記録する手段と、前記文書間で前記部品文書のコピー・ペースト操作を許可し、それ以外の範囲の文書片のコピー・ペースト操作を禁止する手段と、を具備することを特徴とする。

本発明によれば、文書に含まれる部分文書の文書間の引用履歴を管理可能な技術を提供することができる。

図面を参照して本発明の実施の形態を説明する。

（第１の実施形態）
図１は、本発明の第１の実施形態に係る文書管理システムの概略構成を示す図である。本実施態様に係る文書管理システムは、文書管理部０１０１と、引用履歴管理部０１０２と、文書編集部０１０３と、引用履歴可視化部０１０４と、引用文書オープン部０１０５と、文書関連性分析部０１０６とを備えている。これらの各部は、通常の汎用コンピュータ（例えば、パーソナルコンピュータＰＣ）で実現可能であり、例えば、文書管理部０１０１や引用履歴管理部０１０２は、ＷｅｂサーバやＰＣのハードディスクなどの記憶装置と、それらの動作を制御したり、その他の必要な処理を実行するプログラムモジュールで構成され、文書編集部０１０３〜文書関連性分析部０１０６は、それぞれの役割を実行するプログラムモジュールで構成される。これらのプログラムモジュールは、図示しないＣＰＵで実行され、所定の処理を行う。なお、図１において、文書管理部０１０１〜文書関連性分析部０１０６の各部（以下、「モジュール」と称する場合もある）の間を結ぶ線はデータあるいは命令が交換される可能性があることを示している。なお、本実施態様では、文書管理部０１０１と、引用履歴管理部０１０２は、外部サーバに用意されているものとして説明する。また、以下の説明においては、文書管理部０１０１と引用履歴管理部０１０２は、Ｗｅｂサーバに置かれているものとして説明する。ここにおいて、文書管理部０１０１と引用履歴管理部０１０２が、Ｗｅｂサーバそのものであっても良い。

本実施態様に係るシステムは、主に、以下の６つの機能要素から構成されている。なお、機能の次に括弧書きで示したモジュールは、各機能を実現する上で主な働きをするモジュールであることを意味する。
（１）文書編集機能（文書編集部０１０３＋文書管理部０１０１）
（２）引用履歴の格納機能（文書編集部０１０３＋引用履歴管理部０１０２）
（３）引用の表示機能（引用履歴可視化部０１０４＋文書編集部０１０３＋引用履歴管理部０１０２）
（４）引用履歴のオープン機能（引用文書オープン部０１０５＋引用履歴管理部０１０２＋文書管理部０１０１）
（５）文書関連性分析機能（文書関連性分析部０１０６＋引用履歴管理部０１０２＋文書管理部０１０１）
上記のように、本実施態様では、各機能に対して異なるモジュールが主に活躍するような構成となっている。なお、上記の構成は、以降の実施形態についても同様である。上記のような構成において、各機能の詳細について説明する。

（１）文書編集機能
文書編集機能は、基本的に、文書を文書管理部０１０１から取り出す機能と、文書を編集する機能と、文書編集結果を文書管理部０１０１にアップロードする機能とを備えている。以下、具体的に説明する。

（１−１）文書の取り出し
文書管理部０１０１は、複数の文書を有する文書群を蓄積しており、これらの文書には、それぞれＩＤが付されている。ユーザは、文書編集部０１０３に所望文書のＩＤを入力することで、文書管理部０１０１から、所望の文書を取り出すことができる。

本実施態様に係る文書管理システムの１つの実施例としてＷｅｂシステムに類似した形態で実現した例について説明する。具体的には、Ｗｅｂサーバに文書管理部０１０１が置かれており、文書管理部０１０１に蓄積されている各文書には固有のＩＤとしてＵＲＬが割り当てられている。一方、文書編集部０１０３は、ＨＴＭＬなどの公知の形式のＷｅｂページを表示することができるＷｅｂブラウザの１種であり、一般的なＷｅｂブラウザと似たＧＵＩ構成を持っている。図２は、文書編集部０１０３による編集画面の画面例を示す図である。

図２に示すように、編集画面は、「ＵＲＬテキストボックス」と、「メイン領域」と、「更新ボタン」とで構成されている。ここで、ユーザが、図示しないキーボードなどの入力装置からＵＲＬテキストボックスに所望文書のＵＲＬを入力すると、該当する文書が文書管理部０１０１からダウンロードされて、メイン領域に表示される。このメイン領域に表示された文書は、詳細は後述するように、文書編集部０１０３によって編集ができるようになっている。

文書を取得際に、ＵＲＬを用いずに、文書ＩＤを用いる方法もある。その場合には、文書ＩＤを入力するＨＴＭＬフォームページを通じて所望の文書を取得するという方法で良い。この文書ＩＤは、後述の引用に関する機能で重要な役割を果たすものであり、各文書に対してユニーク性と一貫性が補償されていなければならない。それに対してＵＲＬは文書ＩＤとしては不確かという面がある。例えば、ＣＧＩのＷｅｂページの場合、同じＵＲＬであっても取得するごとに内容が異なるということが可能である。文書をユニークなものとして取得するために、本実施形態では、文書取得にはＵＲＬを用い、文書ＩＤとしてはルートエレメントのｐｚ：ｉｄを用いる方式を採用する。

（１−２）文書の編集
文書の編集は、部品定義がなされた文書を処理対象として行われる。部品定義がなされた文書とは、当該文書において、編集可能な文書片である「部品文書」を含む文書をいう。この編集は、特許文献３に記載された方式などを用いて行う。以下、その方式について、図３を参照して、簡単に紹介する。

図３は、文書管理部０１０１からダウンロードされた文書であって、文書編集機能で取り扱う文書の一例を示す図である。図３（ａ）にダウンロードした文書例を示す。以下の文書が、ダウンロードした文書の文書例である。

<?xml version="1.0"?>
<cats pz:id="xks" ps:style="cats.xsl" xmlns:ps="http://www.toshiba.co.jp/ps">
<title>tos shopping catalog</title>
<date>2005/10/06</date>
<cat pz:id="0001" pz:component="yes" ps:style="cat.xsl">
<img>note.jpg</img>
<name>tos notepc x</name>
<price>120000</price>
<hdd>250<hdd>
<memory>256</memory>
</cat>
<cat pz:id="0002" pz:component="yes" ps:style="cat.xsl">
<name>tos deskpc a</name>
<img>desk.jpg</img>
<price>220000</price>
<hdd>200<hdd>
<memory>512</memory>
<cat pz:id="0003" pz:component="yes" ps:style="cat.xsl">
<img>disp.jpg</img>
<name>tos display1</name>
<price>50000</price>
<screensize>17</screensize>
</cat>
</cat>
</cats>
上記の文書例において、３つの部品文書が定義されており、それぞれ<cat pz:id="0001" pz:component="yes" ps:style="cat.xsl">、<cat pz:id="0002" pz:component="yes" ps:style="cat.xsl">、及び<cat pz:id="0003" pz:component="yes" ps:style="cat.xsl">から始まり、</cat>で終了する部品文書となっている。ここで、「pz:component」という属性は、その属性が属するエレメントではさまれた範囲の文書片が部品文書であるということを宣言しており、かつその部品文書に対するドラッグ・ドロップ操作あるいはコピー・ペースト操作の可否を示すものであって、”yes”は当該部品文書のドラッグ・ドロップ操作あるいはコピー・ペースト操作が可能であることを示している。ここで、３番目の部品文書は、２番目の部品文書に対して入れ子構造となっており、図３（ａ）に定義された文書を文書編集部０１０３にロードすると、図３（ｂ）に示したようなイメージで表示される。図３（ｂ）において、点線で示した部分は、部品文書としての境界線であり、各部品文書は、「pz:style」で示されたスタイルシートによって、ビューとして展開されている。

上記のように、本発明の実施形態では、取り扱う文書を部品文書の入れ子として定義された複合文書としている。部品文書とは、文書作成者が再利用単位として定義した文書片である。本発明の文書編集機能では、部品文書の単位でしか、コピー・ペーストなどの再利用作業を許可しないという限定をしている。このことから、本発明では、文書間での文書片のコピー・ペースト操作（すなわち「引用操作」）は部品文書の単位でのみ可能である。なおこの部品編集機能については特許文献３に記載された実現方法を利用できる。なお文書および文書片と述べるものは、単なるテキストのみならず、たとえばＨＴＭＬのような画像、音声、映像などを含むマルチメディア文書も対象とする。

図３（ｂ）に示す文書編集部０１０３によって表示された文書では、各部品文書に対してドラッグ・ドロップ操作あるいはコピー・ペースト操作ができるようになっている。これにより、部品文書という単位での文書片の再利用が可能である。これらの操作は文書間でも実行可能であり、これにより部品文書単位での引用ができる。なお、部品文書以外の範囲でのドラッグ・ドロップ操作（あるいはコピー・ペースト操作）はできないようになっている。また、ドラッグ・ドロップ操作（あるいはコピー・ペースト操作）によってやりとりされる部品文書の具体的内容は、その部品文書に対応する「pz:component」属性を持つエレメント以下の文書片である。

また各部品文書には、「pz:id」という特別な属性が割り当てられている。これは、各部品文書に対してユニークに与えられているＩＤを記述しているもので、以下、「部品文書ＩＤ」と呼ぶ。部品文書ＩＤは、後続の引用履歴の格納処理、引用の表示機能、引用履歴のオープン機能、文書関連性分析部０１０６、引用履歴貼付け機能で用いるものであるため、ここではその説明を省略する。以上が特許文献３に記載された方式に基づいて実現した部品文書の再利用の機能である。

本発明は、後述する引用履歴機能を実現した点に特徴を有する。この機能を実現するための要件は「再利用できる文書片単位があらかじめ定められており、かつ各文書片にＩＤが割り振られており、それ以外の文書片の範囲では再利用できないようになっていること」である。したがって、この要件を満たしていれば、文書編集機能の実現には他の方式が用いられても良い。

また、文書編集機能によって、このような部品引用操作のほかに、部品文書の削除が可能である。この場合において、特定の部品文書を指定して削除操作を行うと、その部品文書を削除することが可能である。この削除機能を加えることで、基本的な部品操作機能が取りそろうことになるが、本明細書では部品文書の引用履歴を特徴とするため、削除については説明を省略する。

また特許文献３に記載の方式を用いて、このような部品操作のほかに、部品文書のコンテンツの編集機能などもオプショナルとして具備することも可能である。これにより高い編集性をユーザに提供することができる。ただし、コンテンツの編集機能においても、「pz:」から始まる特別な命令の値を変更することはできないように実装する必要がある。

（１−３）文書編集結果のアップロード
文書編集部０１０３で行われた文書編集結果を文書管理部０１０１にアップロードするには、図２の「更新ボタン」をクリックする。そうすると、当該ＵＲＬとともに文書内容がアップロードされる。文書管理部０１０１は、ＵＲＬを文書ＩＤとみなし（または文書中に文書ＩＤが記載されている場合はそのＩＤ値を用いる）、新しく送信されてきた文書内容を、当該ＩＤに対応する内容として上書き格納する。

（２）引用履歴の格納処理
引用履歴の格納処理は、文書編集機能のバックグランドとして働く処理である。基本的な動作は、以下の通りである。文書編集機能において、ユーザが文書を編集する際に、文書間での引用作業が行われると、文書編集部０１０３が引用履歴管理部０１０２に対して対応する履歴レコードをアップロードする。そして、引用履歴管理部０１０２がその履歴レコードを格納する。

具体例として、文書編集部０１０３を２つ起動してそれぞれ文書Ａと文書Ｂを開き、文書Ａから文書Ｂに対して部品文書Ｘを引用した場合を例に取って説明する。ただし、Ａ、Ｂはそれぞれ文書ＩＤ、Ｘは部品文書ＩＤである。この場合における引用履歴の格納処理の詳細を図４に示す。図４は、引用履歴の格納処理の手順を示すフローチャートである。

文書編集部０１０３は、Ａ、Ｂ、Ｘおよび現在時刻を元に引用履歴レコードを生成する（ステップ０４０１）。この場合において、時刻の厳密化を求める場合はミリセカンドまで精度を高めても良い。次に、文書編集部０１０３は履歴レコードを引用履歴管理部へ送信する（ステップ０４０２）。そして、引用履歴管理部０１０２は受理した引用履歴レコードにユニークな履歴レコードＩＤを付与し（ステップ０４０３）、引用履歴レコードをデータベースなどに蓄積する（ステップ０４０４）。

上記の処理において、引用履歴レコードは、
履歴レコードＩＤ、
時刻、
引用元文書ＩＤ、
引用先文書ＩＤ、
引用対象の部品文書ＩＤ
のような項目を持つようなスキーマである。

（３）引用の表示機能
引用の表示機能は、引用履歴管理部０１０２において蓄積されている引用履歴レコード群をユーザ向けに表示する機能であり、中心的役割を果たすモジュールは、引用履歴可視化部０１０４である。表示形式として、テーブル表示形式および有向グラフ表示形式の２種類がある。

テーブル表示形式とは、図５に示すように、履歴レコードを単に時系列に列挙する表示形式である。有向グラフ表示形式とは、詳細は後述する図８に示すように、文書をノードとし、文書間で行われた引用のやりとりをアーク（ノード間を結ぶ矢印）として有向グラフ化し、さらにアーク上に引用された部品文書を時刻、ＩＤつきで表示する形式である。

実際には、引用履歴可視化部０１０４は、テーブル表示向けと有向グラフ表示向けで、それぞれ独立的なサブモジュールに分かれている。ここでは、それぞれのモジュールを、引用履歴テーブル表示形式出力部と有向グラフ表示形式出力部と呼ぶ。以下、各モジュールの処理を説明する。

（３ー１）引用履歴テーブル表示形式出力部
本発明の一実施形態に係る文書システムにおいて、引用履歴テーブル表示形式出力部は、一般的なＣＧＩとして実装している。図６は、引用履歴テーブル表示形式出力部０６０１を用いてテーブル表示を行う場合の概要について説明するための図である。

文書編集部０１０３において、Ｗｅｂブラウザ上の検索条件を入力するためのＨＴＭＬフォームページ０６０２が表示されているものとする。そこで、ＨＴＭＬフォームページ０６０２に引用履歴の検索条件を入力すると、該検索条件がＨＴＴＰ ＰＯＳＴなどの通信方式でＷｅｂサーバに検索要求として送信される。なお、ＨＴＭＬフォームページ０６０２において、時刻のみ時間の範囲を指定するようになっている。また、検索条件の各項目はすべて埋める必要はない。すべての項目を空にした場合（すなわち、何も入力しない場合）は、すべての履歴レコードが検索条件に該当することになる。

この検索要求を受けてＷｅｂサーバ上に設置されているＣＧＩである引用履歴テーブル表示形式出力部０６０１が起動される。なお、ＨＴＭＬフォームページ０６０２のようなＧＵＩからではなく、他モジュールからＡＰＩとして引用履歴テーブル表示形式出力部０６０１機能を呼び出すことももちろん可能である（引用履歴テーブル表示形式出力部０６０１の左側に記載しているロリポップ記号は、ＡＰＩ受信口を示す際に慣例的に用いられる記号である）。その場合は、他モジュールはプログラム内部でＨＴＴＰ ＰＯＳＴを送信する処理となる。実際、後述の機能ではＡＰＩとして当該機能を呼び出すようになっている。

引用履歴テーブル表示形式出力部０６０１の入力パラメータは、履歴レコードＩＤ、時間（開始時刻および終了時刻）、引用元文書ＩＤ、引用先文書ＩＤ、引用対照の部品文書ＩＤの６つである。検索条件作成においては、これらはすべてＡＮＤとして解釈される。また、省略パラメータに対しては、前述のように無条件として解釈される。

引用履歴テーブル表示形式出力部０６０１は、受信した検索条件をＳＱＬなどに翻訳して、引用履歴管理部０１０２に蓄積されている引用履歴レコードを検索する。そして、検索の結果、取得した引用履歴レコード群（１つでも良い）を元にＨＴＭＬページを生成して、ＨＴＴＰレスポンスとしてＷｅｂブラウザ（文書編集部０１０３）に返す。するとＷｅｂブラウザは、当該ＨＴＭＬページ０６０３を表示する。

検索結果を出力するＨＴＭＬページ０６０３に掲載されているテーブルは、履歴レコードＩＤ、時刻、引用元文書ＩＤ、引用先文書ＩＤ、引用対象の部品文書ＩＤの５つのカラムを用意している。このテーブルには、次のような機能が提供されている。テーブル上に用意されたカラムのうち、引用元文書ＩＤカラム、引用先文書ＩＤカラム、引用対象の部品文書ＩＤカラム上に表示されているＩＤ値をクリックすると、該当する文書あるいは部品文書が、文書編集部０１０３によって表示される。その動作詳細を、図７を参照して、説明する。

図７は、文書ＩＤや部品文書ＩＤから文書を問い合わせる動作の概要を示す図である。図７において、Ｗｅｂサーバは、文書検索部０７０１を備えている。また、ＨＴＭＬページ０６０３は、図６のＨＴＭＬページ０６０３と同様のＨＴＭＬページであり、文書編集部０１０３上で表示されている画面である。

ＨＴＭＬページ０６０３において、ここでは、引用元文書ＩＤカラム、引用先文書ＩＤカラム、引用対象の部品文書ＩＤカラムに表示されている各ＩＤの値はハイパーリンクとなっていて、そのリンク先がＣＧＩとして実装されている文書検索部０７０１となっている。そして、当該ハイパーリンクをクリックすると、そのＩＤ値を付けてＨＴＴＰ ＰＯＳＴまたはＧＥＴなどで文書検索部０７０１へ検索要求がかかる。

文書検索部０７０１は受信したＩＤを元に、文書管理部０１０１に対して文書検索をかける。文書管理部０１０１では、文書および部品文書はすべて異なるＩＤを持つようにＩＤを発番しており、ＩＤを元に一意に資源（すなわち、文書および部品文書）が決定されるようになっている。この検索結果として得られた文書あるいは部品文書をＨＴＴＰレスポンスとして返す。すると、文書編集部０１０３は、該当する文書または部品文書０７０３を表示する。

なおここでの処理においては無関係であるが、文書または部品文書のＩＤを入力するＨＴＭＬフォームページ０７０２のように、通常ＨＴＭＬページからＩＤを入力させる画面を用意して当該機能を利用する仕組みを用意することができる。これを利用して、最初に文書を開く際の文書問い合わせ方法として、ＵＲＬを入力する方法のほかに、文書ＩＤを入力する方法を提供することも可能である。

（３−２）有向グラフ表示形式出力部
上記のように、引用履歴は、有向グラフで表示することができる。図８は、引用履歴レコードの有向グラフ表示形式例を示す図である。この引用履歴有向グラフで表示する機能は、主に、図９のような構成で動作する。図９は、引用履歴の検索から検索結果を有向グラフで表示する場合の動作の概要を示す図である。この場合において、Ｗｅｂサーバは、更に、有向グラフ表示ＣＧＩ０９０１と、有向グラフ生成部０９０２と、前向き有向グラフ生成部０９０３と、後ろ向き有向グラフ生成部０９０４とを備えている。

上記の構成において、引用履歴テーブル表示機能での方式と同様に、システムの最前線の入力インターフェースとなる有効グラフ表示ＣＧＩ０９０１は、ＣＧＩとして作成されており、ＨＴＭＬページ０９０５や文書編集部０１０３などからのＨＴＴＰ ＰＯＳＴ要求などによって起動することができる。そして、グラフ作成処理結果がＨＴＭＬページ０９０６のように、文書編集部０１０３に返される。

また引用履歴テーブル表示機能における引用履歴テーブル表示形式出力部０６０１と同様に、ＨＴＭＬページ０９０５のような検索画面からしか有効グラフ表示ＣＧＩ０９０１を起動することができないわけではなく、別モジュールのプログラムからＡＰＩ的に呼び出すことも可能である（引用履歴テーブル表示形式出力部０６０１に記載のロリポップ記号はＡＰＩ受信口を示す慣例的な記号である）。

この場合において、引用履歴の検索に係る入力としては「起点部品文書ＩＤ」「追跡文書ＩＤ」「ホップ数」「時刻上限」の４つであり、これらは１つも省略してはならない。そして、これらの入力は引用履歴レコードの検索条件として扱われる。ここで、起点の文書ＩＤは、グラフ生成する際において、開始地点となるノードとなる。起点の部品文書ＩＤは、グラフ化に際して、やりとりを追跡する対象とする部品文書を指定している。ホップ数は、グラフ生成の際に、開始地点ノードからの距離の上限である。ホップ数が５であれば、５を超える距離のノードは生成しないでそれ以上は打ち切りとなる。時刻上限とは、引用履歴を検索する際の時刻の上限であり、検索の際には、指定された時刻上限を超えない最近の引用履歴を探す。

このようにして図８に示すグラフが生成される。有効グラフ表示ＣＧＩ０９０１が作るグラフには、その生成過程における探索アルゴリズムから、次のような特徴がある。
１． 指定された起点文書を開始ノードとする。
２． 指定された追跡部品文書ＩＤの引用のやりとりのみを検索対象として、グラフを拡大する。
３． 引用のやり取りは前方、後方の両方を対象とする、すなわち引用先を漸次的に追いかける前方、引用元を漸次的に追いかける後方の両方でグラフを拡大する。
４． グラフ拡大における第一歩、すなわち起点文書しかノードがない瞬間のグラフ拡大（ホップ数１）においては、時刻上限を超えない最近の引用履歴を対象とする。
５． グラフ拡大においては、指定されたホップ数を超えるとき、その枝についてはそれ以上のグラフ拡大は行わない。
これにより、注目したい特定の部品文書がどのような経路で文書間をやりとりされたのかを可視化することができる。

また、本発明の実施形態では、文書片の表層的な内容一致を元に引用の流れを追跡しているのではなく、部品文書ＩＤをベースとしてコンテンツのやり取りを追跡しているため、引用された文書片（すなわち、部品文書）が改変されていたとしても追跡できる。なおグラフ生成処理の実際としては、有効グラフ表示ＣＧＩ０９０１が単独で行うのではなく、有向グラフ生成部０９０２、前向き有向グラフ生成部０９０３、後ろ向き有向グラフ生成部０９０４が部分的な処理を行った結果をまとめる形で、有効グラフ表示ＣＧＩ０９０１が最終結果を返すようになっている。具体的な、処理の流れを、図１０を参照して説明する。図１０は、引用履歴レコード有向グラフ表示モジュール群（有効グラフ表示ＣＧＩ０９０１〜後ろ向き有向グラフ生成部０９０４）の連携処理の流れを示す図である。

まず、有効グラフ表示ＣＧＩ０９０１は外部からのＨＴＴＰ ＰＯＳＴを受信し、検索条件である追跡部品文書ＩＤ、起点文書ＩＤ、ホップ数、時刻上限を取り出す。有向グラフ生成部０９０２にこれらの項目を入力として、グラフ生成を要求する（ステップ１００１）。有向グラフ生成部０９０２は４つのパラメータを受け取り、起点文書ＩＤを元にノードを生成する（ステップ１００２）。ここで、ノードには起点文書ＩＤをデータとして書き込む。

次に、有向グラフ生成部０９０２は、４つのパラメータおよび起点文書に対応するノードを入力として、前向き有向グラフ生成部０９０３を呼び出し、前向きグラフを生成させる（ステップ１００３）。これにより、前方側のグラフが完成する（前向きグラフの生成方法の詳細は後述する）。なおノードを引数として渡すとき、すでにグラフ構造ができている場合は、それらの構造も紐付けされた状態で渡される。

有向グラフ生成部０９０２は、４つのパラメータおよび起点文書に対応するノードを入力として、後ろ向き有向グラフ生成部０９０４を呼び出し後ろ向きグラフを生成させる（ステップ１００４）。これにより、後方側のグラフが完成する（後ろ向きグラフの生成方法の詳細は後述する）。なおノードを引数として渡すときに、すでにグラフ構造ができている場合は、それらの構造も紐付けされた状態で渡される。

有向グラフ生成部０９０２は、完成したグラフを有効グラフ表示ＣＧＩ０９０１に返す（ステップ１００５）。有効グラフ表示ＣＧＩ０９０１は有向グラフ生成部０９０２から受け取ったグラフ構造データを読み取り、それを視覚的に表現するＨＴＭＬ形式の文書に変換する。また各ノードはクリックすれば、対応する文書が開くようにハイパーリンクをしかける。また各アーク上に記載されている部品文書についても、同様に対応する部品文書が開くようにハイパーリンクを仕掛ける。このハイパーリンク先は、文書検索部０７０１のようにＩＤを検索条件として対応する文書を開くＣＧＩとすればよい。この変換結果を、ＨＴＴＰレスポンスとして返す（ステップ１００６）。

上記において、前向きグラフの生成方法（前向き有向グラフ生成部０９０３による処理）および後ろ向きグラフの生成方法（後ろ向き有向グラフ生成部０９０４による処理）について、以下に詳細に説明する。

（３−３）有向グラフ表示形式出力部の前向き有向グラフ生成手順
前向き有向グラフ生成処理は、前向き有向グラフ生成部０９０３が主体となって行うものであり、前向き有向グラフ生成部０９０３は、入力引数として、起点文書ＩＤ、追跡部品文書ＩＤ、ホップ数、時刻上限、カレントノードの５つのパラメータを、有向グラフ生成部０９０２から受け取る。なお、引数として渡されたカレントノードにグラフ構造ができている場合は、それらの構造も紐付けされた状態で渡される。したがってすでにグラフ構造がある程度構築されている場合は、その続きの構築作業ができるようになっているものとする。図１１は、前向き有向グラフ生成部０９０３による前向き有向グラフの生成手順を示すフローチャートである。

前向き有向グラフ生成部０９０３は、ホップ数を判定する。ホップ数０なら終了する（ステップ１１０１）。そして、次の条件で引用履歴管理部から履歴レコードを検索する（ステップ１１０２）。
履歴レコードＩＤ＝無指定
時刻＜時刻上限
引用元文書ＩＤ＝起点文書ＩＤ
引用先文書ＩＤ＝無指定
引用対象の部品文書ＩＤ＝追跡部品文書ＩＤ
ソート方法：時刻で降順
件数上限：５件
なお、上記の検索条件において、件数上限５というのは、当該ノードを起点として前向き方向に展開されるノード数の上限となる。この理由は、ノード数が多いとグラフが見難くなるためである。もしより多くの展開数で出力するシステムにした場合はこの数を増やして実装すればよい。

検索の結果得られた履歴レコード群それぞれに対して、ステップ１１０４からステップ１１０８の処理を行う（ステップ１１０３）。
まず、注目する履歴レコードについて次の処理を行う（ステップ１１０８）。
（１）グラフ上に存在するノード群から、引用先文書ＩＤに対応するノードがあるどうか探索する。もしすでに存在すれば、１１０３に戻る。もしなければ次の（２）と（３）の処理を行う（ステップ１１０４）。
（２）ノードを新規作成し引用先文書ＩＤをデータとして記載する。
（３）カレントノードから引用先文書ノードへアークで結び、アーク上に部品文書ＩＤを履歴レコードの時刻とともに記載する。

次に、以下を引数パラメータとしてステップ１１０１をサブプロシージャとして呼び出す（ステップ１１０５）。なお、ステップ１１０１の実行完了後、このステップに戻ってくる。
起点文書ＩＤ＜＝引用先文書ＩＤ
追跡部品文書＜＝変更なし
ホップ数＜＝ホップ数−１
時刻上限＜＝履歴レコードの時刻
カレントノード＜＝引用先文書ＩＤに対応するノード
そして、以下を引数パラメータとしてステップ１２０１をサブプロシージャとして呼び出す（ステップ１１０６）。なお、ステップ１２０１の実行完了後、このステップに戻ってくる。
起点文書ＩＤ＜＝引用先文書ＩＤ
追跡部品文書＜＝変更なし
ホップ数＜＝ホップ数−１
時刻上限＜＝履歴レコードの時刻
カレントノード＜＝引用先文書ＩＤに対応するノード
検索結果の履歴レコードすべてに対して処理が終了するまで、ステップ１２０３からの処理を実行する（ステップ１１０７）。
上記のようにして、前向き有向グラフが生成される。

（３−４）有向グラフ表示形式出力部の後ろ向き有向グラフ生成手順
後ろ向き有向グラフ生成処理は、後ろ向き有向グラフ生成部０９０４が主体となって行うものであり、入力引数として、起点文書ＩＤ、追跡部品文書ＩＤ、ホップ数、時刻上限、カレントノードの５つのパラメータを、有向グラフ生成部０９０２から受け取る。なお引数として渡されたカレントノードにグラフ構造ができている場合は、それらの構造も紐付けされた状態で渡される。したがってすでにグラフ構造がある程度構築されている場合は、その続きの構築作業ができるようになっているものとする。図１２は、後ろ向き有向グラフ生成部０９０４による後ろ向き有向グラフの生成手順を示すフローチャートである。

後ろ向き有向グラフ生成部０９０４は、ホップ数を判定する。０なら終了する（ステップ１２０１）。そして、次の条件で引用履歴管理部から履歴レコードを検索する（ステップ１２０２）。
履歴レコードＩＤ＝指定なし
時刻＜時刻上限
引用元文書ＩＤ＝無指定
引用先文書ＩＤ＝起点文書ＩＤ
引用対象の部品文書ＩＤ＝追跡部品文書ＩＤ
ソート方法：時刻で降順
件数上限：５件
なお、上記の検索条件において、件数上限５というのは、当該ノードを起点として後ろ向き方向に展開されるノード数の上限となる。この理由は、ノード数が多いとグラフが見難くなるためである。もしより多くの展開数で出力するシステムにした場合はこの数を増やして実装すればよい。

検索の結果得られた履歴レコード群それぞれに対して、ステップ１２０４からステップ１２０８の処理を行う（ステップ１２０３）。
まず、注目する履歴レコードについて次を行う（ステップ１２０８）。

（１）グラフ上に存在するノード群から、引用元文書ＩＤに対応するノードがあるどうか探索する。もしすでに存在すれば、１２０３に戻る。もしなければ次の（２）と（３）の処理を行う（ステップ１２０４）。
（２）ノードを新規作成し引用元文書ＩＤをデータとして記載する。
（３）引用元文書ノードからカレントノードへアークで結び、アーク上に部品文書ＩＤを履歴レコードの時刻とともに記載する。
次に、以下を引数パラメータとしてステップ１１０１をサブプロシージャとして呼び出す（ステップ１２０５）。なお、ステップ１１０１の実行完了後、このステップに戻ってくる。

起点文書ＩＤ＜＝引用元文書ＩＤ
追跡部品文書＜＝変更なし
ホップ数＜＝ホップ数−１
時刻上限＜＝履歴レコードの時刻
カレントノード＜＝引用元文書ＩＤに対応するノード
そして、以下を引数パラメータとしてステップ１２０１をサブプロシージャとして呼び出す（ステップ１２０６）。なお、ステップ１２０１の実行完了後、このステップに戻ってくる。
起点文書ＩＤ＜＝引用元文書ＩＤ
追跡部品文書＜＝変更なし
ホップ数＜＝ホップ数−１
時刻上限＜＝履歴レコードの時刻
カレントノード＜＝引用元文書ＩＤに対応するノード
検索結果の履歴レコードすべてに対して処理が終了するまで、ステップ１２０３からの処理を実行する（ステップ１２０７）。
上記のようにして、後ろ向き有向グラフが生成される。

（４）引用履歴のオープン機能
引用履歴オープン機能は、図３（ｂ）に示すような文書編集部０１０３によって閲覧している複合文書において、ユーザが興味を持った部品文書上あるいは文書全体に対して、引用履歴表示コマンド操作を行うと、該当する履歴が別ウィンドウで表示されるという機能である。図１３は、引用履歴オープン機能の利用イメージを示す図である。図１３に示すように、図３（ｂ）に示すような文書を表示している際に、別のウィンドウでテーブル形式の履歴やグラフ形式の履歴が表示できるようになっている。

別ウィンドウで表示された履歴画面は、前述のように、ハイパーリンクをクリックすれば、対応する文書や部品文書が開くようになっている。したがって履歴画面を機軸に関連文書を次々開くこともできる。この機能は当該システムにおける特徴的な効果を発揮する機能の１つである。

この機能を実現している主たるモジュールは、引用文書オープン部０１０５である。引用文書オープン部０１０５は、図１４に示すように、テーブル形式引用履歴オープン部１４０１とグラフ形式引用履歴オープン部１４０２とを有している。テーブル形式引用履歴オープン部１４０１は、テーブル表示形式で引用履歴を表示し、グラフ形式引用履歴オープン部１４０２は、グラフ表示形式で引用履歴を表示する。図１４は、それぞれの表示形式に対する命令の流れを示す図である。

なお、上記の２つの表示形式においても、それぞれ特定の部品文書を追跡する方法と文書単位で追跡する方法の２種類が用意されている。従って、全部で４種類の追跡方法が用意されている。以下、それぞれの追跡方法について具体的な動作詳細を説明する。

（４−１）引用履歴オープン機能の動作詳細／部品文書：テーブル形式
この機能は、指定された部品文書に関して、当該文書に限らずいずれかの文書において、現在時刻以前で引用のやりとりがあった履歴をすべて一覧表示する機能である。なお、数が多過ぎる場合は、上限件数を設けるなどの工夫があっても良い。これは当該部品文書を起点にして近傍の履歴を探すのではなく、文書群全体について検索が行われるため、文書管理者などの立場の人間にとって便利な機能である。

本機能に関する、処理の流れを図１５に示す。図１５は、引用履歴オープン機能の動作の流れを示す図であって、部品文書単位で検索を行ってテーブル形式で表示する場合の処理の流れを示す図である。
ユーザが文書編集部０１０３で表示されている文書のうち、興味のある部品文書の上で、「履歴開く（テーブル）」というコンテクストメニューを実行する（ステップ１５０１）。すると、文書編集部０１０３は、次の引数でテーブル形式引用履歴オープン部１４０１を起動する（ステップ１５０２）。
追跡部品文書ＩＤ：指定された部品文書の部品文書ＩＤ
時刻上限：現在時刻
テーブル形式引用履歴オープン部０４０１は、受け取った引数を元に、引用履歴テーブル表示形式出力部０６０１を起動し、検索結果のＨＴＭＬ文書を受け取る（ステップ１５０３）。そして、文書編集部０１０３は、ＨＴＭＬ文書を別ウィンドウで表示する（ステップ１５０４）。

（４−２）引用履歴オープン機能の動作詳細／文書：テーブル形式
この機能は、指定された文書に含まれるすべての部品文書に関して、当該文書に限らずいずれかの文書において、現在時刻以前で引用のやりとりがあった履歴をすべて一覧表示する機能である。なお、数が多過ぎる場合は、上限件数を設けるなどの工夫があっても良い。この機能は当該文書を起点にして近傍の履歴を探すのではなく、文書群全体について検索が行われるため、上記と同様に、文書管理者などの立場の人間にとって便利な機能である。

本機能に関する、処理の流れを図１６に示す。図１６は、引用履歴オープン機能の動作の流れを示す図であって、文書単位で検索を行ってテーブル形式で表示する場合の処理の流れを示す図である。
ユーザが文書編集部０１０３で表示されている文書のうち、部品文書以外の領域で、「履歴開く（テーブル）」というコンテクストメニューを実行する（ステップ１６０１）。すると、文書編集部０１０３は、当該文書に含まれるすべての部品文書ＩＤをリストアップする（ステップ１６０２）。見つかった部品文書ＩＤ群それぞれについて、ステップ１６０４とステップ１６０５の処理を行う（ステップ１６０３）。

文書編集部０１０３は、次の引数でテーブル形式引用履歴オープン部１４０１を起動する（ステップ１６０４）。
追跡部品文書ＩＤ：指定された部品文書の部品文書ＩＤ
時刻上限：現在時刻
そして、テーブル形式引用履歴オープン部０４０１は、受け取った引数を元に、引用履歴テーブル表示形式出力部０６０１を起動し、検索結果のＨＴＭＬ文書を受け取る（ステップ１６０５）。

すべての部品文書ＩＤについて行うまでステップ１６０４と１６０５の処理を繰り返す（ステップ１６０６）。そして、ＨＴＭＬ文書群として得られた検索結果を１つのＨＴＭＬ文書にマージし（ステップ１６０７）、マージされたＨＴＭＬ文書を別ウィンドウで表示する（ステップ１６０８）。

（４−３）引用履歴オープン機能の動作詳細／部品文書：グラフ形式
この機能は、指定された部品文書に関して、当該文書との引用のやりとりにおける近傍の履歴をグラフで表示する機能である。この機能は、文書を編集したり閲覧しているユーザにとって、作成経緯を理解したり、関連する情報を発掘するなどの効果を狙うものである。たとえば、ある閲覧文書において、この部品文書はどういう経緯でこの文書に組み込まれたのだろうか？という疑問に対して、履歴を表示することで、経緯を知ることができるという効果がある。また、この部品文書の引用関係における近傍の文書群を見ることで関連文書を確認できるので、新しい知識発掘や知識拡大につなげることができるという効果がある。

本機能に関する、処理の流れを図１７に示す。図１７は、引用履歴オープン機能の動作の流れを示す図であって、部品文書単位で検索を行ってグラフ形式で表示する場合の処理の流れを示す図である。
ユーザが文書編集部０１０３で表示されている文書のうち、部品文書以外の領域で、「履歴開く（グラフ）」というコンテクストメニューを実行する（ステップ１７０１）。すると、文書編集部０１０３は、次の引数でグラフ形式引用履歴オープン部１４０２を起動する（ステップ１７０２）。
追跡部品文書ＩＤ：指定された部品文書の部品文書ＩＤ
起点文書ＩＤ：当該文書の文書ＩＤ
時刻上限：現在時刻
ホップ数：３
上記の引数において、ホップ数は３としたが、一度に見られる探索範囲をもっと広くしたいのであれば、この数を増やして実装すればよい。

グラフ形式引用履歴オープン部１４０２は、受け取った引数を元に、有効グラフ表示ＣＧＩ０９０１有向グラフ表示ＣＧＩを起動し、検索結果のＨＴＭＬ文書を受け取る（ステップ１７０３）。そして、ＨＴＭＬ文書を別ウィンドウで表示する（ステップ１７０４）。

（４−４）引用履歴オープン機能の動作詳細／文書：グラフ形式
この機能は、指定された文書に含まれるすべての部品文書に関して、当該文書との引用のやりとりにおける近傍の履歴をグラフで表示する機能である。この機能は、文書を編集したり閲覧しているユーザにとって、作成経緯を理解したり、関連する情報を発掘するなどの効果を狙うものである。たとえば、ある閲覧文書において、「この部品文書はどういう経緯でこの文書に組み込まれたのだろうか？」という疑問に対して、履歴を表示することで、経緯を知ることができるという効果がある。また、この部品文書の引用関係における近傍の文書群を見ることで関連文書を確認できるので、新しい知識発掘や知識拡大につなげることができるという効果がある。

本機能に関する、処理の流れを図１８に示す。図１８は、引用履歴オープン機能の動作の流れを示す図であって、文書単位で検索を行ってグラフ形式で表示する場合の処理の流れを示す図である。
ユーザが文書編集部０１０３で表示されている文書のうち、部品文書以外の領域で、「履歴開く（グラフ）」というコンテクストメニューを実行する（ステップ１８０１）。すると、文書編集部０１０３は、当該文書のＩＤを元にノードを生成する（ステップ１８０２）。これを起点文書ＩＤとする。ノードには起点文書ＩＤがデータとして書き込まれる。

文書編集部０１０３は、当該文書に含まれるすべての部品文書ＩＤをリストアップする（ステップ１８０３）。そして、見つかった部品文書ＩＤ群それぞれについて、ステップ１８０５とステップ１８０６の処理を行う（ステップ１８０４）。

文書編集部０１０３は、次の引数でグラフ形式引用履歴オープン部１４０２を起動する（ステップ１８０５）。
追跡部品文書ＩＤ：指定された部品文書の部品文書ＩＤ
起点文書ＩＤ：当該文書の文書ＩＤ
時刻上限：現在時刻
ホップ数：３
カレントノード：起点文書に対応するノード
上記の引数において、ホップ数は３としたが、一度に見られる探索範囲をもっと広くしたいのであれば、この数を増やして実装すればよい。

グラフ形式引用履歴オープン部１４０２は、受け取った引数を元に、有向グラフ生成部０９０２を呼び出す。これにより現在注目する部品文書についてのグラフが追加生成される（ステップ１８０６）。そして、すべての部品文書ＩＤについて行うまでステップ１８０５とステップ１８０６の処理を繰り返す（ステップ１８０７）。

ステップ１８０８の処理は、ステップ１００６の処理と同様の処理である。具体的には、グラフ形式引用履歴オープン部１４０２は、得られたグラフ構造データを読み取り、それを視覚的に表現するＨＴＭＬ形式の文書に変換する。また、各ノードはクリックすれば、対応する文書が開くようにハイパーリンクをしかける。また、各アーク上に記載されている部品文書についても、同様に対応する部品文書が開くようにハイパーリンクを仕掛ける。このハイパーリンク先は、文書検索部０７０１のようにＩＤを検索条件として対応する文書を開くＣＧＩとすればよい。この変換結果のＨＴＭＬを、別ウィンドウで表示する。

（５）文書関連性分析機能
文書関連性分析機能は、蓄積された引用履歴を元に、文書同士の関連性の強さを測定する機能である。このような文書間の関連性を測定する機能は、さまざまなシステムによってさまざまな方式で提供されている。しかし、どのようなシステムであったとしても、システムが収集済みのデータ群を材料として、何らかの評価関数を用いてスコアを算出する、ということは同じである。ただし、本発明の一実施形態に係る文書管理システムは文書間で引用された部品文書を特定できるという特徴を有しているので、文書間の関連性を、部品文書のやりとりの流れを用いて測定することができる。ここでは、その特徴を活かした評価関数の一例およびその実装例を示す。

本実施態様に係る文書管理システムでの評価関数を定義するための基本的な考え方として、「部品文書流通パス」という概念を導入する。「部品文書流通パス」を、特定の部品文書、すなわち同じ部品文書ＩＤを持つ部品文書が複数の文書を渡り歩いた経路として定義する。たとえば、部品文書Ｘが、文書Ａ→文書Ｂ→文書Ｃと渡り歩いたとしたら、部品文書流通パスは、Ａ→Ｂ→Ｃとなる。更に、本実施態様に係る文書管理システムでは、「部品文書流通パスの長さ」という概念を導入する。「部品文書流通パスの長さ」は、部品文書流通パスにおける引用の回数として定義され、例えば部品文書流通パスがＡ→Ｂ→Ｃならば、部品文書流通パスの長さは２となる。

ここで、文書Ｘと文書Ｙとの関連性をあらわす評価関数Ｒ（Ｘ，Ｙ）を、

とする。なお、Ｐａｔｈ（Ｘ，Ｙ）は、文書Ｘと文書Ｙとの部品文書流通パスの長さである。上式のように、評価関数は、文書Ｘと文書Ｙの間に存在する各部品文書流通パスそれぞれについて、部品文書流通パスの逆数を計算し、その値を足し合わせたものとして表され、この式によってスコアが求められる。

上記の評価関数において、１つの部品文書流通パスにおいて、その逆数をとっているのは、距離が遠くなればなるほど（すなわち、パスの長さが長くなるほど）スコアが単調減少するが、０よりは大きくなるという特徴があるからである。これにより、流通パスが数多く存在するほうが、スコアが高くなるものの、パスの長さが長くなるにつれてとスコアの上昇量は少なくなる。なお、部品文書の流れに注目した上記の評価関数としては、今回は逆数を用いたが、単調減少する関数であれば、逆数に限らず他の関数を用いることができる。

図１９を参照して、上記の関数を用いて、スコアを計算する手順を説明する。図１９は、本実施態様に係る文章関連性分析の動作の流れを示すフローチャートである。図１９に示す文章関連性分析の動作は、基本的に、文書関連性分析部０１０６が実行するが、以下の説明では、評価機能を文書編集部０１０３から呼び出せるようにしている。これにより、ユーザは編集作業中に、関連性の強い文書群をオンデマンドで表示させることができる。しかし評価機能の利用形態は、これに限るものではない。

まず、ユーザが文書編集部０１０３で表示している文書上から「関連文書を開く」コンテクストメニューを実行することにより処理が開始される（ステップ１９０１）。すると、文書編集部０１０３は、当該文書ＩＤを引数として文書関連性分析部０１０６を起動する（ステップ１９０２）。

文書関連性分析部０１０６は、文書、グラフ形式での引用履歴オープン機能（ステップ１８０１〜１８０７）の一部（最後のＨＴＭＬ生成以外のステップ）を実行する（ステップ１９０３）。これにより、文書近傍のグラフが得られる。そして、グラフ上に存在するノードをリストアップし、ノードごとにステップ１９０５とステップ１９０６を実行する（ステップ１９０４）。

注目ノードの文書とカレントノードの文書との間に存在する部品文書流通パスをすべてリストアップする（ステップ１９０５）。ただし、部品文書流通パスと判定されるためには、同じ部品文書のアークだけで到達できるパスでなければならない。次に、得られたパス群それぞれについて長さの逆数を計算してその合計値を計算して、この値を一時的に記憶する（ステップ１９０６）。これが当注目ノードとカレントノードとの間の関連性となる。そして、グラフ上のノードすべてに対する処理が終了するまで、ステップ１９０５とステップ１９０６を繰り返す（ステップ１９０７）。

グラフ上のすべてのノードについて得られた各関連性のスコアを元に、スコアの高い順に文書ＩＤをソートする（ステップ１９０８）。そして、ソートされた文書ＩＤのリストをハイパーリンク形式で１つのＨＴＭＬページにまとめ、別ウィンドウに表示する（ステップ１９０９）。
これにより、部品文書を用いた文書の関連性を分析することができる。

（第２の実施形態）
第２の実施形態は、第１の実施形態に「引用履歴貼り付け機能」を付加したものである。「引用履歴貼り付け機能」は、引用履歴オープン機能によって、表示された履歴レコードを、文書中に貼り付けることができる機能である。例えば、この機能により、文書の作成経緯や手順などを説明する文書を作成するという目的で履歴レコードを貼り付けることができる。この際、ユーザは、当該文書を後から読む読者にとって、特に重要と思われる履歴だけを選択的に貼り付ければよい。

第２の実施形態において、その構成は、第１の実施形態と同じであるので、図示及び詳細な説明を省略する。また、第２の実施形態で追加した引用履歴貼り付け機能は、第１の実施形態及び以降の実施形態と組み合わせて用いることもできる。なお、この引用履歴貼り付け機能は、文書編集部０１０３によって実行されるものとする。

第１の実施形態では、引用履歴オープン機能によって表示される画面はＨＴＭＬを用いていたが、第２の実施形態では、本発明の一実施形態に係る文書管理システムが編集対象として利用している複合文書０３０１の形式を用いるようにし、さらにこの複合文書において履歴レコードを部品文書として定義した形で提供するということである。

図２０は、引用履歴貼り付け機能の利用イメージを示す図である。図２０に示すように、履歴ウィンドウから文書へドラッグアンドドロップによって選択的に履歴レコードを貼り付けている。なおこ、の利用イメージでは、部品文書がそのままの表示形式で張り付いているが、特許文献３に記載の機能を用いて、ドロップ時に適切な表示形式に自動調整された形で貼り付けることもできる。ただし、引用履歴レコードを貼り付ける操作を行った場合には、その操作自体は引用履歴として記録されない。

なお、具体的には、第１の実施形態において、ステップ１５０４、ステップ１６０７、ステップ１７０４、ステップ１８０８で、いずれも検索して得られた履歴レコード群を元にＨＴＭＬ文書を生成しているが、本実施態様では、複合文書０３０１の形式で生成するように変更すればよい。

（第３の実施形態）
第３の実施形態は、第１の実施形態に「部品文書ＣＯＰＹＩＤによる引用履歴管理機能」を付加したものである。第３の実施形態において、その構成は、第１の実施形態と同じであるので、図示及び詳細な説明を省略する。また、第３の実施形態で追加した部品文書ＣＯＰＹＩＤによる引用履歴管理機能は、第１の実施形態及びその他の実施形態と組み合わせて用いることもできる。

本実施態様において、「部品文書ＣＯＰＹＩＤ」とは、引用すなわち文書間でのコピー・ペースト操作、あるいは同一文書内でのコピー・ペースト操作によって、複数になる同一部品文書を区別するＩＤである。すなわち、同一部品文書ＩＤを持つ部品文書であっても、個別に異なる部品文書ＣＯＰＹＩＤが発番されることになる。これは、文書編集部０１０３において、部品文書が複製された瞬間にＣＯＰＹＩＤを新規発番することによって実現される。

本実施態様における部品文書ＣＯＰＹＩＤの導入によってもたらされる最大の効果は、文書関連性分析機能で説明した部品文書流通パスについて、真のパスが得られるということである。第１の実施形態では、部品文書ＩＤを元に部品文書のやりとりの流れを同定していた。しかし、実際には、同一文書中に、同じ部品文書ＩＤを持つ部品文書が複数存在する可能性がある。このようなケースに対して、これらの複数の部品文書のいずれの部品文書を引用したのか第１の実施形態では区別できない。

その例を図２４に挙げる。文書Ａ〜Ｆの６文書があり、文書Ａに部品文書Ｘがある。矢印は引用を示している。１つの引用（コピーペースト）の流れとして、文書Ａ、Ｂ、Ｄ、Ｅの遷移で部品文書Ｘが引用されている。もう１つの引用の流れとして、文書Ａ、Ｃ、Ｄ、Ｆの遷移で部品文書Ｘが引用されている。第１の実施形態では、文書Ｆが文書Ｄのどちらの部品文書Ｘを引用したものかを区別することはできない。文書Ｄには部品文書Ｘが２つあるが、どちらも同じ部品文書ＩＤだからである。部品文書Ｘがどこから来たものかという区別が付かなくても、同じ部品文書Ｘなのであるから、知識伝播という意味では特に問題とならない。しかし、たとえば情報漏れを調べる管理者などにとってコンテンツの流れを完全に追いかけたいというニーズもある。また、特許文献３に記載のようなコンテンツ編集機能など搭載している場合には、文書Ａから来た部品文書Ｘと、文書Ｂから来た部品文書Ｘとでは、内容が異なる場合がある。すなわち、同じＩＤなので大元のルーツは同じだが内容更新されていて異なるものになっている場合がある。その場合は、知識伝播という意味でも区別できたほうが好ましい。

そこで、文書編集部０１０３が取り扱う構造文書を、本実施態様では図２１に示す形式とする。すなわち、図２１に示すように、部品文書に、「pz:id」という属性と並び、「pz:copyid」という属性が追加されている。この場合において、文書編集部０１０３は、例えば図３に示すような形式の文書をロードした場合に、部品文書にpz:copyidが付加されていないので、当該部品文書にＣＯＰＹＩＤを発番して属性として付与する。なお、ＣＯＰＹＩＤの発番には、ＧＵＩＤなどの必ずユニークになるアルゴリズムを用いればよい。

文書編集部０１０３は、引用操作またはコピー・ペースト操作によって、部品文書が複製された場合には、コピーとして新しく生成された部品文書に対して、新しくＣＯＰＹＩＤを発番する。さらに、その操作が引用操作（つまり文書間でのコピー・ペースト）の場合は、ＣＯＰＹＩＤを含む履歴レコードを生成する。この処理手順は、図４のうち、ステップ０４０１を次のように改良したものとなる。

文書Ａから文書Ｂに部品文書Ｘが引用され、引用前のＣＯＰＹＩＤはｘ１、引用後のＣＯＰＹＩＤはｘ２であった場合に、ステップ０４０１の処理を、「文書編集部０１０３は、Ａ、Ｂ、Ｘ、ｘ１、ｘ２および現在時刻を元に引用履歴レコードを生成する」と変更する。これによって、複数の部品文書Ｘに対して、それぞれユニークなＣＯＰＹＩＤが付されることになる。

これによって生成される引用履歴レコードは以下のような項目を持つようなスキーマである。
履歴レコードＩＤ
時刻
引用元文書ＩＤ
引用先文書ＩＤ
引用対象の部品文書ＩＤ
引用元部品文書ＣＯＰＹＩＤ
引用先部品文書ＣＯＰＹＩＤ
引用履歴の表示機能（テーブル、グラフを問わない）においては、入力する検索条件の構成、検索アルゴリズムはまったく同じである。ただし、その表示形式のみが異なる。その表示例として、引用履歴のテーブル表示形式の例を図２２に示し、引用履歴のグラフ表示形式の例を図２３に示す。

図２２に示すように、テーブル表示形式の場合は、引用元部品文書ＣＯＰＹＩＤと引用先部品文書ＣＯＰＹＩＤのカラムが追加された形で表示される。また、図２３に示すように、グラフ表示形式の場合は、アーク上に表示されている部品文書の左下および右下において、引用元部品文書ＣＯＰＹＩＤと引用先部品文書ＣＯＰＹＩＤが表示される。

なお、図２３の例では、すべての引用において同じ部品文書ＩＤが対象となっているが、例えば、左上の文書から来た部品文書は右上の文書へ渡され、左下の文書から来た部品文書は右下の文書へ渡されていることが、ＣＯＰＹＩＤからわかる。また、表示された各ＣＯＰＹＩＤをクリックすれば、そのＣＯＰＹＩＤを持つ部品文書を開くようにしても良い。

本実施態様における、ＣＯＰＹＩＤの導入によって最も大きな効果を得るのは、文書関連性分析機能である。本実施態様では、文書関連性分析機能における、関連性をスコアリングする評価関数の礎となっている部品文書流通パスの定義が変わる。

第１の実施形態では、部品文書流通パスは、同じ部品文書ＩＤを持つ部品文書が複数の文書を渡り歩いた流れとしていた。すなわち、文書Ａ→文書Ｂ→文書Ｃというアークが存在するとき、ＡとＢの間、ＢとＣの間に、同一部品文書ＩＤが存在するとき、部品文書流通パスとして認定された。

しかし、本実施形態では、連続的なアークリストにおいて各アークの接する終端同士でＣＯＰＹＩＤが一致するような、連続的なアークリストが成立するとき、部品文書流通パスとして認定される。すなわち、文書Ａ→文書Ｂ→文書Ｃというアークが存在するとき、ＡＢ間アークでの引用先部品文書ＣＯＰＹＩＤと、ＢＣ間アークでの引用元部品文書ＣＯＰＹＩＤが一致するとき、部品文書流通パスとして認定される。

具体的には、図１９のステップ１９０５が、本実施態様では次のように変更される。ステップ１９０５では、注目ノードの文書とカレントノードの文書との間に存在する部品文書流通パスをすべてリストアップする。ただし、部品文書流通パスと判定されるためには、文書間を結ぶ連続的なアークリストにおいて各アークの接する終端同士でＣＯＰＹＩＤが一致するような、連続的なアークリストが成立しなければならない。

（第４の実施形態）
第４の実施形態は、第１の実施形態に「文書版管理機能」を付加したものである。「文書版管理機能」とは、文書を更新保存する際に、上書きすることなく、古い内容も残す機能である。第４の実施形態において、その構成は、第１の実施形態と同じであるので、図示及び詳細な説明を省略する。また、第４の実施形態で追加した文書版管理機能は、第１の実施形態及びその他の実施形態と組み合わせて用いることもできる。

履歴をたどって関連する文書を開くという操作をユーザが行ったとき、現在ではその文書が引用した当初とは内容が異なっている可能性がある。ユーザがこのような操作を行うとき、ユーザが見たいのは引用時（すなわち更新前）における当該文書の内容である可能性が高い。しかし第１の実施形態では最新文書内容しか開示できないため、その要望に対応できない。本実施形態では、このような要求に対応させたものである。

本実施態様では、まず、文書編集結果のアップロード処理を次のように変更している。文書編集部０１０３の更新ボタンをクリックすることにより、文書編集部０１０３で行われた文書編集結果を文書管理部０１０１にアップロードする。そうすると、当該ＵＲＬとともに文書内容がアップロードされる。文書管理部０１０１はＵＲＬを文書ＩＤとみなし（または文書中に文書ＩＤが記載されている場合はそのＩＤ値を用いる）、新しく送信されてきた文書内容を、当該ＩＤおよび更新時刻と関連付けた形で追加格納する。

そして、文書ＩＤ、部品文書ＩＤから文書を問い合わせる文書検索部０７０１の機能を次のように変更する。
文書検索部０７０１は、ＨＴＴＰ ＰＯＳＴまたはＧＥＴによって、ＩＤおよび時刻上限のパラメータを受信するようになっている。ただし時刻上限パラメータは省略することも可能である。省略した場合は、時刻上限は現在時刻となる。そして、文書検索部０７０１は、指定ＩＤに一致し、かつ時刻上限より過去の更新時刻である、文書または部品文書を検索する。この検索結果として得られた文書あるいは部品文書をＨＴＴＰレスポンスとして返す。これにより、複数の版に対する文書（或いは部分文書）が、検索されることになる。

次に、図７のＨＴＭＬページ０６０３として説明した「ＩＤをクリックしたときに文書を開く機能」について、以下のように変更する。
ＨＴＭＬページ０６０３検索結果を表示するＨＴＭＬページにおいて、引用元文書ＩＤカラム、引用先文書ＩＤカラム、引用対象の部品文書ＩＤカラムに表示されている各ＩＤ値はハイパーリンクとなっていて、そのリンク先がＣＧＩとして実装されている文書検索部０７０１である。クリックすると、そのＩＤ値および引用履歴の時刻を付けて、ＨＴＴＰ ＰＯＳＴまたはＧＥＴなどで文書検索部０７０１へ要求がかかる。

上記変更では、クリック時に引用履歴の時刻をつけていることに特徴がある。これにより、その引用履歴が行われる以前の版の文書が問い合わされることになる。

そして、図１０のステップ１００６として説明したＨＴＭＬ化処理について、以下のように変更する。
ステップ１００６では、有効グラフ表示ＣＧＩ０９０１は有向グラフ生成部０９０２から受け取ったグラフ構造データを読み取り、それを視覚的に表現するＨＴＭＬ形式の文書に変換する。また各ノードはクリックすれば、対応する文書が開くようにハイパーリンクをしかける。また各アーク上に記載されている部品文書についても、同様に対応する部品文書が開くようにハイパーリンクを仕掛ける。このハイパーリンク先は、文書検索部０７０１のようにＩＤおよび引用履歴の時刻を検索条件として対応する文書を開くＣＧＩとすればよい。この変換結果を、ＨＴＴＰレスポンスとして返す。

すなわち、ハイパーリンク先となるＣＧＩに対して、ＩＤだけでなく引用履歴の時刻も併せてパラメータとして渡すように改良している。これにより、その引用履歴が行われる以前の版の文書が問い合わされることになる。

従来、自由な範囲の部品文書の文書間引用が可能であるため、引用される部品文書のバリエーションは無限となる。これに対して、本発明は、引用可能な部品文書はあらかじめ定められたものに限定されるため、引用される部品文書のバリエーションは有限であり管理可能となる。本発明は、この有限性を利用し、引用対象となる部品文書すべてにユニークなＩＤを割り当てるようにし、引用履歴にこのＩＤも併せて記録するようにしている。これにより、引用履歴として、どの文書からどの文書へどの部品文書が引用されたか、という情報を記録することを可能としている。従って、本発明によれば、下記のような効果が得られる。

（１） 特定の部品文書の流通経路を特定できる
たとえば、部品文書Ｘが文書Ａ→文書Ｂ→文書Ｃなどを渡り歩いてきたということがわかる。従来技術では、文書Ａと文書Ｂ、文書Ｂと文書Ｃの間に引用があったことはわかるが、特定部品文書が文書間をどのような流通経路を経てきたかは明確化できなかった。

（２） 部品文書を軸にしたコンテクストセンシティブな履歴表示ができる
表示している文書の特定の部品文書をユーザが指定し、その部品文書を基点としてその引用関係を表示する機能を実現できる。従来技術では、引用可能な部品文書は自由であり、加えてＩＤなどで管理されているわけでもないので、特定の部品文書を指し示して、その部品文書にまつわる履歴を表示するという機能を実現することは不可能である。
また、本発明では、部品文書の表層的な内容一致を元に引用の流れを追跡しているのではなく、部品文書ＩＤをベースとしてコンテンツのやり取りを追跡しているため、引用された部品文書が改変されていたとしても追跡できる。

（３） 部品文書単位での利用状況を分析処理にかけることができる
本効果として、単純な例としては、例えば、部品文書Ｘが引用された回数を割り出すことができる。別の例としては、同一部品文書を引用ホップ数から文書間の関係の高さを割り出すことができる。従来技術は、文書Ａが他文書から引用された回数を割り出すなど、文書単位での利用状況の分析はできるが、文書内での部品文書の利用状況を分析することは原理的に不可能である。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

本発明の第１の実施形態に係る文書管理システムの概略構成を示す図である。 文書編集部０１０３による編集画面の画面例を示す図である。 文書管理部０１０１からダウンロードされた文書であって、文書編集機能で取り扱う文書の一例を示す図である。 引用履歴の格納処理の手順を示すフローチャートである。 テーブル表示形式を表示例を示す図である。 引用履歴テーブル表示形式出力部０６０１を用いてテーブル表示を行う場合の概要について説明するための図である。 文書ＩＤや部品文書ＩＤから文書を問い合わせる動作の概要を示す図である。 引用履歴レコードの有向グラフ表示形式例を示す図である。 引用履歴の検索から検索結果を有向グラフで表示する場合の動作の概要を示す図である。 引用履歴レコード有向グラフ表示モジュール群（有効グラフ表示ＣＧＩ０９０１〜後ろ向き有向グラフ生成部０９０４）の連携処理の流れを示す図である。 前向き有向グラフ生成部０９０３による前向き有向グラフの生成手順を示すフローチャートである。 後ろ向き有向グラフ生成部０９０４による後ろ向き有向グラフの生成手順を示すフローチャートである。 引用履歴オープン機能の利用イメージを示す図である。 それぞれの表示形式に対する命令の流れを示す図である。 引用履歴オープン機能の動作の流れを示す図であって、部品文書単位で検索を行ってテーブル形式で表示する場合の処理の流れを示す図である。 引用履歴オープン機能の動作の流れを示す図であって、文書単位で検索を行ってテーブル形式で表示する場合の処理の流れを示す図である。 引用履歴オープン機能の動作の流れを示す図であって、部品文書単位で検索を行ってグラフ形式で表示する場合の処理の流れを示す図である。 引用履歴オープン機能の動作の流れを示す図であって、文書単位で検索を行ってグラフ形式で表示する場合の処理の流れを示す図である。 本実施態様に係る文章関連性分析の動作の流れを示すフローチャートである。 引用履歴貼り付け機能の利用イメージを示す図である。 第３の実施形態において、文書編集部０１０３が取り扱う構造文書を示す図である。 引用履歴のテーブル表示形式の例を示す図である。 引用履歴のグラフ表示形式の例を示す図である。 同一文書中に、同じ部品文書ＩＤを持つ部品文書が複数存在する場合の例を示す図である。

符号の説明

０１０１…文書管理部
０１０２…引用履歴管理部
０１０３…文書編集部
０１０４…引用履歴可視化部
０１０５…引用文書オープン部
０１０６…文書関連性分析部

Claims (14)

1. ユニークな識別子である文書ＩＤが付与された文書と前記文書中にあらかじめ定義された範囲の文書片であり、ユニークな識別子である部分文書ＩＤが付与された部品文書とを管理する手段と、
   前記部分文書がある文書から他の文書へ引用された場合に、当該引用履歴を記録する手段と、
   前記文書間で前記部品文書のコピー・ペースト操作を許可し、それ以外の範囲の文書片のコピー・ペースト操作を禁止する手段と、
   を具備することを特徴とする文書管理システム。
2. 請求項１に記載の文書管理システムにおいて、前記引用履歴は、少なくとも、引用元となった文書の文書ＩＤと、引用先となった文書の文書ＩＤと、引用された部分文書の部品文書ＩＤを含むことを特徴とする文書管理システム。
3. 請求項１又は請求項２に記載の文書管理システムにおいて、
   部分文書ＩＤに基づいて、前記引用履歴から当該部分文書ＩＤを含む引用履歴を検索する手段と、
   前記検索の結果得られた引用履歴を、少なくとも引用元となった文書の文書ＩＤ、引用先となった文書の文書ＩＤ、引用対象となった文書片の部品文書ＩＤをカラムとして持つ表形式で表示する手段と、を更に具備することを特徴とする文書管理システム。
4. 請求項１又は請求項２に記載の文書管理システムにおいて、
   部分文書ＩＤに基づいて、前記引用履歴から当該部分文書ＩＤを含む引用履歴を検索する手段と、
   前記検索の結果得られた引用履歴を、前記部分文書ＩＤを含む文書ＩＤをノードとし、前記部分文書ＩＤの引用関係をアークとするグラフとして表示する手段と、を更に具備することを特徴とする文書管理システム。
5. 請求項３に記載の文書管理システムにおいて、前記表形式で表示する手段は、前記検索の結果得られた引用履歴をマージして、少なくとも引用元となった文書の文書ＩＤ、引用先となった文書の文書ＩＤ、引用対象となった文書片の部品文書ＩＤをカラムとして持つ表形式で表示することを特徴とする文書管理システム。
6. 請求項４に記載の文書管理システムにおいて、前記グラフを表示する手段は、前記検索の結果得られた引用履歴に基づいて得られたグラフをマージして新たなグラフを表示することを特徴とする文書管理システム。
7. 請求項３から請求項６のいずれか１項に記載の文書管理システムにおいて、前記表示されている引用履歴の文書ＩＤまたは部品文書ＩＤの選択操作により、当該部品文書ＩＤ又は文書ＩＤに該当する文書あるいは部品文書を検索して表示する手段を更に具備することを特徴とする文書管理システム。
8. 請求項１から請求項７のいずれか１項に記載の文書管理システムにおいて、前記引用履歴に基づいて、前記文書間の関連性を分析する手段を更に具備することを特徴とする文書管理システム。
9. 請求項８に記載の文書管理システムにおいて、前記分析する手段は、前記引用履歴に記載されている部品文書ＩＤを用いて、第１の文書が持つ部品文書が第２の文書に引用されたパスをすべて検索して、当該パスの長さを引数とする関数を用いて関連性を分析することを特徴とする文書管理システム。
10. 請求項９に記載の文書管理システムにおいて、前記関数は、前記パスの長さを引数として単調減少する関数であることを特徴とする文書管理システム。
11. 請求項１から請求項６のいずれか１項に記載の文書管理システムにおいて、前記管理する手段は、前記引用履歴のうち所望の引用履歴を選択して、文書中に貼り付けることを特徴とする文書管理システム。
12. 請求項１から請求項１１のいずれか１項に記載の文書管理システムにおいて、前記管理する手段は、同一部品文書が複数である場合に、当該部品文書にそれぞれ区別可能な識別子を付加することを特徴とする文書管理システム。
13. 請求項１から請求項１２のいずれか１項に記載の文書管理システムにおいて、前記管理する手段は、編集前後の前記部分文書をその更新時刻と合わせて管理することを特徴とする文書管理システム。
14. 文書に含まれる部品文書の文書間の引用を管理するプログラムにおいて、
    ユニークな識別子である文書ＩＤが付与された文書と前記文書中にあらかじめ定義された範囲の文書片であり、ユニークな識別子である部分文書ＩＤが付与された部品文書とを記憶手段に記憶させる手段と、
    前記部分文書がある文書から他の文書へ引用された場合に、当該引用履歴を記録する手段と、
    前記文書間で前記部品文書のコピー・ペースト操作を許可し、それ以外の範囲の文書片のコピー・ペースト操作を禁止する手段と、を具備することを特徴とする文書管理プログラム。

Images