JP3644765B2 - 文書管理方式および文書管理方法 - Google Patents
文書管理方式および文書管理方法 Download PDFInfo
- Publication number
- JP3644765B2 JP3644765B2 JP19054496A JP19054496A JP3644765B2 JP 3644765 B2 JP3644765 B2 JP 3644765B2 JP 19054496 A JP19054496 A JP 19054496A JP 19054496 A JP19054496 A JP 19054496A JP 3644765 B2 JP3644765 B2 JP 3644765B2
- Authority
- JP
- Japan
- Prior art keywords
- document
- data
- search
- character
- component
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、文書管理方式および文書管理方法に係わり、特に、文字成分表を利用して全文書に対して文字列を検索する装置に関するものである。
【０００２】
【従来の技術】
従来の文書管理方式では、文書管理部を一体化しており、そのため、システムで規定する文書ＩＤのみしか利用できない。したがって、既存の文書管理部を持つアプリケーションと組み合わせる場合に文書データを二重に管理したり、文書ＩＤを統一したりしなければならない。また、実際の文書検索を行う場面では、必ずしも文書全体を検索対象とせず、文書内の特定の領域のみに対して検索要求があるが、このような要求に対応できない。
【０００３】
【発明が解決しようとする課題】
上述のように、従来の方法では様々なデータ形態を持つ文書データ及び文書ＩＤに容易に対応ができない。また従来の方法では文書中の一部の領域及び複数の領域を対象に検索することができない。
【０００４】
【課題を解決するための手段】
請求項１の発明は、指定された検索文字列を含む文書を検索し、その検索結果を出力する文書検索ライブラリを構成する文書管理方式であって、指定された文書ＩＤに対する文書データを取得する文書取得関数と、動的に渡された前記文書取得関数を用いて、指定された文書ＩＤに対する文書データを取得し、該取得した文書データより各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成して、インデックスデータ部へ登録する登録処理部と、指定された検索語を前記登録処理と同様に文字成分に分解し、前記インデックスデータ部に登録された文字成分表を用いて文書を検索し、当該検索結果の文書を出力する検索処理部とを有し、前記登録処理部は、動的に渡された前記文書取得関数を通して文書ＩＤに対応する文書データを取得するようにして、本文書管理方式の文書検索部分と前記文書データを保持管理する部分とを分離し、多様なアプリケーションに対応可能としたことを特徴としたものである。
【０００５】
請求項２の発明は、請求項１の発明において、前記登録処理部は、前記指定された文書ＩＤをバイナリ列で表し、当該登録処理部内では該文書ＩＤの代わりに内部文書ＩＤで管理するようにし、該内部文書ＩＤと前記バイナリ列とを対応付けて保持する文書ＩＤテーブルを有することで、アプリケーション依存する多様な文書ＩＤに対応可能としたことを特徴としたものである。
【０００６】
請求項３の発明は、指定された検索文字列を含む文書を検索し、その検索結果を出力する文書検索ライブラリを用いる文書管理方法であって、指定された文書ＩＤに対する文書データを取得する文書取得関数を用意し、文書を登録する際には、動的に渡された前記文書取得関数を用いて、指定された文書ＩＤに対する文書データを取得し、該取得した文書データより各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成して、インデックスデータ部へ登録し、指定された検索語を前記文書の登録と同様に文字成分に分解し、前記インデックスデータ部に登録された文字成分表を用いて文書を検索し、当該検索結果の文書を出力するようにして、本文書管理方法の文書検索部分と前記文書データを保持管理する部分とを分離し、多様なアプリケーションに対応可能としたことを特徴としたものである。
【０００７】
請求項４の発明は、請求項３の発明において、前記登録処理を行うときには、前記指定された文書ＩＤをバイナリ列で表し、当該登録処理部内では該文書ＩＤの代わりに内部文書ＩＤで管理するようにし、該内部文書ＩＤと前記バイナリ列とを対応付けて文書ＩＤテーブルに保持することによって、アプリケーション依存する多様な文書ＩＤに対応可能としたことを特徴としたものである。
【０００８】
【発明の実施の形態】
図１は、本発明による文書管理方式が適用される一実施例を説明するための構成図で、図中、１は入力部、２は出力部、３は登録処理部、４は検索処理部、５は外部文書管理部、６はインデックスデータ部、７は文書データ部である。本文書管理方式は、図１のうち、登録処理部３、検索処理部４、インデックスデータ部６から構成される。
【０００９】
文書登録時には、入力部１に入力された文書ＩＤを、登録処理部３において外部文書管理部５を介して文書データ部７から文書データを取得して、該文書データに内部文書ＩＤを付加し、該文書データから文字成分を抽出し、インデックスデータ部６に内部文書ＩＤに対応させて文字成分を登録するとともに、文書ＩＤテーブル６２に文書ＩＤを内部文書ＩＤと対応付けて登録する。
【００１０】
文書検索時には、検索処理部４はインデックスデータ部６の文字成分表６１により、入力部１に入力された検索文字列を含む文書を検索し、文書ＩＤテーブル６２から文書ＩＤを得て、出力部２は文書データ部７から文書管理部５を介して文書ＩＤに対応する文書データを取得して出力する。
【００１１】
以下の説明では対象文書は１バイト文字コード（例えば、ＡＳＣＩＩ）及び２バイト文字コード（ＥＵＣ：Extended ＵＮＩＸ ＣＯＤＥ）からなるテキストデータとする。しかし、対象とする文字コードはＥＵＣ以外にも容易に適用可能である。
【００１２】
「登録処理」
文書をデータ部に登録する時には、単一文字成分及び隣接文字分を抽出し、文字成分表を作成する。単一文字成分は各内部文字コードの２バイトコードとし、隣接文字成分は隣接する２文字以上の内部文字コードから変換したコードである。この実施例では内部文字コードのビット成分を適当に抽出したビット列を隣接文字成分とする。上記方法で得られた文字成分及び隣接文字成分に対して、それぞれ単一文字成分表（図２）及び隣接文字成分表（図３）を生成する。図３では隣接する文字の下位１バイトを合わせて２バイトとしている。各文字成分表は、各単一文字成分または隣接文字成分が各文書に存在するか否かを０と１で示す。図３の隣接文字成分表を例とすると、ａ０ａ０（１６進数）のビット列は文書１，２，３，ｎには存在せず、文書４，５には存在することを意味する。文書登録時に上記方法により文書から文字成分を抽出し各文字成分テーブルに加える。
【００１３】
「検索処理」
検索時には指定された検索語を上記登録時と同様に単一成分及び隣接文字成分を抽出し上記単一文字成分表（図２）及び隣接文字成分表（図３）において抽出した成分に対応する０，１（存在を意味する）からなるビット列を得てａｎｄをとることによって各成分が存在する文書を得る。この文書集合が指定された検索語を含む文書として出力される。なお、文字成分表のみによる検索では誤検索を含む場合もあるので、必要に応じて文書データをサーチして誤検索を除去する後処理を行う。
【００１４】
文字成分表によるインデックス自体には登録時に文書データを保持する機能を持っていないので、実際に何らかのアプリケーションを構築する場合には文書を管理する部分（文書管理部）が必要となる。一つの方法として、検索のために必要なインデックス（文字成分表及び文書ＩＤテーブルなど）の管理部分と文書管理部を一つのモジュールとして密に作り上げることが考えられる。この場合、文書管理部で要求する仕様とは異なる文書を管理できないという欠点が生ずる。また、既に文書管理機能を持ったアプリケーションの場合には重複して文書データを持つことにもなりかねない。そこで、文書管理部を独立し、かつ、外部の文書管理部と容易に結合できるような方式を提案する。
【００１５】
登録処理部３や検索処理部４はインデックスデータ部６で管理されているＩＤに対応する文書データが必要になる場合がある。例えば、本文書管理方式において文字成分表のみの検索では検索結果に誤検索が含まれる場合がある。そこで、最終的に文書データをサーチして誤検索を除く必要がある。この時に、文書データが必要になる。外部の文書管理部は本文書管理方式が指定する呼び出しフォーマットに従って指定されたテキストＩＤに対応する文書データを返す関数を予め用意する。アプリケーションが本文書管理方式を起動する時（後述のフォルダのオープン時）にこの関数ポインタを渡すことによって動的に本文書管理方式は外部の文書管理部５と結合しデータのやりとりを行うことが可能となる。
【００１６】
上記のように構成することで文書管理部を独立し、かつ、実行時に動的に結合することが可能である。ただし、外部の文書管理部が本インデックスデータ部６と同じフォーマットの文書ＩＤを有するとは限らない。例えば、インデックスデータ部６はｌｏｎｇ形式（４バイトのバイナリ）で管理しているにも関わらず、外部の文書管理部が文字列を文書ＩＤとしている可能性もある。この場合には、外部の文書管理部に合わせてインデックスデータ部６の文書ＩＤの管理部分を変更する必要が生じる。そこで、ユーザの文書ＩＤに依存せず、かつ、ユーザが指定した文書ＩＤにより文書ＩＤを管理できる方式を提案する。
【００１７】
ユーザは文書インデックスを生成する時点で外部の文書管理部５で使用している文書ＩＤ（今後ユーザ文書ＩＤと呼ぶ）のバイト長を指定する。与えられたバイト長の内容については例えば文字列の場合や、構造体の場合も考えられるが、本文書管理方式では、その中身には関知せず、単にバイナリ列として管理する。インデックスデータ部６はバイナリ列として図４ａのような配列を生成し、インデックスデータ部６の内部で管理している文書ＩＤ（内部文書ＩＤ）とを対応付ける。
【００１８】
文書検索や削除などの操作によって、ユーザ文書ＩＤから内部文書ＩＤを取り出す場合と、内部文書ＩＤからユーザ文書ＩＤを取り出す場合がある。内部文書ＩＤからは前述の文書ＩＤテーブル６ ２ によって容易に外部文書ＩＤを取り出すことができる。例えば、図４の例では内部文書ＩＤが３の時には配列の３番目の内容の「Ｘ２」がユーザ文書ＩＤとなる。しかし、ユーザ文書ＩＤから内部文書ＩＤを取得する場合、テーブル上でユーザ文書ＩＤが意味のある順で並べられていないので、このテーブルからは高速に内部文書ＩＤを取得することができない。そこで、例えば図４ｂのようなユーザ文書ＩＤでソートされた逆テーブルを用意することでユーザ文書ＩＤからも内部文書ＩＤを容易に取得することが可能である。
【００１９】
従来技術では、与えられた文書の全体が検索の対象となり、文書内の一部の検索は不可能であった。そこで、文書内の複数の領域又は全体を検索対象とし、各領域（今後エリアと呼ぶ）ごとにインデックスを生成することで各エリア単位に検索することを可能とする。
ユーザは本文書管理方式により文書管理する場合に最初に文書を仮想的に格納する（実際に文書を管理する部分は外部の文書管理部である）場所（今後フォルダと呼ぶ）を生成する（図５）。次にテキストの検索対象とする領域エリアを生成する。生成時にはそれぞれのエリア毎にそれぞれ文字成分表が生成される。図５の場合には３つのエリアを生成したことになる。
【００２０】
文書の登録時の処理を以下に示す。
１．フォルダをオープンする。この時に文書データ取得関数を指定する。
２．ユーザは登録する文書ＩＤを指定する。
３．本管理装置では文書データを管理していないので既にフォルダをオープンする時に与えられている文書データ取得関数によって与えられた文書ＩＤの文書データを取得する。
４．生成されているすべてのエリア単位の文字成分表に取得した文書データを登録する。
５．フォルダをクローズする。
文書検索時にはユーザが指定したエリアについてそのエリアに対応する文字成分表より検索結果を得る。
【００２１】
上記のようにユーザはエリア単位に検索を行うことができ、さらに、ユーザはエリア毎の検索結果集合の論理演算を行うことができる。例えば「Ａｒｅａ１」，「Ａｒｅａ２」，「Ａｒｅａ３」の３つのエリアがある場合に、ユーザは以下のようにエリアの検索結果集合の論理演算を指定することができる。
Ａｒｅａ１＆（Ａｒｅａ２｜Ａｒｅａ３）
上記式では＆はａｎｄ演算、｜はｏｒ演算を示し、Ａｒｅａ２とＡｒｅａ３の検索結果集合の論理和を取り、さらにＡｒｅａ１の検索結果集合との論理積をとることを意味する。
例えばＡｒｅａ１の検索結果の文書ＩＤ集合が｛１，５，７，１０｝、Ａｒｅａ２の検索結果が｛２，３，４｝、Ａｒｅａ３の検索結果が｛３，４，５，７｝の場合、演算結果は｛５，７｝となる。
【００２２】
【発明の効果】
本発明によれば、アプリケーションにより様々なデータ形式をもつ文書データを分離して管理することが可能となり、多様なアプリケーションに対応することが可能となる。
【００２３】
また、アプリケーション依存する多様な文書ＩＤに対応することが可能となる。
【００２４】
また、文書中の一部の領域及び複数の領域を対象に検索することが可能となる。
【図面の簡単な説明】
【図１】 本発明による文書管理方式が適用される一実施例を説明するための構成図である。
【図２】 単一文字成分表の例を示す図である。
【図３】 隣接文字成分表の例を示す図である。
【図４】 内部文書ＩＤとユーザ文書ＩＤの関係を示す図である。
【図５】 フォルダの一例を示す図である。
【符号の説明】
１…入力部、２…出力部、３…登録処理部、４…検索処理部、５…外部文書管理部、６…インデックスデータ部、７…文書データ部。
【発明の属する技術分野】
本発明は、文書管理方式および文書管理方法に係わり、特に、文字成分表を利用して全文書に対して文字列を検索する装置に関するものである。
【０００２】
【従来の技術】
従来の文書管理方式では、文書管理部を一体化しており、そのため、システムで規定する文書ＩＤのみしか利用できない。したがって、既存の文書管理部を持つアプリケーションと組み合わせる場合に文書データを二重に管理したり、文書ＩＤを統一したりしなければならない。また、実際の文書検索を行う場面では、必ずしも文書全体を検索対象とせず、文書内の特定の領域のみに対して検索要求があるが、このような要求に対応できない。
【０００３】
【発明が解決しようとする課題】
上述のように、従来の方法では様々なデータ形態を持つ文書データ及び文書ＩＤに容易に対応ができない。また従来の方法では文書中の一部の領域及び複数の領域を対象に検索することができない。
【０００４】
【課題を解決するための手段】
請求項１の発明は、指定された検索文字列を含む文書を検索し、その検索結果を出力する文書検索ライブラリを構成する文書管理方式であって、指定された文書ＩＤに対する文書データを取得する文書取得関数と、動的に渡された前記文書取得関数を用いて、指定された文書ＩＤに対する文書データを取得し、該取得した文書データより各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成して、インデックスデータ部へ登録する登録処理部と、指定された検索語を前記登録処理と同様に文字成分に分解し、前記インデックスデータ部に登録された文字成分表を用いて文書を検索し、当該検索結果の文書を出力する検索処理部とを有し、前記登録処理部は、動的に渡された前記文書取得関数を通して文書ＩＤに対応する文書データを取得するようにして、本文書管理方式の文書検索部分と前記文書データを保持管理する部分とを分離し、多様なアプリケーションに対応可能としたことを特徴としたものである。
【０００５】
請求項２の発明は、請求項１の発明において、前記登録処理部は、前記指定された文書ＩＤをバイナリ列で表し、当該登録処理部内では該文書ＩＤの代わりに内部文書ＩＤで管理するようにし、該内部文書ＩＤと前記バイナリ列とを対応付けて保持する文書ＩＤテーブルを有することで、アプリケーション依存する多様な文書ＩＤに対応可能としたことを特徴としたものである。
【０００６】
請求項３の発明は、指定された検索文字列を含む文書を検索し、その検索結果を出力する文書検索ライブラリを用いる文書管理方法であって、指定された文書ＩＤに対する文書データを取得する文書取得関数を用意し、文書を登録する際には、動的に渡された前記文書取得関数を用いて、指定された文書ＩＤに対する文書データを取得し、該取得した文書データより各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成して、インデックスデータ部へ登録し、指定された検索語を前記文書の登録と同様に文字成分に分解し、前記インデックスデータ部に登録された文字成分表を用いて文書を検索し、当該検索結果の文書を出力するようにして、本文書管理方法の文書検索部分と前記文書データを保持管理する部分とを分離し、多様なアプリケーションに対応可能としたことを特徴としたものである。
【０００７】
請求項４の発明は、請求項３の発明において、前記登録処理を行うときには、前記指定された文書ＩＤをバイナリ列で表し、当該登録処理部内では該文書ＩＤの代わりに内部文書ＩＤで管理するようにし、該内部文書ＩＤと前記バイナリ列とを対応付けて文書ＩＤテーブルに保持することによって、アプリケーション依存する多様な文書ＩＤに対応可能としたことを特徴としたものである。
【０００８】
【発明の実施の形態】
図１は、本発明による文書管理方式が適用される一実施例を説明するための構成図で、図中、１は入力部、２は出力部、３は登録処理部、４は検索処理部、５は外部文書管理部、６はインデックスデータ部、７は文書データ部である。本文書管理方式は、図１のうち、登録処理部３、検索処理部４、インデックスデータ部６から構成される。
【０００９】
文書登録時には、入力部１に入力された文書ＩＤを、登録処理部３において外部文書管理部５を介して文書データ部７から文書データを取得して、該文書データに内部文書ＩＤを付加し、該文書データから文字成分を抽出し、インデックスデータ部６に内部文書ＩＤに対応させて文字成分を登録するとともに、文書ＩＤテーブル６２に文書ＩＤを内部文書ＩＤと対応付けて登録する。
【００１０】
文書検索時には、検索処理部４はインデックスデータ部６の文字成分表６１により、入力部１に入力された検索文字列を含む文書を検索し、文書ＩＤテーブル６２から文書ＩＤを得て、出力部２は文書データ部７から文書管理部５を介して文書ＩＤに対応する文書データを取得して出力する。
【００１１】
以下の説明では対象文書は１バイト文字コード（例えば、ＡＳＣＩＩ）及び２バイト文字コード（ＥＵＣ：Extended ＵＮＩＸ ＣＯＤＥ）からなるテキストデータとする。しかし、対象とする文字コードはＥＵＣ以外にも容易に適用可能である。
【００１２】
「登録処理」
文書をデータ部に登録する時には、単一文字成分及び隣接文字分を抽出し、文字成分表を作成する。単一文字成分は各内部文字コードの２バイトコードとし、隣接文字成分は隣接する２文字以上の内部文字コードから変換したコードである。この実施例では内部文字コードのビット成分を適当に抽出したビット列を隣接文字成分とする。上記方法で得られた文字成分及び隣接文字成分に対して、それぞれ単一文字成分表（図２）及び隣接文字成分表（図３）を生成する。図３では隣接する文字の下位１バイトを合わせて２バイトとしている。各文字成分表は、各単一文字成分または隣接文字成分が各文書に存在するか否かを０と１で示す。図３の隣接文字成分表を例とすると、ａ０ａ０（１６進数）のビット列は文書１，２，３，ｎには存在せず、文書４，５には存在することを意味する。文書登録時に上記方法により文書から文字成分を抽出し各文字成分テーブルに加える。
【００１３】
「検索処理」
検索時には指定された検索語を上記登録時と同様に単一成分及び隣接文字成分を抽出し上記単一文字成分表（図２）及び隣接文字成分表（図３）において抽出した成分に対応する０，１（存在を意味する）からなるビット列を得てａｎｄをとることによって各成分が存在する文書を得る。この文書集合が指定された検索語を含む文書として出力される。なお、文字成分表のみによる検索では誤検索を含む場合もあるので、必要に応じて文書データをサーチして誤検索を除去する後処理を行う。
【００１４】
文字成分表によるインデックス自体には登録時に文書データを保持する機能を持っていないので、実際に何らかのアプリケーションを構築する場合には文書を管理する部分（文書管理部）が必要となる。一つの方法として、検索のために必要なインデックス（文字成分表及び文書ＩＤテーブルなど）の管理部分と文書管理部を一つのモジュールとして密に作り上げることが考えられる。この場合、文書管理部で要求する仕様とは異なる文書を管理できないという欠点が生ずる。また、既に文書管理機能を持ったアプリケーションの場合には重複して文書データを持つことにもなりかねない。そこで、文書管理部を独立し、かつ、外部の文書管理部と容易に結合できるような方式を提案する。
【００１５】
登録処理部３や検索処理部４はインデックスデータ部６で管理されているＩＤに対応する文書データが必要になる場合がある。例えば、本文書管理方式において文字成分表のみの検索では検索結果に誤検索が含まれる場合がある。そこで、最終的に文書データをサーチして誤検索を除く必要がある。この時に、文書データが必要になる。外部の文書管理部は本文書管理方式が指定する呼び出しフォーマットに従って指定されたテキストＩＤに対応する文書データを返す関数を予め用意する。アプリケーションが本文書管理方式を起動する時（後述のフォルダのオープン時）にこの関数ポインタを渡すことによって動的に本文書管理方式は外部の文書管理部５と結合しデータのやりとりを行うことが可能となる。
【００１６】
上記のように構成することで文書管理部を独立し、かつ、実行時に動的に結合することが可能である。ただし、外部の文書管理部が本インデックスデータ部６と同じフォーマットの文書ＩＤを有するとは限らない。例えば、インデックスデータ部６はｌｏｎｇ形式（４バイトのバイナリ）で管理しているにも関わらず、外部の文書管理部が文字列を文書ＩＤとしている可能性もある。この場合には、外部の文書管理部に合わせてインデックスデータ部６の文書ＩＤの管理部分を変更する必要が生じる。そこで、ユーザの文書ＩＤに依存せず、かつ、ユーザが指定した文書ＩＤにより文書ＩＤを管理できる方式を提案する。
【００１７】
ユーザは文書インデックスを生成する時点で外部の文書管理部５で使用している文書ＩＤ（今後ユーザ文書ＩＤと呼ぶ）のバイト長を指定する。与えられたバイト長の内容については例えば文字列の場合や、構造体の場合も考えられるが、本文書管理方式では、その中身には関知せず、単にバイナリ列として管理する。インデックスデータ部６はバイナリ列として図４ａのような配列を生成し、インデックスデータ部６の内部で管理している文書ＩＤ（内部文書ＩＤ）とを対応付ける。
【００１８】
文書検索や削除などの操作によって、ユーザ文書ＩＤから内部文書ＩＤを取り出す場合と、内部文書ＩＤからユーザ文書ＩＤを取り出す場合がある。内部文書ＩＤからは前述の文書ＩＤテーブル６ ２ によって容易に外部文書ＩＤを取り出すことができる。例えば、図４の例では内部文書ＩＤが３の時には配列の３番目の内容の「Ｘ２」がユーザ文書ＩＤとなる。しかし、ユーザ文書ＩＤから内部文書ＩＤを取得する場合、テーブル上でユーザ文書ＩＤが意味のある順で並べられていないので、このテーブルからは高速に内部文書ＩＤを取得することができない。そこで、例えば図４ｂのようなユーザ文書ＩＤでソートされた逆テーブルを用意することでユーザ文書ＩＤからも内部文書ＩＤを容易に取得することが可能である。
【００１９】
従来技術では、与えられた文書の全体が検索の対象となり、文書内の一部の検索は不可能であった。そこで、文書内の複数の領域又は全体を検索対象とし、各領域（今後エリアと呼ぶ）ごとにインデックスを生成することで各エリア単位に検索することを可能とする。
ユーザは本文書管理方式により文書管理する場合に最初に文書を仮想的に格納する（実際に文書を管理する部分は外部の文書管理部である）場所（今後フォルダと呼ぶ）を生成する（図５）。次にテキストの検索対象とする領域エリアを生成する。生成時にはそれぞれのエリア毎にそれぞれ文字成分表が生成される。図５の場合には３つのエリアを生成したことになる。
【００２０】
文書の登録時の処理を以下に示す。
１．フォルダをオープンする。この時に文書データ取得関数を指定する。
２．ユーザは登録する文書ＩＤを指定する。
３．本管理装置では文書データを管理していないので既にフォルダをオープンする時に与えられている文書データ取得関数によって与えられた文書ＩＤの文書データを取得する。
４．生成されているすべてのエリア単位の文字成分表に取得した文書データを登録する。
５．フォルダをクローズする。
文書検索時にはユーザが指定したエリアについてそのエリアに対応する文字成分表より検索結果を得る。
【００２１】
上記のようにユーザはエリア単位に検索を行うことができ、さらに、ユーザはエリア毎の検索結果集合の論理演算を行うことができる。例えば「Ａｒｅａ１」，「Ａｒｅａ２」，「Ａｒｅａ３」の３つのエリアがある場合に、ユーザは以下のようにエリアの検索結果集合の論理演算を指定することができる。
Ａｒｅａ１＆（Ａｒｅａ２｜Ａｒｅａ３）
上記式では＆はａｎｄ演算、｜はｏｒ演算を示し、Ａｒｅａ２とＡｒｅａ３の検索結果集合の論理和を取り、さらにＡｒｅａ１の検索結果集合との論理積をとることを意味する。
例えばＡｒｅａ１の検索結果の文書ＩＤ集合が｛１，５，７，１０｝、Ａｒｅａ２の検索結果が｛２，３，４｝、Ａｒｅａ３の検索結果が｛３，４，５，７｝の場合、演算結果は｛５，７｝となる。
【００２２】
【発明の効果】
本発明によれば、アプリケーションにより様々なデータ形式をもつ文書データを分離して管理することが可能となり、多様なアプリケーションに対応することが可能となる。
【００２３】
また、アプリケーション依存する多様な文書ＩＤに対応することが可能となる。
【００２４】
また、文書中の一部の領域及び複数の領域を対象に検索することが可能となる。
【図面の簡単な説明】
【図１】 本発明による文書管理方式が適用される一実施例を説明するための構成図である。
【図２】 単一文字成分表の例を示す図である。
【図３】 隣接文字成分表の例を示す図である。
【図４】 内部文書ＩＤとユーザ文書ＩＤの関係を示す図である。
【図５】 フォルダの一例を示す図である。
【符号の説明】
１…入力部、２…出力部、３…登録処理部、４…検索処理部、５…外部文書管理部、６…インデックスデータ部、７…文書データ部。
Claims (4)
- 指定された検索文字列を含む文書を検索し、その検索結果を出力する文書検索ライブラリを構成する文書管理方式であって、指定された文書ＩＤに対する文書データを取得する文書取得関数と、動的に渡された前記文書取得関数を用いて、指定された文書ＩＤに対する文書データを取得し、該取得した文書データより各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成して、インデックスデータ部へ登録する登録処理部と、指定された検索語を前記登録処理と同様に文字成分に分解し、前記インデックスデータ部に登録された文字成分表を用いて文書を検索し、当該検索結果の文書を出力する検索処理部とを有し、前記登録処理部は、動的に渡された前記文書取得関数を通して文書ＩＤに対応する文書データを取得するようにして、本文書管理方式の文書検索部分と前記文書データを保持管理する部分とを分離し、多様なアプリケーションに対応可能としたことを特徴とする文書管理方式。
- 請求項１記載の文書管理方式において、前記登録処理部は、前記指定された文書ＩＤをバイナリ列で表し、当該登録処理部内では該文書ＩＤの代わりに内部文書ＩＤで管理するようにし、該内部文書ＩＤと前記バイナリ列とを対応付けて保持する文書ＩＤテーブルを有することで、アプリケーション依存する多様な文書ＩＤに対応可能としたことを特徴とする文書管理方式。
- 指定された検索文字列を含む文書を検索し、その検索結果を出力する文書検索ライブラリを用いる文書管理方法であって、指定された文書ＩＤに対する文書データを取得する文書取得関数を用意し、文書を登録する際には、動的に渡された前記文書取得関数を用いて、指定された文書ＩＤに対する文書データを取得し、該取得した文書データより各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成して、インデックスデータ部へ登録し、指定された検索語を前記文書の登録と同様に文字成分に分解し、前記インデックスデータ部に登録された文字成分表を用いて文書を検索し、当該検索結果の文書を出力するようにして、本文書管理方法の文書検索部分と前記文書データを保持管理する部分とを分離し、多様なアプリケーションに対応可能としたことを特徴とする文書管理方法。
- 請求項３記載の文書管理方法において、前記登録処理を行うときには、前記指定された文書ＩＤをバイナリ列で表し、当該登録処理部内では該文書ＩＤの代わりに内部文書ＩＤで管理するようにし、該内部文書ＩＤと前記バイナリ列とを対応付けて文書ＩＤテーブルに保持することによって、アプリケーション依存する多様な文書ＩＤに対応可能としたことを特徴とする文書管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP19054496A JP3644765B2 (ja) | 1996-07-19 | 1996-07-19 | 文書管理方式および文書管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP19054496A JP3644765B2 (ja) | 1996-07-19 | 1996-07-19 | 文書管理方式および文書管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH1040256A JPH1040256A (ja) | 1998-02-13 |
| JP3644765B2 true JP3644765B2 (ja) | 2005-05-11 |
Family
ID=16259855
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP19054496A Expired - Fee Related JP3644765B2 (ja) | 1996-07-19 | 1996-07-19 | 文書管理方式および文書管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3644765B2 (ja) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3333549B2 (ja) * | 1992-03-24 | 2002-10-15 | 株式会社リコー | 文書検索方式 |
| JPH06290217A (ja) * | 1993-03-31 | 1994-10-18 | Ricoh Co Ltd | 文書検索方式 |
| JP3325677B2 (ja) * | 1993-11-29 | 2002-09-17 | 株式会社リコー | 文書検索装置 |
| JP3563823B2 (ja) * | 1994-06-02 | 2004-09-08 | 株式会社リコー | 文書管理装置 |
-
1996
- 1996-07-19 JP JP19054496A patent/JP3644765B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH1040256A (ja) | 1998-02-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2000231563A (ja) | 文書検索方法及び文書検索システム及び文書検索プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| JPH08241332A (ja) | 全文登録語検索装置および方法 | |
| JP4247108B2 (ja) | 構造化文書検索方法、構造化文書検索装置、及びプログラム | |
| JP2986865B2 (ja) | データ検索方法および装置 | |
| JPH08329116A (ja) | 構造化文書検索方法 | |
| JP3644765B2 (ja) | 文書管理方式および文書管理方法 | |
| JP2004220176A (ja) | データベース検索システム、その検索方法及び検索に用いられるデータファイルの作成方法並びにデータファイルを格納した記録媒体 | |
| JP3647940B2 (ja) | データ管理装置 | |
| JP2002149676A (ja) | マークアップ言語文書変換装置および方法 | |
| JP2000163445A (ja) | データベース管理システム | |
| JPH05135102A (ja) | 文書検索方式 | |
| JPH1153400A (ja) | 構造化文書検索装置及びプログラムを記録した機械読み取り可能な記録媒体 | |
| JPS60129873A (ja) | 文書保管検索システム | |
| JP2001318935A (ja) | 情報処理装置及び方法、情報処理用ソフトウェアを記録した記録媒体並びにリレーショナルデータベース | |
| JP2827658B2 (ja) | 図形解析装置及び図形検索装置 | |
| JPH03137772A (ja) | データベース利用システム | |
| JP3384017B2 (ja) | データ抽出システム | |
| JPH10301940A (ja) | 情報処理装置及びその方法 | |
| JPH01286020A (ja) | プログラム検索方式 | |
| JPH05298368A (ja) | 電子ファイリングシステムの検索語入力方法 | |
| JPH05158984A (ja) | 文字列抽出装置 | |
| JP2842611B2 (ja) | 候補文生成による自然文意味解析処理装置 | |
| JPH05225244A (ja) | アラビア語データの検索方式 | |
| JPH1021246A (ja) | 文書検索システム | |
| JPS61267828A (ja) | 情報登録検索装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040713 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040913 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050201 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050201 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080210 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090210 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100210 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110210 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120210 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130210 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130210 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140210 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |