JP2016085580A - 文書情報管理システム、文書情報管理方法、及びプログラム - Google Patents

Abstract

【課題】グラフデータベースに文書情報を格納し、文書情報内の記述内容から自動的に関連情報の抽出を行うことを可能とする。【解決手段】文書情報管理システムにおいて、ノードとエッジからなるグラフデータを格納するデータベースと、文書情報からなるマークアップ文書群の型情報を記述しているスキーマを読み込み、当該スキーマを解析するスキーマ解析手段と、前記マークアップ文書群を読み込み、当該マークアップ文書群を解析し、当該マークアップ文書群の各要素をノードに変換し、要素間の親子関係をエッジに変換することによりグラフデータを生成し、当該グラフデータを前記データベースに格納する変換手段と、を備え、前記変換手段は、前記スキーマ解析手段により得られた型情報に基づいて、前記マークアップ文書群に含まれる文書情報の要素間の同一性を判定することによって、異なるマークアップ文書にまたがる関連情報をエッジとして生成する。【選択図】図７

Description

本発明は、文書情報を管理する技術に関連し、特に、ソフトウェア開発における設計書等の設計情報の管理において利用する技術に関連するものである。

ソフトウェアの設計情報は、従来はオフィス文書作成ソフトで多く作成されていた。しかし、オフィス文書作成ソフトで作成された設計情報は、複数のファイルにまたがった検索が不便であったり、プログラムの階層構造やプログラムとデータの関係性等の、ソフトウェアの設計情報の持つ構造や関係性を表現できない問題がある。そこで、この問題を解決するために、設計情報を何らかの方法でデータベース化して、検索性を向上させたり、構造を表現したりする技術が開発されている。設計情報のデータベース化の方法としては、モデルベースのソフトウェア設計支援ツールの利用と文書管理システムの利用という大きく２つのアプローチがある。

モデルベースのソフトウェア設計支援ツールは、ＵＭＬ等のソフトウェア設計のためのモデルに従って、ソフトウェア設計情報をコンピュータ上に記録できるツールである。ＵＭＬは、ソフトウェア内の階層関係等の構造と関係性を表現することができるから、上記の問題を解決することができる。しかし、ＵＭＬ自体の普及が十分でなかったこと、特定のベンダのツールに縛られることが好まれなかったこと、オフィス文書作成ソフトに比較して使い勝手が悪かったこと、複数社による開発に馴染まなかったこと等の原因によって十分に普及していないのが現実である。

文書管理システムとは、コンピュータ上で作成された電子文書を効率的に管理するためのシステムであり、検索性を向上することができる。文書管理システムにおける電子文書の表記形式は様々あるが、よく使われている形式の１つにＸＭＬ形式がある。文書管理システムの内部のデータベースには、一般的には関係データベース（ＲＤＢ）が利用されることが多い。

しかし、近年では新しいデータモデルによる各種データベースが開発・提供されており、グラフデータベースがその一つとして注目されている。そこで、以下にＸＭＬ技術とグラフデータベース技術について説明する。

（ＸＭＬ及びＸＭＬスキーマについて）
ＸＭＬとはマークアップ言語の一つであり、ＸＭＬで記述された文書は構造化され、構造に意味を持ったデータである。図１にＸＭＬ文書とその構造の例を示す。

図１に示すように、ＸＭＬ文書は木構造モデルであり、根のノードをルート要素、値（記述内容）をテキストノード、タグ中に記述されたものを属性（データモデルの属性と区別するため、以降「ＸＭＬ属性」と呼ぶ）、テキストノードとＸＭＬ属性以外のノードを要素と呼ぶ。また、データ全体をＸＭＬドキュメントと呼ぶ。

また、ＸＭＬドキュメントの形式を規定するためのＸＭＬスキーマがあり、ＸＭＬ Ｓｃｈｅｍａ（非特許文献４）を代表とする標準技術として制定されている。例えば、図２のリスト１に示すように定義し、ｂｏｏｋ要素の下には、ｔｉｔｌｅ、ｄａｔｅ、ｃｈａｐｔｅｒ要素を保持でき、ｔｉｔｌｅ要素のテキストノードは文字列型、ｄａｔｅ要素のテキストノードは日付型、といったことが規定されている。

（グラフデータ及びグラフデータベース）
グラフデータとは、ノード群とノード間の関係を表すエッジ群で構成されるデータ構造である。図３にグラフデータの例を示す。

図３に示す例は、エッジが向きを有するが、エッジが向きを有しない構造もある。また、ノード及びエッジにプロパティ（属性及び属性値）を複数保持させる場合もある（これはプロパティグラフと呼ばれる）。グラフデータは、非常に汎用的なデータ構造であり、表現力が高い。例えば木構造もグラフ構造の一部と見ることもできる。

このようなデータ群を効率的に扱うデータベースとして、グラフデータベースがある（例えば、非特許文献１〜３等）。従来の関係データベース（ＲＤＢ）でも、機能的にはグラフデータを管理することは可能であるが、ノードからノードへエッジを辿っていく処理を多段に行うような操作の実行には性能的に問題がある。逆に言えば、グラフデータベースはそのような操作の実行を高速に行えるように設計されている。

Neo4j the Graph Database、http://www.neo4j.org/、平成２６年１０月１７日検索 AllegroGraph RDFStore、http://www.franz.com/agraph/allegrograph/、平成２６年１０月１７日検索 infoGrid WebGraph Database、http://infogrid.org/、平成２６年１０月１７日検索 XML Scheama、http://www.w3.org/XML/Schema、平成２６年１０月１７日検索

従来の文書管理システムでは、多数の電子文書を格納し、特定の項目（管理ＩＤや日付等）による検索や、全文検索といった機能により、個別の求める文書を探し出すことが、高速に行える。

しかし、文書間の関連を管理し、その関連を活用した機能は十分とは言えない。例えば、ある文書群とそれぞれに関連する文書群を探したいといった場合、例えば以下の３つの手法を用いることが考えられるが、それぞれ問題点を持っている。

第１の手法として、全文検索機能を用いることが考えられる。しかし、この手法では、ユーザが適切な検索キーワードを指定する必要があり、適切な検索キーワードを発見するために試行錯誤することになる。

第２の手法として、データベースのジョイン操作を用いることが考えられる。しかし、この手法を用いて高速に実行するためには、ジョイン条件とする項目に対しインデクスを作成しておく、といった事前準備・設計が必要となる。

第３の手法として、各文書に関連を表すメタ情報を付与し、それを利用した検索を行うことが考えられるが、この手法では、メタ情報の付与及びその管理コストが大きくなる。

このような問題点を解決するために、関連を容易に管理できるグラフデータベースを利用することが考えられるが、グラフデータベースは前述したような辿る処理（トラバース）に特化して設計されており、文書管理システムに必要とされる、条件を指定して必要な部分を切り出すような検索処理的な機能は不十分であった。

本発明は上記の点に鑑みてなされたものであり、グラフデータベースに文書情報を格納し、文書情報内の記述内容から自動的に関連情報の抽出を行うことを可能とする技術を提供することを目的とする。

本発明の実施の形態によれば、ノードとエッジからなるグラフデータを格納するグラフデータベースと、
管理対象となる文書情報からなるマークアップ文書群の型情報を記述しているスキーマを読み込み、当該スキーマを解析するスキーマ解析手段と、
前記マークアップ文書群を読み込み、当該マークアップ文書群を解析し、当該マークアップ文書群の各要素をノードに変換し、要素間の親子関係をエッジに変換することによりグラフデータを生成し、当該グラフデータを前記グラフデータベースに格納する変換手段と、を備え、
前記変換手段は、前記スキーマ解析手段により得られた型情報に基づいて、前記マークアップ文書群に含まれる文書情報の要素間の同一性を判定することによって、異なるマークアップ文書にまたがる関連情報をエッジとして生成する
ことを特徴とする文書情報管理システムが提供される。

また、本発明の実施の形態によれば、ノードとエッジからなるグラフデータを格納するグラフデータベースを備える文書情報管理システムにおいて実行される文書情報管理方法であって、
管理対象となる文書情報からなるマークアップ文書群の型情報を記述しているスキーマを読み込み、当該スキーマを解析するスキーマ解析ステップと、
前記マークアップ文書群を読み込み、当該マークアップ文書群を解析し、当該マークアップ文書群の各要素をノードに変換し、要素間の親子関係をエッジに変換することによりグラフデータを生成し、当該グラフデータを前記グラフデータベースに格納する変換ステップと、を備え、
前記変換ステップにおいて、前記スキーマ解析ステップにより得られた型情報に基づいて、前記マークアップ文書群に含まれる文書情報の要素間の同一性を判定することによって、異なるマークアップ文書にまたがる関連情報をエッジとして生成する
ことを特徴とする文書情報管理方法が提供される。

本発明の実施の形態によれば、グラフデータベースに文書情報を格納し、文書情報内の記述内容から自動的に関連情報の抽出を行うことを可能とする技術が提供される。

ＸＭＬ文書とその構造の例を示す図である。 ＸＭＬスキーマの例を示す図である。 グラフデータの例を示す図である。 画面設計書例及び処理設計書例を示す図である。 ＸＭＬスキーマ例を示す図である。 グラフデータの構造化例を示す図である。 本発明の実施の形態におけるシステム構成例を示す図である。 実施例におけるＸＭＬスキーマ定義の例を示す図である。 ＸＭＬ文書の例を示す図である。 事前処理の手順を示すフローチャートである。 格納処理の手順を示すフローチャートである。 格納処理のステップＬ０５の詳細を示すフローチャートである。 グラフデータの例を示す図である。 検索処理の手順を示すフローチャートである。 検索結果例１を示す図である。 検索結果例２を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態では、管理の対象を設計書情報としているが、これは例であり、本発明は設計書情報に限らず構造及び関係性を有する文書情報全般に適用可能である。また、以下では、マークアップ言語としてＸＭＬを使用しているが、ＸＭＬ以外でも本発明を適用できる。なお、マークアップ言語で記述した文書をマークアップ文書と呼ぶことができる。マークアップ文書には、ＸＭＬ文書の他、ＸＭＬ以外のマークアップ言語で記述された文書も含まれる。

本実施の形態では、グラフデータベースを使ってＸＭＬ形式で記述された設計書情報を格納し、設計書情報内の記述内容から自動的に関連の抽出・管理を実現する技術が提供される。以下、まず、基本的な技術内容を説明し、その後に、実施例としてより具体的な例を説明する。

（基本的な技術内容）
文書間の関連には様々な種類があるが、文書内の表記パターンとして典型的なものは、関連を持つ双方の文書内に、同じ意味を示す項目と内容が記述されているものである。一例として、ソフトウェア開発の設計書を例にとって説明する。

図４（ａ）に画面設計書の例（リスト２）を示し、図４（ｂ）に処理設計書の例（リスト３）を示す。これら２つの文書間には、例えば以下の関連がある。

すなわち、リスト２が示す画面からリスト３が示す処理が呼び出される、という意味的な関連があり、これはリスト２の１２行目「呼出し処理」と、リスト３の３行目「処理名」が、同一の記述であることで表されている。

また、リスト２が示す画面とリスト３が示す処理は、同じ設計者によって設計されている、という意味的な関連があり、これはリスト２の１３〜１６行目「設計者」と、リスト３の１０〜１３行目「設計者」が、同一の記述であることで表されている。

なお、リスト２の５行目「要素名」と、リスト３の２行目の「サブシステム名」は、「ＩＴＥＭ１」という記述は同一であるが、項目として意味が異なるため、関連はない。つまり、同じ意味を持つ項目と同じ意味を持つ内容を見つけ出すことで、関連を抽出できる。本実施の形態では、ＸＭＬスキーマを利用してこれを自動的に抽出することとしている。ＸＭＬスキーマでは、各要素に対しデータ型（型情報）を規定できるため、これを利用し、同じデータ型のものを同じ意味を示す項目であると判定する。また、内容の同一性はその記述同士で判定できる。

＜項目の同一性について＞
例えば、図４に示したリスト２、３のＸＭＬ文書に対し、図５に示すようなＸＭＬスキーマを記述することで、項目の同一性を判定できる。

すなわち、リスト４の１６行目で画面設計書の「呼出し処理」を、２４行目で処理設計書の「処理名」を、同じデータ型（単純型）として４２行目の「処理名ｔｙｐｅ」で定義しており、１７行目で画面設計書の「設計者」を、３４行目で処理設計書の「設計者」を、同じデータ型（複合型）として４４〜４８行目の「設計者ｔｙｐｅ」で定義している。

＜内容の同一性について＞
内容の同一性に関しては、必要に応じて様々な判定基準を定義できるが、まずは最も単純な例として完全一致を判定基準とした場合について説明する。

この場合、例えば図６に示すようなグラフデータとして文書を構造化し管理（保持）する。従来は文書単位でデータベースへ格納・管理しているのに対し、本実施の形態では、文書群全体での構造化を行う。図６に示すように、「ＰＲＯＣ１」、「設計者」が項目・内容が同一として判定され、同一ノードで双方の文書から共有されている。

記述の完全一致を内容の同一性の判定基準とした場合はこのように同一のノードとするが、そうでない場合は個別のノードとし、２つのノード間に関連を示す特別なエッジを作成することで表現できる。

＜システム構成例、動作例＞
上述したような処理を実行する本実施の形態における設計書情報管理システム（文書情報管理システムの例）の構成例を図７に示す。

図７に示すように、本実施の形態の設計書情報管理システムは、ＸＭＬスキーマ解析部１０、ＸＭＬ・グラフ変換部２０、関連検索部３０、グラフデータベース４０を含む。

ＸＭＬスキーマ解析部１０は、ＸＭＬスキーマを解析し管理する機能部である。ＸＭＬ・グラフ変換部２０は、ＸＭＬ文書からグラフデータへの変換をＸＭＬスキーマの解析結果から同一ノードの判定を行いながら実行する機能部である。グラフデータベース４０は、グラフデータを格納する格納部（データベース）である。関連検索部３０は、グラフデータベース４０に格納したグラフデータに対し文書間の関連を利用した検索を行う機能部である。

以下、図７に示す設計書情報管理システムにおいて実行される処理の概要を説明する。まず、データ格納時の処理（ステップ１０１〜１０２）を説明する。

ステップ１０１）
事前に、ＸＭＬスキーマ解析部１０がＸＭＬスキーマ１１を読み込み、解析する。解析結果には、同一のデータ型が定義された要素宣言を保持する。

ステップ１０２）
ＸＭＬ・グラフ変換部２０が、ＸＭＬ文書群２１を読み込み、構文解析する。また、ＸＭＬ・グラフ変換部２０は、ＸＭＬスキーマ解析部１０を呼出し、構文解析結果とスキーマ解析結果を照合し、構文解析結果にスキーマ情報を付与する。

更に、ＸＭＬ・グラフ変換部２０は、構文解析結果から、グラフデータへの変換を実行する。ここで、同一のデータ型で内容が同一なものを、記述の完全一致の場合は１つのノードとし、複数のエッジを作成する。そして、グラフデータをグラフデータベース４０に格納する。

次に、関連検索部３０により実行されるデータ検索時の処理を説明する。データ検索として、様々な検索パターンが考えられるが、一例として、特定の文書を検索し、その文書に関連を持つ文書の一覧を探す場合の処理を以下のステップ２０１〜２０３において説明する。

ステップ２０１）
利用者は、文書を特定するための検索条件３１として、例えば文書種別、記述箇所の位置（ノードへのパス）、キーワード、各文書種別ごとの返却項目（ノードへのパス）を指定し、関連検索部３０に検索要求する。

ステップ２０２）
関連検索部３０は、グラフデータベース４０に対し、以下の操作を行うような問合せを発行する。

（ｉ）文書種別と記述箇所の位置に該当するノード群のうち、キーワードに合致する記述を持つものを取得する。

（ｉｉ）ヒットしたノードからエッジを（逆向きに）辿って、文書のルートノードを取得する。

（ｉｉｉ）文書のルートノードからエッジを辿って、自身以外からのエッジを持つノード（複数）を取得する。

（ｉｖ）該当する各ノードに対し、自身の文書以外のエッジを（逆向きに）辿って、関連する文書のルートノードを取得する。

（ｖ）関連する文書のルートノードから、それぞれの返却項目のノードを取得する。

ステップ２０３）
関連検索部３０は、返却項目の一覧を、結果として返す。

なお、ここではＮｅｏ４ｊに採用されているＣｙｐｈｅｒを例に説明しているが、ＳＰＡＲＱＬ等でも同様である。

本実施の形態に係る設計書情報管理システム（文書情報管理システムの例）は、１つ又は複数のコンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、設計書情報管理システムが有する機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、設計書情報管理システムで実施される処理に対応するプログラムを実行することによって実現することが可能である。また、上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

また、例えば、設計書情報管理システムにおけるグラフデータベース４０を１つのコンピュータに備え、ＸＭＬスキーマ解析部１０、ＸＭＬ・グラフ変換部２０、及び関連検索部３０を別の１つ又は複数のコンピュータ（プログラム）で実現することも可能である。

（実施例）
以下、ソフトウェア開発の設計書の管理を例にとって、設計書情報管理システムの処理内容をより具体的に説明する。

本実施例における画面設計書と処理設計書の構造を規定するＸＭＬスキーマ定義を、図８（リスト５）に示す。リスト５に示すように、画面設計書の画面名と、処理設計書の処理名のデータ型が、複数の要素宣言で共通的に定義されている。

本実施例のＸＭＬ文書群を図９に示す。図９に示すように、ＸＭＬ文書群として、５つの画面設計書（リスト６〜１０）と２つの処理設計書（リスト１１〜１２）が用意される。

上記のＸＭＬスキーマ（図８）、ＸＭＬ文書群（図９）に対し、内容の同一性判定を記述の完全一致とした場合における、データ格納処理のフローを図１０〜図１２に示す。これらのフローを参照して、データ格納処理を説明する。

＜事前処理＞
まず、図１０に示す事前処理を説明する。事前処理では、ＸＭＬスキーマ解析部１０がＸＭＬスキーマ（図８）を読み込み、解析する（ステップＰ０１）。

ＸＭＬスキーマ解析部１０は、解析結果をグラフデータベース４０に格納する（ステップＰ０２）。解析結果は、同一のデータ型が定義された要素宣言を判別しやすい形で保持しておく。リスト５（図８）では、画面設計書の「画面名」と処理設計書の「出力画面」が同一のデータ型「画面名ｔｙｐｅ」、画面設計書の「呼出し処理」と処理設計書の「処理名」が同一のデータ型「処理名ｔｙｐｅ」となっているので、例えばこれらを判別しやすい形で保持する。

＜格納処理＞
次に、図１１に示す格納処理を説明する。格納処理では、ＸＭＬ・グラフ変換部２０が、リスト６〜１２（図９）のＸＭＬ文書を順次読み込み（ステップＬ０１）、以下の処理を行う。

ＸＭＬ・グラフ変換部２０は、ＸＭＬ文書を構文解析する（ステップＬ０２）。次に、ＸＭＬ・グラフ変換部２０は、ＸＭＬスキーマ解析部１０を呼出し、構文解析結果とスキーマ解析結果を照合し、構文解析結果にスキーマ情報を付与する（ステップＬ０３）。

ＸＭＬ・グラフ変換部２０は、構文解析結果を、ＸＭＬの各要素と値（テキストノード、属性値）をノードに、親子関係をエッジとしたグラフデータに変換する（ステップＬ０４）。各ノードには、対応するスキーマ情報（要素宣言、データ型）をプロパティとして保持させる。

そして、ＸＭＬ・グラフ変換部２０は、各ノード及びエッジをグラフデータベース４０に格納する（ステップＬ０５）。

上記の処理を全てのＸＭＬ文書に対して行った後、処理を終了する（ステップＬ０６）。

＜ステップＬ０５の詳細＞
ステップＬ０５において、値ノードに対しては、同一のノードが既にデータベース４０内に存在しているかどうかチェックし、存在しない場合のみ新しいノードとして格納することとしている。このチェック処理により、同一ノードに複数のエッジが作成され、共有がなされる。このようなステップＬ０５における処理の詳細を図１２のフローを参照して説明する。

ＸＭＬ・グラフ変換部２０は、ステップＬ０４で得られたノード集合から１つのノードを取り出し（ステップＧ０１）、同一のノードがグラフデータベース４０内に存在するかどうかをチェックする（ステップＧ０２）。

同一ノードが存在しなければ（ステップＧ０２のＮｏ）、取り出したノードを新しいノードとしてグラフデータベース４０に追加する（ステップＧ０３）。同一ノードが存在する場合（ステップＧ０２のＮｏ）、新しいノードの追加を行わずにステップＧ０４に進む。

ステップＧ０４において、全ノードを処理していなければステップＧ０１に戻って別のノードについての処理を行い、全ノードを処理していればステップＧ０５に進む。

ステップＧ０５では、ＸＭＬ・グラフ変換部２０は、ステップＬ０４で得られたエッジ集合から１つのエッジを取り出しグラフデータベース４０に追加する。全てのエッジの処理を終了したら（ステップＧ０６のＹｅｓ）、処理を終了する。

図１０〜図１２の処理の結果、グラフデータベース４０には図１３に示すグラフデータが格納される。なお、図１３では、プロパティとして保持しているスキーマ情報は省略している。

＜検索処理例１＞
次に、関連検索部３０により実行される検索処理例１について、図１４のフローを参照して説明する。検索処理例１は、画面とそこから呼び出す処理の関連情報を取得する例である。

関連検索部３０は、検索条件とともに検索要求を受け付ける（ステップＳ０１）。検索条件は下記のとおりである。

始点となるノード：「画面設計書」全て
関連を持つノード：「呼出し処理」の値
関連先の基点ノード：「処理設計書」
返却値ノード：「画面設計書」の「画面名」の値と「概要」の値、「処理設計書」の「処理名」の値と「概要」の値
関連検索部３０は、グラフデータベース４０に対し、以下の操作を行うような問合せを発行することで検索を行う。

まず、始点ノードの条件を満たすノードを探し（ステップＳ０２）、条件を満たしたノードから始点ノードを探す（ステップＳ０３）。本実施例では、５つの「画面設計書」ノードが該当する。

ステップＳ０４、Ｓ０５は、関連を持つノード全てについて行う（ステップＳ０６）。ステップＳ０４では、始点ノードから、関連を持つノードへ辿る。本実施例では、エッジを辿って行き、「ＳＥＡＲＣＨ１」、「ＤＥＴＡＩＬ１」が重複して該当する。

また、ステップＳ０５では、関連を持つノードから、関連先の基点ノードまで辿る。本実施例では、エッジを（逆向きに）辿って行き、それぞれ、２つの「処理設計書」ノードが該当する。

