JP2006031377A - 構造化文書管理装置、検索装置、記憶方法、検索方法及びプログラム - Google Patents

構造化文書管理装置、検索装置、記憶方法、検索方法及びプログラム Download PDF

Info

Publication number
JP2006031377A
JP2006031377A JP2004208885A JP2004208885A JP2006031377A JP 2006031377 A JP2006031377 A JP 2006031377A JP 2004208885 A JP2004208885 A JP 2004208885A JP 2004208885 A JP2004208885 A JP 2004208885A JP 2006031377 A JP2006031377 A JP 2006031377A
Authority
JP
Japan
Prior art keywords
structured document
data
node
document data
document
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.)
Granted
Application number
JP2004208885A
Other languages
English (en)
Other versions
JP4309818B2 (ja
Inventor
Masakazu Hattori
雅一 服部
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.)
Toshiba Corp
Original Assignee
Toshiba Corp
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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2004208885A priority Critical patent/JP4309818B2/ja
Priority to EP05254160A priority patent/EP1617345A1/en
Priority to US11/182,008 priority patent/US8082492B2/en
Priority to CNB2005100846285A priority patent/CN100565508C/zh
Publication of JP2006031377A publication Critical patent/JP2006031377A/ja
Application granted granted Critical
Publication of JP4309818B2 publication Critical patent/JP4309818B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80Information 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/83Querying
    • G06F16/835Query processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Document Processing Apparatus (AREA)

Abstract

【課題】構造化文書データの検索が高速に行える構造化文書管理装置、検索装置を提供する。
【解決手段】複数の要素を含む各構造化文書データを記憶する記憶手段に新たな構造化文書データを記憶する際には、前記記憶手段で記憶された各構造化文書データ及び前記新たな構造化文書データにそれぞれ含まれている構造を含む汎用構造を求めて、前記新たな構造化文書データの構造と前記汎用構造との差分構造を求め、前記新たな構造化文書データの複数の要素を前記差分構造に基づき並べた配列を前記記憶手段に記憶する。
【選択図】 図1

Description

本発明は、階層化された論理構造をもつ構造化文書データベースに関する。
Extensible markup language(XML)などで記述された構造化文書データを記憶・検索するための構造化文書管理システムには、いくつかの方式が考えられている。
(1)単純な方式として、構造化文書データをそのままテキストファイルとして管理する方式。この方式では、データ数やサイズが大きくなると格納効率が悪くなったり、構造化文書の特性を生かした検索が困難になる。
(2)RDB(Relational Database)に構造化文書データを管理する方式。
(3)構造化文書データを管理するために開発されたOODB(Object Oriented Database)で管理する方式。基幹系などで広くRDBが使われているが、これを拡張した例えばXML対応RDBが製品として出ている。RDBは、データをフラットなテーブル形式に格納するため、XMLデータのような階層構造をテーブルに対応づける複雑なマッピングが必要となる。このマッピングのため、テーブルに関する事前の構造(スキーマ)設計を十分に行わないと、パフォーマンスが低下してしまう問題が発生する。
近年、上記(1)〜(3)以外に新たな方式が提案されている。
(4)ネイティブに構造化文書データを管理する方式。この方式は、多種多様な階層構造を持つXMLデータを特別なマッピング処理すること無しに格納する。このため、格納や取得時に特別なオーバヘッドが存在しない。また、コストのかかる事前のスキーマ設計が不要になり、ビジネス環境の変化により必要に応じてXMLデータの構造を自由に変更することが可能である。
いくら構造化文書データが効率良く格納されたからといって、格納されたデータを取り出す手段が無ければ意味が無い。この格納されたデータを取り出す手段として、問合せ言語がある。RDBの世界ではSQL(Structured Query Language)があるように、XMLではXQuery(XML Query Language)が策定されている。XQueryは、XMLデータをデータベースのように扱うための言語である。このため条件に合致するデータ集合の取り出しや集計・分析を行うための手段が提供されている。また、XMLデータは親子や兄弟などの要素が組み合わさった階層構造を持つため、この階層構造を辿る手段が提供されている。
格納された構造化文書データの階層構造を辿りながら、検索条件で指定された特定の要素と特定の構造が含まれている構造化文書データを検索するための技術は既に開示されている(例えば、特許文献1、2参照)。
構造化文書データの構造が大規模になるほど、データベースに格納されている構造化文書データの数が多いほど、検索条件が複雑なほど、各構造化文書データの階層構造を構成する要素間をたどるという処理には時間がかかる。また、構造化文書データの数、サイズが大きくなれば、格納された構造化文書データをメモリ上に展開することは不可能であり、多くはハードディスクなど二次記憶に格納されることになる。
ネイティブに構造化文書データを管理する方式では、構造化文書データは要素間の階層構造をそのまま記憶する。検索条件として指定された要素や構造があるか否かを調べるためには、二次記憶上に格納された構造化文書データの要素間を頻繁にアクセスしなければならない。複雑な検索条件の場合はなおさらである。
特開2002−34618公報 特開2000−57163公報
従来は、階層構造を有する構造化文書データを記憶するデータベースから所望の要素や構造を有する構造化文書データを検索する際には、データベース内の各構造化文書データの階層構造を構成する要素データ間を辿りながら、検索条件にて指定された要素や構造を持つ構造化文書データを検索するため、高速に検索できないという問題点があった。特に、構造化文書データのサイズが大きくなるほど、検索対象の構造化文書データの数が多いほど、検索条件が複雑であるほど検索処理の高速化が困難であった。
そこで、本発明は上記問題点に鑑み、構造化文書データの検索が高速に行える構造化文書管理装置、検索装置を提供することを目的とする。
複数の要素を含む各構造化文書データを記憶する記憶手段に新たな構造化文書データを記憶する際には、前記記憶手段で記憶された各構造化文書データ及び前記新たな構造化文書データにそれぞれ含まれている各構造を含む汎用構造を求めて、前記新たな構造化文書データの構造と前記汎用構造との差分構造を求め、前記新たな構造化文書データの複数の要素を前記差分構造に基づき並べた配列を前記記憶手段に記憶する。
複数の要素を含む各構造化文書データを記憶する記憶手段に記憶された第1の構造化文書データから、前記所望の要素を検索する際には、前記第1の構造化文書データが前記記憶手段で記憶されるまでに当該記憶手段で記憶された各構造化文書データ及び前記第1の構造化文書データにそれぞれ含まれている各構造を含む汎用構造と、前記第1の構造化文書データの構造との差分構造とから、前記第1の構造化文書データの構造を復元し、復元された構造から前記所望の要素を特定する。
本発明によれば、構造化文書データの検索が高速に行える。
以下、本発明の実施形態について図面を参照して説明する。
図1は、本実施形態に関る構造化文書管理システムの機能的な構成例を示したものである。構造化文書管理システムは、大きく分けてクライアント201とサーバ101とから構成されている。クライアント201からの格納要求や検索要求を受けて、サーバ101が各要求に対応する処理を行う。
クライアント201は、主に、構造化文書登録部202と検索部203と入力部204と表示部205を有する。キーボードやマウス等の入力装置からなる入力部204は、構造化文書を入力したり、各種指示入力を行うためのものである。構造化文書登録部202は、入力部204から入力された構造化文書や、クライアント201のもつ記憶装置などに予め記憶された構造化文書を構造化文書データベース(構造化文書DB)111に登録するためのものである。構造化文書登録部202は、登録すべき構造化文書とともに格納要求をサーバ101へ送信する。
検索部203は、ユーザにより入力部204から入力された指示に従って、構造化文書データベース111から所望のデータを検索するための検索条件などが記述された問合せデータを作成し、当該問合せデータを含む検索要求をサーバ101へ送信する。また、サーバ101から送信された当該検索要求に対応する結果データを受け取り、これを表示部205に表示する。
サーバ101は、要求処理部102、格納処理部103、検索処理部104から構成されている。また、サーバ101には構造化文書データベース111が接続されている。構造化文書データベース111は、汎用構造データ記憶部112と差分構造データ記憶部113と索引データ記憶部114と文書オブジェクトデータ記憶部115から構成されている。
要求処理部102は、クライアント201から送信される格納要求や検索要求を判別し、格納処理部103や検索処理部104へ処理の振り分けを行い、格納処理部103や検索処理部104での処理結果をクライアント201に返す。
格納処理部103は、クライアント201からの格納要求を受けて、クライアント201から送信された構造化文書を構造化文書データベース111に格納する処理を行う。格納処理部103は、文書データ解析部31と構造データ抽出部32と汎用構造登録部33と差分構造登録部34と文書オブジェクト格納部35から構成される。
文書データ構文解析部31は、要求処理部102から渡された構造化文書を構文解析し、この解析結果を基に構造データ抽出部32では当該構造化文書の(文書)構造データを抽出する。当該構造データと汎用構造データ記憶部112に記憶されている汎用構造データとの差分は差分構造登録部34により、差分構造データ記憶部113に格納される。汎用構造登録部33は、今回格納する構造化文書データの構造データに基づき汎用構造データ記憶部112に記憶されている汎用構造データを更新する。
文書オブジェクト格納部35は、構造化文書データを文書オブジェクトデータ記憶部115に格納するとともに、当該構造化文書データに出現する語彙の所在を探し出すための索引データを索引データ記憶部115に格納する。文書データ解析部31にて解析された構造化文書データ中の各要素(ノード)に対応するオブジェクトデータは、構造化文書データから抽出された差分構造データに基づく配置順に、文書オブジェクトデータ記憶部115に格納される。
検索処理部104は、クライアント201からの検索要求を受けて、指定された条件(問合せデータ)に合致するデータを構造化文書データベース111から探し出し、この探し出したデータを結果データとして返す処理を行う。検索処理部104は、大きく分けて、問合せデータ解析部41、問合せ実行部42、結果生成部46からなり、また、問合せ実行部42は、構造スキャン部43、索引スキャン部44、データ結合部45からなる。
問合せデータ解析部41は、要求処理部102から渡された問合せデータを構文解析する。問合せ実行部42は、この解析結果を基に構造スキャン部43、索引スキャン部44を用いて、汎用構造データ記憶部112に記憶された汎用構造データ、差分構造データ記憶部113に記憶された差分構造データ、索引データ記憶部114に記憶された索引データを参照して、この結果をデータ結合部45で結合する。
結果生成部46は、データ結合部45で得られたデータを基に、文書オブジェクトデータ記憶部115に記憶されているオブジェクトデータを読み出して、問合せデータに記述された条件に合致する結果データを生成する。
図2は、サーバ101のハードウエア的な構成例を示したもので、バス1に通信I/F装置2、可搬記録媒体ドライブ装置3、表示装置4、入力装置5、出力装置6、演算装置(CPU)7および外部記憶装置8並びにメモリ9が接続されて構成されている。さらに、図2に示す構成では、バス1に、図2の構造化文書データベース111が接続されている。
図1の要求処理部102と格納処理部103と検索処理部104のそれぞれの機能を実現するためのプログラムは、図2の外部記憶装置8に予め記憶され、必要に応じて、各プログラムがメモリ9に読み込まれて実行される。
以下、図1を参照して説明する。
図3は、構造化文書データの一例を示したものである。構造化文書を記述するための代表的な言語としてXML(eXtensible Markup Language)が挙げられる。図3に示す構造化文書(文書A)はXMLで記述されたものである。XMLでは、文書構造を構成する個々のパーツを「要素」(エレメント:Element)と呼び、要素はタグ(tag)を使って記述する。具体的には、要素の始まりを示すタグ(開始タグ)と、終わりを示すタグ「終了タグ」)の2つのタグでデータを挟み込んで、1つの要素を表現している。なお、開始タグと終了タグで挟み込まれたテキストデータは、当該開始タグと終了タグで表された1つの要素に含まれるテキスト要素(テキストノード)である。
この例では、<book>というタグで囲まれた要素のルート要素が存在する。この「book」要素は、<title>、<authors>、<abstract>の各タグで囲まれた3つの子要素を包含する。<TITLE>要素は、「データベース」というテキスト要素をもつ。また、<AUTHORS>要素は、<AUTHOR>要素という2つの子要素を包含する。
図4は、構造化文書データの他の例を示したもので、図3の構造化文書データと類似した構造を持っている。図3と図4の構造化文書データの相違点を以下に示す。図4の構造化文書データ(文書B)は3つの<AUTHOR>要素が含まれている。また、<ABSTRACT>要素が含まれていないが、<KEYWORD>要素が含まれている。
XMLなどで記述された構造化文書の特徴として、以下のものが挙げられる。
・階層的なデータモデルである。
・同じ要素が繰返し出現することがある。
・要素間に順序性がある。
・スキーマを持つ場合、持たない場合、いずれも可能である。
図5は、構造化文書データベースのデータ構造を論理的に表したもので、ノードとアークから構成される木構造を有する。大量の構造化文書が「root」ノードをルートする1つの構造化文書の部分文書として記憶されている。
「ROOT」ノードをルートにして、「BOOKFOLDER」ノードが子ノードとして存在している。「BOOKFOLDER」ノードの下には、図3の文書A2と図4の文書Bのそれぞれに対応するサブツリーが存在する。
ここでは、フォルダとドキュメントという概念を導入している。図5では、「ROOT」と「BOOKFOLDER」がフォルダであり、フォルダの下には複数の文書、この場合は2つの文書(文書A、文書B)が存在する。
実際には、各ノード(テキストノードを含む)はオブジェクトデータのファイルとして構造化文書データ記憶部115に格納される。各ノード(テキストノードを含む)には、オブジェクトID(OID)と呼ばれる識別子が割当てられている。なお、図5では、説明の簡単のため、OIDを数字で表している。OIDを指定することで所望のオブジェクトデータを取り出すことができる。実際のOIDは、当該ノード(テキストノードを含む)を含む構造化文書の識別子である文書IDと、文書オブジェクトデータ記憶部115内の当該ノードを含む構造化文書の記憶エリア内における当該ノードに対応するオブジェクトデータを記憶するスロット位置を示すスロットIDが含まれている。
ノードに対応するオブジェクトの属性として、子ノードOID、親ノードOIDなどのアークに関する情報がある。さらに、タグ名などの属性もある。
(格納)
次に、図6〜図10を参照して、図3の文書Aを構造化文書DB111に格納する際の格納処理部103の処理動作の概略を説明する。ここでは、文書Aが構造化文書DB111に格納される最初の構造化文書データであるとする。この場合、汎用構造データはまだ存在していない。
クライアント201から送信された文書Aの格納要求を受け付けると、まず、文書データ解析部31にて、文書Aの構文解析を行って、「BOOK」ノードをルートノードする図6に示すような文書ツリーが出力される。これは周知・公用技術であるYacc&Lexなどのコンパイラ+コンパイラツールに代表される構文解析技術により出力することができる。
構造データ抽出部32は、図6示すような文書ツリーから、図7に示すような構造データを求める。汎用構造登録部33は、図7に示した構造データから図8に示すような汎用構造を求めて、汎用構造データ記憶部112に登録する。汎用構造とは、格納された各構造化文書に含まれている構造を表したものである。図8に示すように、汎用構造では、同じタグ名の複数の兄弟ノードは、1つのノードに集約して表すようになっている。なお、汎用構造データ記憶部112には、汎用構造データを示すツリーを束ねるルートノードとして汎用構造データの「ROOT」ノードが初期作成されている。
差分構造登録部34は、文書Aの図7に示した構造データのうち図8の汎用構造データで落ちてしまった構造に関する情報、すなわち図10に示すような差分構造データ(第2の差分構造データ)を求める。ここでは、第2の差分構造データを求めるために、図9に示すような第1の差分構造データを求めるようになっている。なお、以下の説明において、第1及び第2の差分構造データのうち第2の差分構造データのみを指す場合には、単に差分構造データと呼ぶことがある。
文書Aの構造データの「AUTHORS」ノードには2つの「AUTHOR」ノードが存在し、同じ部分構造(部分ツリー)が繰返し出現する。しかし、このような繰返し形式の構造は汎用構造には表されていないため、それを差分構造として表したものが図10に示す第2の差分構造データである。
なお、第2の差分構造データでは、構造データのあるノード以下にある部分ツリー(の全部または一部)が複数回繰返し出現する場合には、図10に示すように、当該ノードに、当該部分ツリーの発生回数を属性情報として付加するとともに、当該複数個の部分ツリーを1つの部分ツリーで集約して表す。この際、当該構造データ中で繰返し出現する部分ツリーのなかで、必ず出現するとは限らないノード(不定ノード)が存在する場合には、当該ノードが不定ノードであることを示すマーク「?」を当該ノードの属性情報として付加する。
汎用構造データは、それまでに格納された複数の構造化文書データを網羅するものであるが、差分構造データは、格納される1つの構造化文書データに対し1つ存在する。また、構造化文書データを格納する際には、この構造化文書データの中にこの時点の汎用構造データには存在しないノードがあれば、当該存在しないノードが汎用構造データに追加されるので、汎用構造データのサイズは単調に増加することになる。
汎用構造データ記憶部112に記憶される汎用構造データ中の各ノードには、それぞれを識別するためのノードIDが付されている。図8に示す汎用構造の場合、ノードID「T0」がルートノードであり、他のノードには、「T1」〜「T7」というノードIDをもつ。すなわち、文書Aを格納する際に、差分構造データを求める際に用いられた汎用構造データはノードID「T7」までのノードからなる汎用構造データである。この後、構造化文書データを格納していくと、当該汎用構造データには、新たなノードが追加されるから、当該新たなノードには、当該汎用構造データに追加された順を示す上記ノードIDを付加することとする。本実施形態では、差分構造データを求める際に用いた汎用構造データを識別するために、当該汎用構造データの最後のノードIDを当該差分構造データとともに差分構造データ記憶部113に記憶する。
文書Aの差分構造データは、当該差分構造データを求める際に用いた汎用構造データの最後のノードID「T7」とともに、例えば、図16に示すように、「管理T7[1][1][2*][1][1][1]」という配列形式で差分構造データ記憶部113に記憶される。
文書オブジェクト格納部35は、図10に示した差分構造データに基づき、文書ツリー上の各ノード(テキストノードを含む)に対応するオブジェクトデータを並べた配列を文書オブジェクトデータ記憶部115に格納する。文書オブジェクト記憶部115は、各構造化文書データを記憶するための複数の記憶領域を含み、各記憶領域は複数のスロットに分割されている。各スロットは、その位置を示すスロットIDをもち、各スロットには当該構造化文書中の各オブジェクトデータを記憶するようになっている。1構造化文書データが記憶されている1記憶領域内のデータを文書オブジェクトレコードと呼ぶ。この文書オブジェクトレコードは、当該構造化文書データを構成する複数要素の配列である。配列内の各要素の位置情報は、上記スロットIDに対応する。
各文書(例えば、文書A)を格納する記憶領域内では、図17に示すように、汎用構造データ中の各ノードに対応するオブジェクトデータを(差分構造データの左側のノードから順に、上流ノードから下流ノードの順に)優先的に格納し、この後に、文書ツリー中の不定ノードやテキストノードを順に格納するようになっている。
次に、図4の文書Bを構造化文書DB111に格納する際の格納処理部103の処理動作の概略を説明する。ここでは、汎用構造データ記憶部112に、図8に示した汎用構造データが記憶されている場合について説明する。
文書データ解析部31は、クライアント201から送信された文書Bの格納要求を受け付けると、文書Bの構文解析を行って、「BOOK」ノードをルートノードする図11に示すような文書ツリーを出力する。
構造データ抽出部32は、図11示すような文書ツリーから、図12に示すような構造データを求める。
汎用構造登録部33は、汎用構造データ記憶部112に記憶されている図8に示した汎用構造データと、図12の構造データとを比較して、図8の汎用構造データを更新する。すなわち、この場合には、図13に示すように、図8の汎用構造データにはないが、図12の構造データには存在する「KEYWORD」ノードを「BOOK」ノードの子ノードとして追加する。なお、「KEYWORD」ノードのノードIDは「T8」である。
図12に示した構造データから図8に示すような汎用構造を求めて、汎用構造データ記憶部112に登録する。
差分構造登録部34は、文書Bの図12に示した構造データと図13の汎用構造データとの差分構造を示す差分構造データ(図15参照)を求める。この際、まず、図14に示すような第1の差分構造データを求める。図14に示すように、第1の差分構造データは、図12の構造データにはなく、図13の汎用構造データに存在するノード、すなわち「ABSTRACT」ノードが追加されているが、このノードの属性情報として、発生回数「0」が付されている。これは、文書Bには存在しないが、汎用構造データには存在する要素であることを示している。
文書Bの構造データの「AUTHORS」ノードには3つの「AUTHOR」ノードが存在し、同じ部分構造(部分ツリー)が繰返し出現する。従って、図15の第2の差分構造データには、この繰返し形式の構造を1つの部分構造で集約して表し、当該部分構造のルートの「AUTHOR」ノードには発生回数「3*」が付加されている。
文書Bの差分構造データは、当該差分構造データを求める際に用いた汎用構造データの最後のノードID「T8」とともに、例えば、図16に示すように、「管理T8[1][1][3*][1][1][0][1]」という配列形式で差分構造データ記憶部113に記憶される。
文書Bを格納する記憶領域内では、図17に示すように、汎用構造データ中の各ノードに対応するオブジェクトデータを(差分構造データのルートノードを起点に、当該ルートノード以下の構造を最初の子ノードから順に、各子ノードについては、当該子ノード以下の構造を上流ノードから下流ノードの順に)優先的に格納し、この後に、文書ツリー中の不定ノードやテキストノードを順に格納するようになっている。
図18は、構造データ抽出部32の構造データ抽出処理を説明するためのフローチャートである。ここでは、図6に示す文書ツリーから図7に示す構造データを抽出する場合を例にとり説明する。図6の文書ツリーをルートノードから下流方向へ辿りながら文書ツリー上の各ノードを構造データのノードとして追加することにより、構造データを抽出する。
まず、文書データ解析部31から出力された図6の文書Aの文書ツリーのルートノードを構造データのルートノードに設定する(ステップS1)。構造データのルートノード以下に、文書ツリー上の各ノードを追加する処理のために、文書ツリーのルートノードをdnode、構造データのルートノードをfnodeと定める(ステップS2)。dnodeに子ノードが存在する場合には(ステップS3のYes)、dnodeの最初の子ノードをdnode´と定める(ステップS4)。そして、fnodeの子ノードにdnode´を追加し、当該子ノードに、発生回数「1」という属性情報を付加する(ステップS5)。dnodeの全ての子ノードについて、ステップS4〜ステップS5を行った後、文書ツリー上の全ノードについて上記ステップS4、ステップS5の処理が終了するまで、dnodeとfnodeを更新する(ステップS6、ステップS7)。すなわち、ステップS7では、文書ツリーの次のノードをdnodeと定め、構造データの当該dnodeに対応するノードをfnodeと定める。そして、ステップS3へ戻り、上記ステップS3〜ステップS5を繰り返す。
図18に示した処理によれば、構造データのルートノード、すなわち、「BOOK」ノードに「TITLE」ノード、「AUTHORS」ノードが、この順に追加される。この後、当該「AUTHORS」ノードに、当該ノードの1番目の子ノードである「AUTHOR」ノードが追加され、当該「AUTHOR」ノード以下に「FIRST NAME」ノードや「LAST NAME」ノードが追加される。さらに、「AUTHORS」ノードの2番目の子ノードである「AUTHOR」ノードが追加され、当該「AUTHOR」ノード以下に「FIRST NAME」ノードや「LAST NAME」ノードが追加される。最後に構造データの「BOOK」ノードの子ノードとして、「ABSTRACT」ノードが追加される。各ノードには、発生回数「1」という属性情報が付加されている。
図19は、汎用構造登録部33の汎用構造登録処理を説明するためのフローチャートである。ここでは、図7に示す構造データをもつ最初の文書Aを格納する場合に汎用構造データを新規作成する場合を例にとり説明する。図7の構造データをルートノードから下流方向へ辿りながら構造データ上の各ノードと汎用構造データ上のノードとを比較して、汎用構造データにはないノード(gnode)を汎用構造データに追加することにより、汎用構造データを更新する。ここでは、前述したように、構造データに同じ(要素名の)ノードが繰返し出現しても、これを汎用構造データには追加しないようになっている。
構造データ抽出部32から出力された図7の文書Aの構造データのルートノード「BOOK」をfnodeと定める(ステップS11)。汎用構造データのルートノード「ROOT」以下に、fnodeに対応するノードが存在する場合にはステップS15へ進み、存在しない場合には、ステップS13へ進む(ステップS12)。ここでは、新規の汎用構造データの作成であるため「ROOT」ノード以下には汎用構造データは存在しないので、ステップS13へ進み「ROOT」ノードの子ノードとしてfnodeを追加する。すなわち「BOOK」ノードを追加する。そして、構造データ上の「BOOK」ノードをgnodeと定める(ステップS14)。
以下、ステップS16〜ステップS21を繰返して、当該gnode以下に汎用構造を構築する。すなわち、fnodeに子ノードが存在する場合には(ステップS16のYes)、fnodeの最初の子ノードをfnode´と定める(ステップS17)。そして、汎用構造データのgnodeの子ノードにfnode´が存在しない場合には(ステップ18のNo)、gnodeの子ノードにfnode´を追加し、当該子ノードに、ノードIDを付加する(ステップS19)。一方、汎用構造データのgnodeの子ノードにfnode´が既に存在する場合には(ステップS18のYes)、ステップS16へ戻り、fnodeの次の子ノードを新たにfnode´と定める。fnodeの全ての子ノードについて、ステップS18〜ステップS19を行った後、構造データ上の全ノードについて上記ステップS18、ステップS19の処理が終了するまで、fnodeとgnodeを更新する(ステップS20、ステップS21)。すなわち、ステップS21では、構造データの次のノードをfnodeと定め、当該fnodeに対応する汎用構造データのノードをgnodeと定める。そして、ステップS16へ戻り、上記ステップS16〜ステップS19を繰り返す。
以上の処理により、構造データ中に出現する複数個の同じ部分ツリーが1つの部分ツリーで表された、図8に示すような汎用構造データが得られる。最後に、図8に示すような汎用構造データを汎用構造データ記憶部112に格納する(ステップS22)。
次に、汎用構造データ記憶部112に図8に示すような汎用構造データが既に格納されている状態において、図12に示す構造データをもつ文書Bを格納する場合の汎用構造登録処理動作について、文書Aを格納する場合と異なる部分についてのみ説明する。この場合、ステップS15では、汎用構造データの「BOOK」ノードをgnodeと定める。そして、ステップS16〜ステップS21で、汎用構造データ記憶部112に記憶されている汎用構造データを更新する処理を行う。図12の構造データには存在し、図8の汎用構造データには存在しないノードは「KEYWORD」ノードである。従って、ステップS17で、「BOOK」ノードの3番目の子ノードである「KEYWORD」をfnode´と定めると、図8の汎用構造データの「BOOK」ノードの子ノードには、「KEYWORD」ノードは存在しないので(ステップS18のNo)、ステップS19へ進み、「BOOK」ノードの子ノードに「KEYWORD」ノードを追加し、当該ノードのノードIDとして「T8」を付加する。
以上の処理により、図13に示すような汎用構造データが得られる。最後に、図13に示すような汎用構造データで汎用構造データ記憶部112に格納されている汎用構造データを更新する(ステップS22)。
図20〜図21は、差分構造登録部34の差分構造登録処理動作を説明するためのフローチャートである。ここでは、図12に示す構造データをもつ文書Bを格納する場合を例にとり、差分構造登録処理動作を説明する。
まず、図12の構造データと、図13の汎用構造データとを比較して、図12の構造データには存在しないが、図13の汎用構造データには存在するノード、すなわち、ここでは「ABSTRACT」ノードを、発生回数「0」という属性情報を付加して当該構造データに追加することにより、図14に示すような第1の差分構造データを生成する。
すなわち、汎用構造データの更新に用いた、図12の構造データのルートノードをfnodeと定める(ステップS31)。そして、fnodeに対応する汎用構造データ中のノードをgnodeと定める(ステップS32)。
gnodeに子ノードが存在する場合には(ステップS33のYes)、gnodeの最初の子ノードをgnode´と定める(ステップS34)。そして、構造データのfnodeの子ノードにgnode´が存在しない場合には(ステップS35のNo)、fnodeの子ノードにgnode´を追加し、当該子ノードの属性情報として、発生回数「0」を付加する(ステップS36)。一方、構造データのfnodeの子ノードにgnode´が存在する場合には(ステップS35のYes)、ステップS33へ戻り、ステップS33で更に子ノードが存在すれば(ステップS33のYes)、gnodeの次の子ノードを新たにgnode´と定める(ステップS34)。
例えば、ステップ34で、「BOOK」ノードの3番目の子ノードである「ABSTRACT」をgnode´と定めると、図12の構造データの「BOOK」ノードの子ノードには、「ABSTRACT」ノードは存在しないので(ステップS35のNo)、ステップS36へ進み、「BOOK」ノードの子ノードに「ABSTRACT」ノードを追加し、当該ノードの属性情報として発生回数「0」を付加する。
gnodeの全ての子ノードについて、ステップS35〜ステップS36を行った後(ステップS33)、汎用構造データ上の全ノードについて上記ステップS35、ステップS36の処理が終了するまで、gnodeとfnodeを更新する(ステップS37、ステップS38)。すなわち、ステップS38では、汎用構造データの次のノードをgnodeと定め、当該gnodeに対応する構造データのノードをfnodeと定める。そして、ステップS33へ戻り、上記ステップS33〜ステップS36を繰り返す。
以上の処理により、図14に示すような第1の差分構造データが得られる。
次に、当該第1の差分構造データ中の、繰返し形式の部分構造を1つの部分構造で集約して表した、図15に示したような第2の差分構造データを生成する。すなわち、第1の差分構造データのあるノード以下に、同じ部分ツリーが複数回出現している場合には(図21のステップS41のYes)、当該繰返し形式の構造を完全繰返し形式に書き直す(ステップS42)。すなわち、当該複数個の同じ部分ツリーを1つの部分ツリーで表すとともに、当該部分ツリーのルートノードに、当該部分ツリーの出現回数を示す属性情報(発生回数)を付加する。
図15の第1の差分構造データは、「AUTHORS」ノード以下に、「AUTHOR」ノードをルート(root)とする全く同一の部分ツリーが3つ存在する。従って、図15に示すように、これら3つの部分ツリーを1つの部分ツリーで表し、当該部分ツリーのルートノード「AUTHOR」に発生回数「3」を付加する。
第1の差分構造データのあるノード以下に、複数の同じ構造の部分ツリーが出現するが、このうちの少なくとも1つの部分ツリーは当該部分ツリーの一部の構造のみしか含まれていない場合には(ステップS43のYes)、当該繰返し形式の構造を部分繰返し形式に書き直す(ステップS44)。
例えば、図24に示すような構造データを例にとり、部分繰返し形式の表現方法について説明する。図24の構造データは、「AUTHORS」ノード以下に、「AUTHOR」ノードをルートとする部分ツリーが2つ存在し、このうちの1つの部分ツリーには「LASTNAME」ノードが存在していないが、他方は、文書Bの構造データ(図12参照)と同様な構造を有している。
図24の構造データと図13の汎用構造データとの差分を示す第1の差分構造データを図25に示す。また、図26は、図25の第1の差分構造データ中の繰返し形式の部分構造を1つの部分構造で集約して表した第2の差分構造データを示したものである。
図25に示す第1の差分構造データでは、「AUTHORS」ノード以下に、「AUTHOR」ノードをルートとする部分ツリーが2つ存在し、このうちの1つの部分ツリーには「LASTNAME」ノードが存在していない。従って、図21のステップS44では、図26に示すように、当該2つの部分ツリーを1つの部分ツリーで表し、当該部分ツリーのルートノード「AUTHOR」に発生回数「2」を付加する。そして、当該部分ツリーに含まれる「LASTNAME」ノードには、不定ノードであることを示す「?」を付加する。
図21の説明に戻り、第1の差分構造データ中の上記繰返し形式の構造以外の部分(すなわち、繰返し形式の構造がなく、展開形式のままでも、所定の閾値以下の情報量で表現できる部分)は、そのままの展開形式で表す(ステップS45)。すなわち、図14の第1の差分構造データ内の、「BOOK」ノード、「TITLE」ノード、「AUTHORS」ノード、「ABSTRACT」ノード、「KEYWORD」ノードからなる部分ツリーは、図15の第2の差分構造データでは、そのままの形式で表されている。
以上の処理により得られた、第2の差分構造データを配列形式に書き換える(ステップS46)。例えば、図15の第2の差分構造データを、ルートノードを起点として当該ルートノード以下の構造を最初の子ノードから順に、各子ノードについては、当該子ノード以下の構造を上流ノードから下流ノードの順に、各ノードに付加されている発生回数を並べる。すなわち、「BOOK」ノード、「TITLE」ノード、「AUTHORS」ノード、「AUTHOR」ノード、「FIRSTNAME」ノード、「LASTNAME」ノード、「ABSTRACT」ノード、「KEYWORD」ノードの順で、各ノードの発生回数を並べると、[1][1][3*][1][1][0][1]となる。
差分構造登録部34は、この配列の先頭に、当該差分構造データを求める際に用いた汎用構造データの最後のノードID「T8」(これを管理情報と呼ぶ)を付加して、図16に示したように、当該差分構造データを差分構造データ記憶部113に格納する。
図16は、差分構造データの記憶例を示したものである。差分構造データ記憶部113には、文書Aの差分構造データ、文書Bの差分構造データが記憶されている。
文書Aの差分構造データは、[1][1][2*][1][1][1]という数値列、実際には配列形式となっている。各データに対応する意味は以下の通りである。
・[1] :「TITLE」が1回発生している。
・[1] :「AUTHORS」が1回発生している。
・[2*]:「AUTHOR」以下の構造を2回繰り返している。
・[1] :「AUTHOR/FIRSTNAME」が1回発生している。
・[1] :「AUTHOR/LASTNAME」が1回発生している。
・[1] :「ABSTRACT」が1回発生している。
文書Aの差分構造データは、[1][1][3*][1][1][0][1]という数値列、実際には配列形式となっている。各データに対応する意味は以下の通りである。
・[1] :「TITLE」が1回発生している。
・[1] :「AUTHORS」が1回発生している。
・[3*]:「AUTHOR」以下の構造を3回繰り返している。
・[1] :「AUTHOR/FIRSTNAME」が1回発生している。
・[1] :「AUTHOR/LASTNAME」が1回発生している。
・[0] :「ABSTRACT」が0回発生している。すなわち、「ABSTRACT」は存在しない。
・[1] :「KEYWORD」が1回発生している。
各差分構造データに付加されている管理情報は、当該差分構造データを求める際に用いた汎用構造データの範囲を特定することのできる最大ノード番号である。汎用構造データは、汎用構造データに存在していないノードを持つ新たな構造化文書データが格納される毎にノードが追加される。つまり単調増加するから、この管理情報は、どの範囲の汎用構造データを用いて当該差分構造データが生成されたのかを示している。
図22は、構造化文書データのさらに他の例を示したもので、図3の構造化文書データ(文書A)、図4の構造化文書データ(文書B)と類似した構造を持っている。すなわち、図22の構造化文書データ(文書C)は、「AUTHORS」ノードは2つの「AUTHOR」ノードをもち、2番目の「AUTHOR」ノード、つまり「AUTHORS/AUTHOR[2]」には「LASTNAME」ノードが存在しない。また、「ABSTRACT」ノードが存在しないが、「KEYWORD」ノードが存在する。
図23は、図22の文書Cの文書ツリーを示したものである。
図24は、図23の文書Cの文書ツリーを基に、図18の構造データ抽出処理を行うことにより得られた構造データを示したものである。
汎用構造データ記憶部112に図13に示した汎用構造データが記憶されているとき、図22の文書Cを格納する場合、図19の汎用構造登録処理により汎用構造データ記憶部112に格納される汎用構造データは図13と同様である。図24の構造データと、図13の汎用構造データとを用いて図20に示す差分構造登録処理を行った結果得られる第1の差分構造データを図25に示す。
図25では、「AUTHORS」ノード以下に、「AUTHOR」ノードをルートとする部分ツリーが2つ存在し、このうちの1つの部分ツリーには「LASTNAME」ノードが存在していない。また、発生回数「0」の「ABSTRACT」ノードが「BOOK」ノードに追加され、発生回数「0」の「LASTNAME」が2番目の「AUTHOR」ノードに追加されている。
図25の第1の差分構造データに対し、図21に示す処理を行うことにより得られる第2の差分構造データを図26に示す。
図26では、「AUTHORS」ノード以下の「AUTHOR」ノードをルートする2つの部分ツリーが1つの部分ツリーで表され、当該部分ツリーのルートノード「AUTHOR」に発生回数「2」が付加されている。そして、当該部分ツリーに含まれる「LASTNAME」ノードには、不定ノードであることを示す発生回数「?」が付加されている。また、図26に示す第2の差分構造データは、発生回数「0」の「ABSTRACT」ノードを含む。
図26に示す差分構造データは、[1][1][2*][1][?][0][1]と表すことができる。差分構造登録部34は、この配列の先頭に、当該差分構造データを求める際に用いた汎用構造データの最後のノードID「T8」を付加して、図27に示したように、当該差分構造データを差分構造データ記憶部113に格納する。
次に、文書オブジェクト格納部35の処理動作について、図22に示すフローチャートを参照して説明する。ここでは、文書Bの文書ツリー(図11参照)を格納する場合を例にとり説明する。すなわち、図15に示す第2の差分構造データをルートノードから下流方向へ辿りながら、まず、汎用構造中の各ノードに対応する文書ツリーのオブジェクトデータを文書オブジェクトデータ記憶部115に格納していき、この後に文書ツリー中の不定ノードやテキストノードを順に格納する。
まず、差分構造登録部34で得られた図15に示すような第2の差分構造データのルートノード(「BOOK」ノード)をsnodeと定める。また、図11の文書ツリーのルートノード(「BOOK」ノード)をdnodeと定める(ステップS51)。
snodeが展開形式で表されているときには(ステップS52のYes)、文書ツリーのdnodeに対応するオブジェクトデータを文書オブジェクトデータ記憶部115に格納する(ステップS53)。現在、snodeは「BOOK」ノードであり、展開形式で表されているから、図17に示すように、文書オブジェクトデータ記憶部115の文書Bの記憶エリアの最初のスロット(スロットID=0)に、dnodeに対応するオブジェクトデータ、すなわち、「BOOK」を格納する。
この後、ステップS59において、snode、dnodeを更新した後、ステップS52へ戻る。ステップS59では、第2の差分構造データの次のノード、すなわち、「TITLE」ノードをsnodeと定め、snodeに対応する文書ツリー内のノード、すなわち、「TITLE」ノードをdnodeと定める。
この場合も、snodeが展開形式で表されているので(ステップS52のYes)、図17に示すように、文書オブジェクトデータ記憶部115の文書Bの記憶エリアの2番目のスロット(スロットID=1)に、dnodeに対応するオブジェクトデータ、すなわち、「TITLE」を格納する(ステップS53)。
この後、ステップS59において、第2の差分構造データの次のノード、すなわち、「AUTHORS」ノードをsnodeと定め、snodeに対応する文書ツリー内のノード、すなわち、「AUTHORS」ノードをdnodeと定た後、ステップS52へ戻る。
この場合も、snodeが展開形式で表されているので(ステップS52のYes)、図17に示すように、文書オブジェクトデータ記憶部115の文書Bの記憶エリアの3番目のスロット(スロットID=2)に、dnodeに対応するオブジェクトデータ、すなわち、「AUTHORS」を格納する(ステップS53)。
この後、ステップS59において、第2の差分構造データの次のノード、すなわち、「AUTHOR」ノードをsnodeと定め、snodeに対応する文書ツリー内のノード、すなわち、「AUTHOR」ノードをdnodeと定めた後、ステップS52へ戻る。
この場合には、snodeの属性情報である発生回数が「3」であり(ステップS52のNo)、当該snode以下の部分ツリーが完全繰返し形式で表されているので(ステップS54のYes)、文書ツリーのdnode以下の部分ツリー内の各オブジェクトデータを完全繰返し形式で文書オブジェクトデータ記憶部115に格納する(ステップS55)。すなわち、図11の文書ツリーでは、dnode(「AUTHOR」ノード)をルートとする部分ツリーが3回出現しているので、当該部分ツリーに含まれるオブジェクトデータ「AUTHOR」、「FIRSTNAME」「LASTNAME」をこの順で、連続する3つのスロットに格納する動作を3回繰り返す。この結果、図17に示すように、文書オブジェクトデータ記憶部115の文書Bの記憶エリアの4番目のスロット(スロットID=3)から6番目のスロット(スロットID=5)に、1つ目の部分ツリーのオブジェクトデータが格納され、7番目のスロット(スロットID=6)から9番目のスロット(スロットID=8)に、2つ目の部分ツリーのオブジェクトデータが格納され、8番目のスロット(スロットID=9)から10番目のスロット(スロットID=11)に、3つ目の部分ツリーのオブジェクトデータが格納される。
第2の差分構造データの「ABSTRACT」ノードの発生回数は「0」であるから、このノードをとばして、ステップS59では、第2の差分構造データの「KEYWORD」ノードをsnodeと定め、snodeに対応する文書ツリー内のノード、すなわち、「KEYWORD」ノードをdnodeと定めた後、ステップS52へ戻る。
この場合も、snodeが展開形式で表されているので(ステップS52のYes)、図17に示すように、文書オブジェクトデータ記憶部115の文書Bの記憶エリアの11番目のスロット(スロットID=12)に、dnodeに対応するオブジェクトデータ、すなわち、「KEYWORD」を格納する(ステップS53)。
以上で、第2の差分構造データの全ノードの探索は終了したので(ステップS58のYes)、ステップS60へ進み、文書ツリー内で格納されていないオブジェクトデータをノードを文書オブジェクトデータ記憶部115に格納する。ここでは、テキストノードに対応するオブジェクトデータを、汎用構造データ上の各ノードに対応するオブジェクトデータの格納順と同様に、例えば、図17に示すように、スロットID=21以降のスロットに格納していく。
次に、文書オブジェクト格納部35の処理動作について、文書Cの文書ツリー(図23参照)を格納する場合を例にとり説明する。この場合、図26に示す第2の差分構造データを用いて、文書ツリーの各オブジェクトデータを格納する。「AUTHORS」ノードまでを格納する処理動作は、上記文書Bの場合と同様である。以下、上記文書Bと異なる部分についてのみ説明する。
ステップS59において、第2の差分構造データの次のノード、すなわち、「AUTHOR」ノードをsnodeと定め、snodeに対応する文書ツリー内のノード、すなわち、「AUTHOR」ノードをdnodeと定めた後、ステップS52へ戻る。
この場合には、snodeの属性情報である発生回数が「2」であり(ステップS52のNo)、当該snode以下の部分ツリーが部分繰返し形式で表されているので(ステップS54のNo、ステップS56のYes)、文書ツリーのdnode以下の部分ツリー内の各オブジェクトデータを部分繰返し形式で文書オブジェクトデータ記憶部115に格納する(ステップS57)。
すなわち、図23の文書ツリーでは、dnode(「AUTHOR」ノード)をルートとする部分ツリーが2回出現しているが、2番目の部分ツリーの「LASTNAME」ノードは存在しないため、第2の差分構造データでは「LASTNAME」ノードは不定ノードとなっている。従って、ここでは不定ノードに対応するオブジェクトデータは格納しないようにする。不定ノードに対応するオブジェクトデータの格納処理については、ステップS60で行う。
ステップS57では、まず、当該部分ツリーに含まれるオブジェクトデータ「AUTHOR」、「FIRSTNAME」をこの順で、連続する2つのスロットに格納する動作を2回繰り返す。この結果、図30に示すように、文書オブジェクトデータ記憶部115の文書Cの記憶エリアの4番目のスロット(スロットID=3)から5番目のスロット(スロットID=4)に、1つ目の部分ツリーのオブジェクトデータが格納され、6番目のスロット(スロットID=5)から7番目のスロット(スロットID=6)に、2つ目の部分ツリーのオブジェクトデータが格納される。
この後、前述の文書Bを格納する場合と同様にして、スロットID=7のスロットに「KEYWORD」が格納される。
以上で、第2の差分構造データの全ノードの探索は終了したので(ステップS58のYes)、ステップS60へ進み、文書ツリー内で格納されていないオブジェクトデータをノードを文書オブジェクトデータ記憶部115に格納する。このステップS60では、まず、ステップS57で格納されなかった不定ノードに対応するオブジェクトデータを格納する。すなわち、1番目の部分ツリーの「LASTNAME」を、例えば図30に示すように、スロットID=30のスロットに格納する。この後、ステップS60では、テキストノードに対応するオブジェクトデータを、汎用構造データ上の各ノードに対応するオブジェクトデータの格納順と同様に、例えば図30に示すように、スロットID=31以降のスロットに格納していく。
図30は、文書オブジェクトレコードの記憶例を示したもので、文書Aの文書オブジェクトレコード、文書Bの文書オブジェクトレコード、文書Cの文書オブジェクトレコードが記憶されている。各文書オブジェクトレコードは、当該レコードに対応する文書の文書IDに対応付けて記憶されている。各文書の各オブジェクトデータは、文書IDとスロットIDから一意に特定することができる。すなわち、文書IDとスロットIDを含むオブジェクトIDが与えられれば、任意の文書オブジェクトデータにアクセスすることができる。
文書オブジェクト格納部35は、文書ツリーの各オブジェクトデータを文書オブジェクトデータ記憶部115に格納するとともに、当該文書ツリー内の各オブジェクトデータを基に、索引データ記憶部114を更新する。索引データとは、格納された構造化文書データに含まれるテキスト要素のテキストデータ(文字列)を抽出し、テキストデータと当該テキストデータを含む構造化文書データ中の要素のオブジェクトID(OID)との対応関係を表す情報である。
索引データ記憶部114には、図29に示すように、語彙テーブルと当該語彙テーブル中の各語彙にリンクされた当該語彙を含むテキスト要素のOIDを記録する複数のテーブルが記憶されている。語彙テーブル中の語彙からリンクをたどることで、その語彙を含むテキスト要素の出現位置、つまりOIDが得られる。
ここでは、各オブジェクトデータのオブジェクトIDを<文書ID、スロットID>と表し、文書A、B、Cの文書IDはそれぞれ「文書A」「文書B」「文書C」である。
(検索)
次に、図1の検索処理部104の処理動作について説明する。
図31は、検索処理部104に入力する問合せデータの一例を示したものである。XMLでは、W3Cで提案されているXQuery(XML Query Language)という問合せ言語があり、これに基づいた問合せ記述方法に則っている。
図31に示す問合せデータには、「構造化文書DB「DB」の階層木の中に「BOOK」という要素があり、この「BOOK」という要素の中に、「AUTHOR」という要素があり、この「AUTHOR」という要素の中に、「太郎」という文字列を含むテキスト要素をもつ「FIRSTNAME」という要素と、さらに「田中」という文字列を含むテキスト要素もつ「LASTNAME」という要素がある」という条件が記述されている。
この条件では、「BOOK」という要素には、「AUTHOR」という要素があり、「AUTHOR」という要素には、「太郎」という文字列を含むテキスト要素をもつ「FIRSTNAME」という要素と、「田中」という文字列を含むテキスト要素もつ「LASTNAME」という要素という2つの要素を含むという、いわゆるAND条件が含まれている。
図31に示すような問合せデータは、クライアント201の検索部203からサーバ101へ送信され、サーバ101の要求処理部102で受信される。
以下、図32、図33に示すフローチャートを参照して、例えば、図31に示したような問合せデータを受信した検索処理部104の処理動作の概略を説明する。
要求処理部102で受信された問合せデータは、検索処理部104の問合せデータ解析部41に渡される。問合せデータ解析部41では、受け取った問合せデータの構文解析を行い、この結果を基に当該問合せデータから問合せグラフと呼ばれるグラフ構造を抽出する(ステップS101、ステップS102)。例えば、図31に示した問合せデータの場合、図34に示すような問合せグラフが得られる。ここでは、問合せグラフで表されるような問合せデータ中の構造をScと表す。
問合せグラフは、図34に示すように、問合せデータ中に含まれる要素(例えば、「db“DB”」、「BOOK」、「AUTHOR」「FIRSTNAME」「LASTNAME」)、や文字列(例えば「太郎」、「田中」)にそれぞれ対応する変数と、問合せデータ中に含まれる要素間の階層関係と文字列の包含関係に従って各変数を接続したグラフ形式で構成されている。
図34に示した問合せグラフでは、変数は、丸で囲まれたノードで表されており、丸のなかに変数名が記述されている。これを変数ノードと呼ぶ。また、問合せデータ中に指定されていた要素は、六角形のなかに「TAG」と書かれたノードで表されている。これをタグノードと呼ぶ。さらに、問合せデータ中に指定されていた文字列は、六角形のなかに「VALCMP」と書かれたノードで表されている。これを値比較タグノードと呼ぶ。
次に、問合せ実行部42は、問合せグラフに含まれる全ての変数の具体化を目標として、テーブルと呼ばれる変数集合の取り得る値の組み合わせを表すデータを次々と生成する。
まず、問合せグラフに含まれる全ての変数が1テーブルで具体化されているか判定する(ステップS103)。ステップS103でYesであれば、全ての変数の取り得る値の組合せが具体化されたので、これが結果となりステップS111で結果の出力処理を行う。なお、変数が取り得る値とは、OIDのことである。
以下、問合せグラフに含まれる全ての変数が1テーブルで具体化されていないならば(ステップS104のYes)、具体化されるまで、ステップS104〜ステップS110を繰り返す。
ステップS104では、索引データ記憶部114に記憶されている索引データを用いた検索が可能か判定する。「contains」など語彙索引系の関数があれば、構造化文書DB111中の索引データを用いて検索を高速化できる。この場合、索引スキャン部44で索引スキャンを実行する(ステップS105)。
ステップS106では、問合せグラフ上のある変数が具体化され、当該変数の下位階層にある変数が具体化されていて、当該変数の上位階層にある変数が具体化されていなければ(ステップS106のNo)、構造スキャン部43で構造スキャンを実行する(ステップS107)。
ステップS108では、複数テーブルに同一変数が発生しているか判定する。ステップS108でYesの場合は、データ系都合部45で当該複数のテーブルを結合するための結合処理を実行する(ステップS109)。
ステップS108でNoの場合は、ステップS110で上記以外の処理を行う。
先にも述べたがステップS111では、結果出力処理を行う。ここで各変数の取り得る値(OID)の組合せ(OIDの組合せ)がテーブルとして得られている。各組合せは、同じドキュメントIDをもつ複数のOIDからなり、よって、テーブル上の各組合せは、1つの構造化データに対応する。テーブル上の組合せから得られる各ドキュメントIDに対応する構造化データを構造化文書データ記憶部112から取り出すことにより、問合せデータに合致する構造化文書データの集合を得ることができる。
図35は、図34の問合せグラフに基づく検索処理を説明するための図である。
(1)問合せグラフには値比較タグノード、contains語彙索引系の関数があるので、文字列「太郎」に関して、図29に示すような索引データを用いて、索引スキャンを実行する。この結果、変数ノード$4が具体化する(図35(a)に示すTable1)。すなわち、変数ノード$4に対応するOIDとして、<文書A,4>、<文書B,4>、<文書B,7>が得られる。
(2)同様に、文字列「田中」に関して、図29に示すような索引データを用いて、索引スキャンを実行する。この結果、変数ノード$5が具体化する(図35(b)に示すTable12)。すなわち、変数ノード$5に対応するOIDとして、<文書1,5>、<文書2,8>が得られる。
(3)変数$4と$5が具体化されたので、これら変数の上位階層にある変数を具体化するために、構造スキャンを実行する。
ここで、図33に示すフローチャートを参照して、構造スキャンについて説明する。
まず、図35のTable1及びTable2から、(具体化された)変数$4、$5に対し得られた各オブジェクトIDに含まれる文書IDを読みとる(ステップS121)。
各文書IDに対応する差分構造データと、(当該差分構造データに付加されている管理情報に対応する)汎用構造データを、差分構造データ記憶部113及び汎用構造データ記憶部112からそれぞれ読み出す(ステップS122)。
各文書IDについて、差分構造データと汎用構造データとから、当該文書IDに対応する構造データを復元する(ステップS123)。
例えば、文書Aの構造データを復元する場合には、図10に示した差分構造データの完全繰返し形式で表された部分ツリーを元の展開形式で表し、図7に示したような構造データを復元する。
また、文書Bの構造データを復元する場合には、図15に示した差分構造データの完全繰返し形式で表された部分ツリーを元の展開形式で表し、発生回数「0」のノード(「ABSTRACT」ノード)を削除することにより、図12に示したような構造データを復元する。
次に、これら復元された各文書の構造データについて、Table1上の各オブジェクトデータを起点として、そこから上流方向へ辿ることで、問合せグラフ上の上流の変数ノードに一致するノードを探索する(ステップS124)。
構造データから得られた、問合せグラフ上の上流の変数ノードに一致するノードが、例えば、不定ノードの場合には、当該不定ノードのスロットIDを特定することができないため(ステップS125のNo)、ステップS127へ進む。また、構造データから得られた、問合せグラフ上の上流の変数ノードに一致するノードが不定ノードでない場合には、当該ノードのスロットIDは、当該構造データから特定可能であるので(ステップS125のYes)、ステップS126へ進む。
ここで、ステップS125におけるスロットlDを特定することができるか否か(不定ノードであるか否か)の判定方法の一例を説明する。文書オブジェクト格納部35には、前述したように、各文書がオブジェクトデータの配列として格納される。この配列内の各要素の位置情報がスロットIDである。そして、配列の先頭から順に、汎用構造データ中の各ノードに対応するオブジェクトデータを(差分構造データの左側のノードから順に、上流ノードから下流ノードの順に)優先的に格納し、この後に、文書ツリー中の不定ノードやテキストノードを格納するようになっている(図30参照)。
そこで、復元された構造データをルートノードからトラバースし、不定ノード「?」の場合を除いて発生回数の総和を取り出す。上位ノードが複数回発生していれば(例えば、2*)、その加重和とする。その値とスロットlDとを比較し、スロットlDの方が大きければ、スロットlDを特定できないことになる。但し、ルートノードの発生回数については総和をとらない。
例えば、図23に示した文書Cの場合、不定ノードの「LASTNAME」を除くと、「TlTLE」要素は1回、「AUTHORS」要素は1回、「AUTHOR」要素は2回、各「AUTHOR」要素には「FIRSTNEME」要素が1回ずつ出現し、さらに、「KEYWORD」要素が1回出現している。従って、当該文書Cについては、
1+1+2×(1+1)+1=7
となるから、「7」を越えたスロットlDは特定できないことになる。
ステップS126では、構造データを辿りることで、得られたノードのスロットIDを計算する。例えば、構造データのルートノードを起点として、当該得られたノードまでのオブジェクトデータをカウントすることで、スロットIDを求めることができる。
一方、ステップS127では、得られたノードのスロットIDを求めるために、文書オブジェクトデータ記憶部115に記憶されている当該文書IDに対応するオブジェクトレコードをサーチして、当該得られたノードのスロットIDを得る。
このようにして、復元された各構造データをスキャンして、図35(a)に示す変数$4に対応するTable1から、図35(c)に示す変数$3に対応するTable3が得られ、図35(b)に示す変数$5に対応するTable2から、図35(d)に示す変数$3に対応するTable4が得られる(ステップS128)。
Table1から、図35(c)に示す変数$3に対応するTable3が得られ過程を説明する。図34の変数ノード$3は、「AUTHOR」である。図7の文書Aの復元された構造データを参照して、スロットID「4」の「FIRSTNAME」から上流ノードを特定する「AUTHOR」ノードが得られる。当該ノードのスロットIDは、スロットID「0」のルートノードから数えて4番目のスロットに格納されているから、スロットIDは「3」である。
同様に、図12の文書Bの復元された構造データを参照して、スロットID「4」の「FIRSTNAME」から上流ノードを特定する「AUTHOR」ノードが得られる。当該ノードのスロットIDは、スロットID「0」のルートノードから数えて4番目のスロットに格納されているから、スロットIDは「3」である。
同様に、図12の文書Bの構造データを、スロットID「7」の「FIRSTNAME」から上流へ辿ることで、「AUTHOR」ノードが得られる。当該ノードのスロットIDは、スロットID「0」のルートノードから数えて7番目のスロットに格納されているから、スロットIDは「6」である。
このようにして、Table1から、変数ノード$3を具体化することができる(図35(c)に示すTable3)。すなわち、変数ノード$3に対応するOIDとして、<文書A,3>、<文書B,3>、<文書B,6>が得られる。
Table2から、図35(d)に示す変数$3に対応するTable4が得られ過程を説明する。図34の変数ノード$3は、「AUTHOR」である。図7の文書Aの復元された構造データを参照して、スロットID「5」の「LASTNAME」から上流ノードを特定する「AUTHOR」ノードが得られる。当該ノードのスロットIDは、スロットID「0」のルートノードから数えて4番目のスロットに格納されているから、スロットIDは「3」である。
同様に、図12の文書Bの復元された構造データを参照して、スロットID「8」の「LASTNAME」上流ノードを特定する「AUTHOR」ノードが得られる。当該ノードのスロットIDは、スロットID「0」のルートノードから数えて7番目のスロットに格納されているから、スロットIDは「6」である。
このようにして、Table2から、変数ノード$3を具体化することができる(図35(d)に示すTable4)。すなわち、変数ノード$3に対応するOIDとして、<文書A,3>、<文書B,6>が得られる。
(4)上記(2)(3)に示したように、別系統で変数#3がそれぞれ具体化されたので、Table3とTable4との結合処理を実行する。Table3とTable4には、OID<文書A、3>及びOID<文書B、6>が出現している。従って、両者を含む図35(e)に示すTeble5を得る。
(5)変数#4、#5、#3が具体化されたので、これら変数の上位階層にある変数#2(「BOOK」)を具体化するために、構造スキャンを実行する。
まず、OID<文書A、3>に関し、図33に示す構造スキャンを行う。図7の文書Aの復元された構造データを参照して、スロットID「3」の「AUTHOR」の上流ノードの「BOOK」ノードを特定する。当該ノードのスロットIDは、スロットID「0」のルートノードである。
次に、OID<文書B、6>に関し、図33に示す構造スキャンを行う。図12の文書Bの復元された構造データを参照して、スロットID「6」の「AUTHOR」の上流ノードの「BOOK」ノードを特定する。当該ノードのスロットIDは、スロットID「0」のルートノードである。
このようにして、Table5から、変数ノード$2を具体化することができる(図35(f)に示すTable6)。すなわち、変数ノード$2に対応するOIDとして、<文書A,0>、<文書B,0>が得られる。
ここでは、OID<文書A,0>とOID<文書B,0>が、検索結果として問合せ実行部44から出力される。結果生成部46は、当該検索結果として得られたOIDを基に結果データを生成する(図36参照)。
図36は、図31の問合せデータを満足する結果データの一例である。図35(f)に示したTable6で得られたOIDのリストを基に、文書オブジェクトデータ記憶部115から当該OIDに対応するノード以下の構造化文書データの全部あるいは一部のデータを読出して、結果データを生成する。図36に示す結果データには、文書Aと文書Bが含まれている。
図36に示すような検索結果は、要求処理部102から検索要求元のクライアント201へ渡される。クライアント201では、サーバ101から受け取った構造化データを出力部205内の表示部へ表示する。
図37は、問合せデータの他の例を示したものである。この問合せデータは、「BOOK」要素の中の「AUTHOR」要素であって、「LASTNAME」という要素の中に「田中」という文字列を含む「AUTHOR」の一覧を検索する」という意味をもつ。図31の問合せデータでは、「BOOK」の一覧を結果として要求されているが、図37に示す問合せデータでは、「AUTHOR」の一覧を結果として要求されている。
図37に示した問合せデータの場合、図38に示すような問合せグラフが得られる。
図39は、図38の問合せグラフに基づく検索処理を説明するための図である。
(1)問合せグラフには値比較タグノード、contains語彙索引系の関数があるので、文字列「田中」に関して、図29に示すような索引データを用いて、索引スキャンを実行する。この結果、変数ノード$3が具体化する(図39(a)に示すTable7)。すなわち、変数ノード$3に対応するOIDとして、<文書A,5>、<文書B,8>、が得られる。
(2)変数$3が具体化されたので、この変数の上位階層にある変数$2を具体化するために、構造スキャンを実行する。
まず、文書Aと文書Bの差分構造データと(当該差分構造データに付加されている管理情報に対応する)汎用構造データとから、文書Aと文書Bの構造データをそれぞれ復元する。
図7の文書Aの構造データを、スロットID「5」の「LASTNAME」から上流へ辿ることで、「AUTHOR」ノードが得られる。当該ノードのスロットIDは、スロットID「0」のルートノードから数えて4番目のスロットに格納されているから、スロットIDは「3」である。
同様に、図12の文書Bの構造データを、スロットID「8」の「LASTNAME」から上流へ辿ることで、「AUTHOR」ノードが得られる。当該ノードのスロットIDは、スロットID「0」のルートノードから数えて7番目のスロットに格納されているから、スロットIDは「6」である。
このようにして、変数ノード$2を具体化することができる(図39(b)に示すTable3)。すなわち、変数ノード$2に対応するOIDとして、<文書A,3>、<文書B,6>が得られる。
これら2つのOIDが図37の問合せデータを満足する検索結果である。
結果生成部46は、図39(b)に示したTable8で得られたOIDのリストを基に、文書オブジェクトデータ記憶部115から当該OIDに対応するノード以下の構造化文書データの全部あるいは一部のデータを読出して、結果データを生成する。図40に示す結果データには、文書AのスロットID「3」、すなわち、1番目の「AUTHOR」ノード以下の部分文書と、文書BのスロットID「6」、すなわち、2番目の「AUTHOR」ノード以下の部分文書が含まれている。
以上説明したように、上記実施形態では、構造化文書DB111に新たな構造化文書データを格納する際には、構造化文書DB111に既に記憶されている各構造化文書データに含まれている構造及び新たな構造化文書データに含まれている構造を含む汎用構造と、新たな構造化文書データの構造との差分構造を求める。この差分構造は、構造化文書DB111に既に記憶されている各構造化文書データの構造を含む汎用構造を新たな構造化文書データの構造を用いて更新することにより得る。新たな構造化文書データの各要素を当該差分構造に基づき並べた配列が文書オブジェクトデータ記憶部115に記憶される。
上記実施形態によれば、新たな構造化文書データを格納する際には、当該新たな構造化文書データの構造を用いて汎用構造を更新し、当該更新された汎用構造と当該新たな構造化文書データの構造との差分構造、及び当該差分構造に基づき新たな構造化文書データの各要素を並べた配列とを記憶する。従って新たな構造化文書データについて記憶すべきデータ量を大幅に削減することができる。また、配列内の各要素の位置は、差分構造上の当該要素の配置位置に対応するため、新たな構造化文書データの構造から容易に所望の要素の記憶エリアを特定することができる。
また、構造化文書DB111に記憶されている構造化文書データから(検索条件で指定された)所望の要素を検索する際には、当該構造化文書データの構造及び当該構造化文書データが構造化文書DB111で記憶されるまでに構造化文書DB111で既に記憶された各構造化文書データの構造を含む汎用構造と、当該構造化文書データの構造との差分構造とから、当該構造化文書データの構造を復元し、復元された構造から当該所望の要素を検索する。オブジェクトデータ記憶部115には、上記差分構造に基づき並べられた当該構造化文書データの複数の要素の配列が記憶されている。この配列内の当該所望の要素の位置情報(スロットID)は、復元された構造内の当該所望の要素の配置位置に基づき求める。
上記実施形態によれば、構造化文書DB111に記憶されている構造化文書データの構造を復元して、当該構造を辿ることで所望の要素の有無を判定するとともに、少ないデータ参照量で当該所望の要素の記憶エリア(スロットID)を特定することができ、構造化文書データの検索が高速に行える。
本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク(フレキシブルディスク、ハードディスクなど)、光ディスク(CD−ROM、DVDなど)、半導体メモリなどの記録媒体に格納して頒布することもできる。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
本発明の実施形態に係る構造化文書管理システムの機能的な構成例を示した図。 サーバのハードウエア的な構成例を示した図。 構造化文書データの一例(文書A)を示した図。 構造化文書データの一例(文書B)を示した図。 構造化文書データベースのデータ構造を論理的に表した図。 文書Aの文書ツリーを示した図。 文書Aの構造データを示した図。 汎用構造データの一例を示した図。 図8の汎用構造データと文書Aの構造データの差分を示す第1の差分構造データを示した図。 図8の汎用構造データと文書Aの構造データの差分を示す第2の差分構造データを示した図。 文書Bの文書ツリーを示した図。 文書Bの構造データを示した図。 汎用構造データの他の例を示した図。 図13の汎用構造データと文書Bの構造データの差分を示す第1の差分構造データを示した図。 図13の汎用構造データと文書B構造データの差分を示す第2の差分構造データを示した図。 差分構造データの記憶例を示した図。 文書オブジェクトレコード(配列)の記憶例を示した図。 構造データ抽出処理を説明するためのフローチャート。 汎用構造登録処理を説明するためのフローチャート。 差分構造登録処理を説明するためのフローチャート。 差分構造登録処理を説明するためのフローチャート。 構造化文書データの一例(文書C)を示した図。 文書Cの文書ツリーを示した図。 文書Bの構造データを示した図。 図13の汎用構造データと文書Cの構造データの差分を示す第1の差分構造データを示した図。 図13の汎用構造データと文書Cの構造データの差分を示す第2の差分構造データを示した図。 差分構造データの記憶例を示した図。 文書オブジェクト格納処理を説明するためのフローチャート。 索引データ記憶部に記憶される索引データのデータ構造を模式的に示した図。 文書オブジェクトレコード(配列)の記憶例を示した図。 問合せデータの一例を示した図。 検索処理部の処理動作の概略を説明するためのフローチャート。 構造スキャン部の処理動作を説明するためのフローチャート。 図31の問合せデータから得られる問合せグラフを示した図。 図34の問合せグラフに基づく検索処理を説明するための図。 結果データの一例を示した図。 問合せデータの他の例を示した図。 図37の問合せデータから得られる問合せグラフを示した図。 図38の問合せグラフに基づく検索処理を説明するための図。 結果データの他の例を示した図。
符号の説明
31…文書データ解析部、32…構造データ抽出部、33…汎用構造登録部、34…差分構造登録部、41…問合せデータ構文解析部、42…問合せ実行部、43…構造スキャン部、44…索引スキャン部、45…データ結合部、46…結果生成部、101…サーバ装置、102…要求処理部、103…格納処理部、104…検索処理部、111…構造化文書データベース、112…汎用構造データ記憶部、113…差分構造データ記憶部、114…索引データ記憶部、115…文書オブジェクトデータ記憶部、201…クライアント装置、202…構造化文書登録部、203…検索部、204…入力部、205…表示部。

Claims (10)

  1. 複数の要素を含む各構造化文書データを記憶する記憶手段を有する構造化文書管理装置であって、
    前記記憶手段で記憶された各構造化文書データに含まれている各構造を含む汎用構造を記憶する汎用構造記憶手段と、
    新たな構造化文書データを入力する入力手段と、
    前記汎用構造記憶手段で記憶された汎用構造を、前記記憶手段で記憶された各構造化文書データ及び前記新たな構造化文書データにそれぞれ含まれている各構造を含む新たな汎用構造に更新する手段と、
    前記新たな構造化文書データの構造と前記新たな汎用構造との差分構造を求める手段と、
    前記差分構造を記憶する差分構造記憶手段と、
    前記新たな構造化文書データの複数の要素を前記新たな差分構造に基づき並べた配列を前記記憶手段に記憶する手段と、
    を具備したことを特徴とする構造化文書管理装置。
  2. 前記差分構造には、前記新たな汎用構造の各要素の有無を示す情報及び前記新たな構造化文書データの部分構造の繰返し回数が含まれていることを特徴とする請求項1記載の構造化文書管理装置。
  3. 前記新たな構造化文書データの各要素の前記配列内の位置情報が当該要素を特定するための識別子であることを特徴とする請求項1記載の構造化文書管理装置。
  4. 複数の要素を含む各構造化文書データを記憶する記憶手段と、
    所望の要素を検索するための検索条件を入力する入力手段と、
    前記記憶手段に記憶された第1の構造化文書データから前記所望の要素を検索する検索手段とを具備した検索装置であって、
    前記検索手段は、
    前記第1の構造化文書データが前記記憶手段で記憶されるまでに当該記憶手段で記憶された各構造化文書データ及び前記第1の構造化文書データにそれぞれ含まれている各構造を含む汎用構造と、前記第1の構造化文書データの構造との差分構造とから、前記第1の構造化文書データの構造を復元する手段と、
    復元された構造から前記所望の要素を特定する手段と、
    を具備したことを特徴とする検索装置。
  5. 前記記憶手段は、前記第1の構造化文書データの複数の要素を前記差分構造に基づき並べた配列を記憶し、
    前記検索手段は、前記復元された構造内の前記所望の要素の配置位置に基づき、前記配列内の前記所望の要素の位置情報を求めることを特徴とする請求項4記載の検索装置。
  6. 複数の要素を含む各構造化文書データを記憶する記憶手段に新たな構造化文書データを記憶するための記憶方法であって、
    前記記憶手段で記憶された各構造化文書データ及び前記新たな構造化文書データにそれぞれ含まれている各構造を含む汎用構造を求めるステップと、
    前記新たな構造化文書データの構造と前記汎用構造との差分構造を求めるステップと、
    前記新たな構造化文書データの複数の要素を前記差分構造に基づき並べた配列を前記記憶手段に記憶するステップと、
    を有することを特徴とする記憶方法。
  7. 複数の要素を含む各構造化文書データを記憶する記憶手段に記憶された第1の構造化文書データから、前記所望の要素を検索するための検索方法であって、
    前記第1の構造化文書データが前記記憶手段で記憶されるまでに当該記憶手段で記憶された各構造化文書データ及び前記第1の構造化文書データにそれぞれ含まれている各構造を含む汎用構造と、前記第1の構造化文書データの構造との差分構造とから、前記第1の構造化文書データの構造を復元するステップと、
    復元された構造から前記所望の要素を検索するステップと、
    を有することを特徴とする検索方法。
  8. 前記復元された構造内の前記所望の要素の配置位置に基づき、前記記憶手段に記憶された、前記第1の構造化文書データの複数の要素を前記差分構造に基づき並べた配列内の前記所望の要素の位置情報を求めるステップをさらに有することを特徴とする請求項7記載の検索方法。
  9. 複数の要素を含む各構造化文書データを記憶する記憶手段を備えたコンピュータに新たな構造化文書データを記憶するためのプログラムであって、
    前記コンピュータに、
    前記記憶手段で記憶された各構造化文書データ及び前記新たな構造化文書データにそれぞれ含まれている各構造を含む汎用構造を求めるステップと、
    前記新たな構造化文書データの構造と前記汎用構造との差分構造を求めるステップと、
    前記新たな構造化文書データの複数の要素を前記差分構造に基づき並べた配列を前記記憶手段に記憶するステップと、
    を実行させるプログラム。
  10. 複数の要素を含む各構造化文書データを記憶する記憶手段を備えたコンピュータを、前記記憶手段で記憶された第1の構造化文書データから所望の要素を検索する検索装置として機能させるためのプログラムであって、
    前記コンピュータに、
    前記第1の構造化文書データが前記記憶手段で記憶されるまでに当該記憶手段で記憶された各構造化文書データ及び前記第1の構造化文書データにそれぞれ含まれている各構造を含む汎用構造と、前記第1の構造化文書データの構造との差分構造とから、前記第1の構造化文書データの構造を復元するステップと、
    復元された構造から前記所望の要素を検索するステップと、
    を実行させるプログラム。
JP2004208885A 2004-07-15 2004-07-15 構造化文書管理装置、検索装置、記憶方法、検索方法及びプログラム Expired - Lifetime JP4309818B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2004208885A JP4309818B2 (ja) 2004-07-15 2004-07-15 構造化文書管理装置、検索装置、記憶方法、検索方法及びプログラム
EP05254160A EP1617345A1 (en) 2004-07-15 2005-07-01 Apparatus, method and program for managing and searching structured documents
US11/182,008 US8082492B2 (en) 2004-07-15 2005-07-15 Structured-document management apparatus, search apparatus, storage method, search method and program
CNB2005100846285A CN100565508C (zh) 2004-07-15 2005-07-15 结构化文档管理设备、搜索设备、存储和搜索方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004208885A JP4309818B2 (ja) 2004-07-15 2004-07-15 構造化文書管理装置、検索装置、記憶方法、検索方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2006031377A true JP2006031377A (ja) 2006-02-02
JP4309818B2 JP4309818B2 (ja) 2009-08-05

Family

ID=34941800

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004208885A Expired - Lifetime JP4309818B2 (ja) 2004-07-15 2004-07-15 構造化文書管理装置、検索装置、記憶方法、検索方法及びプログラム

Country Status (4)

Country Link
US (1) US8082492B2 (ja)
EP (1) EP1617345A1 (ja)
JP (1) JP4309818B2 (ja)
CN (1) CN100565508C (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008065543A (ja) * 2006-09-06 2008-03-21 Toshiba Corp 構造化文書検索装置及び構造化文書検索方法

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070162470A1 (en) * 2006-01-10 2007-07-12 International Business Machines Corporation Method and apparatus for event transformation and adaptive correlation for monitoring business solutions
US20070239742A1 (en) * 2006-04-06 2007-10-11 Oracle International Corporation Determining data elements in heterogeneous schema definitions for possible mapping
US9189478B2 (en) * 2008-04-03 2015-11-17 Elumindata, Inc. System and method for collecting data from an electronic document and storing the data in a dynamically organized data structure
US8554800B2 (en) * 2008-07-30 2013-10-08 Portool Ltd. System, methods and applications for structured document indexing
US9740765B2 (en) 2012-10-08 2017-08-22 International Business Machines Corporation Building nomenclature in a set of documents while building associative document trees
US10262035B2 (en) * 2013-11-14 2019-04-16 Hewlett Packard Enterprise Development Lp Estimating data
US10558679B2 (en) * 2016-02-10 2020-02-11 Fuji Xerox Co., Ltd. Systems and methods for presenting a topic-centric visualization of collaboration data
US11003635B2 (en) * 2016-08-24 2021-05-11 Sap Se Database scheme for storing generic data
US10236422B1 (en) * 2018-05-17 2019-03-19 Eie Materials, Inc. Phosphors with narrow green emission

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3028738B2 (ja) * 1994-11-10 2000-04-04 富士ゼロックス株式会社 文書共通論理情報編集装置
CA2242158C (en) * 1997-07-01 2004-06-01 Hitachi, Ltd. Method and apparatus for searching and displaying structured document
JP3692764B2 (ja) * 1998-02-25 2005-09-07 株式会社日立製作所 構造化文書登録方法、検索方法、およびそれに用いられる可搬型媒体
JP2000057163A (ja) 1998-08-12 2000-02-25 Nec Corp 構造化文書データベースシステム
JP3390357B2 (ja) * 1999-02-12 2003-03-24 日本電気株式会社 木構造データ編集システムにおける木構造差分出力方法及び装置
JP3492246B2 (ja) 1999-07-16 2004-02-03 富士通株式会社 Xmlデータ検索処理方法および検索処理システム
JP2001167087A (ja) * 1999-12-14 2001-06-22 Fujitsu Ltd 構造化文書検索装置,構造化文書検索方法,構造化文書検索用プログラム記録媒体および構造化文書検索用インデックス作成方法
JP2001307032A (ja) * 2000-04-27 2001-11-02 Matsushita Electric Ind Co Ltd 携帯端末
JP2002034618A (ja) 2000-07-28 2002-02-05 Casio Comput Co Ltd 腕時計バンド及び腕時計
WO2002017115A2 (en) * 2000-08-21 2002-02-28 Thoughtslinger Corporation Simultaneous multi-user document editing system
US7185044B2 (en) * 2000-11-06 2007-02-27 The Weather Channel Weather information delivery systems and methods providing planning functionality and navigational tools
JP2003030039A (ja) * 2001-04-12 2003-01-31 Matsushita Electric Ind Co Ltd 構造化文書配信装置及び構造化文書配信システム
JP4045400B2 (ja) * 2001-08-24 2008-02-13 富士ゼロックス株式会社 検索装置及び検索方法
US7899067B2 (en) * 2002-05-31 2011-03-01 Cisco Technology, Inc. Method and apparatus for generating and using enhanced tree bitmap data structures in determining a longest prefix match
US7669120B2 (en) 2002-06-21 2010-02-23 Microsoft Corporation Method and system for encoding a mark-up language document
JP2004062600A (ja) * 2002-07-30 2004-02-26 Fujitsu Ltd 構造型文書の変換方法、復元方法、変換及び復元方法及びプログラム
JP3880504B2 (ja) * 2002-10-28 2007-02-14 インターナショナル・ビジネス・マシーンズ・コーポレーション 構造化・階層化コンテンツ用処理装置、構造化・階層化コンテンツ用処理方法、及びプログラム
JP4114462B2 (ja) * 2002-11-13 2008-07-09 沖電気工業株式会社 情報検索装置および情報検索システム
US7111000B2 (en) * 2003-01-06 2006-09-19 Microsoft Corporation Retrieval of structured documents
US7873663B2 (en) * 2004-01-13 2011-01-18 International Business Machines Corporation Methods and apparatus for converting a representation of XML and other markup language data to a data structure format
US20050289185A1 (en) * 2004-06-29 2005-12-29 The Boeing Company Apparatus and methods for accessing information in database trees

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008065543A (ja) * 2006-09-06 2008-03-21 Toshiba Corp 構造化文書検索装置及び構造化文書検索方法

Also Published As

Publication number Publication date
CN100565508C (zh) 2009-12-02
JP4309818B2 (ja) 2009-08-05
US20060015809A1 (en) 2006-01-19
US8082492B2 (en) 2011-12-20
EP1617345A1 (en) 2006-01-18
CN1722138A (zh) 2006-01-18

Similar Documents

Publication Publication Date Title
US7293018B2 (en) Apparatus, method, and program for retrieving structured documents
JP3754253B2 (ja) 構造化文書検索方法、構造化文書検索装置及び構造化文書検索システム
JP4637113B2 (ja) 階層データの好ましいビューを構築するための方法
JP5407043B2 (ja) バイナリにエンコードされたxmlデータの効率的な区分的アップデート
JP3842573B2 (ja) 構造化文書検索方法、構造化文書管理装置及びプログラム
US8209352B2 (en) Method and mechanism for efficient storage and query of XML documents based on paths
US7263525B2 (en) Query processing method for searching XML data
US20040220912A1 (en) Techniques for changing xml content in a relational database
US7668888B2 (en) Converting object structures for search engines
US8082492B2 (en) Structured-document management apparatus, search apparatus, storage method, search method and program
JP2007226452A (ja) 構造化文書管理装置、構造化文書管理プログラムおよび構造化文書管理方法
JP4247135B2 (ja) 構造化文書記憶方法、構造化文書記憶装置、構造化文書検索方法
JP4247108B2 (ja) 構造化文書検索方法、構造化文書検索装置、及びプログラム
US20060161525A1 (en) Method and system for supporting structured aggregation operations on semi-structured data
US8171040B2 (en) Method and system for navigation of a data structure
Liu et al. An XML-enabled data extraction toolkit for web sources
JP2006127235A (ja) 構造化文書管理システム、構造化文書管理方法及びプログラム
JP4724177B2 (ja) Xmlデータにアクセスするためのインデックス
JP3914081B2 (ja) アクセス権限設定方法および構造化文書管理システム
US20090307187A1 (en) Tree automata based methods for obtaining answers to queries of semi-structured data stored in a database environment
JP3999093B2 (ja) 構造化文書検索方法及び構造化文書検索システム
Molnar et al. Conceptual graph driven modeling and querying methods for RDMBS and XML databases
JP3842572B2 (ja) 構造化文書管理方法および構造化文書管理装置およびプログラム
JP3842576B2 (ja) 構造化文書編集方法及び構造化文書編集システム
JP4289022B2 (ja) 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080909

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081110

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090106

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090306

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

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090508

R151 Written notification of patent or utility model registration

Ref document number: 4309818

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120515

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120515

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130515

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130515

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140515

Year of fee payment: 5