(57)【要約】【課題】構造化文書から所望の情報を効率的に得ることのできる文書管理装置、文書管理システム、文書管理方法、および文書管理プログラムを提供する。【解決手段】文書蓄積手段１１に蓄積される文書を階層構造により管理する文書管理装置１０であって、前記文書に含まれる要素の前記階層構造における位置を特定するインデックスを生成するインデックス生成手段１０１と、前記インデックス生成手段１０１によって生成された前記インデックスと、前記要素とを対応付けて管理するインデックス管理手段３００とを備えた。【選択図】      図１
2004310607.tif 000002
【特許請求の範囲】
【請求項１】
文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理装置であって、
前記文書に含まれる要素の前記階層構造における位置を特定するインデックスを生成するインデックス生成手段と、
前記インデックス生成手段によって生成された前記インデックスと、前記要素とを対応付けて管理するインデックス管理手段と
を備えたことを特徴とする文書管理装置。
【請求項２】
前記インデックスと前記要素とを対応付けて蓄積するインデックス蓄積手段をさらに備え、
前記インデックス管理手段は、前記インデックス蓄積手段に蓄積されている前記インデックスを管理することを特徴とする請求項１に記載の文書管理装置。
【請求項３】
前記要素を検索する検索条件を取得する検索条件取得手段と、
前記検索条件取得手段が取得した前記インデックスと前記インデックス管理手段に管理されている前記インデックスとを照合する照合手段と、
前記照合手段の照合結果に基づいて、前記検索条件に合致する前記要素を特定する要素特定手段と
をさらに備えたことを特徴とする請求項１または２に記載の文書管理装置。
【請求項４】
前記インデックス生成手段は、前記要素の前記階層構造における探索経路を示す要素位置特定経路情報と、同一の前記要素位置特定経路情報で特定される複数の要素を識別する経路内要素特定情報とを含む前記インデックスを生成することを特徴とする請求項１から３のいずれか一項に記載の文書管理装置。
【請求項５】
前記検索条件取得手段は、前記要素位置特定経路情報および前記経路内要素特定情報のうち少なくとも一方を検索条件として取得し、
前記照合手段は、前記インデックス取得手段が取得した前記検索条件と、前記インデックス管理手段に管理されている前記インデックスとを照合し、
前記要素特定手段は、照合の結果に基づいて、前記検索条件に合致する部分を有する前記インデックスにより、前記検索条件に合致する前記要素を特定することを特徴とする請求項４に記載の文書管理装置。
【請求項６】
前記検索条件取得手段が、複数の検索条件と、各検索条件に対する論理演算子を取得し、前記照合手段が、各検索条件と前記インデックス管理手段に管理されている前記インデックスとをそれぞれ照合した場合に、前記照合の結果に基づいて、各検索条件に合致する前記インデックスをそれぞれ特定する候補特定手段と、
前記候補特定手段が各検索条件に対して特定した複数の前記インデックスに対し、前記論理演算子を用いた論理演算を行う論理演算手段と
をさらに備え、
前記要素特定手段は、当該論理演算の結果得られた前記インデックスにより、検索条件に合致する前記要素を特定することを特徴とする請求項３から５のいずれか一項に記載の文書管理装置。
【請求項７】
前記照合手段は、前記インデックスに文字列が含まれる場合に、各検索条件の文字列と前記インデックス管理手段に管理されている前記インデックスに含まれる文字列とを照合し、
前記候補特定手段は、前記文字列の照合の結果に基づいて、各検索条件に合致する前記インデックスをそれぞれ特定し、
前記論理演算手段は、特定した複数の前記インデックス間で文字列を照合することにより前記論理演算を行うことを特徴とする請求項６に記載の文書管理装置。
【請求項８】
前記検索条件取得手段は、前記要素特定手段が前回特定した前記要素の前記階層構造における位置から、次に特定すべき要素までの相対経路を取得し、
前記要素特定手段が前回特定した前記要素の前記インデックスと、前記検索条件取得手段が取得した前記相対経路に基づいて、次に特定すべき要素の前記階層構造における絶対経路で示された前記インデックスを特定する絶対経路特定手段をさらに備えたことを特徴とする請求項３から７のいずれか一項に記載の文書管理装置。
【請求項９】
前記要素特定手段は、前記相対経路特定手段によって特定された前記絶対経路に基づいて、前記検索条件に合致する要素を特定することを特徴とする請求項８に記載の文書管理装置。
【請求項１０】
前記要素特定手段が特定した前記要素と、当該要素の前記インデックスとを対応付けて出力する出力手段と
をさらに備えたことを特徴とする請求項２から９のいずれか一項に記載の文書管理装置。
【請求項１１】
前記インデックス蓄積手段に蓄積されている前記インデックスの更新を行う更新手段をさらに備えたことを特徴とする請求項１から１０のいずれか一項に記載の文書管理装置。
【請求項１２】
前記インデックス蓄積手段に蓄積されているインデックスの登録および削除を行う登録削除手段をさらに備えたことを特徴とする請求項１から１１のいずれか一項に記載の文書管理装置。
【請求項１３】
前記更新手段が一の処理を行っている場合に、他の処理を排除する排除制御手段をさらに備えたことを特徴とする請求項１１に記載の文書管理装置。
【請求項１４】
前記インデックス管理手段は、前記インデックス蓄積手段に蓄積されている前記インデックスの登録、削除、および更新のうち少なくとも一つが行われた場合に、前記インデックスおよび前記要素のうち少なくともいずれか一方を更新することを特徴とする請求項１２または１３に記載の文書管理装置。
【請求項１５】
文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理装置であって、
前記要素を検索する検索条件を取得する検索条件取得手段と、
前記インデックス生成手段によって生成された前記インデックスと、前記要素とを対応付けて管理するインデックス管理手段と、
前記検索条件取得手段が取得した前記インデックスと前記インデックス管理手段に管理されている前記インデックスとを照合する照合手段と、
前記照合手段の照合結果に基づいて、前記検索条件に合致する前記要素を特定する要素特定手段と
を備えたことを特徴とする文書管理装置。
【請求項１６】
文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理システムであって、
前記文書に含まれる要素の前記階層構造における位置を特定するインデックスを生成するインデックス生成手段と、
前記インデックス生成手段によって生成された前記インデックスと前記文書に含まれる要素とを対応付けて蓄積する複数のインデックス蓄積手段と、
前記複数の前記インデックス蓄積手段に蓄積される前記インデックスを管理するインデックス管理手段と
を備えたことを特徴とする文書管理システム。
【請求項１７】
文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理システムであって、
前記文書に含まれる要素の前記階層構造における位置を特定するインデックスを生成するインデックス生成手段と、
前記インデックス生成手段によって生成された前記インデックスと前記文書に含まれる要素とを対応付けて蓄積する複数のインデックス蓄積手段と、
前記複数の前記インデックス蓄積手段に蓄積される前記インデックスをそれぞれ管理する複数のインデックス管理手段と
を備えたことを特徴とする文書管理システム。
【請求項１８】
前記文書を検索する検索条件を取得する検索条件取得手段と、
前記検索条件取得手段が取得した前記インデックスと前記インデックス管理手段に管理されている前記インデックスとを照合する照合手段と、
前記照合手段の照合結果に基づいて、前記検索条件に合致する前記要素を特定する要素特定手段と
をさらに備えたことを特徴とする請求項１６または１７に記載の文書管理システム。
【請求項１９】
文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理方法であって、
前記文書の前記階層構造における位置を特定するインデックスを生成するインデックス生成ステップと、
前記インデックス生成ステップにおいて生成された前記インデックスと、前記文書に含まれる要素とを対応付けて、インデックス蓄積手段に蓄積するインデックス蓄積ステップと
を有することを特徴とする文書管理方法。
【請求項２０】
文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理方法をコンピュータに実行させる文書管理プログラムであって、
前記文書の前記階層構造における位置を特定するインデックスを生成するインデックス生成ステップと、
前記インデックス生成ステップにおいて生成された前記インデックスと、前記文書に含まれる要素とを対応付けて管理するインデックス管理ステップと
をコンピュータに実行させることを特徴とする文書管理プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、文書蓄積手段に蓄積される文書を階層構造により管理する文書管理装置、文書管理システム、文書管理方法、および文書管理プログラムに関する。
【０００２】
【従来の技術】
近年の情報化に伴い電子化文書が増加し、電子化文書を効率的に管理、検索する技術の提供が望まれている。電子化文書を検索する方法としては、論理構造を有する構造化文書によるものが知られている。
【０００３】
構造化文書を利用することにより、所定のキーワードを指定することにより、効率的に該当する要素を抽出することができる。
【０００４】
構造化文書の記述方式としては、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）で規格化が薦められているＸＭＬ（ｅｘｔｅｎｄｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）が知られている。これは、文書への属性情報付加や、文書の階層構造を表現するのに適した記述方式である。このように、属性情報付加や、階層構造を表現するのに適しているという特徴を有することから、新聞や本などの通常の文書だけでなく、出納データや、部品番号データなどの情報を管理するのにも適している。
【０００５】
【発明が解決しようとする課題】
しかし、例えば、新聞の全文検索おいては、新聞のレイアウト情報は不要である。また、映像データの検索においては、詳細な映像フォーマットに関する情報は不要である。このように、対象となる文書が異なると、検索対象となるデータの種類も異なってくる。このように、構造化文書の対象となる文書は多岐に渡っており、各文書の種類ごとに最適な管理方法も異なってくる。そのため、各文書の種類に適した管理方法の提供が望まれている。また、対象となる文書内の全ての要素が検索対象となるわけではないので、検索対象となる要素のみを効率的に検索することにより、検索などの処理の効率化を図る必要がある。
【０００６】
この発明は、上記に鑑みてなされたもので、所望の情報を効率的に得ることのできる文書管理装置、文書管理システム、文書管理方法、および文書管理プログラムを得ることを目的とする。
【０００７】
【課題を解決するための手段】
上記目的を達成するため、請求項１にかかる発明は、文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理装置であって、前記文書に含まれる要素の前記階層構造における位置を特定するインデックスを生成するインデックス生成手段と、前記インデックス生成手段によって生成された前記インデックスと、前記要素とを対応付けて管理するインデックス管理手段とを備えたことを特徴とする。
【０００８】
この請求項１の発明によれば、インデックス管理手段は、文書の階層構造における位置を特定するインデックスと、要素とを対応付けて管理しているので、所定の要素が特定された場合に、当該要素の構造化文書内における位置を認識することができる。このように、特定した要素が構造化文書内のいずれの位置に格納されているのかを把握することができるので、例えば、さらに他の要素を特定する場合に、既に特定している要素の位置を基準とした、他の要素までの相対経路に基づいて他の要素を特定することができる。このように、特定した要素の位置に基づいて、検索処理を行うことにより、処理の効率化を図ることができる。
【０００９】
また、ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎ  Ｄａｔａｂａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）においては構造化文書のスキーマを予め定めておく必要があるが、本発明においては、このようにインデックスと要素とを対応付けているので、構造化文書のスキーマを予め定める必要がない。したがって、文書のスキーマに制限されることなく、多様な種類の文書を管理することができる。
【００１０】
また、請求項２にかかる発明は、請求項１に記載の文書管理装置であって、前記インデックスと前記要素とを対応付けて蓄積するインデックス蓄積手段をさらに備え、前記インデックス管理手段は、前記インデックス蓄積手段に蓄積されている前記インデックスを管理することを特徴とする。
【００１１】
この請求項２の発明によれば、インデックス蓄積手段は、インデックスと要素とを対応付けて蓄積しているので、インデックス管理手段は、要素とともにインデックスを特定することができる。また、このインデックスは、構造化文書における要素の位置を示しているので、これにより、要素の位置を把握することができる。このように、特定した要素の位置に基づいて、処理を行うことにより、処理の効率化を図ることができる。
【００１２】
また、請求項３にかかる発明は、請求項１または２に記載の文書管理装置であって、前記要素を検索する検索条件を取得する検索条件取得手段と、前記検索条件取得手段が取得した前記インデックスと前記インデックス管理手段に管理されている前記インデックスとを照合する照合手段と、前記照合手段の照合結果に基づいて、前記検索条件に合致する前記要素を特定する要素特定手段とをさらに備えたことを特徴とする。
【００１３】
この請求項３の発明によれば、インデックスは要素の位置を示しているので、要素の位置を示す検索条件を取得した場合には、検索条件とインデックスとの照合結果に基づいて、検索条件に合致する要素を特定することができる。従って、より効率的に検索対象を特定することができる。
【００１４】
また、請求項４にかかる発明は、請求項１から３のいずれか一項に記載の文書管理装置であって、前記インデックス生成手段は、前記要素の前記階層構造における探索経路を示す要素位置特定経路情報と、同一の前記要素位置特定経路情報で特定される複数の要素を識別する経路内要素特定情報とを含む前記インデックスを生成することを特徴とする。
【００１５】
この請求項４の発明によれば、インデックス生成手段は、階層構造における探索経路を示す要素位置特定経路情報と、同一の要素位置特定経路情報で特定される複数の要素を識別する経路内要素特定情報とを含むインデックスを生成する。このため、同一の経路で特定される要素が複数ある場合、すなわち一の親ノードに対して、複数の子ノードが存在するような構成であっても、複数の要素それぞれを識別することができる。従って、すべての要素を正確に識別することができる。
【００１６】
また、請求項５にかかる発明は、請求項４に記載の文書管理装置であって、前記検索条件取得手段は、前記要素位置特定経路情報および前記経路内要素特定情報のうち少なくとも一方を検索条件として取得し、前記照合手段は、前記インデックス取得手段が取得した前記検索条件と、前記インデックス管理手段に管理されている前記インデックスとを照合し、前記要素特定手段は、照合の結果に基づいて、前記検索条件に合致する部分を有する前記インデックスにより、前記検索条件に合致する前記要素を特定することを特徴とする。
【００１７】
この請求項５の発明によれば、検索条件が要素位置特定経路情報および経路内要素特定情報のうち少なくとも一方を含む場合には、当該検索条件とインデックスとを照合することによって、検索条件に合致する要素を特定することができる。従って、より効率的に検索対象を特定することができる。
【００１８】
また、請求項６にかかる発明は、請求項３から５のいずれか一項に記載の文書管理装置であって、前記検索条件取得手段が、複数の検索条件と、各検索条件に対する論理演算子を取得し、前記照合手段が、各検索条件と前記インデックス管理手段に管理されている前記インデックスとをそれぞれ照合した場合に、前記照合の結果に基づいて、各検索条件に合致する前記インデックスをそれぞれ特定する候補特定手段と、前記候補特定手段が各検索条件に対して特定した複数の前記インデックスに対し、前記論理演算子を用いた論理演算を行う論理演算手段とをさらに備え、前記要素特定手段は、当該論理演算の結果得られた前記インデックスにより、検索条件に合致する前記要素を特定することを特徴とする。
【００１９】
この請求項６の発明によれば、複数の検索条件と、各検索条件に対する論理演算子を取得した場合には、まず、各検索条件とインデックスとの照合結果に基づいて、各検索条件に合致するインデックスを特定する。そして、特定したインデックスに対して論理演算子を用いた論理演算を行うことにより、検索対象を示すインデックスを特定することができる。このように、インデックスと検索対象との照合により検索対象を特定することができるので、処理効率を向上させることができる。
【００２０】
また、請求項７にかかる発明は、請求項６に記載の文書管理装置であって、前記照合手段は、前記インデックスに文字列が含まれる場合に、各検索条件の文字列と前記インデックス管理手段に管理されている前記インデックスに含まれる文字列とを照合し、前記候補特定手段は、前記文字列の照合の結果に基づいて、各検索条件に合致する前記インデックスをそれぞれ特定し、前記論理演算手段は、特定した複数の前記インデックス間で文字列を照合することにより前記論理演算を行うことを特徴とする。
【００２１】
この請求項７の発明によれば、インデックスに文字列が含まれている場合には、検索条件とインデックスに含まれている文字列の各文字を照合することにより、実質的に、論理演算を行うことができる。このように、文字列照合の結果を利用することにより、検索処理の効率を向上させることができる。
【００２２】
また、請求項８にかかる発明は、請求項３から７のいずれか一項に記載の文書管理装置であって、前記検索条件取得手段は、前記要素特定手段が前回特定した前記要素の前記階層構造における位置から、次に特定すべき要素までの相対経路を取得し、前記要素特定手段は、前回特定した前記要素の前記インデックスと、前記検索条件取得手段が取得した前記相対経路に基づいて、次に特定すべき要素の前記階層構造における絶対経路を特定する絶対経路特定手段をさらに備えたことを特徴とする。
【００２３】
この請求項８の発明によれば、絶対経路特定手段は、前回特定したインデックスと、検索条件取得手段が取得した相対経路に基づいて、次に特定すべき要素の絶対経路、すなわちインデックスを特定することができるので、検索条件を解析して構造化文書の根から検索を開始する場合に比べて、検索処理の効率を向上させることができる。
【００２４】
また、請求項９にかかる発明は、請求項８に記載の文書管理装置であって、前記要素特定手段は、前記絶対経路特定手段によって特定された前記絶対経路に基づいて、前記検索条件に合致する要素を特定することを特徴とする。
【００２５】
この請求項９の発明によれば、絶対経路特定手段によって特定された絶対経路に基づいて、検索条件に合致する要素を特定することができる。すなわち、絶対経路を取得しなくとも、相対経路から特定した絶対経路に基づいて、要素を特定することができる。
【００２６】
また、請求項１０にかかる発明は、請求項２から９のいずれか一項に記載の文書管理装置であって前記要素特定手段が特定した前記要素と、当該要素の前記インデックスとを対応付けて出力する出力手段とをさらに備えたことを特徴とする。
【００２７】
この請求項１０の発明によれば、検索条件に合致するとして抽出した要素と、当該要素のインデックスとを対応付けて出力するので、ユーザは、要素が構造化文書のいずれの位置に格納されているのかを把握することができる。
【００２８】
また、請求項１１にかかる発明は、請求項１から１０のいずれか一項に記載の文書管理装置であって、前記インデックス蓄積手段に蓄積されている前記インデックスの更新を行う更新手段をさらに備えたことを特徴とする。
【００２９】
この請求項１１の発明によれば、インデックス蓄積手段に蓄積されているインデックスを更新する更新手段をさらに備えているので、インデックスを自由に更新することができる。
【００３０】
また、請求項１２にかかる発明は、請求項１から１１のいずれか一項に記載の文書管理装置であって、前記インデックス蓄積手段に蓄積されているインデックスの登録および削除を行う登録削除手段をさらに備えたことを特徴とする。
【００３１】
この請求項１２の発明によれば、インデックス蓄積手段に蓄積されているインデックスの登録および削除を行う登録削除手段をさらに備えているので、インデックスを自由に登録および削除することができる。
【００３２】
また、請求項１３にかかる発明は、請求項１１に記載の文書管理装置であって、前記更新手段が一の処理を行っている場合に、他の処理を排除する排除制御手段をさらに備えたことを特徴とする。
【００３３】
この請求項１３の発明によれば、更新手段が一の処理を行っているときに、排他制御手段は、他の処理を排除するので、複数の処理が同時に行われることにより、不適切な更新が行われるのを避けることができる。
【００３４】
また、請求項１４にかかる発明は、請求項１２または１３に記載の文書管理装置であって、前記インデックス管理手段は、前記インデックス蓄積手段に蓄積されている前記インデックスの登録、削除、および更新のうち少なくとも一つが行われた場合に、前記インデックスおよび前記要素のうち少なくともいずれか一方を更新することを特徴とする。
【００３５】
この請求項１４の発明によれば、インデックス管理手段は、インデックス蓄積手段に蓄積されているインデックスの登録，削除、および更新のうち少なくとも１つが行われた場合には、インデックス蓄積手段に蓄積されているインデックスのうち、当該処理により更新の必要が生じたデータを更新することができる。従って、一の処理により、他のデータとの整合性がとれなくなるのを回避することができる。
【００３６】
また、請求項１５にかかる発明は、文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理装置であって、前記要素を検索する検索条件を取得する検索条件取得手段と、前記インデックス生成手段によって生成された前記インデックスと、前記要素とを対応付けて管理するインデックス管理手段と、前記検索条件取得手段が取得した前記インデックスと前記インデックス管理手段に管理されている前記インデックスとを照合する照合手段と、前記照合手段の照合結果に基づいて、前記検索条件に合致する前記要素を特定する要素特定手段とを備えたことを特徴とする。
【００３７】
この請求項１５の発明によれば、インデックスは要素の位置を示しているので、要素の位置を示す検索条件を取得した場合には、検索条件とインデックスとの照合結果に基づいて、検索条件に合致する要素を特定することができる。従って、より効率的に検索対象を特定することができる。
【００３８】
また、請求項１６にかかる発明は、文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理システムであって、前記文書に含まれる要素の前記階層構造における位置を特定するインデックスを生成するインデックス生成手段と、前記インデックス生成手段によって生成された前記インデックスと前記文書に含まれる要素とを対応付けて蓄積する複数のインデックス蓄積手段と、前記複数の前記インデックス蓄積手段に蓄積される前記インデックスを管理するインデックス管理手段とを備えたことを特徴とする。
【００３９】
この請求項１６の発明によれば、複数のインデックス蓄積手段を備えているので、処理の効率化図ることができる。
【００４０】
また、請求項１７にかかる発明は、文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理システムであって、前記文書に含まれる要素の前記階層構造における位置を特定するインデックスを生成するインデックス生成手段と、前記インデックス生成手段によって生成された前記インデックスと前記文書に含まれる要素とを対応付けて蓄積する複数のインデックス蓄積手段と、前記複数の前記インデックス蓄積手段に蓄積される前記インデックスをそれぞれ管理する複数のインデックス管理手段とを備えたことを特徴とする。
【００４１】
この請求項１７の発明によれば、複数のインデックス蓄積手段と、各インデックス蓄積手段を管理する複数のインデックス管理手段とを備えているので、分散処理が可能となり、処理の効率化を図ることができる。
【００４２】
また、請求項１８にかかる発明は、請求項１６または１７に記載の文書管理システムであって、前記文書を検索する検索条件を取得する検索条件取得手段と、前記検索条件取得手段が取得した前記インデックスと前記インデックス管理手段に管理されている前記インデックスとを照合する照合手段と、前記照合手段の照合結果に基づいて、前記検索条件に合致する前記要素を特定する要素特定手段とをさらに備えたことを特徴とする。
【００４３】
この請求項１８の発明によれば、インデックスは要素の位置を示しているので、要素の位置を示す検索条件を取得した場合には、検索条件とインデックスとの照合結果に基づいて、検索条件に合致する要素を特定することができる。従って、より効率的に検索対象を特定することができる。
【００４４】
また、請求項１９にかかる発明は、文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理方法であって、前記文書の前記階層構造における位置を特定するインデックスを生成するインデックス生成ステップと、前記インデックス生成ステップにおいて生成された前記インデックスと、前記文書に含まれる要素とを対応付けて、インデックス蓄積手段に蓄積するインデックス蓄積ステップとを有することを特徴とする。
【００４５】
この請求項１９の発明によれば、特定した要素が構造化文書内のいずれの位置に格納されているのかを把握することができるので、例えば、さらに他の要素を特定する場合に、既に特定している要素の位置を基準とした、他の要素までの相対経路に基づいて他の要素を特定することができる。このように、特定した要素の位置に基づいて、検索処理を行うことにより、処理の効率化を図ることができる。
【００４６】
また、請求項２０にかかる発明は、文書蓄積手段に蓄積される、階層構造により表現された文書を管理する文書管理方法をコンピュータに実行させる文書管理プログラムであって、前記文書の前記階層構造における位置を特定するインデックスを生成するインデックス生成ステップと、前記インデックス生成ステップにおいて生成された前記インデックスと、前記文書に含まれる要素とを対応付けて管理するインデックス管理ステップとをコンピュータに実行させることを特徴とする。
【００４７】
この請求項２０の発明によれば、特定した要素が構造化文書内のいずれの位置に格納されているのかを把握することができるので、例えば、さらに他の要素を特定する場合に、既に特定している要素の位置を基準とした、他の要素までの相対経路に基づいて他の要素を特定することができる。このように、特定した要素の位置に基づいて、検索処理を行うことにより、処理の効率化を図ることができる。
【００４８】
【発明の実施の形態】
以下に添付図面を参照して、この発明にかかる文書管理装置および文書管理システムの好適な実施の形態を詳細に説明する。
【００４９】
（実施の形態１）
図１は、この発明の実施の形態１である文書管理装置１０の構成を示すブロック図である。文書管理装置１０は、構造化文書蓄積部１１と、構造化文書蓄積部１１を制御する構造化文書管理部２００と、インデックス蓄積部１２と、インデックス蓄積部１２を制御するインデックス処理部３００と、インデックスリスト蓄積部１３と、インデックスリスト蓄積部１３を制御し、また、文書管理装置１０全体を制御する総合管理部１００とを備えている。
【００５０】
構造化文書蓄積部１１は、構造化文書と、当該構造化文書を識別する構造化文書ＩＤとを対応付けて蓄積する。図２を参照しつつ、構造化文書蓄積部１１における構造化文書のデータ構成について説明する。構造化文書は、階層構造を有しており、文書に含まれる各要素が、各階層に分けて管理されている。
【００５１】
例えば、図２に示される要素「”タイトル”」４１０は、ノード４００から３段階下位のノード４０３に格納されている。すなわち、要素４１０を特定するための絶対経路は、ノード４００、ノード４０１、ノード４０２、およびノード４０３である。また、ＸＰａｔｈの記述方式によれば、「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］／ＣｒｅａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ／Ｔｉｔｌｅ」と表現される。
【００５２】
ここで、「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］」中の［１］は、「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ」と同一階層の複数のノードを識別するための識別番号である。図２に示す階層構造においては、「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ」４０５，４１６は、それぞれ「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］」および「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［２］」と表される。
【００５３】
また、要素「”キーワード”」４１１と要素「”特許１”」４１２の絶対経路は、いずれもノード４００、ノード４０４、ノード４０５、およびノード４０６、ノード４０７である。このように、絶対経路が等しい場合には、さらに、経路内ＩＤにより識別される。ここで、絶対経路とは、階層構造における途中の枝であるノードからの相対的な経路ではなく、根であるノードを基準とした絶対的な経路のことである。また、経路内ＩＤとは、同一の親ノードに対する複数の子ノードを識別するための情報である。
【００５４】
このように、各要素は、絶対経路および経路内ＩＤにより特定される。本実施の形態におけるインデックスは、この絶対経路を識別する絶対経路ＩＤと経路内ＩＤで構成されている。ここで、絶対経路ＩＤは、本発明における要素位置特定経路情報に相当する。また、経路内ＩＤは、本発明における経路内要素特定情報に相当する。
【００５５】
なお、本実施の形態においては、構造化文書は、ファイルとして管理されており、構造化文書ＩＤはファイル名である。
【００５６】
他の例としては、構造化文書は、メモリに記憶されていてもよい。また、構造化文書ＩＤは、構造化文書を一意に識別できる情報であればよく、ファイルパスであってもよい。また、他の例としては、ＵＲＬであってもよい。
【００５７】
また、構造化文書蓄積部１１の実現方式は、実施の形態に限定されるものではなく、他の例としては、データベースで実現されてもよい。
【００５８】
構造化文書管理部２００は、構造化文書蓄積部１１に構造化文書を新規に登録する登録部２０１と、構造化文書蓄積部１１に既に蓄積されている構造化文書を削除する削除部２０２と、構造化文書蓄積部１１に蓄積されている構造化文書の内容等を更新する更新部２０３と、構造化文書蓄積部１１に蓄積されている構造化文書から所定のノード値を取得するノード値取得部２０４と、構造化文書蓄積部１１に対して一の処理が行われているときに、他の処理を排除する排他制御部２０５とを有する。
【００５９】
インデックスリスト蓄積部１３は、構造化文書蓄積部１１に蓄積されている構造化文書を構成する各ノードのリスト構造である、インデックスリストを蓄積する。
【００６０】
総合管理部１００は、インデックスリスト蓄積部１３に新たにインデックスリストを登録する登録部１０１と、インデックスリスト蓄積部１３に蓄積されているインデックスリストを削除する削除部１０２と、インデックスリスト蓄積部１３に蓄積されているインデックスリストを更新する更新部１０３と、外部からの情報を取得する通信部１１０と、通信部１１０が取得した情報を振り分ける要求振り分け部１０４と、要求振り分け部１０４から検索条件を取得し、また、検索条件に対する検索結果を構造化文書管理部２００、インデックス処理部３００、またはインデックスリスト蓄積部１３から取得する検索条件、検索条件取得部１０５と、検索条件取得部１０５から検索条件を受け取り、検索条件を解析する検索条件解析部１０６とを有する。ここで、登録部１０１は、本発明のインデックス生成手段を構成する。
【００６１】
インデックス蓄積部１２は、構造化文書蓄積部１１に蓄積されている構造化文書内の所定のノードを特定するために利用されるインデックスを、対応する構造化文書を識別する構造化文書ＩＤに対応付けて蓄積する。
【００６２】
インデックスは、第１値と第２値のリスト構造で構成されている。ここで、第１値は、インデックスにより特定される要素である。また、第２値は、インデックスへのアクセス手段の識別子、すなわちインデックスＩＤである。本実施の形態においては、インデックスＩＤは、絶対経路ＩＤ、および経路内ＩＤを含んでいる。ここで、絶対経路ＩＤは、単一の要素名、または連続する複数の要素名で構成されている。同一の経路内に複数のインデックスが存在する場合、すなわち、兄弟インデックスが存在する場合には、さらに経路内ＩＤを含んでいる。なお、二値はユーザにより定義される。
【００６３】
より、具体的には、例えば、図２における要素「キーワード」４１１のインデックスにおける第１値は、キーワードであり、第２値は、「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ  ／  Ｔｅｍｐｏｒａｌ  Ｄｅｃｏｍｐｏｓｉｔｉｏｎ  ／  ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ  ／  ＴｅｘｔＡｎｎｏｔａｔｉｏｎ  ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」である。
【００６４】
また、要素名が「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」である場合、第１値は、「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」である。また、あるノードの要素名が「ＴｅｘｔＡｎｎｏｔａｔｉｏｎ」であり、このノードの子ノード要素名が「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」である場合には、当該子ノードの第１値は、「ＴｅｘｔＡｎｎｏｔａｔｉｏｎ  ／  ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」である。
【００６５】
また、要素名「ＴｅｘｔＡｎｎｏｔａｔｉｏｎ」で属性名「ｔｙｐｅ」の値が「ｈｅａｄｌｉｎｅ」であるノードの子ノードの要素名が「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」である場合、当該子ノードの第１値は、「ＴｅｘｔＡｎｎｏｔａｔｉｏｎ［＠ｔｙｐｅ＝”ｈｅａｄｌｉｎｅ”］  ／  ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」である。
また、それぞれのインデックスの第２値は、それぞれのインデックスへのアクセス手段である。具体的には、第２値は、例えば、「ＴｅｘｔＤＢ  ：  ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」であってもよい。また、他の例としては、例えば、ＵＲＬであってもよい。
【００６６】
インデックス処理部３００は、インデックス蓄積部１２にインデックスを追加する追加部３０１と、インデックス蓄積部１２に蓄積されているインデックスを削除する削除部３０２と、インデックス蓄積部１２に蓄積されているインデックスの内容等を更新する更新部３０３と、インデックス蓄積部１２から所定のインデックスを検索する検索部３０４と、インデックス蓄積部１２に対して一の処理が行われているときに、他の処理を排除する排他制御部３０５と、要素特定手部３１２が前回特定した要素のインデックスと、検索条件取得１０５が取得した相対経路に基づいて、次に特定すべき要素の階層構造における絶対経路で示されたインデックスを特定する絶対経路特定部３０６とを備えている。
【００６７】
また、検索部３０４は、検索条件と、インデックス蓄積部１２に蓄積されているインデックスとの文字列照合を行う照合部３１５と、照合結果に基づいて、検索条件に合致する要素を特定する要素特定部３１１と、検索条件に合致する要素の候補のインデックスを特定する候補特定部３１２と、検索条件に含まれる論理演算子による論理演算を行う論理演算部３１４とを有している。なお、ここで、論理演算部３１４は、文字列の比較により、結果として論理演算の結果を取得する。
【００６８】
ここで、通信部１１０は、本発明の出力手段を構成する。また、登録部１０１と削除部１０２は、本発明の登録削除手段を構成する。
【００６９】
図３は、ＭＰＥＧ−７（Ｍｕｌｔｉｍｅｄｉａ  Ｃｏｎｔｅｎｔ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｉｎｔｅｒｆａｃｅ）で記述した構造化文書を示している。図３に示す構造化文書は、図２に示す構造化文書と同一である。
【００７０】
ここで、ＭＰＥＧ−７とは、動画や音声などのマルチメディアコンテンツを有効に検索するための記述方法の標準技術である。具体的には、登場人物や映像ファイルフォーマットなどのメタデータを構造化文書（ＸＭＬ）で記述する方式である。
【００７１】
ＭＰＥＧ−７では、対象となる映像データに関する多くの情報を記述することができる。しかし、ＭＰＥＧ−７を実際に映像検索システムに利用する場合、詳細な映像フォーマットの情報は検索対象とはならない場合がある。一方、映像フォーマット変換システムでは、詳細な映像フォーマットの情報のみが必要である。また、新聞のレイアウト情報は、新聞の全文検索データベースには不要である。
【００７２】
さらに、構造化文書は構造を持った情報を記述するための文書であるため、帳票データや顧客データのようにその構造化文書の全情報が検索対象となるとは限らず、検索対象となるのは、構造化文書内の一部分のみである場合もある。このようにインデックスを付与すべき対象となる情報は、アプリケーション毎に、またはデータ毎に異なっている。
【００７３】
利用されない情報に対してインデックスを付与し、管理することは、処理効率を低下させる要因となる。このように、多様なデータに対して、それぞれのデータ特性にあったインデックスを付与することによって、より効率的に構造化文書を管理することができる。なお、利用されない情報には、ＸＭＬにおけるタグ情報も含まれる。
【００７４】
次に、動画データの構造化文書について説明する。動画データでは、開始時間と、時間長により所定のフレームを特定する。ただし、その特定方法はＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）やＸＭＬＳｃｈｅｍｅからは一意に決められない場合がある。なお、ＤＴＤとは、タグの属性などを定義する言語であり、ＸＭＬＳｃｈｅｍｅとは、文書の構造を定義する言語である。
【００７５】
図４は、動画データにおける一部のデータを指定する記述を示している。一部のデータとは、例えば、動画データの開始時間から３０秒後に再生されるデータのことである。一部のデータは、開始時間と時間長により指定される。図４（Ａ）、（Ｂ）、および（Ｃ）は、いずれも開始時間３０秒後、時間長２０秒を表現している。いずれも、２行目で開始時間を指定している。また、いずれも３行目で時間長を示している。
【００７６】
図４（Ａ）は、「”．．／．．／ＭｅｄｉａＴｉｍｅ［１］”」の時間点ＰＴの３０秒後、すなわち「ＰＴ３０Ｓ」という直接的な表現で表している。なお、ここで、「．．」であれば軸方向は“上り”で、その数は１であることを示している。図４（Ｂ）は、「”．．／．．／ＭｅｄｉａＴｉｍｅ［１］”」の時間点ＰＴの１０秒単位、すなわち「ｔｉｍｅＵｎｉｔ＝”ＰＴ１０Ｓ”」の３個分後、すなわちボディ部に「３」と表現している。また、図４（Ｃ）は、３０秒単位「ｔｉｍｅＵｎｉｔ＝”ＰＴ３０Ｓ”」を１個分と表現している。
【００７７】
このように複数の記述を許容すると、例えば「”．．／．．／ＭｅｄｉａＴｉｍｅ［１］”」で記述される開始時間から１０秒後のＭｅｄｉａＴｉｍｅの全てを探すという検索条件を受けた場合には、開始時間を表現する二種類の要素名「ＭｅｄｉａＲｅｌＴｉｍｅＰｏｉｎｔ」と「ＭｅｄｉａＲｅｌＩｎｃｒＴｉｍｅＰｏｉｎｔ」のインデックスを参照し、「ＭｅｄｉａＲｅｌＴｉｍｅＰｏｉｎｔ」の値を解釈し検索条件と比較し、「ＭｅｄｉａＲｅｌＩｎｃｒＴｉｍｅＰｏｉｎｔ」のボディ部と属性部を解釈し、検索条件と比較するという処理を行わなければならない。２種類の場合には、さほど処理量の増加は問題とならない。しかし、１００種類の表現形式で同一の内容を記述した場合には、処理量が膨大となり、処理効率が低下するという問題が生じる。
【００７８】
また、「”．．／．．／ＭｅｄｉａＴｉｍｅ［１］”」で記述される終了時間から４０秒後のＭｅｄｉａＴｉｍｅの全てを探すという検索条件を受けた場合には、図４（Ａ）の場合には、二種類の要素「ＭｅｄｉａＲｅｌＴｉｍｅＰｏｉｎｔ」および「ＭｅｄｉａＩｎｃｒＤｕｒａｔｉｏｎ」を参照して、それぞれ終了時刻を計算する必要あり効率が悪い。
【００７９】
図５は、本実施の形態における動画データの構造化文書５１０を示している。構造化文書５１０内の行５１２，５１３，５１４は、いずれも動画データ中の所定の時間を指定する記述である。すなわち、動画データ中の一部のデータを指定する記述である。時間を指定する４行のうち２行目５１２ａ，５１３ａ，５１４ａは、いずれも開始時間を示している。また、３行目５１２ｂ，５１３ｂ，５１４ｂは、いずれも開始時間からの時間長を示している。
【００８０】
このように、本実施の形態においては、時間を指定する情報は、統一された形式で記述されており、かつ、他の情報と同様に絶対経路ＩＤとして記述されている。このため、図４を参照しつつ説明したように、同一の情報を指定する方法が複数存在することにより、処理効率が低下するという問題を解消することができる。
【００８１】
さらに、本実施の形態における構造化文書のインデックスは、Ｗ３Ｃで規格化されているＸＰａｔｈ（ＸＭＬ  Ｐａｔｈ  ｌａｎｇｕａｇｅ）の方式で表現されている。構造化文書の記述方式の代表的なものに、Ｗ３Ｃで規格化が進められているＸＭＬがある。ＸＰａｔｈとは、ＸＭＬ文書の記述を特定する方法である。
【００８２】
以下、図６を参照しつつ、ＸＰａｔｈ式による記述について説明する。図６は、ＸＰａｔｈ式により示された絶対経路ＩＤを示している。図６（Ａ）は、ＸＭＬ方式で示した絶対経路ＩＤを示している。図６（Ｂ）は、図６（Ａ）に示す絶対経路ＩＤを、ＸＰａｔｈ式で表している。
【００８３】
このように、絶対経路ＩＤをＸＰａｔｈ式で表すことにより、同じ親ノードに属するノードは、数字部分のみが異なる文字列で表現されるので、単純な文字列の比較により各ノードを識別することができる。
【００８４】
図７は、インデックス蓄積部１２に格納されているインデックスのデータ構造を示している。インデックス５２０は、第１値と第２値を含むリスト構造で構成されている。第１値は、絶対経路ＩＤ５２２である。また、第２値は、絶対経路ＩＤ５２２により特定される値５２４である。
【００８５】
ここで、絶対経路ＩＤにより特定される値は、構造化文書に含まれる情報であるが、他の例としては、予め計算された値であってもよい。ここで、予め計算された値とは、例えば、図４を参照しつつ説明した動画データの一部のデータのことである。すなわち、開始時間と時間長により特定される一部のデータのことである。
【００８６】
なお、インデックス蓄積部１２は、ＲＤＢ（Ｒｅｌａｔｉｏｎ  Ｄａｔａ  Ｂａｓｅ）である必要はない。
【００８７】
従来は、検索エンジンとしてＲＤＢＭＳの利用を想定しているため、構造化文書中に例えば複雑な計算を要する画像特徴量が記述されている場合には、その画像特徴量に対する問合せも他の文字列の問合せと同時に行う必要があるアプリケーションを考えた場合、複雑な画像特徴量問い合わせ処理も文字列問い合わせ用ＲＤＢＭＳで行わせるか、または画像特徴量検索エンジンにＲＤＢＭＳとしてのインターフェイスを持たせ、問合せ式を解析し検索最適化モジュールで文字列問い合わせ用ＲＤＢＭＳと画像特徴量用ＤＢに割り振らなければならず、処理が煩雑であった。
【００８８】
これに対して、本実施の形態におけるインデックス蓄積部１２に格納されるインデックスは、図７に示すように、第１値および第２値の２つの情報を有するという簡単な形式で構成されている。従って、検索条件を受け付けたときに、対応するインデックスを返す機能さえあれば、特にＲＤＢＭＳに限定する必要はない。このため、あるキーに対して値を返すといういわゆる検索エンジンを簡単に組み込むことができる。
【００８９】
図８は、文書管理装置１０の新規文書登録処理を示すフローチャートである。新規文書登録処理とは、構造化文書蓄積部１１に新たに文書を蓄積する処理である。
【００９０】
通信部１１０は、クライアントから文書を登録する旨の登録要求を受信し（ステップＳ１００）、要求振り分け部１０４に送る。要求振り分け部１０４が受け取った要求が登録要求である場合には（ステップＳ１０１，Ｙｅｓ）、登録部１０１が呼び出され、登録処理が開始する。
【００９１】
まず、登録部１０１は、構造化文書管理部２００の登録部２０１を介して、構造化文書蓄積部１１に対象となる構造化文書を登録する（ステップＳ１０２）。なお、本実施の形態においては、通信部１１０が、外部から、すなわち登録要求の送信元であるクライアントから構造化文書の全文を取得する。他の例としては、構造化文書を参照するためのファイルパスを取得する。この場合には、取得したファイルパスに基づいて、構造化文書を取得する。なお、構造化文書および構造化文書のファイルパスのいずれも取得できない場合には、通信部１１０は、クライアントに対して、エラーを返す。
【００９２】
次に、登録部１０１は、構造化文書蓄積部１１に登録した文書に対する構造化文書ＩＤを取得する（ステップＳ１０３）。本実施の形態においては、登録部１０１は、構造化文書管理部２００を介して、構造化文書のファイル名を構造化文書ＩＤとして構造化文書蓄積部１１から抽出する。
【００９３】
次に、登録部１０１は、通信部１１０を介して、構造化文書蓄積部１１に蓄積されている文書のインデックスリストを取得する（ステップＳ１０４）。次に、インデックス処理部３００の排他制御部３０５は、インデックス蓄積部１２に対して排他制御を行う（ステップＳ１０６）。具体的には、インデックス蓄積部１２は、一の要求に応じて処理を開始すると、当該処理が終了するまで、他の処理を受け付けない。
【００９４】
次に、インデックス処理部３００の追加部３０１が呼び出される。そして、追加部３０１は、当該構造化文書のインデックスをインデックス蓄積部１２に追加する（ステップＳ１１０）。次に、インデックス処理部３００の排他制御部３０５は、全てのインデックスに対する排他制御を解除する（ステップＳ１１２）。そして、総合管理部１００の通信部１１０は、クライアントに対して、登録処理が完了した旨を通知する（ステップＳ１１４）。以上で、登録処理が完了する。
【００９５】
図９は、図８におけるインデックス追加処理（ステップＳ１１０）における詳細な処理を示すフローチャートである。
【００９６】
インデックス追加処理では、まず、総合管理部１００の登録部１０１は、現在登録処理の対象となっている構造化文書が複数ある場合には、そのうちの一の構造化文書に対して、ＸＰａｔｈを指定する（ステップＳ２００）。そして、ＸＰａｔｈに対する返答として、インデックスリスト蓄積部１３から該当するＸＭＬノードの集合を取得する（ステップＳ２０１）。
【００９７】
具体的には、構造化文書と、第１値を指定して、インデックスへの追加を要求する。ここで、第１値は、例えば、「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」など、登録するノードの要素名である。
【００９８】
次に、未処理のノードがある場合には（ステップＳ２０２，Ｙｅｓ）、未処理のノードに対して絶対経路ＩＤを定義する（ステップＳ２０４）。次に、兄弟ノードが存在する場合には、経路内ＩＤを定義する（ステップＳ２０６）。すなわち、既に登録されているノードと今回登録するノードを兄弟とし、両者を識別する経路内ＩＤを定義する。
【００９９】
具体的には、ノードが既に１つ存在していた場合には、既に存在していたノードを今回登録するノードの兄ノードとし、当該兄ノードの同一経路内ＩＤを「１」と定義する。さらに、今回登録するノードの同一経路内ＩＤを「２」と定義する。
【０１００】
さらに、当該ノードに対する上位の階層がある場合には（ステップＳ２０８，Ｙｅｓ）、上位の階層のノードの経路内ＩＤ定義する（ステップＳ２０６）。以上、ステップＳ２０６およびステップＳ２０８の処理を繰り返し、今回登録するノードに対する上位の全ての階層におけるノードに対して経路内ＩＤを定義すると（ステップＳ２０８，Ｎｏ）、今回登録するノードの絶対経路ＩＤを決定する（ステップＳ２１０）。そして、今回登録するノードに対して割り当てられた絶対経路ＩＤをインデックス蓄積部１２に追加する（ステップＳ２１２）。さらに、インデックスリスト蓄積部１３に今回登録するノードのインデックスリストを追加する（ステップＳ２１４）。
【０１０１】
以上、ステップＳ２０４からステップＳ２１４の処理を、登録すべきノードに対して繰り返し（ステップＳ２０２）、全てのノードに対して処理が完了すると、ステップＳ１１０の処理が完了し、図８に示すステップＳ１１２へ進む。
【０１０２】
本実施の形態においては、構造的に連続した要素、すなわち、階層における深さ方向に対応したインデックスを作成する。従って、図１０に示す構造化文書に対してインデックスを追加する場合には、「Ｌｏｃａｔｉｏｎ」の子ノードが「Ｎａｍｅ」である場合のみインデックスを生成すると指定することにより、「Ｐａｔｔｅｒｎ」を含むノードを除外して、「東京」を含むノードのみをインデックス追加の対象として選択することができる。
【０１０３】
次に、図１１を参照しつつ、既に登録されているインデックスを削除する場合の処理について説明する。
【０１０４】
通信部１１０がクライアントから文書を削除する旨の削除要求を受信し（ステップＳ３００）、要求振り分け部１０４に送る。要求振り分け部１０４が受け取った要求が削除要求である場合に（ステップＳ３０１，Ｙｅｓ）、削除部１０２が呼び出され、処理が開始する。なお、削除要求には、削除の対象となる構造化文書の構造化文書ＩＤが含まれている。削除要求に構造化文書ＩＤが含まれていない場合には、クライアントに対してエラーを返す。
【０１０５】
まず、削除部１０２は、インデックスリスト蓄積部１３からインデックスリストを取得する（ステップＳ３０２）。次に、インデックス処理部３００の排他制御部３０５に対して、削除部１０２が取得したインデックスリストに含まれているインデックスの排他制御を要求する（ステップＳ３０３）。
【０１０６】
次に、インデックスリストの第２値、すなわち絶対経路ＩＤを参照し、絶対経路ＩＤに基づいてインデックス処理部３００の削除部３０２に削除すべき構造化文書ＩＤを指定する（ステップＳ３０４）。削除部３０２は、指定された構造化文書ＩＤにより特定されるインデックスをインデックス蓄積部１２から削除する（ステップＳ３０６）。具体的には、まず、構造化文書ＩＤが指定されて、削除部３０２が呼び出される。そして、削除条件として、インデックスの第２値の先頭文字列が「ｄｏｃｕｍｅｎｔ（”構造化文書”）」であるインデックスを指定して、インデックス蓄積部１２に対して削除を要求する。
【０１０７】
以上、ステップＳ３０４およびステップＳ３０６の処理を指定された全てのインデックスに対して行う（ステップＳ３０８）。
【０１０８】
インデックス蓄積部１２から全てのインデックスを削除した後（ステップＳ３０８，Ｙｅｓ）、構造化文書管理部２００の削除部２０２は、指定された構造化文書ＩＤにより特定される構造化文書を構造化文書蓄積部１１から削除する（ステップＳ３１０）。具体的には、まず構造化文書ＩＤを指定されて、削除部２０２が呼び出される。そして、構造化文書ＩＤにより特定される構造化文書を削除対象として、構造化文書蓄積部１１に削除を要求する。
【０１０９】
次に、インデックス処理部３００の排他制御部３０５は、全インデックスに対する排他制御を解除し（ステップＳ３１２）、さらに、総合管理部１００の通信部１１０は、削除処理が完了した旨をクライアントに通知する（ステップＳ３１４）。以上で、削除処理が終了する。
【０１１０】
以上のように、インデックスの第２値に対する条件が指定された削除の要求に対して、該当する値がリスト構造内に含まれている場合には、このインデックスを全て削除することができる。
【０１１１】
他の例としては、インデックスの第１値に対する条件が指定された削除の要求に対して、該当するインデックスを全て削除してもよい。また、インデックスの第１値に対する条件と第２値に対する条件とがそれぞれ指定された削除要求に対して、該当するインデックスを全て削除してもよい。
【０１１２】
次に、図１２を参照しつつ、更新処理について説明する。更新処理とは、構造化文書蓄積部１１に格納された構造化文書に対するインデックスの内容を更新する処理である。
【０１１３】
通信部１１０がクライアントからインデックスの内容を更新する旨の更新要求を受信し、要求振り分け部１０４に送る。要求振り分け部１０４は、更新要求を受け取ると、更新部１０３を呼び出し、処理が開始する。
【０１１４】
まず、更新部１０３は、更新要求に基づいて、指定された構造化文書ＩＤを指定し、構造化文書管理部２００の排他制御部２０５に対して排他制御を要求する（ステップＳ４００）。次に、インデックスリスト蓄積部１３からインデックスリストを取得する（ステップＳ４０２）。さらに、総合管理部１００の排他制御部３０５に対してインデックスリストに存在するインデックスに対して排他制御を要求する（ステップＳ４０４）。
【０１１５】
その後、構造化文書管理部２００の更新部２０３に対して、対象となる構造化文書の全文の更新を要求する（ステップＳ４０６）。そして、処理の結果得られた差分情報をインデックス処理部３００の更新部３０３に送り、インデックスを更新する旨要求する。なお、インデックスリストに存在する全てのインデックスに対して、インデックスを更新する旨要求する。
【０１１６】
次に、更新部３０３は、差分情報に基づいて、更新すべきインデックスを特定する（ステップＳ４０８）。すなわち、更新すべきインデックスの絶対経路ＩＤを特定する。そして、更新部３０３は、インデックス蓄積部１２に蓄積されているインデックス、すなわち絶対経路ＩＤを更新する（ステップＳ４１０）。なお、本実施の形態においては、更新条件と、差分情報に基づいて、インデックスが更新される。
【０１１７】
ここで、差分情報とは、構造化文書の構造単位である。そして、差分情報は、当該ノードの絶対経路ＩＤと共に示される。更新の対象が複数存在する場合は、複数の対象がリストとして表示される。
【０１１８】
所定のノードが完全に削除された場合、例えば、
ＤＥＬＥＴＥ：
ｄｏｃｕｍｅｎ（”ｓａｍｐｌｅ．ｘｍｌ”）／ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］／ＴｅｘｔＡｎｎｏｔａｔｉｏｎ［２］
と表される。また、所定のノードの値が変更された場合には、例えば、
ＣＨＡＮＧＥ：
ｄｏｃｕｍｅｎｔ（”ｓａｍｐｌｅ．ｘｍｌ”）／ＡｕｄｉｏＶｉｓｕａｌＳｅｇｅｍｎｔ［１］／ＴｅｘｔＡｎｎｏｔａｔｉｏｎ［３］／ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ［１］  修正後特許１
と表される。
【０１１９】
本発明におけるインデックスは、絶対経路ＩＤとその値のみを有する簡単な形式であり、絶対経路ＩＤも構造化文書の構造に基づいたものである。したがって、以下に示すように簡単にインデックスの更新処理を行うことができる。
【０１２０】
例えば、図１３に示すように、兄弟ノードに存在するデータ「特許１」、「特許２」、「特許３」、「特許４」のうち、「特許２」の「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」のノードが削除された場合には、「特許３」の「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」の絶対経路ＩＤの「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ［３］」の部分を、「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ［２］」に更新する。さらに、「特許４」の「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」の絶対経路ＩＤの「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ［４］」の部分を、「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ［３］」に更新する。このように、連続番号を変更するだけでよく、高速に更新処理を行うことができる。
【０１２１】
また、従来は、実際の構造化文書は、ノードが出現する位置、すなわち開始行目とインデント位置、終了行目とインデント位置の各情報を保持していた。そして、これらの情報により、問合せ結果のノードを取得した後、指定された問合せ結果ノードから相対経路で辿れるノードの値を取得していた。このため、構造化文書が変更された場合、構造化文書の構造とは無関係に、更新されたノードが出現する階層よりも下位の層の全てのインデックスを更新しなければならなかった。
【０１２２】
具体的には、例えば、要素「キーワード」における「キー」と「ワード」の間に改行を加えた場合には、ＸＭＬにおいて当該「キーワード」が記述された行以降のすべての内容を更新しなければならなかった。さらに、値ではなく、ノード単位の追加、削除に対してはこれに加えて、経路内ＩＤの変更も必要であった。これに対して、本実施の形態では、差分情報と、絶対経路ＩＤを更新するのみでよく、従来に比べて効率的に更新処理を行うことができる。
【０１２３】
なお、複数存在する場合であっても、リストの先頭から順に処理が行われた場合には、不整合が生じない。
【０１２４】
説明を図１２に戻す。すべてのインデックスに対して、ステップＳ４０８およびステップＳ４１０の処理が完了すると（ステップＳ４１２，Ｙｅｓ）、インデックス処理部３００の排他制御部３０５は、全インデックスに対する排他制御を解除し（ステップＳ４１４）、さらに、構造化文書管理部２００の排他制御部２０５は、指定された構造化文書に対する排他制御を解除する（ステップＳ４１６）。そして、総合管理部１００の通信部１１０は、更新処理が完了した旨をクライアントに通知する（ステップＳ４１８）。以上で、更新処理が終了する。
【０１２５】
次に、図１４を参照しつつ、インデックス定義処理について説明する。インデックス定義処理とは、インデックスリスト蓄積部１３に格納されているインデックスリストに新たにインデックスを定義する処理である。
【０１２６】
通信部１１０がクライアントからインデックスの内容を更新する旨の更新要求を受信し、要求振り分け部１０４に送る（ステップＳ５００）。要求振り分け部１０４は、受け取った要求がインデックス定義である場合には（ステップＳ５０２，Ｙｅｓ）、更新部１０３が呼び出され、インデックス定義処理が開始する。具体的には、更新部１０３は、インデックスリスト蓄積部１３に格納されているインデックスリストに対して、クライアントから指定されたインデックスを定義を追加する（ステップＳ５０４）。以上で、インデックス定義処理が終了する。
【０１２７】
次に、図１５を参照しつつ、検索処理について説明する。検索処理とは、クライアントから指定された検索条件に合致するインデックスをクライアントに返す処理である。
【０１２８】
まず、通信部１１０がクライアントから検索要求を受信し、要求振り分け部１０４に送る（ステップＳ６００）。要求振り分け部１０４は、受け取った要求が検索要求である場合には（ステップＳ６０１，Ｙｅｓ）、検索条件取得部１０５が呼び出され、検索処理が開始する。具体的には、検索条件取得部１０５は、検索要求に含まれる問い合わせ式を検索条件解析部１０６に送る。ここで、問い合わせ式とは、検索条件のことである。また、問い合わせ式は、インデックスの第１値と第２値のうち少なくとも一方に対応する条件が含まれている。
【０１２９】
次に、検索条件解析部１０６は、受け取った問い合わせ式を解析し（ステップＳ６０２）、解析された問合せ式、問合せキー、インデックスＩＤ（複数であればリスト）、要求された相対ノード式のリストを取得する（ステップＳ６０４）。
【０１３０】
ここで、相対ノード式とは、問い合わせ結果として特定されるノードのほかに、クライアントが取得したい情報を含むノードまでの相対経路である。すなわち、相対経路は、本発明における相対経路ＩＤに相当する。
【０１３１】
例えば、「ｄｏｃｕｍｅｎｔ（”ｓａｍｐｌｅ．ｘｍｌ”）／／ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ［ｃｏｎｔａｉｎｓ（ｔｅｘｔ（），”特許２”）］  」で記述される問い合わせ式１に対して返された結果に対し、クライアントがさらに当該ノードの近辺の情報も結果として得たい場合がある。先の問合せ式１の結果であるノードを＄Ｉとすると、その結果得られたノードの近辺の情報を要求する問い合わせ式２は、「＄Ｉ／．．／．．／．．／ＣｒｅａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ／Ｃｒｅａｔｉｏｎ／Ｔｉｔｌｅ」と記述することができる。このように、取得したいノードを、すでに特定したノードからの相対的な位置で表した経路情報が相対経路である。
【０１３２】
再び、説明を図１５に示すフローチャートに戻す。検索条件解析部１０６の解析の結果、インデックスに基づいて、指定された検索対象を特定できる場合には、その解析された問合せ式、問合せキー、インデックスＩＤの組（複数であればリスト）を指定して（ステップＳ６１０）、インデックス処理部３００の検索部３０４に検索を要求する（ステップＳ６１２）。この要求に対して、絶対経路ＩＤとその値の組を取得する。なお、このとき、照合部３１５による文字列の照合により、特定される。
【０１３３】
一方、検索条件解析部１０６における解析の結果、指定された検索対象をインデックスを利用して特定することができない場合には（ステップＳ６０８，Ｙｅｓ）、問合せ式を指定し、構造化文書管理部２００のノード値取得部２０４にノード値を要求する。これに対して、ノード値取得部２０４は、インデックス蓄積部１２から既に登録済みの構造化文書のノード値を取得する。なお、ノード値は、絶対経路ＩＤとその値の組である。また、該当するノードが複数ある場合には、そのリストである（ステップＳ６２０）。
【０１３４】
次に、ノード値取得部２０４は、問い合わせ式に該当するノードの絶対経路ＩＤと値のリストを取得する（ステップＳ６２２）。なお、全構造化文書から、問い合わせ式に該当する全てのノードを取得するまで繰り返し（ステップＳ６２４）、ステップＳ６３０に進む。
【０１３５】
次に、相対ノードパス数が０であれば（ステップＳ６３０，Ｎｏ）、絶対経路ＩＤとその値の組（複数であればリスト）をクライアントに返す（ステップＳ６３２）。相対ノードパス数が０でなければ（ステップＳ６３０，Ｙｅｓ）、相対ノード式リストを取得し（ステップＳ６４０）、相対ノード式リストとともに、絶対経路ＩＤとその値の組（複数であればリスト）をクライアントに返す（ステップＳ６３２）。以上で、検索処理が終了する。
【０１３６】
問い合わせ式に対する結果は、所定のノードを示すリストである。しかし、問合せ結果として、そのノードから相対経路によって辿れるノードが必要とされる場合もある。
【０１３７】
例えば、図５に示した構造化文書５１０に対して「“Ｍｏｖｉｅ”」を含む文字列を取得するという問い合わせ式、すなわち図１６（Ａ）に示す第１問い合わせ式５４０に対して、文字列「“Ｍｏｖｉｅ  Ｔｏｏｌサンプルストリーム”」、「“オープニングＭｏｖｉｅ”」、「“ＭｏｖｉｅＴｏｏｌの動作”」およびが結果として返される。
【０１３８】
この結果には、構造化文書における構造に関する情報が含まれていないので、例えば、この問い合わせの後、さらに「”ＭｏｖｉｅＴｏｏｌサンプルストリーム”」の上位の階層の情報を取得したい場合に、再度同様の問い合わせを行わなければならない。すなわち、再度図１６（Ｂ）の第２問い合わせ式５４２を指定して同様の処理を行う必要があり、手続きが面倒であった。
【０１３９】
これに対して、図１５を参照しつつ説明した本実施の形態における検索処理によれば、文書管理装置１０は、図１６（Ａ）に示される第１問い合わせ式５４０に対して、文字列「”ＭｏｖｉｅＴｏｏｌサンプルストリーム”」と「”オープニングＭｏｖｉｅ”」が結果として返されるとともに、これらの絶対経路ＩＤが返される。また、この相対経路を自動的に絶対経路ＩＤに変換するので、利用者は、第２の問い合わせ式を改めて指定する必要はなく、手続きを簡略化することができる。
【０１４０】
以上のように、インデックスの第１値および第２値の少なくとも一方に対する条件が指定された検索条件に対して、該当する値がリスト構造内に含まれている場合には、このインデックスを全て検索結果として返すことができる。
【０１４１】
また、検索条件として、複数の検索条件と、各検索条件に対する論理演算子とを取得した場合には、まず各検索条件とインデックス蓄積部１２に管理されているインデックスとをそれぞれ照合する。そして、照合結果に基づいて、各検索条件に合致する前記インデックスをそれぞれ特定する。さらに、各検索条件に対して特定した複数のインデックスに対し、論理演算子を用いた論理演算を行い、当該論理演算の結果得られたインデックスを、検索条件に合致する前記インデックスとして特定する。
【０１４２】
さらに、検索条件として取得したインデックスは文字列で構成されているので、各検索条件の文字列とインデックス蓄積部１２に蓄積されているインデックスに含まれる文字列とを照合し、文字列の照合の結果に基づいて、各検索条件に合致する前記インデックスをそれぞれ特定する。そして、特定した複数のインデックス間で文字列を照合することにより論理演算を行う。そして、当該論理演算の結果得られたインデックスを、検索条件に合致するインデックスとして特定する。
【０１４３】
図１７は、図１５において説明した相対ノード値取得ステップ（ステップＳ６４０）における詳細な処理を示すフローチャートである。
【０１４４】
総合管理部１００の検索条件取得部１０５は、既に取得している絶対経路ＩＤと相対ノード式リストのうちから（ステップＳ７００）、最初に処理すべき一の絶対経路ＩＤを取得する（ステップＳ７０２）。さらに、最初に処理する相対ノード式を取得する（ステップＳ７０４）。そして、取得した絶対経路ＩＤと相対ノード式に基づいて、絶対経路で示された問い合わせ式を生成する（ステップＳ７０６）。
【０１４５】
図１８（Ａ）は、検索条件取得部１０５が取得した絶対経路ＩＤリストの一例を示している。また、図１８（Ｂ）は、検索条件取得部１０５は取得した相対ノード式リストの一例を示している。図１８（Ａ）に示す絶対経路ＩＤ６００のそれぞれと図１８（Ｂ）に示す相対ノード式リストとの組み合わせからそれぞれ問い合わせ式が生成される。
【０１４６】
図１９は、図１８に示す絶対経路ＩＤと相対ノード式リストから生成された問い合わせ式リストを示している。図１９（Ａ）に示す問い合わせ式リスト６２０のうち上から１行目から３行目の問い合わせ式６２２は、絶対経路ＩＤリスト６００の１行目の絶対経路ＩＤと、相対ノード式リスト６１０とにより生成された問い合わせ式である。また、４行目から６行目の問い合わせ式６２４は、絶対経路ＩＤリスト６００の２行目の絶対経路ＩＤと、相対ノード式リスト６１０とにより生成された問い合わせ式である。
【０１４７】
また、図１９（Ｂ）は、図１９（Ａ）に示す問い合わせ式を簡略化した簡略問い合わせ式リスト６３０を示している。このように、問い合わせ式の簡略化して表現してもよい。
【０１４８】
再び、説明を図１６に戻す。問い合わせ式が生成されると（ステップＳ７０６）、構造化文書管理部２００のノード値取得部２０４は、生成された問い合わせ式に基づいて、ノード値を取得する（ステップＳ７０８）。総合管理部１００の検索条件取得部１０５は、現在対象としている絶対経路ＩＤに対し、未処理の相対ノード式がある場合には（ステップＳ７１０，Ｎｏ）、次の相対ノード式を取得し（ステップＳ７１２）、再び問い合わせ式を生成する（ステップＳ７０６）。以上、全ての相対ノード式について生成した問い合わせ式に対するノード値を取得するまで、ステップＳ７０６およびステップＳ７１０の処理を繰り返す（ステップＳ７１０）。
【０１４９】
全ての相対ノード式について処理が完了すると（ステップＳ７１０，Ｙｅｓ）、次の絶対経路ＩＤに対して、同様の処理を行う。すなわち、未処理の絶対経路ＩＤがある場合には（ステップＳ７２０，Ｎｏ）、次の絶対経路ＩＤを取得し（ステップＳ７２２）、取得した絶対経路ＩＤに対して組み合わせる一の相対ノード式を再び取得する（ステップＳ７０４）。以上、全ての絶対経路ＩＤについて生成した問い合わせ式に対するノード値を取得するまで、ステップＳ７０４からステップＳ７２０の処理を繰り返す。以上で、相対ノード値取得処理が終了する。
【０１５０】
このように、ノード値取得部２０４は、指定された問合せ式に基づいて、一つの構造化文書から、該当するノードの絶対経路ＩＤとその値を取得することができる。
【０１５１】
一般に問合せの対象となる構造化文書の数が増えると、すなわち、構造化文書蓄積部１１に蓄積されている構造化文書の数が増えると、構造化文書の数の増加に伴って、ファイルＩ／ＯやＤＯＭツリー生成の問題で処理時間が長くなる。
【０１５２】
これに対して、本実施の形態おいては、図１５から図１７を参照しつつ説明したように、インデックスを利用できる場合は、必ずインデックスを利用して問合せを行うので、処理時間を短縮することができる。
【０１５３】
クライアントが問合せの結果の件数を得て、その問合せ結果の詳細な情報を得たい場合、その件数は、１０件程度であることが多い。１０件程度であれば、仮に全て別の構造化文書であったとしても、全構造化文書から値を取得したり、多数のインデックスからノード値を取得するよりも、相対ノード式によってノード値を取得するほうが高速に処理が行えるためである。
【０１５４】
次に、図１５において説明した問い合わせ式解析処理（ステップＳ６０２）について、図２０を参照しつつ詳細に説明する。図２０は、問い合わせ式の一例を示している。
【０１５５】
総合管理部１００の検索条件解析部１０６は、まず、問い合わせ式をインデックスを利用できる可能性のある単位に分解する。具体的には、以下の順序で処理を行う。
Ｓｔｅｐ１  問い合わせ式本体と相対ノード式とを分解する
Ｓｔｅｐ２  問合せ式本体をＡｘｉｓ（軸）ごとに分解する
Ｓｔｅｐ３  各Ａｘｉｓ毎の属性情報を取得する。
ここで、属性情報とは、要素名、軸方向と数、述語種（比較演算子）とその値のことである。属性情報のうち要素名とは、「Ｗｈｏ」、「Ｎａｍｅ」などであり、「．．」や「ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ：：」は空のノードと見なされる。軸方向とは、そのパスが構造のどちらに向いているかを示すもので、要素名だけであれば、軸方向は“下り”で、その数１であることを示している。
【０１５６】
また、「．．」であれば軸方向“上り”その数１となり、ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ：：ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］であれば軸方向“上り”その数１となる。述語種とは、「ｃｏｎｔａｉｎｓ（ｔｅｘｔ（），）」などその問合せ条件に該当し、その問合せキーは「東京」となる。述語に該当するものがない場合は空となる。
【０１５７】
まず、図２０に示す問い合わせ式の問い合わせ式本体「ｄｏｃｕｍｅｎｔ（”ｓａｍｐｌｅ．ｘｍｌ”）／／Ｗｈｏ／Ｎａｍｅ［ｃｏｎｔａｉｎｓ（ｔｅｘｔ（），”山田”）］／．．／．．／Ｗｈｅｒｅ／Ｎａｍｅ（ｃｏｎｔａｉｎｓ（ｔｅｘｔ（），”東京”）］／ａｎｃｅｓｔｏｒ−ｏｒ−ｓｅｌｆ：：ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］」と残りの部分、すなわち相対ノード式とを分離する。さらに、問い合わせ式本文は、「／」文字で区切られた軸毎に分解され、その属性情報が取得される。分解されたＡｘｉｓは以下の条件によって、まとめられる。解析の結果まとめられたものを軸集合と呼ぶ。
Ｃｏｎｄｉｔｉｏｎ１  軸方向が上りの軸と、軸方向が下りの軸を分岐点としてまとめる。
Ｃｏｎｄｉｔｉｏｎ２  軸方向が下りで述語種が空ではない軸と、軸方向が下りの軸を分岐点としてわける。
【０１５８】
各軸集合の中で以下の条件を満たすものが、インデックスを利用できる軸の候補となる。
１  述語種が空でないもの
２  次の軸の軸方向が上りである軸方向が下りの軸
インデックスを利用できる候補の軸の要素名を条件にし、インデックスリストにインデックスＩＤを取得する。その際、前の軸が下りでその数が１の場合は、その要素名も連結し、そのインデックスが存在すればそちらを採用する。例えば、ＮａｍｅよりもＷｈｏ／Ｎａｍｅのインデックスを優先する。
【０１５９】
インデックスＩＤが存在しない場合、その要素名に対するインデックスは存在しないことになり、利用可能なインデックスが存在しないという結果を返す。存在すれば、そのインデックスＩＤ、解析した問合せ式、相対ノード式を返す。
【０１６０】
続いて、インデックス処理部３００の検索部３０４は、解析された問合せ式（軸集合）、問合せキー、インデックスＩＤの組（複数であればリスト）の指定に基づいて、各組毎に、インデックス蓄積部１２対して問合せキーを第１値の条件として取得を要求する。そして、該当するものがあればその値と絶対経路ＩＤの組のリストを取得する。これを各組毎に繰り返す。
【０１６１】
ここで、値と絶対経路ＩＤの組のリストを取得する方法について詳述する。例えば、問い合わせ式が、論理積演算である場合には、そのリストの絶対経路ＩＤが重複するもののみ結果として取得する。また、論理和演算であれそのリストの絶対経路ＩＤが重複するものを一つだけ結果として取得する。
【０１６２】
図３に示した構造化文書に対して、図２１に示す問い合わせ式が指定された場合の処理を例に説明する。
【０１６３】
図２１に示すように、２つの条件の論理積である場合、まず、各条件に合致するノードの絶対経路ＩＤを取得する。図２１に示す２つの条件に対しては、結果１の絶対経路ＩＤ「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］  ／  Ｃｒｅａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ［１］  ／  Ｃｒｅａｔｉｏｎ［１］  ／  Ｔｉｔｌｅ［１］」、結果２の絶対経路ＩＤ「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［２］  ／  ＣｒｅａｔｉｏｎＩｎｆｏｒｍａｔｉｏｎ［１］  ／  Ｃｒｅａｔｉｏｎ［１］  ／  Ｔｉｔｌｅ［１］」、および結果３の絶対経路ＩＤ「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］  ／  ＴｅｍｐｏｒａｌＤｅｃｏｍｐｏｓｉｔｉｏｎ［１］  ／  ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］  ／  ＴｅｍｐｏｒａｌＤｅｃｏｍｐｏｓｉｔｉｏｎ［１］  ／  ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］  ／  ＴｅｘｔＡｎｎｏｔａｔｉｏｎ［１］  ／  ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ［１］」を取得する。
【０１６４】
以上、結果１から結果３の論理積を求め、問合せ式を満たす「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ」を取得するためには、
【０１６５】
▲１▼  結果１の絶対経路ＩＤの先頭側の文字列「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］」と結果３の絶対経路ＩＤの先頭側文字列「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］」までを比較し、等しいので問い合わせ式を満たす。
▲２▼  結果１の絶対経路ＩＤの先頭側の文字列「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［２］」と結果３の絶対経路ＩＤの先頭側文字列「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ［１］」までを比較し、等しいので問い合わせ式を満たす。
以上、２回の文字列処理、すなわち、文字列の照合により問い合わせ式に指定された論理演算を行うことができる。
【０１６６】
なお、従来は、問合せ式に該当する２つの「Ｔｉｔｌｅ」ノードと１つの「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」ノードを取得することはできるが、両方の条件を満たした「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ」要素を取得するためには、まず「Ｔｉｔｌｅ」ノードを取得し、ポインタで「ＡｕｄｉｏＶｉｓｕａｌＳｅｇｍｅｎｔ」まで辿り、更に総当りで計五つの「ＦｒｅｅＴｅｘｔＡｎｎｏｔａｔｉｏｎ」が条件を満たすか問合せる必要がある。
【０１６７】
以上のように、経路が異なる複数の経路情報も含めた問合せ式が複合されている論理積演算の処理に対し、本実施の形態においては、インデックスに含まれた絶対経路ＩＤの文字列処理のみで行うことができる。従って、従来のようにポインタを辿る処理に比べて処理を効率化することができる。
【０１６８】
図２２は、文書管理装置１０のハードウェア構成を示す図である。文書管理装置１０は、ハードウェア構成として、文書管理装置１０における文書管理の処理を実行するプログラムなどが格納されているＲＯＭ５２、ＲＯＭ５２内のプログラムに従って文書管理装置１０の各部を制御し、文書管理等を実行するＣＰＵ５１、ワークエリアが形成され、文書管理装置１０の制御に必要な種々のデータが記憶されているＲＡＭ５３、ネットワークに接続して、通信を行う通信Ｉ／Ｆ５７、および各部を接続するバス６２を備えている。
【０１６９】
先に述べた文書管理装置１０における文書管理処理を実行する文書管理プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フロッピー（Ｒ）ディスク（ＦＤ）、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
【０１７０】
また、本実施形態の文書管理プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。
【０１７１】
この場合には、文書管理プログラムは、文書管理装置１０において上記記録媒体から読み出して実行することにより主記憶装置上にロードされ、上記ソフトウェア構成で説明した各部が主記憶装置上に生成されるようになっている。
【０１７２】
（実施の形態２）
次に、実施の形態２にかかる文書管理装置１０について説明する。図２３は、実施の形態２にかかる文書管理装置１０の構成を示すブロック図である。
【０１７３】
実施の形態２にかかる文書管理装置１０は、実施の形態１にかかる文書管理装置１０の構造化文書蓄積部１１にかえて構造化文書ファイルパス蓄積部１４を備える。また、構造化文書管理部２００の排他制御部２０５、インデックス処理部３００の排他制御部３０５を備えない。また、総合管理部１００は、インデックスリスト１２に蓄積されているインデックスリストを再構築するインデックス再構築部１１１を備える。
【０１７４】
構造化文書ファイルパス蓄積部１４は、構造化文書にかえて、構造化文書へのファイルパスを蓄積している。構造化文書ファイルパス蓄積部１４は、構造化文書の追加要求に対して、構造化文書ファイルパスを蓄積する。なお、ノード値取得部２０４からの取得要求に対して、構造化文書を識別するための構造化文書ＩＤは、各構造化文書ファイルパスである。構造化文書ファイルパスは、ファイルとして蓄積されてもよく、また他の例としては、メモリ上に蓄積されてもよい。
【０１７５】
構造化文書ファイルパス蓄積部１４は、構造化文書ＩＤを指定された取得要求に対し、該当する構造化文書ファイルパスが存在すれば、該当する構造化文書ファイルパスを返す。また、構造化文書ＩＤを指定された削除要求に対し、該当する構造化文書ファイルパスが存在すれば、その構造化文書ファイルパスを削除し、管理対象から除く。本実施の形態における構造化文書ファイルパス蓄積部１４は、計算機のファイルシステムで構成されている。なお、他の例としては、構造化文書ファイルパス蓄積部１４は、データベースであってもよい。
【０１７６】
なお、構造化文書管理部２００の登録部２０１、削除部２０２、および更新部２０３は、構造化文書ファイルパス蓄積部１４に蓄積されている構造化文書ファイルパスに対してそれぞれ所定の処理を行う。
【０１７７】
実施の形態２においては、総合管理部１００の要求振り分け部１０４が受け付ける要求種にインデックス再構築が加えられる。要求振り分け部１０４がインデックス再構築の要求を取得した場合、総合管理部１００のインデックス再構築部１１１が呼び出される。
【０１７８】
このときの基本的な処理は、図８から図１１を参照しつつ説明した実施の形態１にかかる文書管理装置１０の処理と同様であるが、実施の形態２においては、排他制御は行われない。
【０１７９】
なお、実施の形態２においては、構造化文書ＩＤは、構造化文書が参照できるファイルパスに固定される。また、構造化文書への操作は、そのファイルパスを参照して行う。
【０１８０】
総合管理部１００のインデックス再構築部１１１は、要求振り分け部１０４から要求を受け、削除部３０２に対して全ノードのインデックス削除を要求する。その後、ノード値取得部２０４に対して、全構造化文書のファイルパス取得の要求を行い全構造化文書のファイルパスを取得し、インデックスリスト蓄積部１３からインデックスリストを取得する。その後、インデックス処理部３００の追加部３０１は、インデックスリストに定義されている数の分のインデックスを追加する。なお、この処理を全構造化文書に対して行う。
【０１８１】
なお、これ以外の文書管理装置１０の構成および動作は、図１から図２０を参照しつつ説明した実施の形態１にかかる文書管理装置１０の構成および動作と同様である。
【０１８２】
本実施の形態においては、全インデックスを再構築しているが、構造化文書ファイルパス蓄積部１４において、各ファイルパスに対応して、最終更新日時とファイルサイズ、ＵＮＩＸ（Ｒ）ファイルシステムでいうＩノードなど、その構造化文書のファイルが更新された事を確認できる情報も保持し、インデックス再構築要求時に更新された構造化文書のみのインデックスを削除、再構築するということも容易に考えられる。
【０１８３】
（実施の形態３）
次に、実施の形態３にかかる文書管理装置１０について説明する。図２４は、実施の形態３にかかる文書管理装置１０の構成を示すブロック図である。
【０１８４】
実施の形態３にかかる文書管理装置１０は、実施の形態１において説明したインデックス処理部３００とインデックス蓄積部１２とを複数備えている。すなわち、実施の形態３にかかる文書管理装置１０は、インデックスを蓄積する第１インデックス蓄積部１２１、第２インデックス蓄積部１２２、および第３インデックス蓄積部１２３と、各蓄積部に蓄積されているインデックスに対し、それぞれ処理を行う、第１インデックス処理部３００、第２インデックス処理部３１０、および第３インデックス処理部３２０とを備えている。
【０１８５】
さらに、実施の形態３においては、第１インデックス処理部３００および第１インデックス蓄積部１２１は、文字列専用である。また、第２インデックス処理部３１０および第２インデックス蓄積部１２２は、数値専用である。また、第３インデックス処理部３２０および第３インデックス蓄積部１２３は、画像特徴量専用である。
【０１８６】
このように、複数のインデックス処理部およびインデックス蓄積部を有しているので、データの種類に応じて、複数のインデックス処理部およびインデックス蓄積部を使い分けることができる。
【０１８７】
なお、どの場合にどのインデックス処理部を利用するかは、インデックスリスト蓄積部が保持しているインデックスＩＤにより決定される。
【０１８８】
これ以外の文書管理装置１０の構成および動作は、図１から図２２を参照しつつ説明した実施の形態１にかかる文書管理装置１０の構成および動作と同様である。
【０１８９】
また、実施の形態３においては、複数のインデックス蓄積部それぞれに対応してインデックス処理部が設けられていたが、他の例としては、複数のインデックス蓄積部に対して一のインデックス処理部が設けられていてもよい。この場合にも、処理を効率化することができる。
【０１９０】
以上、本発明を実施の形態を用いて説明したが、上記実施の形態に多様な変更または改良を加えることができる。
【０１９１】
【発明の効果】
以上説明したように、請求項１にかかる発明によれば、特定した要素が構造化文書内のいずれの位置に格納されているのかを把握することができるので、例えば、さらに他の要素を特定する場合に、既に特定している要素の位置を基準とした、他の要素までの相対経路に基づいて他の要素を特定することができる。このように、特定した要素の位置に基づいて、検索処理を行うことにより、処理の効率化を図ることができるという効果を奏する。
【０１９２】
また、請求項２にかかる発明によれば、インデックス管理手段は、要素とともにインデックスを特定することができる。また、このインデックスは、構造化文書における要素の位置を示しているので、これにより、要素の位置を把握することができる。このように、特定した要素の位置に基づいて、処理を行うことにより、処理の効率化を図ることができるという効果を奏する。
【０１９３】
また、請求項３にかかる発明によれば、インデックスは要素の位置を示しているので、要素の位置を示す検索条件を取得した場合には、検索条件とインデックスとの照合結果に基づいて、検索条件に合致する要素を特定することができる。従って、より効率的に検索対象を特定することができるという効果を奏する。
【０１９４】
また、請求項４にかかる発明によれば、同一の経路で特定される要素が複数ある場合、すなわち一の親ノードに対して、複数の子ノードが存在するような構成であっても、複数の要素それぞれを識別することができる。従って、すべての要素を正確に識別することができるという効果を奏する。
【０１９５】
また、請求項５にかかる発明によれば、検索条件が要素位置特定経路情報および経路内要素特定情報のうち少なくとも一方を含む場合には、当該検索条件とインデックスとを照合することによって、検索条件に合致する要素を特定することができる。従って、より効率的に検索対象を特定することができるという効果を奏する。
【０１９６】
また、請求項６にかかる発明によれば、インデックスと検索対象との照合により検索対象を特定することができるので、処理効率を向上させることができるという効果を奏する。
【０１９７】
また、請求項７にかかる発明によれば、文字列照合の結果を利用することにより、検索処理の効率を向上させることができるという効果を奏する。
【０１９８】
また、請求項８にかかる発明によれば、絶対経路特定手段は、前回特定したインデックスと、検索条件取得手段が取得した相対経路に基づいて、次に特定すべき要素の絶対経路、すなわちインデックスを特定することができるので、検索条件を解析して構造化文書の根から検索を開始する場合に比べて、検索処理の効率を向上させることができるという効果を奏する。
【０１９９】
また、請求項９にかかる発明によれば、  この請求項９の発明によれば、絶対経路特定手段によって特定された絶対経路に基づいて、検索条件に合致する要素を特定することができる。すなわち、絶対経路を取得しなくとも、相対経路から特定した絶対経路に基づいて、要素を特定することができるという効果を奏する。
【０２００】
また、請求項１０にかかる発明によれば、前回特定したインデックスと今回特定したインデックスとの排他論理和を算出することにより、相対経路を特定することができる。すなわち、比較的簡単な処理により相対経路を特定することができるという効果を奏する。
【０２０１】
また、請求項１１にかかる発明によれば、検索条件に合致するとして抽出した要素と、当該要素のインデックスとを対応付けて出力するので、ユーザは、要素が構造化文書のいずれの位置に格納されているのかを把握することができるという効果を奏する。
【０２０２】
また、請求項１２にかかる発明によれば、インデックス蓄積手段に蓄積されているインデックスを更新する更新手段をさらに備えているので、インデックスを自由に更新することができるという効果を奏する。
【０２０３】
また、請求項１３にかかる発明によれば、インデックス蓄積手段に蓄積されているインデックスの登録および削除を行う登録削除手段をさらに備えているので、インデックスを自由に登録および削除することができるという効果を奏する。
【０２０４】
また、請求項１４にかかる発明によれば、更新手段が一の処理を行っているときに、排他制御手段は、他の処理を排除するので、複数の処理が同時に行われることにより、不適切な更新が行われるのを避けることができるという効果を奏する。
【０２０５】
また、請求項１５にかかる発明によれば、一の処理により、他のデータとの整合性がとれなくなるのを回避することができるという効果を奏する。
【０２０６】
また、請求項１６にかかる発明によれば、インデックスは要素の位置を示しているので、要素の位置を示す検索条件を取得した場合には、検索条件とインデックスとの照合結果に基づいて、検索条件に合致する要素を特定することができる。従って、より効率的に検索対象を特定することができるという効果を奏する。
【０２０７】
また、請求項１７にかかる発明によれば、複数のインデックス蓄積手段を備えているので、処理の効率化図ることができるという効果を奏する。
【０２０８】
また、請求項１８にかかる発明によれば、複数のインデックス蓄積手段と、各インデックス蓄積手段を管理する複数のインデックス管理手段とを備えているので、分散処理が可能となり、処理の効率化を図ることができるという効果を奏する。
【０２０９】
また、請求項１９にかかる発明によれば、インデックスは要素の位置を示しているので、要素の位置を示す検索条件を取得した場合には、検索条件とインデックスとの照合結果に基づいて、検索条件に合致する要素を特定することができる。従って、より効率的に検索対象を特定することができるという効果を奏する。
【０２１０】
また、請求項２０にかかる発明によれば、特定した要素が構造化文書内のいずれの位置に格納されているのかを把握することができるので、例えば、さらに他の要素を特定する場合に、既に特定している要素の位置を基準とした、他の要素までの相対経路に基づいて他の要素を特定することができる。このように、特定した要素の位置に基づいて、検索処理を行うことにより、処理の効率化を図ることができるという効果を奏する。
【０２１１】
また、請求項２０にかかる発明によれば、特定した要素が構造化文書内のいずれの位置に格納されているのかを把握することができるので、例えば、さらに他の要素を特定する場合に、既に特定している要素の位置を基準とした、他の要素までの相対経路に基づいて他の要素を特定することができる。このように、特定した要素の位置に基づいて、検索処理を行うことにより、処理の効率化を図ることができるという効果を奏する。
【図面の簡単な説明】
【図１】実施の形態１である文書管理装置１０の構成を示すブロック図である。
【図２】構造化文書蓄積部１１に蓄積されている構造化文書のデータ構成を模式的に示す図である。
【図３】ＭＰＥＧ−７で記述した構造化文書を示す図である。
【図４】動画データにおける一部のデータを指定する記述を示す図である。
【図５】実施の形態１における動画データの構造化文書５１０を示す図である。
【図６】ＸＰａｔｈ式により示された絶対経路ＩＤを示す図である。
【図７】インデックス蓄積部１２に格納されているインデックスのデータ構造を示す図でる。
【図８】文書管理装置１０の新規文書登録処理を示すフローチャートである。
【図９】図８におけるインデックス追加処理（ステップＳ１１０）における詳細な処理を示すフローチャートである。
【図１０】構造化文書を示す図である。
【図１１】文書管理装置１０の削除処理を示すフローチャートである。
【図１２】文書管理装置１０の更新処理を示すフローチャートである。
【図１３】インデックスの削除を説明するための図である。
【図１４】文書管理装置１０のインデックス定義処理を示すフローチャートである。
【図１５】文書管理装置１０の検索処理を示すフローチャートである。
【図１６】図１５において説明した相対ノード値取得ステップ（ステップＳ６４０）における詳細な処理を示すフローチャートである。
【図１７】問い合わせ式を示す図である。
【図１８】絶対経路ＩＤリストの一例を示す図である。
【図１９】図１８に示す絶対経路ＩＤと相対ノード式リストから生成された問い合わせ式リストを示す図である。
【図２０】問い合わせ式の一例を示す図である。
【図２１】問い合わせ式の一例を示す図である。
【図２２】文書管理装置１０のハードウェア構成を示す図である。
【図２３】実施の形態２に係る文書管理装置１０の構成を示すブロック図である。
【図２４】実施の形態３に係る文書管理装置１０の構成を示すブロック図である。
【符号の説明】
１０  文書管理装置
１１  構造化文書蓄積部
１２  インデックス蓄積部
１３  インデックスリスト蓄積部
１４  構造化文書ファイルパス蓄積部
１００  総合管理部
１０１  登録部
１０２  削除部
１０３  更新部
１０５  検索条件取得部
１０６  検索条件解析部
１１０  通信部
１１１  インデックス再構築部
１２１  第１インデックス蓄積部
１２２  第２インデックス蓄積部
１２３  第３インデックス蓄積部
２００  構造化文書管理部
２０１  登録部
２０２  削除部
２０３  更新部
２０４  ノード値取得部
２０５  排他制御部
３００  インデックス処理部
３０１  追加部
３０２  削除部
３０３  更新部
３０４  検索部
３０５  排他制御部
３０６  相対経路特定部
３１５  照合部
３１１  要素特定部
３１２  候補特定部
３１４  論理演算部
【図１】
2004310607.tif 000003
【図２】
2004310607.tif 000004
【図３】
2004310607.tif 000005
【図４】
2004310607.tif 000006
【図５】
2004310607.tif 000007
【図６】
2004310607.tif 000008
【図７】
2004310607.tif 000009
【図８】
2004310607.tif 000010
【図９】
2004310607.tif 000011
【図１０】
2004310607.tif 000012
【図１１】
2004310607.tif 000013
【図１２】
2004310607.tif 000014
【図１３】
2004310607.tif 000015
【図１４】
2004310607.tif 000016
【図１５】
2004310607.tif 000017
【図１６】
2004310607.tif 000018
【図１７】
2004310607.tif 000019
【図１８】
2004310607.tif 000020
【図１９】
2004310607.tif 000021
【図２０】
2004310607.tif 000022
【図２１】
2004310607.tif 000023
【図２２】
2004310607.tif 000024
【図２３】
2004310607.tif 000025
【図２４】
2004310607.tif 000026