[go: up one dir, main page]

JP5695586B2 - Xml文書検索装置及びプログラム - Google Patents

Xml文書検索装置及びプログラム Download PDF

Info

Publication number
JP5695586B2
JP5695586B2 JP2012039242A JP2012039242A JP5695586B2 JP 5695586 B2 JP5695586 B2 JP 5695586B2 JP 2012039242 A JP2012039242 A JP 2012039242A JP 2012039242 A JP2012039242 A JP 2012039242A JP 5695586 B2 JP5695586 B2 JP 5695586B2
Authority
JP
Japan
Prior art keywords
xml document
path
sequence
search
select
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
Application number
JP2012039242A
Other languages
English (en)
Other versions
JP2013175053A (ja
Inventor
安田 知弘
知弘 安田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2012039242A priority Critical patent/JP5695586B2/ja
Publication of JP2013175053A publication Critical patent/JP2013175053A/ja
Application granted granted Critical
Publication of JP5695586B2 publication Critical patent/JP5695586B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、複数のXML(Extensible Markup Language)文書から、ユーザが指定した検索条件に合致する箇所を探索する装置及びプログラムに関する。
データ交換及び蓄積に用いるデータの記述方法として、XMLが広く普及している。XMLを用いることにより、多様なデータを高い自由度で、機械的に処理しやすいテキストフォーマットで記述できる。図1に、XML文書の例を示す。この文書の内容は「<」と「>」で囲まれたタグにより複数の部分に区切られている。タグには、「<タグ名>」の形式で書かれている開始タグ101と、「</タグ名>」の形式で書かれた終了タグ102がある。同じタグ名の開始タグと終了タグで区切られた領域を、要素又はXML要素と呼ぶ。
なお、開始タグおよび終了タグに挟まれるタグやテキスト領域がない場合、XMLでは、開始タグおよび終了タグの代わりに「<タグ名/>」という形式のタグを使用できる。本明細書では、このようなタグは、「<タグ名></タグ名>」と記述した場合と同様に扱う。また、開始タグでは、「<タグ名 属性1=属性の値1 属性2=属性の値2 ...>」の形式で、タグに属性値を与えることができる。本明細書では、このようなタグが与えられると、「<タグ名> <@属性1>属性の値1<@属性1> <@属性2>属性の値2</@属性2>」と書かれた場合と同様に扱う。また、本明細書では、テキスト領域は、タグ名が「#」である要素であるとみなす。また、親をもたない要素をルート要素と呼ぶ。各XML文書は、ただ1つのルート要素を持つ。
XMLでは、複数の要素を入れ子にすることで、複雑なデータ構造を記述することができる。終了タグのタグ名は、XML文章を先頭から末尾へ読み進めたとき、まだ対応する終了タグが出現していない開始タグのうち最も直前に現れた開始タグのタグ名と、同一でなければならない。従って、任意の2つの要素は、一方が他方を完全に包含するか、全く重なりがないかのいずれかに限られる。ある要素Aが「要素Bを包含し」、かつ、「要素Aに包含され、かつ、要素Bを包含する別の要素Cが存在しない」とき、要素Bは要素Aの子であるといい、要素Aは要素Bの親であるという。親を順次辿って到達可能な要素は先祖と呼ばれ、子を順次辿って到達可能な要素は子孫と呼ばれる。また、同じ親の子である要素を、兄弟と呼ぶ。
この要素間の関係は、一般に、木構造により表される。図2に、木構造の一例を示す。図2に示す木構造は、各要素に対応するノード201を用意し、親要素に対応するノードから子要素に対応するノードへ有向エッジ202を張ることで得られる。この木構造は、DOM木(document object model tree)と呼ばれる。DOM木の根から、各ノードへ至る経路上にある要素のタグ名を「/」を挟んで連結し、さらに先頭に「/」を付与して得られる文字列を、本明細書では構造パスと呼ぶ。例えば図2の場合、もっとも右側の「c」の構造パスは、「/a/c」である。構造パスに含まれるタグの数を、その要素の深さと定義する。
特開2006−228155号公報
清水敏之、鬼塚真、江田毅晴、吉川正俊、XMLデータの管理とストリーム処理に関する技術、電子情報通信学会論文誌D J90-D(2):159-184, 2007. R. Kaushik, R. Krishnamurthy, J.F. Naughton, R. Ramakrishnan, On the integration of structure indexes and inverted lists, Proc. ACM SIGMOD, pp 779-790, 2004. 江田毅晴、鬼塚真、山室雅司、XML データの要約情報を用いた高速な XPath 処理方法、電子情報通信学会論文誌D、J89-D(2): 139-150, 2006. 萩尾一仁、御手洗秀一、石野明、竹田正幸、漸増的なパストライ構築に基づく高速・軽量XML文書フィルタリング、DBSJ Letters 6(2):1-4, 2007. Navarro, G. and Makinen, V., Compressed full-text indexes, ACM Computing Surveys 39(1): Article 2, 2007. Managing Gigabytes,I.Witten,A.Moffat,and T.Bell,Morgan Kaufmann
XML文書を検索対象とする検索クエリの記述方法として、XPathと呼ばれる規格が普及している(非特許文献1)。例えばXPathは、「要素aの子である要素b」を指定する検索クエリを「a/b」と書く。XPathでは、このような検索クエリの記述方法が規格化されている。また、XPathで記述した検索クエリでは、親、子、先祖、子孫、兄弟等の関係にある複数の要素の組み合わせも指示することができる。
XPathにより記述された検索クエリによる検索処理においては、その検索処理を効率化する方法として、(1) 検索対象とするXMLデータに現れる構造と、(2) 各構造の出現位置とを記録したインデックスとを事前に構築し、それらを参照して検索クエリに合致する箇所を探す方法が広く用いられる(特許文献1、非特許文献2、3を参照)。この他、XPathにより記述された検索クエリによる検索処理においては、前述した事前処理は実行せず、検索実行時に検索対象とするXML文書に現れる構造をリアルタイムで分析する方法も用いられる(非特許文献4を参照)。ただし、こちらの方法は、検索インデックスを事前に計算する方法に比べ、検索速度の点で不利となる。
XPathにより記述された検索クエリによる検索を効率よく実行するためには、XML文書に現れる構造情報を分析して各構造パスに該当する箇所がどこにあるかを記録すると共に、親、子、先祖、子孫、兄弟といった要素間の関係を効率よく計算できるデータ構造が必要となる。さらに、大規模なXML文書を扱う場合には、このようなデータを極力小さいデータサイズで表現できることと、高速に読み取れることが必要となる。
そこで、本発明は、XML文書の検索処理で使用する検索用データのデータサイズを極力小さくし、検索クエリで指定された条件を満たす箇所の検索を高速に計算可能にする。このために、本発明は、XML文書分析部において、(1) 要素の出現順に、当該要素の深さを表す数値の列を部分列として含む第一の数列Sと、(2) DOM木の各ノードに対応する構造パスの種類を記録する1つ以上の数列からなる数列群Tとで与えられるXML文書のDOM木の形状を記録する検索用データを作成する。そして、数列Sと数列群Tを走査し、検索クエリとして与えられた構造パスに合致する箇所を計算する。
本発明によれば、XPathにより記述された検索クエリによる検索処理を高速化することができる。上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
XMLデータの一例を示す図。 DOM木の一例を示す図。 XML要素に割り当てる要素番号を説明する図。 第1の形態例に係るXML文書検索装置のブロック構成例を示す図。 第1の形態例に係る前処理実行時の各構成間の連携を説明する図。 第1の形態例に係る前処理動作の流れを説明するフローチャート。 第1の形態例に係る前処理動作の概念を示す図。 第1の形態例に係るXML文書分析部で実行される処理動作(分析動作)の流れを説明するフローチャート。 第1の形態例に係る検索実行時の各構成間の連携を説明する図。 第1の形態例に係るXML文書検索装置による検索処理の流れを説明するフローチャート。 第1の形態例に係る検索処理の処理例を説明する図。 rank演算及びselect演算を説明する図。 第1の形態例に係る構造パス分析部の動作の流れを説明するフローチャート。 第1の形態例に係る要素探索部の動作の流れを説明するフローチャート。 ビットベクトルを説明する図。 Wavelet木を説明する図。 第2の形態例に係るXML文書検索装置のブロック構成例を示す図。 第2の形態例に係る前処理実行時の各構成間の連携を説明する図。 第2の形態例に係る前処理の流れを説明するフローチャート。 第3の形態例において親要素を計算する動作の流れを説明するフローチャート。 第3の形態例において1つ前の兄弟要素を計算する動作の流れを説明するフローチャート。 第3の形態例において1つ後の兄弟要素を計算する動作の流れを説明するフローチャートで。
以下、図面に基づいて、本発明の実施の形態を説明する。なお、本発明は、後述する形態例に限定されるものではなく、その技術思想の範囲において、種々の変形が可能である。
[第1の形態例]
本形態例に係るXML文書検索装置は、XML文書集合を前処理して作成した検索用データと検索クエリとを照合し、検索クエリが指定する構造パスに合致する要素を探索結果として出力する。探索結果の出力は、XML文書に出現する全ての要素(XML要素)について割り当てられている要素番号により行う。
[要素番号]
図3に、XML文書を構成する各要素(XML要素)に対する要素番号の割り当て例を示す。図3では、要素番号301に対応する数字を四角形の枠内に表している。要素番号301は、検索処理の前処理において、全てのXML要素に割り当てられる、各要素を一意に識別する番号である。要素番号は、XML文書を先頭からスキャンしたとき、それまでに出会った要素数と文書数の合計値とする。i番目のXML文書のj番目の要素の要素番号は、i−1番目のXML文書の要素番号の最大値をE(i−1)とするとき、E(i−1)+1+jとなる。なお、E(0)=0とする。
[装置構成]
図4に、本形態例に係るXML文書検索装置400のブロック構成を示す。XML文書検索装置400は、CPU(Central Processing Unit)401、主記憶装置402、補助記憶装置403、リムーバブルドライブ404、ユーザインタフェース406及びネットワークインタフェース407を備える。各構成部は、内部バス等によって互いに接続される。
また、XML文書検索装置400は、LAN(Local Area Network)等のネットワーク440を介して外部記憶装置430と接続される。本形態例は、ネットワーク440の種別に限定されない。ネットワーク440は、有線接続でも、無線接続でも構わない。
CPU401は、主記憶装置402に格納されたプログラムを実行する演算装置である。CPU401による主記憶装置402に格納されるプログラムの実行により、XML文書検索装置400が有する機能が実現される。以下の説明においてプログラムを主語として説明する処理動作は、CPU401上での該当プログラムの実行を通じて実現される。
主記憶装置402は、CPU401によって実行されるプログラム及び当該プログラムの実行に必要な情報を格納する。主記憶装置402は、例えばRAM(Random Access Memory)等のメモリを想定する。
主記憶装置402には、プログラムとして、XML文書分析部410、構造パス分析部412及び要素探索部413を格納し、データとして、XML文書集合420、パストライ421、数列化されたDOM木422及びテキストデータ424を格納する。
XML文書分析部410は、XML文書集合420に含まれる各XML文書をパース(parse)し、タグを認識するとともにテキストデータ424を抽出する。そして、分析結果に基づき、XML文書分析部410は、パストライ421及び数列化されたDOM木422を生成する。
構造パス分析部412は、検索クエリである構造パスの深さ及びパス種別を、パストライ421を用いて計算する。なお、パス種別とは、各構造パスを識別するために割り当てる識別番号である。その詳細については後述する。
要素探索部413は、構造パス分析部412が計算した深さ及びパス種別に基づき、検索クエリに合致する箇所をXML文書集合420から全て列挙し、検索結果とする。
XML文書集合420は、検索対象となる1つ又は複数のXML文書のデータである。パストライ421は、XML文書集合420に含まれる構造情報の要約である。その詳細については後述する。数列化されたDOM木422は、XML文書集合420に含まれる構造情報を検索しやすい形式で抽出したものであり、これの詳細も後述する。テキストデータ424は、XML文書集合420においてタグに挟まれたテキストの情報を抽出したものである。
なお、XML文書集合420は、主記憶装置402に格納される必要はなく、例えば補助記憶装置403、リムーバブルメディア又は外部記憶装置430に格納されていてもよい。この場合、CPU401が、補助記憶装置403、リムーバブルメディア又は外部記憶装置430からXML文書集合420を読み出し、主記憶装置402に格納する。
同様に、パストライ421、数列化されたDOM木422、テキストデータ424も、主記憶装置402に格納される必要はなく、例えば補助記憶装置403及びリムーバブルメディアに格納されてもよい。この場合、CPU401は、必要に応じ、これらのデータを、補助記憶装置403及びリムーバブルメディア404から読み出す。
本形態例においては、XML文書分析部410、構造パス分析部412、要素探索部413をいずれもプログラムにより実現しているが、本発明はこれに限定されない。例えばこれらの機能を専用のハードウェアとして実現してもよい。すなわち、XML文書検索装置400が、XML文書分析装置、構造パス分析装置、要素探索装置を備える構成でもよい。
補助記憶装置403は、情報を永続的に保持することが可能な装置であり、例えばHDD(Hard Disk Drive)等が考えられる。リムーバブルドライブ404は、リムーバブルメディアへのデータの書込処理及び読出処理を実行する装置である。リムーバブルメディアには、CD−ROM、DVDなどの光学ディスク、フロッピー(登録商標)ディスクなどの磁気ディスクが含まれる。
ユーザインタフェース406は、XML文書検索装置400の利用者が、データの入力と処理結果の出力に使用するインタフェースである。ユーザインタフェース406は、ディスプレイ装置、キーボード及びマウスなどが含まれる。ネットワークインタフェース407は、ネットワーク440を介して外部装置と接続するためのインタフェースである。
次に、XML文書検索装置400の具体的な処理内容を説明する。ただし、以下の説明では、XML文書集合420は、補助記憶装置403に格納されているものとする。
[前処理時の構成間連携]
図5に、本形態例に係るXML文書検索装置100がXML文書を前処理する際の各構成間の連携動作を示す。
まず、XML文書検索装置400の利用者が、ユーザインタフェース406を用いて、処理の開始を指示する(ステップS101)。
処理の開始指示を受け付けたCPU401は、補助記憶装置403からXML文書集合420を読み出す(ステップS102)。読み出されたXML文書集合420は、主記憶装置402に格納される。
次に、XML文書分析部410(CPU401)は、XML文書集合420に含まれる各XML文書を分析し、パストライ421、数列化されたDOM木422、テキストデータ424を生成する(ステップS103)。この後、CPU401は、パストライ421、数列化されたDOM木422、テキストデータ424を補助記憶装置403に出力する(ステップS104)。
なお、ステップS101では、利用者が、XML文書集合420を直接入力してもよい。この場合には、ステップS102の省略が可能である。XML文書集合420は、外部記憶装置430から読み出してもよい。
[前処理の概要]
図6に、本形態例に係るXML文書検索装置400が検索前に実行する前処理の流れを説明するフローチャートを示す。
CPU401は、XML文書集合420が入力されると、XML文書分析部410による分析処理を実行する(ステップS201)。XML文書分析部410は、XML文書集合420に含まれる各XML文書を分析し、パストライ421、数列化されたDOM木422、テキストデータ424を生成する。XML文書分析部410が実行する前処理の詳細については後述する。処理が終了すると、CPU401は、パストライ421、数列化されたDOM木422、テキストデータ424を、補助記憶装置403に出力する(ステップS202)。
[数列化されたDOM木]
図7を参照し、XML文書分析部410が生成する、数列化されたDOM木422の例を説明する。なお、図7には、パストライ421の例も表している。DOM木に出現する各ノードの接続関係(すなわち、DOM木の形状)は、数列Sに記録される。数列Sには、次のルールに従って数値が格納される。
・各文書に対応する情報(部分数列)は、数値0で開始される。
・各文書に対応する情報(部分数列)を構成する数値は、XML文書を先頭から順に読み出す場合に発見される開始タグに対応する要素の深さ位置を表す。なお、テキストについては、前述した通り、タグ名が「#」である開始タグ・終了タグに囲まれている場合と同様の処理を行なう。
図7に示す例の場合、第1のXML文書(上段左側)を先頭から読むと、<a>、「テキスト1」、<b>、「テキスト2」、</b>、<c>、「テキスト3」、</c>、</a>の順にタグやテキストが出現する。終了タグ以外の要素の深さは、1,2,2,3,2,3である。従って、数列Sには、XML文書の先頭を表す0を考慮すると、0,1,2,2,3,2,3が追加される。同様に、第2のXML文書(上段右側)については、0,1,2,3,2,2,3が追加される。
このように、数列Sは、DOM木の形状を記録することができる。ただし、検索用データとして使用するには、タグの種類で特定される情報(パス種別)も必要である。そこで、任意の構造パスに割り当てた番号で識別されるパス種別を、深さ別のDOM木構造に対応する数列T[d]に記録する。パス種別を与える数値は、同じ深さを有する構造パスに対して一意に割り当てられた番号である。
パス種別の番号は、パストライ421に基づいて記録される。パストライ421とは、XML文書集合420を構成する全てのXML文書について出現する構造パスの全てを含むように構築された木構造のデータである。パストライ421は、公知の方法(例えば非特許文献4)により構築することができる。本形態例の場合、パストライ421の構築時に新規ノードを追加する必要が生じた場合、その新規ノードに新たなパス種別の番号を割り当てる処理機能を、公知の構築機能に追加する。番号の割り当て方法については後述する。図7の場合、括弧で囲まれた数値703が、パス種別の番号に相当する。
[数列SとTの生成]
図8に、本形態例に係るXML文書分析部410において実行される分析動作の詳細を示す。この分析動作において、数列Sと数列T[d]が作成される。
まず、XML文書分析部410は、数列S,T[1],…,T[D]を空の数列に初期化する(ステップS300)。ここでの[D]は、XML文書集合420で最も深い位置の要素の深さを表している。また、XML文書分析部410は、配列Rの要素R[1],…,R[D]を全て「1」に初期化する(ステップS300)。また、XML文書分析部410は、パストライ421を、ルートノード701(図7)のみを持つように初期化する。
次に、XML文書分析部410は、XML文書集合420に含まれる全ての文書の処理が完了したか否かを判定する(ステップS301)。肯定結果が得られるまで、後述するステップS302〜S309の処理が繰り返し実行される。
ステップS301で否定結果が得られた場合、XML文書分析部410は、未処理の文書を読み込む(ステップS302)。以下、この文書をXとする。ステップS302において、XML文書分析部410は、数列Sに文書の先頭を表す「0」を追加する。また、XML文書分析部410は、変数dを用意し、初期値として「0」をセットする。さらに、XML文書分析部410は、変数vを用意し、パストライのルートノード701を指すように初期化する。
次に、XML文書分析部410は、文書Xを最後まで読んだか否か判定する(ステップ303)。肯定結果が得られるまで、後述するステップS304〜S309が繰り返し実行される。
ステップS303で否定結果が得られると、XML文書分析部410は、現在の読み位置にあるタグが「終了タグ」か否か判定する(ステップS304)。肯定結果が得られた場合、XML文書分析部410は、変数vをパストライ421上で親ノードを指すように変更し、変数dから1を減じる(ステップS304−1)。そして、XML文書分析部410は、読み位置を終了タグの直後まで進め、ステップS304に戻る。
ステップS304で否定結果が得られた場合、XML文書分析部410は、文書Xにおいて、現在の読み位置が「タグ」でなく「テキスト」であるか否かを判定する(ステップS305)。肯定結果が得られた場合、XML文書分析部410は、そのテキストを読み込み、その内容をテキストデータ424に追加する(ステップS305−1)。さらに、XML文書分析部410は、変数tに「#」をセットし、ステップS307に進む(ステップS305−1)。
ステップS305で否定結果が得られた場合、XML文書分析部410は、開始タグを読み、その直後まで読み位置を進める。また、XML文書分析部410は、この開始タグのタグ名を、変数tにセットする(ステップS306)。
ステップS305−1の後又はステップS306の後、XML文書分析部410は、パストライ421上のノードvに、タグ名が変数tの値に一致する子ノードv’が存在するか否か判定する(ステップS307)。否定結果が得られた場合、XML文書分析部410は、新規に子ノード(以下「v’」という)を作成し、v’のパス種別をR[d]の値とした後、R[d]に1を加える(ステップS307−1)。
ステップS307で肯定結果が得られた場合、XML文書分析部410は、vの子ノードv’を指すように変数vを更新し、変数dに1を加える(ステップS308)。
ステップS307−1の後又はステップS308の後、XML文書分析部410は、数列Sに変数dの値を追加し、さらに数列T[d]に更新された変数vのパス種別を追加し、ステップS303に戻る(ステップS309)。
[検索動作時の構成間連携]
図9に、本形態例に係るXML文書検索装置400がXML文書を検索する際の各構成間の連携動作を示す。
まず、XML文書検索装置400は、検索に使用するパストライ421と数列化されたDOM木422を、補助記憶装置403から主記憶装置402に予め読み出す(ステップS401)。これらのデータは、前述した前処理により事前に作成されたデータである。
XML文書検索装置400の利用者が、ユーザインタフェース406を通じ、検索クエリとしての構造パスを投入する(ステップS402)。検索クエリを受け取ったCPU401は、パストライ421を使用し、XML文書集合420において、検索クエリに含まれる構造パスに該当する要素の深さdとパス種別tを計算する(ステップS403)。
次に、要素探索部413(CPU401)は、数列化されたDOM木422を使用し、検索クエリに含まれる構造パスに合致する要素番号をすべて列挙する(ステップS404)。その後、CPU401は、得られた要素番号をユーザへ送信する(ステップS405)。
[検索動作の詳細]
図10に、本形態例に係るXML文書検索装置400がXML文書を検索する際の処理の流れを示す。なお、CPU401は、検索に用いるパストライ421、数列化されたDOM木422、テキストデータ424を、補助記憶装置403から主記憶装置402に事前に読み出しているものとする。
まず、ユーザがユーザインタフェース406を通じ、検索クエリとしての構造パスをXML文書検索装置400に投入する。この後、構造パス分析部412は、XML文書集合420について作成されたパストライ421にアクセスし、検索クエリとして指定された構造パスに該当する要素の深さdとパス種別tを計算する(ステップS501)。
次に、要素探索部413は、数列化されたDOM木422にアクセスし、当該構造パスに該当する要素の番号を列挙する(ステップS502)。
図11に、前述した検索処理の概要を示す。図11は、検索クエリとして、「/a/b」で表される構造パスが与えられた場合について、この構造パスが出現する要素の番号を計算する概念を表している。
この構造パスは、「/a/b」でbが2番目のタグ名なので、深さが「2」である。さらに、パストライ421において、ルートノード701から「a」、「b」と辿っていくと、「b(2)」と書かれたノードに到達する。「(2)」は、このノードのパス種別が「2」であることを表している。従って、「/a/b」の出現位置を全て知るためには、深さ「2」にあるパス種別が「2」の要素の全てについて、要素番号を計算すればよい。そのために、後述するrank演算及びselect演算を実行する。
(1)rank(A,c,i)=数列Aのi番目までの要素にあるcの数
(2)select(A,c,j)=数列Aにj番目に出現するcの位置
図12に、rank演算およびselect演算の例を示す。図12の例の場合、数列Xの10番目までの要素にある「3」の数を与えるrank(X,3,10)は「2」である。また、数列Xについて「3」が2番目に出現する位置を与えるselect(X,3,2)は「7」である。
図11の説明に戻る。前述の「/a/b」を検索する処理動作は、深さが「2」でパス種別が「2」の要素を抽出する処理である。
まず、深さが「2」でパス種別が「2」の要素の総数nは、n=rank(T[2],2,|T[2]|)により計算することができる。ただし、|T[d]|は、数列T[d]の要素数である。
次に、1≦k≦nである全ての整数kについて、k’=select(T[2],2,k)を計算する。この計算で得られる値k’の集合は、深さが「2」の要素に限定した場合、パス種別が「2」の要素が何番目に出現するかを表している。図11の例では、2番目と6番目である。
さらに、k”=select(S,2,k’)を計算すれば、検索対象であるXML文書集合420のDOM木の形状を現す数列Sにおいて、深さが「2」の要素の中でk’番目に出現する要素が全体の何番目に位置するかを計算することができる。図11の例では、4番目と13番目である。この「4」と「13」が、要素探索部413の検索結果となる。
[構造パスの分析動作]
図13に、構造パス分析部412が実行する構造パスの分析動作を示す。ここでは、構造パスに含まれる左からd番目のタグ名をP[d],タグの総数を|P|とする。
まず、構造パス分析部412は、変数vをパストライ421のルート701にセットし、変数dを「0」にセットする(ステップS601)。
次に、構造パス分析部412は、d≧|P|か否かを判定する(ステップS602)。ステップS602で肯定結果が得られるまで、構造パス分析部412は、ステップS603〜S605の処理を繰り返す。因みに、肯定結果が得られた場合(d≧|P|の場合)、構造パス分析部412は、深さを与える情報として「d」を出力し、パス種別703を与える情報として変数vが指すノードのパス種別を出力し、分析処理を終了する(ステップS606)。
これに対し、ステップS602で否定結果が得られた場合、構造パス分析部412は、変数dに「1」を加える(ステップS603)。
続いて、構造パス分析部412は、変数vの指すノードの子にタグ名がP[d]のものがあるか否か判定する(ステップS604)。否定結果が得られた場合(子が存在しない場合)、構造パス分析部412は、「当該構造無し」と出力し、検索処理自体を終了する(ステップS607)。
一方、ステップS604において肯定結果が得られた場合(子が存在する場合)、構造パス分析部412は、変数vをタグ名がP[i]である子に変更する(ステップS605)。
[要素探索動作]
図14に、要素探索部413において実行される検索動作の詳細を示す。
要素探索部413はまず変数nに、深さがdであり、かつ、パス種別がtである要素の「総数」をセットする。この総数は、rank(T[d],t,|T[d]|)の計算値として与えられる。さらに、要素探索部413は、変数kを初期値「0」にセットする。
次に、要素探索部413は、k>nか否かを判定する(ステップS702)。肯定結果が得られるまで、要素探索部413は、後述するステップS703〜S706の処理を繰り返し実行する。
要素探索部413は、検索クエリに合致する次の要素が、深さdの要素の中で何番目に位置するかを、select(T[d],t,k)により計算し、計算結果を変数k’にセットする(ステップS703)。
次に、要素探索部413は、検索クエリに合致する次の要素(ステップS703と同じ要素)が、XML文書全体に対応する数列Sの何番目の要素に位置するかを、select(S,d,k’)により計算し、計算結果を変数k”にセットする(ステップS704)。
要素探索部413は、変数k”の値を出力する(ステップS705)。
この後、要素探索部413は、変数kに「1」を加え、ステップS702に戻る(ステップS706)。
[計算処理の高速化]
前述の処理により構造パスに合致するXML要素の計算を高速化するには、rank演算とselect演算を高速に処理する必要がある。
まず、本形態例の場合、rank演算は、ステップS701において、T[d]に値tが幾つあるかを数えるためにしか使用しない。処理の高速化のため、本実施例では、数列化されたDOM木422を補助記憶装置403から読み出す際に、予め深さ別に各要素が何回出現したかを数え、パス種別(値t)の順に当該構造パスの出現回数を並べた2次元配列N 702(図7)を作成する。Nのうち、特定の深さdに対応する配列N[d]の内容は、(T[d]における値1の数、値2の数、…、値tの数、…)で与えられる。例えば図7の場合、深さが「2」のパス種別の構造を表す数列T[2]には、値1が2回、値2が2回、値3が1回、値4が1回出現する。このため、2次元配列Nのd=2の部分はN[2]=(2,2,1,1)のように作成される。
続く、ステップS703のselect演算では、kの値が1、2、3、…と順に変化し、T[d]において値がtとなる箇所を順に計算する。この処理は、単純に数列T[d]を先頭から順に読み、値tが出現する箇所を計算することで実現できる。数列T[d]に値tが頻出すれば、この処理の計算効率は十分に良い。ただし、数列T[d]に値tが頻出しない場合は、数列を走査する処理時間が性能劣化を招く可能性がある。従って、数列T[d]に値tが頻出しないことが予測される場合には、後述する第2の形態例で説明する手法を用いることが好ましい。なお、繰り返し回数nは上述の方法で計算してステップS702で用いても良いが、k>nかを判定する代わりに、数列T[d]の要素をすべて読み終わった時点で要素探索部413を終了する手法を採用してもよい。
ステップS704のselect演算についても、やはり数列を先頭から順番に読み、値dがk’(=select(T[d],t,k))回目に出現する位置を求めることで計算できる。
ここで、1<k≦nならば、k’=select(T[d],t,k)の値が、kについて単調に増加する。このため、次の不等式が成立する。
select(T[d],t,k−1)<select(T[d],t,k)
同様に、select(S,d,k’)の値も、k’について単調に増加する。このため、次の不等式が成立する。
select(S,d,select(T[d],t,k−1))
< select(S,d,select(T[d],t,k))
このため、ステップS704では、前回出力した値であるselect(S,d,select(T[d],t,k−1))を保存しておき、その位置から数列Sを走査してselect(S,d,select(T[d],t,k))を計算すれば、計算時間を短縮することができる。
[変形例]
本実施形態で例示した種々のソフトウェアは、電磁的、電子的及び光学式等の種々の記録媒体に格納可能であり、インターネット等の通信網を通じて、コンピュータにダウンロード可能である。
以上の説明では、数列化されたDOM木422の全体を主記憶装置402に読み込んで処理する方法を説明した。しかし、実際の運用では、主記憶装置402に入りきらない膨大なデータを処理可能とするため、データを補助記憶装置403に配置し、処理に必要な箇所をその都度、主記憶装置402へ読み込むことが好ましい。
[第1の形態例の効果]
本形態例に係るXML文書検索装置400を用いれば、XPathにより記述された検索クエリによるXML文書の検索処理を高速化することができる。
[第2の形態例]
[Wavelet木]
数列をコンパクトに圧縮し、さらにデータを圧縮したままでrank演算及びselect演算を効率よく計算できるデータ構造として、Wavelet木が知られている(例えば、Navarro, G. and Makinen, V., Compressed full-text indexes, ACM Computing Surveys 39(1): Article 2, 2007.)。
Wavelet木は、0と1の任意の並びであるビットベクトルと呼ばれるデータ構造を用いて構築される。ビットベクトルの例を、図15に示す。ビットベクトルを数列と見たときに効率よくrank演算及びselect演算を行うために、一定間隔でrank演算及びselect演算の結果をサンプリングし格納するとともに、サンプリングされていない箇所の値は、短いビットベクトルのrank演算及びselect演算の結果を事前計算して格納した1501のような表を併用し、高速に計算する手法が知られている(例えば非特許文献5を参照)。
図16に、数列S「012223230123223」に対するWavelet木の構造例を示す。Wavelet木は、木のノードにビットベクトルを格納し、全体として数列と同等の情報を記録できるデータ構造である。
ルートノード1601には、数列に格納された値を2つのグループに分割するとき、各値がどちらのグループに属すかを記録したビットベクトルB1が格納される。図16の例では、値が「2」であるか、「2」でないかでグループ分けを行っている。ルートノード1601の下にあるノード1602では、ルートノードでグループ分けされた「2」以外の値を、さらにグループ分けし、「3」であるか、「3」でないかでグループ分けしたビットベクトルB2が格納されている。同様に、その下のノード1603は、残った「0」と「1」を区別している。
Wevelet木に対するrank演算は、ルートノード1601から木を辿ることによって行う。例えばrank(S,3,7)を計算する場合を説明すると以下のようになる。
まず、「3」はルートノード1601では、「1」にグループ分けされている。このため、rank(B1,1,7)を計算し、「4」を得る。この結果は、数列Sの7番目までに0,1,3が計4個あることを意味する。
次のビットベクトルB2では、「3」が「1」にグループ分けされている。このため、rank(B2,1,4)を計算し、「2」を得る。この結果は、数列Sの7番目までに出現する4個の0,1,3のうち、「3」が計2個であることを表す。このように、rank(S,3,7)の結果として、正しく「2」が計算できたことが分かる。
これに対し、select演算は、リーフからルートノードに木を辿ることによって計算する。例えばselect(S,3,2)を計算する場合を説明すると以下のようになる。
まず、「3」を表すリーフの親ノードであるノード1602において、2番目の「3」に該当する位置を計算する。「3」は、ノード1602において、「1」にグループ分けされている。このため、select(B2,1,2)を計算すると、「4」が得られる。この結果は、2番目の「3」が、0,1,3だけを取り出した部分数列では4番目の値であることを意味する。
さらに、この値が数列Sの中で何番目に位置するかを求めるには、select(B1,1,4)を計算すれば良い。この場合、「7」が得られる。この結果は、0、1又は3が4番目に現れる位置が全体では7番目の値であることを表す。すなわち、この「7」がselect(S,3,2)の計算結果となる。
このように、Wavelet木を用いると、ビットベクトルに対するrank演算やselect演算を、最大でも木の高さに等しい回数分の処理の繰り返しにより実現できる。すなわち、最大でも木の高さに等しい計算処理の回数の実行により、数列に対するrank演算及びselect演算の解を得ることができる。
Wavelet木の高さは、数列の長さよりも遥かに小さな値であり、特に数列の長さが非常に長く、rank演算又はselect演算の第二引数の値の出現頻度が小さいとき、数列を直接走査する場合に比して効率がよい。また、Wavelet木は、格納される数列において各値の出現頻度に偏りがあると、圧縮が可能であることが知られている。
[装置構成]
本形態例では、第1の形態例において、rank演算及びselect演算を実行していた箇所に、Wavelet木を適用する手段を提供する。
図17に、本形態例に係るXML文書検索装置1700のブロック構成を示す。図17には、図4との対応部分に同一符号を付して示している。XML文書検索装置1700は、Wavelet木構築部411と、Wavelet木群423を有する点で、第1の形態例と異なる。
図18に、本形態例に係るXML文書検索装置1700がXML文書を前処理する際の各構成間の連携動作を示す。
まず、XML文書検索装置400の利用者が、ユーザインタフェース406を用いて、処理の開始を指示する(ステップS801)。
処理の開始指示を受け付けたCPU401は、補助記憶装置403からXML文書集合420を読み出す(ステップS802)。読み出されたXML文書集合420は、主記憶装置402に格納される。
次に、XML文書分析部410(CPU401)は、XML文書集合420に含まれる各XML文書を分析し、パストライ421、数列化されたDOM木422、テキストデータ424を生成する(ステップS803)。ここまでは、第1の形態例と同じである。
Wavelet木構築部411は、XML文書分析部410が生成した数列化されたDOM木422に含まれる各数列を、Wavelet木群423に変換する(ステップS804)。Wavelet木構築部411は、公知の方法(例えば非特許文献5を参照)を使用し、数列化されたDOM木422をWavelet木群423に変換する。そして、数列化されたDOM木422に代わり、Wavelet木群423を補助記憶装置に出力し、同様にパストライ421、テキストデータ424も出力する(ステップS805)。数列化されたDOM木422は、Wavelet木群423を構築した後に消去してもよい。
[前処理の概要]
図19に、本形態例に係るXML文書検索装置400が検索前に実行する前処理の流れを説明するフローチャートを示す。
CPU401は、XML文書集合420が入力されると、XML文書分析部410による分析処理を実行する(ステップS901)。XML文書分析部410は、XML文書集合420に含まれる各XML文書を分析し、パストライ421、数列化されたDOM木422、テキストデータ424を生成する。
この処理が終了すると、CPU401は、前述したようにWavelet木群423を構築する(ステップS902)。
この後、CPU401は、パストライ421、Wavelet木群123、テキストデータ424を補助記憶装置403に出力する(ステップS903)。
[検索処理]
本形態例に係るXML文書検索装置1700は、検索の際、まず、パストライ421およびWavelet木群423を補助記憶装置403から読み出す。前述の通り、数列化されたDOM木422は不要である。
検索動作は、第1の形態例と同様、図14に従って実行される。第1の形態例との違いは、検索クエリである構造パスが与えられた後に実行されるステップS701(図14)のrank演算と、ステップS703(図14)及びS704(図14)のselect演算にWavelet木を用いる点と、2次元配列N702(図7)が不要な点である。ただし、rank演算よりも配列参照の処理の方が速いため、本形態例の場合にも、2次元配列N702を使用してもよい。
[第2の形態例の効果]
本形態例に係るXML文書検索装置1700を用いれば、数列T[d]に値tが頻出しない場合にも、XPathにより記述された検索クエリによるXML文書の検索処理を高速に実行することができる。
[第3の形態例]
XPathによる検索では、親要素、子要素、兄弟要素等に関する制約条件が検索クエリに盛り込まれる場合がある。そこで、本形態例では、親要素、子要素、兄弟要素等を探索する機能と、任意の2つの要素i、jが、指定された関係にあるか否かを検査するための機能について説明する。以下の説明では、要素i、jの深さをdi、djとし、パス種別をそれぞれti、tjとする。
(1)要素iの親要素の計算
深さdi≦1の場合、要素iの親要素は存在しない。それ以外の場合、親要素は深さがdi−1で与えられる、i未満でiに最も近い要素番号の要素である。従って、親要素の要素番号は、select(S,di−1,rank(S,di−1,i))を計算することにより取得することができる。
(2)要素iの最初の子要素の計算
子要素が存在すれば、要素番号はi+1で与えられる。ただし、子要素が存在しない場合があり、その場合、要素番号i+1の要素の深さはdi+1以外である。第1の形態例で述べたように数列化されたDOM木422を使用している場合はS[i+1]=di+1か否かを判定すればよいが、第2の形態例で述べたようにWavelet木群423しか使用できない場合は、rank(S,di+1,i+1)=rank(S,di+1,i)+1か否かを判定すればよい。後者の場合CPU401は、図20に示す処理手順により、子要素の存在を判定し(ステップS1001)、存在する場合にはその要素番号i+1を出力し(ステップS1002)、存在しない場合には「子要素無し」と出力する(ステップS1003)。
(3)要素iの兄弟要素の計算
要素iよりも前に兄弟要素が存在する場合、1つ前の兄弟要素は、要素iと同じ深さdiであり、i未満でiに最も近い要素番号の要素となる。従って、その要素番号jは、j=select(S,di,rank(S,di,i−1))として与えることができる。
これに対し、要素iよりも後に兄弟要素が存在する場合、1つ後の兄弟要素は、要素iと同じ深さdiであり、iより大きくiに最も近い要素番号の要素となる。従って、その要素番号jは、j=select(S,di,rank(S,di,i)+1)として与えることができる。
一方、そのような兄弟要素が存在しない場合、いずれの場合にも、要素iと要素jの間には、i及びjのいずれか一方だけの親要素が存在する。よって、rank(S,di−1,i)=rank(S,di−1,j)ならばjは兄弟要素であり、それ以外の場合は当該兄弟要素が存在しないことになる。
この判定処理をフローチャートで表すと図21及び図22となる。図21は、1つ前の兄弟要素を探すためのフローチャートであり、図22は、1つ後の兄弟要素を探すためのフローチャートである。
まず、図21に示すフローチャートについて説明する。前述したように、1つ前の兄弟要素jは、要素iと同じ深さdiであり、i未満でiに最も近い要素番号の要素となる。従って、ステップS1101では、j=select(S,di,rank(S,di,i−1))を計算する。次に、要素iの深さdiよりも1つ浅い深さについてi番目までの数(=rank(S,di−1,i)と、j番目までの数(=rank(S,di−1,i)を比較する(ステップS1102)。2つの値が同じであれば、同じ親要素の子なのでステップS1101で計算されたjを出力する(ステップS1103)。2つの値が異なれば、兄弟要素無しと出力する(ステップS1104)。
次に、図22に示すフローチャートについて説明する。前述したように、1つ後の兄弟要素jは、要素iと同じ深さdiであり、iより大きくiに最も近い要素番号の要素となる。従って、ステップS1201では、j=select(S,di,rank(S,di,i)+1)を計算する。次に、要素iより1つ浅い深さについてi番目までの数(=rank(S,di−1,i)と、j番目までの数(=rank(S,di−1,j)を比較する(ステップS1202)。2つの値が同じであれば、同じ親要素の子なのでステップS1201で計算されたjを出力する(ステップS1203)。2つの値が異なれば、兄弟要素無しと出力する(ステップS1204)。
(4)要素iが要素jの親か否かの判定
上記(1)の方法で要素jの親要素を計算し、計算された親要素の値が要素iに一致するか否かで判定する。
(5)要素iがjの先祖であるか否かの判定
以下の条件を同時に満たせば先祖であり、そうでなければ先祖でないと判定する。
(5−1) i<j
この条件を満たせば、要素iの開始タグは、要素jの開始タグよりも先に出現する。
(5−2) rank(S,i,di)=rank(S,j,di)
この条件を満たせば、要素iと要素jの間には、深さがdi以下である要素i以外の要素はない。
(6)要素i、jが兄弟要素であるか否かの判定
要素iと要素jの親要素を計算し、一致するか否かを判定する。
rank(S,i,di−1)=rank(S,j,dj−1)であれば、兄弟要素であると判定してもよい。
[第4の形態例]
XPathに規定されている検索クエリは、複数の構造パスに合致する場合がある。例えば、「/a//text()」という検索クエリは、タグ名が「a」であるルート要素の子孫であるテキストノードの全てに合致する。このような検索クエリが与えられた場合、パストライ上でクエリに合致する構造パスを全て計算し、それらの検索結果の和集合を取ればよい。
[第5の形態例]
XPathに規定されている検索クエリは、テキストに関する条件を含む場合がある。例えば「”/a//text()[contains(.,”abc")]」という検索クエリは、タグ名が「a」であるルート要素の子孫であるテキストで"abc"を含むものに合致する。このような検索クエリが与えられた場合、前述したXML要素に関する検索結果と、テキストデータ424に対するテキスト検索の結果を照合し、両方の条件に合致する箇所を検索結果とすればよい。
テキスト検索の処理には、公知の任意の手法が使用できる(例えば非特許文献6を参照)。
[他の形態例]
前述の形態例は、本発明の適用例を例示したものであり、本発明の技術的範囲を前述した各形態例の具体的構成に限定する趣旨ではない。本発明の要旨を逸脱しない範囲において種々の変更可能である。例えば本発明は、前述した各形態例の全ての構成要素を備える必要はない。また、ホン発明は、ある形態例の一部を他の形態例の構成に置き換えることもでき、ある形態例の構成に他の形態例の構成を加えることもできる。
また、上述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路その他のハードウェアとして実現しても良い。また、各処理機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、SSD(Solid State Drive)等の記憶装置、ICカード、SDカード、DVD等の記憶媒体に格納することができる。
400 XML文書検索装置
401 CPU
402 主記憶装置
403 補助記憶装置
404 リムーバブルドライブ
406 ユーザインタフェース
407 ネットワークインタフェース
410 XML文書分析部
411 Wavelet木構築部
412 構造パス分析部
413 ノード探索部
420 XML文書集合
421 パストライ
422 数列化されたDOM木
423 Wavelet木
424 テキストデータ
430 外部記憶装置
440 ネットワーク
1700 XML文書検索装置

Claims (8)

  1. プロセッサと、主記憶装置と、XML文書を入出力する入出力装置とを有し、検索クエリとして、XML文書の要素及びその要素の祖先要素をルート要素から順にすべて列挙したものである構造パスが与えられたとき、その構造パスに合致する箇所を探索するXML文書検索装置において、
    前記入出力装置は、検索対象のXML文書集合の入力を受け付け、
    前記XML文書検索装置は、
    前記XML文書を分析し、タグの種類および包含関係を認識し数列群に変換するとともにパストライを構築するXML文書分析部と、
    前記パストライを用いて、検索クエリである構造パスの深さおよびパス種別を計算する構造パス分析部と、
    前記構造パスの深さ及びパス種別に基づき、検索クエリである構造パスに合致する要素が出現する箇所を計算する要素探索部とを有し、
    前記XML文書分析部は、
    XML文書のDOM木の形状を記録するために、XML文書の出現する要素の出現順に、当該要素の深さを表す数値の列を部分列として含む第一の数列Sと、
    前記DOM木の各ノードに対応する構造パスの種類を記録する1つ以上の数列からなる数列群Tとを作成し、数列群Tに含まれる数列T[d]が深さdである構造パスの種類を記録したものであるとき、
    前記要素探索部は、
    前記数列Sと、前記数列群Tを走査することにより、検索クエリである構造パスに合致する箇所を計算する
    ことを特徴とするXML文書検索装置。
  2. 請求項1に記載のXML文書検索装置において、
    前記要素探索部は、
    数列Aにおいてj番目に値cが出現する位置をselect(A,c,j)と表記し、この値を計算する処理をselect演算と呼び、前記検索クエリの構造パスの深さをd、パス種別をtとし、当該構造パスの出現総数をnとするとき、1≦k≦nである整数kに対し、式(1)を適用して得られるk”の値を計算することにより、前記検索クエリに合致する箇所を前記XML文書集合から探索する
    ことを特徴とするXML文書検索装置。
    [数1]
    k”=select(S,d,select(T[d],t,k)) …式(1)
  3. 請求項2に記載のXML文書検索装置において、
    前記XML文書分析部の処理に引き続き、前記数列S及び前記数列群Tに含まれる各数列をWavelet木に変換するWavelet木構築部を有し、
    前記select演算に、前記Wavelet木を用いる
    ことを特徴とするXML文書検索装置。
  4. 請求項1に記載のXML文書検索装置において、
    XML文書のDOM木の形状を記録するために、XML文書の出現する要素の出現順に、当該要素の深さを表す数値の列を部分列として含む数列を構築する手段を有し、
    前記数列Sにおいてi番目までにある値cの数をrank(S,c,i)と表記し、この値を計算する処理をrank演算と呼び、
    数列Sにおいてj番目に値cが出現する位置をselect(S,c,j)と表記し、この値を計算する処理をselect演算と呼び、
    前記数列においてi番目の値に対応するXML文書の要素に対し、その要素の構造パスの深さをdとするとき、
    前記要素の親である要素の番号を式(2)によって計算し、
    前記要素の最初の子である要素の番号を式(3)によって計算し、
    前記要素に最も近い先行する兄弟要素の番号を式(4)によって計算し、
    前記要素に最も近い後続の兄弟要素の番号を式(5)によって計算する
    ことを特徴とするXML文書検索装置。
    [数2]
    select(S,d−1,rank(S,d−1,i)) …式(2)
    [数3]
    i+1 …式(3)
    [数4]
    select(S,d,rank(S,d,i−1)) …式(4)
    [数5]
    select(S,d,rank(S,d,i)+1) …式(5)
  5. 請求項4に記載のXML文書検索装置において、
    前記XML文書分析部の処理に引き続き、前記数列Sおよび前記数列群Tに含まれる各数列をWavelet木に変換するWavelet木構築部を有し、
    前記rank演算及び前記select演算に、前記Wavelet木を用いる
    ことを特徴とするXML文書検索装置。
  6. 検索クエリとして、XML文書の要素及びその要素の祖先要素をルート要素から順にすべて列挙したものである構造パスが与えられたときに、その構造パスに合致する箇所を探索する処理をコンピュータに実行させるプログラムにおいて、
    前記プログラムは、
    前記XML文書を分析し、タグの種類および包含関係を認識し数列群に変換しパストライを構築する第1の処理と、
    前記パストライを用いて、検索クエリである構造パスの深さおよびパス種別を計算する第2の処理と、
    前記構造パスの深さ及びパス種別に基づき、検索クエリである構造パスに合致する要素が出現する箇所を計算する第3の処理とを前記コンピュータに実行させ、
    前記第1の処理は、
    XML文書のDOM木の形状を記録するために、XML文書の出現する要素の出現順に、当該要素の深さを表す数値の列を部分列として含む第一の数列Sと、DOM木における各ノードに対応する構造パスの種類を記録する1つ以上の数列からなる数列群Tとを作成し、数列群Tに含まれる数列T[d]が深さdである構造パスの種類を記録したものであるとき、
    前記第3の処理は、
    前記数列Sと、前記数列群Tを走査することにより、検索クエリである構造パスに合致する箇所を計算する
    ことを特徴とするプログラム。
  7. 請求項6に記載のプログラムにおいて、
    前記第3の処理は、
    数列Aにおいてj番目に値cが出現する位置をselect(A,c,j)と表記し、この値を計算する処理をselect演算と呼び、前記検索クエリの構造パスの深さをd、パス種別をtとし、当該構造パスの出現総数をnとするとき、1≦k≦nである整数kに対し、式(6)を適用して得られるk”の値を計算することにより、前記検索クエリに合致する箇所を前記XML文書集合から探索する
    ことを特徴とするプログラム。
    [数6]
    k”=select(S,d,select(T[d],t,k)) …式(6)
  8. 請求項7に記載のプログラムにおいて、
    前記第1の処理に引き続き、前記数列S及び前記数列群Tに含まれる各数列をWavelet木に変換する第4の処理を有し、
    前記select演算に、前記Wavelet木を用いる
    ことを特徴とするプログラム。
JP2012039242A 2012-02-24 2012-02-24 Xml文書検索装置及びプログラム Expired - Fee Related JP5695586B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012039242A JP5695586B2 (ja) 2012-02-24 2012-02-24 Xml文書検索装置及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012039242A JP5695586B2 (ja) 2012-02-24 2012-02-24 Xml文書検索装置及びプログラム

Publications (2)

Publication Number Publication Date
JP2013175053A JP2013175053A (ja) 2013-09-05
JP5695586B2 true JP5695586B2 (ja) 2015-04-08

Family

ID=49267899

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012039242A Expired - Fee Related JP5695586B2 (ja) 2012-02-24 2012-02-24 Xml文書検索装置及びプログラム

Country Status (1)

Country Link
JP (1) JP5695586B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6893480B2 (ja) 2018-01-18 2021-06-23 株式会社日立製作所 分析装置および分析方法
CN108650250B (zh) * 2018-04-27 2021-07-23 奇安信科技集团股份有限公司 非法页面检测方法、系统、计算机系统和可读存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3492246B2 (ja) * 1999-07-16 2004-02-03 富士通株式会社 Xmlデータ検索処理方法および検索処理システム
JP4562130B2 (ja) * 2005-02-21 2010-10-13 日本電信電話株式会社 Xmlデータ処理装置、xmlデータ処理方法、xmlデータ処理プログラムおよびxmlデータ処理プログラムを記録した記憶媒体
JP4314221B2 (ja) * 2005-07-28 2009-08-12 株式会社東芝 構造化文書記憶装置、構造化文書検索装置、構造化文書システム、方法およびプログラム
JP4649339B2 (ja) * 2006-01-20 2011-03-09 日本電信電話株式会社 XPath処理装置、XPath処理方法、XPath処理プログラム、および、記憶媒体
WO2010106681A1 (ja) * 2009-03-19 2010-09-23 富士通株式会社 データベース検索プログラムを記録するコンピュータ読取可能な記憶媒体、データベース検索装置、および、データベース検索方法

Also Published As

Publication number Publication date
JP2013175053A (ja) 2013-09-05

Similar Documents

Publication Publication Date Title
JP5121146B2 (ja) 構造化文書管理装置、構造化文書管理プログラムおよび構造化文書管理方法
JP5338238B2 (ja) ワードの類似性を用いたオントロジーの自動生成
CN102033954B (zh) 关系数据库中可扩展标记语言文档全文检索查询索引方法
CN108280114B (zh) 一种基于深度学习的用户文献阅读兴趣分析方法
CN107122443A (zh) 一种基于Spark SQL的分布式全文检索系统及方法
JP5423676B2 (ja) データ分類システム、データ分類方法、及びデータ分類プログラム
US7822788B2 (en) Method, apparatus, and computer program product for searching structured document
CN105335487A (zh) 基于农业技术信息本体库的农业专家信息检索系统及方法
US20120143847A1 (en) Database management method and system
CN118917305B (zh) 一种rag系统优化方法、系统、电子设备及存储介质
JP4839195B2 (ja) Xml文書の適合度の算出方法およびそのプログラムと、情報処理装置
Sunuwar et al. Comparative analysis of relational and graph databases for data provenance: Performance, queries, and security considerations
CN103425719A (zh) 结构化文档检索装置和程序
JP5695586B2 (ja) Xml文書検索装置及びプログラム
JP5869948B2 (ja) パッセージ分割方法、装置、及びプログラム
Iser et al. A problem meta-data library for research in SAT
KR101476225B1 (ko) 자연어 및 수식 색인화 방법과 그를 위한 장치 및 컴퓨터로 읽을 수 있는 기록매체
JP5321258B2 (ja) 情報収集システムおよび情報収集方法ならびにそのプログラム
JP4649339B2 (ja) XPath処理装置、XPath処理方法、XPath処理プログラム、および、記憶媒体
JP5954742B2 (ja) 文書を検索する装置及び方法
US20130246479A1 (en) Computer-readable recording medium, data model conversion method, and data model conversion apparatus
JP2010267081A (ja) 情報検索方法及び装置及びプログラム
JP5764448B2 (ja) 文書ランキングスコアの動的更新のための方法および装置
JP7363914B2 (ja) 検索方法、検索プログラム及び検索装置
JP5485856B2 (ja) 閲覧ログ解析装置及び閲覧ログ解析プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140604

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20141126

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: 20150127

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150206

R151 Written notification of patent or utility model registration

Ref document number: 5695586

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees