JP3914081B2 - Access authority setting method and structured document management system - Google Patents

Description

となる。
【０２４９】
検索要求処理部３は、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す（ステップＳ１０４）。
【０２５０】
クライアント端末では、図１１に示したＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５１】
同様にして、スキーマの検索も行える。
【０２５２】
例えば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「ｓｃｈｅｍａ」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図４７に示すように、領域Ｗ１から「ｒｏｏｔ」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「＃ｓｃｈｅｍａ」を入力する。また、検索条件として、「要素の属性名に「特許」という文字列を含む」「要素の属性名に「要約」という文字列を含む」という内容を予め設定されたデータ入力領域に入力すればよい。
【０２５３】
その後、「検索」ボタンＢ２１を選択することにより、上記検索要求を記述したクエリ（図４８参照）が、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【０２５４】
さて、上記クエリの場合、例えば、「「＃ｓｃｈｅｍａ」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図９に示したような要素名称生起インデックスを用いて、「＃ｓｃｈｅｍａ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」という要素にたどり着いたときは、当該「＃ｓｃｈｅｍａ」を先頭タグにもつ文書オブジェクトツリーＯｔ２１を抽出する。この文書オブジェクトツリーＯｔ２１が上記クエリの内容に適合する文書となる。さらに、図４８に示したクエリの要求内容に従えば、各文書オブジェクトツリーＯｔ２１のトップノードへの構造化文書パスを求める。
【０２５５】
検索要求処理部３は、文書オブジェクトツリーＯｔ２１が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのＸＭＬ文書を作成し、検索結果処理部１２を介して、上記ＸＭＬ文書をスタイルシートとともに、要求元のクライアント端末に返す。
【０２５６】
クライアント端末では、検索結果として受け取ったＸＭＬ文書を、スタイルシートを用いてＨＴＭＬデータに変換して、例えば、図４４に示すように、領域Ｗ１２に表示する。
【０２５７】
クライアント端末では、検索結果の中の１つのスキーマを選択して、表示させると、例えば、図３８に示すような文書の格納／削除を行うための画面とともに、その領域Ｗ３に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【０２５８】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【０２５９】
例えば、図３８の領域Ｗ３に入力した「特許」情報の格納先として、領域Ｗ１で「特許ＤＢ」をマウス等を用いて選択すると、領域Ｗ２に構造化文書パスとして、「ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ」が表示される。その後、「登録」ボタンＢ１を選択すると、「ａｐｐｅｎｄＸＭＬ（“ｕｉｘ：／／ｒｏｏｔ／特許ＤＢ”，“＜特許＞…＜／特許＞”）」なる追加コマンドが構造化文書管理システムへ送信される。
【０２６０】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図２０のステップＳ１０の妥当性チェックでエラーとなることはない。
【０２６１】
同様にして、クエリの検索も行える。クエリを検索して、検索結果として得られた既存のクエリを加工して、再利用することもできる（クエリの再利用）。
【０２６２】
クエリの検索は、前述したような構造化文書の検索と同様にして行われ、その検索範囲は、クエリ群の格納されている構造化データベース上の一部の文書オブジェクトツリーとなる。
【０２６３】
例えば、図１８に示したような状態の構造化文書データベースから、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索する場合について説明する。そのような検索要求を記述したクエリを図４９に示す。
【０２６４】
図４９に示すクエリは、「「ｕｉｘ：／／ｒｏｏｔ／クエリＤＢ」の示す「＃３０１」ノード以下に存在するクエリの中から「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリを検索し、その内容（タグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーの文書）を列挙せよ」を意味するものである。
【０２６５】
なお、「ｋｆ：ａｓ」タグの内容で変数「＄ｅｌｔ」に、「ｋｆ：ｆｒｏｍ」タグに「特許ＤＢ」を含むクエリのタグ名が「ｑｕｅｒｙ」である要素以下の文書オブジェクトツリーが代入される。
【０２６６】
このクエリを検索要求処理部３が処理する際には、前述同様にして、例えば、図９に示したような要素名称生起インデックスを用いて、「ｋｆ：ｆｒｏｍ」という要素にリンクされているノードの（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、「特許」というタグ名にたどり着いたときは、さらに、上流側にアークを辿って「ｑｕｅｒｙ」というタグ名に辿りついたとき、当該「ｑｕｅｒｙ」を先頭タグにもつ文書オブジェクトツリーＯｔ３１を抽出する。この文書オブジェクトツリーＯｔ３１が上記クエリの内容に適合する文書となる。
【０２６７】
複数の文書オブジェクトツリーＯｔ３１が検索されたら、それらを統合して、ＸＭＬ文書を作成して、それをスタイルシートとともにクライアント端末へ返す。
【０２６８】
クライアント端末では、検索結果の中の１つのクエリを選択して、表示させると、例えば、図４４に示した検索画面の領域Ｗ１１に、各データ入力領域にデータの入力された状態で、当該クエリに記述された検索要求の内容が表示される。
【０２６９】
ユーザは、この状態から、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という当該クエリに記述された検索要求中の「文書」を「ＸＭＬ」に変更して、「検索」ボタンＢ２１を選択すれば、「「ｕｉｘ：／／ｒｏｏｔ」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「ＸＭＬ」という文字列を含み、「１９９８」年以降に作成された文書を検索せよ」という意味のクエリが構造化文書管理システムへ送信される。
【０２７０】
以上説明したように、図１の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のＸＭＬ文書群（コンテンツ文書、スキーマ文書、クエリ文書など）を、図１８，図１９に示すように、「ｒｏｏｔ」タグを先頭に持つツリー状の１つの巨大なＸＭＬ文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【０２７１】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【０２７２】
（３）適用例
次に、上記概念検索の特許調査への適用例について説明する。
【０２７３】
図５０は、特許調査における構造化文書データベースの一例であり、「特許」情報の他に、「概念」情報も格納している。
【０２７４】
特許調査において、最も重要となってくる作業は、関連する「特許」情報を収集し、「特許」情報を様々な観点から分析し、特許マップ（図５４参照）を作成することである。特許マップを作成するために、従来、特許マップにおける縦軸、横軸を予め決定し、それに従い、縦軸に並ぶ任意の項目と横軸に並ぶ任意の項目とを検索条件とした検索を逐次行うという方法がとられ、この部分に非常に莫大なコストがかかっていた。しかし、本発明の構造化文書管理システムを用いることで、この部分のコストを大幅に減少させることが可能となる。
【０２７５】
なお、ここで、マップとは、縦軸（ｙ軸）に並ぶ任意の項目と横軸（ｘ軸）に並ぶ任意の項目とを検索条件とした検索結果をｘ軸とｙ軸とを分類軸として分類整理するものである。
【０２７６】
本発明の構造化文書管理システムで、クライアント端末のユーザが図５４に示すような特許マップを作成しようとする場合、ユーザは、クライアント端末上の表示装置に表示される図５０に示すような構造化文書データベースの現在のツリー構造を参照して、図５１に示すような検索画面上に、分析対象の範囲とする「特許」情報のパスと、分析の軸（例えば、ｘ軸、ｙ軸）となる要素を、それぞれ領域Ｗ２１、Ｗ２２に入力する。分析の軸となる要素は、構造化文書データベース内の「特許」情報の要素、「概念」情報の要素のいずれであってもよい。
【０２７７】
例えば、図５１では、ｘ軸に「機能」、ｙ軸に「技術」という「概念」情報の要素を入力している。
【０２７８】
その後、ユーザは、「実行」ボタンＢ３１を選択すると、クライアント端末から図１の構造化文書管理システムへ、図５２に示したようなクエリが送出される。
【０２７９】
この場合のクエリには、「「特許ＤＢ」アークが示すノード以下に格納されている「特許」情報の文書群の中から、「概念ＤＢ」アークが示すノード以下に格納されている、概念「機能」の子要素のいずれかと概念「技術」の子要素のいずれかとを、「キーワード」や「要約」などの要素の値に含む「特許」情報を検索せよ。検索結果として、「機能」の子要素と「技術」の子要素と、それらに対応する「特許」情報の「公開番号」との組を列挙せよ。」という意味の検索要求である。
【０２８０】
概念「機能」には、「検索」「格納」…「分析支援」という子要素があり、概念「技術」には、「実装データベース」「反構造データベース」「自然言語処理」…という子要素があるものとする。
【０２８１】
上記クエリを受けた構造化文書検索システムの検索要求処理部３では、例えば、図１０に示したようなデータ生起インデックスを用いて、概念「機能」の各子要素（文字列）にリンクされているノード（文書オブジェクト）のオブジェクトＩＤを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に遡り、「特許」というタグにたどり着いたときは、さらに、そのノード以下の文書オブジェクトツリーを下流側に辿って概念「技術」の子要素（文字列）のいずれかにリンクされているタグ名にたどり着いたときは、当該文書オブジェクトツリーと、その「公開番号」タグにリンクされている文字列（要素値）を抽出する。このようにして、抽出された「特許」情報のそれぞれについて、対応の「機能」の子要素と「技術」の子要素と「公開番号」との組を統合して、図５３に示すような検索結果としてのＸＭＬ文書を作成、要求元のクライアント端末へ、所定のスタイルシートとともに返す。
【０２８２】
これらを受け取ったクライアント端末の表示装置には、図５４に示したような表形式の特許マップが表示されることになる。
【０２８３】
このように、所望の概念を「軸」として指定するだけで、構造化文書データベースに蓄積された情報を「軸」として指定された概念に基づき集計・分類して、マップ表示することが容易に行える。すなわち、構造化文書データベースに蓄積された情報を、「概念」情報を用いて様々な観点で集計・分類することが容易に行える。
【０２８４】
（アクセス権限の設定）
ここでは、図２に示した利用形態（ＷＷＷのバックエンドで、図１に示した構成の構造化文書管理システム１００が動作する利用形態）の場合を例にとり説明する。すなわち、図２に示すように、複数（ここでは、例えば３つ）のクライアント端末１０２のそれぞれでＷＷＷブラウザ１０３が動作しており、ユーザは、各クライアント端末からＷＷＷサーバ１０１にアクセスすることにより、構造化文書管理システム１００にアクセスすることができる。
【０２８５】
ユーザからの文書格納、文書取得、文書検索などの要求は、ＷＷＷブラウザ１０３から送信されて、ＷＷＷサーバ１０１を通して構造化文書管理システム１００にて受け付けられ、処理された結果は、ＷＷＷサーバ１０１を通して要求元のＷＷＷブラウザ１０３へ返信される。
【０２８６】
クライアント端末装置１０２の要部の構成例を図５５に示す。
【０２８７】
クエリの実行結果としてのＸＭＬ文書は、スタイルシートとともに、構造化文書管理システム１００からクライアント端末装置１０２に送られてくるものとする。以下、図５６、図５７に示すフローチャートを参照して、図５５の各構成部の処理動作について説明する。
【０２８８】
クエリは、前述したように、検索位置、検索条件、情報抽出部分などを記述した、構造化されたＸＭＬ文書である。クエリ文書も本発明の構造化文書管理システムの管理対象である。ここで、構造化文書データベースに対しその論理構造に基づき所望の構成要素を検索するクエリを例にとり説明する。
【０２８９】
ＸＭＬ文書受信部１１１で、構造化文書管理システム１００から送られてきた検索結果文書である表示対象のＸＭＬ文書と、スタイルシートとを受信すると（図５６のステップＳ２０１）、ＸＭＬ／ＨＴＭＬ変換部１１２では、受信したスタイルシートを用いて、受信した表示対象のＸＭＬ文書をＨＴＭＬ文書に変換する（ステップＳ２０２）。その変換処理中、テーブル作成部１１３は、ＨＴＭＬ文書中の記述部分と、その記述部分を生成したスタイルシート中の記述部分との対応関係を示したテーブル、すなわち、対応テーブル１１４を作成する（ステップＳ２０３、ステップＳ２０４）。
【０２９０】
構造化文書管理システム１００から送られてくるスタイルシートの各記述部分には予め識別子ＳＩＤが与えられているものとする。例えば、この識別子ＳＩＤは、コメント文（コメント文でなくとも、ブラウザでは表示されない記述形式の文）として、予めスタイルシートに書き込まれていてもよい。
【０２９１】
テーブル作成部１１３は、まず、ＸＭＬ／ＨＴＭＬ変換部１１２での変換作業中に、得られたＨＴＭＬ文書の各記述部分のそれぞれに識別子ＨＩＤを与える。そして、ＨＴＭＬ文書中の記述部分と、その記述部分を生成したスタイルシート中の記述部分との対応関係をＳＩＤとＨＩＤを用いて表した対応テーブル１１４を作成する。
【０２９２】
描画部１１５では、ＸＭＬ／ＨＴＭＬ変換部１１２で生成されたＨＴＭＬ文書を基に表示データを作成し、その表示データは、ディスプレイ装置１２１に表示される（ステップＳ２０５）。その際、描画部１１５は、ＨＴＭＬ文書中の記述部分とその記述部分に与えられた識別子ＨＩＤとの対応を記憶しておいてもよい。
【０２９３】
アクセス権限の設定は、ディスプレイ装置１２１の表示画面を基に行う。
【０２９４】
例えば、ユーザがアクセス権限の設定開始の所定の指示操作を入力部１１６で行うと、アクセス権限設定部１１７が起動される。まず、表示画面上でアクセス権限を設定する領域の選択が行われる（ステップＳ１１１）。すなわち、マウス等の入力装置１２２を用いて、表示対象の文書が表示されたディスプレイ装置１２１の表示画面上で、アクセス権限を設定したい文字列（テキスト）や画像などの表示領域の選択を行う。
【０２９５】
アクセス権限を設定したい表示領域がマウス等で選択されれば、描画部１１５でその指定された領域に文字列や画像などを表示するＨＴＭＬ文書中の記述部分を検知することができる。この検知されたＨＴＭＬ文書中の記述部分に対応する識別子ＨＩＤがアクセス権限設定部１１６に渡される（ステップＳ１１２）。
【０２９６】
アクセス権限設定部１１６は、描画部１１５で検知されたＨＴＭＬ文書中の記述部分の識別子ＨＩＤから、対応テーブル１１４を参照して、当該識別子ＨＩＤに対応するスタイルシートの記述部分の識別子ＳＩＤを得る（ステップＳ１１３）。
【０２９７】
さらに、クライアント端末装置１０２のアクセス権限設定部１１７では、アクセス権限の設定されるユーザの範囲や、アクセスレベルや、アクセスタイプなどをユーザに入力してもらうための入力画面を表示して、アクセス権限の設定のために必要な上記各情報を収集する（ステップＳ１１４〜ステップＳ１１６）。上記各情報の入力が終了すると、それらは、識別子ＳＩＤとともに、送信部１１８を介して構造化文書管理システム１００へ送信される（ステップＳ１１７）。
【０２９８】
なお、図５５に示した構成部のうち、テーブル作成部１１３，対応テーブル１１４，アクセス権限設定部１１６以外は、ほぼ従来技術に属するものである。
【０２９９】
次に、図１のアクセス権限設定管理部２０１について、図５８を参照して説明する。図５８は、アクセス権限設定管理部２０１の機能ブロック図である。
【０３００】
アクセス権限設定管理部２０１は、アクセス権限設定部２０２とアクセス権限管理部２０１とから構成され、アクセス権限設定管理部２０１は、スキーマアクセス権限管理部２１１と、データアクセス権限管理部２１２と、クエリアクセス権限管理部２１３と、スタイルアクセス権限管理部２１４と、パスアクセス権限管理部２１５とから構成されている。
【０３０１】
アクセス権限設定部２０２は、クライアント端末装置１０２から送信されてきた、上記ＳＩＤや、アクセス権限の設定されるユーザの範囲や、アクセスレベルや、アクセスタイプなどの情報を基に、実際に、アクセス権限の設定を行うようになっている。
【０３０２】
アクセス権限管理部２０１では、上記アクセス権限設定部２０２で設定された、各レベル（スキーマ、データ、クエリ、スタイル、パス）のアクセス権限の管理を行うためのものである。
【０３０３】
図５９は、構造化文書データベースの論理構造の一部を模式的に示したものである。構造化文書データベースに新たにＸＭＬ文書を登録していくと、それら各ＸＭＬ文書は、「ｒｏｏｔ」という１つの大きなＸＭＬ文書の部分文書として参照できる構成になっている。図５９に示した構造化文書データベースでは、ＸＭＬ文書としての「報告書」情報は、「報告書ＤＢ」ノード以下に格納され、同じくＸＭＬ文書としての「従業員」情報は、「従業員ＤＢ」ノード以下に格納され、同じくＸＭＬ文書としての「特許」情報は、「特許ＤＢ」ノード以下に格納されている。
【０３０４】
図６０は、ＸＭＬで記述された構造化文書の一例として、「報告書ＤＢ」ノード以下の上記「報告書」情報に対応する１つの部分文書を示したものであり、図６１は、「従業員ＤＢ」ノード以下の上記「従業員」情報に対応する３つの部分文書を示したものである。
【０３０５】
図６２は、クライアント端末装置１０２のディスプレイ装置１２１の画面表示例を示したもので、クライアント端末装置１０２から入力されたクエリを実行した結果得られたＸＭＬ文書（検索結果文書）の表示例を示している。
【０３０６】
前述したように、クエリの「ｋｆ：ｆｒｏｍ」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「ｋｆ：ｗｈｅｒｅ」タグから始める要素には、変数に関する条件づけの記述があり、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素には、検索結果の出力形式が記述される。クエリを実行することより、単純検索の場合には、クエリ中に指定された検索条件を満たす情報を検索・抽出し、概念検索の場合には、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出する。そして、検索要求処理部３では、抽出された情報（構成要素）を、「ｋｆ：ｓｅｌｅｃｔ」タグから始まる要素の記述に従った形式の情報に合成・加工し、その結果得られたＸＭＬ文書を結果処理部１２を介して、要求元のクライアント端末装置１０２に所定のスタイルシートとともに送信する。要求元のクライアント端末装置１０２では、構造化文書管理システム１００から送られてきたクエリの実行結果としてのＸＭＬ文書（検索結果文書）を図５６のフローチャートに従って、図６２に示すように表示する。なお、検索結果文書は、クエリ中の検索条件の記述によっては、上記のように、構造化文書データベース中の複数の構造化文書から生成された加工された文書である場合も、構造化文書データベース中の構造化文書そのものである場合もあり得る。
【０３０７】
この状態において、クライアント端末装置１０２では、アクセス権限の設定が行える。
【０３０８】
クライアント端末装置１０２上でのアクセス権限の設定を行うための操作手順の概略を説明する。
【０３０９】
（ａ）表示画面からアクセス権限の設定を行いたい文字列や画像などの表示されている領域を指定（選択）する。ここで、指定される文字列や画像などは、構造化文書データベース中のＸＭＬ文書を構成する要素の要素名や要素値に対応するものである。
【０３１０】
（ｂ）アクセス権限を設定するユーザの範囲を指定（選択）する。アクセス権限は、ユーザ１人１人に対し設定することも、複数のユーザからなる特定のグループ単位に（例えば、会社組織上の所属部署単位に）設定することも可能であるとする。前者を個人に対するアクセス権限の設定と呼び、後者をグループに対するアクセス権限の設定と呼ぶ。
【０３１１】
（ｃ）アクセスレベルを指定（選択）する。アクセスレベルには、ここでは、スタイル、クエリ、データ、スキーマ、パスがある。スタイルレベルは、スタイルシート毎にアクセス権限を設定するもので、表示形式が異なれば、同じ構成要素であっても表示されたりされなかったりすることがあり得る。また、クエリレベルは、クエリ文書毎にアクセス権限を設定するもので、クエリレベルでアクセス権限を設定すると、このレベルでアクセスが制限されたユーザに対しては、同じ構成要素であっても、その構成要素を得るために用いたクエリに応じて（すなわち、当該構成要素の用途が異なれば）、表示されたりされなかったりすることがあり得る。また、データレベルは、構造化文書データベースに格納されている検索対象のＸＭＬ文書中の構成要素に対しアクセス権限を設定するもので、このレベルでアクセスが制限されたユーザからは、その構成要素に対しては、たとえ、クエリやスタイルが異なっても、アクセス不可能である（見ることはできない）。さらに、スキーマレベル、パスレベルは、構造化文書データベース中の同じ文書構造を持つ構造化文書中の同じ要素名の構成要素に対しアクセス権限を設定するもので、このレベルでアクセスが制限されたユーザからは、そのような構成要素に対しては、たとえ、クエリやスタイルが異なっても、アクセス不可能である（見ることはできない）。
【０３１２】
（ｄ）上記（ａ）で指定した領域に表示されるデータの表示方法（ここでは、アクセス態様あるいはアクセスタイプと呼ぶ）を指定（選択）する。アクセスタイプとして、大きく分けると、その表示領域に何も表示しなかったり、黒く塗り潰して表示したりと、そこに表示されているデータがあるのかないのかもわからないようにする非表示にする場合と、特殊な表示を行う場合（特殊表示）とが設定可能である。特殊表示とは、その表示領域には、何らかのデータが表示されているが、それが何であるかが判別できないように表示を行うもので、例えば、上記（ａ）で指定した領域に表示される文字列や画像などを伏せ字で表示したり、モザイクをかけて表示したりすることである。伏せ字で表示するのか、モザイクなどをかけて表示するのかなどは選択可能であり、また、伏せ字を選択した場合は、どのような伏せ字を用いるかも（例えば「○」「×」など）選択可能である。
【０３１３】
さて、図６２に示すように、クライアント端末装置１０２の表示画面には、上記のようにして、表示対象のＸＭＬ文書が表示されている。すなわち、「報告書」情報の構成要素である「報告番号」、「タイトル」、「報告者」、「報告日」、「要約」、「代表図」と、本文へのリンクが表示され、さらに、「従業員」情報の構成要素である「報告者プロフィール」などの情報が表示されている。このように、ここで表示されているＸＭＬ文書は、構造化文書データベースに格納されている検索対象の複数のＸＭＬ文書のそれぞれに含まれる構成要素を合成したものである。
【０３１４】
表示画面に表示されているデータは、あくまでも表示データであって（例えば、上記の例の場合、複数のＸＭＬ文書から抽出された構成要素を合成したもの）、構造化文書データベースには、表示画面通りの構造のＸＭＬ文書が存在しているわけではない。そこで、構造化文書管理システム１００のアクセス権限設定管理部２０１では、ユーザにより、アクセスレベルとして、例えば、「データ」が指定されたときには、表示形式を基に逆に遡り構造化文書データベース中の元のデータを特定し、アクセス権限の設定を行うようになっている。
【０３１５】
では、実際に、図６２の表示からアクセス権限を設定する方法について述べる。図６２の表示は、構造化文書データベース中の複数のＸＭＬ文書の構成要素をクエリにより合成した（加工した）結果得られたＸＭＬ文書を、スタイルシートを通して、ＨＴＭＬ形式に変換したものをブラウザで表示したものである。表示対象のＸＭＬ文書を図６３に示す。また、適用しているスタイルシートを図６４に示す。
【０３１６】
図６３に示したＸＭＬ文書をＨＴＭＬ文書に変換する際には、前述したように、ＨＴＭＬ文書の各記述部分（例えば、表示対象の文字列などを所定のタグで囲んだもの）のそれぞれに識別子ＨＩＤが与えられるが、図６５に、その様子を示す。図６５には、ＨＴＭＬ文書そのものではなく、説明の簡単のため、ＨＴＭＬ文書中のどのような記述部分にどのような識別子ＨＩＤが与えられたかを、そのＨＴＭＬ文書を表示した図６２と同じ表示画面上で示したものであって、各記述部分に対し識別子ＨＩＤ（ここでは、例えば、ＨＩＤ１〜ＨＩＤ１８）を符号として示している。ここでは、識別子ＨＩＤの与えられたＨＴＭＬ文書中の１つの記述部分は、１つの表示領域に対応する。すなわち、図６５に示すように、１つの表示窓（テキストボックス）に対し１つの記述部分が対応し、ＨＩＤが与えられているものとする。
【０３１７】
クライアント端末装置１０２のＸＭＬ／ＨＴＭＬ変換部１１２では、図５６のステップＳ１０２において、図６３に示したＸＭＬ文書に、図６４に示したスタイルシートを適用して、図６５に示したように表示されるＨＴＭＬ文書を作成するようになっている。その際、図５６のステップＳ２０３に示したように、テーブル作成部１１３は、図６６に示すような対応テーブル１１４を作成する。
【０３１８】
例えば、図６５において、識別子「ＨＩＤ６」の与えられているＨＴＭＬ文書中の記述部分は、「報告者」という文字列を表示領域３０６（図６２参照）に表示するものであって、識別子「ＨＩＤ７」の与えられているＨＴＭＬ文書中の記述部分は、「山田太郎」という文字列を表示領域３０７（図６２参照）に表示するものである。この２つの記述部分は、図６４に示したスタイルシートの識別子「ＳＩＤ４」の与えられている記述部分の記述に従って図６３のＸＭＬ文書の６行目に記述されている要素から生成されたものである。従って、クライアント端末装置１０２のテーブル作成部１１３は、図６６に示したように、ＨＩＤ６，ＨＩＤ７には、それぞれＳＩＤ４が対応付けられている。なお、図６６の対応テーブルでは、ＨＩＤのそれぞれに対し、「ｔｙｐｅ」という項目によって、その要素は、変換前のＸＭＬ文書中では、要素名であったものか、要素値であったものかを区別している。
【０３１９】
図８８は、図６５に示した表示画面に対応するＨＴＭＬ文書の一部を示したものである。例えば、図６５に示した、識別子「ＨＩＤ１」「ＨＩＤ２」「ＨＩＤ３」「ＨＩＤ６」「ＨＩＤ７」の与えらた記述部分の一例を示している。これら記述部分には、それらの符号として識別子「ＨＩＤ１」「ＨＩＤ２」「ＨＩＤ３」「ＨＩＤ６」「ＨＩＤ７」を示している。
【０３２０】
例えば、表示領域３０７に「山田太郎」という文字列を表示するための、図８８に示したＨＴＭＬ文書の記述部分（識別子「ＨＩＤ７」の与えられている記述部分）のように、「報告書」「報告番号」「報告者」などの項目名（要素名である場合もある）以外のＸＭＬ文書の要素値が表示される表示領域（例えば、表示領域３０７など）に対応する記述部分には、そのような記述部分がマウス等により指示（選択）されたとき、描画部１１５に、当該表示領域が指示された旨を通知するためのイベント関数「ｆｕｎｃ（）」が埋め込まれているものとする。
【０３２１】
このような関数の埋め込みは、図６４に示したスタイルシートにて指示することができる。すなわち、例えば、識別子「ＨＩＤ７」の与えられているＨＴＭＬ文書の記述部分に上記関数を埋め込むための指示は、図６４に示したスタイルシートの記述部分４０１には記述されている。
【０３２２】
このように、公知のスタイルシートを用いることにより、表示対象のＸＭＬ文書をＨＴＭＬ文書に変換する際に、識別子ＨＩＤの与えられたＨＴＭＬ文書中の１つの記述部分に、１つの表示領域を対応させ、その表示領域がマウス等で指示されたとき、描画部１１５に、当該表示領域が指示（選択）された旨を通知するためのイベント関数「ｆｕｎｃ（）」を埋め込むことができる。
【０３２３】
描画部１１５は、イベント関数により、ユーザにより指示（選択）された表示領域がどれであるか、また、その表示領域のＨＩＤは何であるかを検知することができる。
【０３２４】
さて、図６２に示したような表示が行われている状態で、ユーザが、アクセス権限の設定開始の所定の指示操作を入力部１１６を介して行うと、アクセス権限設定部１１７が起動される。まず、図５７のステップＳ１１１に示したように、アクセス権限を設定する領域の選択を行う。
【０３２５】
例えば、図６２の表示画面上の、「山田太郎」という文字列の表示されている、その文字列を表示するために予め定められた表示領域（テキストボックス）３０７が、マウス等を用いて選択されたとする。この選択されたテキストボックスを表示するためのＨＴＭＬ文書中の記述部分の識別子は、「ＨＩＤ７」である。描画部１１５は、これを検知すると、当該識別子「ＨＩＤ７」をアクセス権限設定部１１６へ渡す（図５７のステップＳ１１２）。
【０３２６】
アクセス権限設定部１１６は、対応テーブル１１４を参照して、「ＨＩＤ７」に対応するスタイルシート中の記述部分の識別子を取得する（図５７のステップＳ１１３）。この場合、図６６から「ＳＩＤ４」が得られる。
【０３２７】
次に、アクセス権限を設定するユーザの範囲の選択を行う（図５７のステップＳ１１４）が、その際、アクセス権限設定部１１６は、図６７に示したようなウインドウを表示してもよい。このウインドウ上で、ユーザは、個人あるいはグループを選択し、個人を選択した場合には、さらに、その個人を特定するユーザ名を選択すればよい。ここでは、ユーザの範囲として、例えば「山田太郎」という個人が選択されたとする。
【０３２８】
次に、アクセスレベルの選択を行う（図５７のステップＳ１１５）が、その際、アクセス権限設定部１１６は、図６８に示したようなウインドウを表示してもよい。このウインドウ上で、ユーザは、スタイル、クエリ、データ、スキーマ、パスのいずれかを選択すればよい。
【０３２９】
さらにアクセスタイプの選択を行う（図５７のステップＳ１１６）が、その際、アクセス権限設定部１１６は、図６９に示したようなウインドウを表示してもよい。このウインドウ上で、ユーザは、「非表示」か「特殊表示」のいずれかを選択すればよい。「特殊表示」を選択した場合には、さらに、伏せ字、モザイクのうちのいずれかを選択すればよい。
【０３３０】
最後に、ユーザによりアクセス権限設定完了を指示する所定の操作が行われると、上記のようにして収集された情報は、アクセス権限設定要求とともに、クライアント端末装置１０２から、構造化文書管理システムへ送信される（図５７のステップＳ１１７）。構造化文書管理システムでは、要求制御部１で上記アクセス権限設定要求を受け取ると、それをアクセス権限設定管理部２０１に出力する。
【０３３１】
アクセス権限設定要求には、例えば、クライアント端末装置１０２でアクセス権限の設定対象となった（表示対象の）ＸＭＬ文書、そのＸＭＬ文書を画面表示する際に用いたスタイルシート、さらに、そのＸＭＬ文書を得るために用いたクエリを特定するための情報が含まれていることが望ましい。
【０３３２】
次に、図７０〜図７１に示すフローチャートを参照して、アクセス権限設定管理部２０１の処理動作について説明する。
【０３３３】
アクセス権限設定管理部２０１に、アクセス権限設定要求とともに、クライアント端末装置１０２から送られてきた、ＳＩＤ、ユーザの範囲、アクセスレベル、アクセスタイプが入力されると（ステップＳ１２１）、まず、アクセス権限設定要求を基に、そのアクセス権限設定要求にて特定しているスタイルシート中の当該ＳＩＤ対応の記述部分に関連付けられた、表示対象のＸＭＬ文書中の要素のパスを取得する（ステップＳ１２２）。例えば、図５７のステップＳ１１１において、識別子「ＨＩＤ７」の付されたＨＴＭＬ文書中の記述部分に対応する表示領域が選択されて、識別子「ＨＩＤ７」に対応する図６４に示したスタイルシート中の記述部分の識別子「ＳＩＤ４」が、図７０のステップＳ１２１で入力したとする。このとき、図６４に示したスタイルシート中の識別子「ＳＩＤ４」の付された記述部分は、「＜ｘｓｌ：ｖａｌｕｅ−ｏｆ ｓｅｌｅｃｔ＝“／報告者／名前”／＞」である。この記述部分において、「“／報告者／名前”／」は、表示対象のＸＭＬ文書（検索結果文書）中の当該要素のパスの一部を表したものである。また、当該スタイルシートを「ＳＩＤ４」の付された記述部分から上の行に辿っていくと、「ＳＩＤ１」の付された記述部分には、「“／報告者／名前”／」の上流のパスとして、「”／報告書リスト／報告書／“」が記述されている。従って、当該スタイルシートの「ＳＩＤ４」対応の記述部分に関連付けられた、表示対象のＸＭＬ文書中の当該要素の全体としてのパスは「”／報告書リスト／報告書／報告者／名前”」であることがわかる。また、上記例の場合、識別子「ＨＩＤ７」の付されたＨＴＭＬ文書中の記述部分に対応する表示領域には、「山田太郎」が表示されていた。従って、「”／報告書リスト／報告書／報告者／名前”」というパスにて特定される要素であって、その要素値が「山田太郎」である要素が、検索結果文書中のアクセス権限を設定する箇所（構成要素）である。これをもとに、以後、指定されたアクセスレベルに応じて、構造化文書データベースを探索していく。
【０３３４】
アクセスレベルがスタイルと指定されていた場合（ステップＳ１２３）、アクセス権限設定部２０２は、アクセス権限設定管理部２０３のスタイルアクセス権限管理部２１４に格納されている、図７２に示すようなスタイルアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１２４）。スタイルアクセス権限テーブルは、図７２に示すように、複数種類あるスタイルシートのうちのどれであるかを識別するためのスタイルシートの識別子毎に、そのスタイルシート中のアクセス権限の設定された記述部分を示すＳＩＤとユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、アクセス権限を設定しようとしているスタイルシートの識別子が「ＳＳＩＤ１」であるとすると、スタイルシート中の識別子「ＳＩＤ４」の付された記述部分に対し、ユーザ範囲として「グループＢ」というグループに、アクセスタイプとして「非表示」がアクセス権限として設定されたことになる。
【０３３５】
アクセスレベルがスタイルでないときは、次に、ステップＳ１２５へ進む。
【０３３６】
上記ステップＳ１２２において、表示対象のＸＭＬ文書（検索結果文書）中の「”／報告書リスト／報告書／報告者／名前”」というパスで特定され、しかも要素値が「山田太郎」である要素が取得された。すなわち、これは、図６３に示した表示対象のＸＭＬ文書中において、第６行目に記述されている要素が特定されたことになる（ステップＳ１２５）。
【０３３７】
図６３に示したＸＭＬ文書は、図７７に示すようなクエリを実行することにより得られたＸＭＬ文書である。なお、図７７に示したクエリの識別子を「ＱＲＹ１」であるとする。そこで、このクエリを基に、構造化文書データベース中のリソースを検索する。
【０３３８】
次に、クエリを解析して、当該クエリから上記ステップＳ１２５で得た要素のパスに対応する記述部分を取得する（ステップＳ１２６）。例えば、図７７に示したクエリと、このクエリを実行することにより得られた図６３に示したＸＭＬ文書とを参照して、クエリの解析方法について説明する。なお、構造化文書データベースに格納されている全てのクエリの各記述部分には予め識別子ＱＩＤが与えられているものとする。
【０３３９】
まず、図６３の６行目に記述されている要素「＜名前＞山田太郎＜／名前＞」の当該ＸＭＬ文書中でのパスは、「報告書／報告者／名前」であることがわかっているので、クエリにおいて、この要素を作り出している部分に着目する。これはクエリの出力形式の記述部、すなわち、＜ｋｆ：ｓｅｌｅｃｔ＞タグで囲まれた記述部を調べることでわかる。この場合、図７７において、当該＜ｋｆ：ｓｅｌｅｃｔ＞タグで囲まれた記述部で定めた記述形式（文書構造）から、先ほどの「＜名前＞山田太郎＜／名前＞」という要素を作り出した記述部分は、識別子「ＱＩＤ５」の付された「＜名前＞＄ｎａｍｅ＜／名前＞」であることが容易に判別できる。
【０３４０】
アクセスレベルがクエリと指定されていた場合（ステップＳ１２７）、アクセス権限設定部２０２は、アクセス権限設定管理部２０３のクエリアクセス権限管理部２１３に格納されている、図７３に示すようなクエリアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１２８）。クエリアクセス権限テーブルは、図７３に示すように、複数種類あるクエリのうちのどれであるかを識別するためのクエリの識別子毎に、そのクエリ中のアクセス権限の設定された記述部分を示すＱＩＤとユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、上記例の場合、アクセス権限を設定しようとしているクエリの識別子が「ＱＲＹ１」であるとすると、当該クエリ中の識別子「ＱＩＤ５」の付された記述部分に対し、ユーザ範囲として「グループＢ」というグループに、アクセスタイプとして「非表示」がアクセス権限として設定されたことになる。
【０３４１】
さて、次に、当該クエリの記述に基づき、構造化文書データベース中から、ステップＳ１２５で得られた要素、すなわち、「＜名前＞山田太郎＜／名前＞」の格納されている箇所（パス）を探索する（ステップＳ１２９）。ここでは、まず、当該クエリ中の＜ｋｆ：ｆｒｏｍ＞タグで囲まれた記述部から、変数「＄ｎａｍｅ」が要素の値として関連付けられている記述部分を探索する。この場合、１６行目と２２行目の記述部分において、変数「＄ｎａｍｅ」が要素「報告者」「名前」のそれぞれの要素値に関連付けられている。すなわち、「ＱＩＤ５」の付された記述部分「＜名前＞＄ｎａｍｅ＜／名前＞」は、＜ｋｆ：ｆｒｏｍ＞タグで囲まれた記述部において、「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下にある「＜報告者＞＄ｎａｍｅ＜／報告者＞」および「”ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ”」以下にある「＜名前＞＄ｎａｍｅ＜／名前＞」を出力結果として出力するための記述であることがわかる。また、変数「＄ｎａｍｅ」はテキストであり、「山田太郎」が指定されているので、これを条件として更にデータベース中のパスを検索する。
【０３４２】
そこで、アクセス権限設定部２０２は、図７８に示すような、構造化文書データベースの「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下から、「山田太郎」という値を持つ「報告者」という構成要素のパスを検索するためのクエリと、図７９に示すような、構造化文書データベースの「”ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ”」以下から、「山田太郎」という値を持つ「名前」という要素名の構成要素へのパスを検索するためのクエリとを生成して（発行して）、それを検索要求処理部３へ送る。
【０３４３】
なお、上記例の場合、図６５の表示画面上の、ＨＩＤ７の「山田太郎」という文字列の表示されているテキストボックスがアクセス権限を設定する領域として指定されたので、これに対応するように、図７８，図７９に示したクエリでは要素値「山田太郎」をもつ構成要素を検索条件としているが、もし、ＨＩＤ６の「報告者」という文字列の表示されているテキストボックスが指定されているのであれば、要素値「山田太郎」をもつ構成要素を検索条件とする必要がない。すなわち、＜ｋｆ：ｗｈｅｒｅ＞タグで囲まれた記述部は必要ない。
【０３４４】
検索要求処理部３では、前述したようにして、各クエリに記述された検索条件に基づき、構造化文書データベースを検索する。すると、図８０に示すように、「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下にある「山田太郎」という値を持つ「報告者」という要素名の構成要素３０１へのパスと、「”ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ”」以下から、「山田太郎」という値を持つ「名前」という要素名の構成要素３０２へのパスを取得することができる。
【０３４５】
例えば、構成要素３０１のパスが、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」であり、構成要素３０２のパスが、「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」であるとする。パスは必ずしも１つだけ検索されるのでなく、場合によっては複数検索される場合がある。
【０３４６】
アクセスレベルがデータと指定されていた場合（図７１のステップＳ１３１）、アクセス権限設定部２０２は、アクセス権限設定管理部２０３のデータアクセス権限管理部２１２に格納されている、図７４に示すようなデータアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１３２）。データアクセス権限テーブルは、図７４に示すように、ステップＳ１３０で取得したパスとユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、上記例の場合、アクセス権限を設定しようとしているパスが「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」であり、このパスにより表された格納エリアに格納されている要素（要素値が「山田太郎」で要素名「報告者」の構成要素）に対し、ユーザ範囲として「グループＢ」というグループに、アクセスタイプとして「伏せ字（○）」がアクセス権限として設定されたことになる。
【０３４７】
一方、アクセスレベルがスキーマと指定されていた場合（ステップＳ１３３）、ステップＳ１３４へ進み、ステップＳ１３０で取得したパスにスキーマが設定されているかをチェックする。例えば、ステップＳ１３０で、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスを取得したとき、このパスにて特定される「報告者」という構成要素（ノード）３０１に、スキーマが存在する旨の属性値がセットされているときは（ステップＳ１３４）、当該スキーマ文書の「報告者」という構成要素に対応する記述部分に対し、アクセス権限を設定する。すなわち、アクセス権限設定部２０２は、アクセス権限設定管理部２０３のスキーマ権限管理部２１１に格納されている、図７５に示すようなスキーマアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１３５）。
【０３４８】
例えば、上記の例の場合、「報告者」という構成要素（ノード）３０１を含む、「報告書ＤＢ」ノード以下に、図８１に示すスキーマ文書が格納されているとする。図８１に示すスキーマ文書において、構成要素３０１に対応する記述部分は、実線で囲まれた部分である。構造化文書データベース中で、この記述部分を特定するパスは、例えば、「ｕｉｘ：／／ｒｏｏｔ／ｓｃｈｅｍａ／ｅｌｅｍｅｎｔＴｙｐｅ［４］／ｎａｍｅ」であるとする。この場合、スキーマアクセス権限テーブルには、図７５に示すように、スキーマ文書の「報告者」という構成要素に対応する記述部分を特定するパス、すなわち、「ｕｉｘ：／／ｒｏｏｔ／ｓｃｈｅｍａ／ｅｌｅｍｅｎｔＴｙｐｅ［４］／ｎａｍｅ」とユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、上記例の場合、アクセス権限を設定しようとしているスキーマ文書の記述部分（構成要素）のパスは「ｕｉｘ：／／ｒｏｏｔ／ｓｃｈｅｍａ／ｅｌｅｍｅｎｔＴｙｐｅ［４］／ｎａｍｅ」であり、このパスにより特定された記述部分に対し、ユーザ範囲として「グループＡ」というグループに、アクセスタイプとして「モザイク」がアクセス権限として設定されたことになる。
【０３４９】
このように、スキーマにアクセス権限を設定することにより、以後、このスキーマの設定された構造化文書データベース中の格納領域（例えば、上記例の場合、「報告書ＤＢ」ノード以下の格納領域）に格納された、このスキーマが適用される全ての構造化文書に対して、スキーマアクセス権限テーブルに登録されたのと同一のアクセス権限が適用される。
【０３５０】
さて、アクセスレベルがパスに対しても設定可能である。例えば、図８２に示すように、「報告書ＤＢ」ノード以下には、複数の「報告書」情報（構造化文書）が格納されている。この複数の「報告書」情報のそれぞれは、「報告者」という要素名の構成要素（ノード）を持つ。そこで、この複数の「報告書」情報中の１つに含まれる「報告者」ノードが図７０のステップＳ１３０で特定されたとき、他の全ての「報告書」情報中の「報告者」ノードについても、アクセス権限を設定することも可能である。アクセスレベルがパスと指定されたときは、この他の全ての「報告書」情報中の「報告者」ノードに対し、同一のアクセス権限を設定する。この効果は、「報告書ＤＢ」ノード以下にスキーマが設定されている場合に、スキーマに対しアクセス権限を設定する場合（図７１のステップＳ１３５）と同じである。従って、ステップＳ１３３でアクセスレベルがスキーマと設定されている場合に、ステップＳ１３４で、当該スキーマが存在しないときは、ステップＳ１３７へ進むようにしてもよい。また、図７１には示していないが、ステップＳ１３６でアクセスレベルがパスと設定されている場合に、例えば、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスにて特定される「報告者」という構成要素（ノード）３０１にスキーマが設定されているときは、ステップＳ１３５に進みようにしてもよい。
【０３５１】
アクセスレベルがパスと指定されていた場合（ステップＳ１３６）、ステップＳ１３７へ進み、アクセス権限設定部２０２は、構造化文書データベースの「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下から、「報告者」という構成要素のパスを検索するためのクエリ生成して（発行して）、それを検索要求処理部３へ送る。
【０３５２】
検索要求処理部３では、前述したようにして、クエリに記述された検索条件に基づき、構造化文書データベースを検索する。すると、「”ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ”」以下にある全ての「報告者」という要素名の構成要素へのパスを取得することができる。このときのクエリ中の要素値を検索条件とする「記述はない。
【０３５３】
アクセス権限設定部２０２は、アクセス権限設定管理部２０３のパスアクセス権限管理部２１５に格納されている、図７６に示すようなパスアクセス権限テーブルに、指定されたアクセス権限を登録する（ステップＳ１３８）。パスアクセス権限テーブルは、図７６に示すように、ステップＳ１３７で取得したパスとユーザ範囲とアクセスタイプとが登録されるようになっている。例えば、上記例の場合、アクセス権限を設定しようとしているパスが「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［１］／報告者」、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［２］／報告者」、…であり、これらパスにより特定された格納エリアに格納されている要素（要素名「報告者」の構成要素）に対し、ユーザ範囲として「グループＢ」というグループに、アクセスタイプとして「伏せ字（○）」がアクセス権限として設定されたことになる。
【０３５４】
このように、上記実施形態では、構造化文書データベースを検索した結果得られた表示対象のＸＭＬ文書（検索結果文書）は、クライアント端末装置１０２で所定のスタイルシート（検索結果文書を所定の表示形式で表示するために用いた検索結果文書の文書構造の変換規則）を適用してＨＴＭＬ文書に変換された後、表示画面上に表示される。変換の際には、ＨＴＭＬ文書の１つの記述部分を１つの表示領域（テキストボックス）で表示するようなスタイルシートをＸＭＬ文書に適用する。この表示画面上で、所望の表示領域（テキストボックス）を指定することにより、クライアント端末装置１０２の描画部１１５は、（ａ）このテキストボックスに表示されているＨＴＭＬ文書の記述部分を特定することができるので、さらに、クライアント端末装置１０２のアクセス権限設定部１１６は、対応テーブル１１４を参照して、当該ＨＴＭＬ文書の記述部分に対応するスタイルシート中の記述部分を特定する。次に、（ｂ）スタイルシート中の当該記述部分に関連付けられた検索結果文書中の要素のパスを特定した後、（ｃ）当該検索結果文書を得るために用いたクエリ中の出力形式の記述部から当該パスに対応する記述部分を特定する。そして、（ｄ）構造化文書データベースにアクセスして（クエリを発行して）、当該記述部分に関連付けられた構造化文書データベース中の要素のパス（パスリスト）を取得する。以上のように、ユーザにより所望の表示領域が指定されると、ユーザにより指定されたレベルに応じて、該指定された表示領域に対応するスタイルシートの記述部分、さらに、それに対応するクエリ中の記述部分、さらにそれに関連付けられた構造化文書データベース中の要素を順次特定していくことにより、指定されたレベルにアクセス権限を設定することが容易に行える。ユーザは、検索結果の表示画面上で、少なくとも所望の表示領域と、アクセスレベルを指定するだけで、構造化文書データベース中の構成要素にアクセス権限の設定が行える。さらに、スタイルシートの記述部分、クエリ中の記述部分、当該要素を含む構造化文書と同じ文書構造を持つ他の構造化文書中の当該要素と同じ要素名の要素に対しても、それ対応のレベルを指定するだけでアクセス権限を設定することができるので、各種アプリケーションに柔軟に対処できる。
【０３５５】
なお、上記アクセス権限の設定は、１つの表示領域を選択して、その表示領域に対応する、スタイルシート、クエリ、構造化文書データベース中の要素（データ）、スキーマ、パスのうちの１つレベルにアクセス権限を設定する場合について説明したが、一度に複数の表示領域を選択して、それらに対応する上記複数のレベルのうちの１つのレベルに一括して（ユーザ範囲、アクセスタイプを同じくした）アクセス権限を設定することも上記同様にして容易に行える。
【０３５６】
また、スタイルに対しアクセス権限を設定した場合、スタイル権限テーブルに登録された内容に基づき、スタイルシート自体に、指定されたユーザ範囲やアクセスタイプを登録するようにしてもよい。この場合、例えば、図８３の実線で囲まれた部分に示すように、スタイルシート中のアクセス権限を設定する記述部分（ＳＩＤにて特定される記述部分）に、ユーザ範囲とアクセスタイプを書き込み、クライアント端末装置１０２が、当該スタイルシートを適用する段階で、このアクセス権限の記述を解釈できる機能があればよい。
【０３５７】
また、クエリに対しアクセス権限を設定した場合、クエリ権限テーブルに登録された内容に基づき、クエリ文書自体に、指定されたユーザ範囲やアクセスタイプを登録するようにしてもよい。この場合も例えば、図８４の実線で囲まれた部分に示すように、クエリ文書中のアクセス権限を設定する記述部分（ＱＩＤにて特定される記述部分）に、ユーザ範囲とアクセスタイプを書き込み、検索要求処理部３が、当該クエリを実行する際に、このアクセス権限の記述を解釈できる機能があればよい。
【０３５８】
次に、上記のようにしてアクセス権限が設定された後、クエリを用いた検索実行結果の表示例について説明する。
【０３５９】
ここでは、例えば、図６２の中、「ＨＩＤ７」という識別子を持つ記述部分に対応する表示領域３０７と、「ＨＩＤ１１」という識別子を持つ記述部分に対応する表示領域３１１と、「ＨＩＤ１３」という識別子を持つ記述部分に対応する表示領域３１３とが指定されて、「山田太郎」という個人をユーザ範囲としたアクセス権限が設定されたとする。表示領域３０７、３１１には、アクセスタイプとして「伏せ字」が指定され、表示領域３１３にはアクセスタイプとして「モザイク」が指定されたとする。
【０３６０】
さらに、上記３つの表示領域に、アクセスレベルが「データ」と指定されてアクセス権限が設定されたとする。この場合、「山田太郎」というユーザが、クライアント端末装置１０２から、所定の操作を行って、図１に示した構造化文書管理システムにアクセスして、図７７に示したクエリを用いて検索を行ったとする。なお、ユーザ名「山田太郎」は、構造化文書管理システムにアクセスする際に、クライアント端末装置１０２を介して、構造化文書管理システムの要求制御部１，アクセス権限設定管理部２０１にも入力するようになっている。
【０３６１】
すると、検索結果として得られた検索結果文書（ＸＭＬ文書）は、クライアント端末装置１０２の表示画面には、図８５に示すように表示される。すなわち、表示領域３０７、３１１に表示されるデータは、伏せ字「×」や「○」で表示されている。また、表示領域３１３は、モザイクがかけられて表示されている。さらに、表示領域３０７に表示されるデータと同じデータを表示している表示領域３１５にも、表示領域３０７と同様の伏せ字「×」が表示されている。これは、表示領域３０７に表示されているデータ（この場合、テキスト）は、そのデータを要素値とする構造化文書データベース中の構成要素、すなわち、例えば、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスにて表現される論理的な格納エリアに格納されている構成要素と、「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」というパスにて表現される論理的な格納エリアに格納されている構成要素とに対しアクセス権限が設定されているからである。
【０３６２】
検索要求処理部３では、例えば、図７７に示したクエリを実行して、検索条件を満たす構成要素を構造化文書データベースから取り出す際に、アクセス権限設定管理部２０１と通信を行い、アクセス権限設定管理部２０１にて管理されている図７４に示したようなアクセス権限テーブルに基づき、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスにて特定される構成要素と、「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」というパスにて特定される構成要素とに、アクセス権限が設定されていることを知る。
【０３６３】
このアクセス権限の設定された、「ｕｉｘ：／／ｒｏｏｔ／報告書ＤＢ／報告書［０］／報告者」というパスにて特定される構成要素と、「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」というパスにて特定される構成要素は、図７７に示したクエリにより、検索結果文書中の「報告書／報告者／名前」というパスで特定される検索結果文書の構成要素として用いられる（バインドされている）。この段階で、当該検索結果文書中に当該構成要素のアクセスタイプなどをクライアント端末装置１０２の所定の機能により解釈可能なように書き込むようにしてもよい。
【０３６４】
あるいは、検索要求処理部３で検索結果文書を作成した段階で、アクセス権限設定管理部２０１が、この検索結果文書中の構成要素にアクセス権限が設定されているか否かをアクセス権限テーブルを参照することによりチェックして、当該検索結果文書中のアクセス権限の設定された構成要素にアクセスタイプなどをクライアント端末装置１０２の所定の機能により解釈可能なように書き込むようにしてもよい。
【０３６５】
この検索結果文書は、図６４に示すようなスタイルシートとともに、検索要求元のクライアント端末装置１０２に送信される。
【０３６６】
図６４に示すようなスタイルシートにより、「報告書／報告者／名前」というパスで特定される検索結果文書の構成要素は、図８５に示すように、表示領域３０７と３１５の両方に表示されるように、当該検索結果文書としてのＸＭＬ文書をＨＴＭＬ文書に変換するようになっている。なお、図６４に図示していないが、図６４のスタイルシートには、「報告書／報告者／名前」というパスで特定される検索結果文書の構成要素を、図８５に示すように、表示領域３０７と３１５の両方に表示するようなＨＴＭＬ文書に変換するための変換規則が記述されている。
【０３６７】
表示領域３０７にアクセスレベルが「スタイル」と指定されてアクセス権限が設定されたとする。この場合、スタイルシートには、図８３に示すように、アクセス権限が書き込まれているものとする。また、クライアント端末装置１０２で検索結果文書をＨＴＭＬ文書に変換する際に、当該スタイルシート中のアクセス権限に関する記述を解釈する機能が必要である。スタイルシートには、「報告書／報告者／名前」というパスで特定される検索結果文書の構成要素を表示領域３０７に表示するようなＨＴＭＬ文書に変換するための記述部分には、例えばユーザ範囲とアクセスタイプとが書き込まれているが、表示領域３１５に表示するようなＨＴＭＬ文書に変換するための記述部分には、そのようなアクセス権限に関する記述は書き込まれていない。従って、図８６に示すように、表示領域３１５には、伏せ字ではなく、実際のデータが表示される。
【０３６８】
「山田太郎」というユーザが、クライアント端末装置１０２から、所定の操作を行って、図１に示した構造化文書管理システムにアクセスして、図７７に示したクエリとは異なるクエリを用いて検索を行ったとする。このクエリは、例えば、構造化文書データベース中の「従業員ＤＢ」ノード以下に格納されている情報から所定の条件を満たす「従業員」情報を検索するものであるとする。この検索の結果得られる検索結果文書は、上記所定の条件を満たす複数の「従業員」情報を合成したものであるとする。
【０３６９】
この検索結果文書には、上記のようにしてアクセス権限の設定された「ｕｉｘ：／／ｒｏｏｔ／従業員ＤＢ／従業員［３］／名前」というパスにて特定される構成要素が含まれているとする。すると、上記同様にして、図８７に示すように、この構成要素を表示する表示領域３２１には伏せ字「ｘ」による表示がなされている。
【０３７０】
しかし、表示領域３０７にアクセスレベルが「クエリ」と指定されてアクセス権限が設定されたとする。すなわち、表示領域３０７に表示されるデータに対応する検索結果文書中の構成要素に対応する図７７に示したクエリ中の記述部分に、（検索結果文書中の構成要素に対する）アクセス権限が設定されていた場合には、今回のクエリは図７７に示したクエリとは異なるものであるから、図８７に示した表示領域３２１には伏せ字「ｘ」ではなく、実際のデータ、すなわち、「山田太郎」が表示される。
【０３７１】
このように、アクセス権限をスタイルシート、クエリといったレベルに設定することにより、あるスタイルシートを用いていたときには表示されなかったデータが他の異なるスタイルシートを用いれば表示される、あるクエリを用いた検索結果では表示されなかったデータが他の異なるクエリを用いたときには表示されるといった、柔軟なアクセス権限の設定が可能になる。
【０３７２】
以上説明したように、上記実施形態は、１つの表示領域（テキストボックス）には、１つの構成要素の要素名あるいは要素値が表示されていて、クエリによって検索した結果得られた検索結果文書を表示した表示画面上の複数の表示領域のうちの１つが選択されたら、その選択された表示領域に表示されているデータ（要素名あるいは要素値）を起点にして、スタイルシート、検索結果文書、クエリ、構造化文書データベース中の構造化文書とレベルを掘り下げていく過程に存在する、ユーザにより指定されたレベルのアクセス権限の設定対象にアクセス権限を設定するものであり、ユーザは、検索結果の表示画面上で、少なくとも所望の表示領域と、アクセスレベルを指定するだけで、構造化文書データベース中の構成要素にアクセス権限の設定が行える。さらに、スタイルシートの記述部分、クエリ中の記述部分、当該要素を含む構造化文書と同じ文書構造を持つ他の構造化文書中の当該要素と同じ要素名の要素に対しても、それ対応のレベルを指定するだけでアクセス権限を設定することができるので、構造化文書データベースに格納されている構造化文書の構成要素の用途や表示形式（検索結果として表示する際の表示形式）に応じて、異なる内容のアクセス権限を容易に設定することができる。
【０３７３】
なお、上記実施形態では、アクセス権限の設定は、クエリを用いて、構造化文書データベースを検索した結果得られた文書を表示した表示画面上で行ったが、この場合に限らず、例えば、前述した取得コマンド「ｇｅｔＸＭＬ」を実行する際においても、そのコマンドにて指定されたパス以下の文書（を構成する全ての構成要素）に、あるいは、当該指定されたパス以下の文書の一部の構成要素に、上記したようなアクセス権限が設定されている場合には、当該指定されたパス以下の文書を表示する際には、そのアクセス権限の設定された構成要素を非表示にしたり、特殊表示にしたりすればよい。
【０３７４】
また、上記実施形態では、アクセスタイプとして、非表示にするか、特殊表示にするかのいずれかを選択するようになっているが、アクセスタイプとしては、これ以外に、削除禁止、編集禁止などがあってもよい。削除禁止、編集禁止といいた構造化文書データベース中の構成要素自体に対する操作を制限するようなアクセスタイプを設定するときは、このアクセスタイプととともに設定されるアクセスレベルはデータレベルである。
【０３７５】
例えば、アクセスタイプとして削除禁止が構造化文書データベース中のある構成要素に設定されると、当該構成要素あるいは、そのような構成要素を含む構造化文書データベース中の論理的なエリア（パス）を指定した領域削除コマンドが実行されても、少なくとも当該アクセス権限の設定された構成要素は削除されることはない。また、アクセスタイプとして編集禁止が構造化文書データベース中のある構成要素に設定されると、当該構成要素の要素値を書き換えることはできない。
【０３７６】
なお、本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピーディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、半導体メモリなどの記録媒体に格納して頒布することもできる。
【０３７７】
また、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題（の少なくとも１つ）が解決でき、発明の効果の欄で述べられている効果（のなくとも１つ）が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０３７８】
【発明の効果】
以上説明したように、本発明によれば、検索結果の表示画面上で、少なくとも所望の表示領域とアクセスレベルを指定するだけで、構造化文書データベース中の所望の構成要素に、用途や表示形式などに応じた所望のアクセス権限を容易にしかもきめ細かく設定することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図２】図１に示した構造化文書管理システムの一利用形態を示したもので、ＷＷＷのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図３】ＸＭＬで記述された構造化文書の一例を示した図。
【図４】図３の構造化文書の文書構造を模式的に示した図。
【図５】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図６】図５（ｂ）に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図７】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して１つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図８】図５（ｂ）に示した状態の構造化文書データベースに対し、追加コマンドを実行して３つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図９】要素名生起インデックスの格納例を示した図。
【図１０】データ生起インデックスの格納例を示した図。
【図１１】図８に示した状態の構造化文書データベースに対して、３つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図１２】ＸＭＬ文書の文書構造を定義するスキーマの一例を示した図。
【図１３】図８に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図１２に示したスキーマを追加格納（設定）した場合を示した図。
【図１４】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図１５】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図１６】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１７】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図１８】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図１９】図８に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図１６，図１７に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図２０】図１の構造化文書管理システムの文書格納処理動作について説明するためのフローチャート。
【図２１】図２０のステップＳ９の処理（合成文書作成部の処理）について説明するためのフローチャート
【図２２】追加コマンド中のパラメータの格納文書の文書オブジェクトツリーを構造化文書データベースから取得した文書オブジェクトツリーに挿入して得られた合成文書の文書オブジェクトツリーをＸＭＬ文書に変換した結果であって、テンポラリファイルＡに格納される合成文書の一例を示した図。
【図２３】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２４】テンポラリファイルＡに格納される合成文書の他の例を示した図。
【図２５】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図２６】図１の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図２７】図１の構造化文書管理システムの文書削除処理動作について説明するためのフローチャート。
【図２８】図２７のステップＳ４６の処理（合成文書作成部の処理（削除コマンド用））について説明するためのフローチャート。
【図２９】テンポラリファイルＡに格納される合成文書のさらに他の例であって、削除コマンドの実行時に作成される合成文書の一例を示した図。
【図３０】テンポラリファイルＢに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図３１】ユーザインタフェースとしての画面の表示例を示した図。
【図３２】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３３】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３４】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図３５】妥当性のチェックでエラーとなっときにクライアント端末へ返すメッセージの表示例を表示例を示した図。
【図３６】文書の格納／削除を行うためのユーザインタフェースとしての画面の表示例を示したもので、文書取得動作を説明するための図。
【図３７】スキーマの設定を行うためのユーザインタフェースとしての画面の表示例を示したもので、スキーマの設定動作を説明するための図。
【図３８】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図３９】クエリ（ＸＭＬ文書）の一例を示した図。
【図４０】単純検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４１】図４０の単純検索のクエリを用いた検索結果（ＸＭＬ文書）を示した図。
【図４２】概念検索のクエリ（ＸＭＬ文書）の一例を示した図。
【図４３】図１の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図４４】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図４５】図４４に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図４６】図４２に示したクエリの構造化文書データベース内における格納例を示した図。
【図４７】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図４８】スキーマ検索のクエリの一例を示した図。
【図４９】クエリを検索するためのクエリの一例を示した図。
【図５０】特許調査における構造化文書データベースの一例を示した図。
【図５１】概念検索のための入力画面の表示例を示した図。
【図５２】図５１に示した入力画面上の入力情報に対応するクエリを示した図。
【図５３】図５２に示したクエリに対応する検索結果としてのＸＭＬ文書を示した図。
【図５４】特許マップの一例を示した図。
【図５５】クライアント端末装置の要部の構成例を示した図。
【図５６】クライアント端末装置で構造化文書管理システムから送信されてきたＸＭＬ文書を表示する際の処理動作を説明するためのフローチャート。
【図５７】アクセス権限の設定のためのクライアント端末装置における処理動作を説明するためのフローチャート。
【図５８】アクセス権限設定管理部の機能ブロック図。
【図５９】構造化文書データベースの論理構造の一部を模式的に示した図。
【図６０】ＸＭＬで記述された構造化文書の一例として、「報告書ＤＢ」ノード以下の論理的な格納エリアに格納されている「報告書」情報を示した図。
【図６１】ＸＭＬで記述された構造化文書の一例として、「従業員ＤＢ」ノード以下の論理的な格納エリアに格納されている複数の「報告書」情報を示した図。
【図６２】クライアント端末装置のディスプレイ装置の画面表示例を示したもので、クライアント端末装置から入力されたクエリを実行した結果得られたＸＭＬ文書（検索結果文書）の表示例を示した図。
【図６３】図６２に対応する検索結果文書を示した図。
【図６４】図６３に示した検索結果文書を図６２に示したような表示形式で表示するためのＨＴＭＬ文書に変換するためのスタイルシートの一例を示した図。
【図６５】ＨＴＭＬ文書の各記述部分と各記述部分に与えられている識別子ＨＩＤとの対応を説明するための図。
【図６６】ＨＴＭＬ文書中の記述部分と、スタイルシート中の記述部分との対応関係を示した対応テーブルの一例を示した図。
【図６７】ユーザの範囲を入力するためのＧＵＩ画面の一例を示した図。
【図６８】アクセスレベルを入力するためのＧＵＩ画面の一例を示した図。
【図６９】アクセスタイプを入力するためのＧＵＩ画面の一例を示した図。
【図７０】アクセス権限設定管理部で、アクセス権限を設定するための処理動作を説明するためのフローチャート。
【図７１】アクセス権限設定管理部で、アクセス権限を設定するための処理動作を説明するためのフローチャート。
【図７２】スタイルアクセス権限管理部に格納されているスタイルアクセス権限テーブルの一例を示した図。
【図７３】クエリアクセス権限管理部に格納されているクエリアクセス権限テーブルの一例を示した図。
【図７４】データアクセス権限管理部に格納されているデータアクセス権限テーブルの一例を示した図。
【図７５】スキーマアクセス権限管理部に格納されているスキーマアクセス権限テーブルの一例を示した図。
【図７６】パスアクセス権限管理部に格納されているパスアクセス権限テーブルの一例を示した図。
【図７７】図６３に示したＸＭＬ文書を得るために用いたクエリ文書を示した図。
【図７８】図７７に示したクエリの記述を基に、アクセス権限の設定対象の構成要素を構造化文書データベースから検索するために発行するクエリの一例を示した図。
【図７９】図７７に示したクエリの記述を基に、アクセス権限の設定対象の構成要素を構造化文書データベースから検索するために発行するクエリの一例を示した図。
【図８０】図７８、７９に示したクエリを実行したことにより得られた構造化文書データベース中の構成要素の論理的な格納位置（パス）を示した図。
【図８１】図６２の表示領域３０７が指定され、しかもアクセスレベルがスキーマと指定されたときに、アクセス権限が設定されるスキーマ中の記述部分を示した図。
【図８２】図６２の表示領域３０７が指定され、しかもアクセスレベルがパスと指定されたときに、アクセス権限が設定される構成要素を示した図。
【図８３】アクセス権限の内容が書き込まれたスタイルシートの一例を示した図。
【図８４】アクセス権限の内容が書き込まれたクエリの一例を示した図。
【図８５】データレベルでアクセス権限が設定された後に、図７７に示したクエリを実行した際に得られた検索結果文書の表示例を示した図。
【図８６】スタイルレベルでアクセス権限が設定された後に、図７７に示したクエリを実行した際に得られた検索結果文書の表示例を示した図。
【図８７】データレベルでアクセス権限が設定された後に、図７７に示したクエリとは異なるクエリを実行した際に得られた検索結果文書の表示例を示した図。
【図８８】図６５に示した表示画面に対応するＨＴＭＬ文書の一部を示した図。
【符号の説明】
１…要求制御部
２…アクセス要求処理部
３…検索要求処理部
４…データアクセス部
５…文書記憶部
６…インデックス記憶部
１１…受付要求部
１２…結果処理部
２１…文書格納部
２２…文書取得部
２３…文書削除部
４１…文書オブジェクトツリー格納部
４２…文書オブジェクトツリー削除部
４３…文書オブジェクトツリー取得部
４４…文書文字列取得部
４５…パスから文書オブジェクトツリー取得部
４６…文書パーサ
４７…合成文書作成部
４８…インデックス更新部
１００…構造化文書管理システム
１０１…ＷＷＷサーバ
１０２…クライアント端末
１０３…ＷＷＷブラウザ
１１１…ＸＭＬ文書受信部
１１２…ＸＭＬ／ＨＴＭＬ変換部
１１３…テーブル作成部
１１４…対応テーブル
１１５…描画部
１１６…アクセス権限設定部
１１７…送信部
１２１…ディスプレイ装置
１２２…入力装置
２０１…アクセス権限設定管理部
２０２…アクセス権限設定部
２０３…アクセス権限管理部
２１１…スキーマアクセス権限管理部
２１２…データアクセス権限管理部
２１３…クエリアクセス権限管理部
２１４…スタイルアクセス権限管理部
２１５…パスアクセス権限管理部[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a method for setting access authority for a structured document database having a hierarchical logical structure for a plurality of structured documents having different document structures.
[0002]
[Prior art]
XML (extensible Markup Language) is currently attracting attention as a global standard for intra-organizational data and exchange formats between companies. Structural information can be added to these XML documents (hereinafter referred to as XML documents), which is called a structured document. Development of a database for storing and retrieving these structured documents is currently in progress. By creating a structured document into a database, a new structured document (processed structured document) in which a desired structured document is retrieved from the database using a data query language (hereinafter referred to as a query) and synthesized. ) Can be generated. For example, a query makes it possible to create one processed structured document from the contents of a paper database and an employee database.
[0003]
A style sheet represented by XSL (extensible stylesheet language) is used to display a structured document on a browser or the like. XSL is recommended by the W3C, and is itself described in XML. This consists of a language that defines the display, and determines the display format mainly by pattern matching.
[0004]
The following procedure is generally used as a format for using a database from an application.
[0005]
(1) Store structured documents in database
(2) Obtain desired data from these databases by query
▲ 3 ▼ Display these data on the screen of the browser etc. according to the style
Here, the query includes an operation of acquiring stored data. Therefore, a query is issued even when a document stored in the database is to be displayed as it is.
[0006]
Depending on the application, there are many requests to be able to set the access authority according to the hierarchical structure of the structured document. For example, you want to specify according to the document structure that user A and user B have access authority to one element in a structured document, and only user A has access to the other element. It is.
[0007]
Such an access authority setting is not an access authority setting for each table and record such as an RDB, but an access authority setting for a tree structure, and several methods have been proposed.
[0008]
For example, there is PH07-44579 as an access authority setting method according to the hierarchical structure. This allows setting of access authority for each hierarchical structure of the structured document, and also allows inheritance of access authority. In other words, it shows an implementation method close to access authority for object-oriented data. Since access authority is set for a document, it is necessary to set access authority for all stored documents. Since XML is allowed even when there is no schema, it is not sufficient to set access authority for a schema. Therefore, setting the access authority for each of the enormous number of documents is a laborious operation. Also, this is to set direct access authority for the XML document, but the XML document is only data, and how to use this data often depends on the application side.
[0009]
Depending on the application, there is a request that even a user with the same access authority does not allow display on an element on a certain screen but allows display on a certain screen. In addition, even if the access authority is the same, the display of the XML document itself is not permitted, but there may be a case where it is desired to perform the setting so that the display is possible when the result is processed as a total result by the query. In other words, rather than a stored XML document, the former is an access authority for display, and the latter is an access authority for a query.
[0010]
As described above, on the application side, the authority for the data displayed in the display format (style) is often used as the access authority. There is P2001-22749 as an attempt to set access authority for each style. This is simply managed by associating a user ID and a style ID and specifying an accessible style for each user, and does not consider the document structure of the XML document itself.
[0011]
In PH11-25076, in the access authority setting of the structured document, when the display unit and the data management unit are separately managed and only the information having the access authority is presented to the user and it is desired to perform the update, It has a configuration that allows only part of the update. However, this also requires setting the access authority for each document, and there still remains a problem regarding the load on the setting.
[0012]
If a schema is required, such as RDB, it may be possible to set access authority to the schema. However, XML has the same name and features such as whether or not the schema is present. There are features such as the fact that multiple elements may exist at the same level, and the structure is often ambiguous. Considering these, it is necessary to set access authority for each component of the structured document.
[0013]
In addition, the access authority is actually set after the application level, and is not at the stage of creating data in many cases. For example, even if the same data is used, in a certain usage (search condition) or style (display format), the user A is given access authority to a certain element x, but another certain usage or style (display format). Then, it is also possible to perform flexible processing such as losing access authority. In other words, the access authority is often set at the application creation stage, and a function is required to easily set the access authority at that stage.
[0014]
Furthermore, when captured from the application side, a function that can set access authority for each style or for each application is desired. For example, regarding the style, the graph of a certain element x is shown to the user A, but the graph display is not possible to the user B, for example, due to restrictions such as displaying with a mosaic. is there. However, although user B cannot display it as a graph, it may be possible to acquire the value as XML data. It is also conceivable to set an access right such that the results aggregated by the query can be accessed, but other individual documents cannot be accessed. These cannot be realized by a method of giving access authority only to documents stored in the database.
[0015]
[Problems to be solved by the invention]
As described above, the conventional method for setting access authority to a structured document can set the access authority for each component of the structured document, but the setting is troublesome. was there. In particular, the labor and cost of setting access authority for each component of a huge amount of structured documents in a structured document database having a logical space are considerably large.
[0016]
In addition to setting access rights to the components of the structured document stored in the structured document database, depending on the display format and usage (ie, depending on the style sheet or query), There was a problem that fine access authority settings such as setting different access authority for a component could not be performed.
[0017]
In view of the above problems, an object of the present invention is to provide an access authority setting method and a structured document management apparatus in which it is easy to finely set an access authority for each component of a structured document.
[0018]
In addition, it is easy to set access privileges for different contents according to the usage and display format of the components of the structured document stored in the structured document database (display format when displaying as a search result). An object is to provide an access authority setting method and a structured document management apparatus.
[0019]
[Means for Solving the Problems]
The present invention is for setting an access authority for the components of the structured document constituting the logical structure of the structured document database having a hierarchical logical structure storing a plurality of structured documents. A search result document composed of a plurality of components obtained as a result of a search using a search request statement (query) for searching for a desired component based on the logical structure from the structured document database is displayed. When an arbitrary display area on the display screen is designated, the first constituent element in the search result document corresponding to the data displayed in the designated display area is specified, and the first constituent element is specified. A second component corresponding to the first component in the structured document database is searched based on the description of the second description part in the search request sentence associated with To 2 components, and sets the access privileges define the range of the user to access at least the second component is limited.
[0020]
According to the present invention, the user simply designates at least a desired display area on the search result display screen, and the user can select a desired document in the structured document database corresponding to the data displayed in the designated display area. The access authority can be easily set for the components.
[0021]
Further, the present invention sets an access authority for the components of the structured document constituting the logical structure of the structured document database having a hierarchical logical structure storing a plurality of structured documents. A search result document composed of a plurality of components obtained as a result of a search using a search request statement (query) for searching for a desired component based on the logical structure from the structured document database is displayed. When an arbitrary display area on the display screen is specified, the search result used to display the search result document associated with the data displayed in the specified display area in a predetermined display format A first description part in a document structure conversion rule (style sheet) of a document and a first component in the search result document associated with the first description part are extracted. At least a first level (style level) for setting access authority to the first description part in the conversion rule, and a second description part corresponding to the first component in the search request sentence A second level (query level) for setting an access right, and the structured document database in the structured document database identified based on a description of a third description part in the search request sentence associated with the second description part. Of the plurality of levels including the third level (data level) for setting the access authority to the second component corresponding to the first component, at least the level designated by the user is accessed. The access authority is set by determining the range of restricted users.
[0022]
According to the present invention, when a desired display area is designated by the user, the description portion of the style sheet corresponding to the designated display area and a search associated therewith are specified according to the level designated by the user. By specifying the components in the result document, the corresponding description part in the query, and the elements in the structured document database associated therewith, the access authority is set to the specified level. Can be done easily. The user can set the access authority to the components in the structured document database only by designating at least a desired display area and access level on the search result display screen.
[0023]
By setting the access authority to a level such as a style sheet or query, data that was not displayed when a certain style sheet was used will be displayed if another different style sheet is used. In search results using a certain query, it will be displayed. It is possible to set flexible access authority such that data that has not been displayed is displayed when other different queries are used. Further, when the access authority is set at a certain query level, this access authority is applied to any style sheet used for displaying the search result document obtained as a result of the query. Further, when the access authority is set at the data level, this access authority is applied regardless of which query or style sheet is used in order to use the component for which the access authority is set.
[0024]
When access authority is set at the query level, it is possible to set access authority according to the purpose of use for components in the structured document database. When the access authority is set at the style level, the access authority can be set according to the display format for the component in the structured document database.
[0025]
Further, the plurality of levels may include the second component included in another structured document having the same document structure as the structured document including the second component stored in the structured document database. By including a fourth level for setting the access authority to all the components that are the same as the element name, the description portion of the style sheet, the description portion in the query, the second component in the structured document database In addition, the level corresponding to the element having the same element name as the second component in the other structured document having the same document structure as the structured document including the second component is also provided. The access authority can be easily set in a lump by simply designating (fourth level).
[0026]
In particular, when the fourth level is designated by the user, the designation is made according to the logical structure in which a plurality of structured documents having the same document structure as the structured document including the second component are stored. When there is a document structure definition document (schema) that defines a document structure to be followed by a structured document stored in the structured database in a logical area, the first item in the document structure definition document The access authority for the component having the same element name as that of the second component may be set in the description part regarding the component having the same element name as that of the second component.
[0027]
Further, the conversion rule (style sheet) is for converting the search result document into a display document (HTML document) that displays at least element values of each component of the search result document in one display area. When the search result document is converted into a display document using the conversion rule, the correspondence between the description part of the display document and the description part in the conversion rule related to the description part When a relation is extracted and an arbitrary display area on the display screen is designated, the relation corresponding to the fourth description portion in the display document corresponding to the data displayed in the designated display area By extracting the first description part in the conversion rule based on the correspondence relationship, the first description part in the conversion rule associated with the data displayed in the designated display area can be easily extracted. That.
[0028]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below with reference to the drawings.
[0029]
Examples of structured documents include documents described in XML, SGML, and the like. SGML (Standard Generalized Markup Language) is a standard defined by ISO (International Organization for Standardization). XML (extensible Markup Language) is a standard defined by W3C (World Wide Web Consortium). Each is a structured document convention that allows documents to be structured.
[0030]
Hereinafter, description will be given by taking a document described in XML as a structured document. Data defining the document structure of a structured document (document structure definition data) is called a schema. In XML, schema languages such as XML-Schema and XDR (XML Data Reduced) have been proposed to define the schema. Here, for example, a description will be given of a case where a schema in XDR is described.
[0031]
The schema is also a structured document to be managed by the structured document management system of the present invention, and therefore may be called a schema document. In order to distinguish from a schema document, a document having various contents such as a patent specification, an email, a weekly report, and an advertisement may be referred to as a content document.
[0032]
In the structured document management system of the present invention, the schema document, the content document, and a query describing a search request content from a user as described later, that is, a query document is also managed, and these are collectively referred to as “ Called “Document”.
[0033]
Hereinafter, when there is no special notice, when referring to “document”, it means all content documents, schema documents, and query documents.
[0034]
First, XML will be briefly described before describing the embodiment.
[0035]
FIG. 3 shows an example of “patent” information as an example of a structured document described in XML. In XML and SGML, tags are used to express the structure of a document. A tag has a start tag and an end tag. By enclosing a component of document structure information with a start tag and an end tag, a character string (text) delimiter in the document and which component the text belongs to in the structure Can be clearly described.
[0036]
Here, the start tag is an element name closed with symbols “<” and “>”, and the end tag is an element name closed with symbols “</” and “>”. The content of the component following the tag is a text (character string) or a repetition of a child component. Further, attribute information such as “<element name attribute =“ attribute value ”>” can be set in the start tag. A component that does not include text, such as “<patent DB></ patent DB>”, can also be expressed as “<patent DB />” as a simple notation.
[0037]
The document shown in FIG. 3 has an element set starting from a “title”, “application date”, “applicant”, and “summary” tag as an element starting from the “patent” tag. . Further, for example, one element (character string) such as “XML database” exists in the element starting from the “title” tag.
[0038]
Structured documents such as XML usually contain arbitrary constituent elements, and the document structure is not determined in advance (cannot be defined by RDB (relational database) or OODB (object-oriented database) schema). is there.
[0039]
In order to logically express the structured document as shown in FIG. 3, a tree expression as shown in FIG. 4 is used. The tree is composed of nodes (numbered and indicated by circles), arcs (line with data connecting the circles representing the nodes), and text surrounded by a rectangle.
[0040]
A node corresponds to a document object, and a plurality of arcs with labels corresponding to tag names and attribute names appear from the node. The destination of the arc is a character string (text) as a node or element value. Alphanumeric characters (# 0, # 49) described in the node are object IDs.
[0041]
The tree structure shown in FIG. 4 is called the document object tree of the structured document shown in FIG.
[0042]
FIG. 1 shows an example of the structure of a structured document management system according to this embodiment. In FIG. 1, the structured document management system is roughly divided into a request control unit 1, an access request processing unit 2, a search request processing unit 3, a data access unit 4, a document storage unit 5, an index storage unit 6, and an access authority setting. The management unit 201 is configured. The document storage unit 5 and the index storage unit 6 are configured using, for example, an external storage device.
[0043]
The system configuration of FIG. 1 can be realized using software.
[0044]
The access authority setting management unit 201 will be described later (see “Access authority setting”).
[0045]
The request control unit 1 includes a request reception unit 11 and a result processing unit 12. The request reception unit 11 receives a request for document storage, document acquisition, document search, and the like from the user and calls the access request processing unit 2. The result processing unit 12 performs processing for returning the result processed by the access request processing unit 2 to the requesting user.
[0046]
The access request processing unit 2 includes a plurality of processing units corresponding to requests such as document storage and document acquisition from the user. That is, the document storage unit 21, the document acquisition unit 22, and the document deletion unit 23 are configured.
[0047]
The document storage unit 21 performs processing for storing a document in a logical designated area in the document storage unit 5.
[0048]
When a logical area in the document storage unit 5 is specified, the document acquisition unit 22 performs processing for acquiring a document existing in the specified area.
[0049]
The document deletion unit 23 performs processing for deleting a document existing in a logical designated area in the document storage unit 5.
[0050]
The document storage unit 5 is a structured document database. For example, as shown in FIG. 8, documents are hierarchically stored in a tree structure like a UNIX directory structure.
[0051]
As shown in FIG. 8, the structured document database can be expressed in the same manner as the tree structure of one structured document as shown in FIG. That is, the partial hierarchical tree (partial tree) below an arbitrary node is a structured document cut out from the structured document database, and here, this is called a document object tree. Each node is assigned an object ID. The object ID has a unique numerical value in the structured document database.
[0052]
It is assumed that an object ID “# 0” for specifying that the node is the root node is assigned to the node serving as the root of the hierarchical tree.
[0053]
A link is extended from the root node, that is, the node “# 0” to the node “# 1” having the “root” tag at the head. The “# 1” node has a link to the “# 2” node having the “patent DB” tag at the head. From the “# 2” node, links to a “# 42” node, a “# 52” node, and a “# 62” node having a “patent” tag at the head are provided.
[0054]
The “patent” information shown in FIG. 3 corresponds to a partial tree below the “# 42” node. From this node, a link is made to a node having “title” tag, “applicant” tag, “summary” tag, etc. at the head, and from the end node are “XML database”, “T company”. A link to a character string (element value) such as “Provide a database for uniformly managing XML” is provided.
[0055]
The partial tree below the “# 52” node and the partial node below the “# 62” node are also portions corresponding to one “patent” information.
[0056]
By the way, for example, the element value “XML database” linked to the “# 43” node is connected to the “# 43” node by a special tag name “#value”. Since the tag name starts with “#”, it cannot be used as a standard tag name in the XML standard.
[0057]
A structured document path is used to designate a specific node of such a structured document database. The structured document path is a character string that starts with “ux: /// root”. uix (Universal Identifier for XML) is a prefix character string indicating a structured document path.
[0058]
For example, “uix: // root / patent DB” corresponds to the node indicated by the arc to which “patent DB” is assigned from the “# 1” node, that is, the “# 2” node. In this way, the partial character string delimited by “/” from “root” is regarded as the tag name, and the corresponding arc is descended from the “# 0” node along the sequence of the tag name, and the last arc points to it. The node points to the path location.
[0059]
For example, “uix: // root / patent DB / patent” indicates a “# 42” node, and “uix: // root / patent DB / application date / year” indicates a “# 45” node.
[0060]
If multiple "patent" information is stored below the "# 2" node, that is, in the "patent DB", an index can be expressed in the structured document path to identify each "patent" information. It is.
[0061]
If it is the first “patent” information of “patent DB”, it will be “uix: // root / patent DB / patent [0]”, which is the same as “uix: // root / patent DB / patent” It is considered.
[0062]
If it is the second “patent” information of “patent DB”, if it is the fifth “patent” information of “uix: // root / patent DB / patent [1] DB”, then “uix: // root / Patent DB / Patent [4] ".
[0063]
The index storage unit 6 stores an element name occurrence index and a data occurrence index used at the time of search.
[0064]
The element name occurrence index is an index file created by associating a list of element names stored in the structured document database with the position of the structured document (document object tree) having each element name at the head. For example, as in the structured document database of FIG. 8, a structured document whose element name “patent” (corresponding to “patent” information) is “# 42” node or less, and a structured document “# 52” node or less. , If they are indexed in the structured document below the “# 62” node, as shown in FIG. 9, their parent node, “# 2” node, is “patent” in the element name occurrence index file. Stored in a chain from the key.
[0065]
Thus, when indexing is performed at the parent node, the index file can be compressed. In other words, if indexing is performed at the parent node, the chain size does not increase because the parent node substitutes even if the child node increases. On the other hand, if the real nodes are indexed, the chain size increases in proportion to the increase in the number of stored “patent” information.
[0066]
The data occurrence index is an index file formed by associating a list of character string data stored in the structured document database with the position of the structured document (document object tree) where each character string data is stored. For example, as in the structured document database of FIG. 8, a structured document whose character string data “XML” (and a character string including a character string “XML”) is “# 43” or lower node, “# 49”. If they are present in the structured document below the node, as shown in FIG. 10, the “# 43” node and the “# 49” node are chained from the “XML” key to the data occurrence index file as shown in FIG. Stored.
[0067]
Note that other index files such as a reverse hierarchy index may be used. The reverse hierarchy index stores the correspondence between a certain node and its parent node (the parent node can be obtained from a certain node).
[0068]
The logical designation area in the document storage unit 5 indicates a storage location of a document designated by the user using a structured document path. A structured document path (sometimes simply called a path) is an expression that can be recognized by the user.
[0069]
Returning to the description of FIG.
[0070]
The data access unit 4 is a set of basic interfaces for accessing the document storage unit 5. The data access unit 4 includes a document object tree storage unit 47, a document object tree deletion unit 48, a document object tree acquisition unit 49, a document character string acquisition unit 44, a path-to-document object tree acquisition unit 45, a document parser unit 46, a composite document A creation unit 47 and an index update unit 48 are included.
[0071]
The document object tree storage unit 41 performs processing for storing the document object tree in a physical designated area in the document storage unit 5.
[0072]
The document object tree deletion unit 42 performs processing for deleting the document object tree existing in the physical designated area in the document storage unit 5.
[0073]
The document object tree acquisition unit 43 performs a process of acquiring a document object tree existing in a physical designated area in the document storage unit 5.
[0074]
The document character string acquisition unit 44 performs processing for converting the document object tree into a structured document (XML document).
[0075]
From the path, the document object tree acquisition unit 45 analyzes the structured document path, specifies a physical area in the document storage unit 5, and performs a process of extracting the document object tree existing in the area.
[0076]
The document parser unit 46 reads a structured document input by a user, parses and analyzes the consistency, and further verifies whether or not the schema which is document structure definition data is structurally valid. . The output result is a document object tree. The document parser can usually be constructed by combining a lexical analyzer (lexical analyzer generator) such as lex (performs lexical analysis and decomposes into tokens) and a parser generator such as yacc (yet another compiler compiler).
[0077]
The composite document creation unit 47 must check whether it conforms to the schema when storing a document or deleting a document, and creates and outputs data necessary for this check.
[0078]
The index updating unit 48 updates the element name occurrence index and the data occurrence index shown in FIGS. 9 and 10 every time the stored contents of the structured document database are updated due to document storage or document deletion.
[0079]
The physical designation area in the document storage unit 5 is internal data indicating the location of unique document data in the structured document database such as file offset and object ID. The data cannot be recognized by the user.
[0080]
A process for retrieving a document stored in the document storage unit 5 is performed. When the request receiving unit 11 of the request control unit 1 receives a document search request from the user, the search request processing unit 3 receives a query document described in the query language from the request receiving unit 11. Then, the index storage unit 6 and the document storage unit 5 are accessed through the data access unit 4, a document set that matches the search request is acquired, and the result is output via the result processing unit 12.
[0081]
FIG. 2 shows one use form of the structured document management system shown in FIG. 1. In FIG. 2, the structured document management of the configuration shown in FIG. 1 is performed on the back end of the WWW (World Wide Web). The case where the system 100 is operating is shown.
[0082]
The WWW browser 103 is operating in each of a plurality (for example, three) of client terminals (for example, personal computers, portable communication terminals, etc.) 102. The user can access the structured document management system 100 by accessing the WWW server 101 from each client terminal. The WWW browser 103 and the WWW server 101 communicate with each other using HTTP (Hyper Text Transfer Protocol). Further, the WWW server 101 and the structured document management system 100 communicate with each other via CGI (Common Gateway Interface) or COM (Component Object Model).
[0083]
Requests such as document storage, document acquisition, and document search from the user are transmitted from the WWW browser 103 and received by the structured document management system 100 through the WWW server 101, and processed results are requested through the WWW server 101. A reply is sent to the original WWW browser 103.
[0084]
The (1) storage function and (2) search function of the structured document management system in FIG. 1 will be described in detail below. In (3) Application Example, a case of patent search using concept search will be described as an example.
[0085]
(1) Storage function
The storage system commands in the structured document management system of FIG.
[0086]
insertXML (path, Nth, XML): document storage
appendXML (path, XML): document storage
getXML (path): Document acquisition
removeXML (path): Delete document
setSchema (path, schema): Schema storage
getSchema (path): Schema acquisition
“InsertXML” is a command (hereinafter simply referred to as an insert command) that inserts a document at the Nth position below the structured document path specified in ().
[0087]
“AppendXML” is a command for inserting a document at the end of the structured document path specified in () (hereinafter simply referred to as an add command).
[0088]
“GetXML” is a command for retrieving a document below the structured document path specified in () (hereinafter simply referred to as an acquisition command).
[0089]
“RemoveXML” is a command (hereinafter simply referred to as a delete command) for deleting a document below the structured document path specified in () (a document other than a schema document, mainly a content document).
[0090]
“SetSchema” is a command (hereinafter simply referred to as a schema storage command) for setting a schema in the structured document path specified in ().
[0091]
“GetSchema” is a command for retrieving the schema set in the structured document path specified in () (hereinafter simply referred to as a schema acquisition command).
[0092]
Among the above commands, processing for the insert command, addition command, and schema storage command is executed by the document storage unit 21 of the access request processing unit 2, and processing for the acquisition command and schema acquisition command is executed by the document acquisition unit 22. Processing regarding the delete command is executed by the document deletion unit 23.
[0093]
With reference to FIG. 5, the case where an additional command is executed in the initial state of the structured document database (see FIG. 5A) will be described.
[0094]
As shown in FIG. 5A, with respect to the initial state in which the “# 0” node and the “# 1” node are connected by the “root” arc,
“AppendXML (“ uix: // root ”,“ <patent DB /> ”)”
As a result of the above, as shown in FIG. 5B, a “# 2” node and a “patent DB” arc are created.
[0095]
A case where an acquisition command is executed on the structured document database in the state shown in FIG.
[0096]
For example, when “getXML (“ uix: /// root ”)” is executed, the document object tree below the “# 0” node indicated by the “root” arc in FIG. 5B is taken out, and is stored in the XML character string table. Convert to actual. As a result, as shown in FIG. 6, a character string “<root><patent DB /></root>” is extracted. The processing of the acquisition command is executed by the document acquisition unit 22 of the access request processing unit 2.
[0097]
Next, when an additional command for storing “patent” information as a content document (XML document) as shown in FIG. 3 is executed for the structured document database in the state shown in FIG. Will be described. That is, in this case, “appendXML (“ uix: // root / patent DB ”,“ <patent>... </ Patent> ”)” is executed. In this command, ““ <patent>... </ Patent> ”” corresponds to the “patent” information shown in FIG.
[0098]
When the processing of the additional command is executed, as shown in FIG. 7, a document object tree (corresponding to FIG. 4) with the “# 42” node at the top is added below the “# 2” node.
[0099]
Assume that the following additional command is repeatedly executed three times for the structured document database in the state shown in FIG.
[0100]
"AppendXML (" uix: // root / patent DB ","<patent> ... </ patent>")"
In the above command, “<patent>... </ Patent>” corresponds to the content document having the document structure shown in FIG.
[0101]
Then, as shown in FIG. 8, a document object tree with “# 42” node, “# 52” node, and “# 62” node at the top is added below the “# 2” node.
[0102]
Next, a case where an acquisition command for extracting three pieces of “patent” information is executed on the structured document database in the state shown in FIG. 8 will be described. In this case, “getXML (“ uix: // root / patent DB ”)” is executed. Then, the document object tree below the “# 2” node indicated by the “patent DB” arc is extracted, and is converted into an XML character string representation (XML document). As a result, as shown in FIG. 11, a character string “<patent DB><patent> ... </ patent><patent> ... </ patent><patent> ... </ patent></ patent DB>” is extracted. It is.
[0103]
In the structured document database, data defining the document structure of the content document (XML document) such as the “patent” information, that is, the schema, is also managed.
[0104]
FIG. 12 shows an example of a schema that defines the document structure of an XML document. Here, XDR (XML-Data Reduced), which is one of XML document structure definition languages, will be taken up. Of course, other document structure definition languages such as XML-Schema may be used.
[0105]
The schema shown in FIG. 12 defines the document structure of the “patent” information shown in FIG. 3 in XDR. As can be easily seen from FIG. 12, the schema is also a structured document in the XML format. There is an element set that starts with a component starting with a “Schema” tag and starts with an “ElementType” tag as its child elements.
[0106]
In the schema shown in FIG. 12, for example, a child element starting from the first “ElementType” tag means the following information.
[0107]
A document structure definition of an element having a “patent” tag (“ElementType name =“ patent ””).
[0108]
A child element is only an element (“content =“ eltOnly ””).
[0109]
-It is composed of child elements starting with "title", "application date", and "summary" tags ("element type =" title ", ..."). Further, the order is uniquely determined (“order =“ seq ””).
[0110]
In addition to the document structure definition of the element starting from the “patent” tag, the document structure definition of “title”, “applicant”, “summary”, “year”, “month”, “day”, and “application date” is described. That is, the child element of the component starting from the “title”, “applicant”, “summary”, “year”, “month”, and “day” tags, excluding “application date”, is defined as text only (“content =“ textOnly ”). "").
[0111]
The child elements of the constituent elements starting from the “application date” tag are a sequence of “year”, “month”, and “day”.
[0112]
A case where a schema storage command for storing the schema document shown in FIG. 12 is executed on the structured document database in the state shown in FIG. 8 will be described. In this case, “set Schema (“ uix: // root / patent DB ”,“ <Schema>... </ Schema> ”)” is executed. In this command, ““ <Schema>... </ Schema> ”” corresponds to the schema document shown in FIG.
[0113]
By executing the above command, as shown in FIG. 13, a “#schema” arc is added below the “# 2” node, and a document object tree having the “# 3” node as a top node is added to the “# 3” node. The Since the schema itself is expressed as an XML document, the tree can be expanded as in the case of storing content documents such as the “patent” information described above.
[0114]
In FIG. 13, arcs beginning with “@” such as “@name” correspond to attributes. Since the tag name “#schema” also begins with “#” and “@”, it cannot be used as a standard tag name in the XML standard.
[0115]
Since the schema document shown in FIG. 12 is stored under the “# 2” node, the document structure of the documents to be stored below the “# 2” node is defined by the schema document shown in FIG. Conform to the document structure. That is, the schema shown in FIG. 12 is set below the “# 2” node.
[0116]
When the schema shown in FIG. 12 is set below the “# 2” node, as shown in FIG. 14, the document object file of the “# 2” node has a document object tree below the “# 2” node. Is set to an attribute value indicating that the schema exists.
[0117]
After the schema shown in FIG. 12 is set below the “# 2” node, the “patent” information shown in FIG. 3 that matches the document structure defined in this schema is shown in FIG. When the document object tree is stored in the structured document database, an attribute value indicating that the schema shown in FIG. 12 exists in the document structure of this document is set in each document object constituting the document object tree. . For example, “1” is set to an attribute value (for example, “schema conformity presence / absence”) indicating that a schema exists for each document object file constituting the document object tree. Each document object (node) conforming to the schema is indicated by a double circle, and each document object indicated by the double circle has a document structure definition corresponding to the document object.
[0118]
FIG. 15 conceptually shows the contents of a file of each document object. For example, a file of a document object whose object ID is “# 42” relates to another document object linked to the document object. The attribute value is described together with information (for example, an arc or a pointer value to a linked document object). Note that when there is no schema to be applied to the document object, the value of “existence of schema conformance” is “0”.
[0119]
FIGS. 16 and 17 show examples in which the conceptual hierarchy used in the search is expressed as a structured document as needed in the structured document management system of FIG. The “concept” information shown in FIGS. 16 and 17 is a content document described in XML.
[0120]
The example of “concept” information shown in FIG. 16 represents an “information model” used as one classification axis for classifying the contents of a patent document in a so-called patent search in a concept hierarchy. “Concept” information surrounded by “concept” tags has a document structure with a nested structure. That is, in the example of FIG. 16, there are a concept “document”, a concept “relation”, and a concept “object” as child concepts of the concept “information model”. Further, there are a concept “structured appeal” and a concept “unstructured document” as child concepts of the concept “document”, and a concept “XML” and a concept “ SGML "exists.
[0121]
The description example of the “concept” information illustrated in FIG. 17 represents a classification axis “information operation” different from that in FIG. In the example of FIG. 17, there are a concept “search”, a concept “store”, a concept “processing”, and a concept “distribution” as child concepts of the concept “information operation”.
[0122]
The “concept” information as shown in FIGS. 16 and 17 can also be stored in the structured document database in the same manner as the “patent” information described above. That is, for example, first, “appendXML (“ uix: // root ”,“ <concept DB /> ”)” is executed on the structured document database in the state shown in FIG. Thus, a “# 201” node and a “concept DB” arc are created. In this state, when “concept” information shown in FIG. 16 is stored, “appendXML (“ uix: // root / concept DB ”,“ <concept name>... </ Concept> ”)” is executed. . In this command, ““ <concept name>... </ Concept> ”” corresponds to the “concept” information shown in FIG.
[0123]
When the processing of the addition command is executed, as shown in FIG. 19, a document object tree with the “# 202” node at the top is added below the “# 201” node.
[0124]
As described above, in the structured document management system in FIG. 1, a large number of XML document groups (content documents, schema documents, query documents, etc.) having different document structures registered in the structured document database are displayed. 18. As shown in FIG. 19, it is handled as one large XML document in the form of a tree having a “root” tag at the head. Therefore, in order to access a partial XML document, it is possible to search and process a wide range of XML documents by using a unified access means that does not depend on the document structure, which is a path for a large XML document. .
[0125]
In addition, by setting a schema in a part of the structured document database, the validity of whether or not the document structure of the document to be stored matches the document structure defined by the schema is automatically checked. (See below).
[0126]
(1-1) Document storage processing
Next, the document storage processing operation of the structured document management system of FIG. 1 will be described with reference to the flowchart shown in FIG.
[0127]
When one of an insert command, an add command, and a schema storage command is transmitted as a document storage request from the client terminal to the structured document management system and received by the request reception unit 11, it is shown in FIG. The processing operation is performed.
[0128]
On a predetermined display device of the client terminal, for example, a screen as a user interface as shown in FIG. 31 provided from the structured document management system 100 (for example, the request control unit 1) is displayed.
[0129]
On the screen shown in FIG. 31, a list (menu) of operation items for the structured document management system 100 is displayed. The operation items include “XML registration / deletion”, “schema setting”, and “XML search”.
[0130]
For example, when the user selects “XML registration / deletion” on this screen using a pointing device such as a mouse, a screen as a user interface for storing / deleting a document as shown in FIG. 32 is displayed. Is done.
[0131]
In FIG. 32, in the area W1, element names (tag names) of the current tree structure of the document structured document database are simply displayed so that the user can understand them. In FIG. 32, only the element name of the upper layer is displayed, but it is possible to display the element name at the end. The area W2 is an input area for the structured document path, and the structured document path is input according to the display contents of the area W1. In the area W3, a document to be stored is input and the acquired document is displayed.
[0132]
For example, when “root” is input as the structured document path, “root” in the area W1 may be selected with a mouse or the like. Then, as shown in FIG. 32, “ux: // root” is displayed in the input area of the structured document path in the area W2. When a new element “patent DB” is added, “patent DB” is input in the area W3 as shown in FIG. When the “Register” button B1 is selected, an additional command “appendXML (“ uix: // root ”,“ <patent DB /> ”)” is transmitted from the client terminal to the structured document management system. In the structured document management system, as a result of executing the processing as described later upon receiving the additional command, for example, as shown in FIG. 5B, a “# 2” node and a “patent DB” arc are created. . In the area W1, “patent DB” is additionally displayed under “root” as shown in FIG.
[0133]
Now, the user inputs, for example, a document “<A> data </A>” into an area W3 on the document storage / deletion screen as shown in FIG. 34 (or a predetermined recording medium such as a CD-ROM). When “patent [0]” in the area W1 is selected with a mouse or the like, “uix: // root / patent DB / patent [0]” is entered in the structured document path input area W2. Is displayed. When the “Register” button B1 is selected, an additional command “appendXML (“ uix: // root ”,“ <patent DB /> ”)” is transmitted from the client terminal to the structured document management system.
[0134]
Here, for example, when the structured document database is in the state shown in FIG. 14, “appendXML (“ uix: // root / patent DB / patent [0] ”,“ <A> data </A> ”). ) ”Will be described as an example.
[0135]
Upon receipt of the additional command, the request receiving unit 11 receives the structured document path “uix: // root / patent DB / patent [0]” and the document “<A> data <which are two parameters in the additional command. / A>"(hereinafter referred to as a stored document) is passed to the document storage unit 21 (step S1).
[0136]
First, the document storage unit 21 passes the stored document to the document parser unit 46. The document parser unit 46 reads the stored document, performs syntax analysis, and checks the consistency of whether or not the document structure of the stored document has a correct format defined by XML (step S2).
[0137]
If an error is found in the consistency check (step S3), a message “document storage failure” is returned to the client terminal via the document storage unit 21 and the result processing unit 12 (step S4).
[0138]
If no error is found in the consistency check, the document storage unit 21 then passes the structured document path from the path to the document object tree acquisition unit 45. The document object tree acquisition unit 45 from the path specifies the physical area in the document storage unit 5 from the structured document path, and thereby the node (document object Ox0) represented by the structured document path existing in that area. ) Including the document object tree is extracted (step S5). If the structured document path is specified correctly, the object ID of the document object Ox0 can be acquired (step S6). In this case, the process proceeds to step S8.
[0139]
For example, in the case of the above addition command, since the “# 42” node becomes the document object Ox0, “# 42” is acquired as the object ID, and the document object tree including this “# 42” node (for example, “ A document object tree comprising all descendant nodes of the “# 42” node, all (sibling) nodes in the same hierarchy as the “# 42” node, and a “# 2” node that is a parent node of the “# 42” node) To get.
[0140]
If the corresponding document object Ox0 is not found from the specified structured document path, an error occurs (step S6), and a message “document storage failure” is sent to the client terminal via the document storage unit 21 and the result processing unit 12. A message is returned (step S7).
[0141]
For example, when the structured document database is in the state shown in FIG. 18 and the structured document path is represented as “ux: /// root / other” as a parameter of the additional command, the corresponding document is displayed. Since the object does not exist, an error occurs in step S6, and the process proceeds to step S7.
[0142]
Next, in step S8, it is checked whether or not a schema exists in the document object Ox0. As described above, since this attribute value is described in the file of each document object, this value may be checked. When the value of “whether or not schema conforms” of the document object Ox0 is “1”, the process proceeds to step S9.
[0143]
Hereinafter, the process of step S9 of FIG. 20 (process of the composite document creation unit 47) will be described in detail with reference to the flowchart shown in FIG.
[0144]
The document storage unit 21 passes the document object tree acquired in step S5 to the composite document creation unit 47.
[0145]
The composite document creation unit 47 goes back from the document object Ox0 and searches for the document object Ox1 having the “Schema” tag as a child element (step S21).
[0146]
For example, in the structured document database shown in FIG. 14, a node (“# 3”) having a “Schema” tag at the top from the “# 2” node that is the parent node of the “# 42” node as the document object Ox0. The “# 2” node becomes the document object Ox1 because the link to the “node” is established (because it has the “Schema” tag as a child element). Therefore, step S22 is skipped and it progresses to step S23.
[0147]
The document object Ox0 is traced from this document object Ox1, and the arc is further traced from the document object Ox0, and a document object tree Ot1 composed of all the child nodes whose attribute value is “1” downstream from the document object Ox0 is extracted ( Step S23).
[0148]
For example, when the structured document path of the parameter in the additional command is designated as “uix: // root / patent DB / patent [0]”, the document object tree Ot1 includes “# 42” node to “#” 49 ”nodes (see FIG. 14).
[0149]
Next, the process proceeds to step S25.
[0150]
In step S25, the document object tree of the stored document is inserted into the document object tree Ot1 as a child node of the document object Ox0. The new document object tree obtained as a result is set as a document object tree Ot2.
[0151]
This document object tree Ot2 is converted into an XML document, which is output to a temporary file A (step S27).
[0152]
For example, the document object tree (in this case, one document object) of the parameter storage document “<A> data </A>” in the additional command is composed of “# 42” node to “# 49” nodes. FIG. 22 shows the result of converting the document object tree Ot2 of the synthesized document obtained by inserting the document object tree Ot1 as a child node of the “# 42” node into an XML document. This composite document is obtained by adding data “<A> data </A>” to the original “patent” information.
[0153]
The XML document shown in FIG. 22, that is, the synthesized document, is output to the temporary file A and temporarily stored in the temporary file A.
[0154]
On the other hand, the document object tree Ot3 below the schema tag is converted into an XML document and output to the temporary file B (step S28). In other words, the schema document is temporarily stored in the temporary file B.
[0155]
For example, FIG. 23 shows a result of converting a document object tree having the “# 3” node as the top node in the document object tree Ot3 into an XML document. The XML document shown in FIG. 23 is output to the temporary file B and temporarily stored in the temporary file B.
[0156]
As shown in FIG. 22, in the temporary file A (“tmp000.xml”), in addition to the original “patent” information element, a stored document, that is, “<A> data </ A > ”Is inserted. In addition, “xmlns =” x-schema: tmp001. There is a description of link information to the temporary file B (“tmp001.xml”), “xml” ”. This description specifies the temporary file B in which the schema applied to the “patent” information is output.
[0157]
Next, the description returns to FIG.
[0158]
In step S10, the document storage unit 21 provides the document parser unit 46 with the temporary file A of the synthesized document and the temporary file B of the schema, and checks the validity of the document structure of the synthesized document. That is, the document parser unit 46 reads the temporary file A of the composite document and the temporary file B of the schema, and checks whether the document structure of the composite document matches the document structure defined by the schema.
[0159]
For example, when the validity check is performed on the composite document shown in FIG. 22 and the schema shown in FIG. 23, the composite document includes an element “A” that is not defined by the schema. In the case of 23 composite documents, an error occurs in the validity check (step S11). In this case, a message “document storage failure” is returned to the client terminal via the document storage unit 21 and the result processing unit 12 (step S12).
[0160]
For example, a message as shown in FIG. 35 is displayed on a predetermined display device of the client terminal.
[0161]
Next, when the structured document database is in the state shown in FIG. 14, an additional command “appendXML (“ uix: // root / patent DB ”,“ <patent>... / Patent> ”)” is accepted. The case will be described with reference to FIG. In the same manner as described above, the object ID “# 2” of the document object Ox0 is acquired (step S5). Since this document object has a schema (step S8), a composite document is created in step S9.
[0162]
In this case, since the link from the “# 2” node itself, which is the document object Ox0, to the node (“# 3” node) having the “Schema” tag at the top (the top) is established, the “# 2” node Becomes the document object Ox1 (step S21 in FIG. 21). That is, since the document object Ox0 and the document object Ox1 are the same (step S22), the process proceeds to step S29, and the document object tree of the stored document “<patent>... </ Patent>” is converted into an XML document and output to the temporary file A. (Step S29).
[0163]
For example, as shown in FIG. 24, “patent” information that is a stored document, that is, “<patent>... / Patent>” is output to the temporary file A (“tmp000.xml”). Yes. In addition, “xmlns =” x-schema: tmp001. There is a description of link information to the temporary file B (“tmp001.xml”), “xml” ”.
[0164]
Next, the process proceeds to step S28. As shown in FIG. 25, the temporary file B is output as a result of converting a document object tree having a schema whose top node is the “# 3” node into an XML document.
[0165]
When the validity check is performed on the composite document shown in FIG. 24 and the schema shown in FIG. 25 in step S10 in FIG. 20, the document structure of the composite document and the document structure defined by the schema are: In this case, the process proceeds from step S11 to step S13.
[0166]
In step S13, the document object tree of the stored document is added under the document object Ox0. That is, the document storage unit 21 assigns an object ID to each document object (file) constituting the document object tree of the stored document, and a link is established from the document object Ox0 to the first document object of the stored document document tree. It is done. Then, the document object tree storage unit 41 stores each document object (file) constituting the document object tree of the stored document in the document storage unit 5.
[0167]
Next, it progresses to step S14 and the index of the index memory | storage part 6 is updated.
[0168]
If the attribute value of the document object Ox0 is “0” in step S8, the process proceeds directly to step S13 without checking the validity of the document structure of the composite document using the above-described schema. Then, the document object tree of the stored document is added under the document object Ox0 (step S13), and accordingly, the index of the index storage unit 6 is updated (step S14).
[0169]
(1-2) Document acquisition processing
Next, the document acquisition processing operation of the structured document management system of FIG. 1 will be described with reference to the flowchart shown in FIG.
[0170]
When one of an acquisition command and a schema acquisition command is transmitted as a document acquisition request from the client terminal to the structured document management system and received by the request reception unit 11, the processing operation shown in FIG. I do.
[0171]
For example, when the user selects (clicks) “patent DB” in the area W1 on the document storage / deletion screen as shown in FIG. 36 with a mouse or the like (“click”), the structured document path input area W2 displays “uix: // root / patent DB ”is displayed, and an acquisition command“ getXML (“uix: // root / patent DB”) ”is transmitted to the structured document management system.
[0172]
Here, for example, a case where the acquisition command “getXML (“ uix: // root / patent DB ”)” is received when the structured document database is in the state shown in FIG. 8 will be described as an example.
[0173]
When receiving the acquisition command, the request reception unit 11 passes the structured document path “uix: // root / patent DB”, which is a parameter in the acquisition command, to the document acquisition unit 22 (step S31).
[0174]
The document acquisition unit 22 passes the structured document path from the path to the document object tree acquisition unit 45. The document object tree acquisition unit 45 from the path specifies the physical area in the document storage unit 5 from the structured document path, and thereby the node (document object Ox5) represented by the structured document path existing in that area. ) Is taken out (step S32). If the structured document path is specified correctly, the object ID of the document object Ox5 can be acquired (step S33). In this case, the process proceeds to step S35.
[0175]
For example, in the case of the above acquisition command, the “# 2” node becomes the document object Ox5. Therefore, “# 2” is acquired as the object ID, and the document object tree Ot5 (“#” below this “# 2” node is acquired. 2 ”node,“ # 42 ”node to“ # 49 ”node,“ # 52 ”node and below,“ # 62 ”node and below) are acquired (step S35).
[0176]
In step S32, if the corresponding document object Ox5 is not found from the designated structured document path, an error occurs (step S33), and the document acquisition unit 22 and the result processing unit 12 notify the client terminal that “document acquisition failed. Is returned (step S34).
[0177]
The document object tree Ot5 acquired in step S35 is converted into an XML document by the document character string acquisition unit 44. For example, in the case of the above acquisition command, the acquired XML document is an XML document of three “patent” information as shown in FIG.
[0178]
The document acquisition unit 22 returns the XML document as shown in FIG. 11 via the result processing unit 12 (for example, along with a predetermined style sheet such as XSL (extensible Style Language)) to the client terminal (step S37).
[0179]
In the client terminal, the XML document shown in FIG. 11 is converted into HTML data using a style sheet and displayed in the area W2, for example, as shown in FIG.
[0180]
Using XSL, XML documents can be converted into various forms. It can be converted into an XML document with a different syntax, and an HTML page can be generated from the XML document.
[0181]
(1-3) Document deletion processing
Next, the document deletion processing operation of the structured document management system of FIG. 1 will be described with reference to the flowchart shown in FIG.
[0182]
When a deletion command is transmitted as a document deletion request from the client terminal to the structured document management system and received by the request receiving unit 11, the processing operation shown in FIG. 27 is performed.
[0183]
For example, when the user selects (clicks) “patent DB” in the area W1 on the document storage / deletion screen as shown in FIG. 36 with a mouse or the like (“click”), the structured document path input area W2 displays “uix: // root / patent DB ”is displayed. When the“ delete ”button B2 is selected, a delete command“ removeXML (“uix: // root / patent DB”) ”is transmitted to the structured document management system.
[0184]
Here, for example, when the structured document database is in the state shown in FIG. 14, a delete command “removeXML (“ uix: // root / patent DB / patent [0] / application date ”)” is accepted. A case will be described as an example.
[0185]
Upon receiving the delete command, the request receiving unit 11 passes the structured document path “uix: // root / patent DB / patent [0] / application date”, which is a parameter in the delete command, to the document deleting unit 23. (Step S41).
[0186]
Next, the document deletion unit 23 passes the structured document path from the path to the document object tree acquisition unit 45. The document object tree acquisition unit 45 from the path specifies the physical area in the document storage unit 5 from the structured document path, and thereby the node (document object Ox0) represented by the structured document path existing in that area. ) Including the document object tree is extracted (step S42). If the structured document path is specified correctly, the object ID of the document object Ox0 can be acquired (step S43). In this case, the process proceeds to step S45.
[0187]
For example, in the case of the delete command, since the “# 44” node becomes the document object Ox0, “# 44” is acquired as the object ID, and the document object tree including the “# 44” node (for example, “ All descendant nodes of the “# 44” node, all (sibling) nodes in the same hierarchy as the “# 44” node, the “# 42” node that is the parent node of the “# 44” node, and the parent node “ Document object tree (# 2) node is acquired.
[0188]
If the corresponding document object Ox0 is not found from the designated structured document path, an error occurs (step S43), and a message “document deletion failure” is sent to the client terminal via the document storage unit 21 and the result processing unit 12. A message is returned (step S44).
[0189]
Next, in step S45, it is checked whether or not a schema exists in the document object Ox0. As described above, since this attribute value is described in the file of each document object, this value may be checked. When the attribute value of the document object Ox0 is “1”, the process proceeds to step S46.
[0190]
In the following, the processing in step S46 in FIG. 27 (processing by the composite document creation unit 47 (for deletion command)) will be described in detail with reference to the flowchart shown in FIG.
[0191]
In FIG. 28, the same parts as those in FIG. 21 are denoted by the same reference numerals.
[0192]
The document storage unit 21 passes the document object tree acquired in step S42 to the composite document creation unit 47.
[0193]
The composite document creation unit 47 goes back from the document object Ox0 and searches for the document object Ox1 having the “Schema” tag as a child element (step S21).
[0194]
For example, in the structured document database shown in FIG. 14, a node (“# 3”) having a “Schema” tag at the top from the “# 2” node upstream of the “# 44” node as the document object Ox0. Since a link to (node) is established (because it has a “Schema” tag as a child element), this “# 2” node becomes the document object Ox1.
[0195]
The document object Ox0 is traced from this document object Ox1, and the arc is further traced from the document object Ox0, and a document object tree Ot1 composed of all the child nodes whose attribute value is “1” downstream from the document object Ox0 is extracted ( Step S23).
[0196]
For example, when the structured document path of the parameter in the additional command is specified as “uix: // root / patent DB / patent [0] / application date”, the document object tree Ot1 includes a “# 42” node. To "# 49" nodes (see FIG. 14).
[0197]
In step S26, the document object tree below the document object Ox0 is deleted from the document object tree Ot1. The new document object tree obtained as a result is set as a document object tree Ot2.
[0198]
This document object tree Ot2 is converted into an XML document, which is output to a temporary file A (step S27).
[0199]
For example, the document object tree below the “# 44” node indicated by the structured document path “uix: // root / patent DB / patent [0] / application date” of the parameter in the delete command is set to the “# 42” node˜ FIG. 29 shows a result of converting the document object tree Ot2 of the composite document obtained by deleting from the document object tree Ot1 configured with the “# 49” node into an XML document. This composite document is obtained by deleting data “<application date>... </ Application date>” from the original “patent” information.
[0200]
The XML document shown in FIG. 29, that is, the composite document, is output to the temporary file A and temporarily stored in the temporary file A.
[0201]
On the other hand, the document object tree Ot3 below the schema tag is converted into an XML document and output to the temporary file B (step S28). In other words, the schema document is temporarily stored in the temporary file B.
[0202]
For example, FIG. 30 shows a result of converting a document object tree having the “# 3” node as the top node in the document object tree Ot3 into an XML document. The XML document shown in FIG. 30 is output to the temporary file B and temporarily stored in the temporary file B.
[0203]
Next, the description returns to FIG.
[0204]
In step S47, the document deletion unit 21 gives the document parser unit 46 the temporary file A of the composite document and the temporary file B of the schema, and the validity of the document structure of the composite document is the same as in the document storage process. Check.
[0205]
For example, when the validity check is performed with the composite document shown in FIG. 29 and the schema shown in FIG. 30, the composite document does not have an element “application date” defined by the schema. The composite document in FIG. 29 results in an error in the validity check (step S48). In this case, a message “document deletion failure” is returned to the client terminal via the document deletion unit 21 and the result processing unit 12 (step S49).
[0206]
When the structured document database is in the state shown in FIG. 14, if a delete command “removeXML (“ uix: // root / patent DB / patent [0] ”)” is processed according to FIG. 28, the composite document as shown in FIG. 24 is output to the temporary file A in step S27. The temporary file B is the same as that shown in FIG.
[0207]
At this time, when the validity check is performed on the composite document shown in FIG. 24 and the schema shown in FIG. 30, the document structure of the composite document matches the document structure defined by the schema. The process proceeds from step S48 to step S50.
[0208]
In step S50, the document object tree below the document object Ox0 is deleted. That is, the document object tree deletion unit 42 deletes each document object (file) constituting the document object tree below the document object Ox0 from the document storage unit 5. For example, the document object file below the “# 42” node is deleted from the “# 2” node.
[0209]
Next, it progresses to step S51 and the index of the index memory | storage part 6 is updated. Further, “patent [0]” is not displayed in the area W1 of the display screen as shown in FIG. 36 of the client terminal.
[0210]
If the attribute value of the document object Ox0 is “0” in step S45, the process proceeds to step S50 without checking the validity of the document structure of the composite document using the schema described above. The document object tree below the document object Ox0 is deleted (step S50), and the index in the index storage unit 6 is updated accordingly (step S51).
[0211]
(1-4) Schema setting and document storage using schema
When the user selects “Schema setting Win” on the screen shown in FIG. 31 using a pointing device such as a mouse, a screen as a user interface for setting the schema shown in FIG. 37 is displayed. Is done.
[0212]
For example, when the user inputs a schema of “patent” information as shown in FIG. 12 in the area W3 and sets the input schema to a node below the “patent DB”, the “patent” After selecting “DB” by clicking with the mouse or the like (“ux: // root / patent DB” is displayed in the area W2), the “Schema setting” button B3 is selected. Then, a schema storage command “setSchema (“ uix: // root / patent DB ”,“ <Schema>... </ Schema> ”)” is transmitted to the structured document management system. Processing of this command is the same as the document storage processing operation described above.
[0213]
Next, when storing "patent" information under "uix: // root / patent DB", enter "patent" information using the schema already set in the nodes below "patent DB" The case where it does is demonstrated.
[0214]
First, get the schema. For example, if “schema” is selected from the area W1 of the screen for storing / deleting a document as shown in FIG. 38 by using a mouse or the like, “ux: // root / patent” is entered in the input area W2 of the document path. “DB / # Schema” is displayed, and a schema acquisition command “getXML (“ uix: // root / patent DB / Schema ”)” is transmitted to the structured document management system.
[0215]
Processing of this command is the same as the document acquisition processing described above. The XML document returned from the structured document management system is displayed in the area W3 of the screen in FIG.
[0216]
As shown in FIG. 38, a data input area for “patent” information is set and displayed for each element in the area R3. According to this display, the user may input data. For example, data input areas such as “title” and “year” are arranged hierarchically and displayed. The user can easily create a stored document having a document structure defined by the schema by inputting data in the data input area.
[0217]
Further, when “patent DB” is selected in the area W1 using a mouse or the like as the storage destination of the “patent” information input in the area W3, “uix: // root / patent DB” is used as a structured document path in the area W2. Is displayed. Thereafter, when the “Register” button B1 is selected, an additional command “appendXML (“ uix: // root / patent DB ”,“ <patent>... </ Patent> ”)” is transmitted to the structured document management system. .
[0218]
In this case, since the stored document is input in accordance with the schema in advance, an error does not occur in the validity check in step S10 in FIG.
[0219]
(2) Search function
The search commands in the structured document management system of FIG.
[0220]
query (ql)
“Query” is a command (hereinafter referred to as a search command) that executes the query ql in () as a parameter and acquires the resulting XML document.
[0221]
As shown in FIG. 39, the query is a structured XML document in which a search position, a search condition, an information extraction portion, and the like are described in a language similar to SQL (Structured Query Language). The query document is also a management target of the structured document management system of the present invention.
[0222]
The element starting from the “kf: from” tag has a description for associating a variable with the specification of the search position and the value of the document element, and the element starting from the “kf: where” tag has a description of conditioning regarding the variable , The output format of the search result is described in the element starting from the “kf: select” tag.
[0223]
Search includes simple search and concept search. Simple search searches and extracts information that satisfies the search conditions specified in the query, and concept search uses the concept information specified in the query to search specified in the query. It searches and extracts information that satisfies the conditions.
[0224]
FIG. 40 shows an example of a simple search query. The query shown in FIG. 40, for example, in the “patent” information document group stored below the node indicated by the “patent DB” arc in the structured document database in the state shown in FIG. In addition, this means a search request “list enumeration of“ titles ”of documents (“ patent ”information) having an element of“ summary ”such as“ PC ”.
[0225]
Document elements of “Title”, “Year”, and “Summary” of “Patent” information are respectively added to the variables “$ t”, “$ y”, and “$ s” by the description of the element that starts with the “kf: from” tag. The value of is assigned.
[0226]
The variable “$ y” = “1999” is compared based on the description of the element starting from the “kf: where” tag. The component “MyLike” is a function for detecting the variable “$ s” having a value similar to “PC” with the variables “$ s” and “PC” as arguments.
[0227]
The variable “$ t” is used as the output value by the description of the element starting from the “kf: from” tag.
[0228]
The “kf: star” tag is an ambiguous expression of the structure. For example, “<patent><kf:star><year>” exists as a descendant element of an element whose tag name is “patent”. And an element whose tag name is “year”.
[0229]
FIG. 41 shows a search result using the simple search query of FIG. This search result (search result document) is also an XML document. This search result document is a document structure document according to the output format of the search result described in the element starting from the “kf: select” tag, and a structured document database that satisfies the search conditions specified in the query. It may be generated by synthesizing the components inside.
[0230]
FIG. 42 shows an example of a query for concept search. The query shown in FIG. 42, for example, with respect to a document group of “patent” information stored under the node indicated by the “patent DB” arc in the structured document database in the state shown in FIGS. This is a search request for searching using “concept” information stored under the node indicated by the “concept DB” arc. Here, the values of the child elements of the tag having the value of the concept “peripheral device” include the concepts “SCSI”, “memory”, “HDD”, and the like. Further, although not shown in FIG. 18, it is assumed that elements of each “patent” information include elements starting from “keyword” tags.
[0231]
That is, the query of FIG. 42 means a search request “list enumeration of“ titles ”of documents (“ patent ”information) having any of the concepts below“ peripheral devices ”as the value of the element“ keyword ”. is doing.
[0232]
By the description of the element starting from the “kf: from” tag, the values of the elements “title” and “keyword” of the “patent” information are substituted into the variable “$ t” and the variable “$ k”, respectively. The variable “$ x” is substituted with the values of tag child elements (“SCSI”, “memory”, “HDD”, etc.) having the value of “peripheral device” as “concept” information.
[0233]
A comparison of “$ k” = “peripheral device” or “$ k” = “$ x” is made based on the description of the element starting from the “kf: where” tag.
[0234]
Next, the document search processing operation of the structured document management system of FIG. 1 will be described with reference to the flowchart shown in FIG.
[0235]
When the user selects “XML search Win” using a pointing device such as a mouse on the screen shown in FIG. 31, a screen as a user interface for performing a document search as shown in FIG. 44 is displayed. .
[0236]
In the search screen of FIG. 44, the element name (tag name) of the current tree structure of the structured document database is simply displayed in the area W1 so that the user can understand, as described above.
[0237]
The area W2 is an area for inputting a search target range (search range on the tree structure), search conditions, and the like. A search result is displayed in the area W3.
[0238]
For example, among documents having “patent” under “uix: // root” as the first tag, a document created after “1998” including the character string “document” in the “title” tag is created. In the case of a search request “search,” “root” is selected from the area W1 with a mouse or the like, and a structured document path is input as a search target range. Then, “patent” is input as the top node (in this case, “patent” may be input from the area W1 by selecting with a mouse or the like). Further, as a search condition, a data input area in which contents of “the element value“ title ”includes the character string“ document ”” and “the value of the element“ year ”is“ 1998 ”or more” are set in advance. You can enter in
[0239]
Thereafter, by selecting the “search” button B21, for example, a query as shown in FIG. 45 is transmitted to the structured document management system together with an additional command for storing the query on the structured document database. The storage location of the query is determined in advance, and the system side automatically sets the parameter of this additional command. For example, when the structured document database is in the state shown in FIG. 18, the structured document path as a parameter indicating the storage location of the query is “uix: // root / query DB”. The other parameter of the additional command is the query document.
[0240]
When receiving the query (step S101), the request receiving unit 11 passes the query to the search request processing unit 3. Then, the parameter of the additional command for storing the query document is passed to the document storage unit 21. This additional command is processed in the same manner as described above, and the query is stored in the document storage unit 5.
[0241]
For example, in the case of the query as shown in FIG. 42, the “# 301” node indicated by the structured document path “uix: // root / query DB” is expanded in the structured document database as shown in FIG. Linked to:
[0242]
On the other hand, the search request processing unit 3 accesses the index storage unit 6 and the document storage unit 5 through the data access unit 4 based on the received query, acquires a document set that matches the search request, etc. The requested information is extracted and output via the result processing unit 12.
[0243]
For example, in the case of the above query, it is efficient to narrow down the search target by first searching for a query that satisfies the condition “character string“ document ”is included in the“ title ”tag” ”. Therefore, the object ID of the node (document object) linked to the character string “document” is obtained using the data occurrence index as shown in FIG. Then, for each of them, the document object tree is moved up one upstream, and when the tag name “title” is reached, further upstream is reached. When the tag name “patent” is reached, the node The following document object tree Ot11 is extracted.
[0244]
Next, a document object tree Ot12 whose element value “year” is “1998” or more is extracted from the extracted document object trees Ot11.
[0245]
This document object tree Ot12 is a document that matches the contents of the query. Further, according to the request contents of the query, a structured document path to the top node of each document object tree Ot12 is obtained (step S102).
[0246]
The search process is not limited to the above-described method, and various efficient search methods using index information are possible.
[0247]
The search request processing unit 3 integrates the results obtained in step S102 and creates an XML document as a search result (step S103).
[0248]
For example, the XML document of the search result is

It becomes.
[0249]
The search request processing unit 3 returns the XML document together with the style sheet to the requesting client terminal via the search result processing unit 12 (step S104).
[0250]
In the client terminal, the XML document shown in FIG. 11 is converted into HTML data using a style sheet, and displayed in the area W12, for example, as shown in FIG.
[0251]
Similarly, a schema can be searched.
[0252]
For example, in the case of a search request “search for a schema having tag names“ patent ”and“ summary ”from documents having“ schema ”below“ uix: /// root ”as the first tag, As shown in FIG. 47, “root” is selected from the area W1 with a mouse or the like, and a structured document path is input as a search target range. Then, “#schema” is input as the top node. In addition, if a search condition is entered in the data input area set in advance, the contents of “element attribute name includes character string“ patent ”” “element attribute name includes character string“ summary ”” Good.
[0253]
Thereafter, by selecting a “search” button B21, the query describing the search request (see FIG. 48) is transmitted to the structured document management system together with an additional command for storing the query on the structured document database. Is done.
[0254]
In the case of the above query, for example, a search is made that matches the condition of “having“ #schema ”as the first tag”. Therefore, using the element name occurrence index as shown in FIG. 9, the object ID of the (document object) of the node linked to the element “#schema” is obtained. Then, for each of them, the arc is traced downstream in the document object tree, and when the attribute name reaches the elements “patent” and “summary”, the document object tree having “#schema” as the top tag Extract Ot21. This document object tree Ot21 is a document that matches the contents of the query. Further, according to the request contents of the query shown in FIG. 48, a structured document path to the top node of each document object tree Ot21 is obtained.
[0255]
If there are a plurality of document object trees Ot21, the search request processing unit 3 collects structured document paths to the respective top nodes, creates an XML document as a search result, and passes the search result processing unit 12 through the search result processing unit 12. The XML document is returned to the requesting client terminal together with the style sheet.
[0256]
In the client terminal, the XML document received as the search result is converted into HTML data using a style sheet, and displayed in the area W12 as shown in FIG. 44, for example.
[0257]
In the client terminal, when one schema in the search result is selected and displayed, for example, the “patent” information is displayed in the area W3 together with a screen for storing / deleting a document as shown in FIG. The data input area is set and displayed for each element.
[0258]
The user can easily create a stored document having a document structure defined by the schema by inputting data in the data input area.
[0259]
For example, when “patent DB” is selected in the area W1 using a mouse or the like as the storage destination of the “patent” information input in the area W3 in FIG. 38, “uix: /// root” is used as a structured document path in the area W2. / Patent DB ”is displayed. Thereafter, when the “Register” button B1 is selected, an additional command “appendXML (“ uix: // root / patent DB ”,“ <patent>... </ Patent> ”)” is transmitted to the structured document management system. .
[0260]
In this case, since the stored document is input in accordance with the schema in advance, an error does not occur in the validity check in step S10 in FIG.
[0261]
Similarly, queries can be searched. It is also possible to search for a query, process an existing query obtained as a search result, and reuse the query (reuse of query).
[0262]
The query search is performed in the same manner as the structured document search described above, and the search range is a partial document object tree on the structured database in which the query group is stored.
[0263]
For example, a case will be described in which a query including “patent DB” in the “kf: from” tag is searched from the structured document database in the state shown in FIG. A query describing such a search request is shown in FIG.
[0264]
The query shown in FIG. 49 searches for a query including “patent DB” in the “kf: from” tag from queries existing under the “# 301” node indicated by “uix: // root / query DB”. , Enumerate its contents (document object tree documents below the element whose tag name is “query”) ”.
[0265]
The document object tree below the element whose query tag name is “query” including “patent DB” in the “kf: from” tag is substituted into the variable “$ elt” in the contents of the “kf: as” tag. The
[0266]
When the search request processing unit 3 processes this query, in the same manner as described above, for example, a node linked to an element “kf: from” using an element name occurrence index as shown in FIG. The object ID of (document object) is obtained. Then, for each of them, the arc was traced downstream in the document object tree, and when the tag name “patent” was reached, the arc was traced further upstream to the tag name “query”. At this time, the document object tree Ot31 having the “query” as a head tag is extracted. This document object tree Ot31 is a document that matches the contents of the query.
[0267]
When a plurality of document object trees Ot31 are retrieved, they are integrated to create an XML document, which is returned to the client terminal together with the style sheet.
[0268]
In the client terminal, when one query in the search result is selected and displayed, for example, the query is displayed in the data input area in the area W11 of the search screen shown in FIG. The contents of the search request described in is displayed.
[0269]
From this state, the user includes the character string “document” in the “title” tag from among documents having “patent” below “uix: // root” as the top tag, and after “1998”. If “document” in the search request described in the query “search the created document” is changed to “XML”, and the “search” button B21 is selected, “uix: // root” or less A query that means “search for documents created after“ 1998 ”containing the character string“ XML ”in the“ title ”tag from among documents having“ patent ”in the top tag” is a structured document. Sent to the management system.
[0270]
As described above, in the structured document management system in FIG. 1, a large number of XML document groups (content documents, schema documents, query documents, etc.) having different document structures registered in the structured document database are displayed. 18. As shown in FIG. 19, it is handled as one large XML document in the form of a tree having a “root” tag at the head. Accordingly, it is possible to easily search for a document that matches the search condition from among a large number of documents having different schemas and different schemas.
[0271]
Further, since the query used for the search is also a structured document, an application that reuses a past query can be easily constructed by storing the query in the structured document database as a log.
[0272]
(3) Application examples
Next, an application example of the concept search to patent search will be described.
[0273]
FIG. 50 shows an example of a structured document database in patent research, in which “concept” information is stored in addition to “patent” information.
[0274]
In patent research, the most important task is to collect related “patent” information, analyze the “patent” information from various viewpoints, and create a patent map (see FIG. 54). Conventionally, in order to create a patent map, the vertical axis and the horizontal axis in the patent map are determined in advance, and in accordance therewith, a search is sequentially performed using an arbitrary item aligned on the vertical axis and an arbitrary item aligned on the horizontal axis. The method of doing was taken and this part was very expensive. However, by using the structured document management system of the present invention, the cost of this part can be greatly reduced.
[0275]
Here, the map refers to a search result using an arbitrary item arranged on the vertical axis (y axis) and an arbitrary item arranged on the horizontal axis (x axis) as a search condition, and the x axis and the y axis are classified axes. It is classified and arranged as.
[0276]
In the structured document management system of the present invention, when a user of a client terminal tries to create a patent map as shown in FIG. 54, the user has a structure as shown in FIG. 50 displayed on the display device on the client terminal. Referring to the current tree structure of the document database, on the search screen as shown in FIG. 51, the path of “patent” information to be analyzed and the analysis axes (for example, x-axis and y-axis) Are input to the areas W21 and W22, respectively. The element serving as the axis of analysis may be either “patent” information element or “concept” information element in the structured document database.
[0277]
For example, in FIG. 51, elements of “concept” information, “function” on the x-axis and “technology” on the y-axis, are input.
[0278]
Thereafter, when the user selects the “execute” button B31, a query as shown in FIG. 52 is sent from the client terminal to the structured document management system of FIG.
[0279]
In the query in this case, the concept “stored in the node indicated by the“ concept DB ”arc from the document group of the“ patent ”information stored in the node indicated by the“ patent DB ”arc is stored. Search for “patent” information that includes one of the child elements of “function” and one of the child elements of the concept “technology” in the values of elements such as “keyword” and “summary”. As a search result, list a set of “function” child elements, “technology” child elements, and “patent” information “publication numbers” corresponding to them. Is a search request meaning "."
[0280]
The concept “function” has child elements “search”, “storage”… “analysis support”, and the concept “technology” has child elements “implementation database”, “anti-structure database”, “natural language processing”, etc. It shall be.
[0281]
The search request processing unit 3 of the structured document search system that has received the query is linked to each child element (character string) of the concept “function” using, for example, a data occurrence index as shown in FIG. Get the object ID of the node (document object). Then, for each of them, when the document object tree is traced back to the upstream side and the tag “patent” is reached, the document object tree below that node is further traced downstream and the child element (character) of the concept “technology” When the tag name linked to one of the columns is reached, the document object tree and the character string (element value) linked to the “public number” tag are extracted. In this way, for each of the extracted “patent” information, the corresponding “function” child element, “technical” child element, and “public number” pair are integrated, as shown in FIG. An XML document as a search result is created and returned to the requesting client terminal together with a predetermined style sheet.
[0282]
Upon receipt of these, a tabular patent map as shown in FIG. 54 is displayed on the display device of the client terminal.
[0283]
In this way, simply by specifying the desired concept as an “axis”, the information stored in the structured document database can be aggregated and classified based on the concept specified as the “axis” and displayed on a map. Yes. That is, the information stored in the structured document database can be easily aggregated and classified from various viewpoints using “concept” information.
[0284]
(Access authority setting)
Here, the case of the usage mode shown in FIG. 2 (the usage mode in which the structured document management system 100 having the configuration shown in FIG. 1 operates in the back end of the WWW) will be described as an example. That is, as shown in FIG. 2, the WWW browser 103 is operating in each of a plurality of (for example, three) client terminals 102, and the user accesses the WWW server 101 from each client terminal. The structured document management system 100 can be accessed.
[0285]
Requests such as document storage, document acquisition, and document search from the user are transmitted from the WWW browser 103 and received by the structured document management system 100 through the WWW server 101, and processed results are requested through the WWW server 101. A reply is sent to the original WWW browser 103.
[0286]
A configuration example of a main part of the client terminal apparatus 102 is shown in FIG.
[0287]
It is assumed that the XML document as the query execution result is sent from the structured document management system 100 to the client terminal device 102 together with the style sheet. Hereinafter, processing operations of the components shown in FIG. 55 will be described with reference to flowcharts shown in FIGS.
[0288]
As described above, the query is a structured XML document describing a search position, a search condition, an information extraction part, and the like. The query document is also a management target of the structured document management system of the present invention. Here, a query for searching for a desired component based on the logical structure of the structured document database will be described as an example.
[0289]
When the XML document receiving unit 111 receives the XML document to be displayed, which is the search result document sent from the structured document management system 100, and the style sheet (step S201 in FIG. 56), the XML / HTML conversion unit 112 is received. In step S202, the received style sheet is used to convert the received XML document to be displayed into an HTML document. During the conversion process, the table creation unit 113 creates a table showing the correspondence between the description part in the HTML document and the description part in the style sheet that generated the description part, that is, the correspondence table 114 (step S203, step S204).
[0290]
Assume that an identifier SID is given in advance to each description portion of the style sheet sent from the structured document management system 100. For example, this identifier SID may be written in the style sheet in advance as a comment sentence (a sentence in a description format that is not displayed in the browser even if it is not a comment sentence).
[0291]
First, the table creation unit 113 gives an identifier HID to each description portion of the obtained HTML document during the conversion work in the XML / HTML conversion unit 112. Then, a correspondence table 114 is created in which the correspondence between the description portion in the HTML document and the description portion in the style sheet that generated the description portion is expressed using SID and HID.
[0292]
The drawing unit 115 creates display data based on the HTML document generated by the XML / HTML conversion unit 112, and the display data is displayed on the display device 121 (step S205). At that time, the drawing unit 115 may store the correspondence between the description part in the HTML document and the identifier HID given to the description part.
[0293]
The access authority is set based on the display screen of the display device 121.
[0294]
For example, when the user performs a predetermined instruction operation for starting setting of access authority with the input unit 116, the access authority setting unit 117 is activated. First, an area for setting access authority is selected on the display screen (step S111). In other words, using the input device 122 such as a mouse, a display area such as a character string (text) or image for which access authority is to be set is selected on the display screen of the display device 121 on which a display target document is displayed.
[0295]
If a display area to which access authority is to be set is selected with a mouse or the like, the drawing section 115 can detect a description portion in an HTML document that displays a character string, an image, or the like in the designated area. The identifier HID corresponding to the description portion in the detected HTML document is passed to the access authority setting unit 116 (step S112).
[0296]
The access authority setting unit 116 refers to the correspondence table 114 from the identifier HID of the description portion in the HTML document detected by the drawing unit 115, and obtains the identifier SID of the description portion of the style sheet corresponding to the identifier HID ( Step S113).
[0297]
Further, the access authority setting unit 117 of the client terminal apparatus 102 displays an input screen for allowing the user to input the range of the user to which the access authority is set, the access level, the access type, etc. Each of the above-mentioned information necessary for setting is collected (steps S114 to S116). When the input of each information is completed, they are transmitted to the structured document management system 100 via the transmission unit 118 together with the identifier SID (step S117).
[0298]
Of the components shown in FIG. 55, components other than the table creation unit 113, the correspondence table 114, and the access authority setting unit 116 belong to the prior art.
[0299]
Next, the access authority setting management unit 201 in FIG. 1 will be described with reference to FIG. FIG. 58 is a functional block diagram of the access authority setting management unit 201.
[0300]
The access authority setting management unit 201 includes an access authority setting unit 202 and an access authority management unit 201. The access authority setting management unit 201 includes a schema access authority management unit 211, a data access authority management unit 212, and a query access. An authority management unit 213, a style access authority management unit 214, and a path access authority management unit 215 are configured.
[0301]
The access authority setting unit 202 actually accesses the access authority based on information such as the SID, the range of users for which access authority is set, the access level, and the access type transmitted from the client terminal apparatus 102. It is supposed to be set.
[0302]
The access authority management unit 201 manages the access authority of each level (schema, data, query, style, path) set by the access authority setting unit 202.
[0303]
FIG. 59 schematically shows a part of the logical structure of the structured document database. When new XML documents are registered in the structured document database, each XML document can be referred to as a partial document of one large XML document called “root”. In the structured document database shown in FIG. 59, “report” information as an XML document is stored below the “report DB” node, and “employee” information as an XML document is also “employee DB”. The “patent” information as an XML document is stored below the “patent DB” node.
[0304]
FIG. 60 shows one partial document corresponding to the “report” information below the “report DB” node as an example of a structured document described in XML, and FIG. 3 shows three partial documents corresponding to the “employee” information below the “employee DB” node.
[0305]
FIG. 62 shows a screen display example of the display device 121 of the client terminal device 102, and shows a display example of an XML document (search result document) obtained as a result of executing a query input from the client terminal device 102. ing.
[0306]
As described above, the element starting from the “kf: from” tag of the query has a description of associating a variable with the specification of the search position and the value of the document element, and the element starting from the “kf: where” tag relates to the variable. There is a description of conditioning, and an output format of a search result is described in an element starting from a “kf: select” tag. By executing a query, in the case of a simple search, information that satisfies the search conditions specified in the query is searched and extracted, and in the case of a concept search, the concept information specified in the query is used. Search and extract information that satisfies the search conditions specified in the query. Then, the search request processing unit 3 synthesizes and processes the extracted information (component) into information in a format according to the element description starting from the “kf: select” tag, and the resulting XML document is processed. The result is sent together with a predetermined style sheet to the requesting client terminal device 102 via the result processing unit 12. The request source client terminal device 102 displays an XML document (search result document) as a query execution result sent from the structured document management system 100 as shown in FIG. 62 according to the flowchart of FIG. Depending on the description of the search condition in the query, the search result document may be a processed document generated from a plurality of structured documents in the structured document database as described above. It may be the structured document itself.
[0307]
In this state, the client terminal apparatus 102 can set access authority.
[0308]
An outline of an operation procedure for setting access authority on the client terminal apparatus 102 will be described.
[0309]
(A) Designate (select) a displayed area of a character string or image for which access authority is to be set from the display screen. Here, the designated character string, image, or the like corresponds to the element name or element value of the element constituting the XML document in the structured document database.
[0310]
(B) Designate (select) a range of users to set access authority. It is assumed that the access authority can be set for each user, or can be set for a specific group consisting of a plurality of users (for example, for each department in a company organization). The former is called access authority setting for an individual, and the latter is called access authority setting for a group.
[0311]
(C) Specify (select) an access level. Here, the access level includes style, query, data, schema, and path. The style level sets access authority for each style sheet. If the display format is different, the same component may or may not be displayed. In addition, the query level sets the access authority for each query document. When the access authority is set at the query level, even if it is the same component for users whose access is restricted at this level, Depending on the query used to obtain the component (ie, the usage of the component is different), it may or may not be displayed. The data level is used to set access authority for a component in the XML document to be searched that is stored in the structured document database. A user whose access is restricted at this level is assigned to the component. On the other hand, even if the query or style is different, it is inaccessible (not visible). Furthermore, the schema level and the path level are used to set access authority for components with the same element name in a structured document having the same document structure in the structured document database, and users whose access is restricted at this level. From the point of view, such components are inaccessible (not visible) even if the query or style is different.
[0312]
(D) Designates (selects) a display method of data displayed in the area designated in (a) above (referred to here as access mode or access type). As an access type, it can be roughly divided to display nothing in the display area, display it in black, or hide it so that you do not know whether there is data displayed there or not The special display (special display) can be set. The special display is a display in which some data is displayed in the display area so that it cannot be determined what the data is. For example, the special display is displayed in the area specified in (a) above. It is to display a character string, an image, etc. with face-down characters or display with a mosaic. It is possible to select whether to display with a hidden character or to display with a mosaic, etc. Also, when selecting a hidden character, it is possible to select what hidden character is used (for example, “○”, “×”, etc.) is there.
[0313]
As shown in FIG. 62, the XML document to be displayed is displayed on the display screen of the client terminal device 102 as described above. In other words, the “report number”, “title”, “reporter”, “report date”, “summary”, “representative chart”, which are the components of the “report” information, and a link to the text are displayed. , Information such as “reporter profile” which is a component of “employee” information is displayed. As described above, the XML document displayed here is a combination of components included in each of a plurality of search target XML documents stored in the structured document database.
[0314]
The data displayed on the display screen is only display data (for example, in the case of the above example, a combination of components extracted from a plurality of XML documents), and the structured document database includes a display screen. An XML document with a street structure does not exist. Therefore, in the access authority setting management unit 201 of the structured document management system 100, for example, when “data” is designated as the access level by the user, the data in the structured document database is traced back based on the display format. Is specified, and access authority is set.
[0315]
Now, a method of actually setting access authority from the display of FIG. 62 will be described. The display of FIG. 62 is an XML document obtained as a result of combining (processing) the constituent elements of a plurality of XML documents in the structured document database, converted into HTML format through a style sheet, and displayed in a browser. It is a thing. An XML document to be displayed is shown in FIG. FIG. 64 shows the applied style sheet.
[0316]
When the XML document shown in FIG. 63 is converted into an HTML document, as described above, an identifier is assigned to each description part of the HTML document (for example, a character string to be displayed surrounded by a predetermined tag). An HID is given, which is shown in FIG. FIG. 65 shows not the HTML document itself but the same display screen as FIG. 62 that displays what kind of identifier HID is given to what descriptive part in the HTML document for the sake of simplicity. The identifier HID (here, for example, HID1 to HID18) is shown as a code for each description part. Here, one description portion in the HTML document given the identifier HID corresponds to one display area. That is, as shown in FIG. 65, it is assumed that one description portion corresponds to one display window (text box) and an HID is given.
[0317]
In the XML / HTML conversion unit 112 of the client terminal apparatus 102, the style sheet shown in FIG. 64 is applied to the XML document shown in FIG. 63 and displayed as shown in FIG. 65 in step S102 of FIG. An HTML document is created. At that time, as shown in step S203 of FIG. 56, the table creation unit 113 creates a correspondence table 114 as shown in FIG.
[0318]
For example, in FIG. 65, the description part in the HTML document to which the identifier “HID6” is given displays the character string “reporter” in the display area 306 (see FIG. 62), and the identifier “HID7 The description portion in the HTML document to which “is given” displays the character string “Taro Yamada” in the display area 307 (see FIG. 62). These two description parts are generated from the element described in the sixth line of the XML document in FIG. 63 according to the description of the description part given the identifier “SID4” of the style sheet shown in FIG. is there. Therefore, the table creation unit 113 of the client terminal apparatus 102 associates SID4 with HID6 and HID7, as shown in FIG. In the correspondence table of FIG. 66, for each HID, the item “type” indicates whether the element is an element name or an element value in the XML document before conversion. Distinguish.
[0319]
FIG. 88 shows a part of the HTML document corresponding to the display screen shown in FIG. For example, FIG. 65 shows an example of a description portion given identifiers “HID1”, “HID2”, “HID3”, “HID6”, and “HID7”. In these description portions, identifiers “HID1”, “HID2”, “HID3”, “HID6”, and “HID7” are shown as codes.
[0320]
For example, as in the description part of the HTML document shown in FIG. 88 (the description part given the identifier “HID7”) for displaying the character string “Taro Yamada” in the display area 307, the “report” In a description part corresponding to a display area (for example, display area 307) where an element value of an XML document other than item names (which may be element names) such as “report number” and “reporter” is displayed, When such a description portion is instructed (selected) with a mouse or the like, an event function “func ()” for notifying that the display area has been instructed is embedded in the drawing unit 115. .
[0321]
Such function embedding can be instructed by the style sheet shown in FIG. That is, for example, an instruction for embedding the above function in the description portion of the HTML document given the identifier “HID7” is described in the description portion 401 of the style sheet shown in FIG.
[0322]
In this way, by using a well-known style sheet, when converting an XML document to be displayed into an HTML document, one display area is made to correspond to one description part in the HTML document given the identifier HID. When the display area is instructed with a mouse or the like, an event function “func ()” for notifying the drawing unit 115 that the display area has been instructed (selected) can be embedded.
[0323]
The drawing unit 115 can detect which display area is designated (selected) by the user and what the HID of the display area is based on the event function.
[0324]
Now, in the state where the display as shown in FIG. 62 is being performed, when the user performs a predetermined instruction operation for starting setting of access authority via the input unit 116, the access authority setting unit 117 is activated. . First, as shown in step S111 of FIG. 57, an area for setting access authority is selected.
[0325]
For example, a character string “Taro Yamada” on the display screen of FIG. 62 is displayed, and a display area (text box) 307 predetermined for displaying the character string is selected using a mouse or the like. Suppose that The identifier of the description portion in the HTML document for displaying the selected text box is “HID7”. Upon detecting this, the drawing unit 115 passes the identifier “HID7” to the access authority setting unit 116 (step S112 in FIG. 57).
[0326]
The access authority setting unit 116 refers to the correspondence table 114 and acquires the identifier of the description portion in the style sheet corresponding to “HID7” (step S113 in FIG. 57). In this case, “SID4” is obtained from FIG.
[0327]
Next, the user range for setting the access authority is selected (step S114 in FIG. 57). At this time, the access authority setting unit 116 may display a window as shown in FIG. On this window, the user selects an individual or a group, and when selecting an individual, a user name for specifying the individual may be further selected. Here, for example, it is assumed that an individual “Taro Yamada” is selected as the user range.
[0328]
Next, an access level is selected (step S115 in FIG. 57). At this time, the access authority setting unit 116 may display a window as shown in FIG. On this window, the user may select any of style, query, data, schema, and path.
[0329]
Further, the access type is selected (step S116 in FIG. 57). At that time, the access authority setting unit 116 may display a window as shown in FIG. On this window, the user may select either “non-display” or “special display”. When “special display” is selected, any one of a hidden character and a mosaic may be selected.
[0330]
Finally, when the user performs a predetermined operation instructing completion of access authority setting, the information collected as described above is transmitted from the client terminal apparatus 102 to the structured document management system together with the access authority setting request. (Step S117 in FIG. 57). In the structured document management system, when the request control unit 1 receives the access authority setting request, it outputs it to the access authority setting management unit 201.
[0331]
In the access authority setting request, for example, the XML document that is the object of setting the access authority in the client terminal device 102 (the display object), the style sheet used when displaying the XML document on the screen, and the XML document are displayed. It is desirable that information for specifying the query used for obtaining is included.
[0332]
Next, the processing operation of the access authority setting management unit 201 will be described with reference to the flowcharts shown in FIGS.
[0333]
When the SID, the user range, the access level, and the access type sent from the client terminal device 102 together with the access authority setting request are input to the access authority setting management unit 201 (step S121), first, the access authority setting is performed. Based on the request, the path of the element in the XML document to be displayed associated with the description part corresponding to the SID in the style sheet specified in the access authority setting request is acquired (step S122). For example, in step S111 of FIG. 57, the display area corresponding to the description portion in the HTML document with the identifier “HID7” is selected, and the description in the style sheet shown in FIG. 64 corresponding to the identifier “HID7” is selected. It is assumed that the part identifier “SID4” is input in step S121 of FIG. At this time, the description portion with the identifier “SID4” in the style sheet shown in FIG. 64 is “<xsl: value-of select =“ / reporter / name ”/>”. In this description part, ““ / reporter / name ”/” represents a part of the path of the element in the XML document (search result document) to be displayed. Further, when the style sheet is traced to the upper line from the description part with “SID4”, the description part with “SID1” has an upstream of ““ / reporter / name ”/”. As the path, “” / report list / report / “” is described. Therefore, the path of the element in the XML document to be displayed associated with the description part corresponding to “SID4” of the style sheet is “” / report list / report / reporter / name ””. I know that there is. In the above example, “Taro Yamada” is displayed in the display area corresponding to the description portion in the HTML document with the identifier “HID7”. Therefore, an element identified by a path “” / report list / report / reporter / name ”whose element value is“ Taro Yamada ”is an access authority in the search result document. Is a location (component) for setting. Based on this, the structured document database is searched according to the designated access level.
[0334]
When the access level is designated as style (step S123), the access authority setting unit 202 stores the style access authority as shown in FIG. 72 stored in the style access authority management unit 214 of the access authority setting management unit 203. The designated access authority is registered in the table (step S124). As shown in FIG. 72, the style access authority table is a description part in which access authority is set in each style sheet for each of the style sheet identifiers for identifying which style sheet is a plurality of types. SID, user range, and access type are registered. For example, if the identifier of the style sheet for which the access authority is to be set is “SSID 1”, the description part with the identifier “SID 4” in the style sheet is assigned to the group “group B” as the user range. “Hide” is set as the access right as the access type.
[0335]
If the access level is not style, the process proceeds to step S125.
[0336]
In the above step S122, the element specified by the path “” / report list / report / reporter / name ”in the XML document (search result document) to be displayed and having the element value“ Taro Yamada ” Was acquired. That is, this means that the element described in the sixth line is specified in the XML document to be displayed shown in FIG. 63 (step S125).
[0337]
The XML document shown in FIG. 63 is an XML document obtained by executing a query as shown in FIG. Note that the identifier of the query shown in FIG. 77 is “QRY1”. Therefore, a resource in the structured document database is searched based on this query.
[0338]
Next, the query is analyzed, and a description portion corresponding to the element path obtained in step S125 is acquired from the query (step S126). For example, a query analysis method will be described with reference to the query shown in FIG. 77 and the XML document shown in FIG. 63 obtained by executing this query. It is assumed that an identifier QID is given in advance to each description part of all queries stored in the structured document database.
[0339]
First, it is understood that the path in the XML document of the element “<name> Taro Yamada </ name>” described in the sixth line of FIG. 63 is “report / reporter / name”. Therefore, focus on the part that creates this element in the query. This can be understood by examining the description part of the query output format, that is, the description part enclosed by the <kf: select> tag. In this case, in FIG. 77, the description that created the element “<name> Taro Yamada </ name>” from the description format (document structure) defined in the description section enclosed by the <kf: select> tag. It can be easily determined that the part is “<name> $ name </ name>” with the identifier “QID5”.
[0340]
When the access level is designated as a query (step S127), the access authority setting unit 202 stores the query access authority as shown in FIG. 73 stored in the query access authority management unit 213 of the access authority setting management unit 203. The designated access authority is registered in the table (step S128). As shown in FIG. 73, the query access authority table includes, for each query identifier for identifying which of a plurality of types of queries, a QID indicating a description portion in which the access authority is set in the query. User range and access type are registered. For example, in the case of the above example, if the identifier of the query whose access authority is to be set is “QRY1”, “Group B” as the user range for the description part with the identifier “QID5” in the query. In this group, “hidden” is set as the access right as the access type.
[0341]
Next, based on the description of the query, the element (path) where “<name> Taro Yamada </ name>” stored in the structured document database, that is, “<name> Taro Yamada </ name>” is stored. Search is performed (step S129). Here, first, a description portion in which the variable “$ name” is associated as an element value is searched from the description portion surrounded by <kf: from> tags in the query. In this case, in the description part of the 16th and 22nd lines, the variable “$ name” is associated with each element value of the elements “reporter” and “name”. That is, the description part “<name> $ name </ name>” with “QID5” is added to the “” ux: // root / report DB ”in the description part enclosed by the <kf: from> tag. "<Reporter> $ name </ reporter>" and "" ux: // root / employee DB "" and below "<name> $ name </ name>" are output as output results. It turns out that it is the description for doing. Further, since the variable “$ name” is text and “Taro Yamada” is designated, the path in the database is further searched on the condition.
[0342]
Therefore, the access authority setting unit 202 is referred to as “reporter” having a value of “Taro Yamada” from “structured under the“ uix: // root / report DB ”” of the structured document database as shown in FIG. A query for searching for a path of a component and a “name” having a value of “Taro Yamada” from “under” uix: // root / employee DB ”in the structured document database as shown in FIG. A query for searching for a path to a component having an element name “is generated (issued), and is sent to the search request processing unit 3.
[0343]
In the case of the above example, the text box displaying the character string “Taro Yamada” of HID7 on the display screen of FIG. 65 is designated as the area for setting the access authority. The query shown in FIG. 78 and FIG. 79 uses a component having the element value “Taro Yamada” as a search condition, but if a text box displaying the character string “reporter” of HID6 is specified. If so, it is not necessary to use a component having the element value “Taro Yamada” as a search condition. That is, there is no need for a description part surrounded by <kf: where> tags.
[0344]
As described above, the search request processing unit 3 searches the structured document database based on the search conditions described in each query. Then, as shown in FIG. 80, the path to the component 301 having the element name “reporter” having the value “Taro Yamada” below ““ uix: // root / report DB ”” and “ The path from “uix: // root / employee DB” to the component 302 with the element name “name” having the value “Taro Yamada” can be acquired.
[0345]
For example, the path of the component 301 is “uix: // root / report DB / report [0] / reporter”, and the path of the component 302 is “uix: // root / employee DB / Employee [3] / Name ”. Only one path is not necessarily searched, and a plurality of paths may be searched in some cases.
[0346]
When the access level is designated as data (step S131 in FIG. 71), the access authority setting unit 202 is stored in the data access authority management unit 212 of the access authority setting management unit 203 as shown in FIG. The designated access authority is registered in the data access authority table (step S132). In the data access authority table, as shown in FIG. 74, the path, user range, and access type acquired in step S130 are registered. For example, in the case of the above example, the path for which the access authority is to be set is “uix: // root / report DB / report [0] / reporter” and is stored in the storage area represented by this path. For the group element (the element value is “Taro Yamada” and the element name “Reporter”) is set to “Group B” as the user range and “Hidden character (○)” is set as the access authority as the access type It will be done.
[0347]
On the other hand, if the access level is designated as a schema (step S133), the process proceeds to step S134 to check whether the schema is set in the path acquired in step S130. For example, when a path “uix: // root / report DB / report [0] / reporter” is acquired in step S130, a component (node) “reporter” identified by this path is obtained. If the attribute value indicating that the schema exists is set in 301 (step S134), the access authority is set for the description portion corresponding to the “reporter” component of the schema document. That is, the access authority setting unit 202 registers the designated access authority in the schema access authority table as shown in FIG. 75 stored in the schema authority management unit 211 of the access authority setting management unit 203 (step S135). ).
[0348]
For example, in the case of the above example, it is assumed that the schema document shown in FIG. 81 is stored under the “report DB” node including the component (node) 301 “reporter”. In the schema document shown in FIG. 81, a description portion corresponding to the component 301 is a portion surrounded by a solid line. In the structured document database, it is assumed that a path for specifying the description portion is, for example, “uix: // root / schema / elementType [4] / name”. In this case, in the schema access authority table, as shown in FIG. 75, a path for specifying a description part corresponding to the component “reporter” of the schema document, that is, “uix: // root / schema / elementType [ 4] / name ", the user range, and the access type are registered. For example, in the case of the above example, the path of the description part (component) of the schema document for which access authority is to be set is “uix: // root / schema / elementType [4] / name”, and is specified by this path. For the described part, “mosaic” as the access type is set as the access authority for the group “group A” as the user range.
[0349]
Thus, by setting the access authority to the schema, the storage area in the structured document database in which this schema is set (for example, in the case of the above example, the storage area below the “report DB” node) is set. The same access authority registered in the schema access authority table is applied to all stored structured documents to which this schema is applied.
[0350]
Now, the access level can also be set for a path. For example, as shown in FIG. 82, a plurality of “report” information (structured documents) is stored under the “report DB” node. Each of the plurality of “report” information has a component (node) having an element name “reporter”. Therefore, when the “reporter” node included in one of the plurality of “report” information is specified in step S130 of FIG. 70, the “reporter” node in all other “report” information. It is also possible to set the access authority. When the access level is designated as pass, the same access authority is set for the “reporter” node in all other “report” information. This effect is the same as when the access authority is set for the schema when the schema is set under the “report DB” node (step S135 in FIG. 71). Accordingly, when the access level is set to schema in step S133, if the schema does not exist in step S134, the process may proceed to step S137. In addition, although not shown in FIG. 71, when the access level is set to pass in step S136, for example, the path “ux: // root / report DB / report [0] / reporter” is used. If the schema is set for the component (node) 301 “reporter” specified in step S135, the process may proceed to step S135.
[0351]
If the access level is designated as “pass” (step S136), the process proceeds to step S137, and the access authority setting unit 202 starts from “Structure document database” “uix: // root / report DB” ”to“ report ”. A query is generated (issued) for searching for the path of the component “user”, and is sent to the search request processing unit 3.
[0352]
As described above, the search request processing unit 3 searches the structured document database based on the search conditions described in the query. Then, it is possible to obtain the paths to the constituent elements having the element name “reporter” under ““ uix: // root / report DB ””. “There is no description” using the element value in the query at this time as a search condition.
[0353]
The access authority setting unit 202 registers the designated access authority in the path access authority table shown in FIG. 76 stored in the path access authority management unit 215 of the access authority setting management unit 203 (step S138). . As shown in FIG. 76, the path access authority table is configured to register the path, user range, and access type acquired in step S137. For example, in the case of the above example, the path for which the access authority is to be set is “uix: // root / report DB / report [1] / reporter”, “uix: // root / report DB / report”. [2] / Reporter ”,... For the elements stored in the storage area specified by these paths (components of the element name“ Reporter ”) as a user range“ Group B ”. Therefore, “hidden character (○)” is set as the access right as the access type.
[0354]
As described above, in the above-described embodiment, the XML document (search result document) to be displayed obtained as a result of searching the structured document database is displayed on the client terminal device 102 by a predetermined style sheet (search result document is displayed in a predetermined display format) The document is converted to an HTML document by applying the conversion rule of the document structure of the search result document used for displaying in (3), and then displayed on the display screen. At the time of conversion, a style sheet that displays one description part of the HTML document in one display area (text box) is applied to the XML document. By designating a desired display area (text box) on this display screen, the drawing unit 115 of the client terminal apparatus 102 (a) specifies the description part of the HTML document displayed in this text box. In addition, the access authority setting unit 116 of the client terminal apparatus 102 refers to the correspondence table 114 and identifies a description portion in the style sheet corresponding to the description portion of the HTML document. Next, (b) after specifying the path of the element in the search result document associated with the description part in the style sheet, (c) description of the output format in the query used to obtain the search result document The description part corresponding to the path is specified from the part. Then, (d) the structured document database is accessed (a query is issued), and a path (path list) of an element in the structured document database associated with the description part is acquired. As described above, when a desired display area is designated by the user, the description portion of the style sheet corresponding to the designated display area and the query in the query corresponding to the designated display area are selected according to the level designated by the user. By sequentially specifying the description part and the elements in the structured document database associated therewith, it is possible to easily set the access authority to the designated level. The user can set the access authority to the components in the structured document database only by designating at least a desired display area and access level on the search result display screen. In addition, the description part of the style sheet, the description part in the query, and the element with the same element name as the corresponding element in the other structured document having the same document structure as the structured document including the element are also supported. Since access authority can be set simply by specifying the level, it is possible to flexibly deal with various applications.
[0355]
The access authority is set by selecting one display area and selecting one level of a style sheet, a query, an element (data), a schema, and a path in the structured document database corresponding to the display area. In the case of setting the access authority to the above, a plurality of display areas are selected at a time, and one of the plurality of levels corresponding to them is selected (the user range and the access type are the same). ) Access authority can be set easily as described above.
[0356]
When access authority is set for a style, the specified user range and access type may be registered in the style sheet itself based on the contents registered in the style authority table. In this case, for example, as shown in the part surrounded by the solid line in FIG. 83, the user range and the access type are written in the description part (description part specified by the SID) for setting the access authority in the style sheet. The client terminal device 102 only needs to have a function that can interpret the description of the access authority at the stage of applying the style sheet.
[0357]
Further, when the access authority is set for the query, the designated user range and access type may be registered in the query document itself based on the contents registered in the query authority table. Also in this case, for example, as shown in the part surrounded by a solid line in FIG. 84, the user range and access type are written in the description part (description part specified by the QID) for setting the access authority in the query document. The search request processing unit 3 only needs to have a function capable of interpreting the description of the access authority when executing the query.
[0358]
Next, a display example of a search execution result using a query after the access authority is set as described above will be described.
[0359]
Here, for example, the display area 307 corresponding to the description part having the identifier “HID7”, the display area 311 corresponding to the description part having the identifier “HID11”, and the identifier “HID13” in FIG. It is assumed that the display area 313 corresponding to the description portion possessed is designated and the access authority for the user range “Taro Yamada” is set. In the display areas 307 and 311, it is assumed that “hiding” is designated as the access type, and “mosaic” is designated as the access type in the display area 313.
[0360]
Furthermore, it is assumed that the access authority is set in the three display areas with the access level designated as “data”. In this case, the user “Taro Yamada” performs a predetermined operation from the client terminal device 102 to access the structured document management system shown in FIG. 1 and perform a search using the query shown in FIG. Suppose you went. The user name “Taro Yamada” is also input to the request control unit 1 and the access authority setting management unit 201 of the structured document management system via the client terminal device 102 when accessing the structured document management system. It is like that.
[0361]
Then, the search result document (XML document) obtained as the search result is displayed on the display screen of the client terminal apparatus 102 as shown in FIG. In other words, the data displayed in the display areas 307 and 311 is displayed with the hidden characters “X” and “◯”. The display area 313 is displayed with a mosaic. Furthermore, the same hidden character “X” as that of the display area 307 is also displayed in the display area 315 displaying the same data as the data displayed in the display area 307. This is because the data (in this case, text) displayed in the display area 307 is a component in the structured document database whose element value is the data, for example, “uix: // root / report DB”. The components stored in the logical storage area represented by the path “/ report [0] / reporter”, and “uix: // root / employee DB / employee [3] / name” This is because the access authority is set for the component stored in the logical storage area expressed by the path.
[0362]
In the search request processing unit 3, for example, when the query shown in FIG. 77 is executed to extract components satisfying the search condition from the structured document database, the search request processing unit 3 communicates with the access right setting management unit 201 to set the access right. A configuration specified by a path “ux: // root / report DB / report [0] / reporter” based on the access authority table as shown in FIG. 74 managed by the management unit 201. It is known that the access authority is set for the element and the component specified by the path “uix: // root / employee DB / employee [3] / name”.
[0363]
The component specified by the path of “uix: // root / report DB / report [0] / reporter” with the access authority set, and “uix: // root / employee DB / The component specified by the path “employee [3] / name” is the search result document specified by the path “report / reporter / name” in the search result document by the query shown in FIG. Used as a component of (bound). At this stage, the access type of the constituent element may be written in the search result document so that it can be interpreted by a predetermined function of the client terminal device 102.
[0364]
Alternatively, when the search request processing unit 3 creates the search result document, the access authority setting management unit 201 refers to the access authority table as to whether or not the access authority is set for the component in the search result document. Thus, the access type and the like may be written in the search result document to which the access authority is set so that it can be interpreted by a predetermined function of the client terminal device 102.
[0365]
The search result document is transmitted to the search request source client terminal device 102 together with the style sheet as shown in FIG.
[0366]
The component of the search result document specified by the path “report / reporter / name” by the style sheet as shown in FIG. 64 is displayed in both display areas 307 and 315 as shown in FIG. As described above, the XML document as the search result document is converted into an HTML document. Although not shown in FIG. 64, the style sheet of FIG. 64 displays the components of the search result document specified by the path “report / reporter / name” as shown in FIG. A conversion rule for converting into an HTML document to be displayed in both areas 307 and 315 is described.
[0367]
Assume that the access level is designated as “style” in the display area 307 and the access authority is set. In this case, it is assumed that the access authority is written in the style sheet as shown in FIG. Further, when the client terminal apparatus 102 converts the search result document into an HTML document, a function for interpreting the description about the access authority in the style sheet is required. The style sheet includes, for example, a user range in the description part for converting the constituent elements of the search result document specified by the path of “report / reporter / name” into an HTML document that is displayed in the display area 307. And the access type are written, but the description regarding the access authority is not written in the description part for conversion into the HTML document displayed in the display area 315. Therefore, as shown in FIG. 86, actual data is displayed in the display area 315 instead of the hidden characters.
[0368]
The user “Taro Yamada” performs a predetermined operation from the client terminal device 102 to access the structured document management system shown in FIG. 1 and perform a search using a query different from the query shown in FIG. Suppose that For example, this query is to retrieve “employee” information that satisfies a predetermined condition from information stored under the “employee DB” node in the structured document database. It is assumed that a search result document obtained as a result of this search is a combination of a plurality of “employee” information that satisfies the predetermined condition.
[0369]
This search result document includes a component specified by the path “uix: // root / employee DB / employee [3] / name” in which access authority is set as described above. Suppose that Then, in the same manner as described above, as shown in FIG. 87, the display area 321 for displaying this component is displayed with the hidden character “x”.
[0370]
However, it is assumed that the access level is designated as “query” in the display area 307 and the access authority is set. That is, the access authority (for the component in the search result document) is set in the description part in the query shown in FIG. 77 corresponding to the component in the search result document corresponding to the data displayed in the display area 307. In this case, since the current query is different from the query shown in FIG. 77, the display area 321 shown in FIG. Is displayed.
[0371]
In this way, by setting the access authority to a level such as a style sheet or query, data that was not displayed when a certain style sheet was used was displayed when another different style sheet was used. It is possible to set flexible access authority such that data that is not displayed in the search result is displayed when another different query is used.
[0372]
As described above, in the above embodiment, the element name or element value of one component is displayed in one display area (text box), and the search result document obtained as a result of the search by the query is displayed. When one of a plurality of display areas on the displayed display screen is selected, a style sheet, a search result document, a search result document, starting from data (element name or element value) displayed in the selected display area In the process of delving into the level of queries and structured documents in the structured document database, access authority is set for the access authority setting target specified by the user. Just specify at least the desired display area and access level on the display screen, and access authority to the components in the structured document database Setup can be performed. In addition, the description part of the style sheet, the description part in the query, and the element with the same element name as the corresponding element in the other structured document having the same document structure as the structured document including the element are also supported. Since the access authority can be set simply by specifying the level, it depends on the usage and display format of the components of the structured document stored in the structured document database (display format when displaying as a search result). , Different content access authority can be set easily.
[0373]
In the above embodiment, the access authority is set on the display screen that displays the document obtained as a result of searching the structured document database using a query. Even when the acquired acquisition command “getXML” is executed, the document below the path specified by the command (all constituent elements) or a part of the document below the specified path When the access authority as described above is set for the element, when displaying a document under the specified path, the component for which the access authority is set is hidden or specially displayed. Or just do it.
[0374]
In the above embodiment, the access type is selected to be either non-display or special display, but other access types include deletion prohibition, editing prohibition, etc. There may be. When setting an access type such as deletion prohibition or edit prohibition that restricts operations on the component itself in the structured document database, the access level set together with this access type is the data level.
[0375]
For example, if deletion prohibition is set as an access type for a component in a structured document database, the component or a logical area (path) in the structured document database containing such a component is specified. Even if the area deletion command is executed, at least the component to which the access authority is set is not deleted. Also, if edit prohibition is set as an access type for a certain component in the structured document database, the element value of the component cannot be rewritten.
[0376]
Note that the method of the present invention described in the embodiment of the present invention includes a magnetic disk (floppy disk, hard disk, etc.), optical disk (CD-ROM, DVD, etc.), semiconductor memory, etc. as programs that can be executed by a computer. It can also be stored and distributed on a recording medium.
[0377]
Further, the present invention is not limited to the above-described embodiment, and various modifications can be made without departing from the scope of the invention in the implementation stage. Further, the above embodiments include inventions at various stages, and various inventions can be extracted by appropriate combinations of a plurality of disclosed configuration requirements. For example, even if some constituent elements are deleted from all the constituent elements shown in the embodiment, the problem (at least one of them) described in the column of problems to be solved by the invention can be solved, and the column of the effect of the invention If at least one of the effects described in (1) is obtained, a configuration in which this configuration requirement is deleted can be extracted as an invention.
[0378]
【The invention's effect】
As described above, according to the present invention, the usage and display format can be assigned to a desired component in the structured document database only by specifying at least a desired display area and access level on the search result display screen. It is possible to easily and finely set a desired access authority according to the above.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration example of a structured document management system according to an embodiment of the present invention.
FIG. 2 is a diagram showing a usage form of the structured document management system shown in FIG. 1, and shows a case where the structured document management system is operating on the back end of the WWW.
FIG. 3 is a diagram showing an example of a structured document described in XML.
4 is a diagram schematically showing the document structure of the structured document in FIG. 3;
FIG. 5 is a diagram for explaining the function of an additional command, and shows a case where the additional command is executed in the initial state of the structured document database.
6 is a view showing a processing result when an acquisition command is executed on the structured document database in the state shown in FIG.
FIG. 7 shows a case where a document object tree of one “patent” information is added to the structured document database in the state shown in FIG. 5B by executing an add command.
FIG. 8 shows a case where a document object tree of three “patent” information is added to the structured document database in the state shown in FIG. 5B by executing an add command.
FIG. 9 is a diagram showing a storage example of an element name occurrence index.
FIG. 10 is a diagram showing a storage example of a data occurrence index.
11 is a diagram showing an execution result when an acquisition command for extracting three pieces of “patent” information is executed on the structured document database in the state shown in FIG. 8. FIG.
FIG. 12 is a diagram showing an example of a schema that defines the document structure of an XML document.
13 is a diagram showing a case where a schema storage command is executed in the structured document database in the state shown in FIG. 8 and the schema shown in FIG. 12 is additionally stored (set).
FIG. 14 is a diagram showing a document object tree in which a schema is set and an attribute value indicating that the schema exists is set.
FIG. 15 is a diagram conceptually illustrating a state in which attribute values indicating that a schema exists are stored in each object file.
FIG. 16 is a diagram showing an example in which a conceptual hierarchy used in a search is expressed as a structured document as necessary.
FIG. 17 is a diagram showing an example in which a conceptual hierarchy used in a search is expressed as a structured document as necessary.
18 is a diagram showing a case where a document object tree of “concept” information shown in FIGS. 16 and 17 is added to the structured document database in the state shown in FIG. 8 by executing an add command.
19 is a diagram showing a case where a document object tree of “concept” information shown in FIGS. 16 and 17 is added to the structured document database in the state shown in FIG. 8 by executing an add command.
20 is a flowchart for explaining a document storage processing operation of the structured document management system of FIG. 1;
FIG. 21 is a flowchart for explaining the process of step S9 of FIG. 20 (process of the composite document creation unit).
FIG. 22 is a result of converting a document object tree of a composite document obtained by inserting a document object tree of a document storing a parameter in an add command into a document object tree acquired from a structured document database into an XML document; FIG. 5 is a diagram showing an example of a composite document stored in a temporary file A.
FIG. 23 is a diagram showing an example of a schema document acquired from a structured document database stored in a temporary file B.
FIG. 24 is a view showing another example of a composite document stored in a temporary file A.
FIG. 25 is a diagram showing an example of a schema document acquired from a structured document database stored in a temporary file B.
FIG. 26 is a flowchart for explaining the document acquisition processing operation of the structured document management system of FIG. 1;
FIG. 27 is a flowchart for explaining the document deletion processing operation of the structured document management system of FIG. 1;
FIG. 28 is a flowchart for explaining the processing in step S46 of FIG. 27 (processing of the composite document creation unit (for deletion command)).
FIG. 29 is a diagram showing still another example of the composite document stored in the temporary file A, and showing an example of the composite document created when the delete command is executed.
30 is a diagram showing an example of a schema document acquired from a structured document database stored in a temporary file B. FIG.
FIG. 31 is a diagram showing a display example of a screen as a user interface.
FIG. 32 is a diagram showing a display example of a screen as a user interface for storing / deleting a document.
FIG. 33 is a diagram showing a display example of a screen as a user interface for storing / deleting a document.
FIG. 34 is a diagram showing a display example of a screen as a user interface for storing / deleting a document.
FIG. 35 is a diagram showing a display example of a message returned to the client terminal when an error occurs in the validity check.
FIG. 36 shows a display example of a screen as a user interface for storing / deleting a document, and is a diagram for explaining a document acquisition operation.
FIG. 37 shows a display example of a screen as a user interface for setting a schema, and is a diagram for explaining a schema setting operation.
FIG. 38 shows a display example of a screen as a user interface for acquiring a schema, and shows a display example of the acquired schema.
FIG. 39 is a diagram showing an example of a query (XML document).
FIG. 40 is a diagram showing an example of a simple search query (XML document).
41 is a diagram showing a search result (XML document) using the simple search query of FIG. 40. FIG.
FIG. 42 is a diagram showing an example of a concept search query (XML document).
FIG. 43 is a flowchart for explaining the document search processing operation of the structured document management system of FIG. 1;
FIG. 44 is a diagram showing a display example of a screen as a user interface for performing a document search.
45 is a diagram showing a query created based on information input from the screen shown in FIG. 44. FIG.
46 is a diagram showing a storage example of the query shown in FIG. 42 in the structured document database.
FIG. 47 is a display example of a screen as a user interface for performing a document search, for explaining a schema search processing operation;
FIG. 48 is a diagram showing an example of a schema search query.
FIG. 49 is a diagram showing an example of a query for searching for a query.
FIG. 50 is a diagram showing an example of a structured document database in a patent search.
FIG. 51 is a diagram showing a display example of an input screen for concept search.
52 is a diagram showing a query corresponding to input information on the input screen shown in FIG. 51. FIG.
53 is a diagram showing an XML document as a search result corresponding to the query shown in FIG. 52;
FIG. 54 is a diagram showing an example of a patent map.
FIG. 55 is a diagram illustrating a configuration example of a main part of a client terminal device.
FIG. 56 is a flowchart for explaining a processing operation when an XML document transmitted from a structured document management system is displayed on a client terminal device.
FIG. 57 is a flowchart for explaining the processing operation in the client terminal device for setting access authority;
FIG. 58 is a functional block diagram of an access authority setting management unit.
FIG. 59 is a diagram schematically showing a part of the logical structure of a structured document database.
FIG. 60 is a diagram showing “report” information stored in a logical storage area under a “report DB” node as an example of a structured document described in XML.
FIG. 61 is a diagram showing a plurality of “report” information stored in a logical storage area below an “employee DB” node as an example of a structured document described in XML.
FIG. 62 is a diagram showing a screen display example of a display device of a client terminal device, and showing a display example of an XML document (search result document) obtained as a result of executing a query input from the client terminal device.
FIG. 63 is a diagram showing a search result document corresponding to FIG. 62;
64 is a diagram showing an example of a style sheet for converting the search result document shown in FIG. 63 into an HTML document for display in the display format shown in FIG. 62. FIG.
FIG. 65 is a diagram for explaining a correspondence between each description part of the HTML document and an identifier HID given to each description part;
FIG. 66 is a diagram showing an example of a correspondence table showing a correspondence relationship between a description portion in an HTML document and a description portion in a style sheet.
FIG. 67 is a diagram showing an example of a GUI screen for inputting a user range.
FIG. 68 is a diagram showing an example of a GUI screen for inputting an access level.
FIG. 69 is a diagram showing an example of a GUI screen for inputting an access type.
FIG. 70 is a flowchart for explaining a processing operation for setting access authority in the access authority setting management unit;
FIG. 71 is a flowchart for explaining a processing operation for setting access authority in the access authority setting management unit;
FIG. 72 is a diagram showing an example of a style access authority table stored in a style access authority management unit.
FIG. 73 is a diagram showing an example of a query access authority table stored in a query access authority management unit.
74 is a diagram showing an example of a data access authority table stored in the data access authority management unit. FIG.
FIG. 75 is a diagram showing an example of a schema access authority table stored in a schema access authority management unit.
FIG. 76 is a diagram showing an example of a path access authority table stored in a path access authority management unit.
77 is a diagram showing a query document used to obtain the XML document shown in FIG. 63. FIG.
FIG. 78 is a diagram showing an example of a query issued to search a structural document database for components for which access authority is set based on the query description shown in FIG. 77;
FIG. 79 is a diagram showing an example of a query issued to search a structural document database for components for which access authority is set based on the query description shown in FIG. 77;
FIG. 80 is a diagram showing logical storage positions (paths) of components in the structured document database obtained by executing the queries shown in FIGS. 78 and 79;
81 is a diagram showing a description portion in a schema in which access authority is set when the display area 307 of FIG. 62 is designated and the access level is designated as schema.
FIG. 82 is a diagram showing components for which access authority is set when the display area 307 in FIG. 62 is designated and the access level is designated as a pass.
FIG. 83 is a diagram showing an example of a style sheet in which the contents of access authority are written.
FIG. 84 is a diagram showing an example of a query in which the contents of access authority are written.
85 is a view showing a display example of a search result document obtained when the query shown in FIG. 77 is executed after the access authority is set at the data level.
86 is a view showing a display example of a search result document obtained when the query shown in FIG. 77 is executed after the access authority is set at the style level.
87 is a view showing a display example of a search result document obtained when a query different from the query shown in FIG. 77 is executed after the access authority is set at the data level.
88 is a view showing a part of an HTML document corresponding to the display screen shown in FIG. 65;
[Explanation of symbols]
1 ... Request control section
2 ... Access request processing section
3 ... Search request processing part
4. Data access part
5 ... Document storage
6. Index storage unit
11 ... Reception request part
12 ... Result processing section
21 ... Document storage unit
22 ... Document acquisition unit
23. Document deletion section
41 ... Document object tree storage
42 ... Document object tree deletion section
43 ... Document object tree acquisition unit
44 ... Document character string acquisition unit
45 ... Document object tree acquisition section from path
46. Document parser
47. Composite document creation section
48 ... Index update section
100 ... structured document management system
101 ... WWW server
102: Client terminal
103 ... WWW browser
111 ... XML document receiver
112 ... XML / HTML converter
113 ... Table creation section
114 ... correspondence table
115: Drawing unit
116: Access authority setting section
117: Transmitter
121 ... Display device
122... Input device
201: Access authority setting management unit
202 ... Access authority setting section
203 ... Access authority management section
211 ... Schema access authority management section
212 ... Data access authority management section
213 ... Query access authority management unit
214 ... Style Access Authority Management Department
215: Path access authority management unit

Claims (10)

A plurality of structured documents having a document structure including a plurality of elements are stored, and a storage area of each element included in each structured document is stored in the root node via one or more nodes. A structured document database that manages the plurality of structured documents by a logical structure linked according to the document structure, path information indicating a search position in the logical structure, and an element searched from the search position in the search result document A first search step for searching based on a search request sentence including a description part defining a document structure of the search result document including an element for outputting as an element of
An output command for outputting the search result document obtained as a result of the search, with an element in the search result document as a display element in the display document, and an element in the search result document to be processed by the output command A conversion step of converting into the display document using a style document including the position information of
Storing a table indicating a correspondence relationship between each output command in the style document and a display element in the display document generated by the output command in a storage unit;
Displaying the display document on a display screen;
A first detection step of detecting an output command associated with the display element with reference to the table when a display area of the display element in the display document displayed on the display screen is designated. When,
A second detection step of detecting a first element that is a processing target of the detected output command from the search result document;
A second search for searching for path information indicating a position of a second element having an element value of the first element as a value from a search position in the logical structure specified by the path information in the search request sentence; Steps,
A first setting step of setting an access authority defining a range of accessible users for the second element on the logical structure specified by the path information obtained as a result of the search;
Access authority setting method including.   The access authority setting according to claim 1, further comprising a second setting step of setting an access authority that defines a range of accessible users for the output command in the style document detected in the second detection step. Method. A third detection step of detecting a third element that outputs the first element in the search result document from the search request sentence;
A third setting step of setting an access authority that defines a range of accessible users for the third element in the search request sentence;
The access authority setting method according to claim 1, further comprising:   Of the structured documents stored in the structured document database, an element having the same element name as the second element in the structured document having the same document structure as the structured document including the second element The access authority setting method according to claim 1, further comprising a fourth setting step of setting an access authority defining a range of accessible users.   The fourth setting step is stored in the storage area in the logical structure in which a plurality of structured documents having the same document structure as the structured document including the second element are stored. If there is a document structure definition document that defines the document structure to be followed by the structured document, the access authority is set to the element having the same element name as the second element in the document structure definition document. 5. The access authority setting method according to claim 4, wherein the access authority is set. A plurality of structured documents having a document structure including a plurality of elements are stored, and a storage area of each element included in each structured document is stored in the root node via one or more nodes. A structured document database for managing the plurality of structured documents by a logical structure linked according to the document structure;
Path information indicating a search position in the logical structure, and a description section defining a document structure of the search result document including an element for outputting an element searched from the search position as an element in the search result document. First search means for searching a structured document database based on a search request sentence including the search result document obtained as a result of searching by the first search means, and an element in the search result document as a display document Conversion means for converting into a display document using a style document including an output command for output as a display element in the content and position information of an element in the search result document to be processed by the output command; ,
Storage means for storing a table indicating a correspondence relationship between each output command in the style document and a display element in the display document generated by the output command;
Display means for displaying the display document on a display screen;
First detection means for detecting an output command associated with the display element with reference to the table when a display area of the display element in the display document displayed on the display screen is designated When,
Second detection means for detecting a first element that is a processing target of the detected output command from the search result document;
A second search for searching for path information indicating a position of a second element having an element value of the first element as a value from a search position in the logical structure specified by the path information in the search request sentence; Means,
First access authority setting means for setting an access authority defining a range of accessible users for the second element on the logical structure specified by the path information obtained as a result of the search;
A structured document management system.   7. The structure according to claim 6, further comprising second access authority setting means for setting an access authority defining a range of accessible users for the output command in the style document detected by the first detection means. Document management system. Third detection means for detecting a third element that outputs the first element in the search result document from the search request sentence;
Third access authority setting means for setting access authority defining a range of accessible users for the third element in the search request sentence;
7. The structured document management system according to claim 6, further comprising:   Of the structured documents stored in the structured document database, an element having the same element name as the second element in the structured document having the same document structure as the structured document including the second element 7. The structured document management system according to claim 6, further comprising fourth access authority setting means for setting an access authority defining a range of accessible users.   The fourth access authority setting means is provided in the storage area on the logical structure in which a plurality of structured documents having the same document structure as the structured document including the second element are stored. When there is a document structure definition document that defines a document structure to be followed by the structured document to be stored, the access authority is set to an element having the same element name as the second element in the document structure definition document The structured document management system according to claim 9.

Images