そして、ステップＳ０７において、始点ノードとそれに対応する関連先の基点ノードから、それぞれの返却値ノードへ辿り、返却値を取得する。ステップＳ０８において、取得した結果を返却する。例えば、本実施例での取得結果を表で表すと図１５のようになる。

＜検索処理例２＞
次に、関連検索部３０により実行される検索処理例２について説明する。処理の流れ自体は検索処理例１と基本的に同じであり、図１４のフローに示すとおりである。検索処理例２では、検索実行画面から呼び出す処理とさらに出力される画面の関連情報を取得する。

関連検索部３０は、検索条件とともに検索要求を受け付ける（ステップＳ０１）。検索条件は下記のとおりである。

始点となるノード：「画面設計書」のうち「概要」に"検索実行"を含むもの
関連を持つノード（１）：「呼出し処理」の値
関連先の基点ノード（１）：「処理設計書」
関連を持つノード（２）：「出力画面」の値
関連先の基点ノード（２）：「画面設計書」
返却値ノード：「画面設計書」の「画面名」の値と「概要」の値、「処理設計書」の「処理名」の値と「概要」の値
関連検索部３０は、グラフデータベース４０に対し、以下の操作を行うような問合せを発行することで検索を行う。

まず、始点ノードの条件を満たすノードを探す（ステップＳ０２）。本実施例では、「画面設計書」の「概要」の値ノードに"検索実行"を含むものを探すと、「条件Ａを入力、検索実行する」、「条件Ｂを入力、検索実行する」の２つのノードが該当する。これは、従来技術のテキストの部分一致検索で実現できる。

次に、始点ノードを辿る（ステップＳ０３）。本実施例では、エッジを（逆向きに）辿り、それぞれの「画面設計書」ノードが該当する。

ステップＳ０４、Ｓ０５は、関連を持つノード全てについて行う（ステップＳ０６）。ステップＳ０４では、始点ノードから、関連を持つノード（１）へ辿る。本実施例では、エッジを辿って行き、「ＳＥＡＲＣＨ１」が重複して該当する。

ステップＳ０５では、関連を持つノード（１）から、関連先の基点ノード（１）まで辿る。本実施例では、エッジを（逆向きに）辿って行き、「処理設計書」ノードが該当する。

また、関連先の基点ノード（１）から、関連を持つノード（２）へ辿る。本実施例では、エッジを辿って行き、「エラー画面」、「検索結果画面」ノードが該当する。

更に、関連を持つノード（２）から、関連先の基点ノード（２）まで辿る。本実施例では、エッジを（逆向きに）辿って行き、それぞれの「画面設計書」ノードが該当する。

そして、ステップＳ０７において、始点ノードとそれに対応する関連先の基点ノード（１）、（２）から、それぞれの返却値ノードへ辿り、返却値を取得する。ステップＳ０８において、取得した結果を返却する。例えば、本実施例での取得結果を表で表すと図１６のようになる。

（実施の形態のまとめ、効果）
以上、説明したように、本実施の形態により、設計書情報管理システムが提供される。当該設計書情報管理システムは、ＸＭＬによって記述された設計書情報からなるＸＭＬ文書群と、そのＸＭＬ文書群の型情報を記述しているＸＭＬスキーマが存在するときに、ＸＭＬ文書群の型情報とＸＭＬ文書群に含まれる設計書情報を、ノードとエッジからなるグラフデータモデルに従って蓄積・管理するグラフデータベースを有する。

また、当該設計書情報管理システムは、ＸＭＬスキーマを読み込み、解析し、グラフデータベースに格納するＸＭＬスキーマ解析部と、ＸＭＬ文書群をロードし、グラフデータモデルに変換し、ＸＭＬスキーマ解析部によって読み込まれたＸＭＬスキーマの型情報を利用して、各ＸＭＬ文書に含まれる設計情報の各要素の同一性を判定することによって、異なるＸＭＬ文書にまたがる関連情報をエッジとして生成するＸＭＬ・グラフ変換部を有する。

上記の異なるＸＭＬ文書にまたがる関連情報をエッジとして生成することは、例えば、図１３において、「画面設計書」‐「呼出し処理」‐「ＳＥＡＲＣＨ１」の各エッジと、「処理設計書」‐「処理名」‐「ＳＥＡＲＣＨ１」の各エッジを生成することに相当する。

また、設計書情報管理システムは、始点となるノード・関連を持つノード・関連先の基点ノード・返却値ノードからなる検索条件を受け付け、その条件に合致する設計情報をグラフデータベースから検索することを可能とする関連検索部を有することとしてもよい。

本実施の形態の技術によれば、ＸＭＬ文書間の関連の抽出を自動的に行うことで情報付与・管理のコストがかからず、関連を直接的に管理することで、文書間の関連を高速に検索でき、かつ、グラフデータベースに対する検索要求も容易に指定できる設計書情報管理システムを実現できる。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１０ ＸＭＬスキーマ解析部
２０ ＸＭＬ・グラフ変換部
３０ 関連検索部
４０ グラフデータベース

Claims (7)

1. ノードとエッジからなるグラフデータを格納するグラフデータベースと、
   管理対象となる文書情報からなるマークアップ文書群の型情報を記述しているスキーマを読み込み、当該スキーマを解析するスキーマ解析手段と、
   前記マークアップ文書群を読み込み、当該マークアップ文書群を解析し、当該マークアップ文書群の各要素をノードに変換し、要素間の親子関係をエッジに変換することによりグラフデータを生成し、当該グラフデータを前記グラフデータベースに格納する変換手段と、を備え、
   前記変換手段は、前記スキーマ解析手段により得られた型情報に基づいて、前記マークアップ文書群に含まれる文書情報の要素間の同一性を判定することによって、異なるマークアップ文書にまたがる関連情報をエッジとして生成する
   ことを特徴とする文書情報管理システム。
2. 始点となるノード、関連を持つノード、関連先の基点ノード、及び返却値ノードからなる検索条件を受け付け、当該検索条件に合致する文書情報を前記グラフデータベースから検索する関連検索手段
   を更に備えることを特徴とする請求項１に記載の文書情報管理システム。
3. 前記マークアップ文書はＸＭＬ文書であり、前記スキーマはＸＭＬスキーマであることを特徴とする請求項１又は２に記載の文書情報管理システム。
4. ノードとエッジからなるグラフデータを格納するグラフデータベースを備える文書情報管理システムにおいて実行される文書情報管理方法であって、
   管理対象となる文書情報からなるマークアップ文書群の型情報を記述しているスキーマを読み込み、当該スキーマを解析するスキーマ解析ステップと、
   前記マークアップ文書群を読み込み、当該マークアップ文書群を解析し、当該マークアップ文書群の各要素をノードに変換し、要素間の親子関係をエッジに変換することによりグラフデータを生成し、当該グラフデータを前記グラフデータベースに格納する変換ステップと、を備え、
   前記変換ステップにおいて、前記スキーマ解析ステップにより得られた型情報に基づいて、前記マークアップ文書群に含まれる文書情報の要素間の同一性を判定することによって、異なるマークアップ文書にまたがる関連情報をエッジとして生成する
   ことを特徴とする文書情報管理方法。
5. 始点となるノード、関連を持つノード、関連先の基点ノード、及び返却値ノードからなる検索条件を受け付け、当該検索条件に合致する文書情報を前記グラフデータベースから検索する関連検索ステップ
   を更に備えることを特徴とする請求項４に記載の文書情報管理方法。
6. 前記マークアップ文書はＸＭＬ文書であり、前記スキーマはＸＭＬスキーマであることを特徴とする請求項４又は５に記載の文書情報管理方法。
7. コンピュータを、請求項１ないし３のうちいずれか１項に記載の文書情報管理システムにおける各手段として機能させるためのプログラム。

Images