JP3692764B2 - 構造化文書登録方法、検索方法、およびそれに用いられる可搬型媒体 - Google Patents
構造化文書登録方法、検索方法、およびそれに用いられる可搬型媒体 Download PDFInfo
- Publication number
- JP3692764B2 JP3692764B2 JP04318798A JP4318798A JP3692764B2 JP 3692764 B2 JP3692764 B2 JP 3692764B2 JP 04318798 A JP04318798 A JP 04318798A JP 4318798 A JP4318798 A JP 4318798A JP 3692764 B2 JP3692764 B2 JP 3692764B2
- Authority
- JP
- Japan
- Prior art keywords
- document
- index
- search
- character string
- node
- 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
- 238000000034 method Methods 0.000 title claims description 254
- 239000000284 extract Substances 0.000 claims description 5
- 238000000605 extraction Methods 0.000 claims 2
- 238000012545 processing Methods 0.000 description 181
- 230000008569 process Effects 0.000 description 123
- 238000010586 diagram Methods 0.000 description 91
- 238000013500 data storage Methods 0.000 description 36
- 238000012546 transfer Methods 0.000 description 18
- 238000010606 normalization Methods 0.000 description 13
- 238000004458 analytical method Methods 0.000 description 10
- 230000003287 optical effect Effects 0.000 description 10
- 238000006243 chemical reaction Methods 0.000 description 8
- 230000008859 change Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 6
- 238000012217 deletion Methods 0.000 description 6
- 230000037430 deletion Effects 0.000 description 6
- 230000004913 activation Effects 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000014509 gene expression Effects 0.000 description 5
- 230000004044 response Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 4
- 239000003550 marker Substances 0.000 description 4
- 230000002093 peripheral effect Effects 0.000 description 3
- 238000012916 structural analysis Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000002360 explosive Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 238000000547 structure data Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
- G06F16/81—Indexing, e.g. XML tags; Data structures therefor; Storage structures
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99935—Query augmenting and refining, e.g. inexact access
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99936—Pattern matching access
Description
【発明の属する技術分野】
本発明は、コンピュータ装置を用いた文書検索システムや文書管理システム等における文書登録方法および文書検索方法に係わり、特に、各文書がそれぞれ論理的な構造を備えている構造化文書の集合を対象として、特定の文書内容の検索を高速に行うことのできるようにした構造化文書の登録方法,検索方法、およびそれに用いられる可搬型媒体に関する。
【0002】
【従来の技術】
情報化社会の本格的な進展に伴い、ワードプロセッサ、パーソナルコンピュータ等を用いて作成された電子化文書情報が爆発的な勢いで増加しつつある。このような状況下において、蓄積された膨大な電子化文書群の中から、必要とする情報を含んだ文書を高速かつ確実に検索したいという要求が高まっている。
【0003】
このような要求に応える技術として全文検索がある。全文検索では登録対象文書中のテキスト全体を計算機システムに投入してデータベース化し、該データベース上で指定文字列(以後、検索タームと呼ぶ)を直接検索するので、キーワードを必要とせず、原理的に検出漏れのない検索が可能となる。
【0004】
また、例えばSGML(ISO 8879:1986, Standard Generalized Markup Language)で記述された文書など、文書を構成する個々の論理的な構造要素が識別できる文書(以下、構造化文書と呼ぶ)を対象として、論理構造に関する条件を検索条件中に付加した検索(以下、構造指定検索と呼ぶ)を行うことにより、精度の高い検索を実現することができる。
【0005】
構造指定検索を可能にする方式としては、例えば特開平8−147311号公報に示す発明(以下、公知例1と呼ぶ)で提案した検索方法がある。以下、公知例1の概要について説明する。
【0006】
公知例1の構造化文書検索方法は、文書を登録する際、まず登録文書をそのまま本文として検索用データベースに登録する。
【0007】
次に、登録した本文について各論理構造の先頭を表わす特定の文字列(これを公知例1では前方マーカと呼ぶ)および末尾を表わす特定の文字列(これを公知例1では後方マーカと呼ぶ)を検出することにより論理構造の識別処理を行うとともに、本文を論理構造ごとに分割する処理を行う。例えば、電子出願特許明細書の場合には、論理構造「要約」の範囲を示す前方マーカとして“<SD0 ABJ>”を、後方マーカとして“</SD0>”を検出し、これらによって囲まれるテキストを「要約」に対応する本文として切り出す。他の論理構造についても同様な切り出しを行い、本文を論理構造ごとに分割する。
【0008】
次に、分割された各論理構造に対応する本文について、それぞれ凝縮本文の作成処理を行う。すなわち、「要約」については「要約」に関する本文テキストを単語単位に部分文字列に分割し、分割した部分文字列間で相互に包含関係を調べ、他の部分文字列に含まれる文字列を排除することにより「要約」に関する凝縮本文を作成する。他の論理構造についても同様な処理を行うことにより論理構造別の凝縮本文を作成し、これを凝縮本文ファイルとして検索用データベースに登録する。
【0009】
次に、本文中に現れた文字の文字コードに対応するビットに‘1’を設定することにより文字成分表を作成し、これを検索用データベースに文字成分表ファイルとして登録する。
【0010】
このようにして検索用データベースを構築した後、公知例1では次のようにして文書検索処理を行う。
【0011】
はじめに、指定された検索タームを文字単位に分解し、検索タームを構成するすべての文字がともに含まれる文書を上記文字成分表を参照して抽出する。
【0012】
次に、各論理構造に対応する凝縮本文ファイルのうち、検索対象として指定された論理構造に関する凝縮本文ファイルをサーチ対象として選択するとともに、その中で文字成分表サーチによって抽出された文書の凝縮本文だけを対象としてサーチすることにより、指定された論理構造中に指定された検索タームが含まれている文書を抽出する。指定された検索条件式に複数の検索ターム間の本文中での位置関係が指定されていない場合にはここで検索処理を終了する。他方、そのような位置関係が指定されている場合には凝縮本文サーチの結果抽出された文書に対応する本文の内容を読み、指定された検索タームがすべて含まれ、かつ検索ターム間の位置関係について、指定された条件が満たされるもののみを抽出する。
【0013】
このようにして、公知例1の方法によれば、大規模なテキストデータベースに対する実用的な検索速度を保ち、かつ構造指定検索を可能にすることができる。
【0014】
【発明が解決しようとする課題】
前記公知例1に示す従来技術によって、一定の構造指定検索が可能となる。しかし、公知例1による構造指定検索では意図した構造条件に従った検索ができない場合がある。
【0015】
公知例1の方式では、登録対象文書の持つ構造を予め定めておいたいくつかの部分構造に切り分け、各部分構造ごとに凝縮本文ファイルを作成し、検索時には、部分構造の構造名と凝縮本文ファイルとの対応を定義したテーブルを参照して検索対象とすべき凝縮本文ファイルの集合を決定し、該集合中に含まれる凝縮本文ファイルだけを対象として検索を行うことにより構造指定検索を実現する。
【0016】
この方式では、テキストデータベースを構築する段階で、将来どのような構造条件を指定した検索が行われるかを想定し、そのような条件に対応した検索が可能となるように凝縮本文ファイルの切り分けを行うので、データベース構築時に想定していなかった構造条件を指定した検索は不可能となる。
【0017】
例えば、文書が“要約”と“本体”の二つの論理要素(以下、要素と呼ぶ)から構成され、“本体”はさらに任意個数の“節”の繰り返しからなり、各“節”は1個の“節題”と任意個数の“段落”からなる場合を考える。このような構造を持つ文書群からなるテキストデータベースを構築する際に、凝縮本文ファイルを“要約”に対応するものと“本体”に対応するものの二つに分けて作成したとすると、「節題中に文字列○○を含む文書群を求める」という条件を満たす構造指定検索は不可能となってしまう。
【0018】
もちろん、“本体”全体で1個の凝縮本文ファイルとする代わりに、これをさらに“節題”と“段落”とに分けて凝縮本文ファイルを作成しておけばこの条件に対応することはできる。しかし、仮にこのようにファイルを構成しても、例えば「最初の節の内部(節題または段落中)に文字列○○を含む文書群を求める」、あるいは「節中で最後の段落に文字列××を含む文書群を求める」というような構造条件には対応できない。このような順位指定付きの構造条件に対応しようとすると、予め節および段落の出現順位ごとに別々に凝縮本文ファイルを用意しておくことが必要となるが、節および節内の段落はそれぞれ任意個数出現しうるため凝縮本文ファイルの数が極めて多数となるだけでなく、公知例1は出現順位に関する任意の指定を含んだ構造条件から細分化された凝縮本文ファイルの集合への対応付けを行う手段を備えていないので、実際にはこのような条件を満たす検索は不可能となる。
【0019】
このように、前記従来技術では、文書中に現れた論理要素の出現位置に関する条件を構造条件指定中に含めることができないため、精度の高い構造指定検索ができないという問題があった。
【0020】
本発明の目的は、前記従来技術の持つ上記問題点を解決し、高精度でかつ効率のよい構造指定検索を行う機能を提供することにある。
【0021】
さらに、前記従来技術では、あらかじめ定められた1つの構造を持った文書群に対する構造指定検索しか実現できない。
【0022】
つまり、SGMLなどの構造化文書は、文書型定義(DTD: Document Type Definition)によりあらかじめ定められた構造を持つ文書である。したがって、特定の文書型定義に従った文書群に対する構造指定検索を行う場合は、出現しうる構造指定条件すべてに対応するように、文書を構造毎に切り分けることで、構造指定検索が可能となる。
【0023】
しかし、文書型定義は1つだけではない。例えば、論文、報告書などはそれぞれ異なる文書型定義を持っている。このように、構造化文書では、その文書の目的に応じて様々な文書構造を持っており、その文書構造に合わせた文書型定義が作成される。
【0024】
これらの文書を文書型定義毎にグループ化して登録することで、個々のグループにおいては、構造指定検索が可能となるが、全グループに共通して出現しうる構造を指定した検索を実現しようとすると、全グループに対して個々に構造指定検索を行ない、結果を統合しなければ、結果を得ることができない。
【0025】
また、XML(Extended Markup Language)のように、必ずしも特定の構造を持たなくても良い構造化文書の規格化がW3C(World Wide Web Consortium)で進められており、SGMLのように特定のDTDに従った文書構造を持つ文書だけが検索対象とならないことが考えられる。
【0026】
さらに、前記従来技術では、「タイトル」、「題目」のように、同じ意味(種別)を持つ構造であっても、要素型名が異なっていれば別の構造とみなされるため、「"タイトル"に"SGML"が含まれる文書」という構造指定検索では、「"題目"に"SGML"が含まれる文書」という条件を満たす文書は、検索結果として得ることができない。
【0027】
特に、文書型定義が異なる場合、それぞれの文書型定義毎に、同じ種別の構造に異なる要素型名が付けられることが考えられる。
【0028】
例えば、「タイトル」に関する構造指定検索を行おうとすると、ユーザが「タイトル」、「題目」、「表題」、「TITLE」など、各文書型定義に出現する様々な「タイトル」を意味する要素型名を指定して構造指定検索条件を作成しなければ、必要とする文書をすべて取得することができない。また、登録文書の文書型定義をすべて知らなければ、ユーザが想定した要素型名で「タイトル」を意味する構造全てを網羅することはできない。例えば「T」という構造にタイトルを記述するといった文書型定義に従った文書は、それを知らないユーザからの構造指定検索では、決して取得することはできないであろう。
【0029】
本発明のもう一つの目的は、上記問題点を解決し、文書構造が異なる文書が混在する文書群を、高精度でかつ効率的に構造指定検索する機能を提供することである。
【0030】
さらに構造指定検索条件として、「章、節などのいづれかの項目のタイトルにおいて、"SGML"という単語を含む文書」を設定した場合、"タイトル"という構造条件を満たす構造を全て探さなければならないため、検索効率が悪くなるという問題がある。
【0031】
検索条件として、「/文書/章/タイトル」のように、タイトルまでの全ての構造を最上位から順に指定するようにすれば、効率的に構造を特定することができる。しかし、ユーザが「"/文書/章/タイトル"または"/文書/章/節/タイトル"または、、、」のように、全ての構造を示した構造指定検索条件を作成しなければならないため、ユーザの負担が大きくなる上に、ユーザが検索対象の文書の構造を全ての把握しておかなければ、検索漏れが発生することになる。
【0032】
本発明のさらにもう一つの目的は、上記問題点を解決し、複数の階層に出現する同じ種別の構造を指定した検索を、複雑な構造条件を指定することなく、効率的に実現する機能を提供することである。
【0033】
【課題を解決するための手段】
上記課題を解決するため、本発明による文書登録および検索方法は、以下に示すステップを備える。
【0034】
すなわち、本発明による文書登録方法において、文書の登録処理は、
(1)登録対象文書の持つ論理構造を解析して解析済み文書データを生成し、これを文書データベースに登録する解析済み文書データ生成登録ステップと、
(2)各登録対象文書の持つ論理構造を、登録順に従って順次重ね合わせ、文書中における出現位置および種別が同じである要素群は単一のメタ要素によって代表させ、文書中における出現位置が同じである文字列データ群は単一のメタ文字列データによって代表させることにより、メタ要素群およびメタ文字列データ群(以下、これらを総称してメタノードと呼ぶ)の木構造から構成される構造インデックスを生成し、該構造インデックスを構成するすべてのメタノードに対して、それらを構造インデックス中で一意に識別する識別子である文脈識別子を与える構造インデックス生成ステップと、
(3)各登録対象文書について、その文書に対応する解析済み文書データ中に含まれるすべての文字列データと、その文字列データを構造インデックス中で代表するメタ文字列データの文脈識別子との対応関係の定義から構成される構造化全文データを生成する構造化全文データ生成ステップと、
(4)各登録対象文書に対応する構造化全文データから、所定の部分文字列と、該部分文字列の前記登録対象文書中における文字位置情報と、前記登録対象文書を文書データベース中で一意に識別する文書識別子と、前記部分文字列を含む文字列データを構造インデックス中で代表するメタ文字列データの文脈識別子とを抽出し、前記文字位置情報および前記文書識別子および前記文脈識別子からなる構造化文字位置情報を生成し、前記部分文字列と前記構造化文字位置情報との対応関係を登録して文字列インデックスを更新する文字列インデックス更新ステップを有する。
【0035】
また、本発明による文書検索方法において、登録済み文書の検索処理は、
(1)前記構造インデックスを参照し、指定された構造条件を満たす文脈識別子の集合を決定する構造条件判定ステップと、
(2)検索タームから所定の部分文字列を抽出し、前記文字列インデックスを参照して該部分文字列に対応する構造化文字位置情報の集合を抽出する構造化文字位置情報抽出ステップと、
(3)前記構造化文字位置情報の集合中から、前記構造条件判定ステップで決定した集合中に含まれる文脈識別子をもち、かつ前記検索ターム上における部分文字列の並びと同じ位置関係を持つ構造化文字位置情報を抽出するインデックス検索ステップ
を有する。
【0036】
さらに、本発明による文書検索方法において、複数の文書構造を持つ文書をまとめて登録する処理には、
(1)構造インデクス中の複数の構造に出現しうる各構造の名称と構造の種別の対応を記述した種別定義テーブルを参照し、要素型名からその構造の種別を取得する種別取得ステップと、
(2)文書の最上位構造と同じ種別を持つ最上位構造を持つ構造インデクスを取得する最上位構造判定ステップと、
(3)構造化文書の登録時に、複数の文書構造を持つ文書の構造インデクスの上位に各構造インデクスをまとめる親ノード(ルートメタノード)を設けることにより、複数の構造インデクスを1つのメタ構造インデクスにまとめるルートメタノード作成ステップ
を有する。
【0037】
もしくは、
(1)構造インデクス中の複数の構造に出現しうる各構造の名称と構造の種別の対応を記述した種別定義テーブルを参照し、要素型名からその構造の種別を取得する種別取得ステップと、
(4)登録文書を構造解析して得られる解析済み文書データに、全文書に共通な仮の最上位構造を追加するステップ
を有する。
【0038】
種別定義テーブルは、あらかじめ、人手により作成、あるいはシソーラスなどを利用して、同義語を同じ種別に割り当てるなどの方法により自動的に作成する。
【0039】
さらに、本発明による文書検索方法において、構造インデクス中の多くの位置に出現する同じ種別の構造を指定した構造指定検索を効率的に実現するために、
文書登録プログラムには、
(1)文書登録時に構造インデクスを作成すると共に、別名構造インデクスを生成するステップ
を有する。
【0040】
別名構造インデクスとは、例えば、作成日・更新日など、各文書構造毎に設定されうる情報を構造インデクスを辿らなくても、一括して検索できるように作成した構造インデクスである。別名構造インデクスで得られる種別を指定して構造指定検索することで、別名構造インデクスから、別名に対応する構造インデクス中の複数の構造を一括して得ることができるため、構造インデクスを辿って指定された構造の文脈識別子を得るよりも、効率的な検索を実現することが可能である。
【0041】
【発明の実施の形態】
(第一の実施例)
以下、本発明を適用した第一の実施例について、図面を用いて説明する。
【0042】
はじめに、本実施例のシステム構成について説明する。
【0043】
図1は、本発明による文書検索システムの第一の実施例の全体構成を示す図である。図1に示すとおり、本発明による文書検索システムの第一の実施例は、文書登録サブシステム101、文書検索サーバ102、文書検索クライアント103および104、ネットワーク105から構成される。
【0044】
文書登録サブシステム101は、検索対象として入力される各文書の構造を解析し、検索時に必要となるインデックスデータを作成する。このインデックスデータは、ネットワーク105を介して文書検索サーバ102に転送され、後に文書検索サーバ102が構造検索処理を行う際に用いられる。
【0045】
文書検索サーバ102は、検索クライアント103および104からの検索コマンドを受け取り、文書登録サブシステム101が作成したインデックスデータを用いて該検索コマンドの指定する条件に適合する文書内容の検索を行い、検索結果データを要求元の検索クライアントに送り返す。
【0046】
検索クライアント103および104は、ユーザが対話的に検索条件を指定するための画面をディスプレイ上に表示し、この画面上でユーザが指定した検索条件を、文書検索サーバ102によって解釈可能な検索コマンドの形に変換し、この検索コマンドをネットワーク105を介して文書検索サーバ102に送信する。前記のとおり文書検索サーバ102が検索コマンドに対応する検索処理を行い、検索結果データを送り返して来ると、検索クライアント102は受け取った検索結果データを画面に表示してユーザに提示する。なお、図1には2台のコンピュータ103および104を検索クライアントとして使用する構成例を示したが、検索クライアントは1台のみとする構成をとることも、3台以上とする構成をとることもできる。
【0047】
ネットワーク105は、ローカルエリアネットワークおよび/または広域ネットワークであって、文書登録サブシステム101、文書検索サーバ102、検索クライアント103および104が各種データやコマンドを交換するために用いられる。
【0048】
ここで、図1では文書登録サブシステム101から文書検索サーバ102にインデックスデータを転送するためにネットワーク105を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。あるいは、文書登録サブシステム101と文書検索サーバ102を1台のコンピュータ上に実装し、データ転送を行わない構成をとることもできる。
【0049】
さらに、図1では検索クライアント103および104と文書検索サーバ102には別個のコンピュータを使用するものとしたが、1個以上の検索クライアントを文書検索サーバと同一のコンピュータ上で実行する構成をとることもできる。
【0050】
以下、本実施例における文書登録サブシステム、すなわち図1の101について説明する。
【0051】
図2は、本実施例における文書登録サブシステム101の構成を示す図である。
【0052】
図2に示す文書登録サブシステム101は、ディスプレイ201、キーボード202、中央処理装置(CPU)203、フロッピーディスクドライブ204、フロッピーディスク205、通信制御装置206、主メモリ207、磁気ディスク装置208、システムバス209から構成される。
【0053】
ディスプレイ201は、本サブシステムにおける処理の実行状況等を表示するために使用する。キーボード202は、文書登録処理の実行等を指示するコマンドを入力するために使用する。中央処理装置203は、本サブシステムを構成する各種プログラムを実行する。フロッピーディスクドライブ204は、フロッピーディスク205に対するデータの読み書きのために使用する。フロッピーディスク205は、予め登録対象文書を格納しておき、これを本サブシステムに入力するために使用する。通信制御装置206は、ネットワーク105を介して前記文書検索サーバ102と通信し、リクエストおよびデータの交換を行うために使用する。主メモリ207は、本サブシステムによる処理を実行するための各種プログラムおよび一時的なデータを保持するために使用する。磁気ディスク装置208は、登録された文書データおよび本サブシステムが生成するインデックスデータを格納するために使用する。システムバス209は、これらの各種装置を接続するために使用する。
【0054】
主メモリ207中には、文書構造解析プログラム210、構造インデックス作成プログラム211、構造化全文データ生成プログラム212、文字列インデックス作成プログラム213、文書登録制御プログラム214およびシステムプログラム215が格納され、またワークエリア216が保持される。磁気ディスク装置208中には、解析済み文書データ格納領域217、構造インデックス格納領域218、構造化全文データ格納領域219および文字列インデックス格納領域220が確保される。
【0055】
文書構造解析プログラム210は、SGMLを用いて記述され、フロッピーディスク205に格納された登録対象文書を読みだし、その論理構造を解析して解析済み文書データを生成し、これを解析済み文書データ格納領域217に格納する。構造インデックス作成プログラム211は、前記解析済み文書データの持つ論理構造に関する情報を、構造インデックス格納領域218に格納されている構造インデックスに登録して構造インデックスを更新する。構造化全文データ生成プログラム212は、前記解析済み文書データから前記登録対象文書に関する構造化全文データを生成し、これを構造化全文データ格納領域219に格納する。文字列インデックス作成プログラム213は、前記構造化全文データから、所定の部分文字列と、該部分文字列の構造化文字位置情報との対応関係を表わすデータを生成し、これを文字列インデックス格納領域220に格納されている文字列インデックスに登録して文字列インデックスを更新する。
【0056】
文書登録制御プログラム214は、文書構造解析プログラム210、構造インデックス作成プログラム211、構造化全文データ生成プログラム212および文字列インデックス作成プログラム213の起動および実行制御を行うとともに、これらのプログラムによって生成された解析済み文書データ、構造インデックスおよび文字列インデックスをネットワーク105を介して前記文書検索サーバ102に転送する。システムプログラム215は、周辺装置との間のデータの入出力など、コンピュータ上で本サブシステムを構成する各プログラムを実行するための基本機能を提供する。ワークエリア216は、プログラムの実行時に一時的に必要となるデータを記憶するために用いられる。
【0057】
なお、本実施例ではフロッピーディスク205に格納された登録対象文書を入力として読み込む構成としたが、光磁気ディスク、追記型光ディスク等、他種の可搬型媒体から読み込む構成をとることもでき、ネットワーク105を介して転送されてくる文書を入力とする構成をとることもできる。さらに、本実施例では生成された解析済み文書データ、構造インデックスおよび文字列インデックスを文書検索サーバ102に転送するためにネットワーク105を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。あるいは、文書登録サブシステム101と文書検索サーバ102を1台のコンピュータ上に実装し、データ転送を行わない構成をとることもできる。
【0058】
次に、本実施例における文書登録処理の手順について説明する。
【0059】
図3は、本発明の第一の実施例における文書登録処理の概略手順を示すPAD(Problem Analysis Diagram)図である。キーボード202からの登録指示コマンド等により文書登録制御プログラム214が起動されると、本プログラムはまずフロッピーディスク205に格納されている登録対象文書の有無とその数を調べ、すべての登録対象文書について、ステップ302から305までに示す一連の処理を繰り返し実行する(ステップ301)。
【0060】
ステップ302では、フロッピーディスク205に格納されている登録対象文書群の中から、未処理の登録対象文書を1個選択して読み込む。ステップ303では、読み込んだ登録対象文書に文書識別子を割り当てる。文書識別子は、文書データベース中で特定の文書を一意に識別する番号である。
【0061】
ステップ304では、この登録対象文書を入力として文書構造解析プログラム210を実行する。ここで、文書構造解析プログラム210は、この登録対象文書に対応する解析済み文書データを生成して解析済み文書データ格納領域217に格納する。
【0062】
ステップ305では、ステップ304で生成した解析済み文書データを入力として構造インデックス作成プログラム211を実行する。構造インデックス作成プログラム211は、まず構造インデックス格納領域217から現時点での構造インデックスを読み出し、与えられた解析済み文書データの持つ構造情報をこの構造インデックスに登録し、更新された構造インデックスを再び構造インデックス格納領域218に格納する。
【0063】
ステップ306では、ステップ304で生成した解析済み文書データを入力として、構造化全文データ生成プログラム212を実行する。構造化全文データ生成プログラム212は、与えられた解析済み文書データを参照して、ステップ303で読み込んだ登録対象文書に対応する構造化全文データを生成し、構造化全文データ格納領域219に格納する。
【0064】
ステップ307では、ステップ306で生成した構造化全文データを入力として文字列インデックス作成プログラム213を実行する。文字列インデックス作成プログラム213は、まず文字列インデックス格納領域220から現時点での文字列インデックスを読み出し、構造化全文データから、所定の部分文字列と、該部分文字列の構造化文字位置情報との対応関係を表わすデータを生成してこれを文字列インデックスに登録し、更新された文字列インデックスを再び文字列インデックス格納領域220に格納する。
【0065】
すべての登録対象文書についてステップ302から307までに示す一連の処理が終了すると、文書登録制御プログラム214はステップ308を実行して処理を終了する。ステップ308では、解析済み文書データ格納領域217に格納されたすべての解析済み文書データ、構造インデックス格納領域218に格納された構造インデックス、および文字列インデックス格納領域220に格納された文字列インデックスを、ネットワーク105を介して文書検索サーバ102に転送する。
【0066】
次に、図3におけるステップ304の詳細、すなわち本実施例における文書構造解析プログラム210の処理手順について説明する。
【0067】
ここで、文書構造解析プログラム210は、SGMLを用いて記述された1個の登録対象文書を対象として構造解析処理を行う。SGMLでは、特定の種別に属する文書群に共通する論理構造を、DTD(Document Type Definition)によって定義する。図4がDTDの一例である。DTDは、文書を構成する論理要素(以下、これを単に「要素」と呼ぶ)の集合を定義することによって、文書の論理的構造を定義する。図4において、文字列“<!ELEMENT”と文字列“>”で囲まれた部分を要素型宣言と呼び、1個の要素型宣言が、1種類の要素型に属する要素群が共通して持つ名前(これを要素型名と呼ぶ)とその構造を規定する。要素型宣言中の左側に示されている文字列が要素型名、右側に示されている部分がその内容がとる構造の定義である。
【0068】
図4に示すDTDにおいて、要素型“論文”に関する要素型宣言は、この要素型に属する要素の内容が、“タイトル”、“執筆者”、“日付”、“本文”および“文献リスト”という要素型に属する要素1個ずつを、この順序に従って並べた構造を持つことを規定している。ここで、複数の要素型名を文字“,”で区切って並べることにより、それらの要素型名に属する要素が指定した順序で出現しなければならないことを表現する。
【0069】
要素型“執筆者”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“名前”に属する要素の1個以上の繰り返しからなる構造を持つことを規定している。ここで、要素型名の後ろに文字“+”を付加することにより、その要素型名に属する要素が1個以上出現することを表現する。
【0070】
要素型“本文”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“章”に属する要素の0個以上の繰り返しからなる構造を持つことを規定している。ここで、要素型名の後ろに文字“*”を付加することにより、その要素型名に属する要素が0個以上出現することを表現する。
【0071】
要素型“章”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“章題”に属する要素1個の後ろに、要素型“段落”または“備考”に属する要素を0個以上続け、さらにその後ろに要素型“節”に属する要素を0個以上繰り返した構造を持つことを規定している。ここで、複数の要素型名を文字“|”で区切って並べることにより、それらのいずれかの要素型に属する要素が出現することを表現する。
【0072】
要素型“節”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“節題”に属する要素1個の後ろに、要素型“段落”または“備考”に属する要素を0個以上続け、さらにその後ろに要素型“項”に属する要素を0個以上繰り返した構造を持つことを規定している。
【0073】
要素型“項”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“項題”に属する要素1個の後ろに、要素型“段落”または“備考”に属する要素を0個以上繰り返した構造を持つことを規定している。
【0074】
要素型“文献リスト”に関する要素型宣言は、この要素型に属する要素の内容が、要素型“文献”に属する要素の1個以上の繰り返しからなる構造を持つことを規定している。
【0075】
要素型“文献”に関する要素型宣言は、この要素型に属する要素の内容が、“タイトル”、“執筆者”、“日付”および“出典”という要素型に属する要素1個ずつを、この順序に並べた構造を持つことを規定している。
【0076】
また、要素型“タイトル”、“名前”、“日付”、“章題”、“節題”、“項題”、“強調”および“出典”に属する要素の内容は、単に“#PCDATA”と規定されている。これは、これらの要素がそれ以上の下位構造をもたず、単なる文字の列からなる内容を持つことを規定している。要素型“段落”および“備考”に関する要素型宣言は、これらの要素型に属する要素が、要素型“強調”に属する要素または単なる文字列を0個以上繰り返した構造を持つことを規定している。
【0077】
DTD中において、文字列“<!ATTLIST”と文字列“>”で囲まれた部分を属性リスト宣言と呼び、1個の属性リスト宣言が、1種類の要素型に属する要素群が共通して持つ属性を定義する。図4に示すDTDでは、要素型“備考”に属する要素が、属性“type”を持つこと、この属性は“参照”または“注釈”のいずれかを値としてとることができ、指定が省略された場合には“参考”が値として与えられることを規定している。
【0078】
図4に示すDTDに従って記述されたSGML文書の一例を、図5に示す。文書先頭の、文字列“<!DOCTYPE”と文字列“>”で囲まれた部分を文書型宣言と呼び、そのSGML文書が従うDTDと、最上位要素の要素型名を宣言する。図5に示した例では、この文書がファイル“ronbun.dtd”に格納されているDTDに従い、最上位要素の要素型名は“論文”であることが規定されている。ここでは、ファイル“ronbun.dtd”に図4に示した前記DTDが格納されているものとする。
【0079】
図5に示すとおり、SGMLでは文書を構成する個々の要素について、その先頭位置と末尾位置を示すマークを付加することにより、文書構造を明示的に記述する。各要素の先頭位置を示すマークを“開始タグ”、終了位置を示すマークを“終了タグ”と呼ぶ。開始タグは、文字列“<”と“>”との間に、その要素の要素型名を記述することによって示す。終了タグは、文字列“</”と“>”との間に、その要素の要素型名を記述することによって示す。要素が属性を持つ場合、属性値の指定を開始タグ中(要素型名の後ろ)に記述することができる。属性値の指定は、属性名と属性値との間に文字列“=”を置くことによって示す。例えば図5において、開始タグ“<備考 type=注釈>”は、要素“備考”の属性“type”に属性値“注釈”を与えている。SGML文書中において、これらのタグを用いて文書構造を記述している部分を「文書インスタンス」と呼ぶ。
【0080】
図3におけるステップ304の詳細、すなわち本実施例における文書構造解析プログラム210の処理手順を示すPAD図を、図7に示す。
【0081】
図7に示すとおり、文書構造解析プログラム210は、SGMLを用いて記述された1個の登録対象文書を入力として起動されると、まず該文書の先頭に記述された文書型宣言を読み、その構文を解析する(ステップ701)。次に、ステップ702において、文書型宣言中における構文エラーの有無を判定する。構文エラーが検出された場合、ステップ703に進み、エラーメッセージを出力して処理を中断する。
【0082】
文書型宣言に構文エラーがない場合にはステップ704に進み、その文書型宣言で指定されているDTDファイルが存在するかどうかを判定する。DTDファイルが検出されない場合、ステップ705に進み、エラーメッセージを出力して処理を中断する。
【0083】
DTDファイルが検出された場合にはステップ706に進み、該ファイルの内容を読み込んでその構文解析を行う。次に、ステップ707において、DTD中における構文エラーの有無を判定する。構文エラーが検出された場合、ステップ708に進み、エラーメッセージを出力して処理を中断する。構文エラーが検出されなかった場合にはステップ709に進み、DTDが定義する文書構造モデルを記述したデータである文書構造テーブルをメモリ上に生成する。
【0084】
次に、ステップ710において、前記文書構造テーブルを参照しながら文書インスタンスを読み込み、構造解析を行い、その結果として解析済み文書データを生成する。次に、ステップ711において、文書インスタンス中に構文エラーや構造エラー(DTDが定義する構造モデルからの逸脱)がないかどうかを判定する。構文エラーまたは構造エラーが検出された場合にはステップ712に進み、エラーメッセージを出力して処理を中断する。エラーが検出されなかった場合にはステップ713に進み、前記登録対象文書を識別する文書識別子と、前記ステップ710における構造解析によって得られた解析結果データとからなる解析済み文書データを、解析済み文書データ格納領域217に出力して処理を終了する。
【0085】
ここで一例として、図5に示すSGML文書を登録対象文書として文書構造解析プログラム210を実行し、該文書が参照するDTDファイル“ronbun.dtd”の内容が図4に示すDTDだった場合について説明する。この場合、ステップ709において生成される文書構造テーブルは、図8に示すようなデータ構造をとる。図8に示すとおり、文書構造テーブルは構造定義と属性定義の二つの部分からなる。構造定義は、DTDを構成する各要素型の要素型名に対応させて、その要素型に属する要素がとりうる内容のデータモデルを定義する。また属性定義は、DTDを構成する各要素型の要素型名に対応させて、その要素型に属する要素が持つ各属性の属性名、属性値のタイプおよびデフォルト値を定義する。この構造定義を参照することにより、文書インスタンス中に現れる要素群の並び順や階層関係が正しいかどうか(構造エラーの有無)を判断し、また省略されたタグや属性値指定があった場合、それらを補足することができる。
【0086】
図5に示すSGML文書が登録対象文書として文書構造解析プログラム210への入力として与えられ、そのDTDが図4に示すものだった場合、図6に示す木構造データが解析済み文書データとして得られる。図6は、図5に示すSGML記述によって表現されている文書の論理構造を、図形的に示した模式図である。図6に示すように、構造化文書の持つ論理的構造は、個々の要素を中間節、文字列データを終端節とする木構造としてとらえることができる。図6では、各要素を楕円形、文字列データを矩形で表わしている。
【0087】
なお、本実施例ではSGMLを用いて記述された構造化文書を登録対象文書として処理する構成をとったが、ODA(Open Document Architecture)など、他の形式によって記述された構造化文書を登録対象文書とするように構成することもできる。
【0088】
図9は、図3におけるステップ305の詳細、すなわち本実施例における構造インデックス作成プログラム211の処理手順を示すPAD図である。
【0089】
構造インデックス作成プログラム211は、まずステップ901において、既存の構造インデックスが構造インデックス格納領域218中に存在しているかどうかを判定する。該領域中に構造インデックスが存在しない場合にはステップ902に進み、初期状態(空)の構造インデックスを生成する。既存の構造インデックスを検出した場合にはステップ903に進み、該構造インデックスを読み込む。
【0090】
次に、ステップ904において、解析済み文書データ格納領域217から登録対象文書の解析済み文書データを読み込む。
【0091】
次に、ステップ905において、前記解析済み文書データの木構造を構成するすべてのノード(要素および文字列データ)を対象として、ステップ906からステップ909に示す処理を繰り返す。
【0092】
ステップ906では、解析済み文書データ中で現在着目しているノードについて、構造インデックス中に、該ノードに対応するメタノード(メタ要素またはメタ文字列データ)が存在するかどうかを判定する。対応メタノードが存在しない場合はステップ907に進み、該ノードに対応するメタノードを生成して構造インデックスに登録し、さらに該登録したメタノードに対して、該メタノードを構造インデックス中で一意に識別する番号である文脈識別子を割り当てる(ステップ908)。ステップ909では、解析済み文書データ中で現在着目しているノードと、構造インデックス中で該ノードに対応するメタノードを識別する文脈識別子との対応関係を、解析済み文書データに付加して該解析済み文書データを更新する。
【0093】
ステップ905以下の繰り返しを終了するとステップ910に進み、前記更新された解析済み文書データを出力して解析済み文書データ格納領域217に格納する。次に、ステップ911では、前記更新された構造インデックスを出力して構造インデックス格納領域218に格納し、処理を終了する。
【0094】
ここで、前記ステップ905において解析済み文書データの木構造を構成するすべてのノードを対象とする繰り返し処理を行う際に、該木構造を辿り、個々のノードを処理していく順序を図10を用いて説明する。図10では、楕円形で要素ノード、矩形で文字列ノードを表現し、あるノードが複数の下位ノードを持つ場合には、各下位ノードをその出現順に左から右に並べて表現している。また、各ノードに表示された数字がその処理順序を示している。図10に示すとおり、ステップ905においてノード群を処理していく順序は、木構造の根に位置するノードから出発し、ある特定のノードとその下位ノード群を処理する際には、まず該ノードの処理を行い、次に該ノードの下位ノード群を、その出現順に従って処理していく順序となる。
【0095】
次に、前記ステップ906における処理、すなわち解析済み文書データ中で現在着目しているノードについて、構造インデックス中に、該ノードに対応するメタノードが存在するかどうかを判定する処理の内容を、図11を用いて説明する。図11は、図の左側に示す解析済み文書データの木構造を構成するノード群と、右側に示す構造インデックスの木構造を構成するノード(メタノード)群との対応関係を示す図である。
【0096】
ここで、本実施例では、解析済み文書の木構造中におけるあるノードの木構造アドレスと、構造インデックスの木構造中におけるあるメタノードの木構造アドレスとが等しい場合に、該ノードと該メタノードとは対応するものと定義する。ここでいう木構造アドレスとは、木構造の根から出発して上位ノードから下位ノードへと辿り、特定のノードに至るまでの道筋を、該道筋上に存在する各ノードの種別(要素か文字列データか、要素の場合、どの要素型に属するか)と、それらのノードが種別の等しい兄弟ノード群中で何番目に現れたかを示す番号との組み合わせによって表現するアドレスのことである。
【0097】
例えば、図11に示す解析済み文書データ中のノード群のうち、ノード1101は上位ノードをもたず、兄弟ノード中では最初の“論文”要素ノードであるから、その木構造アドレスは“/論文[1]”と表記することができる。同様に、ノード1102はノード1101の下位ノードであり、兄弟ノード中では最初の“章”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]”と表記することができる。また、ノード1103はノード1102の下位ノードであり、兄弟ノード中では2番目の“節”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]/節[2]”と表記することができる。また、ノード1104はノード1103の下位ノードであり、兄弟ノード中では最初の“段落”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]/節[2]/段落[1]”と表記することができる。
【0098】
同様にして、図11右側の構造インデックスの木構造を構成する各メタノードについてその木構造アドレスを求めてみると、メタノード1105の木構造アドレスは“/論文[1]”となり、ノード1101の木構造アドレスと等しくなる。同様に、メタノード1106の木構造アドレスは“/論文[1]/章[1]”となってノード1102の木構造アドレスと等しく、メタノード1107の木構造アドレスは“/論文[1]/章[1]/節[2]”となってノード1103の木構造アドレスと等しくなる。よって、前記ステップ906において、ノード1101はメタノード1105と、ノード1102はメタノード1106と、ノード1103はメタノード1107とそれぞれ対応するものと判定される。
【0099】
なお、図11の構造インデックス中にはノード1104と等しい木構造アドレスを持つメタノードはないので、ノード1104と対応するメタノードは構造インデックス中に存在しないものと判定され、前記ステップ907において新たなメタノードが生成され、該メタノードが構造インデックスに登録されることになる。前記ステップ907において、あるノードに対応する新たなメタノードを登録する際には、該ノードの上位ノードに対応するメタノードの持つ下位ノード群の末尾に、該ノードに対応する種別のメタノードを追加する。図11のノード1104に対応するメタノードを登録する場合には、ノード1104の上位ノードであるノード1103に対応するメタノード1107の下位に、要素型“段落”のメタノードが追加され、該メタノードは兄弟メタノード群の末尾に置かれることになる。
【0100】
次に、複数の解析済み文書データを順次重ね合わせることにより構造インデックスを生成していく過程について、図12を用いて説明する。図12において、1201、1203および1205は、それぞれ登録対象文書の解析済み文書データを表わしている。これらの解析済み文書データの構造を既存の構造インデックス上に順次重ね合わせることにより、構造インデックスが形成されていく。まず最初に文書1の解析済み文書データ1201が入力されると、最初の段階では構造インデックスは初期状態(空)であるため、該解析済みデータと等価な木構造が生成されてそのまま構造インデックスに登録され、構造インデックスは1202に示す状態となる。新たに生成されたメタ要素にはE1からE5までの文脈識別子、新たに生成されたメタ文字列データにはC1からC3までの文脈識別子が割り当てられる。
【0101】
次に文書2の解析済み文書データ1203が入力されると、既存の構造インデックス(1202)と構造が重複する部分については何も行わず、1202上に対応する部分がなかった部分構造(図中の斜線部分)だけが新たに登録される。新たに生成されたメタ要素には文脈識別子E6およびE7、新たに生成されたメタ文字列データには文脈識別子C4が割り当てられる。次に文書3の解析済み文書データ1205が入力されると、既存の構造インデックス(1204)と構造が重複する部分については何も行わず、1204上に対応する部分がなかった部分構造(図中の斜線部分)だけが新たに登録される。新たに生成されたメタ要素には文脈識別子E8、E9およびE10、新たに生成されたメタ文字列データには文脈識別子C5およびC6が割り当てられる。このようにして、3個の文書が登録された段階で、構造インデックスは1206に示す状態となる。
【0102】
図13は、図3におけるステップ306の詳細、すなわち本実施例における構造化全文データ生成プログラム212の処理手順を示すPAD図である。
【0103】
構造化全文データ生成プログラム212は、まずステップ1301において、解析済み文書データ格納領域217から前記登録対象文書の解析済み文書データを読み込む。
【0104】
次に、ステップ1302において、前記登録対象文書を識別する文書識別子を構造化全文データ格納領域219に出力する。
【0105】
次に、ステップ1303において、前記解析済み文書データの木構造を構成するすべてのノード(要素ノードおよび文字列データノード)を対象として、ステップ1304からステップ1306に示す処理を繰り返す。
【0106】
ステップ1304では、解析済み文書データ中で現在着目しているノードについて、該ノードが要素ノードであるか文字列データノードであるかを判定し、該ノードが文字列データノードである場合に限りステップ1305に進む。ステップ1305では、前記解析済み文書データから、前記現在着目している文字列データノードに対応する文脈識別子を求め、該文脈識別子を構造化全文データ格納領域219に出力する。次に、ステップ1306で、前記現在着目している文字列データノードの内容文字列を構造化全文データ格納領域219に出力する。
【0107】
ステップ1303以下の繰り返しをすべて終了した段階で本プログラムは処理を終了する。
【0108】
図14に、構造化全文データ生成プログラム212が出力する構造化全文データのファイル形式を示す。図14は、図5に示したSGML文書を入力として構造化全文データを生成した場合について例示している。図14に示すとおり、本実施例における構造化全文データのデータファイルは、先頭に文書識別子を記述し、その後ろに、文脈識別子と該文脈識別子に対応する内容文字列との対を、文書中に存在する文字列データの数だけ繰り返した構造をとる。
【0109】
例えば、図14に示す構造化全文データに対応する登録対象文書の文書識別子は“D1”であり、図5において“日付”要素の内容として記述されていた文字列データには文脈識別子“C5”が与えられている。なお、図14他ではこれらの識別子を記号により表現しているが、文書識別子としてデータ中に実際に記録される値は登録対象文書の集合中で特定の文書を一意に識別する番号(整数値)であり、文脈識別子の値は構造インデックスを構成するメタノードの集合中で特定のメタノードを一意に識別する番号(整数値)である。
【0110】
図15は、図3におけるステップ307の詳細、すなわち本実施例における文字列インデックス作成プログラム213の処理手順を示すPAD図である。
【0111】
文字列インデックス作成プログラム213は、まずステップ1501において、既存の文字列インデックスが文字列インデックス格納領域220中に存在しているかどうかを判定する。該領域中に文字列インデックスが存在しない場合にはステップ1502に進み、初期状態(空)の文字列インデックスを生成する。既存の文字列インデックスを検出した場合にはステップ1503に進み、該文字列インデックスを読み込む。
【0112】
次に、ステップ1504において、登録対象文書の構造化全文データを構造化全文データ格納領域219から読み込む。
【0113】
次に、ステップ1505において、前記構造化全文データを構成するすべての内容文字列を対象として、ステップ1506から1507に示す処理を繰り返す。
【0114】
ステップ1506では、構造化全文データ中で現在着目している内容文字列から、所定の部分文字列を抽出する。ステップ1507では、前記ステップ1506で抽出した各部分文字列と該部分文字列の構造化文字位置情報との対応関係を、前記文字列インデックスに登録する。
【0115】
ステップ1505以下の繰り返しを終了するとステップ1508に進み、不要となった構造化全文データを構造化全文データ格納領域219から削除して破棄する。次に、ステップ1509において、更新された文字列インデックスを出力して文字列インデックス格納領域220に格納し、処理を終了する。
【0116】
ここで、前記ステップ1506において、ある内容文字列から所定の部分文字列を抽出する際には、予め抽出すべき部分文字列の長さを定めておき、対象とする内容文字列の先頭から出発して、開始位置を1ずつ増しながら前記予め定めておいた長さの部分文字列を順次抽出する。例えば、抽出する部分文字列の長さを2文字とし、処理対象として図14に示す内容文字列群のうち文脈識別子C129に対応する内容文字列“変換処理の実例”を用いた場合、抽出される部分文字列は“変換”、“換処”、“処理”、“理の”、“の実”および“実例”の6個となる。
【0117】
更に、内容文字列の末尾部分については、長さ1文字から部分文字列長−1文字までの各部分文字列をも抽出する。前記の例では“例”が抽出される。これらの部分文字列を前記ステップ1507において文字列インデックスに登録する際には、各部分文字列と、それらが出現した位置を表わす構造化文字位置情報との対応関係を登録する。ここで、構造化文字位置情報は、対応する部分文字列を含む文書の文書識別子、該文書中において前記部分文字列を含む文字列データの文書構造中における位置を識別する文脈識別子、および文書中における前記部分文字列の先頭文字位置から構成される。
【0118】
図16に、本実施例における文字列インデックスのデータ構造を示す。図16は、文字列インデックス作成プログラム213を用いて図14に示す構造化全文データを処理し、文字列インデックスに該構造化全文データに含まれる部分文字列群の登録を終えた段階において、該文字列インデックスのデータ構造の一部(前記内容文字列“変換処理の一例”に関連する部分)を図示したものである。ただし、図16では、前記内容文字列の末尾“例”に対応する文字ノードおよび構造化文字位置情報は省略している。また、前記内容文字列の直前に位置する文字の文字位置を“X”として、相対的に文字位置を表現している。
【0119】
図16に示すとおり、文字列インデックスは、登録対象文書中に現れる所定長さの部分文字列すべてについて、その出現位置情報(文書識別子、文脈識別子および先頭文字位置の組み合わせからなる構造化文字位置情報)のリストを保持する。ここで、インデックス検索を高速化するため、1文字目が共通する部分文字列群については、1文字目の情報をすべての部分文字列が共有するデータ構造をとり、また文字列インデックスのルートから1文字目のノードへのポインタの並びは、ポインタが指す文字の文字コード順となるように配列する。同様に、1文字目のノードから2文字目のノードへのポインタの並びも、ポインタが指す文字の文字コード順となるように配列する。
【0120】
文書データベースに登録するすべての登録対象文書を処理してその内部に現れる部分文字列群を文字列インデックスに登録しておけば、この文字列インデックスを参照するだけで(文書データ本体を一切走査することなく)任意の2文字からなる文字列がどの文書中のどの位置に出現するかを知ることができる。(2文字以外の長さの文字列を検索する方法については後述する。)
なお、本実施例では、予め定める部分文字列の長さを2文字としたが、該長さをこれ以外の値としても同様な文字列インデックスを構築することができる。また、本実施例では部分文字列の長さを固定長としたが、この長さを可変として同様な文字列インデックスを構築することもできる。
【0121】
以上が、本実施例における文書登録サブシステム101の説明である。
【0122】
以下、本発明の第一の実施例における文書検索サーバ、すなわち図1の102について説明する。
【0123】
図17は、本実施例における文書検索サーバ102の構成を示す図である。
【0124】
図17に示す文書検索サーバ102は、ディスプレイ201、キーボード202、中央処理装置(CPU)203、通信制御装置206、主メモリ207、磁気ディスク装置208、システムバス209から構成される。
【0125】
ディスプレイ201は、本サーバの稼動状況等を表示するために使用する。キーボード202は、本サーバの起動・停止等を指示するコマンドを入力するために使用する。中央処理装置203は、本サーバを構成する各種プログラムを実行する。通信制御装置206は、ネットワーク105を介して前記文書登録サブシステム101および前記検索クライアント(103および104)と通信し、リクエストおよびデータの交換を行うために使用する。主メモリ207は、本サーバによる処理を実行するための各種プログラムおよび一時的なデータを保持するために使用する。磁気ディスク装置208は、文書データベースを構成する文書データ群および本サーバが文書検索時に参照するインデックスデータを格納するために使用する。システムバス209は、これらの各種装置を接続するために使用する。
【0126】
主メモリ207中には、検索条件解析プログラム1701、文字列インデックス検索プログラム1702、文書検索制御プログラム1703およびシステムプログラム215が格納され、またワークエリア216が保持される。磁気ディスク装置208中には、解析済み文書データ格納領域217、構造インデックス格納領域218、文字列インデックス格納領域220および検索結果データ格納領域1704が確保される。
【0127】
検索条件解析プログラム1701は、検索クライアント103および104から受信した検索リクエスト中に含まれる検索条件式を解析し、文字列インデックス検索プログラム1702によって直接検索可能な条件指定に翻訳する。文字列インデックス検索プログラム1702は、検索条件解析プログラム1701によって翻訳された条件指定に従って、文字列インデックス格納領域220に格納されている文字列インデックスを検索し、得られた検索結果データを検索結果データ格納領域1704に格納する。
【0128】
文書検索制御プログラム1703は、検索条件解析プログラム1701および文字列インデックス検索プログラム1702の起動および実行制御を行うとともに、ネットワーク105を介して、文書登録サブシステム101および検索クライアント(103および104)との間でリクエストおよびデータの交換を行う。システムプログラム215は、周辺装置との間のデータの入出力など、コンピュータ上で本サーバを構成する各プログラムを実行するための基本機能を提供する。ワークエリア216は、プログラムの実行時に一時的に必要となるデータを記憶するために用いられる。
【0129】
なお、本実施例では文書登録サブシステム101および検索クライアント103および104との間でデータを転送するためにネットワーク105を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。また、文書登録サブシステム101と文書検索サーバ102を1台のコンピュータ上に実装し、これらの間でデータ転送を行わない構成をとることもできる。また、1個以上の検索クライアントを文書検索サーバ102と同一のコンピュータ上で実行し、これらの間でデータ転送を行わない構成をとることもできる。
【0130】
図18は、本発明の第一の実施例における文書検索処理の概略手順を示すPAD図である。キーボード202からのサーバ起動コマンド等により文書検索制御プログラム1703が起動されると、本プログラムはサーバとして文書登録サブシステム101および検索クライアント(103、104等)からリクエストを受信してはその処理を行うループに入る(ステップ1801)。このループは、キーボード202からサーバの停止を指示するコマンドが入力されるまで継続する。
【0131】
ステップ1801のループは、文書登録サブシステム101および検索クライアント(103および104)からリクエストを受信する処理(ステップ1802)と、受信したリクエストの種別を判定し、該種別に対応する処理に分岐する処理(ステップ1803)を繰り返す。
【0132】
ステップ1803では、受信したリクエストの種別を判定し、該リクエストが、文書登録サブシステム101から送信されたデータベース更新リクエスト(新たな文書群を登録して文書データベースを更新することを求めるリクエスト)であった場合、ステップ1804およびステップ1805からなる処理に分岐する。
【0133】
また、前記リクエストが、検索クライアント(103、104等)から送信された文書検索リクエスト(特定の検索条件を満たす文書群の検索を求めるリクエスト)であった場合、ステップ1806、1807および1808からなる処理に分岐する。また、前記リクエストが、検索クライアント(103、104等)から送信された、検索結果問い合わせリクエスト(特定の検索処理の結果を問い合わせるリクエスト)であった場合、ステップ1809からなる処理に分岐する。また、前記リクエストが、検索クライアント(103、104等)から送信された、文書転送リクエスト(指定された文書データの転送を求めるリクエスト)であった場合、ステップ1810からなる処理に分岐する。分岐先の処理が終了した後は再びステップ1802に戻ってループを継続する。
【0134】
ステップ1804では、文書登録サブシステム101から、新規に登録された文書群の解析済み文書データを受信し、該解析済み文書データを解析済み文書データ格納領域216に追加する。次に、ステップ1805では、文書登録サブシステム101から、新規に登録された前記文書群の内容を反映して更新された構造インデックスおよび文字列インデックスを受信し、これらをそれぞれ構造インデックス格納領域218および文字列インデックス格納領域220に格納する。
【0135】
ステップ1806では、検索条件解析プログラム1701を実行し、文書検索リクエスト中で指定されている検索条件を解析し、該検索条件を、文字列インデックス検索プログラム1702によって直接処理可能な条件指定(以下、これを展開済み検索条件データと呼ぶ)に変換する。次に、ステップ1807では、前記ステップ1806によって生成された展開済み検索条件データを入力として文字列インデックス検索プログラム1702を実行し、該展開済み検索条件データが指定する条件を満たす文書群を検索して、検索結果データを求め、該検索結果データを一意に識別する検索結果識別子と対応付けて検索結果データ格納領域1704に格納する。次に、ステップ1808では、前記検索結果識別子を、要求元の検索クライアントに返送する。
【0136】
ステップ1809では、問い合わせの内容に応じて前記ステップ1807で求めた検索結果データの一部または全体を検索結果データ格納領域1704から抽出し、要求元の検索クライアントに転送する。
【0137】
ステップ1810では、文書転送リクエスト中で指定されている文書(複数の文書が指定されている場合には指定されている文書すべて)の解析済み文書データを解析済み文書データ格納領域217から抽出し、要求元の検索クライアントに転送する。
【0138】
図19は、図18におけるステップ1806の詳細、すなわち本実施例における検索条件解析プログラム1701の処理手順を示すPAD図である。
【0139】
検索条件解析プログラム1701は、文書検索リクエスト中で指定されている検索条件を入力として起動されると、まずステップ1901において、該検索条件中に構造条件が含まれているかどうかを判定する。そして、構造条件が含まれている場合に限り、ステップ1902およびステップ1903からなる処理を実行する。構造条件が含まれていなかった場合にはステップ1904に進む。
【0140】
ステップ1902では、構造インデックス格納領域218から構造インデックスを読み込む。次に、ステップ1903では、該構造インデックスを参照して、前記構造条件を満たす構造内に含まれるすべての文字列データの文脈識別子の集合を求める。以下、該集合を文脈識別子集合と呼ぶ。
【0141】
ステップ1904では、前記検索条件中に文字列条件として指定された文字列の長さが、前記文字列インデックスを作成する際に予め定めた部分文字列長を超えているかどうかを判定する。前記指定文字列の長さが前記部分文字列長を超えている場合にはステップ1905に進み、前記指定文字列の先頭から、開始文字位置を1ずつ増しつつ、前記部分文字列長に等しい長さの部分文字列群を抽出し、これらの部分文字列を要素とする部分文字列リストを生成する。前記指定文字列の長さが前記部分文字列長を超えていない場合にはステップ1906に進み、空の(要素をもたない)部分文字列リストを生成する。
【0142】
ステップ1907では、前記ステップ1903で求めた文脈識別子集合、前記検索条件中に含まれていた指定文字列、および前記ステップ1905またはステップ1906で生成した部分文字列リストから構成される展開済み部分文字列データを生成して処理を終了する。
【0143】
ここで、図20は、検索条件解析プログラム1701の処理過程における、展開済み解析条件データの生成例を示す図である。
【0144】
図20において、2001は、文書検索リクエスト中で指定された検索条件の一例である。検索条件2001は、構造条件指定“章/段落[1]”と、文字列条件指定“ガード”とから構成されている。前記検索条件は、“章”要素の直接の下位にある最初の“段落”要素内に、文字列“ガード”が出現するケースを検索すべきことを指定している。
【0145】
ここで、構造インデックスの内容が2002に示すとおりであったとすると、前記ステップ1903においてこの構造インデックスを参照することにより、前記構造条件指定を満たす“段落”要素の文脈識別子はE5およびE14であることがわかる。従って、これらの段落の下位にある文字列データ、すなわち文脈識別子がC3またはC9である文字列データ内に、文字列“ガード”が出現するケースを検索すればよいことがわかる。ただし、検索に用いる文字列インデックスには、長さ2の部分文字列についてのみその出現位置が登録されているので、3文字からなる前記指定文字列を直接検索することはできない。そこで、ステップ1905において、前記指定文字列を分解して長さ2の部分文字列からなるリストを生成する。前記のとおり指定文字列が“ガード”だった場合、抽出される部分文字列は“ガー”および“ード”となる。
【0146】
この結果、前記ステップ1907において、2003に示す展開済み検索条件データ、すなわち文脈識別子集合が{C3,C9}、指定文字列が“ガード”、部分文字列リストが{“ガー”,“ード”}であるデータが生成される。
【0147】
図21は、図18におけるステップ1807の詳細、すなわち本実施例における文字列インデックス検索プログラム1702の処理手順を示すPAD図である。
【0148】
文字列インデックス検索プログラム1702は、前記検索条件解析プログラム1701が生成した展開済み検索条件データを入力として起動される。本プログラムは、起動されるとまずステップ2101において、文字列インデックス格納領域220から文字列インデックスを読み込む。次に、ステップ2102に進み、検索結果データを初期化する。
【0149】
次に、ステップ2103では、前記展開済み検索条件データ中に含まれている指定文字列の長さと、前記文字列インデックスを作成する際に予め定めた部分文字列の長さとを比較する。前記指定文字列の長さが前記部分文字列の長さに等しい場合にはステップ2104に分岐する。前記指定文字列の長さが前記部分文字列の長さに満たない場合にはステップ2105に分岐する。前記指定文字列の長さが前記部分文字列の長さを超える場合にはステップ2106に分岐する。
【0150】
ステップ2104では、文字列インデックス中で前記指定文字列を検索し、該文字列に対応している構造化文字位置の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【0151】
ステップ2105では、文字列インデックス中で前記指定文字列を検索し、該文字列の末尾に対応する文字ノードより前方に存在するすべての構造化文字位置情報の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【0152】
ステップ2106では、前記展開済み検索条件データ中の部分文字列リストを構成する各部分文字列について、ステップ2107を繰り返す。ステップ2107では、文字列インデックス中で前記部分文字列を検索し、該文字列に対応している構造化文字位置情報の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群を前記部分文字列に対応付けて記憶する。
【0153】
ステップ2106での繰り返しを終了するとステップ2108に進み、前記ステップ2107で対応付けを行った構造化文字位置情報群について連接判定処理を行い、連続した文字列として前記指定文字列を構成する構造化文字位置情報のグループのみを抽出し、該抽出した各グループ中で前記指定文字列の先頭に位置する部分文字列に対応する構造化文字位置情報のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【0154】
ステップ2103から分岐したすべての処理を終えるとステップ2109に進み、前記ヒット位置集合中に含まれる構造化文字位置情報群を、同一の文書識別子を持つものからなるグループにまとめて前記検索結果データに登録する。
【0155】
ここで、前記ステップ2108、すなわち文字列インデックス検索プログラム1702の処理過程における連接判定処理について、図22を用いてさらに詳しく説明する。
【0156】
図22において、2201は、文字列インデックスの一例(部分)を表わしている。2201に示すデータを保持している文字列インデックス上で、図20の2003に示す展開済み検索条件データが示す条件に従って検索を行うと、前記ステップ2107に示したとおり、まず部分文字列“ガー”および“ード”に対応する構造化文字位置情報群の中から、文脈識別子がC3またはC9であるもののみが抽出される。該抽出された構造化文字位置情報群を、部分文字列に対応付けたデータを2202に示す。連接判定処理は該データの上で行われる。
【0157】
前記ステップ2108に示す連接判定処理では、抽出された構造化文字位置情報群の中に、全体として前記指定文字列を構成する一連の構造化文字位置情報の組み合わせが存在するかどうかを判定する。ここで、このような組み合わせは次に示す条件を満たさなければならない。
【0158】
(1)構造化文字位置情報群の間で、文書識別子がすべて一致している。
【0159】
(2)構造化文字位置情報群の間で、文脈識別子がすべて一致している。
【0160】
(3)構造化文字位置情報を、その文字位置の値が小さいものから順に並べ、それらの文字位置に従って対応する部分文字列群を配置すると、全体として指定文字列に等しい文字列が得られる。
【0161】
ここで、2202に示す事例には、全体として指定文字列“ガード”を構成する組み合わせが一例含まれている。
【0162】
上記の条件を満たす構造化文字位置情報の組み合わせが見つかると、該組み合わせ中に含まれる構造化文字位置情報群のうち、文字位置の値が最小であるものを代表として選び、前記ヒット位置集合に登録する。
【0163】
次に、図23は、個々の検索処理の結果として生成される検索結果データのデータ構造を示す図である。本図に示すとおり、検索結果データは、ヒット位置集合中に含まれる文字位置情報群を文書識別子ごとにグループ化し、それらのグループを要素とするリストを作り、さらに検出文書の総数を示す情報を付加した構造を持つ。検索結果データは、検索結果データの集合中でその検索結果データを一意に識別する検索結果識別子と対応付けられたうえで、検索結果データ格納領域1704に格納される。
【0164】
次に、図18におけるステップ1809、すなわち検索結果問い合わせリクエストの内容に対応して検索結果を要求元クライアントに転送する処理について、図24を用いてさらに詳しく説明する。図24は、前記ステップ1809の詳細な処理手順を示すPAD図である。
【0165】
ここで、検索結果問い合わせリクエストの本体は、検索結果識別子指定、問い合わせ種別指定および文書識別子指定の三部分からなる。問い合わせの種別によっては、文書識別子指定をもたない場合もある。
【0166】
図24に示すとおり、前記ステップ1809に対応する処理では、まずステップ2401において、問い合わせリクエスト中で指定されている検索結果識別子に対応する検索結果データを検索し、該検索結果データを検索結果データ格納領域1704から読み込む。
【0167】
次に、ステップ2402では、問い合わせ種別を判定し、該問い合わせ種別が検出文書数問い合わせであった場合にはステップ2403、該問い合わせ種別が文書識別子問い合わせであった場合にはステップ2404、該問い合わせ種別が文字位置情報問い合わせであった場合にはステップ2405に分岐する。
【0168】
ステップ2403では、前記ステップ2401で読み込んだ検索結果データから検出文書数を抽出し、該検出文書数の値を要求元の検索クライアントに転送して処理を終了する。
【0169】
ステップ2404では、前記ステップ2401で読み込んだ検索結果データ中に含まれるすべての文書識別子からなる集合を求め、該集合を要求元の検索クライアントに転送して処理を終了する。
【0170】
ステップ2405では、前記ステップ2401で読み込んだ検索結果データから、問い合わせ中で指定された文書識別子に対応する構造化文字位置情報のリストを抽出し、該リストを要求元の検索クライアントに転送して処理を終了する。
以上が、本実施例における文書検索サーバ102の説明である。
【0171】
以下、本発明の第一の実施例における文書検索クライアント、すなわち図1の103および104について説明する。
【0172】
図25は、103および104に共通する、本実施例における文書検索クライアントの構成を示す図である。
【0173】
図25に示す文書検索クライアントは、ディスプレイ201、キーボード202、中央処理装置(CPU)203、通信制御装置206、主メモリ207、磁気ディスク装置208、システムバス209から構成される。
【0174】
ディスプレイ201は、ユーザが対話的に検索条件を入力するための画面や検索結果等を表示するために使用する。キーボード202は、検索条件、検索処理の実行等を指示するコマンドを入力するために使用する。中央処理装置203は、本クライアントを構成する各種プログラムを実行する。通信制御装置206は、ネットワーク105を介して前記文書検索サーバ102と通信し、リクエストおよびデータの交換を行うために使用する。主メモリ207は、本クライアントによる処理を実行するための各種プログラムおよび一時的なデータを保持するために使用する。磁気ディスク装置208は、検索結果として得られた文書およびその他のデータを格納するために使用する。システムバス209は、これらの各種装置を接続するために使用する。
【0175】
主メモリ207中には、検索条件入力プログラム2501、検索結果表示プログラム2502、クライアント制御プログラム2503およびシステムプログラム215が格納され、またワークエリア216が保持される。磁気ディスク装置208中には、解析済み文書データ格納領域217および検索結果データ格納領域1704が確保される。
【0176】
検索条件入力プログラム2501は、ユーザと対話しつつ検索条件の入力および解釈を行う。検索結果表示プログラム2502は、文書検索サーバ102から受け取った検索結果の表示を行う。クライアント制御プログラム2503は、検索条件入力プログラム2501および検索結果表示プログラム2502の起動および実行制御を行うとともに、ネットワーク105を介して、文書検索サーバ102との間でリクエストおよびデータの交換を行う。システムプログラム215は、周辺装置との間のデータの入出力など、コンピュータ上で本クライアントを構成する各プログラムを実行するための基本機能を提供する。ワークエリア216は、プログラムの実行時に一時的に必要となるデータを記憶するために用いられる。
【0177】
なお、本実施例では文書検索サーバ102との間でデータを転送するためにネットワーク105を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。また、1個以上の検索クライアントを文書検索サーバ102と同一のコンピュータ上で実行し、これらの間でデータ転送を行わない構成をとることもできる。本クライアントにプリンタを接続し、検索結果を印刷できるよう構成することもできる。
【0178】
図26は、本発明の第一の実施例における検索クライアントの動作手順を示すPAD図である。キーボード202からのクライアント起動コマンド等によりクライアント制御プログラム2503が起動されると、本プログラムはユーザから文書検索を指示するコマンドを受け取ってはその処理を行うループに入る(ステップ2601)。このループは、キーボード202からクライアントの停止を指示するコマンドが入力されるまで継続する。
【0179】
ステップ2601のループは、ステップ2602からステップ2605までに示す処理を繰り返す。
【0180】
ステップ2602では、検索条件入力プログラム2501を実行し、ユーザとの対話により検索条件を入力し、該検索条件を、文書検索サーバ102が解釈可能な文書検索リクエストに変換する。ステップ2603では、前記文書検索リクエストを、ネットワーク105を介して文書検索サーバ102に送信する。ステップ2604では、文書検索サーバ102から前記文書検索リクエストへの返送として検索結果識別子が返されるのを待ち、該識別子を受信する。
【0181】
ステップ2605では、前記検索結果識別子を入力として検索結果表示プログラム2502を実行し、ユーザと対話しつつ検索結果データの問い合わせおよび画面表示を行う。
【0182】
図27は、前記図26のステップ2602において実行する検索条件入力プログラム2501の詳細な処理手順を示すPAD図である。検索条件入力プログラム2501は、クライアント制御プログラム2503から起動されると、まず検索条件をユーザが対話的に指定するための画面をディスプレイ201に表示する(ステップ2701)。
【0183】
次に、ステップ2702において、前記画面上でユーザが指示した検索条件を読み込む。
【0184】
次に、ステップ2703において、前記ステップ2702において読み込んだ検索条件を、文書検索サーバ102が直接解釈可能な文書検索リクエストの形に変換する。
【0185】
図28は、前記図26のステップ2605において実行する検索結果表示プログラム2502の詳細な処理手順を示すPAD図である。検索結果表示プログラム2502は、クライアント制御プログラム2503から前記検索結果識別子を入力として起動されると、ただちにステップ2801のループに入る。該ループは、ユーザから検索結果表示の終了を指示されるまで、ステップ2802からステップ2815までに示す処理を、繰り返し実行する。
【0186】
前記ステップ2801のループ内では、まずステップ2802において、検索結果の表示とユーザからの指示入力のために用いる画面をディスプレイ201に表示する。次に、ステップ2803において、前記画面上でユーザが指定した指示内容を読み込む。
【0187】
次に、ステップ2804において、前記ユーザ指示の種別を判定し、その種別に対応した分岐を行う。すなわち、該指示が検出文書数の表示を求めるものであった場合にはステップ2805およびステップ2806に示す処理に分岐し、該指示が検出文書群の文書識別子リストの表示を求めるものであった場合にはステップ2807およびステップ2808に示す処理に分岐し、該指示が文書内容の表示を求めるものであった場合にはステップ2809からステップ2815までに示す処理に分岐する。各分岐先の処理が終了するとステップ2802に戻り、再び前記ループを再開する。
【0188】
ここで、ステップ2805では、検出文書数を問い合わせるための検出文書数問い合わせリクエストを生成し、該リクエストを文書検索サーバ102に送信する。次に、ステップ2806では、前記リクエストに対応して文書検索サーバ102から転送されてきた検出文書数を受信し、該数値をディスプレイ201に表示する。
【0189】
ステップ2807では、検出文書群の文書識別子リストを問い合わせるための文書識別子問い合わせリクエストを生成し、該リクエストを文書検索サーバ102に送信する。次に、ステップ2808では、前記リクエストに対応して文書検索サーバ102から転送されてきた文書識別子の集合を受信し、該集合に含まれる文書識別子群をディスプレイ201にリスト表示する。
【0190】
ステップ2809では、表示すべき文書を特定する文書識別子を入力する。次に、ステップ2810では、該識別子が識別する文書の解析済み文書データを得るための文書転送リクエストを生成し、該リクエストを文書検索サーバ102に送信する。次に、ステップ2811では、前記リクエストに対応して文書検索サーバ102から転送されてきた解析済み文書データを受信し、該データを解析済み文書データ格納領域217に格納する。
【0191】
次に、ステップ2812では、前記解析済み文書データ中において、検索条件中に指定した指定文字列が検出された位置を問い合わせるための文字位置情報問い合わせリクエストを生成し、該リクエストを文書検索サーバ102に送信する。次に、ステップ2813では、前記リクエストに対応して文書検索サーバ102から転送されてきた構造化文字位置情報のリストを受信し、該リストを検索結果データ格納領域1704に格納する。
【0192】
次に、ステップ2814では、前記ステップ2811で受信した解析済み文書データおよび前記ステップ2813で受信した構造化文字位置情報リストを参照し、文書検索時における指定文字列検出部分を反転表示するためのデータ加工処理を行う。次に、ステップ2815では、前記反転処理済みの解析済み文書データを、書式化してディスプレイ201上に表示する。
【0193】
以上が、本発明の第一の実施例における検索クライアント103および104の動作手順の説明である。
【0194】
(第二の実施例)
以下、本発明を適用した第二の実施例について、図面を用いて説明する。
【0195】
図29は、本実施例における文書登録サブシステム101の構成を示す図である。
【0196】
図29に示す文書登録サブシステム101は、そのハードウェア構成に関しては、図2に示す第一の実施例の場合と変わらない。ただし、主メモリ207中には、第一の実施例において保持するプログラム群に加えて、逆順構造インデックス作成プログラム2901を保持する。また、磁気ディスク装置208中には、第一の実施例において確保する領域群に加えて、逆順構造インデックス格納領域2902が確保される。逆順構造インデックス作成プログラム2901は、登録対象文書の解析済み文書データが持つ論理構造に関する情報を、逆順構造インデックス格納領域2902に格納されている逆順構造インデックスに登録して逆順構造インデックスを更新する。
【0197】
本実施例において、文書登録制御プログラム214は、文書構造解析プログラム210、構造インデックス作成プログラム211、逆順構造インデックス作成プログラム2901、構造化全文データ生成プログラム212および文字列インデックス作成プログラム213の起動および実行制御を行うとともに、これらのプログラムによって生成された解析済み文書データ、構造インデックス、逆順構造インデックスおよび文字列インデックスをネットワーク105を介して文書検索サーバ102に転送する。
【0198】
なお、本実施例ではフロッピーディスク205に格納された登録対象文書を入力として読み込む構成としたが、光磁気ディスク、追記型光ディスク等、他種の可搬型媒体から読み込む構成をとることもでき、ネットワーク105を介して転送されてくる文書を入力とする構成をとることもできる。さらに、本実施例では生成された解析済み文書データ、構造インデックス、逆順構造インデックスおよび文字列インデックスを文書検索サーバ102に転送するためにネットワーク105を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。あるいは、文書登録サブシステム101と文書検索サーバ102を1台のコンピュータ上に実装し、データ転送を行わない構成をとることもできる。
【0199】
図30は、本発明の第二の実施例における文書登録処理の概略手順を示すPAD図である。本図に示す処理手順は、図3に示す第一の実施例における処理手順とほぼ同様であるが、図3におけるステップ305の直後にステップ3001が追加されている点と、ステップ308の代わりにステップ3002を実行する点が異なる。
【0200】
ここで、ステップ3001では、ステップ304で生成した解析済み文書データを入力として逆順構造インデックス作成プログラム2901を実行する。逆順構造インデックス作成プログラム2901は、まず逆順構造インデックス格納領域2902から現時点での逆順構造インデックスを読み出し、与えられた解析済み文書データの持つ構造情報をこの逆順構造インデックスに登録し、更新された逆順構造インデックスを再び逆順構造インデックス格納領域2902に格納する。
【0201】
ステップ3002では、解析済み文書データ格納領域217に格納されたすべての解析済み文書データ、構造インデックス格納領域218に格納された構造インデックス、逆順構造インデックス格納領域2902に格納された逆順構造インデックス、および文字列インデックス格納領域220に格納された文字列インデックスを、ネットワーク105を介して文書検索サーバ102に転送する。
【0202】
図31は、図30におけるステップ3001の詳細、すなわち本実施例における逆順構造インデックス作成プログラム2901の処理手順を示すPAD図である。
【0203】
逆順構造インデックス作成プログラム2901は、まずステップ3101において、既存の逆順構造インデックスが逆順構造インデックス格納領域2902中に存在しているかどうかを判定する。該領域中に逆順構造インデックスが存在しない場合にはステップ3102に進み、初期状態(空)の逆順構造インデックスを生成する。既存の逆順構造インデックスを検出した場合にはステップ3103に進み、該逆順構造インデックスを読み込む。
【0204】
次に、ステップ3104において、登録対象文書の解析済み文書データを読み込む。
【0205】
次に、ステップ3105において、前記解析済み文書データの木構造を構成するすべてのノード(要素および文字列データ)を対象として、ステップ3106からステップ3109に示す処理を繰り返す。
【0206】
ステップ3106では、解析済み文書データ中で現在着目しているノードについて、逆順構造インデックス中に、該ノードに対応するメタノード(メタ要素またはメタ文字列データ)が存在するかどうかを判定する。対応メタノードが存在しない場合ステップ3107に進み、該ノードに対応するメタノードを生成して逆順構造インデックスに登録し、さらに該登録したメタノードに対して、該メタノードを逆順構造インデックス中で一意に識別する番号である逆順文脈識別子を割り当てる(ステップ3108)。
【0207】
ステップ3109では、解析済み文書データ中で現在着目しているノードと、逆順構造インデックス中で該ノードに対応するメタノードを識別する逆順文脈識別子との対応関係を、解析済み文書データに付加して該解析済み文書データを更新する。
【0208】
ステップ3105以下の繰り返しを終了するとステップ3110に進み、前記更新された解析済み文書データを出力して解析済み文書データ格納領域217に格納する。次に、ステップ3111では、前記更新された逆順構造インデックスを出力して逆順構造インデックス格納領域2902に格納し、処理を終了する。
【0209】
以上に述べたとおり、逆順構造インデックス作成プログラム2901の処理手順は図9に示す構造インデックス作成プログラム211の処理手順とほぼ対応している。しかし、ステップ3105の繰り返しにおいて解析済み文書の木構造を辿る順序が構造インデックス作成プログラム211の場合とは異なっており、その結果構築される逆順構造インデックスの木構造も構造インデックスの木構造とは異なったものとなる。
【0210】
ここで、前記ステップ3105において解析済み文書データの木構造を構成するすべてのノードを対象とする繰り返しを行う際に、該木構造を辿り、個々のノードを処理していく順序を図32を用いて説明する。図32では、楕円形で要素ノード、矩形で文字列ノードを表現し、あるノードが複数の下位ノードを持つ場合には、各下位ノードをその出現順に左から右に並べて表現している。また、各ノードに表示された数字がその処理順序を示している。
【0211】
図32に示すとおり、ステップ3105においてノード群を処理していく順序は、木構造の根に位置するノードから出発し、ある特定のノードとその下位ノード群を処理する際には、まず該ノードの処理を行い、次に該ノードの下位ノード群を、その出現順の逆順に従って処理していく順序となる。
【0212】
次に、前記ステップ3106における処理、すなわち解析済み文書データ中で現在着目しているノードについて、逆順構造インデックス中に、該ノードに対応するメタノードが存在するかどうかを判定する処理について、図33を用いて説明する。図33は、図の左側に示す解析済み文書データの木構造を構成するノード群と、右側に示す逆順構造インデックスの木構造を構成するノード(メタノード)群との対応関係を示す図である。
【0213】
ここで、本実施例では、解析済み文書の木構造中におけるあるノードの逆順木構造アドレスと、逆順構造インデックスの木構造中におけるあるメタノードの逆順木構造アドレスとが等しい場合に、該ノードと該メタノードとは対応するものと定義する。ここでいう逆順木構造アドレスとは、木構造の根から出発して上位ノードから下位ノードへと辿り、特定のノードに至るまでの道筋を、該道筋上に存在する各ノードの種別(要素か文字列データか、要素の場合、どの要素型に属するか)と、それらのノードが種別の等しい兄弟ノード群中で後ろから何番目に現れたかを示す番号との組み合わせによって表現するアドレスのことである(通常の木構造アドレスと区別するため、逆順木構造アドレスでは前記番号を負の整数として表記する)。
【0214】
例えば、図33に示す解析済み文書データ中のノード群のうち、ノード3301は上位ノードをもたず、兄弟ノード中では最後の“論文”要素ノードであるから、その逆順木構造アドレスは“/論文[-1]”と表記することができる。同様に、ノード3302はノード3301の下位ノードであり、兄弟ノード中では最後の“章”要素ノードであるから、その逆順木構造アドレスは“/論文[-1]/章[-1]”と表記することができる。また、ノード3303はノード3302の下位ノードであり、兄弟ノード中では後ろから2番目の“節”要素ノードであるから、その逆順木構造アドレスは“/論文[-1]/章[-1]/節[-2]”と表記することができる。また、ノード3304はノード3303の下位ノードであり、兄弟ノード中では最後の“段落”要素ノードであるから、その逆順木構造アドレスは“/論文[-1]/章[-1]/節[-2]/段落[-1]”と表記することができる。
【0215】
同様にして、図33右側の構造インデックスの木構造を構成する各メタノードについてその逆順木構造アドレスを求めてみると、メタノード3305の逆順木構造アドレスは“/論文[-1]”となり、ノード3301の逆順木構造アドレスと等しくなる。同様に、メタノード3306の逆順木構造アドレスは“/論文[-1]/章[-1]”となってノード3302の逆順木構造アドレスと等しく、メタノード3307の逆順木構造アドレスは“/論文[-1]/章[-1]/節[-2]”となってノード3303の逆順木構造アドレスと等しくなる。よって、前記ステップ3106において、ノード3301はメタノード3305、ノード3302はメタノード3306、ノード3303はメタノード3307とそれぞれ対応するものと判定される。なお、図33の構造インデックス中にはノード3304と等しい逆順木構造アドレスを持つメタノードはないので、ノード3304と対応すメタノードは逆順構造インデックス中に存在しないものと判定され、前記ステップ3107において新たなメタノードが生成され、該メタノードが構造インデックスに登録されることになる。
【0216】
前記ステップ3107において、あるノードに対応する新たなメタノードを登録する際には、該ノードの上位ノードに対応するメタノードの持つ下位メタノード群の先頭に、該ノードに対応する種別のメタノードを追加する。図33のノード3304に対応するメタノードを登録する場合には、ノード3304の上位ノードであるノード3303に対応するメタノード3307の下位に、要素型“段落”のメタノードが追加され、該メタノードは兄弟メタノード群の先頭に置かれることになる。
【0217】
次に、複数の解析済み文書データを順次重ね合わせることにより逆順構造インデックスを生成していく過程について、図34を用いて説明する。図34において、3401、3403および3405は、それぞれ登録対象文書の解析済み文書データを表わしている。これらの解析済み文書データの構造を既存の逆順構造インデックス上に順次重ね合わせることにより、逆順構造インデックスが形成されていく。
【0218】
まず最初に文書1の解析済み文書データ3401が入力されると、最初の段階では逆順構造インデックスは初期状態(空)であるため、該解析済みデータと等価な木構造が生成されてそのまま逆順構造インデックスに登録され、逆順構造インデックスは3402に示す状態となる。新たに生成されたメタ要素には−E1から−E5までの文脈識別子、新たに生成されたメタ文字列データには−C1から−C3までの文脈識別子が割り当てられる。
【0219】
次に文書2の解析済み文書データ3403が入力されると、既存の逆順構造インデックス(3402)と構造が重複する部分については何も行わず、3402上に対応する部分がなかった部分構造(図中の斜線部分)だけが新たに登録される。新たに生成されたメタ要素には文脈識別子−E6および−E7、新たに生成されたメタ文字列データには文脈識別子−C4が割り当てられる。
【0220】
次に文書3の解析済み文書データ3405が入力されると、既存の逆順構造インデックス(3404)と構造が重複する部分については何も行わず、3404上に対応する部分がなかった部分構造(図中の斜線部分)だけが新たに登録される。新たに生成されたメタ要素には文脈識別子−E8、−E9および−E10、新たに生成されたメタ文字列データには文脈識別子−C5および−C6が割り当てられる。このようにして、3個の文書が登録された段階で、逆順構造インデックスは3406に示す状態となる。
【0221】
図35は、図30におけるステップ306の詳細、すなわち本実施例における構造化全文データ生成プログラム212の処理手順を示すPAD図である。図35に示すとおり、本実施例における構造化全文データ生成プログラム212の処理手順は、図13に示す前記第一の実施例の場合の処理手順とほぼ同一である。ただし、本実施例の場合、図13におけるステップ1305の代わりにステップ3501を行う点が異なっている。
【0222】
ここで、ステップ3501では、解析済み文書データから、現在着目している文字列データノードに対応する文脈識別子および逆順文脈識別子を求め、該文脈識別子および該逆順文脈識別子を構造化全文データ格納領域219に出力する。
【0223】
図36に、本実施例において構造化全文データ生成プログラム212が出力する構造化全文データのファイル形式を示す。図36は、図5に示したSGML文書を入力として構造化全文データを生成した場合について例示している。図36に示すとおり、本実施例における構造化全文データのデータファイルは、先頭に文書識別子を記述し、その後ろに、文脈識別子、逆順文脈識別子およびそれらに対応する内容文字列からなる三つ組みを、文書中に存在する文字列データの数だけ繰り返した構造をとる。
【0224】
本実施例における文字列インデックスは、前記第一の実施例の場合と同じく、図15に示す処理手順に従って作成される。図37に、本実施例における文字列インデックスのデータ構造を示す。図37は、文字列インデックス作成プログラム213を用いて図36に示す構造化全文データを処理し、文字列インデックスに該構造化全文データに含まれる部分文字列群の登録を終えた段階において、該文字列インデックスのデータ構造の一部(内容文字列“変換処理の一例”に関連する部分)を図示したものである。
【0225】
図37に示すとおり、本実施例における文字列インデックスでは、個々の構造化文字位置情報中に、前記第一の実施例の場合に保持する情報に加えて、逆順文脈識別子をも保持する。ただし、図37では、前記第一の実施例における図16と同様、前記内容文字列の末尾“例”に対応する文字ノードおよび構造化文字位置情報は省略している。また、前記内容文字列の直前に位置する文字の文字位置を“X”として、相対的に文字位置を表現している。
【0226】
以上が、本実施例における文書登録サブシステム101の説明である。
【0227】
以下、本発明の第二の実施例における文書検索サーバ、すなわち図1の102について説明する。
【0228】
図38は、本実施例における文書検索サーバ102の構成を示す図である。図38に示すとおり、本実施例における文書検索サーバ102は、前記第一の実施例の場合の構成要素群に加えて、磁気ディスク装置208中に、逆順構造インデックス格納領域2902を保持する。
【0229】
なお、本実施例の場合も、文書登録サブシステム101および検索クライアントとの間でデータを転送するためにネットワーク105を使用する代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。また、文書登録サブシステム101と文書検索サーバ102を1台のコンピュータ上に実装し、これらの間でデータ転送を行わない構成をとることもできる。また、1個以上の検索クライアントを文書検索サーバ102と同一のコンピュータ上で実行し、これらの間でデータ転送を行わない構成をとることもできる。
【0230】
図39は、本発明の第二の実施例における文書検索処理の概略手順を示すPAD図である。図39に示すとおり、本実施例における文書検索処理の手順は、図18に示す前記第一の実施例の場合とほぼ同一であるが、前記第一の実施例におけるステップ1805の代わりにステップ3901を実行する点が異なっている。ステップ3901では、文書登録サブシステム101から、新規に登録された文書群の内容を反映して更新された構造インデックス、逆順構造インデックスおよび文字列インデックスを受信し、これらをそれぞれ構造インデックス格納領域218、逆順構造インデックス格納領域2902および文字列インデックス格納領域220に格納する。
【0231】
図40は、図39におけるステップ1806の詳細、すなわち本実施例における検索条件解析プログラム1701の処理手順を示すPAD図である。
【0232】
本実施例の場合、検索条件解析プログラム1701は、文書検索リクエスト中で指定されている検索条件を入力として起動されると、まずステップ4001において、該検索条件中に含まれている構造条件について判定する。ここで、該検索条件中に正順の(すなわち前記第一の実施例におけるものと同様な)構造条件が含まれている場合には、ステップ1902およびステップ1903からなる処理に分岐する。ここで、ステップ1902および1903での処理は、前記第一の実施例の場合と同一である。該検索条件中に逆順の構造条件が含まれている場合には、ステップ4002およびステップ4003からなる処理に分岐する。該検索条件中に構造条件が含まれていなかった場合には何もせずにステップ1904に進む。
【0233】
ステップ4002では、逆順構造インデックス格納領域2902から逆順構造インデックスを読み込む。次に、ステップ4003では、該逆順構造インデックスを参照して、前記構造条件を満たす構造内に含まれるすべての文字列データの逆順文脈識別子の集合を求める。以下、該集合を逆順文脈識別子集合と呼ぶ。
【0234】
ステップ1904およびそこから分岐するステップ1905およびステップ1906における処理は、前記第一の実施例の場合と同一であり、これらの処理を終了した後、ステップ4004に進む。
【0235】
ステップ4004では、ステップ1903で求めた文脈識別子集合、前記ステップ4003で求めた逆順文脈識別子集合、前記検索条件中に含まれていた指定文字列、および前記ステップ1905またはステップ1096で生成した部分文字列リストから構成される展開済み部分文字列データを生成して処理を終了する。
【0236】
ここで、図41は、本実施例での検索条件解析プログラム1701の処理過程における、展開済み解析条件データの生成例を示す図である。
【0237】
図41において、4101は、文書検索リクエスト中で指定された検索条件の一例である。検索条件4101は、構造条件指定“章/段落[-1]”と、文字列条件指定“ガード”とから構成されている。前記検索条件は、“章”要素の直接の下位にある最後の“段落”要素内に、文字列“ガード”が出現するケースを検索すべきことを指定している。
【0238】
ここで、前記検索条件中で指定されている構造条件は、構造を後ろ側からに辿って条件を指定する逆順の構造条件であるから、逆順構造インデックスの内容が4102に示すとおりであったとすると、前記ステップ4003においてこの構造インデックスを参照することにより、前記構造条件指定を満たす“段落”要素の逆順文脈識別子は−E3および−E12であることがわかる。従って、これらの段落の下位にある文字列データ、すなわち逆順文脈識別子が−C1または−C7である文字列データ内に、文字列“ガード”が出現するケースを検索すればよいことがわかる。ただし、検索に用いる文字列インデックスには、長さ2の部分文字列についてのみその出現位置が登録されているので、3文字からなる前記指定文字列を直接検索することはできない。そこで、ステップ1905において、前記指定文字列を分解して長さ2の部分文字列からなるリストを生成する。前記のとおり指定文字列が“ガード”だった場合、抽出される部分文字列は“ガー”および“ード”となる。
【0239】
この結果、前記ステップ4004において、4103に示す展開済み検索条件データ、すなわち文脈識別子集合が空集合、逆順文脈識別子集合が{−C1,−C7}、指定文字列が“ガード”、部分文字列リストが{“ガー”,“ード”}であるデータが生成される。
【0240】
図42は、図39におけるステップ1807の詳細、すなわち本実施例における文字列インデックス検索プログラム1702の処理手順を示すPAD図である。
【0241】
文字列インデックス検索プログラム1702は、前記検索条件解析プログラム1701が生成した展開済み検索条件データを入力として起動される。図42に示すとおり、本プログラムの処理手順は図21に示す第一の実施例の場合の処理手順とほぼ同様であるが、前記図21におけるステップ2104、ステップ2105およびステップ2107に代わって、それぞれステップ4201、ステップ4202およびステップ4203が実行される。
【0242】
ステップ4201では、文字列インデックス中で前記展開済み検索条件データ中における指定文字列を検索し、該文字列に対応している構造化文字位置の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子、または前記展開済み検索条件データ中の逆順文脈識別子集合に含まれているいずれかの逆順文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【0243】
ステップ4202では、文字列インデックス中で前記指定文字列を検索し、該文字列の末尾に対応する文字ノードより前方に存在するすべての構造化文字位置情報の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子、または前記展開済み検索条件データ中の逆順文脈識別子集合に含まれているいずれかの逆順文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群からなるヒット位置集合を生成する。
【0244】
ステップ4203では、前記展開済み検索条件データ中における部分文字列リスト中に含まれている部分文字列群のうち、ステップ2106の繰り返し中で現在着目している部分文字列を文字列インデックス中で検索し、該文字列に対応している構造化文字位置情報の集合を求め、次に該集合の中から、前記展開済み検索条件データ中の文脈識別子集合に含まれているいずれかの文脈識別子、または前記展開済み検索条件データ中の逆順文脈識別子集合に含まれているいずれかの逆順文脈識別子を持つ構造化文字位置情報群のみを抽出し、該抽出した構造化文字位置情報群を前記部分文字列に対応付けて記憶する。
【0245】
図42におけるステップ2108、すなわち文字列インデックス検索プログラム1702の処理過程における連接判定処理は、図22に示す前記第一の実施例の場合と同様となる。ただし、検索条件中の構造条件が逆順の構造条件だった場合には、連接判定の際、文脈識別子の一致ではなく逆順文脈識別子の一致を判定することになる。
【0246】
以上説明したように、本実施例に示した構成によれば、前記第一の実施例において検索が可能となる各種構造条件に加えて、「論文中で最後の章の中で、ある特定の文字列を検索する」、あるいは「後ろから2番目の参考文献の中で、ある特定の文字列を検索する」のように、文書の論理構造を逆順に(後ろから)辿った構造条件を指定した検索も可能となる。
【0247】
以上が、本発明の第二の実施例の説明である。
【0248】
(第三の実施例)
以下、本発明を適用した第三の実施例について、図面を用いて説明する。
【0249】
本実施例は、システムの構成および各プログラムの処理手順のいずれについても前記第一の実施例と同一であるが、文書木構造中のノードと構造インデックス中のメタノードとの対応のさせ方が異なり、その結果、同一の文書群を入力とした場合でも構造インデックスの構造および文脈インデックスの割り当てが前記第一の実施例とは異なってくる。
【0250】
ここで、本実施例における、文書木構造中のノードと構造インデックス中のメタノードとの対応関係を、図43を用いて説明する。図43は、図の左側に示す解析済み文書データの木構造を構成するノード群と、右側に示す構造インデックスの木構造を構成するノード(メタノード)群との対応関係を示している。
【0251】
本実施例においても、解析済み文書の木構造中におけるあるノードの木構造アドレスと、構造インデックスの木構造中におけるあるメタノードの木構造アドレスとが等しい場合に、該ノードと該メタノードとは対応するものと定義する。ただし、本実施例では、前記第一の実施例とは異なり、共通の上位ノードを持つ同種の兄弟ノード間での出現順位を考える際に、先頭のノードと2番目のノードとの区別は行うが、2番目のノードとそれ以降に現れたノードとの区別は行わない。すなわち、木構造アドレス中で出現順位を表わす番号は常に[1]または[2]のいずれかをとり、[3]以上の値をとることはない。
【0252】
例えば、図43に示す解析済み文書データ中のノード群のうち、ノード4301は上位ノードをもたず、兄弟ノード中では最初の“論文”要素ノードであるから、その木構造アドレスは“/論文[1]”と表記することができる。同様に、ノード4302はノード4301の下位ノードであり、兄弟ノード中では最初の“章”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]”となる。これに対して、ノード4303はノード4302の下位ノードであり、兄弟ノード中では4番目の“節”要素ノードであるが、前記規則から、その木構造アドレスは“/論文[1]/章[1]/節[2]”となる。また、ノード4304はノード4303の下位ノードであり、兄弟ノード中では2番目の“段落”要素ノードであるから、その木構造アドレスは“/論文[1]/章[1]/節[2]/段落[2]”となる。
【0253】
同様にして、図43右側の構造インデックスの木構造を構成する各メタノードについてその木構造アドレスを求めてみると、メタノード4305の木構造アドレスは“/論文[1]”となり、ノード4301の木構造アドレスと等しくなる。同様に、メタノード4306の木構造アドレスは“/論文[1]/章[1]”となってノード4302の木構造アドレスと等しく、メタノード4307の木構造アドレスは“/論文[1]/章[1]/節[2]”となってノード4303の木構造アドレスと等しくなる。よって、ノード4301はメタノード4305、ノード4302はメタノード4306、ノード4303はメタノード4307とそれぞれ対応するものと判定される。なお、図43の構造インデックス中にはノード4304と等しい木構造アドレスを持つメタノードはないので、ノード4304と対応するメタノードは構造インデックス中に存在しないものとみなされる。
【0254】
以上説明したように、上記規則の結果、本実施例において形成される構造インデックスでは、同一のメタノードの下位に、同種のメタノードが3個以上付加されることはなく、文書木構造中で同種のノードが3個以上連続している場合、2番目以降のノードには同一の文脈識別子が割り当てられる。よって、本実施例による文書検索方法では、構造条件中で任意の出現順位を指定することはできず、同種要素中で先頭の要素か、2番目以降の要素かを区別できるだけとなる。その代わり、本実施例では構造インデックスのデータ構造が前記第一の実施例の場合と比べて簡略になり、構造インデックス格納領域218として必要となる容量を削減することができる。
【0255】
なお、本実施例におけるノードとメタノードとの対応付けを採用した場合においても、前記第二の実施例同様に正順・逆順二つの構造インデックスを用意することにより、出現順を後ろから辿った構造指定をも可能とすることができる。
【0256】
以上が、本発明の第三の実施例の説明である。
【0257】
(第四の実施例)
以下、本発明を適用した第四の実施例について、図面を用いて説明する。
【0258】
図44は、本実施例における文書登録サブシステム101の構成を示す図である。
【0259】
図44に示す文書登録サブシステム101は、そのハードウェア構成および磁気ディスク208中の格納領域の構成に関しては、図2に示す第一の実施例の場合と変わらない。ただし、主メモリ207中には、第一の実施例において保持するプログラム群に加えて、文書構造正規化プログラム4401を保持する。
【0260】
本実施例において、文書登録制御プログラム214は、文書構造解析プログラム210、文書構造正規化プログラム4401、構造インデックス作成プログラム211、構造化全文データ生成プログラム212および文字列インデックス作成プログラム213の起動および実行制御を行うとともに、これらのプログラムによって生成された解析済み文書データ、構造インデックスおよび文字列インデックスをネットワーク105を介して文書検索サーバ102に転送する。
【0261】
なお、本実施例ではフロッピーディスク205に格納された登録対象文書を入力として読み込む構成としたが、光磁気ディスク、追記型光ディスク等、他種の可搬型媒体から読み込む構成をとることもでき、ネットワーク105を介して転送されてくる文書を入力とする構成をとることもできる。さらに、本実施例では生成された解析済み文書データ、構造インデックスおよび文字列インデックスを文書検索サーバ102に転送するためにネットワーク105を使用するものとしたが、代わりにフロッピーディスク、光磁気ディスク、追記型光ディスク等の可搬型媒体を使用する構成をとることもできる。あるいは、文書登録サブシステム101と文書検索サーバ102を1台のコンピュータ上に実装し、データ転送を行わない構成をとることもできる。
【0262】
図45は、本発明の第四の実施例における文書登録処理の概略手順を示すPAD図である。本図に示す処理手順は、図3に示す第一の実施例における処理手順とほぼ同様であるが、ステップ304の直後にステップ4501が追加されている点が異なる。
【0263】
ここで、ステップ4501では、ステップ304で生成した解析済み文書データを入力として文書構造正規化プログラム4401を実行する。文書構造正規化プログラム4401は、解析済み文書データの中から、検索対象としては不適切な構造および内容文字列を抽出してこれらを削除する。
【0264】
図46に、文書構造正規化プログラム4401の処理手順を示す。本プログラムは、起動されるとまずステップ4601において、正規化パラメタの指定の有無を確認する。正規化パラメタが指定されている場合にはステップ4602からステップ4608までに示す処理を実行し、正規化パラメタが指定されていない場合には何もせずに処理を終了する。
【0265】
ここで、正規化パラメタとは、接続対象要素および削除対象要素の要素型名を指定するパラメタのことである。ここで言う接続対象要素とは、例えば文章の一部を強調表示するために用いられる非構造的な要素であって、検索時にはその要素の境界をまたいで文字列を検出する必要があるもののことである。また、削除対象要素とは、その内部に本来の文書内容とは異なる種類のデータを保持しており、検索時にはその内容を無視して文字列の検出を行うべきもののことである。削除対象要素の例としては、例えばテキスト中に参照先の文献へのリンクデータを埋め込むために用いられる要素などがある。
【0266】
ステップ4602では、指定されている正規化パラメタを読み込む。ここで、正規化パラメタは、ユーザがキーボード202から入力するか、または予め特定のファイルに書き込んでおくなどして指定する。接続対象要素および削除対象要素の要素型名は、それぞれ複数個指定してもよく、あるいは省略してもよい。次に、ステップ4603では、解析済み文書データを解析済み文書データ格納領域217から読み込む。
【0267】
次に、ステップ4604では、解析済み文書データの木構造を順次たどりつつ、すべての要素ノードについて、ステップ4605からステップ4607までに示す処理を繰り返す。そして、すべての要素ノードについて該処理を終了した後、ステップ4608に進む。
【0268】
ステップ4605では、現在着目している要素ノードについて、正規化パラメタが何を指定しているかを判定する。該着目要素の要素型名が接続対象として指定されている場合にはステップ4606に進み、該要素ノードを削除するとともに、該要素の内部に含まれるすべての文字列データを、該要素の前後にある文字列データに接続する。また、該着目要素の要素型名が削除対象として指定されている場合にはステップ4607に進み、該要素ノードおよびその下位にあるすべてのノードを削除する。
【0269】
前記のごとくステップ4605以下の処理を行った後、ステップ4608に進み、正規化対象要素群を処理して更新された解析済み文書データを、解析済み文書データ格納領域217に再び格納する。
【0270】
図47は、正規化処理の具体的な例を示す図である。
【0271】
図47において、4701は正規化パラメタの一例を示しており、ここでは接続対象要素の要素型名として“bold”と“italic”の二つ、削除対象要素の要素型名として“link”と“index”の二つが指定されている。この場合、解析済み文書データ中に4702に示すような構造を持つ部分があると、要素“bold”に対して前記ステップ4606に示す接続処理が行われ、その結果は4703に示す構造となる。また、解析済み文書データ中に4704に示すような構造を持つ部分があると、要素“link”に対して前記ステップ4607に示す削除処理が行われ、その結果は4705に示す構造となる。
【0272】
以上説明したように、本実施例では、解析済み文書データに対して前記正規化処理を行った後に構造インデックスへの登録以下の処理が行われるので、登録対象文書中に含まれていた非構造的な要素に妨げられることなくテキストの検索を行うことができる。
【0273】
なお、本実施例における正規化処理を採用した場合においても、前記第二の実施例同様に正順・逆順二つの構造インデックスを用意することにより、出現順を後ろから辿った構造指定も可能とすることができる。
【0274】
以上が、本発明の第四の実施例の説明である。
【0275】
(第五の実施例)
本発明を利用した第五の実施例について、図面を用いて説明する。
【0276】
図48は、本実施例における文書登録サブシステム101の構成を示す図である。
【0277】
本システム構成は、そのハードウエア構成においては、図2に示す第一の実施例の文書登録サブシステム101と変わらない。ただし、主メモリ207に格納される文書登録プログラムの1つである、構造インデクス作成プログラム211を、メタ構造インデクス作成プログラム4801に変更している。さらに、磁気ディスク装置208には、構造インデクス格納領域218の代わりにメタ構造インデクス格納領域4802を作成し、種別定義テーブル格納領域4803を追加する。
【0278】
メタ構造インデクス作成プログラム4801は、文書構造解析プログラム210の出力結果である解析済み文書データ217を入力として、様々な構造を持つ登録文書の全ての文書構造を一括管理するメタ構造インデクスを出力する。
【0279】
図49にメタ構造インデクスの例を示す。本図は、"論文"という種別の最上位構造を持つ構造インデクス1(4901)と"報告書"という種別の最上位構造を持つ構造インデクス2(4902)をルートメタノード4903によって1つの木構造にまとめたものである。この木構造をメタ構造インデクス4904と呼ぶ。
【0280】
つまり、構造インデクスは、最上位構造の種別が一致する登録文書の構造との重ね合わせにより作成していくため、最上位構造の種別が同じ登録文書群毎に作成することになる。メタ構造インデクスとは、これらの異なる最上位構造を持つ全ての構造インデクスの最上位構造を、1つのルートメタノードに接続することで、1つのインデクスにまとめたものである。
【0281】
ルートメタノードとは、複数の構造インデクスの最上位構造をまとめる仮の上位構造である。つまり、ルートメタノードから、複数の構造インデクスを辿るために存在しており、ルートメタノードに対応する構造が登録文書に存在するわけではない。
【0282】
ルートメタノードは、構造インデクスの要素メタノードと同じく、下位要素である複数の構造インデクスの最上位構造の数および各構造インデクスへのリンクの情報を持つ。
【0283】
上記のメタ構造インデクスを格納するのが、メタ構造インデクス格納領域4802である。
【0284】
次に、種別定義テーブル4803について説明する。
【0285】
種別定義テーブルは、構造化文書の各構造に付けられた要素型名とその意味を表わす種別との対応を定義したテーブルである。ユーザがキーボード202からテキストエディタを利用して作成するなどの方法で、あらかじめ磁気ディスク装置208に格納しておく。
【0286】
図50は種別定義テーブル4803の内容を示す図である。種別とは、例えば"論文"、"PAPER"のように、名称が違っていても同じ意味を持つ要素型名を代表する名称である。種別定義テーブルは、複数の要素型名に付けられた種別を管理しており、本テーブルにおいて同じ種別が定義されている要素型名を持つ構造は、同じ種別であると判断する。
【0287】
本図に示したように、種別定義テーブルには、種別5001と要素型名数5002と要素型名5003の3つの情報を格納する。種別5001が、複数の要素型名に共通に付けられる種別である。要素型名数5002は、各種別に対応する要素型名の数である。さらに、要素型名5003には、要素型名数に記載された数の要素型名を列挙する。
【0288】
本テーブルを参照することにより、要素型名から種別の情報を得ることができる。また、逆に、種別から要素型名を得ることができる。さらに、本テーブルに記載されない要素型名は、その要素型名をそのまま種別とする。
【0289】
本実施例において、種別定義テーブル4803に記載される種別と要素型名は、1対多の対応を満たす。つまり、"書誌"という要素型名は一意に1つの種別を持つ。これは、種別定義テーブルをメタ構造インデクスごとに作成しており、メタ構造インデクスの各メタノードは、種別および出現位置により区別されるためである。要素型名によって一意に種別が決まらなければ、構造インデクスの作成において、要素型名から得られる複数の種別のうちいずれを用いるかが決まらないためである。
【0290】
図51は、本実施例における文書登録処理の概略手順を示すPAD図である。本図は、図3に示す第一の実施例の登録処理の概略手順とほぼ同じであるが、図3におけるステップ305の代わりにステップ5101を実行する点と、ステップ308の代わりにステップ5102を実行する点が異なる。
【0291】
ステップ5101では、メタ構造インデクス作成プログラム4801を呼び出す。メタ構造インデクス作成プログラム4801では、登録済みのメタ構造インデクスをメタ構造インデクス格納領域4802から読み出し、ステップ304で得られた解析済み文書データの持つ構造情報を、このメタ構造インデクスに登録し、更新されたメタ構造インデクスをメタ構造インデクス格納領域4802に格納する。
【0292】
ステップ5102では、登録文書全ての解析済み文書データ217および更新されたメタ構造インデクス4804、文字列インデクス220を文書検索サーバ102に転送する。
【0293】
図52は、ステップ5101でメタ構造インデクスを作成する処理の詳細内容を示すPAD図である。本処理は、図9に示した第一の実施例における構造インデクス作成プログラムの処理とほぼ同じ内容であるが、登録先をメタ構造インデクスに変更していることから、以下の点で図9と異なる。
【0294】
まず、ステップ904の解析済み文書データ読み込み処理を実行する。
【0295】
次に、ステップ901の代わりにステップ5201を実行する。ステップ901は、構造インデクスそのものの有無を判定しているが、ステップ5201では、構造インデクスは1つのメタ構造インデクスの一部であり、最上位構造の種別毎に作成することから、メタ構造インデクス中に、登録文書の最上位構造と一致する構造インデクスが存在するか否かをチェックする処理に変更する。
【0296】
ステップ904をステップ5201の前に実行するのは、本処理において、登録文書の最上位構造の情報が必要なためである。ここで、最上位構造の種別が一致する構造インデクスが存在しない場合は、新しく初期構造インデクスを生成するステップ902の処理を実行し、存在する場合は、該構造インデクスを読み込むステップ903の処理を実行する。また、本ステップにおいて、種別の比較をする前に、種別定義テーブル4803を参照し、登録文書の最上位構造の要素型名を種別に変換してから比較を行う。
【0297】
さらに、ステップ906の代わりにステップ5202を実行する。ステップ5202では、種別定義テーブル4803を参照して、解析済み文書データの識別子名を種別に変換してから、図11を用いて前述したステップ906の処理内容と同じ手順で、構造インデクス中の対応するメタノードの有無のチェックを行う。
【0298】
さらに、ステップ908の代わりにステップ5203を実行する。ステップ5203では、文脈識別子を割り当てる際に、メタ構造インデクス全体で一意にメタノードを識別できる文脈識別子を与える。したがって、構造化全文データ作成プログラム212において、各構造のテキスト列に与えられる文脈識別子は、メタ構造インデクス中のメタノードを一意に決定するものである。ステップ908の処理に加えて、構造インデクスの識別情報を文脈識別子に加えるなどの方法により、実現可能である。
【0299】
さらに、ステップ905による繰り返し処理の後に、ステップ5204を実行する。
【0300】
ステップ5204では、ステップ902で構造インデクスを新規に作成した場合に、メタ構造インデクスのルートメタノードに新規に作成した構造インデクスの最上位のメタノードを接続し、メタ構造インデクスに新規に作成した構造インデクスを組み込む処理を行う。
【0301】
さらに、ステップ911の代わりにステップ5205を実行する。ステップ5205では、作成したメタ構造インデクスをメタ構造インデクス格納領域4802に格納する。
【0302】
その他のステップの処理は、図9を用いて前述した内容と同じである。
【0303】
図53、図54は、上記のステップ5101で作成するメタ構造インデクスの例である。図53は、最上位構造の種別が一致する構造インデクスが存在する場合の例を示している。また、図54は、最上位構造の種別が一致する構造インデクスが存在しない場合の例を示している。
【0304】
図53では、まずメタ構造インデクス5301に存在する構造インデクス5302と登録文書の構造解析結果の木構造5303との比較を行う。この例では登録文書の最上位構造である"文書"と一致する種別の最上位構造を持つ構造インデクス5302が存在するため、この構造インデクス5302に対して、登録文書の木構造5303の重ね合わせを行う。この場合、"日付"のノード5304が構造インデクス5302に存在しないため、構造インデクス5302に、"日付"のノードを追加して、更新された構造インデクス5305を作成する。構造インデクスの更新に伴い、メタ構造インデクス5301も更新される(5306)。
【0305】
図54では、まずメタ構造インデクス5401に存在する構造インデクス5402と登録文書の構造解析結果の木構造5403との比較を行う。この例ではメタ構造インデクス中の構造インデクスの最上位構造は、"論文"(5404)しかなく、登録文書の最上位構造である"報告書"(5405)と一致する最上位構造を持つ構造インデクスは存在しない。このため、登録文書の木構造と同じ構造を持つ、構造インデクス5406を新規に作成する。さらに、作成した構造インデクス5406を、ルートメタノード5407に接続することで、メタ構造インデクスに構造インデクス5406を追加する。構造インデクスの追加に伴い、メタ構造インデクス5401も更新される(5408)。
【0306】
上記のように、最上位構造が一致する構造インデクスが存在する場合は、この構造インデクスに対する重ね合わせを行い、存在しない場合は、新たに構造インデクスを作成した上で、ルートメタノードに接続することで、メタ構造インデクスを更新する。
【0307】
本実施例の文書登録サブシステム101が、第一の実施例の文書登録サブシステムと異なる点は以上であり、その他の構成および処理内容は全て同じである。
【0308】
次に、本発明の第五の実施例における文書検索サーバ、すなわち図1の102について説明する。
【0309】
図55は、本実施例における文書検索サーバ102の構成を示す図である。
【0310】
本システム構成は、そのハードウエア構成においては、図17に示す第一の実施例の文書検索サーバ102の構成と変わらない。
【0311】
ただし、主メモリ207に格納される文書検索処理プログラムのうち検索条件解析プログラム1701をメタ構造インデクス対応検索条件解析プログラム5501に変更し、さらに構造インデクス格納領域218の代わりにメタ構造インデクス格納領域4802を作成し、磁気ディスク装置208に種別定義テーブル格納領域4803を追加する点が異なる。
【0312】
メタ構造インデクス対応検索条件解析プログラム5501は、検索クライアント103および104から受信した検索リクエスト中に含まれる検索条件式を解析し、文字列インデクス検索プログラム1702によって直接検索可能な条件指定に翻訳する。ここで、検索条件解析プログラム1701が、構造インデクスを利用して、検索条件式を解析するのと違い、メタ構造インデクス対応検索条件解析プログラム5501では、メタ構造インデクスおよび種別定義テーブルを利用して検索条件式を解析する。
【0313】
また、メタ構造インデクス格納領域4802には、本実施例において前述した、文書登録サブシステム101で作成したメタ構造インデクスを格納する。種別定義テーブル4803は、ユーザによって文書登録サブシステム101に登録された種別定義テーブルと同じ内容である。
【0314】
図56は、本実施例における検索サーバの処理の概略手順を示すPAD図である。本図は、図18に示す第一の実施例の検索サーバの処理の概略手順とほぼ同じである。ただし、図18におけるステップ1805の代わりにステップ5601を実行する点と、ステップ1806の代わりにステップ5602を実行する点が異なる。
【0315】
ステップ5601では、文書登録サブシステム101から、メタ構造インデクスおよび文字列インデクスを受信し、これらをそれぞれメタ構造インデクス格納領域4802および文字列インデクス格納領域220に格納する。これらのメタ構造インデクスおよび文字列インデクスは、ステップ1804で追加登録した、新規に登録された文書群の内容を反映して更新したものである。
【0316】
ステップ5602では、メタ構造インデクス対応検索条件解析プログラム5501を実行し、文書検索リクエスト中で指定されている検索条件を解析し、該検索条件を、文字列インデックス検索プログラム1702によって直接処理可能な条件指定(以下、これを展開済み検索条件データと呼ぶ)に変換する。
【0317】
その他のステップの処理は、第一の実施例において、図18を用いて前述した内容と同じである。
【0318】
図57は、図56におけるステップ5602の詳細、すなわち本実施例におけるメタ構造インデクス対応検索条件解析プログラム5501の処理手順を示すPAD図である。本図は、図19に示す第一の実施例の検索条件解析プログラム1701の処理手順を示すPAD図とほぼ同じである。図19におけるステップ1902の代わりにステップ5701を実行する点と、ステップ1903の代わりにステップ5702を実行する点が異なる。
【0319】
ステップ5701では、メタ構造インデックス格納領域4802からメタ構造インデックスを読み込む。
【0320】
次に、ステップ5702では、メタ構造インデックスを参照して、前記構造条件を満たす構造内に含まれるすべての文字列データの文脈識別子集合を求める。ここで検索条件で指定された構造条件が、構造の種別により指定される場合は、そのまま、メタ構造インデクスを辿ることで、構造条件を満たす構造内に含まれる文字列データの文脈識別子を得ることができる。要素型名で指定される場合は、種別定義テーブル4803を参照して種別に変換してから、メタ構造インデクスを辿って、構造条件を満たす構造内に含まれる文字列データの文脈識別子を得る。
【0321】
メタ構造インデクスの最上位構造は、各文書の最上位構造を接続したルートメタノードであるため、対応する構造条件は存在しない。
【0322】
その他のステップは、第一の実施例において、図19を用いて前述した内容と同じである。
【0323】
図58は、メタ構造インデクス対応検索条件解析プログラム5501の処理過程における、展開済み解析条件データの生成例を示す図である。
【0324】
図58において、5801は、文書検索リクエスト中で指定された検索条件の一例である。検索条件5801は、構造条件指定“論文/書誌/タイトル”と、文字列条件指定“ガード”とから構成されている。前記検索条件は、“論文”要素の直接の下位にある“書誌”要素の直接の下位にある“タイトル”要素内に、文字列“ガード”が出現するケースを検索すべきことを指定している。
【0325】
ここでは、構造条件に種別を指定した場合について説明する。要素型名を指定した場合は、種別定義テーブル4803を参照して、種別に変換した後に以下の処理を行なう。
【0326】
さらに、構造条件に要素型名、種別を混在して指定するために、種別の場合は構造条件の前に"Type:"などの識別情報を付加する。このため、検索クライアント103、104において、第一の実施例で図27を用いて説明したステップ2702およびステップ2703で、ユーザ指示および文書検索リクエストに上記の識別情報を追加する。ただし、本設定を行なっても、メタ構造インデクスには種別の情報しか持たないため、要素型名による構造条件でメタ構造インデクスから構造条件を満たす構造内に含まれる文字列データの文脈識別子が得られるわけではない。
【0327】
ここで、メタ構造インデックスの内容が5802に示すとおりであったとすると、前記ステップ5702において、この構造インデックスを参照することにより、前記構造条件指定を満たす“タイトル”要素の文脈識別子はE3であることがわかる。従って、この段落の下位にある文字列データ、すなわち文脈識別子がC1である文字列データ内に、文字列“ガード”が出現するケースを検索すればよいことがわかる。ただし、検索に用いる文字列インデックスには、長さ2の部分文字列についてのみ、その出現位置が登録されているので、3文字からなる前記指定文字列を直接検索することはできない。そこで、ステップ1905において、前記指定文字列を分解して長さ2の部分文字列からなるリストを生成する。前記のとおり指定文字列が“ガード”だった場合、抽出される部分文字列は“ガー”および“ード”となる。
【0328】
この結果、前記ステップ1907において、5803に示す展開済み検索条件データ、すなわち文脈識別子集合が{C1}、指定文字列が“ガード”、部分文字列リストが{“ガー”,“ード”}であるデータが生成される。
【0329】
以上説明したように、本実施例に示した構成によると、複数の構造を持つ文書の検索を一括して行なうことができる。また、検索条件において、種別および要素型名を指定した構造条件が可能となる。
【0330】
以上が、本発明を利用した第五の実施例の説明である。
【0331】
(第六の実施例)
次に、本発明を利用した第六の実施例を図面を利用して説明する。
【0332】
第六の実施例において第五の実施例と異なる点は、文書登録の処理では、種別定義テーブルを利用せず、要素型名をそのまま構造の種別としてメタ構造インデクスを作成し、検索処理の際に、種別を用いた構造条件を含む構造指定検索条件を、要素型名を指定した構造条件に変換した上で、検索処理を実施する点である。これにより、種別による構造条件と要素型名による構造条件のいずれも指定可能である。
【0333】
本実施例における文書登録サブシステム101のシステム構成は、図48に示す第五の実施例の文書登録サブシステム101のシステム構成と同じである。
【0334】
ただし、第五の実施例で図48に示したメタ構造インデクス作成プログラム4801のうち、図52を用いて説明した、ステップ5201とステップ5202の処理内容を一部変更する。すなわち、ステップ5201とステップ5202において、種別定義テーブル4803を参照して要素型名から種別への変換を行う処理は実行せず、要素型名をそのまま種別とみなして、構造インデクスへの登録処理を行う。ただし、種別定義テーブル4803を作成し、検索サーバへ転送する処理は変わらない。
【0335】
以上が、第六の実施例における文書登録サブシステム101の、第五の実施例における文書登録サブシステムからの変更点である。その他の構成、処理内容は全て同じである。
【0336】
本実施例における文書検索サーバ102のシステム構成も図55と同じである。
【0337】
ただし、第五の実施例で図55に示したメタ構造インデクス作成プログラム5501のうち、図57を用いて説明したステップ5702の処理が一部変更される。
【0338】
つまり、ステップ5702において、検索条件で指定された構造条件が、構造の種別により指定されていれば、種別定義テーブル4803を参照して、該種別に対応する全ての要素型名を取得し、得られた要素型名のORにより作成した構造条件に変更する。メタ構造インデクスを辿ることで、作成した構造条件を満たす構造内に含まれる文字列データの文脈識別子を得ることができる。要素型名で指定された場合は、そのまま、メタ構造インデクスを辿って、構造条件を満たす構造内に含まれる文字列データの文脈識別子を得る。
【0339】
図59に、本実施例のステップ5702において、種別による構造条件が指定された場合に要素型名に変更して生成する構造条件を示す。本図に示すように、構造条件を構成する種別ごとに、要素型名を取得し、構造条件の各階層を1つあるいは複数の要素型名の論理和(以下OR)で記述する構造条件を生成する。複数の要素型名のORは、構造条件に「{種別または要素型名 , 種別または要素型名 ,… }」のように"{ }"内にで複数の種別または要素型名を列挙するなどの方法により指定する。
【0340】
ユーザが検索条件を種別を指定する際には、種別名の前に"Type:"などの識別情報を記載することで、その名称を種別として、要素型名に変更する。何も指定せずに検索条件を記述する場合は、要素型名であると判断し、そのまま、構造条件を利用して、構造インデクスから適合する構造の文脈識別子を取得する。あるいは、同じ名称の要素型名が存在しない種別であれば、曖昧性がないため、"Type:"などの識別指定を省略してもよい。
【0341】
図59では、「Type:属性/Type:題目」という構造条件(5901)を、構造条件の変換処理(5902)により、種別定義テーブル4803を参照して、要素型名を用いた構造条件(5903)に変換する。
【0342】
検索クライアント103、104の変更点は、第五の実施例で図58を用いて説明した通りである。ただし、本実施例では、要素型名を指定した構造条件は、要素型名が一致する構造内の文字列データの文脈識別子が取得でき、種別を指定した構造条件は、種別が一致する構造内の文字列データの文脈識別子が取得できる。
【0343】
以上の処理により、本実施例では、検索条件に種別による構造条件と要素型名による構造条件を組み込むことが可能となる。
【0344】
さらに、本実施例の方法の第五の実施例の方法と比較したメリットは、構造インデクスが、要素型名毎にメタノードが作成されるため、種別の変更が任意に可能であるということである。例えば、クライアント毎に種別定義テーブルを作成して検索サーバに転送した後に、種別定義テーブルを指定した検索条件を設定するなどの処理方法も可能であり、柔軟な種別の設定が実現できる。第五の実施例では、種別定義テーブルの変更に対応するためには、変更時点までに作成した、メタ構造インデクス、文字列インデクスの再作成が必要となる。
【0345】
また、本実施例の方法のデメリットとしては、第五の実施例に比べて、生成されるメタ構造インデクスが大きくなることがある。メタ構造インデクスにおいて、種別ごとにメタノードを作成する方が、要素型名ごとに作成する場合に比べて、メタノード数を削減できるためである。
【0346】
以上が、本発明を利用した第六の実施例の説明である。
【0347】
(第七の実施例)
次に第七の実施例として、異なる文書構造を持つ文書群を、メタ構造インデクスを使わずに1つの構造インデクスを利用して構造指定検索するためのシステム構成および処理手順を説明する。
【0348】
図60は、本実施例における文書登録サブシステム101のシステム構成である。本システム構成は、そのハードウエア構成においては、図2に示す第一の実施例の文書登録サブシステム101と変わらない。ただし、主メモリ207に格納する文書登録プログラムにルートノード付加プログラム6001を追加する。
【0349】
ルートノード付加プログラム6001の処理内容を図61を用いて説明する。ルートノード付加プログラム6001は、文書構造解析プログラム210の出力結果である解析済み文書データ6101を解析済み文書データ格納領域217から読み出し、該解析済み文書データの最上位ノードの上位ノードとして、固定の種別を持つノードを付加した、ルートノード付加解析済み文書データ6102を作成し、解析済み文書データ格納領域217に格納する。これにより、読み出した解析済み文書データ6101をルートノード付加解析済み文書データ6102に置き換える。
【0350】
本実施例の文書登録サブシステム101において、上記の処理以外は、第一の実施例の文書登録サブシステムの構成および処理と全て同じである。
【0351】
図62は、本実施例における文書検索サーバ102のシステム構成である。本システム構成は、そのハードウエア構成においては、図17に示す第一の実施例の文書検索サーバ102と変わらない。ただし、主メモリ207に格納する文書登録プログラムに検索条件修正プログラム6201を追加する。
【0352】
検索条件修正プログラム6201は、構造条件が最上位構造から指定された場合は、文書登録時に登録文書の解析済み文書データの最上位構造に追加したrootを構造条件に追加する処理が加わる。その他の場合は、検索条件を変更することはない。
【0353】
図63は、検索条件修正プログラム6201の処理内容を示すPAD図である。
【0354】
まず、ステップ6301で、検索条件中の構造条件の有無をチェックする。構造条件が存在するなら、ステップ6302に進み、存在しないなら、検索条件を何も変更せず、検索条件修正プログラム6201を終了する。
【0355】
ステップ6302で、構造条件が最上位構造から指定されているか否かをチェックする。最上位構造から指定されている場合は、ステップ6303に進む。最上位構造から指定されていない場合は、検索条件を何も変更せず、検索条件修正プログラム6201を終了する。
【0356】
ステップ6303で、構造条件を変更し、最上位構造のrootを指定した検索条件とする。
【0357】
ステップ6304で、変更した検索条件を出力する。1702以降の処理内容は、図17を用いて前述した第一の実施例の検索サーバ102の処理内容と同じである。
【0358】
図64は、検索条件修正の結果である。本図に示すように構造条件の構造条件に、最上位構造が指定される場合は、rootという構造を追加した構造条件を生成する。
【0359】
上記の処理により検索条件を変更する処理以外は、全て第一の実施例の検索サーバ102の構成および処理内容と同じである。
【0360】
次に、第七の実施例における検索クライアント103、104の処理内容について説明する。
【0361】
本実施例において、検索クライアント103、104のシステム構成は、図25の第一の実施例の検索クライアントのシステム構成と同じである。
【0362】
ただし、検索結果表示プログラム2502の処理手順を示す図28のPAD図のステップ2815において、解析済み文書データを書式化して表示する際に、文書登録サブシステム101において、追加されたルートノードは削除してから書式化して表示する。つまり、登録文書を構造解析した結果である解析済み文書データに変換してから表示するように変更する。これにより、ユーザからは、解析済み文書データに追加されたルートノードの存在は見えないことになる。
【0363】
以上が第七の実施例における、第一の実施例の処理からの変更点である。その他の構成および処理内容は、第一の実施例の構成および処理内容と同じである。
【0364】
以上の処理により、解析済み文書データが登録文書と異なる点を除いて、構造インデクスを利用してメタ構造インデクスを利用した場合と同様に様々な文書構造を持つ文書群に対する一括した構造指定検索が可能となる。
【0365】
(第八の実施例)
次に、複数の構造において同じ種別を持つ構造をまとめて効率的に検索するための別名構造インデクスの作成方法およびこれを用いた検索処理について説明する。
【0366】
図65は、別名構造インデクス6501の構成および別名構造インデクス6501とメタ構造インデクス6502との関係および、別名構造インデクスを作成するために用いる別名定義テーブル6503の内容を示した図である。
【0367】
別名構造インデクスは、必ずしも構造インデクスのように文書全体の構造を辿るためのインデクスを作成するわけではなく、文書構造の部分構造を構造インデクスから切り出し、切り出した部分構造を重ね合わせて作成する。
【0368】
図65に示すように、異なる文書構造の書誌に関する情報を切り出し、メタ構造インデクスを構成するメタノードの文脈識別子を管理することで、検索条件として個々の構造を指定しなくても、1つの別名を指定した構造条件を設定することで、その別名に対応する全てのメタ構造インデクス中のメタノードの文脈識別子を得ることができる。
【0369】
別名定義テーブル6503には、本図で示したように、別名6504と構造定義数6505と構造定義6506が格納される。
【0370】
別名6504は、別名構造インデクスを参照する際の名称が格納される。構造定義数6505には、別名登録された構造定義数を記述する、構造定義6506には、別名6504で代表される検索条件中の構造条件を構造定義数分列挙する。
【0371】
別名構造インデクスは、いくつかの構造定義によって指定される構造インデクス中のメタノードの文脈識別子をあらかじめ取得しておき、構造条件から検索条件を満たす構造に含まれる文字列データの文脈識別子を高速に取得するためのインデクスである。
【0372】
別名構造インデクスの各ノードには、構造インデクスのメタノードと同じように、論理構造をあらわすためのリンク情報とメタノードの文脈識別子を持つ。ただし、メタノードの文脈識別子には、別名として定義された構造に含まれる文字列データのメタノードの文脈識別子をすべて格納する。
【0373】
図66は、本実施例における文書登録サブシステム101のシステム構成を示す図である。
【0374】
本実施例における文書登録サブシステム101のシステム構成は、図48に示す第五の実施例の文書登録サブシステム101のシステム構成とそのハードウェア構成に関しては変わるところはない。
【0375】
ただし、主メモリ207に格納する文書登録プログラムに別名構造インデクス作成プログラム6601を追加し、磁気ディスク208には、別名構造インデクス格納領域6602および別名定義テーブル6603を追加する点が異なる。
【0376】
別名構造インデクス作成プログラム6601は、別名定義テーブル格納領域6603から別名定義テーブルを読み出す。さらに、メタ構造インデクス作成プログラム4801で作成するメタ構造インデクスをメタ構造インデクス格納領域4802から読み出す。読み込んだ情報を元に、別名構造インデクスを作成し、別名構造インデクス格納領域6602に格納する。
【0377】
図67は、本実施例における文書登録サブシステム101の概略処理手順を示すPAD図である。本実施例の処理手順は、図51を用いて前述した、第五の実施例の文書登録サブシステム101の概略処理手順とほぼ同じである。ただし、ステップ5101のあとで、ステップ6701を実行する点と、ステップ5102の代わりにステップ6702を実行する点が異なる。
【0378】
ステップ6701では、別名構造インデクス作成プログラム6601を実行し、文書の登録により更新されたメタ構造インデクスの情報を参照し、別名構造インデクスの内容を更新する。
【0379】
ステップ6702では、全ての解析済み文書データ、メタ構造インデクス、別名構造インデクス、文字列インデクスを文書検索サーバ102に転送する。
【0380】
図68は、図67のステップ6701の詳細手順を示すPAD図である。本図を用いて、別名構造インデクスの作成手順を説明する。
【0381】
まず、ステップ6801で、別名として作成する構造を定義した別名定義テーブル6603を読み出す。別名定義テーブル6603は、ユーザがキーボード202からテキストエディタなどを利用して作成する。あるいは、構造インデクスから、異なる階層に存在する同じ種別の構造を抽出して、この情報を元に別名定義テーブルを作成するプログラムによって作成する。
【0382】
次に、ステップ6802で、上記ステップ6801で読み出した別名定義テーブル6603を用いて、構造インデクス中から、該構造情報に適合するメタノードを抽出する。これは、図57の5702ステップで前述した、第五の実施例における文書検索処理における検索条件に適合するメタ構造インデクスの取得処理と同じ処理で実現できる。
【0383】
ステップ6803では、得られたメタノードの文脈識別子を管理するテーブルを作成し、これを別名構造インデクスに登録する。
【0384】
ステップ6804では、階層構造がある別名について、階層構造を表現するためにノード同士を接続する。別名構造インデクスに登録する別名は、"書誌/題目"のように階層的な別名を指定することが可能である。この場合、まず、構造インデクスから、"書誌"の種別情報を持つメタノードを抽出した上で、その子ノードから"題目"の種別情報を持つメタノードを抽出し、このメタノードの文脈識別子を管理する文脈識別子管理テーブルを作成して、別名構造インデクスに登録する。さらに、この過程で得られる"書誌"の種別情報を持つメタノードについても文脈識別子管理テーブルを作成し、別名構造インデクスの"書誌"に格納することで、階層的な構造を持った、別名構造インデクスを作成する。
【0385】
図69に、本実施例における全文検索サーバ102のシステム構成図を示す。
【0386】
本構成図は、図55を用いて前述した第五の実施例における全文検索サーバ102のシステム構成図とそのハードウェア構成においては同じである。ただし、主メモリ207にメタ構造インデクス対応検索条件解析プログラム5501の代わりに別名構造インデクス対応検索条件解析プログラム6901を格納する点と、磁気ディスク208に別名構造インデクス格納領域を追加する点が異なる。
【0387】
図70は、本実施例における検索処理の概要を示すPAD図である。
【0388】
本図に示した処理は、図56に示した第五の実施例の検索処理とほぼ同じであるが、ステップ5601の代わりにステップ7001を実行する点とステップ5602の代わりにステップ7002を実行する点が異なる。
【0389】
ステップ7001では、メタ構造インデクス、別名構造インデクス、文字列インデクスを文書登録サブシステム101から受信して、それぞれメタ構造インデクス格納領域4802、別名構造インデクス格納領域6602、文字列インデクス格納領域220に格納する。
【0390】
ステップ7002では、別名構造インデクス対応検索条件解析プログラム6901を実行する。
【0391】
図71は、ステップ7002の処理の詳細すなわち、別名構造インデクス対応検索条件解析プログラム6901の処理手順を示すPAD図である。
【0392】
本図の処理は、図57に示す第五の実施例のメタ構造インデクス対応検索条件解析プログラムの処理手順とほぼ同じである。
【0393】
ただし、構造条件の有無を判定するステップ1901の代わりに、構造条件の有無および別名指定か否かを判定するステップ7101を実行する点と、ステップ7101で別名と判定された場合は、ステップ7102、ステップ7103を実行する点が異なる。構造条件が種別もしくは要素型名の場合は、第五の実施例と同じく、ステップ5701とステップ5702を実行する。
【0394】
ステップ7101では、構造指定検索の構造条件として、別名を利用しているか否かを判定する。構造条件で別名を利用する場合は、構造条件の先頭に、例えば"Alias:"という文字列を指定することで区別する。したがって、別名である"題目"を検索対象の構造として指定する場合は、"Alias:題目"と構造条件に記述しているか否かをチェックすることで判定することができる。
【0395】
ステップ7102では、別名構造インデクスを読み込む。次にステップ7103で、別名構造インデクスを参照し、指定された構造条件を満たす文字列データの文脈識別子の集合を求める。別名インデクスに格納された、別名に対応するメタ構造インデクスのメタノードの下位にある文字列データのメタノードの文脈識別子を取得することで実現できる。
【0396】
その他の処理は、図57で示した、第五の実施例のメタ構造インデクス対応検索条件解析プログラムの処理手順と同じである。
【0397】
本実施例における、検索サーバ102の構成および処理内容は、その他の点においては、全て第五の実施例における、全文検索サーバ102の処理と同じである。
【0398】
以上が、本発明を利用した第八の実施例の説明である。
【0399】
(第九の実施例)
次に第九の実施例として、第五の実施例における種別定義テーブル4803の記載内容を変更し、各文書構造毎に要素型名の種別を指定できるようにする方法について説明する。
【0400】
図72を用いて、本実施例における種別定義テーブル4803の格納情報について説明する。本図のように、DTD名称と要素型名を合わせてDTDおよび要素型名の領域7201に格納することで、解析済み文書データの要素型名だけでなく、DTD名称との組み合わせで種別を決めることができる。これにより、例えば、「報告書」における「本文」の種別は「報告内容」であり、その他の文書の「本文」は、種別も「本文」のままとし、登録文書の文書構造に合わせた種別を定義することが可能となる。
【0401】
本実施例における文書登録サブシステム101のシステム構成は、図48に示す第五の実施例の文書登録サブシステムのシステム構成と同じである。さらに、本実施例における、文書登録サブシステム101の処理手順は、図52のPAD図に示す第五の実施例における文書登録サブシステムの処理手順と同じである。ただし、ステップ5201における構造インデクスの最上位構造の取得の際に種別定義テーブル4803を参照して単に要素型名を種別に変換するのではなく、登録文書のDTDと要素名の組み合わせに対応する種別を取得する点が異なる。さらに、ステップ5202において、構造インデクスの重ね合わせを行なう際に、種別定義テーブル4803を参照して、登録文書のDTDと要素型名の組み合わせにより種別を得てから重ね合わせを行なう点が異なる。
【0402】
その他の構成及び処理内容において、本実施例が第五の実施例と異なる点はない。
【0403】
以上が、本発明を利用した第九の実施例である。
【0404】
(第十の実施例)
次に第十の実施例として、第五の実施例における種別定義テーブル4803を構造インデクス毎に管理し、メタ構造インデクス中の各構造インデクス毎に種別定義テーブルを参照して種別を得る方法について説明する。
【0405】
本実施例における文書登録サブシステム101のシステム構成は、図48に示す第五の実施例の文書登録サブシステムのシステム構成と同じである。ただし、本実施例では、種別定義テーブル4803を各構造インデクス毎に作成し、メタ構造インデクスには、各構造インデクスの最上位構造の種別に関する種別定義テーブルを持つ構成とする点が異なる。このような構成とすることで、1つの要素型名を構造インデクス毎に異なる種別に割り当てることができる。
【0406】
これらの種別定義テーブルは、第五の実施例において、図50に示す内容としても良いし、第九の実施例において、図72で示す内容としても良い。以下の説明では、種別定義テーブルは図50に示す第五の実施例の種別定義テーブルを用いる場合について説明するが、図72で示した第九の実施例の種別定義テーブルを用いる場合でも同様の手順で実現可能である。
【0407】
図73は、本実施例におけるメタ構造インデクスと、種別定義テーブルの関連を示す図である。メタ構造インデクス7301のルートメタノード7302に対応する、最上位構造種別定義テーブル7303を作成する。さらに、各構造インデクス毎に種別定義テーブルを作成する。本図では、論文の構造インデクス7304に対応する種別定義テーブル1(7305)を作成し、さらに報告書の構造インデクス7306に対応する種別定義テーブル2(7307)を作成する。このような構成にすることで、構造インデクス毎に種別を定義することができる。
【0408】
本実施例における、文書登録サブシステム101の処理手順は、図52に示す第五の実施例における文書登録サブシステムの処理手順を示したPAD図と同じである。ただし、ステップ5201における構造インデクスの最上位構造の取得の際には、最上位構造種別定義テーブル7303を参照して要素型名を種別に変換し、対応する構造インデクスを得る。さらにステップ5202において、ステップ5201で得られる構造インデクスに対応する種別定義テーブルを参照して、要素型名を種別に変換し構造インデクスの重ね合わせを行なう。例えば登録文書の種別が論文であれば、構造インデクス7304に対応する種別定義テーブル1(7305)を参照して、要素型名を種別に変換する。
【0409】
その他の構成及び処理内容において、本実施例が第五の実施例と異なる点はない。
【0410】
第九の実施例のように種別定義テーブルが図72に示す構成であっても、第九の実施例で示した手順により要素型名だけでなくDTD名称との組み合わせで参照することで、同様に実現可能である。
【0411】
以上が、本発明を利用した第十の実施例である。
【0412】
【発明の効果】
以上説明したように、本発明による構造化文書の検索方法によれば、文書中に現れる論理要素の文書中における出現位置に関する条件を構造条件指定中に含めることができるので、複雑な論理構造を備えた多数の文書からなる文書データベース上においても精度の高い構造指定検索ができる。
【図面の簡単な説明】
【図1】本発明による文書検索システムの第一の実施例の全体構成を示す図である。
【図2】本発明の第一の実施例における文書登録サブシステムの構成を示す図である。
【図3】本発明の第一の実施例における文書登録処理の概略手順を示すPAD図である。
【図4】文書論理構造を定義するDTDの一例を示す図である。
【図5】SGMLによる構造化文書の記述例を示す図である。
【図6】SGMLが表現する文書の論理構造を図形的に示した模式図である。
【図7】本発明の第一の実施例における文書構造解析プログラムの処理手順を示すPAD図である。
【図8】文書構造テーブルのデータ構造を示す図である。
【図9】本発明の第一の実施例における構造インデックス作成プログラムの処理手順を示すPAD図である。
【図10】本発明の第一の実施例における解析済み文書データの辿り順を示す図である。
【図11】本発明の第一の実施例におけるノードとメタノードとの対応関係を示す図である。
【図12】本発明の第一の実施例における構造インデックスの生成過程を示す図である。
【図13】本発明の第一の実施例における構造化全文データ生成プログラムの処理手順を示す図である。
【図14】本発明の第一の実施例における構造化全文データのファイル形式を示す図である。
【図15】本発明の第一の実施例における文字列インデックス作成プログラムの処理手順を示すPAD図である。
【図16】本発明の第一の実施例における文字列インデックスのデータ構造を示す図である。
【図17】本発明の第一の実施例における文書検索サーバの構成を示す図である。
【図18】本発明の第一の実施例における文書検索処理の概略手順を示すPAD図である。
【図19】本発明の第一の実施例における検索条件解析プログラムの処理手順を示すPAD図である。
【図20】本発明の第一の実施例における展開済み検索条件データの生成例を示す図である。
【図21】本発明の第一の実施例における文字列インデックス検索プログラムの処理手順を示すPAD図である。
【図22】本発明の第一の実施例における連接判定処理の実行例を示す図である。
【図23】本発明の第一の実施例における検索結果データのデータ構造を示す図である。
【図24】本発明の第一の実施例における検索結果データ転送処理の詳細手順を示すPAD図である。
【図25】本発明の第一の実施例における文書検索クライアントの構成を示す図である。
【図26】本発明の第一の実施例における検索クライアントの動作手順を示すPAD図である。
【図27】本発明の第一の実施例における検索条件入力プログラムの処理手順を示すPAD図である。
【図28】本発明の第一の実施例における検索結果表示プログラムの処理手順を示すPAD図である。
【図29】本発明の第二の実施例における文書登録サブシステムの構成を示す図である。
【図30】本発明の第二の実施例における文書登録処理の概略手順を示すPAD図である。
【図31】本発明の第二の実施例における逆順構造インデックス作成プログラムの処理手順を示すPAD図である。
【図32】本発明の第二の実施例における解析済み文書データの辿り順を示す図である。
【図33】本発明の第二の実施例におけるノードとメタノードとの対応関係を示す図である。
【図34】本発明の第二の実施例における逆順構造インデックスの生成過程を示す図である。
【図35】本発明の第二の実施例における構造化全文データ生成プログラムの処理手順を示すPAD図である。
【図36】本発明の第二の実施例における構造化全文データのファイル形式を示す図である。
【図37】本発明の第二の実施例における文字列インデックスのデータ形式を示すPAD図である。
【図38】本発明の第二の実施例における文書検索サーバの構成を示す図である。
【図39】本発明の第二の実施例における文書検索処理の概略手順を示すPAD図である。
【図40】本発明の第二の実施例における検索条件解析プログラムの処理手順を示すPAD図である。
【図41】本発明の第二の実施例における展開済み検索条件データの生成例を示す図である。
【図42】本発明の第二の実施例における文字列インデックス検索プログラムの処理手順を示すPAD図である。
【図43】本発明の第三の実施例におけるノードとメタノードとの対応関係を示す図である。
【図44】本発明の第三の実施例における文書登録サブシステムの構成を示す図である。
【図45】本発明の第四の実施例における文書登録処理の概略手順を示すPAD図である。
【図46】本発明の第四の実施例における文書構造正規化プログラムの処理手順を示すPAD図である。
【図47】本発明の第四の実施例における正規化処理の具体例を示す図である。
【図48】本発明の第五の実施例における文書登録サブシステムの構成を示す図である。
【図49】本発明の第五の実施例におけるメタ構造インデクス作成の例を示す図である。
【図50】本発明の第五の実施例における種別定義テーブルの内容を示す図である。
【図51】本発明の第五の実施例における文書登録処理の概略手順を示すPAD図である。
【図52】本発明の第五の実施例におけるメタ構造インデクス作成処理の概略手順を示すPAD図である。
【図53】本発明の第五の実施例におけるメタ構造インデクスの更新処理の例1を示す図である。
【図54】本発明の第五の実施例におけるメタ構造インデクスの更新処理の例2を示す図である。
【図55】本発明の第五の実施例における文書検索サーバの構成を示す図である。
【図56】本発明の第五の実施例における文書検索処理の概略手順を示すPAD図である。
【図57】本発明の第五の実施例におけるメタ構造インデクス対応検索条件解析プログラムの処理手順を示すPAD図である。
【図58】本発明の第五の実施例における展開済み検索条件データの生成例を示す図である。
【図59】本発明の第六の実施例における構造条件変換の例を示す図である。
【図60】本発明の第七の実施例における文書登録サブシステムの構成を示す図である。
【図61】本発明の第七の実施例におけるルートノード付加プログラムの処理結果の例を示す図である。
【図62】本発明の第七の実施例における文書検索サーバの構成を示す図である。
【図63】本発明の第七の実施例におけるルートノード付加プログラムの処理手順を示す図である。
【図64】本発明の第七の実施例における構造条件変換処理の内容を示す図である。
【図65】本発明の第八の実施例における別名構造インデクスを示す図である。
【図66】本発明の第八の実施例における文書登録サブシステムのシステム構成図である。
【図67】本発明の第八の実施例における登録処理の概略手順のPAD図である。
【図68】本発明の第八の実施例における別名構造インデクス作成処理手順を示すPAD図である。
【図69】本発明の第八の実施例における文書検索サーバのシステム構成図である。
【図70】本発明の第八の実施例における文書検索の概略処理を示すPAD図である。
【図71】本発明の第八の実施例における別名構造インデクス対応検索条件解析プログラムの処理手順を示すPAD図である。
【図72】本発明の第九の実施例における種別定義テーブルの内容を示す図である。
【図73】本発明の第十の実施例におけるメタ構造インデクスと構造インデクス毎の種別定義管理テーブルの対応関係を示す図である。
【符号の説明】
101…文書登録サブシステム、
102…文書検索サーバ、
103…文書検索クライアント、
210…文書構造解析プログラム、
211…構造インデックス作成プログラム、
212…構造化全文データ生成プログラム、
213…文字列インデックス作成プログラム、
214…文書登録制御プログラム、
217…解析済み文書データ格納領域、
218…構造インデックス格納領域、
219…構造化全文データ格納領域、
220…文字列インデックス格納領域、
1701…検索条件解析プログラム、
1702…文字列インデックス検索プログラム、
1703…文書検索制御プログラム、
1704…検索結果データ格納領域、
2001…検索条件の一例、
2002…構造インデックスの一例、
2003…展開済み検索条件データの一例、
2201…文字列インデックスの一例、
2501…検索条件入力プログラム、
2502…検索結果表示プログラム、
2503…クライアント制御プログラム、
2901…逆順構造インデックス作成プログラム、
2902…逆順構造インデックス格納領域、
4102…逆順構造インデックスの一例、
4401…文書構造正規化プログラム、
4801…メタ構造インデクス作成プログラム、
4802…メタ構造インデクス格納領域、
4803…種別定義テーブル、
4901…構造インデクスの一例、
4902…構造インデクスの一例、
4903…ルートメタノード、
4904…メタ構造インデクスの一例、
5501…メタ構造インデクス対応検索条件解析プログラム、
5801…検索条件の一例、
5802…メタ構造インデクスの一例、
5803…展開済み検索条件データの一例、
6001…ルートノード付加プログラム、
6101…解析済み文書データの一例、
6102…ルートノード付加解析済み文書データの一例、
6201…検索条件修正プログラム、
6501…別名構造インデクスの例、
6502…メタ構造インデクスの例、
6503…別名定義テーブルの例、
6601…別名構造インデクス作成プログラム、
6602…別名構造インデクス格納領域、
6901…別名構造インデクス対応検索条件解析プログラム、
7301…メタ構造インデクスの例、
7302…ルートメタノード、
7303…最上位構造種別定義テーブル、
7304…構造インデクス1、
7305…種別定義テーブル1、
7306…構造インデクス2、
7307…種別定義テーブル2。
Claims (7)
- 予め登録した文書の集合を対象として文書内容の検索を行う文書検索システムにおける構造化文書の登録方法であって、
登録される文書の持つ論理構造を解析して得られる解析済み文書を作成する解析済み文書データ生成ステップと、
文書の要素型名と構造の種別の対応を定義した種別定義テーブルの内容を解析して、同じ種別とみなされる構造を得て、
最上位の構造が同じ種別であるとみなされる、複数の解析済み文書の論理構造を重ね合わせ、文書中における出現位置および種別が同一である構造要素群を単一のメタノードによって代表させ、一つの文書のみに出現するとみなされる構造要素は、その構造要素を表わす一つのメタノードを生成することで、最上位の構造が同じとみなされる複数の登録文書ごとに、メタノードを要素とする木構造により共通の構造情報を表わす構造インデクスを作成し、
複数の構造インデクスの最上位構造を表わすメタノードの共通の上位構造として、仮想のノードであるルートメタノードを作成し、各登録文書の最上位構造を表わすメタノードは、ルートメタノードの子構造とした、ルートメタノードを最上位ノードとするメタ構造インデクスを作成し、
メタ構造インデクスを構成するメタノードを識別する文脈識別子を各構造インデクスを構成するメタノードに与えるメタ構造インデクス作成ステップと
を有することを特徴とした構造化文書の登録方法。 - 請求項1に記載の構造化文書の登録方法であって、
各メタノードに対応した各登録文書の構造内の文字列を登録文書の識別情報と文脈識別子の情報と共に文字列インデクスに登録する文字列インデクス生成ステップ
を有することを特徴とした構造化文書の登録方法。 - 請求項1に記載の構造化文書の登録方法であって、
同じ種別であるとみなされる種別を持ち、異なる位置に出現する複数の構造に対する共通名称を別名として設定した別名定義テーブルを読み出し、
該別名とメタノードの文脈識別子を対応付けた、別名構造インデクスを生成する別名構造インデクス作成ステップを有することを特徴とした構造化文書の登録方法。 - 請求項3に記載の構造化文書の登録方法であって、
メタ構造インデスクに含まれる複数の構造インデクスに対して、各構造インデクスを識別するための構造インデクス識別子を付与する構造インデクス識別子付与ステップと、
各メタノードに対応した各登録文書の構造内の文字列を登録文書の識別情報と構造インデクス識別子と文脈識別子の情報と共に文字列インデクスに登録する文字列インデクス生成ステップを有することを特徴とした構造化文書の登録方法。 - 請求項2に記載した登録方法により登録した文書の集合を対象として文書内容の検索を行う文書検索システムにおける構造化文書の検索方法であって、
前記メタ構造インデクス作成ステップにより作成されたメタ構造インデクスを参照して、指定された構造条件を満たす文脈識別子の集合を決定する構造条件判定ステップと、
検索タームから所定の部分文字列を抽出し、前記文字列インデクス生成ステップにより生成された文字列インデクスを参照して該部分文字列に対応する構造化文字位置情報の集合を抽出する構造化文字位置情報抽出ステップと、
前記構造化文字位置情報の集合中から、前記構造条件判定ステップで決定した集合中に含まれる文脈識別子をもち、かつ前記検索ターム上における部分文字列の並びと同じ位置関係をもつ構造化文字位置情報を抽出するインデクス検索ステップ
を有することを特徴とした構造化文書の検索方法。 - 請求項5に記載の構造化文書の検索方法であって、
構造条件判定ステップにおいて、文書の要素型名と構造の種別の対応を定義した種別定義テーブルを用いて、検索条件に記載された要素型名を種別情報に変換した上で、構造インデクスを参照して、種別情報に適合する文脈識別子の集合を決定することを特徴とした構造化文書の検索方法。 - 請求項4に記載した登録方法により登録した文書の集合を対象として文書内容の検索を行う文書検索システムにおける構造化文書の検索方法であって、
前記メタ構造インデクス作成ステップにより作成されたメタ構造インデクスおよび別名構造インデクス作成ステップにより作成された別名構造インデクスを基に、指定された別名を使用した構造条件を満たす構造インデクスおよび文脈識別子の集合を決定する構造条件判定ステップと、
検索タームから所定の部分文字列を抽出し、前記文字列インデクス生成ステップにより生成された文字列インデクスを参照して該部分文字列に対応する構造化文字位置情報の集合を抽出する構造化文字位置情報抽出ステップと、
前記構造化文字位置情報の集合中から、前記構造条件判定ステップで決定した集合中に含まれる文脈識別子をもち、かつ前記検索ターム上における部分文字列の並びと同じ位置関係をもつ構造化文字位置情報を抽出するインデクス検索ステップ
を有することを特徴とした構造化文書の検索方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP04318798A JP3692764B2 (ja) | 1998-02-25 | 1998-02-25 | 構造化文書登録方法、検索方法、およびそれに用いられる可搬型媒体 |
US09/256,178 US6377946B1 (en) | 1998-02-25 | 1999-02-24 | Document search method and apparatus and portable medium used therefor |
US09/972,004 US6510425B1 (en) | 1998-02-25 | 2001-10-09 | Document search method for registering documents, generating a structure index with elements having position of occurrence in documents represented by meta-nodes |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP04318798A JP3692764B2 (ja) | 1998-02-25 | 1998-02-25 | 構造化文書登録方法、検索方法、およびそれに用いられる可搬型媒体 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH11242676A JPH11242676A (ja) | 1999-09-07 |
JP3692764B2 true JP3692764B2 (ja) | 2005-09-07 |
Family
ID=12656924
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP04318798A Expired - Fee Related JP3692764B2 (ja) | 1998-02-25 | 1998-02-25 | 構造化文書登録方法、検索方法、およびそれに用いられる可搬型媒体 |
Country Status (2)
Country | Link |
---|---|
US (2) | US6377946B1 (ja) |
JP (1) | JP3692764B2 (ja) |
Families Citing this family (80)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3696731B2 (ja) * | 1998-04-30 | 2005-09-21 | 株式会社日立製作所 | 構造化文書の検索方法および装置および構造化文書検索プログラムを記録したコンピュータ読み取り可能な記録媒体 |
JP2000181927A (ja) * | 1998-12-15 | 2000-06-30 | Toshiba Corp | 電子ファイリングシステム及び同システムに適用するファイル検索方法 |
AU769963B2 (en) * | 1999-08-02 | 2004-02-12 | Tae Gyu Lee | Remote saving method of the search information on the Internet |
JP3754253B2 (ja) * | 1999-11-19 | 2006-03-08 | 株式会社東芝 | 構造化文書検索方法、構造化文書検索装置及び構造化文書検索システム |
JP2001167087A (ja) | 1999-12-14 | 2001-06-22 | Fujitsu Ltd | 構造化文書検索装置,構造化文書検索方法,構造化文書検索用プログラム記録媒体および構造化文書検索用インデックス作成方法 |
US8271316B2 (en) * | 1999-12-17 | 2012-09-18 | Buzzmetrics Ltd | Consumer to business data capturing system |
JP3719089B2 (ja) * | 2000-03-16 | 2005-11-24 | 松下電器産業株式会社 | 文書処理装置 |
US6684204B1 (en) * | 2000-06-19 | 2004-01-27 | International Business Machines Corporation | Method for conducting a search on a network which includes documents having a plurality of tags |
US7197470B1 (en) * | 2000-10-11 | 2007-03-27 | Buzzmetrics, Ltd. | System and method for collection analysis of electronic discussion methods |
US7185065B1 (en) | 2000-10-11 | 2007-02-27 | Buzzmetrics Ltd | System and method for scoring electronic messages |
US8594364B2 (en) * | 2000-11-02 | 2013-11-26 | Digimarc Corporation | Batch identifier registration and embedding in media signals |
US20030023584A1 (en) * | 2001-04-27 | 2003-01-30 | Brandin Christopher Lockton | Universal information base system |
KR100657267B1 (ko) * | 2003-10-30 | 2006-12-14 | 삼성전자주식회사 | 검색을 위한 메타 정보가 포함된 저장 매체, 재생 장치 및그 재생 방법 |
US7124358B2 (en) * | 2002-01-02 | 2006-10-17 | International Business Machines Corporation | Method for dynamically generating reference identifiers in structured information |
US6963869B2 (en) * | 2002-01-07 | 2005-11-08 | Hewlett-Packard Development Company, L.P. | System and method for search, index, parsing document database including subject document having nested fields associated start and end meta words where each meta word identify location and nesting level |
JP2003271584A (ja) * | 2002-03-14 | 2003-09-26 | Ricoh Co Ltd | 文書管理装置、クライアント装置、文書管理システム、プログラム及び記憶媒体 |
KR20040101544A (ko) * | 2002-04-19 | 2004-12-02 | 컴퓨터 어소시에이츠 싱크, 인코포레이티드 | 검색 결과를 항해하는 시스템 및 방법 |
US7039649B2 (en) * | 2002-05-17 | 2006-05-02 | Sun Microsystems, Inc. | Method and apparatus for maintaining data integrity |
MXPA04011507A (es) * | 2002-05-20 | 2005-09-30 | Tata Infotech Ltd | Identificador de estructura de documento. |
US7702666B2 (en) * | 2002-06-06 | 2010-04-20 | Ricoh Company, Ltd. | Full-text search device performing merge processing by using full-text index-for-registration/deletion storage part with performing registration/deletion processing by using other full-text index-for-registration/deletion storage part |
US7730087B2 (en) * | 2003-02-28 | 2010-06-01 | Raining Data Corporation | Apparatus and method for matching a query to partitioned document path segments |
US7210125B2 (en) * | 2003-07-17 | 2007-04-24 | International Business Machines Corporation | Method and system for application installation and management using an application-based naming system including aliases |
US7725414B2 (en) | 2004-03-16 | 2010-05-25 | Buzzmetrics, Ltd An Israel Corporation | Method for developing a classifier for classifying communications |
GR1004902B (el) * | 2004-04-19 | 2005-05-27 | Αθανασιος Σαββιδης | Μεθοδος αναζητησης πληροφοριων σε ηλεκτρονικους υπολογιστες και μηχανισμος αποθηκευσης κειμενων "ανα παραγραφο" |
US7526490B2 (en) * | 2004-06-08 | 2009-04-28 | Oracle International Corporation | Method of and system for providing positional based object to XML mapping |
JP4309818B2 (ja) * | 2004-07-15 | 2009-08-05 | 株式会社東芝 | 構造化文書管理装置、検索装置、記憶方法、検索方法及びプログラム |
US7430663B2 (en) * | 2004-08-09 | 2008-09-30 | Research In Motion Limited | System and method for enabling bulk retrieval of certificates |
US7549043B2 (en) * | 2004-09-01 | 2009-06-16 | Research In Motion Limited | Providing certificate matching in a system and method for searching and retrieving certificates |
US7631183B2 (en) | 2004-09-01 | 2009-12-08 | Research In Motion Limited | System and method for retrieving related certificates |
US7640428B2 (en) * | 2004-09-02 | 2009-12-29 | Research In Motion Limited | System and method for searching and retrieving certificates |
WO2006039566A2 (en) | 2004-09-30 | 2006-04-13 | Intelliseek, Inc. | Topical sentiments in electronically stored communications |
JP4343814B2 (ja) * | 2004-11-04 | 2009-10-14 | キヤノン株式会社 | 情報処理装置及びその制御方法及びプログラム |
TW200620299A (en) * | 2004-12-08 | 2006-06-16 | Benq Corp | Electronic device and method for updating related programs |
US9158855B2 (en) | 2005-06-16 | 2015-10-13 | Buzzmetrics, Ltd | Extracting structured data from weblogs |
WO2007011841A2 (en) | 2005-07-15 | 2007-01-25 | Indxit Systems, Inc. | Systems and methods for data indexing and processing |
CA2545237A1 (en) * | 2005-07-29 | 2007-01-29 | Cognos Incorporated | Method and system for managing exemplar terms database for business-oriented metadata content |
CA2545232A1 (en) * | 2005-07-29 | 2007-01-29 | Cognos Incorporated | Method and system for creating a taxonomy from business-oriented metadata content |
US20070100779A1 (en) * | 2005-08-05 | 2007-05-03 | Ori Levy | Method and system for extracting web data |
US20070055670A1 (en) * | 2005-09-02 | 2007-03-08 | Maycotte Higinio O | System and method of extracting knowledge from documents |
US9177124B2 (en) | 2006-03-01 | 2015-11-03 | Oracle International Corporation | Flexible authentication framework |
US8307276B2 (en) * | 2006-05-19 | 2012-11-06 | Symantec Corporation | Distributed content verification and indexing |
US7814161B2 (en) | 2006-06-23 | 2010-10-12 | Research In Motion Limited | System and method for handling electronic mail mismatches |
JP4861078B2 (ja) * | 2006-06-30 | 2012-01-25 | 富士通株式会社 | 索引作成プログラム、索引作成装置および索引作成方法 |
US7747629B2 (en) * | 2006-08-23 | 2010-06-29 | International Business Machines Corporation | System and method for positional representation of content for efficient indexing, search, retrieval, and compression |
US7660783B2 (en) * | 2006-09-27 | 2010-02-09 | Buzzmetrics, Inc. | System and method of ad-hoc analysis of data |
JP4860416B2 (ja) * | 2006-09-29 | 2012-01-25 | 株式会社ジャストシステム | 文書検索装置、文書検索方法および文書検索プログラム |
JP5437557B2 (ja) * | 2006-10-19 | 2014-03-12 | 富士通株式会社 | 検索処理方法及び検索システム |
US7885932B2 (en) * | 2006-11-01 | 2011-02-08 | Ab Initio Technology Llc | Managing storage of individually accessible data units |
US8229902B2 (en) * | 2006-11-01 | 2012-07-24 | Ab Initio Technology Llc | Managing storage of individually accessible data units |
US7849399B2 (en) * | 2007-06-29 | 2010-12-07 | Walter Hoffmann | Method and system for tracking authorship of content in data |
US7844633B2 (en) * | 2007-09-13 | 2010-11-30 | International Business Machines Corporation | System and method for storage, management and automatic indexing of structured documents |
US8266519B2 (en) * | 2007-11-27 | 2012-09-11 | Accenture Global Services Limited | Document analysis, commenting, and reporting system |
US8412516B2 (en) | 2007-11-27 | 2013-04-02 | Accenture Global Services Limited | Document analysis, commenting, and reporting system |
US8271870B2 (en) | 2007-11-27 | 2012-09-18 | Accenture Global Services Limited | Document analysis, commenting, and reporting system |
US8392816B2 (en) * | 2007-12-03 | 2013-03-05 | Microsoft Corporation | Page classifier engine |
US20090144277A1 (en) * | 2007-12-03 | 2009-06-04 | Microsoft Corporation | Electronic table of contents entry classification and labeling scheme |
US8250469B2 (en) * | 2007-12-03 | 2012-08-21 | Microsoft Corporation | Document layout extraction |
US8347326B2 (en) | 2007-12-18 | 2013-01-01 | The Nielsen Company (US) | Identifying key media events and modeling causal relationships between key events and reported feelings |
US20090228817A1 (en) * | 2008-03-10 | 2009-09-10 | Randy Adams | Systems and methods for displaying a search result |
US20090228811A1 (en) * | 2008-03-10 | 2009-09-10 | Randy Adams | Systems and methods for processing a plurality of documents |
US20100017486A1 (en) * | 2008-07-16 | 2010-01-21 | Fujitsu Limited | System analyzing program, system analyzing apparatus, and system analyzing method |
US8326977B2 (en) | 2008-07-16 | 2012-12-04 | Fujitsu Limited | Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method |
EP2362333A1 (en) | 2010-02-19 | 2011-08-31 | Accenture Global Services Limited | System for requirement identification and analysis based on capability model structure |
US8874727B2 (en) | 2010-05-31 | 2014-10-28 | The Nielsen Company (Us), Llc | Methods, apparatus, and articles of manufacture to rank users in an online social network |
US8566731B2 (en) | 2010-07-06 | 2013-10-22 | Accenture Global Services Limited | Requirement statement manipulation system |
JP5790664B2 (ja) * | 2011-01-25 | 2015-10-07 | 日本電気株式会社 | 情報検索装置 |
US9400778B2 (en) | 2011-02-01 | 2016-07-26 | Accenture Global Services Limited | System for identifying textual relationships |
US8935654B2 (en) | 2011-04-21 | 2015-01-13 | Accenture Global Services Limited | Analysis system for test artifact generation |
US20130013605A1 (en) | 2011-07-08 | 2013-01-10 | Stanfill Craig W | Managing Storage of Data for Range-Based Searching |
US8843466B1 (en) | 2011-09-27 | 2014-09-23 | Google Inc. | Identifying entities using search results |
US8775439B1 (en) | 2011-09-27 | 2014-07-08 | Google Inc. | Identifying entities using search results |
US8856099B1 (en) | 2011-09-27 | 2014-10-07 | Google Inc. | Identifying entities using search results |
US8473489B1 (en) * | 2011-09-27 | 2013-06-25 | Google Inc. | Identifying entities using search results |
US9001390B1 (en) | 2011-10-06 | 2015-04-07 | Uri Zernik | Device, system and method for identifying sections of documents |
CN103176978B (zh) * | 2011-12-20 | 2016-05-04 | 北大方正集团有限公司 | 一种确定检索词在文档中的位置信息的方法以及装置 |
US9208254B2 (en) * | 2012-12-10 | 2015-12-08 | Microsoft Technology Licensing, Llc | Query and index over documents |
GB201421674D0 (en) * | 2014-12-05 | 2015-01-21 | Business Partners Ltd | Real time document indexing |
JP6932064B2 (ja) * | 2017-11-01 | 2021-09-08 | 株式会社エヌ・ティ・ティ・データ | データベース支援装置、データベース支援方法、及びプログラム |
EP3827360A1 (en) * | 2018-07-25 | 2021-06-02 | Ab Initio Technology LLC | Structured record retrieval |
JP7272540B2 (ja) * | 2021-07-06 | 2023-05-12 | 株式会社 情報システムエンジニアリング | 情報提供システム、情報提供方法、及びデータ構造 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE69032712T2 (de) * | 1989-06-14 | 1999-07-01 | Hitachi Ltd | Hierarchischer vorsuch-typ dokument suchverfahren, vorrichtung dazu, sowie eine magnetische plattenanordnung für diese vorrichtung |
US5748953A (en) * | 1989-06-14 | 1998-05-05 | Hitachi, Ltd. | Document search method wherein stored documents and search queries comprise segmented text data of spaced, nonconsecutive text elements and words segmented by predetermined symbols |
US5708829A (en) * | 1991-02-01 | 1998-01-13 | Wang Laboratories, Inc. | Text indexing system |
US5404518A (en) * | 1991-12-19 | 1995-04-04 | Answer Computer, Inc. | System for building a user-determined database of solution documents from queries that fail within it and from the search steps that do provide a solution |
US5696963A (en) * | 1993-11-19 | 1997-12-09 | Waverley Holdings, Inc. | System, method and computer program product for searching through an individual document and a group of documents |
JPH08147311A (ja) * | 1994-11-17 | 1996-06-07 | Hitachi Ltd | 構造化文書検索方法及び装置 |
US5745745A (en) * | 1994-06-29 | 1998-04-28 | Hitachi, Ltd. | Text search method and apparatus for structured documents |
US5832474A (en) * | 1996-02-26 | 1998-11-03 | Matsushita Electric Industrial Co., Ltd. | Document search and retrieval system with partial match searching of user-drawn annotations |
US5890147A (en) * | 1997-03-07 | 1999-03-30 | Microsoft Corporation | Scope testing of documents in a search engine using document to folder mapping |
US6098066A (en) * | 1997-06-13 | 2000-08-01 | Sun Microsystems, Inc. | Method and apparatus for searching for documents stored within a document directory hierarchy |
US6055538A (en) * | 1997-12-22 | 2000-04-25 | Hewlett Packard Company | Methods and system for using web browser to search large collections of documents |
-
1998
- 1998-02-25 JP JP04318798A patent/JP3692764B2/ja not_active Expired - Fee Related
-
1999
- 1999-02-24 US US09/256,178 patent/US6377946B1/en not_active Expired - Fee Related
-
2001
- 2001-10-09 US US09/972,004 patent/US6510425B1/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JPH11242676A (ja) | 1999-09-07 |
US6510425B1 (en) | 2003-01-21 |
US6377946B1 (en) | 2002-04-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3692764B2 (ja) | 構造化文書登録方法、検索方法、およびそれに用いられる可搬型媒体 | |
JP3887867B2 (ja) | 構造化文書の登録方法 | |
JP4656868B2 (ja) | 構造化文書作成装置 | |
US6889223B2 (en) | Apparatus, method, and program for retrieving structured documents | |
JP4141556B2 (ja) | 構造化文書管理方法及びその実施装置並びにその処理プログラムを記録した媒体 | |
US5553216A (en) | Structured database system together with structure definition frame storing document body data | |
US6931590B2 (en) | Method and system for managing documents | |
US7975220B2 (en) | Apparatus, program product and method for structured document management | |
US20090019015A1 (en) | Mathematical expression structured language object search system and search method | |
JPH08241332A (ja) | 全文登録語検索装置および方法 | |
JP4860416B2 (ja) | 文書検索装置、文書検索方法および文書検索プログラム | |
JP3831085B2 (ja) | 文書管理装置,サーバ装置,クライアント装置およびそれらのプログラム記憶媒体 | |
JP4247108B2 (ja) | 構造化文書検索方法、構造化文書検索装置、及びプログラム | |
WO2008041367A1 (fr) | Dispositif de recherche de document, procédé de recherche de document et programme de recherche de document | |
JP3632643B2 (ja) | 構造化文書管理装置 | |
Barbosa et al. | Efficient incremental validation of XML documents after composite updates | |
JP2000003366A (ja) | 文書登録方法と文書検索方法及びその実施装置並びにその処理プログラムを記録した媒体 | |
JP3842576B2 (ja) | 構造化文書編集方法及び構造化文書編集システム | |
JP4255538B2 (ja) | 構造化文書蓄積検索装置 | |
JP2003288365A (ja) | 付加情報管理方法及び付加情報管理システム | |
JP3910901B2 (ja) | 文書構造検索方法、文書構造検索装置および文書構造検索プログラム | |
JP3842574B2 (ja) | 情報抽出方法および構造化文書管理装置およびプログラム | |
JP4334450B2 (ja) | 構造化文書検索装置及び構造化文書検索方法 | |
JPH1153400A (ja) | 構造化文書検索装置及びプログラムを記録した機械読み取り可能な記録媒体 | |
JPH1027178A (ja) | 文書データベース管理装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041026 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041224 |
|
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: 20050531 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050613 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090701 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100701 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110701 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110701 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120701 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130701 Year of fee payment: 8 |
|
LAPS | Cancellation because of no payment of annual fees |