JP2003288365A - 付加情報管理方法及び付加情報管理システム - Google Patents

Abstract

(57)【要約】 【課題】この発明は、元情報と付加情報とを別途に管理
し、しかも、両者の相互関係を容易に管理することがで
き、効率の良い情報の検索や抽出を行なうことを可能と
した付加情報管理方法及び付加情報管理システムを提供
することを目的としている。 【解決手段】構造化された元文書と、この元文書に付加
される付加情報とを、それぞれ、階層化された論理構造
を持つ別個の構造化データベース上で管理する。この場
合、各構造化データベースの階層化された論理構造を同
一にすることにより、元文書と付加情報との各構造化デ
ータベース上における位置を対応させて、いずれか一方
から他方を容易に参照可能としている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、構造化された情
報を、階層化された論理構造を持つ構造化データベース
で管理する構造化情報管理システムに係り、特に、管理
された異なる複数の構造化情報に対する印象や感想等を
表わす付加的な情報を、その構造化情報に関連付けて管
理する付加情報管理方法及び付加情報管理システムに関
する。

【０００２】

【従来の技術】周知のように、従来の文書管理方法にお
いては、大量の情報を一括管理する手法を主体としてい
たために、その情報を活用する際の効率面で問題が発生
している。

【０００３】このため、近年では、特定の個人や部門が
保有するノウハウや企業データのうち、企業の経営にと
って重要なものを蓄積して「経営資産」として活用しよ
うとする活動、すなわち、ナレッジマネジメントが提唱
されている。

【０００４】このナレッジマネジメントの中核をなす技
術として期待されている技術が、ＸＭＬ（eXtensible M
arkup Language）である。ＸＭＬは、柔軟な活用性と連
携性とを備えた標準のドキュメント記述言語であり、主
要ベンダーからのサポートも約束されている。

【０００５】ＸＭＬデータベースは、管理対象における
複数の構造化文書の各構成要素を、１つの巨大な構造化
文書の文書構造を構成する構成要素として管理する、Ｘ
ＭＬ特化のツリー上の階層的なデータ構造を持ってい
る。

【０００６】このように構造化されたＸＭＬデータベー
スを、ナレッジマネジメント用途として用いる際には、
ナレッジマネジメントの特徴である特定の個人や部門が
保有する情報を蓄積するために、さらなる情報の登録が
必要となる。このため、情報登録に関して管理者の負担
が非常に大きなものとなり、効率が低下する。

【０００７】しかしながら、管理者の負担を軽減するた
めに、情報の登録や管理をユーザに対して開放した場合
には、データベースの破損を招く等、安全性の面で問題
が生じる。

【０００８】この解決方法として、管理者が登録するデ
ータを元情報とし、ユーザの登録するデータを付加情報
として管理する方法が考えられている。ただし、この場
合には、元情報と、この元情報に付加される付加情報と
を別個に管理するために、両情報間の相互関連を示す情
報の管理が必要となる。この情報の管理は、管理者に依
存し、付加情報が多くなるに比例して非常に煩雑なもの
となる。

【０００９】公知の技術として、特開２００１−１７５
６４９号公報に記載された文書管理システムでは、付加
データ管理部が、文書管理部で管理している文書の任意
の領域に付された付加データを、文書に対応付けて、付
加データの作成者毎に管理している。

【００１０】そして、利用者から参照要求を受けると、
要求された文書のページを文書管理部から取り出すとと
もに、その文書に対応付けられた付加データを付加デー
タ管理部から取り出す。このとき、参照を要求したユー
ザ、あるいはユーザの設定にしたがい、取り出す付加デ
ータを制限することができる。

【００１１】この特許に関しては、文書と、この文書に
付加される付加データとを同一データベース上で管理し
ているため、それぞれ一方から他方を参照させるための
情報管理が必要となり、その管理が煩雑であるという問
題が生じる。

【００１２】また、特開２００１−２２７４９号公報に
記載されたオンライン文書への個人付加情報を共有する
方法では、タグ付けされたオンライン文書を対象とし、
個人付加情報が付加してある文書ＩＤと、タグのシーケ
ンシャル番号と、対象文字列と、その種類及び内容とを
合わせて管理する。

【００１３】次に、ユーザ毎に複数の個人付加情報をま
とめて管理するような個人付加シートを導入する。そし
て、シート毎に、当該シートを作成したユーザのＩＤ
と、他のユーザに対する当該シートのアクセス条件と
を、文書ＩＤや前述した個人付加情報とともに管理す
る。また、他のユーザが既存シート上に新たに個人付加
情報を追加する場合には、文書ＩＤの代わりに当該既存
シートのＩＤで添付先を一意に決定する。

【００１４】この特許に関しては、文書に付加される付
加情報を、利用者毎に管理しているために、他の利用者
の情報を参照する際にデータベースへの請求が必要とな
り、処理が遅くなるという問題が生じる。

【００１５】さらに、特開平１０−４０２５８号公報に
記載されたコンテンツと付加的情報の管理システム及び
そのシステムで管理されるコンテンツ及び付加的情報の
表示システムでは、データベースに蓄積されたコンテン
ツと、各コンテンツに対して与えられた付加的情報とを
管理する管理システムを対象としている。

【００１６】そして、複数のコンテンツをコンテンツ集
合として指定するコンテンツ集合指定手段と、該コンテ
ンツ集合指定手段にて指定された複数のコンテンツから
なるコンテンツ集合を管理するコンテンツ集合管理手段
と、各コンテンツに与えられた付加的情報を管理する付
加的情報管理手段とを備え、コンテンツ集合管理手段に
て管理されるコンテンツ集合に属する各コンテンツに対
して与えられた付加的情報を特定できるようにしてい
る。

【００１７】この特許に関しては、文書に対して付加情
報を１対１の対応形式にしていないため、それぞれの文
書と複数に関連付けされている付加情報との関係を示す
情報の管理が別途に必要となり、その管理が煩雑である
という問題が生じる。

【００１８】

【発明が解決しようとする課題】以上のように、元情報
とこの元情報に付加される付加情報とをデータベース上
に格納し管理する際に、元情報に付加情報を一体化させ
て管理した場合は、元情報から対応する付加情報を参照
するのが容易である反面、元情報の信頼性が損なわれ易
く、データベースの安全性が確保され難いという問題が
生じる。

【００１９】また、元情報と付加情報とを別々に管理す
る方法もあるが、元情報と付加情報とを相互に関係付け
ておくための情報管理が必要となり、その情報を管理保
持するために管理者への負担が増大し、利便性が損なわ
れるという問題が生じる。また、付加情報の量が多くな
ると、それらの整理が煩雑になり、情報の検索や抽出に
長い時間を要するという不都合も生じる。

【００２０】そこで、この発明は上記事情を考慮してな
されたもので、元情報と付加情報とを別途に管理し、し
かも、両者の相互関係を容易に管理することができ、効
率の良い情報の検索や抽出を行なうことを可能とした極
めて良好な付加情報管理方法及び付加情報管理システム
を提供することを目的とする。

【００２１】

【課題を解決するための手段】上述した従来の問題点に
対して、この発明は以下のような解決法を持つ。すなわ
ち、元情報とこの元情報に付加される付加情報とを別々
のデータベース上で管理し、それぞれのデータベースの
構造を全く同一のものにすることによって、一方の位置
が判明すれば対応する他方の情報の位置も判明するよう
にする。このため、元情報と付加情報とを対応付けるた
めの情報管理が不要となる。

【００２２】元情報に対する付加情報は、内部に他ユー
ザの情報等を全て保持する。このため、位置の特定が容
易であり、他ユーザ情報の閲覧が容易となる。これに伴
なう情報の増加による管理の煩雑化等の問題点は、構造
化文書（ＸＭＬ）を用いて要素（タグ）単位毎に管理が
可能になるために回避される。

【００２３】元情報に対応する付加情報は、元情報と１
対１の関係で上記の方法にてデータベース上に管理され
ているため、必要な情報を取得するのが容易であり、関
連性を維持するための情報管理が不要である。また、こ
れにより付加情報が煩雑になる等の問題点は、構造化情
報（ＸＭＬ）を用いて要素（タグ）単位で管理すること
により回避している。

【００２４】換言すれば、この発明は、構造化されたデ
ータベースで管理される元情報と、構造化されたデータ
ベースにおいて管理される元情報に対して付加された付
加情報との管理方法において、上述したような問題点を
解決するための手法を持つことを特徴としたものであ
る。

【００２５】上述の問題点を解決するために、この発明
では、元情報とこの元情報を構成する任意の要素に付さ
れた付加情報とを異なるデータベースにて、お互いの相
互関係を維持したまま管理を行ない、元情報に対して参
照要求がある場合は対応する付加情報を検索して出力す
るとともに、付加情報に対して検索がある場合にはそれ
に対する元情報を検索して出力することを特徴とするも
のである。

【００２６】具体的には、元情報、付加情報共に膨大な
数の構造化情報を、それぞれ１つづつの巨大な構造化情
報として一元管理するとともに、元情報より構成される
一元管理された構造化情報と、付加情報より構成される
一元管理された構造化情報との内的な構造を同一のもの
とすることにより、元情報に対する参照要求に対応する
付加情報を抽出し、かつ、付加情報に対する参照要求に
対応する元情報を抽出することが可能な広域な情報検索
システムが容易に構築できる。

【００２７】データベース上の各構造化情報の存在する
論理的なエリアは、構造化情報パスを用いて指定する。
すなわち、元情報と付加情報とが、データベースの名称
は異なるが、同一のパスを持つことによって抽出検索を
容易なものとしている。

【００２８】このように、元情報と付加情報とを別途に
管理することにより、付加情報に編集を加える場合も元
情報に影響を及ぼすことがなく、付加情報は各元情報に
対し１対１にて管理しているために、１つの元情報に対
して複数のユーザの情報を集中管理するためにユーザが
他ユーザの情報を閲覧することが可能であり、付加情報
を元に元情報単位で分析や知識の収集を行なうことが可
能である。

【００２９】元情報と付加情報とを構築する構造化情報
の構築方法としてＸＭＬを用いているが、ＸＭＬの特徴
として出力形式を外部に持つことが可能であり、ＸＳＬ
（eXtensible Stylesheet Language）という形で定義さ
れている。

【００３０】この発明における元情報と付加情報との関
係をこれに適用し、元情報としてのＸＭＬより構成され
る任意の構造化情報に対して、付加情報としてＸＭＬの
出力情報であるＸＳＬを対応させることにより、元情報
と出力形式を効率よく管理することが可能である。

【００３１】また、付加情報は、元情報に対し情報単位
で管理されるために、複数のＸＳＬを一元管理させるこ
とにより、複数のＸＳＬを１つの情報に対応付けること
が可能である。

【００３２】このため、ユーザの要求に応じて、対応す
る情報を元に付加情報よりユーザの請求に応じた出力形
式を対応させて出力させることが可能となる。

【００３３】元情報と付加情報とを構築する構造化情報
の構築方法としてＸＭＬを用いているが、ＸＭＬの特徴
としてどのような要素を用いて構造化を構築するかは、
情報構造定義情報であるＤＴＤ（Document Type Defini
tion）によって定義されるものである。

【００３４】この発明における元情報と付加情報との関
係をこれに適用し、元情報としてのＸＭＬに対し管理者
が変更を行なう際に、付加情報として情報構造定義情報
であるＤＴＤを適用して、情報に対し情報構造の同一性
を保持するための予め定められた情報構造の作成支援を
容易に行なうことが可能である。

【００３５】付加情報は、元情報に対し情報単位で管理
させるために複数のＤＴＤを一元管理させることによ
り、１つの元情報に対し複数のＤＴＤを用意することが
可能である。これにより、管理者が元情報の変更を行な
う際に、予め定められた複数のＤＴＤにしたがって作業
することが可能である。

【００３６】元情報と付加情報とを構築する構造化情報
の構築方法としてＸＭＬを用いているが、ＸＭＬの特徴
として情報全体が各要素より成り立つものである。

【００３７】この発明では、元情報の構成要素を最小単
位として付加情報を付加することが可能である。

【００３８】元情報を構成する内部の要素をユーザの請
求によりユーザの環境に出力する際に、元情報を構築す
る要素の付加情報に出力可能であるかどうかの段階を持
たせることにより、ユーザに対し元情報の要素毎に出力
制限を掛けることが可能となる。

【００３９】

【発明の実施の形態】以下、この発明の実施の形態につ
いて図面を参照して詳細に説明する。まず、構造化文書
管理システムについて説明すると、構造化文書として、
前述したＸＭＬやＳＧＭＬ（Standard Generalized Mar
kup Language）等で記述した文書が挙げられる。

【００４０】ＸＭＬとは、Ｗ３Ｃ（World Wide Web Con
sortium）にて定められた規格である。ＳＧＭＬとは、
ＩＳＯ（International Organization for Standardiza
tion）で定められた規格である。それぞれ文書を構造化
することを可能とする構造化文書規約である。

【００４１】以下、構造化文書として、ＸＭＬにて記述
された文書を例に説明を進める。構造化文書の文書構造
を定義したデータ（文書構造定義データ）をスキーマと
称している。ＸＭＬでは、そのスキーマを定義するため
にＸＭＬ−SchemaやＸＤＲ（XML Data Reduced）等のス
キーマ言語が提案されている。ここでは、例えばＸＤＲ
でのスキーマを記述する場合を例にとり説明する。

【００４２】スキーマも、構造化文書管理システムの管
理対象となる構造化文書であって、スキーマ文書と称さ
れることがある。このスキーマ文書と区別するために、
例えば、特許明細書、メール、週報、広告等の種々雑多
な内容を有する文書を、コンテンツ文書と称することも
ある。

【００４３】構造化文書管理システムでは、上記スキー
マ文書、上記コンテンツ文書、さらに、後述するような
ユーザからの検索要求内容を記述したクエリ、すなわ
ち、クエリ文書も管理対象とし、これらを総称して「文
書」と称している。以下、特に断わりがない場合、「文
書」と称するときは、コンテンツ文書、スキーマ文書、
クエリ文書を全て指すものとする。

【００４４】次に、上記ＸＭＬについて簡単に説明す
る。図２は、ＸＭＬで記述された構造化文書の一例とし
て、「特許」情報の例を示している。ＸＭＬやＳＧＭＬ
では、文書の構造の表現にタグが用いられる。タグに
は、開始タグと終了タグとがあり、文書構造情報の構成
要素を開始タグと終了タグとで囲むことにより、文書中
の文字列（テキスト）区切りと、そのテキストが構造上
どの構成要素に属するのかを明確に記述することができ
る。

【００４５】ここで、開始タグとは、要素名称を記号
「＜」と「＞」とで閉じたものであって、終了タグと
は、要素名称を記号「＜／」と「＞」とで閉じたもので
ある。タグに続く構成要素の内容が、テキスト（文字
列）または子供の構成要素の繰り返しである。

【００４６】また、開始タグには、「＜要素名称 属性
＝“属性値”＞」等のように、属性情報を設定すること
ができる。さらに、「＜特許ＤＢ＞＜／特許ＤＢ＞」の
ように、テキストを含まない構成要素は、簡易記法とし
て「＜特許ＤＢ／＞」のように表わすこともできる。

【００４７】図２に示した文書は、「特許」タグから始
まる要素をルート（根）とし、その子要素として「タイ
トル」、「出願日」、「出願者」、「要約」タグから始
まる要素集合が存在している。また、「タイトル」タグ
から始まる要素には、「ＸＭＬデータベース」といっ
た、１つのテキスト（文字列）が存在する。

【００４８】ＸＭＬ等の構造化文書は、任意の構成要素
を繰り返し含んでいたり、さらには文書構造があらかじ
め決まっていない［ＲＤＢ（Relational Data Base）や
ＯＯＤＢ（オブジェクト指向データベース）のスキーマ
では定義できない］のが普通である。

【００４９】図２に示したような構造化文書を論理的に
表現するために、図３に示すようなツリー表現が用いら
れる。ツリーは、ノード（番号が付され、円形で示され
たもの）とアーク（ノードを表わす円形間を繋ぐデータ
付き線）と四角形で囲まれたテキストとから構成されて
いる。

【００５０】ノードは、文書オブジェクトに対応し、こ
のノードからタグ名や属性名に相当するラベルが付与さ
れた複数のアークが出ている。このアークの先は、他の
ノード、または、要素値としての文字列（テキスト）に
繋がる。また、ノードの中に記載されている英数字（＃
０、＃４９等）は、オブジェクトＩＤである。

【００５１】図３に示したツリー構造を、図２に示した
構造化文書の文書オブジェクトツリーと称する。

【００５２】図１は、この実施の形態で説明する付加情
報管理システムを示している。図１において、付加情報
管理システムは、大きく分けて、要求制御部１、アクセ
ス要求処理部２、検索要求処理部３、データアクセス部
４、付加情報記憶部５及び元文書記憶部６とから構成さ
れている。付加情報記憶部５及び元文書記憶部６は、例
えば外部記憶装置を用いて構成される。図１のシステム
構成は、ソフトウェアを用いても実現可能である。

【００５３】要求制御部１は、要求受付部１１と結果処
理部１２とから構成されている。要求受付部１１は、ユ
ーザからの付加情報追加、付加情報及び元文書の取得、
付加情報や元文書に対する検索等の要求を受け付けて、
アクセス要求処理部２を呼び出す。結果処理部１２は、
アクセス要求処理部２が処理した結果を要求元のユーザ
に返す処理を行なう。

【００５４】アクセス要求処理部２は、ユーザからの付
加情報追加、付加情報及び元文書の取得等に対応した複
数の処理部から構成されている。つまり、このアクセス
処理部２は、付加情報格納部２１、付加情報取得部２２
及び元文書取得部２３とから構成されている。

【００５５】付加情報格納部２１は、付加情報記憶部５
の中の論理的な指定エリアに文書を格納する処理を行な
う。付加情報取得部２２は、付加情報記憶部５の中の論
理的な指定エリアが指定されたときに、その指定エリア
に存在する文書を取得する処理を行なう。元文書取得部
２３は、元文書記憶部６の中の論理的な指定エリアが指
定されたときに、その指定エリアに存在する文書を取得
する処理を行なう。

【００５６】付加情報記憶部５と元文書記憶部６とは、
構造化文書データベースであり、例えば図４に示すよう
に、付加情報や元文書を、ＵＮＩＸ（登録商標）のディ
レクトリ構造のように、階層的にツリー構造上に格納し
ている。

【００５７】図４に示すように、元文書記憶部６は、図
３に示した１つの構造化文書のツリー構造と同様に表現
できる。すなわち、任意のノード以下の部分階層木（部
分ツリー）は、元文書記憶部６から切り出された構造化
文書であり、ここでは、これを元文書オブジェクトツリ
ーと称する。

【００５８】各ノードには、オブジェクトＩＤが割り当
てられている。このオブジェクトＩＤは、元文書記憶部
６内ではユニークな数値を持つものとする。階層木のル
ートとなるノードには、それがルートノードであること
を特定するためのオブジェクトＩＤ「＃０」が割り当て
られるものとする。

【００５９】ルートノード、すなわち、「＃０」のノー
ドからは、「ｒｏｏｔ」タグを先頭に持つ「＃１」のノ
ードにリンクが張られている。「＃１」のノードから
は、「特許ＤＢ」タグを先頭に持つ「＃２」のノードに
リンクが張られている。「＃２」のノードからは、「特
許」タグを先頭に持つ「＃４２」のノードにリンクが張
られている。

【００６０】図２に示した「特許」情報は、「＃４２」
のノード以下の部分ツリーに対応している。このノード
からは、「タイトル」タグ、「出願日」タグ、「出願
者」タグ、「要約」タグ等を先頭に持つ各ノードにリン
クが張られ、末端のノードからは、「ＸＭＬデータベー
ス」、「Ｔ社」、「ＸＭＬに対する付加情報を統一的に
管理する」等の文字列（要素値）にリンクが張られてい
る。

【００６１】ところで、例えば、「＃４３」のノードに
リンクされた「ＸＭＬデータベース」という要素値は、
「＃４３」のノードと「＃value」という特殊なタグ名
で接続されている。このタグ名は、「＃」で始まるた
め、ＸＭＬ規格においては標準的なタグ名として利用す
ることはできない。

【００６２】このような元文書記憶部６の特定ノードを
指定するために、構造化文書パスを用いる。構造化文書
パスは「／／ｒｏｏｔ」から始まる文字列である。例え
ば、「／／ｒｏｏｔ／特許ＤＢ」は、「＃１」のノード
から「特許ＤＢ」が付与されたアークが指し示すノー
ド、つまり、「＃２」のノードに対応する。このように
「ｒｏｏｔ」から「／」で区切られた部分文字列をタグ
名とみなすことで、「＃０」のノードからタグ名の並び
に沿って対応するアークを下っていき、その最後のアー
クが指すノードが、パスの場所を指し示している。

【００６３】例えば、「／／ｒｏｏｔ／特許ＤＢ／特
許」は、「＃４２」のノード、「／／ｒｏｏｔ／特許Ｄ
Ｂ／出願日／年」は、「＃４５」のノードを指し示して
いる。

【００６４】「＃２」のノード以下に、すなわち、「特
許ＤＢ」に、複数の「特許」情報を格納する場合には、
個々の「特許」情報を識別するために、構造化文書パス
にインデックス表現が可能である。

【００６５】「特許ＤＢ」の最初の「特許」情報であれ
ば、「／／ｒｏｏｔ／特許ＤＢ／特許［０］」となる
が、これは「／／ｒｏｏｔ／特許ＤＢ／特許」と同じと
みなしている。

【００６６】「特許ＤＢ」の２番目の「特許」情報であ
れば、「／／ｒｏｏｔ／特許ＤＢ／特許［１］ＤＢ」の
５番目の「特許」情報であれば、「／／ｒｏｏｔ／特許
ＤＢ／特許［４］」となる。

【００６７】図６に示すように、付加情報記憶部５も、
図４に示した１つの構造化文書のツリー構造と同様に表
現できる。すなわち、任意のノード以下の部分階層木
（部分ツリー）は、付加情報記憶部５から切り出された
構造化文書であり、ここでは、これを付加情報オブジェ
クトツリーと称する。

【００６８】各付加情報ノードには、付加対象となるノ
ードのＩＤを用い、ＩＤに付加情報独自のＩＤを付加す
る。付加情報ＩＤは、付加対象となるノードの下ではユ
ニークな数値であり、付加対象となるノードは、構造化
文書データベース内でユニークな数値を持つために、結
果として付加情報ＩＤも、構造化データベース内でユニ
ークな数値を持つこととなる。

【００６９】階層木のルートとなるノードには、それが
ルートノードであることを特定するためのオブジェクト
ＩＤ「＃０」が割り当てられるものとする。

【００７０】ルートノード、すなわち、「＃０」のノー
ドからは、「ｒｏｏｔ」タグを先頭に持つ「＃１」のノ
ードにリンクが張られている。「＃１」のノードから
は、「特許付加情報ＤＢ」タグを先頭に持つ「＃２」の
ノードにリンクが張られている。「＃２」のノードから
は、「特許」タグを先頭に持つ「＃４２」のノードにリ
ンクが張られている。

【００７１】図５に示した「特許」情報に対して付加さ
れた付加情報は、「＃４２」のノード以下の部分ツリー
に対応している。「＃４２」以下の部分ツリーも、元文
書記憶部６の「＃４２」以下の部分ツリーと同じ構造を
持ち、付加情報は付加対象となる元文書の各要素に対し
て分割され、以下のようにリンクが貼られる。

【００７２】すなわち、「＃４２」のノードからは、
「＃４２」である「特許」タグに付加された情報である
「有効度」タグを先頭に持つノードにリンクが張られ、
末端のノードからは、付加情報である「非常に有用であ
る」等の文字列（要素値）にリンクが張られている。

【００７３】このように、元文書に付加された付加情報
記憶部５の特定ノードを指定するために、元文書記憶部
６にて特定ノードを指定した方法と同様に構造化文書パ
スを用いることが可能である。

【００７４】例えば「／／ｒｏｏｔ／特許付加情報ＤＢ
／特許」は、「＃４２」のノードに付加している付加情
報を指し示している。

【００７５】構造化文書パスを用いるにあたって、デー
タベース部分の名称を変えることにより、元文書記憶部
６の特定ノードを指定する構造化文書パスで、付加情報
記憶部５内における元文書記憶部６の特定ノードに対応
する付加情報ノードを指定することが可能である。

【００７６】図１の説明に戻る。データアクセス部４
は、付加情報記憶部５及び元文書記憶部６をアクセスす
る基本インターフェースの集合である。このデータアク
セス部４は、付加情報オブジェクトツリー格納部４１、
付加情報オブジェクトツリー取得部４２、元文書オブジ
ェクトツリー取得部４３及び文書パーサ部４４とから構
成される。

【００７７】付加情報オブジェクトツリー格納部４１
は、付加情報記憶部５中の物理的な指定エリアに付加情
報を格納する処理を行なう。付加情報オブジェクトツリ
ー取得部４２は、付加情報記憶部５中の物理的な指定エ
リアに存在する付加情報を取得する処理を行なう。

【００７８】元文書オブジェクトツリー取得部４３は、
元文書記憶部６中の物理的な指定エリアに存在する元文
書データを取得する処理を行なう。文書パーサ部４４
は、ユーザによる元文書取得要求または付加情報取得要
求に応じて取得した元文書オブジェクトツリー、付加情
報オブジェクトツリーまたはその両方を、クライアント
１０２の表示部１０３に出力するためにＸＭＬ文書に変
換するものである。

【００７９】付加情報記憶部５中の物理的な指定エリア
とは、構造化文書データベース内ではユニークな文書デ
ータの存在場所を指し示す内部データである。ユーザに
とっては、認識不能なデータである。

【００８０】元文書記憶部６中の物理的な指定エリアと
は、構造化文書データベース内ではユニークな文書デー
タの存在場所を指し示す内部データである。ユーザにと
っては、認識不能なデータである。

【００８１】また、上記検索要求処理部３は、付加情報
記憶部５または元文書記憶部６中に格納されたそれぞれ
のデータを検索する処理を行なう。

【００８２】付加情報記憶部５に対する検索要求の場
合、要求制御部１の要求受付部１１でユーザからの付加
情報に対する検索要求が受け付けられると、検索要求処
理部３は、データアクセス部４を通して付加情報記憶部
５にアクセスして検索要求に合致する付加情報集合を取
得し、検索要求に合致する付加情報集合に対応する元文
書データを元文書記憶部６より取得する。その取得結果
は、検索要求の対象として結果処理部１２を介して出力
される。

【００８３】また、元文書記憶部６に対する検索要求の
場合、要求制御部１の要求受付部１１でユーザからの付
加情報に対する検索要求が受け付けられると、検索要求
処理部３は、データアクセス部４を通して元文書記憶部
６にアクセスして検索要求に合致する元文書集合を取得
し、検索要求に合致する元文書集合に対応する付加情報
を付加情報記憶部５より取得する。その取得結果は、検
索要求の対象としてを対象として結果処理部１２を介し
て出力される。

【００８４】図７は、図１に示した構造化文書管理シス
テムの一利用形態を示している。図７では、ＷＷＷのバ
ックエンドで、図１に示した構成の付加情報管理システ
ム１００が動作している場合を示している。

【００８５】複数（図７では３つ）のクライアント端末
（例えばパーソナルコンピュータ、携帯通信端末等）１
０２のそれぞれで、ＷＷＷブラウザ１０３が動作してい
る。ユーザは、各クライアント端末１０２からＷＷＷサ
ーバ１０１にアクセスすることにより、付加情報管理シ
ステム１００にアクセスすることができる。

【００８６】ＷＷＷブラウザ１０３とＷＷＷサーバ１０
１とは、ＨＴＴＰ（Hyper Text Transfer Protocol）で
通信している。

【００８７】ユーザからの文書格納、文書取得、文書検
索等の要求は、ＷＷＷブラウザ１０３から送信されて、
ＷＷＷサーバ１０１を通して付加情報管理システム１０
０に受け付けられ、処理された結果は、ＷＷＷサーバ１
０１を通して要求元のＷＷＷブラウザ１０３へ返信され
る。

【００８８】（１）付加情報格納処理 次に、図１に示した付加情報管理システムの付加情報格
納処理動作について、図８に示すフローチャートを参照
して説明する。すなわち、クライアント端末から付加情
報管理システムに対して送信された文書格納要求が、要
求受付部１１にて受け付けられたとき、図８に示した処
理動作が行なわれる。

【００８９】ここでは、例えば元文書が図４に示すよう
な状態であった場合に、「／／ｒｏｏｔ／特許ＤＢ／特
許［０］」に対して「＜Ａ＞付加情報＜／Ａ＞」（以
下、付加情報と称する）を付加情報格納部２１に渡す
（ステップＳ１）場合について説明する。

【００９０】付加文書格納部２１は、元文書オブジェク
トツリー取得部４３に構造化文書パスを渡す。元文書オ
ブジェクトツリー取得部４３は、構造化文書パスから元
文書記憶部６中の物理的なエリアを特定することによ
り、そのエリアに存在する構造化文書パスにて表記され
たノード（元文書オブジェクトＯｘ０）を含む元文書オ
ブジェクトツリーを取得する（ステップＳ２）。

【００９１】この取得処理が完了することにより、付加
情報を付加するべき元文書データが存在することが証明
されると（ステップＳ３で有）、ステップＳ５に進む。

【００９２】また、指定された構造化文書パスからそれ
に対応する元文書オブジェクトＯｘ０が見つからなけれ
ば（ステップＳ３で無）、エラーとなり、付加情報格納
部２１及び結果処理部１２を介してクライアント端末に
「付加情報格納失敗」の旨のメッセージを返す（ステッ
プＳ４）。

【００９３】付加文書格納部２１は、元文書オブジェク
トツリー取得部４３より付加情報が付加される元文書デ
ータの存在を確認する。元文書記憶部６における付加情
報の付加対象となる元文書の物理的なエリアを指定する
構造化文書パスと、付加情報記憶部５における付加情報
の物理的なエリアを指定する構造化文書パスとは、デー
タベース指定部分を除いて同一である。

【００９４】このため、付加文書格納部２１は、付加情
報を格納するための構造化文書パスを取得するために、
ユーザから指定された構造化文書パスのデータベース記
述部分を、付加情報記憶部６である付加情報データベー
スを指定するように変換する（ステップＳ５）。

【００９５】付加文書格納部２１は、構造化文書パス変
換後、付加情報オブジェクトツリー取得部４２に構造化
文書パスを渡す。この付加情報オブジェクトツリー取得
部４２は、構造化文書パスから付加情報記憶部５中の物
理的なエリアを特定することにより、そのエリアに存在
する構造化文書パスにて表わされたノード（付加情報オ
ブジェクトＯｘ０）を含む付加情報オブジェクトツリー
を取得する（ステップＳ６）。

【００９６】そして、構造化文書パスが正しければ、付
加情報オブジェクトＯｘ０のオブジェクトＩＤを取得す
ることができるので（ステップＳ７でＹＥＳ）、その場
合はステップＳ９に進む。

【００９７】また、指定された構造化文書パスから、そ
れに対応する付加情報オブジェクトＯｘ０が見つからな
ければ（ステップＳ７でＮＯ）、エラーとなり、付加情
報格納部２１及び結果処理部１２を介してクライアント
端末に「付加情報格納失敗」の旨のメッセージを返す
（ステップＳ８）。

【００９８】ステップＳ９では、格納付加情報の付加情
報オブジェクトツリーが、付加情報オブジェクトＯｘ０
以下に追加される。すなわち、付加情報格納部２１によ
り、格納付加情報の付加情報オブジェクトツリーを構成
する各付加情報オブジェクト（のファイル）にオブジェ
クトＩＤが与えられ、付加情報オブジェクトＯｘ０から
格納付加情報の付加情報オブジェクトツリーにおける先
頭の付加情報オブジェクトにリンクが張られる。

【００９９】そして、付加情報オブジェクトツリー格納
部４１により、格納付加情報の付加情報オブジェクトツ
リーを構成する各付加情報オブジェクト（のファイル）
が付加情報記憶部５に格納される。

【０１００】（２）元文書取得処理 次に、図１に示した付加情報管理システムにおいて、付
加情報の付加対象となる元文書の取得処理動作につい
て、図９に示すフローチャートを参照して説明する。す
なわち、クライアント端末から付加情報管理システムに
対し、元文書取得要求として取得コマンドが送信され、
要求受付部１１にて受け付けられたとき、図９に示した
処理動作が行なわれる。

【０１０１】ここでは、例えば元文書が図８に示した状
態のときに「／／ｒｏｏｔ／特許ＤＢ」を取得する作業
を行なう場合を例にとり説明する。要求受付部１１は、
元文書取得命令を受け付けると、構造化文書パス「／／
ｒｏｏｔ／特許ＤＢ」を元文書取得部２３に渡す（ステ
ップＳ１１）。

【０１０２】元文書取得部２３は、元文書オブジェクト
ツリー取得部４３に構造化文書パスを渡す。元文書オブ
ジェクトツリー取得部４３は、構造化文書パスから元文
書記憶部６中の物理的なエリアを特定することにより、
そのエリアに存在する構造化文書パスにて表わされたノ
ード（元文書オブジェクトＯｘ５）を取り出す（ステッ
プＳ１２）。

【０１０３】構造化文書パスの指定が正しければ、元文
書オブジェクトＯｘ５のオブジェクトＩＤを取得するこ
とができるので（ステップＳ１３でＹＥＳ）、その場合
はステップＳ１５に進む。

【０１０４】また、ステップＳ１２において、指定され
た構造化文書パスからそれに対応する元文書オブジェク
トＯｘ５が見つからなければ（ステップＳ１３でＮ
Ｏ）、エラーとなり、元文書取得部２３及び結果処理部
１２を介して、クライアント端末に「元文書取得失敗」
のメッセージを返す（ステップＳ１４）。

【０１０５】上記ステップＳ１５では、ステップＳ１２
で取得した元文書オブジェクトＯｘ５から、元文書オブ
ジェクトＯｘ５以下のオブジェクトツリーを取得する。
取得した元文書オブジェクトツリーは、文書パーサ部４
４にてＸＭＬ文書に変換される（ステップＳ１６）。

【０１０６】元文書記憶部６における付加情報の付加対
象となる元文書の物理的なエリアを指定する構造化文書
パスと、付加情報記憶部５における付加情報の物理的な
エリアを指定する構造化文書パスとは、データベース指
定部分を除いて同一である。

【０１０７】このため、元文書取得部２３は、付加情報
を格納するための構造化文書パスを取得するために、ユ
ーザから指定された構造化文書パスのデータベース記述
部分を、付加情報記憶部５である付加情報データベース
を指定するよう変換する（ステップＳ１７）。

【０１０８】元文書取得部２３は、構造化文書パス変更
後、付加情報オブジェクトツリー取得部４２に構造化文
書パスを渡す。付加情報オブジェクトツリー取得部４２
は、構造化文書パスから付加情報記憶部５中の物理的な
エリアを特定することによって、そのエリアに存在する
構造化文書パスにて表わされたノード（付加情報オブジ
ェクトＯｘ５）を取り出す（ステップＳ１８）。

【０１０９】構造化文書パスの指定が正しければ、付加
情報オブジェクトＯｘ５のオブジェクトＩＤを取得する
ことができるので（ステップＳ１９でＹＥＳ）、その場
合はステップＳ２０に進む。

【０１１０】ステップＳ１８において、指定された構造
化文書パスから、それに対応する付加情報オブジェクト
Ｏｘ５が見つからなければ（ステップＳ１９でＮＯ）、
元文書に対する付加情報が存在しないために、元文書取
得部２３にメッセージを通知した後にステップＳ２１に
進む。

【０１１１】ステップＳ１８で取得した付加情報オブジ
ェクトＯｘ５から、付加情報オブジェクトＯｘ５以下の
オブジェクトツリーを取得する。取得した元文書オブジ
ェクトツリーは、文書パーサ部４４にてＸＭＬ文書に変
換される（ステップＳ２０）。例えば取得した元文書と
付加情報とは統合されて、図１１に示すような情報のＸ
ＭＬ文書となる。

【０１１２】元文書取得部２３は、それぞれ取得したＸ
ＭＬ文書を、例えばＸＳＬ（Extensible Stylesheet La
nguage）といった所定のスタイルシートとともに、クラ
イアント端末に返す（ステップＳ２１）。クライアント
端末では、図１１に示したＸＭＬ文書を、スタイルシー
トを用いてＨＴＭＬデータに変換して、クライアント領
域に表示する。

【０１１３】ＸＳＬを利用すると、ＸＭＬ文書を様々な
形に変換することができる。違う構造のＸＭＬ文書に変
換することもできるし、ＸＭＬ文書からＨＴＭＬページ
を生成することも可能である。

【０１１４】（３）付加情報取得処理 次に、図１に示した付加情報管理システムにおける付加
情報の取得処理動作について、図１０に示すフローチャ
ートを参照して説明する。すなわち、クライアント端末
から付加情報管理システムに対し、付加情報取得要求と
して取得コマンドが送信され、要求受付部１１にて受け
付けられたとき、図１０に示した処理動作が行なわれ
る。

【０１１５】ここでは、例えば元文書が図８に示した状
態のときに「／／ｒｏｏｔ／特許ＤＢ」と対応する付加
情報を取得する作業を行なう場合を例にとり説明する。
要求受付部１１は、付加情報取得命令を受け付けると、
構造化文書パス「／／ｒｏｏｔ／特許ＤＢ」を付加情報
取得部２２に渡す（ステップＳ３１）。

【０１１６】付加情報取得部２２は、付加情報オブジェ
クトツリー取得部４２に構造化文書パスを渡す。付加情
報オブジェクトツリー取得部４２は、構造化文書パスか
ら付加情報記憶部５中の物理的なエリアを特定すること
により、そのエリアに存在する構造化文書パスにて表わ
されたノード（付加情報オブジェクトＯｘ５）を取り出
す（ステップＳ３２）。

【０１１７】構造化文書パスの指定が正しければ、付加
情報オブジェクトＯｘ５のオブジェクトＩＤを取得する
ことができるので（ステップＳ３３でＹＥＳ）、その場
合はステップＳ３５へ進む。

【０１１８】ステップＳ３２において、指定された構造
化文書パスからそれに対応する付加情報オブジェクトＯ
ｘ５が見つからなければ（ステップＳ３３でＮＯ）、エ
ラーとなり、付加情報取得部２２及び結果処理部１２を
介して、クライアント端末に「元文書取得失敗」のメッ
セージを返す（ステップＳ３４）。

【０１１９】ステップＳ３５では、ステップＳ３２にて
取得した付加情報オブジェクトＯｘ５から、付加情報オ
ブジェクトＯｘ５以下のオブジェクトツリーを取得す
る。取得した付加情報オブジェクトツリーは、文書パー
サ部４４にてＸＭＬ文書に変換される（ステップＳ３
６）。

【０１２０】付加情報記憶部５における付加情報の物理
的なエリアを指定する構造化文書パスと、元文書記憶部
６における付加情報の付加対象となる元文書の物理的な
エリアを指定する構造化文書パスとは、データベース指
定部分を除いて同一である。このため、付加情報取得部
２２は、付加情報の付加対象となる元文書を格納するた
めの構造化文書パスを取得するために、ユーザから指定
された構造化文書パスのデータベース記述部分を、元文
書記憶部６である付加情報データベースを指定するよう
変換する（ステップＳ３７）。

【０１２１】付加情報取得部２２は、構造化文書パス変
更後、元文書オブジェクトツリー取得部４３に構造化文
書パスを渡す。元文書オブジェクトツリー取得部４３
は、構造化文書パスから元文書記憶部６中の物理的なエ
リアを特定することにより、そのエリアに存在する構造
化文書パスにて表わされたノード（元文書オブジェクト
Ｏｘ５）を取り出す（ステップＳ３８）。

【０１２２】構造化文書パスの指定が正しければ、元文
書オブジェクトＯｘ５のオブジェクトＩＤを取得するこ
とができるので（ステップＳ３９でＹＥＳ）、その場合
はステップＳ４１へ進む。

【０１２３】また、ステップＳ３８において、指定され
た構造化文書パスからそれに対応する元文書オブジェク
トＯｘ５が見つからなければ（ステップＳ３９でＮ
Ｏ）、付加情報が付加するべき元文書が存在しないため
にエラーとなり、付加情報取得部２２及び結果処理部１
２を介して、クライアント端末に「付加情報取得失敗」
のメッセージを返す（ステップＳ４０）。

【０１２４】ステップＳ３８で取得した元文書オブジェ
クトＯｘ５から、元文書オブジェクトＯｘ５以下のオブ
ジェクトツリーを取得する。取得した元文書オブジェク
トツリーは、文書パーサ部４４にてＸＭＬ文書に変換さ
れる（ステップＳ４１）。例えば、取得した元文書と付
加情報とは統合されて、図１１に示すような情報のＸＭ
Ｌ文書となる。

【０１２５】付加情報取得部２３は、それぞれ取得した
ＸＭＬ文書を、例えばＸＳＬといった所定のスタイルシ
ートとともに、クライアント端末へ返す（ステップＳ４
２）。クライアント端末では、図１１に示したＸＭＬ文
書を、スタイルシートを用いてＨＴＭＬデータに変換し
て、クライアント領域に表示する。

【０１２６】以下、ユーザに対する表示の一例を図１２
を用いて説明する。図１２は、元文書取得処理もしくは
付加情報取得処理を行なった際に、クライアント端末１
０２の表示部１０３に表示される、元文書及び付加情報
の表示形態の一例を示している。

【０１２７】図１２において、Ｆ１は元文書の内容を表
記する表題部分、Ｆ２は元文書の内容の一部分を表示す
る概要部分、Ｆ３は元文書に対する付加情報を編集する
ためのボタン群である。なお、この例では、取得処理が
終了し、該当結果を表示しているものとする。

【０１２８】表題部分Ｆ１には、元文書の表題となる部
分が取り出されて表示されている。これにより、結果と
して、どの要素を取得してきたのかを把握することが可
能である。また、日時情報等、他の元文書と区別が可能
な情報を付記してもよい。

【０１２９】概要部分Ｆ２は、元文書の内容を示す文章
が一定制限下で表示されている。これにより、表題のみ
では不明な情報及び元文書の概略を、把握することが可
能である。この概要部分に表示する要素は任意だが、文
章の形式であり情報量の多い要素を指定することによ
り、ユーザに対して限られた範囲で多くの情報を提供す
ることが可能である。

【０１３０】付加情報編集ボタン群Ｆ３は、元文書に対
する付加情報を構成する要素とボタンが１対１に対応し
ている。ユーザは、編集する付加情報のボタンを押すこ
とによって、付加情報内の任意の要素に対し編集を行な
うことが可能となる。

【０１３１】ボタンを押すことにより、別の画面にその
付加情報が表示される。表示される際には、付加情報を
構成する構造化文書を直接表示するのではなく、ＸＳＬ
等の任意の規則にしたがい、ユーザに対して理解が容易
な形式にて表示される。

【０１３２】また、付加情報の各要素を元にグラフ等の
任意の解析処理を適用した結果を出力することも可能で
ある。各ボタンを押すことにより、別の画面に付加情報
が表示され、表示された付加情報に対し編集を施すこと
も可能である。

【０１３３】そして、編集が終了した際に、情報が更新
されたことを確認し、付加情報を付加情報記憶部５に格
納し、結果を更新するための処理が行なわれる。

【０１３４】なお、図１２に示した表示画面のレイアウ
トは一例であって、これに限られるものではない。ま
た、いくつかの操作例を示したが、これらについても一
例を示したに過ぎず種々の機能を有しても良い。

【０１３５】また、この発明は、上記した実施の形態に
限定されるものではなく、実施段階ではその要旨を逸脱
しない範囲で種々に変形することが可能である。さら
に、上記した実施の形態には、種々の段階の発明が含ま
れており、開示される複数の構成用件における適宜な組
み合わせにより、種々の発明が抽出され得る。

【０１３６】例えば、実施の形態に示される全構成要件
からいくつかの構成要件が削除されても、発明が解決し
ようとする課題の欄で述べた課題（の少なくとも１つ）
が解決でき、発明の効果の欄で述べられている効果（の
なくとも１つ）が得られる場合には、この構成要件が削
除された構成が発明として抽出され得る。

【０１３７】例として、以下の条件下における付加情報
管理システムの適用を記述する。

【０１３８】（バイナリデータに対する適用）アスキー
コードより構成されるテキストデータに相対するデータ
として、バイナリデータが存在する。テキストデータ
は、その特性上、文字単位で内容を分割することが可能
だが、バイナリデータの場合は内部的に分割した場合
に、分割した後の単体では意味を持たないものになる場
合が多いため、バイナリデータを元文書として内部を構
造化し、付加情報を付加することは困難である。

【０１３９】しかしながら、付加情報管理システムを用
いることによって、元データに任意の文書構造を持たせ
た後に、内部でバイナリデータを要素として扱うことに
より構造化文書として扱うことが可能である。

【０１４０】バイナリデータの場合は、内部的に分割し
た場合に、分割した後の単体では意味を持たないものに
なる場合が多いため、要素単位で直接情報を付加するこ
とは困難であるが、任意の規則を適用することにより
（座標、バイト数等）、適用した規則に基づいて付加情
報を関連付けることが可能である。

【０１４１】（ＸＳＬを用いた様々な表記方法）ＸＳＬ
を用いることによって、ＸＭＬ文書を様々な形に変換す
ることが可能である。ＸＳＬはＸＭＬ文書とは独立した
形で存在し、ＸＭＬ文書内部より参照されることによっ
て適用される。

【０１４２】付加情報管理システムを用いるにあたり、
元文書をＸＭＬ文書とし、付加情報をＸＳＬとして適用
することによって、ユーザの選択したＸＭＬ文書を変更
した後に出力することが可能である。

【０１４３】また、付加情報管理システムは、任意の元
文書に対して複数の付加情報を保持することが可能であ
るため、付加情報管理システム上にて管理されるＸＭＬ
文書には、複数のＸＳＬを持たせることが可能となる。
これにより、ユーザが任意のＸＭＬ文書を出力する際
に、複数のＸＳＬから出力形式をユーザの意思により選
択することが可能となる。

【０１４４】（ＤＴＤを用いた文書定義）ＤＴＤ（Docu
ment Type Definition）は、ＸＭＬ文書において持ち得
る要素の形式を定めたものであり、ＤＴＤの存在するＸ
ＭＬ文書は、その定められた形式から逸脱することはで
きない。

【０１４５】ＤＴＤは、ＸＭＬ文書とは独立した形で存
在し、ＸＭＬ文書内部より参照されることによって適用
される。

【０１４６】付加情報管理システムを用いるにあたり、
元文書をＸＭＬ文書とし、付加情報をＤＴＤとして適用
することによって、ＸＭＬ文書に任意のＤＴＤを持たせ
ることが可能となる。

【０１４７】また、付加情報管理システムは任意の元文
書に対して複数の付加情報を保持することが可能である
ために、付加情報管理システム上にて管理されるＸＭＬ
文書には複数のＤＴＤを持たせることが可能となる。こ
れにより、管理者が元文書の変更を行なう際に、複数の
ＤＴＤから任意のＤＴＤを選択して、その定義にしたが
い元文書を編集することが可能となる。

【０１４８】（元文書における要素単位のセキュリティ
情報の付加）付加情報管理システムにて元文書として管
理される文書は構造化文書であり、要素によって構成さ
れている。

【０１４９】そして、元文書に対する付加情報は、元文
書の要素に対して付加することが可能である。付加情報
管理システムにおいて、任意の構造化文書に対し、付加
する情報にセキュリティ情報をもたせることにより、元
文書の要素単位でセキュリティを保持させることが可能
となる。

【０１５０】ユーザが元文書に対して取得要求を出した
際に、付加情報管理システムは指定の元文書に対応する
付加情報を取得し、セキュリティの比較を行なう。そし
て、条件を満たさないユーザに対しては、閲覧不可の旨
のメッセージを送る形式を用いることによって拒否する
ことが可能となる。また、セキュリティ情報は付加情報
であるために、元文書に対して容易に変更することが可
能である。

【０１５１】以上に説明したように、上記した実施の形
態によれば、文書構造記述用言語であるＸＭＬにて構築
されたデータベースに対し、原本であるデータを変更せ
ずに不特定のユーザからの情報追加を行なうことが可能
となる。このため、ユーザは安全性を保持したまま制限
を課されることなく、データベースを使用することが可
能となる。

【０１５２】なお、この発明は上記した実施の形態に限
定されるものではなく、この外その要旨を逸脱しない範
囲で種々変形して実施することができる。

【０１５３】

【発明の効果】以上詳述したようにこの発明によれば、
元情報と付加情報とを別途に管理し、しかも、両者の相
互関係を容易に管理することができ、効率の良い情報の
検索や抽出を行なうことを可能とした極めて良好な付加
情報管理方法及び付加情報管理システムを提供すること
ができる。

【図面の簡単な説明】

【図１】この発明の実施の形態に係る付加情報管理シス
テムを説明するために示すブロック構成図。

【図２】ＸＭＬで記述された構造化文書の一例を説明す
るために示す図。

【図３】図２に示された構造化文書の文書構造を模式的
にツリー表現で説明するために示す図。

【図４】構造化文書データベースに対して、１つの「特
許」情報の文書オブジェクトツリーが追加された状態を
説明するために示す図。

【図５】図２において記述された構造化文書に対し付加
される情報の一例を説明するために示す図。

【図６】図４において記述された文書オブジェクトツリ
ーに対し図５で示された情報が追加された状態を説明す
るために示す図。

【図７】図１に示した付加情報管理システムの一利用形
態を示したもので、ＷＷＷのバックエンドで、付加情報
管理システムが動作している場合を示した図。

【図８】図１に示した付加情報管理システムの付加情報
格納処理について説明するために示すフローチャート。

【図９】図１に示した付加情報管理システムの元文書取
得処理について説明するために示すフローチャート。

【図１０】図１に示した付加情報管理システムの付加情
報取得処理について説明するために示すフローチャー
ト。

【図１１】取得した付加情報と元文書においてクライア
ントに送られるＸＭＬで記述された構造化文書の一例を
説明するために示す図。

【図１２】ユーザインターフェースとしての画面の表示
例を説明するために示す図。

【符号の説明】

１…要求制御部、 ２…アクセス要求処理部、 ３…検索要求処理部、 ４…データアクセス部、 ５…付加情報記憶部、 ６…元文書記憶部、 １１…要求受付部、 １２…結果処理部、 ２１…付加情報格納部、 ２２…付加情報取得部、 ２３…元文書取得部、 ４１…付加情報オブジェクトツリー格納部、 ４２…付加情報オブジェクトツリー取得部、 ４３…元情報オブジェクトツリー取得部、 ４４…文書パーサ部。

フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/21 Ｇ０６Ｆ 17/21 ５７０Ｒ (72)発明者 金輪 拓也 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 野々村 克彦 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 新名 博 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 (72)発明者 磯部 庄三 神奈川県川崎市幸区小向東芝町１番地 株 式会社東芝研究開発センター内 Ｆターム(参考） 5B009 SA03 SA12 SA14 VA09 5B075 ND03 NK02 NK43 NK46 NR06 NR20 PQ02 PQ32

Claims (10)

【特許請求の範囲】
1. 【請求項１】 構造化された元情報と、この元情報に付
   加される付加情報とを、それぞれ、階層化された論理構
   造を持つ別個の構造化データベース上で管理し、各構造
   化データベースの階層化された論理構造を同一にするこ
   とにより、元情報と付加情報との各構造化データベース
   上における位置を対応させることを特徴とする付加情報
   管理方法。
2. 【請求項２】 前記付加情報は、それが付加される前記
   元情報単位で、該元情報と同一の階層化された論理構造
   で管理されることを特徴とする請求項１記載の付加情報
   管理方法。
3. 【請求項３】 前記元情報は、アスキーコードから構成
   されるテキストデータに相当するバイナリデータと称さ
   れるデータであることを特徴とする請求項１記載の付加
   情報管理方法。
4. 【請求項４】 前記付加情報は、それが付加される前記
   元情報を、前記構造化データベースから読み出して出力
   する際の出力形式を選択する情報を含むことを特徴とす
   る請求項１記載の付加情報管理方法。
5. 【請求項５】 前記付加情報は、それが付加される前記
   元情報に変更を行なう際の情報定義方法を選択する情報
   を含むことを特徴とする請求項１記載の付加情報管理方
   法。
6. 【請求項６】 前記付加情報は、それが付加される前記
   元情報に対するセキュリティレベルを示す情報を含むこ
   とを特徴とする請求項１記載の付加情報管理方法。
7. 【請求項７】 前記付加情報で示されるセキュリティレ
   ベルと、予め設定されたセキュリティレベルとを比較す
   ることにより、前記元情報の前記構造化データベースか
   らの読み出しの可否が判断されることを特徴とする請求
   項６記載の付加情報管理方法。
8. 【請求項８】 前記付加情報は、それが付加される前記
   元情報を内容別に管理するために分類する基準となる情
   報を含むことを特徴とする請求項１記載の付加情報管理
   方法。
9. 【請求項９】 前記付加情報は、構造化文書にて形成さ
   れることを特徴とする請求項１記載の付加情報管理方
   法。
10. 【請求項１０】 構造化された元情報を管理する、階層
    化された論理構造を持つ第１の構造化データベースと、 この第１の構造化データベースとは別個に設置され、前
    記元情報に付加される付加情報を管理する、前記第１の
    構造化データベースと同じ階層化された論理構造を持つ
    第２の構造化データベースとを具備し、 前記第１及び第２の構造化データベース上における前記
    元情報と付加情報との位置を対応させたことを特徴とす
    る付加情報管理システム。