JP3842576B2 - 構造化文書編集方法及び構造化文書編集システム - Google Patents
構造化文書編集方法及び構造化文書編集システム Download PDFInfo
- Publication number
- JP3842576B2 JP3842576B2 JP2001098189A JP2001098189A JP3842576B2 JP 3842576 B2 JP3842576 B2 JP 3842576B2 JP 2001098189 A JP2001098189 A JP 2001098189A JP 2001098189 A JP2001098189 A JP 2001098189A JP 3842576 B2 JP3842576 B2 JP 3842576B2
- Authority
- JP
- Japan
- Prior art keywords
- document
- structured document
- search
- structured
- tag
- 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
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明の属する技術分野】
本発明は、階層化された論理構造を持つ構造化文書データベースに格納されている構造化文書の編集方法および、それを用いた構造化文書編集装置に関する。
【0002】
【従来の技術】
現在、IT(情報技術)の進化により、莫大な量の情報が容易に入手できるようになった。その一方で必要な情報が大量のデータに埋没してしまい、十分に活用できないという弊害も発生している。情報が大量に存在していても、それをうまく活用できなければ意味がない。
【0003】
そこで、特定の個人や部門が保有するノウハウや業務データのうち企業の経営に重要なものを蓄積して、「経営資産」として活用しようとする活動、すなわち、ナレッジマネージメントが提唱されている。
【0004】
例えば、特許明細書や、週報など、文書の種類によっては、その書式が予め定められて、1つの書式に統一されているのが一般的である。1つの書式に統一された文書もあれば、全く書式のない自由書式の文書も数多く存在する。
【0005】
従って、ナレッジマネージメントを実現するためには、このような文書構造が予め定められているような文書も、それ以外の自由書式の文書も全て格納管理できるデータベースが必要となる。
【0006】
次世代のナレッジマネージメントの中核技術として期待されている技術がXMLである。XML(Extesible Markup Language)は柔軟な拡張性と連携性を備えた標準のドキュメント記述言語であり、主要ベンダーからのサポートも約束されている。
【0007】
一方、近年のインターネット技術の発達により、WWW(World Wide Web)に代表されるネットワーク上の文書共有システムが急速に普及している。WWWでは、ネットワーク上の文書が現在、HTML(HyperText Markup Language)で記述されている。この分野においてもHTMLに継ぐ次世代の文書記述言語としてXMLが期待されている。XMLでは、文書データの構造と表示スタイルを分けて定義することができるため文書構造の変更や文書の再利用がしやすい、タグを用いて文書の構造を厳密に定義できるためタグの条件指定による検索に適している、といった特徴がある。
【0008】
このような、HTML、XMLで記述された文書は構造化文書と呼ばれており、今後ますます構造化文書をネットワーク上で共有する場面が増えることが予想される。特にXMLで記述された構造化文書に関しては、タグの条件指定による検索要求(クエリ)をクライアントから発行して、サーバ上に置かれた構造化文書の中から所望のデータを検索する検索システムの構築が普及すると期待される。以下、ネットワーク上の構造化文書のことを単に文書と呼ぶことにする。
【0009】
一方、インターネットでWWWを通じて得られる文書は、不特定多数のユーザが共有して閲覧することが前提となるため、ユーザ個人のタグ(あるいはマークやコメント)を通常付加することができないようになっている。
【0010】
しかしながら、文書が例えば、営業員が閲覧する顧客データのとき、各営業員が顧客への訪問や案件処理の優先順位(緊急度)を個人的にタグとしてつけたいという要望が生ずる場合がある。あるいは、文書が特許データのとき、各特許に対しての評価や、何年何月何日に閲覧したかをタグとして追加したいという要望が生ずる場合がある。
【0011】
従って、書き換えが許可されていない構造化文書データベースから、ネットワーク経由で不特定多数のユーザが構造化文書を検索表示するシステムにおいて、ユーザが個人用のタグを追加できる仕組みが望まれている。
【0012】
ここで、上記の要望に応えるための従来技術として、文書に対してユーザが個人的なマークやコメント等の情報を付加する方法が、特開2001−22749号公報に開示されている。そこでは、文書を提供するサーバ側が、予め個人付加情報データベースや個人付加情報管理部を文書とともに保持しており、ユーザが構造化文書を表示する際にマークやコメントを付与して表示することで、組織内の複数メンバー間でこれらの個人付加情報をつけた文書を共有して閲覧する方式が提案されている。
【0013】
しかしながら、上記の方法では文書を提供するサーバと文書を表示するクライアントの両方を新規に作りこむ必要がある。したがって、文書を提供するサーバが外部組織に属していて、その構成を変えることが許可されていない場合にはこの方法を適用することができない。
【0014】
また、上記の方法は、新規に付加した個人付加情報はマークやコメントを想定しているため、個人付加情報を基に構造化文書を検索するといった機能は用意されていない。しかしながら、例えば文書が特許データのとき、自分で付与した評価が「A」の特許だけを検索したい、といった要望が生ずる場合がある。さらに、例えば文書のタグが閲覧日であり、その子要素の「年」、「月」、「日」を取り得る場合もあるため、個人用のタグ自体も階層構造を持つことが可能であることが望まれている。
【0015】
以上より、文書を提供するサーバの構成を変えることなく、個人用のタグを追加するための構造化文書の編集や、編集内容を反映した構造化文書の検索が行えるシステムが望まれている。
【0016】
特に、追加した個人用のタグを基にクライアントから検索できたり、そのために、個人用のタグは階層構造を持つことができることが望まれている。
【0017】
【発明が解決しようとする課題】
以上説明したように、サーバ側に構造化文書をおき、ネットワーク経由でクライアント側から検索要求を発行して所望の構造化文書を検索表示する形態において、構造化文書の書き換えが許可されていないときであってもユーザが個人用のタグを付加する編集を行いたいという要望に対し、特開2001−22749号公報に開示されている方法では、文書を提供するサーバ構成の変更が許可されていない場合に適用できないという問題点があった。
【0018】
また、上記開示されている方法は、新規に付加したマークやコメント等の個人付加情報を文書に付加して表示するためのものであり、個人付加情報を基に構造化文書を検索することはできないという問題点があった。
【0019】
そこで、本発明は、上記問題点に鑑み、構造化文書データベースを有し、その構造化文書データベースに格納されている構造化文書をクライアントからの要求に応じて提供するサーバの構成を変えることなく、また、構造化文書データベースに対し、何ら操作を行うことなく、構造化文書データベースに格納されている構造化文書に個人用のタグを追加する編集と、その編集した結果を反映した構造化文書の検索が容易に行える構造化文書編集方法およびそれを用いた構造化文書編集装置および端末装置およびプログラムを提供することを目的とする。
【0020】
【課題を解決するための手段】
本発明は、階層化された論理構造を持つ構造化文書データベースに格納されている複数の構成要素からなる構造化文書に追加する新たな構成要素を作成して、この作成された新たな構成要素を該構造化文書に対応付けて記憶し、前記構成要素とその値を検索条件に含む検索要求に基づき、前記記憶手段で記憶された新たな構成要素を検索するための第1の検索要求と、前記構造化文書データベースに格納された構造化文書を検索するための第2の検索要求とを生成し、前記第2の検索要求に基づき前記構造化文書データベースから検索された構造化文書に前記第1の検索要求に基づき検索された新たな構成要素が対応付けられているときは、該構造化文書に該新たな構成要素を追加して表示することを特徴とする。
【0021】
本発明によれば、構造化文書を提供する側(例えば、構造化文書管理システムおよびWWWサーバ)の構成は一切変更することなく、しかも、構造化文書データベースに対しては何ら操作を行う必要なく、書き換えが許可されていない構造化文書データべース上の構造化文書への編集(加工)と、その編集した結果を含めた構造化文書の検索が容易に行える。
【0022】
【発明の実施の形態】
まず、本発明の実施形態について説明する前に、構造化文書管理システムについて説明する。
【0023】
(構造化文書管理システムの説明)
構造化文書として、XMLやSGMLなどで記述した文書が挙げられる。SGML(Standard Generalized Markup Language)とは、ISO(国際標準化機構)で定められた規格である。XML(eXtensible Markup Language)とは、W3C(World Wide Web Consortium)にて定められた規格である。それぞれ文書を構造化することを可能とする構造化文書規約である。
【0024】
以下、構造化文書として、XMLにて記述された文書を例に説明を進める。構造化文書の文書構造を定義したデータ(文書構造定義データ)をスキーマと呼ぶ。XMLではそのスキーマを定義するためにXML−SchemaやXDR(XML Data Reduced)などのスキーマ言語が提案されている。ここでは、例えば、XDRでのスキーマを記述する場合を例にとり説明する。
【0025】
スキーマも、構造化文書管理システムの管理対象の構造化文書であり、従って、スキーマ文書と呼ぶことがある。スキーマ文書と区別するために、特許明細書やメール、週報、広告などの種々雑多な内容を有す文書をコンテンツ文書と呼ぶこともある。
【0026】
構造化文書管理システムでは、上記スキーマ文書、上記コンテンツ文書、さらに、後述するようなユーザからの検索要求内容を記述したクエリ、すなわち、クエリ文書も管理対象とし、これらを総称して「文書」と呼ぶ。
【0027】
以下、特にことわりがない場合、「文書」と呼ぶときは、コンテンツ文書、スキーマ文書、クエリ文書を全て指すものとする。
【0028】
まず、実施形態の説明を前に、XMLについて簡単に説明する。
【0029】
図3は、XMLで記述された構造化文書の一例として、「特許」情報の例を示したものである。XMLやSGMLは、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがあり、文書構造情報の構成要素を開始タグと終了タグで囲むことにより、文書中の文字列(テキスト)区切りと、そのテキストが構造上どの構成要素に属するのかを明確に記述することができる。
【0030】
ここで開始タグとは要素名称を記号「<」、「>」で閉じたものであり、終了タグとは要素名称を記号「</」と「>」で閉じたものである。タグに続く構成要素の内容が、テキスト(文字列)または子供の構成要素の繰り返しである。また開始タグには「<要素名称 属性=“属性値”>」などのように属性情報を設定することができる。「<特許DB></特許DB>」のようにテキストを含まない構成要素は、簡易記法として「<特許DB/>」のように表わすこともできる。
【0031】
図3に示した文書は、「特許」タグから始まる要素をルート(根)とし、その子要素として「タイトル」、「出願日」、「出願者」、「要約」タグから始まる要素集合が存在する。また、例えば、「タイトル」タグから始まる要素には「XMLデータベース」といった、1つのテキスト(文字列)が存在する。
【0032】
XMLなどの構造化文書は、任意の構成要素を繰り返し含んでいたり、さらには文書構造があらかじめ決まっていない(RDB(リレーショナルデータベース)やOODB(オブジェクト指向データベース)のスキーマでは定義できない)のが普通である。
【0033】
図3に示したような構造化文書を論理的に表現するために、図4に示すようなツリー表現が用いられる。ツリーは、ノード(番号が付され、円形で示されたもの)とアーク(ノードを表す円形間をつなぐデータ付き線)と四角形で囲まれたテキストから構成されている。
【0034】
ノードは文書オブジェクトに対応し、ノードからタグ名や属性名に相当するラベルが付与された複数のアークが出てきている。そのアークの先は、ノードまたは要素値としての文字列(テキスト)である。ノードの中に記載されている英数字(#0、#49)などはオブジェクトIDである。
【0035】
図4に示したツリー構造を図3に示した構造化文書の文書オブジェクトツリーと呼ぶ。
【0036】
図1は、本実施形態に係る構造化文書管理システムの構成例を示したものである。図1において、構造化文書管理システムは、大きく分けて、要求制御部1、アクセス要求処理部2、検索要求処理部3、データアクセス部4、文書記憶部5、インデックス記憶部6から構成されている。文書記憶部5、インデックス記憶部6は例えば、外部記憶装置を用いて構成される。
【0037】
図1のシステム構成は、ソフトウエアを用いて実現可能である。
【0038】
要求制御部1は、要求受付部11と結果処理部12から構成されている。要求受付部11は、ユーザからの文書格納や文書取得、文書検索などの要求を受け付けて、アクセス要求処理部2を呼び出す。結果処理部12は、アクセス要求処理部2が処理した結果を要求元のユーザに返す処理を行う。
【0039】
アクセス要求処理部2は、ユーザからの文書格納や文書取得などの要求に対応した複数の処理部から構成されている。つまり、文書格納部21、文書取得部22、文書削除部23から構成されている。
【0040】
文書格納部21は、文書記憶部5中の論理的な指定エリアに文書を格納する処理を行う。
【0041】
文書取得部22は、文書記憶部5中の論理的なエリアが指定されたときに、その指定エリアに存在する文書を取得する処理を行う。
【0042】
文書削除部23は、文書記憶部5中の論理的な指定エリアに存在する文書を削除する処理を行う。
【0043】
文書記憶部5は、構造化文書データベースであり、例えば、図8に示すように、文書をUNIXのディレクトリ構造のように階層的にツリー構造状に格納している。
【0044】
図8に示すように、構造化文書データベースは、図4に示したような1つの構造化文書のツリー構造と同様に表現できる。すなわち、任意のノード以下の部分階層木(部分ツリー)は、構造化文書データベースから切り出された構造化文書であり、ここでは、これを文書オブジェクトツリーと呼ぶ。各ノードにはオブジェクトIDが割り当てられている。オブジェクトIDは、構造化文書データベース内ではユニークな数値を持つものとする。
【0045】
階層木のルートとなるノードには、それがルートノードであることを特定するためのオブジェクトID「#0」が割り当てられるものとする。
【0046】
ルートノード、すなわち、「#0」のノードからは「root」タグを先頭に持つ「#1」のノードへリンクが張られている。「#1」のノードからは、「特許DB」タグを先頭にもつ「#2」ノードへのリンクが張られている。「#2」ノードからは、「特許」タグを先頭に持つ「#42」ノード、「#52」ノード、「#62」ノードへのリンクがそれぞれ張られている。
【0047】
図3に示した「特許」情報は、「#42」ノード以下の部分ツリーに対応している。このノードからは「タイトル」タグ、「出願者」タグ、「要約」タグなどを先頭にもつノードへリンクが張られ、末端のノードからは、「XMLデータベース」、「T社」。「XMLを統一的に管理するデータベースを提供する…」などの文字列(要素値)へのリンクが張られている。
【0048】
「#52」ノード以下の部分ツリー、「#62」ノード以下の部分ノードも1つの「特許」情報に対応する部分である。
【0049】
ところで、例えば、「#43」ノードにリンクされた「XMLデータベース」という要素値は、「#43」ノードと「#value」という特殊なタグ名で接続されている。このタグ名は、「#」で始まるためXML規格においては標準的なタグ名として利用することはできない。
【0050】
このような構造化文書データベースの特定ノードを指定するために構造化文書パスを用いる。構造化文書パスは「uix://root」から始まる文字列である。uix(Universal Identifier for XML)は構造化文書パスであることを示す前置文字列である。
【0051】
例えば、「uix://root/特許DB」は、「#1」ノードから「特許DB」が付与されたアークが指し示すノード、つまり「#2」ノードに対応する。このように「root」から「/」で区切られた部分文字列をタグ名とみなすことで「#0」ノードからタグ名の並びに沿って対応するアークを下っていき、その最後のアークが指すノードが、パスの場所を指し示す。
【0052】
例えば、「uix://root/特許DB/特許」は、「#42」ノード、「uix://root/特許DB/出願日/年」は、「#45」ノードを指し示す。
【0053】
「#2」ノード以下に、すなわち、「特許DB」に、複数の「特許」情報を格納する場合には、個々の「特許」情報を識別するために、構造化文書パスにインデックス表現が可能である。
【0054】
「特許DB」の最初の「特許」情報であれば、「uix://root/特許DB/特許[0]」となるが、これは「uix://root/特許DB/特許」と同じとみなす。
【0055】
「特許DB」の2番目の「特許」情報であれば、「uix://root/特許DB/特許[1]DB」の5番目の「特許」情報であれば、「uix://root/特許DB/特許[4]」となる。
【0056】
インデックス記憶部6には検索時に用いる、要素名称生起インデックスとデータ生起インデックスが記憶されている。
【0057】
要素名生起インデックスとは構造化文書データベースに格納されている要素名称のリストと、各要素名称が先頭にある構造化文書(文書オブジェクトツリー)の位置とを関連付けてインデックスファイル化したものである。例えば、図8の構造化文書データベースのように、(「特許」情報に対応する)「特許」という要素名称が「#42」ノード以下の構造化文書、「#52」ノード以下の構造化文書、「#62」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図9に示すように、それらの親ノード、「#2」ノードが、要素名称生起インデックスファイルに「特許」キーからのチェーンで格納される。
【0058】
このように、親ノードでインデックス化すると、インデックスファイルを圧縮することができる。すなわち、親ノードでインデックス化すれば、子ノードが増大しようとも、親ノードで代用しているので、チェーンサイズは増大しない。これに対し、実ノードをインデックス化すれば「特許」情報の格納数の増大とともにチェーンサイズはそれに比例して増加してしまう。
【0059】
データ生起インデックスとは、構造化文書データベースに格納されている文字列データのリストと各文字列データがある構造化文書(文書オブジェクトツリー)の位置とを関連付けてインデックスファイル化したものである。例えば、図8の構造化文書データベースのように、「XML」という文字列データ(および、「XML」という文字列を含む文字列)が「#43」ノード以下の構造化文書、「#49」ノード以下の構造化文書に存在する場合、これらをインデックス化すると、図10に示すように、「#43」ノード、「#49」ノードが、データ生起インデックスファイルに「XML」キーからのチェーンで格納される。
【0060】
なお、逆階層インデックスなど、その他のインデックスファイルを用いてもよい。逆階層インデックスとは、あるノードとその親ノードとの対応を格納したものである(あるノードからその親ノードを求めることができる)。
【0061】
文書記憶部5中の論理的な指定エリアとは、ユーザにより構造化文書パスを用いて指定された文書の格納場所を指す。構造化文書パスは、ユーザにとって認識可能な表現である。
【0062】
図1の説明に戻る。
【0063】
データアクセス部4は、文書記憶部5をアクセスする基本インターフェイスの集合である。データアクセス部4は、文書オブジェクトツリー格納部47、文書オブジェクトツリー削除部48、文書オブジェクトツリー取得部49、文書文字列取得部44、パスから文書オブジェクトツリー取得部45、文書パーサ部46、合成文書作成部47、インデックス更新部48から構成される。
【0064】
文書オブジェクトツリー格納部41は、文書記憶部5中の物理的な指定エリアに文書オブジェクトツリーを格納する処理を行う。
【0065】
文書オブジェクトツリー削除部42は、文書記憶部5中の物理的な指定エリアに存在する文書オブジェクトツリーを削除する処理を行う。
【0066】
文書オブジェクトツリー取得部43は、文書記憶部5中の物理的な指定エリアに存在する文書オブジェクトツリーを取得する処理を行う。
【0067】
文書文字列取得部44は、文書オブジェクトツリーを構造化文書(XML文書)に変換する処理を行う。
【0068】
パスから文書オブジェクトツリー取得部45は、構造化文書パスを解析して文書記憶部5中の物理的なエリアを特定して、そのエリアに存在する文書オブジェクトツリーを取り出す処理を行う。
【0069】
文書パーサ部46は、ユーザにより入力された構造化文書を読み込んで構文解析して整合性の検査を行い、さらに文書構造定義データであるスキーマが存在すれば構造的に妥当かどうかの検証を行う。出力結果は文書オブジェクトツリーとなる。文書パーサは、通常、lex(lexical analyzer generator)といったレキシカルアナライザ(字句解析を行い,トークンに分解する)とyacc(yet another compiler compiler)といったパーサジェネレータを組み合わせて構築することができる。
【0070】
合成文書作成部47は、文書格納や文書削除などをする際に、スキーマに合致しているかどうか検査しなければならないが、この検査時に必要となるデータを作成して出力する。
【0071】
インデックス更新部48は、文書格納や文書削除などにより、構造化文書データベースの格納内容が更新されるたびに、図9、図10に示した要素名称生起インデックスとデータ生起インデックスを更新する。
【0072】
文書記憶部5中の物理的な指定エリアとは、ファイルオフセットやオブジェクトIDなどの構造化文書データベース内ではユニークな文書データの存在場所を指し示す内部データである。ユーザにとっては認識不能なデータである。
【0073】
文書記憶部5中に格納された文書を検索する処理を行う。要求制御部1の要求受付部11でユーザからの文書検索の要求が受け付けられると、検索要求処理部3には、要求受付部11からクエリ言語で記述されたクエリ文書が入力する。そしてデータアクセス部4を通してインデックス記憶部6,文書記憶部5にアクセスし、検索要求に合致する文書集合を取得して、その結果を結果処理部12を介して出力する。
【0074】
図2は、図1に示した構造化文書管理システムの一利用形態を示したもので、図2では、WWW(World Wide Web)のバックエンドで、図1に示した構成の構造化文書管理システム100が動作している場合を示している。
【0075】
複数(ここでは、例えば3つ)のクライアント端末(例えばパーソナルコンピュータ、携帯通信端末など)102のそれぞれでWWWブラウザ103が動作している。ユーザは、各クライアント端末からWWWサーバ101にアクセスすることにより、構造化文書管理システム100にアクセスすることができる。WWWブラウザ103とWWWサーバ101とは、HTTP(Hyper TextTransfer Protocol)で通信している。また、WWWサーバ101と構造化文書管理システム100とは、CGI(Common Gateway Interface)またはCOM(Component Object Model)などで通信している。
【0076】
ユーザからの文書格納、文書取得、文書検索などの要求は、WWWブラウザ103から送信されて、WWWサーバ101を通して構造化文書管理システム100にて受け付けられ、処理された結果は、WWWサーバ101を通して要求元のWWWブラウザ103へ返信される。
【0077】
以下、図1の構造化文書管理システムの(1)格納機能、(2)検索機能について詳細に説明する。そして、(3)適用例では、概念検索を用いた特許調査の場合を例にとり説明する。
【0078】
格納機能
図1の構造化文書管理システムにおける格納系のコマンドには以下のものがある。
【0079】
insertXML(パス、N番目、XML):文書格納
appendXML(パス、XML) :文書格納
getXML(パス) :文書取得
removeXML(パス) :文書削除
setSchema(パス、スキーマ) :スキーマ格納
getSchema(パス) :スキーマ取得
「insertXML」は、( )内に指定した構造化文書パス以下のN番目に文書を挿入するコマンド(以下、簡単に挿入コマンドと呼ぶ)である。
【0080】
「appendXML」は、( )内に指定した構造化文書パス以下の最後に文書を挿入するコマンド(以下、簡単に追加コマンドと呼ぶ)である。
【0081】
「getXML」は、( )内に指定した構造化文書パス以下の文書を取り出すコマンド(以下、簡単に取得コマンドと呼ぶ)である。
【0082】
「removeXML」は、( )内に指定した構造化文書パス以下の文書(スキーマ文書以外の文書で、主に、コンテンツ文書)を削除するコマンド(以下、簡単に削除コマンドと呼ぶ)である。
【0083】
「setSchema」は、( )内に指定した構造化文書パスにスキーマを設定するコマンド(以下、簡単にスキーマ格納コマンドと呼ぶ)である。
【0084】
「getSchema」は、( )内に指定した構造化文書パスに設定されているスキーマを取り出すコマンド(以下、簡単にスキーマ取得コマンドと呼ぶ)である。
【0085】
上記コマンドのうち、挿入コマンド、追加コマンド、スキーマ格納コマンドについての処理はアクセス要求処理部2の文書格納部21で実行され、取得コマンド、スキーマ取得コマンドについての処理は文書取得部22で実行され、削除コマンドについての処理は文書削除部23で実行される。
【0086】
図5を参照して、構造化文書データベースの初期状態(図5(a)参照)において、追加コマンドを実行する場合について説明する。
【0087】
図5(a)に示すように、「#0」ノードと「#1」ノードが「root」アークで接続されている初期状態に対して、
「appendXML(“uix://root”,“<特許DB/>”)」
を実行した結果、図5(b)に示すように、「#2」ノードと「特許DB」アークが作成される。
【0088】
図5(b)に示した状態の構造化文書データベースに対して、取得コマンドを実行する場合について説明する。
【0089】
例えば、「getXML(“uix://root”)」を実行すると、図5(b)の「root」アークが示す「#0」ノード以下の文書オブジェクトツリーが取り出され、それをXMLの文字列表現に変換する。その結果、図6に示すように、「<root><特許DB/></root>」なる文字列が取り出される。取得コマンドの処理は、アクセス要求処理部2の文書取得部22にて実行される。
【0090】
次に、図5(b)に示した状態の構造化文書データベースに対して、図3に示すようなコンテンツ文書(XML文書)としての「特許」情報を格納するための追加コマンドを実行する場合について説明する。すなわち、この場合、「appendXML(“uix://root/特許DB”,“<特許>…</特許>”)」を実行する。このコマンド中「“<特許>…</特許>”」が、図3に示した「特許」情報に対応する。
【0091】
上記追加コマンドの処理が実行されると、図7に示すように、「#2」ノード以下に「#42」ノードをトップとする文書オブジェクトツリー(図4に対応)が追加される。
【0092】
図5(b)に示した状態の構造化文書データベースに対して、次に示すような追加コマンドを3回繰り返して実行したとする。
【0093】
「appendXML(“uix://root/特許DB”,“<特許>…</特許>”)」
上記コマンド中、「<特許>…</特許>」は、図3に示した文書構造のコンテンツ文書に対応する。
【0094】
すると、図8に示すように、「#2」ノード以下に「#42」ノード、「#52」ノード、「#62」ノードをトップとする文書オブジェクトツリーが追加される。
【0095】
次に、図8に示した状態の構造化文書データベースに対して、3つの「特許」情報を取り出すための取得コマンドを実行した場合について説明する。この場合、「getXML(“uix://root/特許DB”)」を実行する。すると、「特許DB」アークが示す「#2」ノード以下の文書オブジェクトツリーが取り出され、それをXMLの文字列表現(XML文書)に変換する。その結果、図11に示すように、「<特許DB><特許>…</特許><特許>…</特許><特許>…</特許></特許DB>」なる文字列が取り出される。
【0096】
構造化文書データベースでは、上記の「特許」情報などのコンテンツ文書(XML文書)の文書構造を定義したデータ、すなわち、スキーマも管理対象とする。
【0097】
図12は、XML文書の文書構造を定義するスキーマの一例を示したものである。ここでは、XMLの文書構造定義言語の一つであるXDR(XML−Data Reduced)を取り上げる。もちろん、XML−Schemaなど他の文書構造定義言語を用いてもかまわない。
【0098】
図12に示したスキーマは、図3に示した「特許」情報の文書構造をXDRで定義したものである。図12からも容易に分かるとおり、スキーマもXML形式の構造化文書である。「Schema」タグから始まる構成要素から始まり、その子要素として、「ElementType」タグから始まる要素集合が存在する。
【0099】
図12に示したスキーマにおいて、例えば、最初の「ElementType」タグから始まる子要素は以下の情報を意味している。
【0100】
・「特許」タグを持つ要素の文書構造定義(「ElementType name=”特許”」)である。
【0101】
・子要素は要素だけ(「content=”eltOnly”」)である。
【0102】
・「タイトル」、「出願日」、「要約」タグから始まる子要素から構成される(「element type=”タイトル”、…」)。さらに、その順番は一意に決まっている(「order=”seq”」)。
【0103】
・上記「特許」タグから始まる要素の文書構造定義の他に、「タイトル」「出願者」「要約」「年」「月」「日」「出願日」の文書構造定義を記述している。すなわち、「出願日」を除く、「タイトル」「出願者」「要約」「年」「月」「日」タグから始まる構成要素の子要素はテキストだけと定義されている(「content=”textOnly”」)。
【0104】
・「出願日」タグから始まる構成要素の子要素は、「年」、「月」、「日」の並びである。
【0105】
図8に示した状態の構造化文書データベースに対して、図12に示したスキーマ文書を格納するためのスキーマ格納コマンドを実行する場合について説明する。この場合、「setSchema(“uix://root/特許DB”,“<Schema>…</Schema>”)」を実行する。このコマンド中、「“<Schema>…</Schema>”」」が図12に示したスキーマ文書に対応する。
【0106】
上記コマンドの実行により、図13に示すように、「#2」ノード以下に「#schema」アークが追加され、その先には、「#3」ノードをトップノードとする文書オブジェクトツリーが追加される。スキーマ自身がXML文書表現になっているため、前述した「特許」情報のようなコンテンツ文書格納のケースと同様にツリー展開可能である。
【0107】
図13において、「@name」など「@」で始まるアークは属性に対応する。タグ名「#schema」も「#」、「@」で始まるためXML規格においては標準的なタグ名として利用することはできない。
【0108】
「#2」ノード下に図12に示したスキーマ文書が格納されたことにより、以後、「#2」ノード以下にこれから格納される文書の文書構造は、図12に示したスキーマ文書により定義された文書構造に適合することが要求される。すなわち、「#2」ノード以下に図12に示したスキーマが設定されることになる。
【0109】
「#2」ノード以下に図12に示したスキーマが設定されると、図14に示すように、「#2」ノードの文書オブジェクトのファイルには、「#2」ノード以下の文書オブジェクトツリーには、当該スキーマが存在する旨の属性値がセットされる。
【0110】
「#2」ノード以下に図12に示したスキーマが設定された後に、このスキーマで定義された文書構造に一致する図3に示したような「特許」情報を、図14に示したように、文書オブジェクトツリーとして構造化文書データベースに格納したとき、この文書の文書構造には図12に示したスキーマが存在する旨の属性値が、当該文書オブジェクトツリーを構成する各文書オブジェクトにセットされる。例えば、当該文書オブジェクトツリーを構成する各文書オブジェクトのファイルに対して、スキーマが存在している旨の属性値(例えば、「スキーマ適合有無」)に「1」がセットされる。図14では、スキーマに適合している各文書オブジェクト(ノード)は2重丸で示している。2重丸で示した各文書オブジェクトには、その文書オブジェクトに対応した文書構造定義が存在することになる。
【0111】
図15は、各文書オブジェクトのファイルの内容を概念的に示したもので、例えば、オブジェクトIDが「#42」の文書オブジェクトのファイルには、その文書オブジェクトにリンクされている他の文書オブジェクトに関する情報(例えば、アークや、リンク先の文書オブジェクトへのポインタ値など)とともに、上記属性値が記述されている。なお、当該文書オブジェクトに適用するスキーマが存在しないときは、「スキーマ適合有無」の値は「0」となる。
【0112】
図16、図17は、図1の構造化文書管理システムで、必要に応じて検索で使用される概念階層を構造化文書で表現した例を示す。図16、図17に示す「概念」情報はXMLで記述したコンテンツ文書である。
【0113】
図16に示した「概念」情報の例は、いわゆる特許調査における特許文書の内容を分類するための1つの分類軸として用いる「情報モデル」を概念階層で表現している。「概念」タグで囲まれた「概念」情報は、入れ子構造を持った文書構造をもっている。つまり、図16の例では、概念「情報モデル」の子供概念として、概念「ドキュメント」、概念「リレーション」、概念「オブジェクト」が存在している。また、概念「ドキュメント」の子供概念として、概念「構造化訴求メント」、概念「非構造化ドキュメント」が存在し、さらに、概念「構造化ドキュメント」の子供概念として、概念「XML」、概念「SGML」が存在している。
【0114】
図17に示す「概念」情報の記述例は、図16とは異なる分類軸「情報操作」を概念階層で表現している。図17の例では、概念「情報操作」の子供概念として、概念「検索」、概念「格納」、概念「加工」、概念「流通」が存在している。
【0115】
図16,図17に示したような「概念」情報も、前述の「特許」情報と同様にして、構造化文書データベース内に格納することができる。すなわち、例えば、まず、図8に示した状態の構造化文書データベースに対して、「appendXML(“uix://root”,“<概念DB/>”)」を実行して、図18に示すように、「#201」ノードと「概念DB」アークが作成される。この状態において、図16に示した「概念」情報を格納する場合には、「appendXML(“uix://root/概念DB”,“<概念名前>…</概念>”)」を実行する。このコマンド中「“<概念名前>…</概念>”」が、図16に示した「概念」情報に対応する。
【0116】
上記追加コマンドの処理が実行されると、図19に示すように、「#201」ノード以下に「#202」ノードをトップとする文書オブジェクトツリーが追加される。
【0117】
以上説明したように、図1の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のXML文書群(コンテンツ文書、スキーマ文書、クエリ文書など)を、図18,図19に示すように、「root」タグを先頭に持つツリー状の1つの巨大なXML文書として取り扱う。そのため、部分的なXML文書をアクセスするには巨大なXML文書に対するパスという文書構造に依存しない統一的なアクセス手段を用いることにより、幅広くXML文書を検索したり加工したりすることが可能になる。
【0118】
また、構造化文書データベース上の一部にスキーマを設定することで、格納しようとする文書の文書構造がそのスキーマにより定義されている文書構造に一致するか否かの妥当性のチェックが自動的に行なえる(後述)。
【0119】
(1−1)文書格納処理
次に、図1の構造化文書管理システムの文書格納処理動作について、図20に示すフローチャートを参照して説明する。
【0120】
クライアント端末から構造化文書管理システムに対し、文書格納要求として、挿入コマンド、追加コマンド、スキーマ格納コマンドのうちのいずれかが送信されて、要求受付部11にて受け付けられたとき、図20に示した処理動作を行う。
【0121】
クライアント端末の所定の表示装置には、構造化文書管理システム100(の例えば、要求制御部1)から提供された、例えば、図31に示すようなユーザインターフェイスとしての画面が表示されている。
【0122】
図31に示す画面には、構造化文書管理システム100への操作項目の一覧(メニュー)が表示されている。操作項目として、「XML登録/削除」、「スキーマ設定」、「XML検索」とがある。
【0123】
ユーザが例えば、この画面上で「XML登録/削除」をマウス等のポインティングデバイスなどを用いて選択すると、図32に示したような文書の格納/削除を行うためのユーザインタフェースとしての画面が表示される。
【0124】
図32において、領域W1には、文書構造化文書データベースの現在のツリー構造の要素名(タグ名)がユーザが理解可能なように簡略的に表示されている。なお、図32では、上位階層の要素名のみを表示しているが、末端の要素名まで表示可能である。また、領域W2は、構造化文書パスの入力領域であり、領域W1の表示内容に従って、構造化文書パスを入力するようになっている。また、領域W3は、格納する文書を入力したり、取得した文書を表示するようになっている。
【0125】
例えば、構造化文書パスとして「root」を入力する場合には、領域W1の「root」をマウス等で選択すればよい。すると、図32に示すように、領域W2の構造化文書パスの入力領域に「uix://root」と表示される。また、新たに、「特許DB」という要素を追加する場合は、図32に示すように、領域W3に、「特許DB」を入力する。そして、「登録」ボタンB1を選択すると、クライアント端末からappendXML(“uix://root”,“<特許DB/>”)」なる追加コマンドが構造化文書管理システムへ送信される。構造化文書管理システムでは、上記追加コマンドを受け、後述するような処理を実行した結果、例えば、図5(b)に示すように、「#2」ノードと「特許DB」アークが作成される。また、領域W1には、図33に示すように、「root」の下に「特許DB」が追加表示される。
【0126】
さて、ユーザが図34に示したような文書の格納/削除画面上の領域W3に、例えば、文書「<A>データ</A>」を入力し(あるいはCD−ROM等の所定の記録媒体等から読み込むことにより入力し)、領域W1の「特許[0]」をマウス等で選択すると、構造化文書パスの入力領域W2に、「uix://root/特許DB/特許[0]」と表示される。そして、「登録」ボタンB1を選択すると、クライアント端末からappendXML(“uix://root”,“<特許DB/>”)」なる追加コマンドが構造化文書管理システムへ送信される。
【0127】
ここでは、例えば、構造化文書データベースが、図14に示した状態のときに、「appendXML(“uix://root/特許DB/特許[0]”,“<A>データ</A>”)」なる追加コマンドを受け付けた場合を例にとり説明する。
【0128】
要求受付部11は、上記追加コマンドを受け付けると、上記追加コマンド中の2つのパラメータである構造化文書パス「uix://root/特許DB/特許[0]」と文書「<A>データ</A>」(以下、格納文書と呼ぶ)とを文書格納部21へ渡す(ステップS1)。
【0129】
まず、文書格納部21は、文書パーサ部46に格納文書を渡す。文書パーサ部46は、格納文書を読み込んで、構文解析を行い、当該格納文書の文書構造がXMLにて規定された正しい形式であるか否かの整合性の検査を行う(ステップS2)。
【0130】
この整合性の検査でエラーが見つかれば(ステップS3)、文書格納部21,結果処理部12を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す(ステップS4)。
【0131】
整合性の検査でエラーが見つからなければ、次に、文書格納部21は、パスから文書オブジェクトツリー取得部45へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部45は、構造化文書パスから文書記憶部5中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード(文書オブジェクトOx0)を含む文書オブジェクトツリーを取り出す(ステップS5)。構造化文書パスの指定が正しければ、文書オブジェクトOx0のオブジェクトIDを取得することができるので(ステップS6)、その場合は、ステップS8へ進む。
【0132】
例えば、上記追加コマンドの場合、「#42」ノードが文書オブジェクトOx0となるので、そのオブジェクトIDとして、「#42」を取得するとともに、この「#42」ノードを含む文書オブジェクトツリー(例えば、「#42」ノードの全ての子孫ノードと「#42」ノードと同じ階層にある全ての(兄弟)ノードと、「#42」ノードの親ノードである「#2」ノードとからなる文書オブジェクトツリー)を取得する。
【0133】
指定された構造化文書パスからそれに対応する文書オブジェクトOx0が見つからなければ、エラーとなり(ステップS6)、文書格納部21,結果処理部12を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す(ステップS7)。
【0134】
例えば、構造化文書データベースが、図18に示した状態のときに、追加コマンドのパラメータとして、構造化文書パスが「uix://root/その他」と表されていたとき、これに対応する文書オブジェクトは存在しないので、ステップS6でエラーとなり、ステップS7へ進む。
【0135】
次に、ステップS8では、文書オブジェクトOx0にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトOx0のもつ「スキーマ属性有無」の値が「1」のときは、ステップS9へ進む。
【0136】
以下、図20のステップS9の処理(合成文書作成部47の処理)について、図21に示すフローチャートを参照して詳細に説明する。
【0137】
文書格納部21は、ステップS5で取得した文書オブジェクトツリーを合成文書作成部47へ渡す。
【0138】
合成文書作成部47は、この文書オブジェクトツリーを文書オブジェクトOx0から遡り、「Schema」タグを子要素として持つ文書オブジェクトOx1を検索する(ステップS21)。
【0139】
例えば、図14に示した構造化文書データベースでは、文書オブジェクトOx0としての「#42」ノードの親ノードである「#2」ノードから「Schema」タグをトップ(先頭)にもつノード(「#3」ノード)へのリンクが張られているので(「Schema」タグを子要素として持つので)、この「#2」ノードが文書オブジェクトOx1となる。よって、ステップS22をスキップして、ステップS23へ進む。
【0140】
この文書オブジェクトOx1から文書オブジェクトOx0、さらに文書オブジェクトOx0からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「1」である全ての子ノードからなる文書オブジェクトツリーOt1を取り出す(ステップS23)。
【0141】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「uix://root/特許DB/特許[0]」と指定されているとき、文書オブジェクトツリーOt1は、「#42」ノード〜「#49」ノードから構成されたものとなる(図14参照)。
【0142】
次に、ステップS25へ進む。
【0143】
ステップS25では、文書オブジェクトツリーOt1に格納文書の文書オブジェクトツリーを文書オブジェクトOx0の子ノードとして挿入する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーOt2とする。
【0144】
この文書オブジェクトツリーOt2をXML文書に変換し、それをテンポラリファイルAに出力する(ステップS27)。
【0145】
例えば、上記追加コマンド中のパラメータの格納文書「<A>データ</A>」の文書オブジェクトツリー(この場合は、1つの文書オブジェクト)を「#42」ノード〜「#49」ノードで構成された文書オブジェクトツリーOt1に「#42」ノードの子ノードとして挿入して得られた合成文書の文書オブジェクトツリーOt2をXML文書に変換した結果を図22に示す。この合成文書は、もともとある「特許」情報に「<A>データ</A>」というデータを追加したものとなっている。
【0146】
図22に示したXML文書、すなわち、合成文書がテンポラリファイルAに出力され、テンポラリファイルAに一時格納される。
【0147】
一方、スキーマタグ以下の文書オブジェクトツリーOt3をXML文書に変換して、それをテンポラリファイルBに出力する(ステップS28)。すなわち、テンポラリファイルBには、スキーマ文書が一時格納されることになる。
【0148】
例えば、文書オブジェクトツリーOt3である「#3」ノードをトップノードとする文書オブジェクトツリーをXML文書に変換した結果を図23に示す。図23に示したXML文書がテンポラリファイルBに出力され、テンポラリファイルBに一時格納される。
【0149】
図22に示すように、テンポラリファイルA(「tmp000.xml」)には、もともとある「特許」情報の要素の他に、格納文書、すなわち、ここでは、例えば、「<A>データ</A>」が挿入されている。また、「xmlns=”x−schema:tmp001.xml”」という、テンポラリファイルB(「tmp001.xml」)へのリンク情報の記述がある。この記述は、「特許」情報に適用されるスキーマが出力されているテンポラリファイルBを指定している。
【0150】
次に、図20の説明に戻る。
【0151】
ステップS10では、文書格納部21は文書パーサ部46に、合成文書のテンポラリファイルAとスキーマのテンポラリファイルBとを与えて、合成文書の文書構造の妥当性をチェックする。すなわち、文書パーサ部46は、合成文書のテンポラリファイルAとスキーマのテンポラリファイルBとを読み込み、合成文書の文書構造が、スキーマにより定義されている文書構造に一致するか否かをチェックする。
【0152】
例えば、図22に示した合成文書と、図23に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されていない「A」という要素が存在するため、図23の合成文書は、妥当性のチェックでエラーとなる(ステップS11)。この場合、文書格納部21,結果処理部12を介して、クライアント端末に「文書格納失敗」の旨のメッセージを返す(ステップS12)。
【0153】
例えば、クライアント端末の所定の表示装置には、図35に示すようなメッセージが表示される。
【0154】
次に、構造化文書データベースが、図14に示した状態のときに、「appendXML(“uix://root/特許DB”,“<特許>…</特許>”)」なる追加コマンドを受け付けた場合について、図20を参照して説明する。前述同様にして、文書オブジェクトOx0のオブジェクトID「#2」を取得する(ステップS5)、この文書オブジェクトには、スキーマが存在するので(ステップS8)、ステップS9において合成文書を作成する。
【0155】
この場合、文書オブジェクトOx0である「#2」ノード自体から「Schema」タグをトップ(先頭)にもつノード(「#3」ノード)へのリンクが張られているので、この「#2」ノードが文書オブジェクトOx1となる(図21のステップS21)。すなわち、文書オブジェクトOx0と文書オブジェクトOx1が同じなので(ステップS22)、ステップS29へ進み、格納文書「<特許>…</特許>」の文書オブジェクトツリーをXML文書に変換し、テンポラリファイルAに出力する(ステップS29)。
【0156】
例えば、図24に示すように、テンポラリファイルA(「tmp000.xml」)には、格納文書である「特許」情報、すなわち、ここでは、「<特許>…</特許>」が出力されている。また、「xmlns=”x−schema:tmp001.xml”」という、テンポラリファイルB(「tmp001.xml」)へのリンク情報の記述がある。
【0157】
次に、ステップS28へ進む。図25に示すように、テンポラリファイルBには、「#3」ノードをトップノードとするスキーマの文書オブジェクトツリーをXML文書に変換した結果が出力されている。
【0158】
図20のステップS10で、図24に示した合成文書と、図25に示したスキーマとで妥当性のチェックを行ったとき、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致する、この場合、ステップS11からステップS13へ進む。
【0159】
ステップS13では、格納文書の文書オブジェクトツリーが、文書オブジェクトOx0下に追加される。すなわち、文書格納部21により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト(のファイル)にオブジェクトIDが与えられ、文書オブジェクトOx0から格納文書の文書オブジェクトツリーの先頭の文書オブジェクトへリンクが張られる。そして、文書オブジェクトツリー格納部41により、格納文書の文書オブジェクトツリーを構成する各文書オブジェクト(のファイル)が文書記憶部5に格納される。
【0160】
次に、ステップS14へ進み、インデックス記憶部6のインデックスを更新する。
【0161】
なお、ステップS8で、文書オブジェクトOx0のもつ属性値の値が「0」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップS13へ進み、格納文書の文書オブジェクトツリーを、文書オブジェクトOx0下に追加し(ステップS13)、それに伴い、インデックス記憶部6のインデックスを更新する(ステップS14)。
【0162】
(1−2)文書取得処理
次に、図1の構造化文書管理システムの文書取得処理動作について、図26に示すフローチャートを参照して説明する。
【0163】
クライアント端末から構造化文書管理システムに対し、文書取得要求として、取得コマンド、スキーマ取得コマンドのうちのいずれかが送信されて、要求受付部11にて受け付けられたとき、図26に示した処理動作を行う。
【0164】
例えば、ユーザが図36に示したような文書の格納/削除画面上の領域W1の「特許DB」をマウス等で選択すると(クリックすると)、構造化文書パスの入力領域W2に、「uix://root/特許DB」と表示されとともに、「getXML(“uix://root/特許DB”)」なる取得コマンドが構造化文書管理システムへ送信される。
【0165】
ここでは、例えば、構造化文書データベースが、図8に示した状態のときに、「getXML(“uix://root/特許DB”)」なる取得コマンドを受け付けた場合を例にとり説明する。
【0166】
要求受付部11は、上記取得コマンドを受け付けると、上記取得コマンド中のパラメータである構造化文書パス「uix://root/特許DB」を文書取得部22へ渡す(ステップS31)。
【0167】
文書取得部22は、パスから文書オブジェクトツリー取得部45へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部45は、構造化文書パスから文書記憶部5中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード(文書オブジェクトOx5)を取り出す(ステップS32)。構造化文書パスの指定が正しければ、文書オブジェクトOx5のオブジェクトIDを取得することができるので(ステップS33)、その場合は、ステップS35へ進む。
【0168】
例えば、上記取得コマンドの場合、「#2」ノードが文書オブジェクトOx5となるので、そのオブジェクトIDとして、「#2」を取得するとともに、この「#2」ノード以下の文書オブジェクトツリーOt5(「#2」ノード、「#42」ノード〜「#49」ノード、「#52」ノード以下、「#62」ノード以下)を取得する(ステップS35)。
【0169】
ステップS32において、指定された構造化文書パスからそれに対応する文書オブジェクトOx5が見つからなければ、エラーとなり(ステップS33)、文書取得部22,結果処理部12を介して、クライアント端末に「文書取得失敗」の旨のメッセージを返す(ステップS34)。
【0170】
ステップS35で取得した文書オブジェクトツリーOt5は、文書文字列取得部44でXML文書に変換される。例えば、上記取得コマンドの場合、取得したXML文書は、図11に示すような3つの「特許」情報のXML文書となる。
【0171】
文書取得部22は、結果処理部12を介して、図11に示したようなXML文書を(例えば、XSL(eXtensible Style Language)といった所定のスタイルシートとともに)、クライアント端末へ返す(ステップS37)。
【0172】
クライアント端末では、図11に示したXML文書を、スタイルシートを用いてHTMLデータに変換して、例えば、図36に示すように、領域W2に表示する。
【0173】
XSLを利用すると、XML文書を様々な形に変換することが出来る。違う構文書造のXML文書に変換することも出来るし、XML文書からHTMLページを生成することも出来る。
【0174】
(1−3)文書削除処理
次に、図1の構造化文書管理システムの文書削除処理動作について、図27に示すフローチャートを参照して説明する。
【0175】
クライアント端末から構造化文書管理システムに対し、文書削除要求として、削除コマンドが送信されて、要求受付部11にて受け付けられたとき、図27に示した処理動作を行う。
【0176】
例えば、ユーザが図36に示したような文書の格納/削除画面上の領域W1の「特許DB」をマウス等で選択すると(クリックすると)、構造化文書パスの入力領域W2に、「uix://root/特許DB」と表示され、さらに、「削除」ボタンB2を選択すると「removeXML(“uix://root/特許DB”)」なる削除コマンドが構造化文書管理システムへ送信される。
【0177】
ここでは、例えば、構造化文書データベースが、図14に示した状態のときに、「removeXML(“uix://root/特許DB/特許[0]/出願日”)」なる削除コマンドを受け付けた場合を例にとり説明する。
【0178】
要求受付部11は、上記削除コマンドを受け付けると、上記削除コマンド中のパラメータである構造化文書パス「uix://root/特許DB/特許[0]/出願日」を文書削除部23へ渡す(ステップS41)。
【0179】
次に、文書削除部23は、パスから文書オブジェクトツリー取得部45へ構造化文書パスを渡す。パスから文書オブジェクトツリー取得部45は、構造化文書パスから文書記憶部5中の物理的なエリアを特定することにより、そのエリアに存在する構造化文書パスにて表されたノード(文書オブジェクトOx0)を含む文書オブジェクトツリーを取り出す(ステップS42)。構造化文書パスの指定が正しければ、文書オブジェクトOx0のオブジェクトIDを取得することができるので(ステップS43)、その場合は、ステップS45へ進む。
【0180】
例えば、上記削除コマンドの場合、「#44」ノードが文書オブジェクトOx0となるので、そのオブジェクトIDとして、「#44」を取得するとともに、この「#44」ノードを含む文書オブジェクトツリー(例えば、「#44」ノードの全ての子孫ノードと「#44」ノードと同じ階層にある全ての(兄弟)ノードと、「#44」ノードの親ノードである「#42」ノード、その親ノードである「#2」ノードとからなる文書オブジェクトツリー)を取得する。
【0181】
指定された構造化文書パスからそれに対応する文書オブジェクトOx0が見つからなければ、エラーとなり(ステップS43)、文書格納部21,結果処理部12を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す(ステップS44)。
【0182】
次に、ステップS45では、文書オブジェクトOx0にスキーマが存在するか否かを検査する。この検査は、前述したように、各文書オブジェクトのファイルに属性値が記述されているので、この値をチェックすればよい。文書オブジェクトOx0のもつ属性値の値が「1」のときは、ステップS46へ進む。
【0183】
以下、図27のステップS46の処理(合成文書作成部47の処理(削除コマンド用))について、図28に示すフローチャートを参照して詳細に説明する。
【0184】
なお、図28において、図21と同一部分は同一符号を付している。
【0185】
文書格納部21は、ステップS42で取得した文書オブジェクトツリーを合成文書作成部47へ渡す。
【0186】
合成文書作成部47は、この文書オブジェクトツリーを文書オブジェクトOx0から遡り、「Schema」タグを子要素として持つ文書オブジェクトOx1を検索する(ステップS21)。
【0187】
例えば、図14に示した構造化文書データベースでは、文書オブジェクトOx0としての「#44」ノードの上流にある「#2」ノードから「Schema」タグをトップ(先頭)にもつノード(「#3」ノード)へのリンクが張られているので(「Schema」タグを子要素として持つので)、この「#2」ノードが文書オブジェクトOx1となる。
【0188】
この文書オブジェクトOx1から文書オブジェクトOx0、さらに文書オブジェクトOx0からアークを辿って、その下流にある、文書オブジェクトの属性値の値が「1」である全ての子ノードからなる文書オブジェクトツリーOt1を取り出す(ステップS23)。
【0189】
例えば、上記追加コマンド中のパラメータの構造化文書パスが「uix://root/特許DB/特許[0]/出願日」と指定されているとき、文書オブジェクトツリーOt1は、「#42」ノード〜「#49」ノードから構成されたものとなる(図14参照)。
【0190】
次に、ステップS26ヘ進み、文書オブジェクトツリーOt1から文書オブジェクトOx0以下の文書オブジェクトツリーを削除する。その結果得られた新たな文書オブジェクトツリーを文書オブジェクトツリーOt2とする。
【0191】
この文書オブジェクトツリーOt2をXML文書に変換し、それをテンポラリファイルAに出力する(ステップS27)。
【0192】
例えば、上記削除コマンド中のパラメータの構造化文書パス「uix://root/特許DB/特許[0]/出願日」が指し示す「#44」ノード以下の文書オブジェクトツリーを「#42」ノード〜「#49」ノードで構成された文書オブジェクトツリーOt1から削除することにより得られた合成文書の文書オブジェクトツリーOt2をXML文書に変換した結果を図29に示す。この合成文書は、もともとある「特許」情報から「<出願日>…</出願日>」というデータを削除したものとなっている。
【0193】
図29に示したXML文書、すなわち、合成文書がテンポラリファイルAに出力され、テンポラリファイルAに一時格納される。
【0194】
一方、スキーマタグ以下の文書オブジェクトツリーOt3をXML文書に変換して、それをテンポラリファイルBに出力する(ステップS28)。すなわち、テンポラリファイルBには、スキーマ文書が一時格納されることになる。
【0195】
例えば、文書オブジェクトツリーOt3である「#3」ノードをトップノードとする文書オブジェクトツリーをXML文書に変換した結果を図30に示す。図30に示したXML文書がテンポラリファイルBに出力され、テンポラリファイルBに一時格納される。
【0196】
次に、図27の説明に戻る。
【0197】
ステップS47では、文書削除部21は文書パーサ部46に、合成文書のテンポラリファイルAとスキーマのテンポラリファイルBとを与えて、文書格納処理の場合と同様にして、合成文書の文書構造の妥当性をチェックする。
【0198】
例えば、図29に示した合成文書と、図30に示したスキーマとで妥当性のチェックを行った場合、合成文書には、スキーマにより定義されている「出願日」という要素が存在しないため、図29の合成文書は、妥当性のチェックでエラーとなる(ステップS48)。この場合、文書削除部21,結果処理部12を介して、クライアント端末に「文書削除失敗」の旨のメッセージを返す(ステップS49)。
【0199】
なお、構造化文書データベースが、図14に示した状態のときに、「removeXML(“uix://root/特許DB/特許[0]”)」なる削除コマンドを、図27に従って処理を行うと、図28のステップS27において、図24に示したような合成文書がテンポラリファイルAに出力される。テンポラリファイルBは、図30と同様である。
【0200】
このとき、図24に示した合成文書と、図30に示したスキーマとで妥当性のチェックを行った場合、合成文書の文書構造と、スキーマにより定義されている文書構造とは一致するので、ステップS48からステップS50へ進む。
【0201】
ステップS50では、文書オブジェクトOx0以下の文書オブジェクトツリーを削除する。すなわち、文書オブジェクトツリー削除部42により、文書オブジェクトOx0以下の文書オブジェクトツリーを構成する各文書オブジェクト(のファイル)が文書記憶部5から削除される。例えば、「#2」ノードから「#42」ノード以下の文書オブジェクトのファイルが削除される。
【0202】
次に、ステップS51へ進み、インデックス記憶部6のインデックスを更新する。また、クライアント端末の図36に示したような表示画面の領域W1には、「特許[0]」が表示さなくなる。
【0203】
なお、ステップS45で、文書オブジェクトOx0のもつ属性値の値が「0」のときは、上述したスキーマを用いた合成文書の文書構造の妥当性のチェックを行わずに、そのままマステップS50へ進み、文書オブジェクトOx0以下の文書オブジェクトツリーを削除し(ステップS50)、それに伴う、インデックス記憶部6のインデックスを更新する(ステップS51)。
【0204】
(1−4)スキーマの設定、スキーマを用いた文書格納
図31に示した画面上で、ユーザが「Schema設定Win」をマウス等のポインティングデバイスなどを用いて選択すると、図37に示したようなスキーマの設定を行うためのユーザインタフェースとしての画面が表示される。
【0205】
ユーザが、領域W3に、例えば、図12に示したような「特許」情報のスキーマを入力し、この入力したスキーマを「特許DB」以下のノードに設定する場合には、領域W1から「特許DB」をマウス等でクリックして選択した後(領域W2には、「uix://root/特許DB」が表示される)、「スキーマ設定」ボタンB3を選択する。すると、「setSchema(“uix://root/特許DB”,“<Schema>…</Schema>”)」なるスキーマ格納コマンドが構造化文書管理システムへ送信される。このコマンドの処理は前述した文書格納処理動作と同様である。
【0206】
次に、「uix://root/特許DB」の下に「特許」情報を格納しようとするとき、「特許DB」以下のノードに既に設定されているスキーマを用いて「特許」情報を入力する場合について説明する。
【0207】
まず、スキーマを取得する。例えば、図38に示すような文書の格納/削除を行うための画面の領域W1から「スキーマ」をマウス等を用いて選択すると、文書パスの入力領域W2に、「uix://root/特許DB/#Schema」と表示されとともに、「getXML(“uix://root/特許DB/Schema”)」なるスキーマ取得コマンドが構造化文書管理システムへ送信される。
【0208】
このコマンドの処理は、前述した文書取得処理と同様である。構造化文書管理システムから返されるXML文書は、図38の画面の領域W3に表示される。
【0209】
図38に示すように、領域R3には、「特許」情報のデータ入力領域が各要素毎に設定されて表示されている。この表示に従って、ユーザは、データを入力すればよい。例えば、「タイトル」、「年」などのデータ入力領域が階層的に配置され、表示されている。ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【0210】
また、領域W3に入力した「特許」情報の格納先として、領域W1で「特許DB」をマウス等を用いて選択すると、領域W2に構造化文書パスとして、「uix://root/特許DB」が表示される。その後、「登録」ボタンB1を選択すると、「appendXML(“uix://root/特許DB”,“<特許>…</特許>”)」なる追加コマンドが構造化文書管理システムへ送信される。
【0211】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図20のステップS10の妥当性チェックでエラーとなることはない。
【0212】
(2)検索機能
図1の構造化文書管理システムにおける検索系のコマンドには以下のものがある。
【0213】
query(ql)
「query」は、パラメータとして( )内のクエリqlを実行し、その結果のXML文書を取得するコマンド(以下、検索コマンドと呼ぶ)である。
【0214】
クエリは、図39に示すように、SQL(Structured QueryLanguage)に似た形式の言語により、検索位置、検索条件、情報抽出部分などを記述した、構造化されたXML文書である。クエリ文書も構造化文書管理システムの管理対象である。
【0215】
「kf:from」タグから始まる要素には、検索位置の指定と文書要素の値に変数を対応付ける記述があり、「kf:where」タグのから始める要素には、変数に関する条件づけの記述があり、「kf:select」タグから始まる要素には、検索結果の出力形式が記述される。
【0216】
検索には、単純検索と概念検索とがある。単純検索とは、クエリ中に指定された検索条件を満たす情報を検索・抽出するものであり、概念検索とは、クエリ中に指定された概念情報を利用して、クエリ中に指定された検索条件を満たす情報を検索・抽出するものである。
【0217】
図40は、単純検索のクエリの例を示したものである。図40のクエリは、例えば、図14に示したような状態の構造化文書データベースに対し、「特許DB」アークが示すノード以下に格納されている「特許」情報の文書群において、「1999年でかつ、「PC」のような内容の「要約」という要素をもつ文書(「特許」情報)の「タイトル」を列挙せよ」という検索要求を意味している。
【0218】
「kf:from」タグから始まる要素の記述により、変数「$t」、「$y」、「$s」に、それぞれ「特許」情報の「タイトル」、「年」、「要約」という文書要素の値が代入される。
【0219】
「kf:where」タグから始める要素の記述により、変数「$y」=「1999」という比較がなされる。また、コンポーネント「MyLike」は変数「$s」と「PC」を引数として、「PC」と類似する値の変数「$s」を検知するための関数である。
【0220】
「kf:from」タグから始まる要素の記述により、変数「$t」が出力値として利用される。
【0221】
なお、「kf:star」タグは構造の曖昧表現であり、例えば「<特許><kf:star><年>」は「タグ名が「特許」である要素の子孫の要素としていずれかに存在し、タグ名が「年」である要素」を意味する。
【0222】
図41に図40の単純検索のクエリを用いた検索結果を示す。この検索結果もXML文書である。
【0223】
図42は、概念検索のクエリの例を示したものである。図42のクエリは、例えば図18,図19に示すような状態の構造化文書データベースに対し、「特許DB」アークが示すノード以下に格納されている「特許」情報の文書群に対し、「概念DB」アークが示すノード以下に格納されている「概念」情報を利用して検索するための検索要求である。ここで、概念「周辺装置」の値をもつタグの子要素の値には、概念「SCSI」、「メモリ」、「HDD」などがあるものとする。また、図18には示していないが、各「特許」情報の構成要素には、「キーワード」タグから始める要素も存在するものとする。
【0224】
すなわち、図42のクエリは、「概念「周辺装置」以下の概念のいずれかを「キーワード」という要素の値にもつ文書(「特許」情報)の「タイトル」を列挙せよ」という検索要求を意味している。
【0225】
「kf:from」タグから始まる要素の記述により、変数「$t」、変数「$k」に、それぞれ、「特許」情報の「タイトル」、「キーワード」という要素の値が代入される。また、変数「$x」は「概念」情報として「周辺装置」の値をもつタグの子要素の値(「SCSI」、「メモリ」、「HDD」など)が代入される。
【0226】
「kf:where」タグから始める要素の記述により、「$k」=「周辺装置」もしくは「$k」=「$x」という比較がなされる。
【0227】
次に、図1の構造化文書管理システムの文書検索処理動作について、図43に示すフローチャートを参照して説明する。
【0228】
図31に示した画面上で、ユーザが「XML検索Win」をマウス等のポインティングデバイスなどを用いて選択すると、図44に示すような文書検索を行うためのユーザインタフェースとしての画面が表示される。
【0229】
図44の検索画面において、領域W1には、前述同様、構造化文書データベースの現在のツリー構造の要素名(タグ名)がユーザが理解可能なように簡略的に表示されてている。
【0230】
領域W2は、検索対象の範囲(ツリー構造上の検索範囲)や、検索条件などを入力するための領域である。領域W3には、検索結果が表示される。
【0231】
例えば、「「uix://root」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「1998」年以降に作成された文書を検索せよ」という検索要求の場合には、領域W1から「root」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「特許」を入力する(この場合、領域W1から「特許」をマウス等で選択することにより入力してもよい)。また、検索条件として、「「タイトル」という要素の値に「文書」という文字列を含む」「「年」という要素の値が「1998」以上である」という内容を予め設定されたデータ入力領域に入力すればよい。
【0232】
その後、「検索」ボタンB21を選択することにより、例えば、図45に示すようなクエリが、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。クエリの格納場所は、予め定められており、システム側が自動的に、この追加コマンドのパラメータを設定することとなる。例えば、構造化文書データベースが図18に示した状態のとき、当該クエリの格納場所を表すパラメータとしての構造化文書パスは、「uix://root/クエリDB」となる。また、追加コマンドのもう一方のパラメータは、当該クエリ文書である。
【0233】
要求受付部11は、上記クエリを受け付けると(ステップS101)、当該クエリを検索要求処理部3へ渡す。そして、当該クエリ文書を格納するための追加コマンドのパラメータを文書格納部21へ渡す。この追加コマンドの処理を、前述同様に行って、当該クエリは、文書記憶部5に格納される。
【0234】
例えば、図42に示すようなクエリの場合、構造化文書データベースには、図46に示すように展開されて、構造化文書パス「uix://root/クエリDB」の示す「#301」ノード以下にリンクされる。
【0235】
一方、検索要求処理部3では、受け取ったクエリを基に、データアクセス部4を通してインデックス記憶部6,文書記憶部5にアクセスし、検索要求に合致する文書集合などを取得して、クエリの中で要求された情報を抽出して結果処理部12を介して出力する。
【0236】
例えば、上記クエリの場合、まず、「「タイトル」タグに「文書」という文字列を含む」という条件に合致するものを検索することが検索対象を絞り込む上で効率がよい。そこで、図10に示したようなデータ生起インデックスを用いて、「文書」という文字列にリンクされているノード(文書オブジェクト)のオブジェクトIDを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に1つ遡り、「タイトル」というタグ名にたどり着いたときは、更に上流に辿っていき、「特許」というタグ名にたどり着いたときは、そのノード以下の文書オブジェクトツリーOt11を抽出する。
【0237】
次に、この抽出された複数の文書オブジェクトツリーOt11の中から、さらに、「年」という要素の値が「1998」年以上の文書オブジェクトツリーOt12を抽出する。
【0238】
この文書オブジェクトツリーOt12が上記クエリの内容に適合する文書となる。さらに上記クエリの要求内容に従えば、各文書オブジェクトツリーOt12のトップノードへの構造化文書パスを求める(ステップS102)。
【0239】
なお、上記検索処理は、上記した方法に限るものではなく、インデックス情報を用いた様々な効率のよい検索方法が可能である。
【0240】
検索要求処理部3は、ステップS102で得られた結果を統合して、検索結果としてのXML文書を作成する(ステップS103)。
【0241】
例えば、検索結果のXML文書は、
<out>
<result>
uix://root/特許DB/特許[0]
</result>
<result>
uix://root/特許DB/特許[2]
</result>
</out>
となる。
【0242】
検索要求処理部3は、検索結果処理部12を介して、上記XML文書をスタイルシートとともに、要求元のクライアント端末に返す(ステップS104)。
【0243】
クライアント端末では、図11に示したXML文書を、スタイルシートを用いてHTMLデータに変換して、例えば、図44に示すように、領域W12に表示する。
【0244】
同様にして、スキーマの検索も行える。
【0245】
例えば、「「uix://root」以下の「schema」を先頭タグに持つ文書の中から、「特許」と「要約」というタグ名を持つスキーマを検索せよ」という検索要求の場合には、図47に示すように、領域W1から「root」をマウス等で選択して検索対象の範囲として、構造化文書パスを入力する。そして、トップノードとして、「#schema」を入力する。また、検索条件として、「要素の属性名に「特許」という文字列を含む」「要素の属性名に「要約」という文字列を含む」という内容を予め設定されたデータ入力領域に入力すればよい。
【0246】
その後、「検索」ボタンB21を選択することにより、上記検索要求を記述したクエリ(図48参照)が、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信される。
【0247】
さて、上記クエリの場合、例えば、「「#schema」を先頭タグに持つ」という条件に合致するものを検索する。そこで、図9に示したような要素名称生起インデックスを用いて、「#schema」という要素にリンクされているノードの(文書オブジェクト)のオブジェクトIDを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、属性名が「特許」と「要約」いう要素にたどり着いたときは、当該「#schema」を先頭タグにもつ文書オブジェクトツリーOt21を抽出する。この文書オブジェクトツリーOt21が上記クエリの内容に適合する文書となる。さらに、図48に示したクエリの要求内容に従えば、各文書オブジェクトツリーOt21のトップノードへの構造化文書パスを求める。
【0248】
検索要求処理部3は、文書オブジェクトツリーOt21が複数あれば、それぞれのトップノードへの構造化文書パスをまとめて、検索結果としてのXML文書を作成し、検索結果処理部12を介して、上記XML文書をスタイルシートとともに、要求元のクライアント端末に返す。
【0249】
クライアント端末では、検索結果として受け取ったXML文書を、スタイルシートを用いてHTMLデータに変換して、例えば、図44に示すように、領域W12に表示する。
【0250】
クライアント端末では、検索結果の中の1つのスキーマを選択して、表示させると、例えば、図38に示すような文書の格納/削除を行うための画面とともに、その領域W3に、「特許」情報のデータ入力領域が各要素毎に設定されて表示される。
【0251】
ユーザは、このデータ入力領域にデータを入力することで、スキーマにより定義された文書構造の格納文書が容易に作成することができる。
【0252】
例えば、図38の領域W3に入力した「特許」情報の格納先として、領域W1で「特許DB」をマウス等を用いて選択すると、領域W2に構造化文書パスとして、「uix://root/特許DB」が表示される。その後、「登録」ボタンB1を選択すると、「appendXML(“uix://root/特許DB”,“<特許>…</特許>”)」なる追加コマンドが構造化文書管理システムへ送信される。
【0253】
この場合、格納文書は、予めスキーマに従って入力されたものなので、図20のステップS10の妥当性チェックでエラーとなることはない。
【0254】
同様にして、クエリの検索も行える。クエリを検索して、検索結果として得られた既存のクエリを加工して、再利用することもできる(クエリの再利用)。
【0255】
クエリの検索は、前述したような構造化文書の検索と同様にして行われ、その検索範囲は、クエリ群の格納されている構造化データベース上の一部の文書オブジェクトツリーとなる。
【0256】
例えば、図18に示したような状態の構造化文書データベースから、「kf:from」タグに「特許DB」を含むクエリを検索する場合について説明する。そのような検索要求を記述したクエリを図49に示す。
【0257】
図49に示すクエリは、「「uix://root/クエリDB」の示す「#301」ノード以下に存在するクエリの中から「kf:from」タグに「特許DB」を含むクエリを検索し、その内容(タグ名が「query」である要素以下の文書オブジェクトツリーの文書)を列挙せよ」を意味するものである。
【0258】
なお、「kf:as」タグの内容で変数「$elt」に、「kf:from」タグに「特許DB」を含むクエリのタグ名が「query」である要素以下の文書オブジェクトツリーが代入される。
【0259】
このクエリを検索要求処理部3が処理する際には、前述同様にして、例えば、図9に示したような要素名称生起インデックスを用いて、「kf:from」という要素にリンクされているノードの(文書オブジェクト)のオブジェクトIDを得る。そして、そのそれぞれについて、文書オブジェクトツリーを下流側にアークを辿っていき、「特許」というタグ名にたどり着いたときは、さらに、上流側にアークを辿って「query」というタグ名に辿りついたとき、当該「query」を先頭タグにもつ文書オブジェクトツリーOt31を抽出する。この文書オブジェクトツリーOt31が上記クエリの内容に適合する文書となる。
【0260】
複数の文書オブジェクトツリーOt31が検索されたら、それらを統合して、XML文書を作成して、それをスタイルシートとともにクライアント端末へ返す。
【0261】
クライアント端末では、検索結果の中の1つのクエリを選択して、表示させると、例えば、図44に示した検索画面の領域W11に、各データ入力領域にデータの入力された状態で、当該クエリに記述された検索要求の内容が表示される。
【0262】
ユーザは、この状態から、「「uix://root」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「文書」という文字列を含み、「1998」年以降に作成された文書を検索せよ」という当該クエリに記述された検索要求中の「文書」を「XML」に変更して、「検索」ボタンB21を選択すれば、「「uix://root」以下の「特許」を先頭タグに持つ文書の中から、「タイトル」タグに「XML」という文字列を含み、「1998」年以降に作成された文書を検索せよ」という意味のクエリが構造化文書管理システムへ送信される。
【0263】
以上説明したように、図1の構造化文書管理システムでは、構造化文書データベース上に登録される文書構造が異なる膨大な数のXML文書群(コンテンツ文書、スキーマ文書、クエリ文書など)を、図18,図19に示すように、「root」タグを先頭に持つツリー状の1つの巨大なXML文書として取り扱う。従って、文書構造が異なる、様々なスキーマを持つ膨大な数の文書の中から検索条件に合致する文書を容易に検索できる。
【0264】
また、検索に用いるクエリも構造化文書であるので、構造化文書データベースにログとして格納することにより、過去のクエリを再利用するようなアプリケーションも容易に構築することができる。
【0265】
(3)適用例
次に、上記概念検索の特許調査への適用例について説明する。
【0266】
図50は、特許調査における構造化文書データベースの一例であり、「特許」情報の他に、「概念」情報も格納している。
【0267】
特許調査において、最も重要となってくる作業は、関連する「特許」情報を収集し、「特許」情報を様々な観点から分析し、特許マップ(図54参照)を作成することである。特許マップを作成するために、従来、特許マップにおける縦軸、横軸を予め決定し、それに従い、縦軸に並ぶ任意の項目と横軸に並ぶ任意の項目とを検索条件とした検索を逐次行うという方法がとられ、この部分に非常に莫大なコストがかかっていた。しかし、構造化文書管理システムを用いることで、この部分のコストを大幅に減少させることが可能となる。
【0268】
なお、ここで、マップとは、縦軸(y軸)に並ぶ任意の項目と横軸(x軸)に並ぶ任意の項目とを検索条件とした検索結果をx軸とy軸とを分類軸として分類整理するものである。
【0269】
構造化文書管理システムで、クライアント端末のユーザが図54に示すような特許マップを作成しようとする場合、ユーザは、クライアント端末上の表示装置に表示される図50に示すような構造化文書データベースの現在のツリー構造を参照して、図51に示すような検索画面上に、分析対象の範囲とする「特許」情報のパスと、分析の軸(例えば、x軸、y軸)となる要素を、それぞれ領域W21、W22に入力する。分析の軸となる要素は、構造化文書データベース内の「特許」情報の要素、「概念」情報の要素のいずれであってもよい。
【0270】
例えば、図51では、x軸に「機能」、y軸に「技術」という「概念」情報の要素を入力している。
【0271】
その後、ユーザは、「実行」ボタンB31を選択すると、クライアント端末から図1の構造化文書管理システムへ、図52に示したようなクエリが送出される。
【0272】
この場合のクエリには、「「特許DB」アークが示すノード以下に格納されている「特許」情報の文書群の中から、「概念DB」アークが示すノード以下に格納されている、概念「機能」の子要素のいずれかと概念「技術」の子要素のいずれかとを、「キーワード」や「要約」などの要素の値に含む「特許」情報を検索せよ。検索結果として、「機能」の子要素と「技術」の子要素と、それらに対応する「特許」情報の「公開番号」との組を列挙せよ。」という意味の検索要求である。
【0273】
概念「機能」には、「検索」「格納」…「分析支援」という子要素があり、概念「技術」には、「実装データベース」「反構造データベース」「自然言語処理」…という子要素があるものとする。
【0274】
上記クエリを受けた構造化文書検索システムの検索要求処理部3では、例えば、図10に示したようなデータ生起インデックスを用いて、概念「機能」の各子要素(文字列)にリンクされているノード(文書オブジェクト)のオブジェクトIDを得る。そして、そのそれぞれについて、文書オブジェクトツリーを上流側に遡り、「特許」というタグにたどり着いたときは、さらに、そのノード以下の文書オブジェクトツリーを下流側に辿って概念「技術」の子要素(文字列)のいずれかにリンクされているタグ名にたどり着いたときは、当該文書オブジェクトツリーと、その「公開番号」タグにリンクされている文字列(要素値)を抽出する。このようにして、抽出された「特許」情報のそれぞれについて、対応の「機能」の子要素と「技術」の子要素と「公開番号」との組を統合して、図53に示すような検索結果としてのXML文書を作成、要求元のクライアント端末へ、所定のスタイルシートとともに返す。
【0275】
これらを受け取ったクライアント端末の表示装置には、図54に示したような表形式の特許マップが表示されることになる。
【0276】
このように、所望の概念を「軸」として指定するだけで、構造化文書データベースに蓄積された情報を「軸」として指定された概念に基づき集計・分類して、マップ表示するこたが容易に行える。すなわち、構造化文書データベースに蓄積された情報を、「概念」情報を用いて様々な観点で集計・分類することが容易に行える。
【0277】
(本発明の実施形態の説明−構造化文書の編集)
以下、本発明の実施の形態について図面を参照して説明する。
【0278】
上記構造化文書データベースに格納されている構造化文書は、書き換えが許可されていないとする。このような場合であっても、ユーザは、個々の利用目的に応じて、クライアント端末102を介して上記構造化文書データベースから検索した構造化文書を編集、加工したという要望がある。
【0279】
上記構造化文書データベースから検索した構造化文書に付け加えたい情報としては、例えば、個人的な評価、日報における(案件処理の)緊急度、人事データにおける重要人物度、その他、複数の特定のユーザからなるユーザグループ内では共有したいが、それ以外のユーザには秘密にしておきたい情報などがある。
【0280】
以下、構造化文書への書き換えが不可能な場合、構造化文書データべースに対しては何ら操作を行わずに、構造化文書への編集(加工)が行え、その編集した結果を含めて、文書の検索を可能にする構造化文書編集機能について説明する。
【0281】
図55は、上記したような機能を実現するためのクライアント端末102の構成例を示したものである。
【0282】
図55に示したクライアント端末102は、図2に示したように、WWW(World Wide Web)のバックエンドで動作する、図1に示した構成の構造化文書管理システム100に対し、アクセスする場合を示している。また、図55に示したクライアント端末102の各構成部の機能を、WWWブラウザ103にアドインして実現することもできる。
【0283】
図55の場合、クライアント端末102とWWWサーバ101とは、図2と同様、例えば、HTTP(Hyper Text Transfer Protocol)で通信し、また、WWWサーバ101と構造化文書管理システム100とは、CGI(Common Gateway Interface)またはCOM(Component Object Model)などで通信している場合を示している。
【0284】
図55に示した構成において、クライアント端末102は、ユーザタグ登録部201、検索要求入力部202,検索結果表示処理部203,文書編集部204,拡張文書検索要求入力部205,ユーザタグ記憶部206,追加文書抽出部207,検索要求分離部208,追加文書検索部209,追加文書記憶部210,文書合成部211から構成されている。
【0285】
図55に示した構成のクライアント端末102を用いて、ユーザは、まず、個人利用のためのタグ、すなわち、ユーザタグを登録し、このユーザタグで囲まれた新たな構成要素を、構造化文書データベースから読み出された構造化文書に追加することにより、当該構造化文書の編集を行う。その際、ユーザ側から見れば、構造化文書には新たな構成要素が追加して、実際に当該構造化文書自体を編集したことになるが、この編集によっては構造化文書データベースに対し何ら操作を行うことはないので、構造化文書データベースからみれば、単に、格納済みの構造化文書を読み出してクライアント端末102に提供しているにすぎない。すなわち、構造化文書データベースに格納されている構造化文書が書き換えられることはない。
【0286】
なお、新たな構成要素の(構造化文書における)追加位置は、予め定められた固定位置とし、ここでは、構造化文書の最後の構成要素としてこの新たな構成要素を追加するものとする。なお、新たな構成要素の追加位置を上記したように「最後」とする場合に限らず、先頭、すなわち、最初の構成要素として追加するようにしてもよいし、場合によっては、上から2番目、3番目、…の構成要素として、構造化文書の中間に追加するようにしてもよい。本発明においては、新たな構成要素の追加位置を特に限定するものではないが、好ましくは、本実施形態のように、最後の構成要素として、構造化文書の最後に追加することが望ましい。
【0287】
構造化文書に追加された、ユーザタグで囲まれた新たな構成要素を含むXML形式の構造化文書を追加文書と呼ぶ。
【0288】
上記編集結果を検索にも反映するために、上記新たな構成要素(を含む追加文書)を、その新たな構造化文書が追加される構造化文書に対応付けて記憶しておく。
【0289】
検索時には、新たな構成要素に基づく検索条件の指定も可能となる。この場合、ユーザから指定された検索条件などのが記述されたクエリ(拡張クエリ)をそのまま構造化文書管理システム100に送出することはできないので、当該クエリから新たな構成要素を指定した検索条件などの記述を取り除いてから、構造化文書管理システム100にクエリを送出する。同時に、新たな構成要素を指定した検索条件を満たす追加文書を検索するための追加文書用のクエリも作成して、この追加文書用クエリを用いて、追加文書の検索を行う。
【0290】
そして、構造化文書管理システム100から送られてきた検索結果としての構造化文書に、追加文書の検索結果として得られた追加文書を合成した後、拡張文書としてユーザに提示する。
【0291】
ユーザタグ登録部201は、ユーザタグ(タグ名と、その取り得る値(の範囲))をユーザタグ記憶部206に登録するためのものである。
【0292】
検索要求入力部202は、ユーザから入力された検索対象の範囲や、検索要求等に基づき、構造化文書管理システム100へそのまま送信可能な(通常の)クエリを生成する。
【0293】
拡張文書検索要求入力部205は、ユーザから入力された検索対象の範囲や、検索要求等に基づき、拡張クエリを生成する。
【0294】
検索結果表示処理部203は、構造化文書管理システムで上記通常のクエリを実行した結果得られた検索結果や、上記拡張クエリを実行した結果得られた検索結果を、クライアント端末102の表示装置に表示するための処理を行う。
【0295】
その際、構造化文書管理システムから当該検索結果とともに送られてくるスタイルシートを用いて当該検索結果を表示するようにしてもよいが、この場合に限らず、予め定められたスタイルで、検索結果を表示するようにしてもよい。また、後述するように、検索結果として拡張文書を表示する際には、当該スタイルシートを拡張文書対応に変更して用いるようにしてもよい。
【0296】
文書編集部204は、ユーザタグ記憶部206に登録したユーザタグを用いて新たな構成要素を作成して、それを構造化文書管理システムで上記通常のクエリを実行した結果得られた構造化文書に追加することにより、構造化文書データベースに格納されている構造化文書を編集するためのものである。
【0297】
追加文書抽出部207は、文書編集部204で構造化文書に追加された新たな構成要素を取出し、それに、この新たな構成要素が追加された構造化文書の文書IDを加えて、XML形式の構造化文書である追加文書を作成する。ここで作成された追加文書は、追加文書記憶部210に記憶される。
【0298】
検索要求分離部208は、拡張文書検索要求入力部205で生成された拡張クエリからユーザタグを指定した検索条件を取り除いた通常のクエリと、追加文書用のクエリとを生成する。
【0299】
追加文書検索部209は、追加文書用クエリに基づき、当該クエリに記述された検索条件を満たす追加文書を追加文書記憶部210から検索する。
【0300】
文書合成部211は、追加文書用クエリを実行して得られた追加文書と、通常のクエリを実行して得られた構造化文書とを合成して、拡張文書を作成する。
【0301】
ここで、構造化文書管理システム100の文書記憶部5に格納されている構造化文書データベースは、現在、図56に示すような状態である場合を考える。
【0302】
なお、図56に示した構造化文書データベースの構造化文書の格納状態は、ノードやアークを簡略化し、ノードをオブジェクトIDではなく要素名や属性名で表して文書オブジェクトツリーの構造、しいていは、構造化文書データベースの構造を示している。
【0303】
図56において、「root」ノード以下には、「特許DB」ノードがある。「特許DB」ノード以下には、図57に示すような文書構造の複数の「特許」情報が格納されている。
【0304】
図57に示すように、「特許」情報は、「特許」タグから始まる要素をルート(根)とし、その子要素として「文書ID」「タイトル」、「出願人」、「出願番号」、「要約」タグから始まる要素集合が存在する。文書IDは、構造化文書データベースに格納されている全ての構造化文書のそれぞれを識別するための識別情報であり、各構造化文書を構造化文書データベースに格納する際に、追加される構成要素である。文書IDは、システム100側で自動的に発番して追加する構成要素であってもよい。
【0305】
さて、図55に示した構成のクライアント端末102の処理動作について、図76〜図77に示すフローチャートに従って説明する。
【0306】
まず、図76に示すフローチャートに従って、文書編集処理について説明する。
【0307】
(ステップS201)
ユーザタグ登録部201は、ユーザが、例えば、個人利用のための情報を、構造化文書データベース上の構造化文書に追加するために用いる新たな構成要素の要素名(ユーザタグ名)と、その要素のとりえる値の(範囲)とを登録するためのものである。
【0308】
ユーザタグ登録部201からは、クライアント端末102の表示装置に、例えば、図58に示すようなユーザタグ登録画面が表示される。この画面上に、所望の要素名(タグ名)と、その取り得る値(の範囲)とを入力して、「登録」ボタンB101をマウス等でクリックすることで、ユーザタグの登録が行える。
【0309】
図58では、1人のユーザにつき、3つまでのユーザタグの登録が可能となっている。タグ名の入力領域W101〜W103に所望のタグ名を入力し、そのそれぞれについて、そのとりえる値(の範囲)を入力領域W104〜W106に入力する。例えば、図58では、「評価」というタグ名と、その取り得る値として、「A」、「B」、「C」、「D」、「E」が入力され、「処理形態」というタグ名には、その取り得る値として、「公開まで」、「審査請求」、「外国出願」が入力されている。
【0310】
なお、各ユーザタグの登録領域には、それぞれ「オプション」ボタンB102〜B104が設けられているが、これは、各ユーザタグの要素に子要素を設定する場合に用いる。例えば、ユーザタグとして「閲覧日」を登録したとする。この「閲覧日」要素の子要素として、「年」、「月」、「日」を登録したい場合には、この「オプション」ボタンをクリックしてから、これらを登録すればよい。
【0311】
さて、図58に示したユーザタグ登録画面上に、所望のユーザタグと、その取り得る値(の範囲)を入力した後、「登録」ボタンB101をクリックすると、ユーザタグ記憶部206には、当該ユーザの識別情報としてのユーザIDに対応付けて、図59に示したように、ユーザタグが登録される。
【0312】
図59において、ユーザタグ記憶部206には、ユーザIDに対応付けて、当該ユーザが登録したユーザタグ名と、その取り得る値(の範囲)とが記憶されている。
【0313】
(ステップS202)
図55の検索要求入力部202は、構造化文書管理システム100に対する、ユーザタグの指定を含まない、通常の検索要求を行うためのクエリを生成するためのものである。
【0314】
検索要求入力部202からは、クライアント端末102の表示装置に、例えば、図60に示すような検索画面が表示される。
【0315】
図60に示した検索画面上の領域W111には、構造化文書データベースの現在のツリー構造の要素名(タグ名)がユーザが理解可能なように簡略的に表示されてている。
【0316】
領域W112〜W116は、検索対象の範囲(ツリー構造上の検索範囲)や、検索条件などを入力するための領域である。
【0317】
例えば、「「uix://root/特許DB」以下に格納されている文書の中から、「出願人」タグに「T社」という文字列を含む文書を検索せよ」という検索要求の場合には、領域W111から「特許DB」をマウス等で選択することにより、検索対象の範囲と指定する構造化文書パスの入力領域W112に、「uix://root/特許DB」が入力する。また、検索条件として、「「出願人」という要素の値に「T社」という文字列を含む」という内容を設定するために、タグ名の入力領域W113に「出願人」、その値の入力領域W114に「T社」を入力すればよい。例えば、タグ名を入力する際には、その入力領域のリストボックスのボタンをクリックして、リストボックスを表示させ、その中から所望のタグ名を選択するようにしてもよい。この場合、リストボックスには、構造化文書データベースに現在格納されている全ての構造化文書の各構成要素のタグ名が表示される。
【0318】
その後、「検索実行」ボタンB111を選択することにより、例えば、「「uix://root/特許DB」以下に格納されている文書の中から、「出願人」タグに「T社」という文字列を含む文書を検索せよ」という内容のクエリが構造化文書管理システム100へ送信される。このとき、当該クエリを構造化文書データベース上に格納するための追加コマンドとともに構造化文書管理システムへ送信されてもよい。
【0319】
このようなクエリを受け取った構造化文書管理システム100からは、当該クエリを実行して、その検索結果をスタイルシートとともに、要求元のクライアント端末102へ送り返す。クライアント端末102では、検索結果表示処理部203で上記検索結果としてのXML文書をスタイルシートを用いてHTMLデータに変換して、クライアント端末102の表示装置に表示する。
【0320】
なお、検索結果表示処理部203で検索結果を表示する際の処理には、構造化文書管理システム100から当該検索結果とともに送られてきたスタイルシートを必ずしも用いる必要はない。予め定められたスタイルで、検索結果を表示するようにしてもよい。また、後述するように、検索結果として拡張文書を表示する際には、当該スタイルシートを拡張文書対応に変更して用いるようにしてもよい。
【0321】
さて、上記クエリを実行した結果として、クライアント端末102の表示装置には、図61に示すような、上記検索条件を満たす構造化文書の文書IDの一覧が表示される。この一覧から、ユーザが所望の文書ID、例えば「DOC100」を選択することにより、当該文書IDの内容が、例えば、図62に示したように表示される。
【0322】
図62では、文書ID「DOC100」の「特許」情報をその各構成要素毎に、その要素名(タグ名)に対応付けて表示している。
【0323】
(ステップS203)
文書編集部204は、構造化文書データベースから検索して得られた構造化文書に対し、ユーザタグを用いて編集を行うためのものである。ここでいう編集とは、前述したように、構造化文書にユーザタグにて囲まれた新たな構成要素を追加することである。
【0324】
新たな構成要素の(構造化文書における)追加位置は、予め定められた固定位置とし、ここでは、構造化文書の最後の構成要素としてこの新たな構成要素を追加するものとする。
【0325】
例えば、図62に示した検索結果閲覧画面上に表示されている構造化文書に対し、編集を行う場合、当該画面上に設けられている「編集」ボタンB121をマウス等でクリックすればよい。すると、クライアント端末102の表示装置には、文書編集部204から、図63に示すような文書編集画面が提供される。
【0326】
図63に示した文書編集画面には、先の検索結果閲覧画面に表示されていた文書ID「DOC100」の構造化文書の各構成要素の他に新たな構成要素を追加するための入力領域W131〜W136が表示されている。ここでは、1人のユーザに3つまでのユーザタグの登録が許されているから、最高3つまでの新たな構成要素が追加可能になっている。
【0327】
ユーザは、図63の文書編集画面上で、当該構造化文書に、ユーザタグ名が「評価」の構成要素を追加する場合、まず、入力領域W131に「評価」を入力し、入力領域W132に、その値として、例えば、「A」を入力すればよい。
【0328】
この場合も、タグ名を入力するときは、入力領域W131に設けられているリストボックスのボタンをクリックして、図64(a)に示すような、当該ユーザが登録したユーザタグ名を一覧表示したリストボックスを表示させ、その中から所望のタグ名を選択するようにしてもよい。この場合、リストボックスには、ユーザタグ記憶部206から当該ユーザのユーザIDに対応つけられて記憶されたユーザタグ名が読み出されて表示される。
【0329】
同様にして、要素値を入力する際も、入力領域W132に設けられているリストボックスのボタンをクリックして、図64(b)に示すような、当該ユーザが登録した当該タグ名の要素値を一覧表示したリストボックスを表示させ、その中から所望の要素値を選択するようにしてもよい。この場合、リストボックスには、ユーザタグ記憶部206から当該ユーザのユーザIDに対応つけられて記憶されたユーザタグ名対応の要素値が読み出されて表示される。
【0330】
図63に示したように、文書編集画面上で、当該構造化文書に、ユーザタグ名が「評価」の構成要素の入力を行った後、「編集完了」ボタンB131をマウス等でクリックすることにより、当該構造化文書の編集が終了する。
【0331】
(ステップS204)
「編集完了」ボタンB131がクリックされると、図55の追加文書抽出部207は、文書編集画面上で追加された新たな構成要素から追加文書を抽出する。
【0332】
すなわち、追加文書抽出部207は、追加された新たな構成要素(例えば、ここでは、<評価>A</評価>)を取出し、それに、この新たな構成要素の追加された構造化文書の文書ID(例えば、ここでは、<文書ID>DOC100</文書ID>)を加えて、図65に示したようなXML形式の追加文書を作成する。
【0333】
(ステップS205)
図65に示したような追加文書は、追加文書記憶部210に記憶される。
【0334】
追加文書記憶部210には、各追加文書が、図66に示すように、各ユーザ毎に追加文書の論理構造に基づくツリー構造状に格納されている。この追加文書記憶部210における追加文書を記憶するためのデータ構造は、構造化文書管理システム100の構造化文書データベースと同様であってもよい。
【0335】
なお、本発明では、追加文書を記憶する際のデータ構造は特に限定するものではないので、上記したように、追加文書をXML形式の構造化文書として記憶する以外に、例えば、新たな構成要素であるユーザタグ名と、その値とを、当該新たな構成要素の追加される構造化文書の文書IDや、ユーザIDとともに、テーブル形式記憶するようにしてもよい。要は、追加文書記憶部210では、少なくとも、新たな構成要素を、その所有者であるユーザと、当該新たな構成要素の追加される構造化文書とに対応つけて記憶するようになっていればよい。ただし、検索の効率を考慮すると、本実施形態のように、XML形式の構造化文書として、構造化文書管理システム100の構造化文書データベースと同様なデータ構造にて記憶することが望ましい。
【0336】
例えば、図66に示すような追加文書記憶部210のデータ構造において、ユーザID「abc」のユーザ対応の追加文書の格納領域の構造化文書パスは「uix://root/ユーザabc」となる。図65に示した追加文書は、図66では、構造化文書パス「uix://root/ユーザabc/追加文書[2]」と表すことのできる格納領域に格納されている。
【0337】
次に、図77に示すフローチャートに従って、図55のクライアント端末102の拡張文書の検索処理動作について説明する。
【0338】
(ステップS211)
図55の拡張文書検索要求入力部205は、以上のようにして、構造化文書データベースから検索された構造化文書に新たな構成要素を追加した結果である拡張文書の検索を行うためのものである。
【0339】
この拡張文書の検索を行うための検索画面は、例えば、検索要求入力部202から提供される図60に示したような検索画面上に設けられた「拡張文書検索」ボタンB113がマウス等でクリックされたとき、拡張文書検索要求入力部205から提供される。
【0340】
拡張文書要求入力部205からは、クライアント端末102の表示装置に、例えば、図67に示すような拡張文書検索画面が表示される。
【0341】
図67に示す拡張文書検索画面には、図60に示した検索画面のように、構造化文書データベースに基づく検索対象の範囲(ツリー構造上の検索範囲)や、検索条件などを入力するための領域W142〜W146以外に、ユーザタグを指定した検索条件を入力するため領域W147〜W152が設けられている。
【0342】
図67に示した拡張文書検索画面上の領域W141には、構造化文書データベースの現在のツリー構造の要素名(タグ名)がユーザが理解可能なように簡略的に表示されてている。
【0343】
領域W142〜W152は、検索対象の範囲(ツリー構造上の検索範囲)や、検索条件などを入力するための領域である。
【0344】
例えば、「「uix://root/特許DB」以下に格納されている文書の中から、「出願人」タグに「T社」という文字列を含み、かつ、「評価」タグに「A」という文字列を含む文書を検索せよ」という検索要求の場合には、領域W141から「特許DB」をマウス等で選択することにより、検索対象の範囲と指定する構造化文書パスの入力領域W142に、「uix://root/特許DB」が入力する。
【0345】
また、検索条件として、「「出願人」という要素の値に「T社」という文字列を含む」という内容を設定するために、タグ名の入力領域W143に「出願人」、その値の入力領域W144に「T社」を入力すればよい。例えば、タグ名を入力する際には、その入力領域のリストボックスのボタンをクリックして、リストボックスを表示させ、その中から所望のタグ名を選択するようにしてもよい。この場合、リストボックスには、構造化文書データベースに現在格納されている全ての構造化文書の各構成要素のタグ名が表示される。
【0346】
また、検索条件として、「ユーザタグ名「評価」という要素の値に「A」という文字列を含む」という内容を設定するために、ユーザタグ名の入力領域W147に「評価」、その値の入力領域W148に「A」を入力すればよい。例えば、ユーザタグ名を入力する際には、その入力領域のリストボックスのボタンをクリックして、図64(a)に示すような、当該ユーザが登録したユーザタグ名を一覧表示したリストボックスを表示させ、その中から所望のタグ名を選択するようにしてもよい。この場合、リストボックスには、ユーザタグ記憶部206から当該ユーザのユーザIDに対応つけられて記憶されたユーザタグ名が読み出されて表示される。
【0347】
同様にして、要素値を入力する際も、入力領域W147に設けられているリストボックスのボタンをクリックして、図64(b)に示すような、当該ユーザが登録した当該タグ名の要素値を一覧表示したリストボックスを表示させ、その中から所望の要素値を選択するようにしてもよい。この場合、リストボックスには、ユーザタグ記憶部206から当該ユーザのユーザIDに対応つけられて記憶されたユーザタグ名対応の要素値が読み出されて表示される。
【0348】
(ステップS212)
その後、「検索実行」ボタンB141を選択することにより、例えば、図68に示すような、「「uix://root/特許DB」以下に格納されている文書の中から、「出願人」タグに「T社」という文字列を含み、かつ、「評価」タグに「A」という文字列を含む文書を検索せよ」という内容のユーザタグを指定した検索条件を含むクエリ(ここでは、これを通常のクエリと区別するために拡張クエリと呼ぶ)が生成される。
【0349】
なお、拡張クエリは、ユーザタグを指定した検索条件の記述を含み以外は、通常のクエリと同様である。
【0350】
(ステップS213)
図68に示したクエリには、10行目と15行目に、ユーザタグを指定した検索条件が含まれているので、このままでは、構造化文書管理システムへは送ることができない。
【0351】
そこで、図55の検索要求分離部208は、拡張文書検索要求入力部205で生成された、例えば、図68に示したような拡張クエリからユーザタグを指定した検索条件を取り除いた通常のクエリと、追加文書用のクエリをとを生成する。
【0352】
拡張クエリから通常のクエリを生成するためには、単純に、当該ユーザタグを指定した検索条件の記述を削除すればよい。
【0353】
例えば、図68に示した拡張クエリの記述のうち、10行目と15行目を削除すれば、図69に示したような、構造化文書管理システム100へ送出するための通常のクエリを生成することができる。
【0354】
一方、追加文書用のクエリを生成するために、検索要求分離部208は、数種類のクエリのテンプレートを予め記憶しているものとする。
【0355】
例えば、図68に示したクエリは、「「uix://root/特許DB」以下に格納されている文書の中から、「出願人」タグに「T社」という文字列を含み、かつ、「評価」タグに「A」という文字列を含む文書を検索せよ」という内容のものであったが、クエリは、一般的に、検索対象の範囲(上記クエリの場合、「uix://root/特許DB」)と、構造化文書の構成要素(上記クエリの場合、「出願人」と「評価」)とその値(上記クエリの場合、「T社」と「A」)とを指定した少なくとも1つの検索条件(上記クエリの場合、2つの検索条件がある)の記述から構成されている。
【0356】
そこで、図70に示すような、追加文書用クエリのテンプレートを予め作成しておく。図70に示した追加用文書用クエリのテンプレートは、クエリの記述のうち検索対象の範囲を記述する部分(t1)と、検索条件としての構成要素を記述する部分(t2,t3)、構成要素の値を記述する部分(t4,t5)に、拡張クエリを介してユーザにより指定された検索対象の範囲と、検索条件としての構成要素とその値とを代入すれば、即、クエリとして実際に実行可能となるものである。
【0357】
図70に示した追加文書用クエリのテンプレートは、検索条件が2つある場合のテンプレートであるが、検索条件の数に応じて複数のテンプレートを予め用意するようにしてもよい。
【0358】
例えば、図68に示した拡張クエリの場合、ユーザタグを指定した検索条件は1つのみであるので、検索要求分離部208は図71に示すような検索条件が1つの追加文書用クエリのテンプレートを用いる。
【0359】
図71のテンプレート中、検索対象の範囲を記述する部分t1には、検索要求を行ったユーザ(例えばユーザIDが「abc」であるユーザ)対応に予め定められた追加文書記憶部210の追加文書の格納場所を指定するための「「uix://root/ユーザabc」が代入される。また、検索条件としての構成要素を記述する部分t2には、図68の拡張クエリ中にあるユーザタグのタグ名、すなわち、「評価」が代入される。さらに、当該構成要素の値を記述する部分t4には、図68の拡張クエリ中にあるユーザタグ「評価」に対し指定された値「A」が代入される。
【0360】
その結果、図72に示すような追加文書用クエリが生成される。
【0361】
図72に示した追加文書用クエリは、「「uix://root/ユーザabc」以下に格納されている追加文書の中から、「評価」タグに「A」という文字列を含む文書を検索せよ」という内容のものである。
【0362】
(ステップS214)
例えば、図68に示したような拡張クエリから生成された図69に示したような通常のクエリは、構造化文書管理システムへ送信され、当該クエリに基づき、図43に示したようにして、構造化文書データベースに対し検索が実行される。
【0363】
(ステップS215)
一方、図68に示したような拡張クエリから生成された図72に示したような追加文書用クエリは、図55の追加文書検索部209へ渡される。
【0364】
図55の追加文書検索部209は、受け取った図72に示したような追加文書用クエリに基づき、当該クエリに記述された検索条件を満たす追加文書を追加文書記憶部210から検索する。
【0365】
追加文書検索部209では、追加文書を図66に示したようなデータ構造にて格納している。そこで、追加文書検索部209は、追加文書用クエリで、検索対象の範囲として指定された構造化文書パス(例えば、図72のクエリの場合「uix://root/ユーザabc」)で表される論理的な格納領域に格納されている追加文書の中から、「評価」タグに「A」という文字列を含む追加文書を検索する。
【0366】
(ステップS216、S217)
さて、図55の文書合成部211では、構造化文書管理システム100で、例えば、図69に示したような通常のクエリを実行して得られた検索結果を受け取るとともに、追加文書検索部209で、例えば図72に示したような追加文書用クエリを実行して得られた検索結果を受け取る。
【0367】
例えば、図72に示したような追加文書用クエリを実行して得られた検索結果として、図65に示した追加文書が得られ、図69に示したような通常のクエリを実行して得られた検索結果として、図57に示したような構造化文書が得られたとする。
【0368】
(ステップS218〜ステップS219)
文書合成部211は、当該追加文書と、当該構造化文書の構成要素として含まれている「文書ID」を取出す。この場合、両者の「文書ID」の値が同じ「DOC100」であるので、図57の構造化文書の最後の構成要素として、図65の追加文書にあるユーザタグ「評価」の構成要素「<評価>a</評価>」を追加・合成し、図73に示すようなXML文書である拡張文書を作成する。
【0369】
なお、拡張文書を作成する際の、新たな構成要素の(構造化文書における)追加位置は、編集時の場合と同様で、予め定められた固定位置とし、ここでは、構造化文書の最後の構成要素としてこの新たな構成要素を追加するものとする。なお、新たな構成要素の追加位置を上記したように「最後」とする場合に限らず、先頭、すなわち、最初の構成要素として追加するようにしてもよいし、場合によっては、上から2番目、3番目、…の構成要素として、構造化文書の中間に追加するようにしてもよい。本発明においては、新たな構成要素の追加位置を特に限定するものではないが、好ましくは、本実施形態のように、最後の構成要素として、構造化文書の最後に追加することが望ましい。
【0370】
文書ID「DOC108」の構造化文書にも、それに対応の追加文書が検索されたとすると、上記同様にして、拡張文書を作成する。
【0371】
このようようにして作成された拡張文書群が、例えば図68に示したような拡張クエリの実行結果である検索結果として、検索結果表示処理部203へ渡される。
【0372】
(ステップS220)
検索結果表示処理部203では、まず、拡張文書の文書IDの一覧を、例えば、図74に示すような検索結果一覧画面上に表示する。この検索結果一覧画面には、拡張文書の文書IDとして、例えば、「DOC100」と「DOC108」が表示されている。この中から、ユーザが、例えば、「DOC100」をマウス等でクリックして選択することにより、当該文書IDの拡張文書の内容が図75に示したように表示される。
【0373】
図75に示した検索結果閲覧画面には、文書ID「DOC100」の「特許」情報の拡張文書の内容が、その各構成要素毎に、その要素名(タグ名)に対応付けて表示している。この場合、ユーザタグ「評価」の構成要素も表示されている。すなわち、文書編集部204での編集結果が反映されて表示されている。
【0374】
以上の説明は、クライアント端末102が上記全ての構造化文書編集機能をもつ場合であるが、この場合に限らず、例えば、図78に示すように、クライアント端末102,構造化文書管理システム100と互いに通信可能なように所定のネットワークに接続された構造化文書編集装置301を設け、この構造化文書編集装置301に、図55のクライアント端末102の持つ機能の一部を持たせるようにしてもよい。
【0375】
この場合のクライアント端末102と、構造化文書編集装置310の構成を図79に示す。なお、図55と同一部分には同一符号を付し、異なる部分について説明する。すなわち、クライアント端末102は、ユーザタグ登録部201、検索要求入力部202,検索結果表示処理部203,文書編集部204,拡張文書検索要求入力部205を有し、構造化文書編集装置301は、記憶部206,追加文書抽出部207,検索要求分離部208,追加文書検索部209,追加宇文書記憶部210,文書合成部211を有している。
【0376】
各クライアント端末102には、データの入力や表示のための機能部だけを持たせ、構造化文書編集装置301には、複数のユーザで共有可能な機能部を持たせ、各クライアント端末102から送られてきたクエリ(通常のクエリ、拡張クエリ)に対する処理やユーザタグなどの処理をしたり、構造化文書管理システムからの検索結果を処理したり等する。
【0377】
このような構成により、クライアント端末102のユーザタグ登録部201,検索要求入力部202,文書編集部204,拡張文書検索要求入力部205を用いて、ユーザタグの登録や、検索要求を行う際には、必ず、構造化文書編集装置301を経由するようになっている。
【0378】
図55に示した構成では、ユーザタグ記憶部206や、追加文書記憶部210には、1人のユーザのみのユーザタグや、追加文書が格納されていればよかった。しかし、図79に示した構造化文書編集装置301は、複数のユーザで共有されるため、ユーザタグ記憶部206や、追加文書記憶部210には、必ず、複数のユーザのユーザタグや追加文書が格納されている。また、クライアント端末102からの各種コマンドメッセージなどから各ユーザを識別するためのユーザIDを取り出してから、これらユーザタグ記憶部206、追加文書記憶部210にアクセスする必要がある。
【0379】
その他、構造化文書編集装置301の持つ各機能部の処理動作は、前述同様である。
【0380】
以上説明したように、上記実施形態によれば、構造化文書管理システム100およびWWWサーバ101の構成は一切変更することなく、しかも、構造化文書データベースに対しては何ら操作を行う必要なく、書き換えが許可されていない構造化文書データべース上の構造化文書への編集(加工)と、その編集した結果を含めた構造化文書の検索が容易に行える。
【0381】
また、構造化文書データベースに対しては何ら操作を行っていないにもかかわらず、ユーザからは、構造化文書データベースに格納されていた構造化文書を直接加工したかのごとく、編集した内容のまま、構造化文書の検索、表示が可能となる。
【0382】
単なるメモを構造化文書に付加するのとは異なり、構造化文書に新たな構成要素を追加するという形態で構造化文書の編集が行えるので、個人的な利用目的で利用する各種情報(例えば、評価、日報における(案件処理の)緊急度、人事データにおける重要人物度など)や、複数の特定のユーザからなるユーザグループ内では共有したいが、それ以外のユーザには秘密にしておきたい情報などをユーザタグを用いて書き込むことにより、一般公開されている情報(構造化文書データベースに格納されている構造化文書)を用いて限定された範囲内のユーザにのみ(個人的な利用を含む)公開可能な情報(拡張文書)を作成することが容易に行える。
【0383】
また、ユーザタグを用いて、1つの構造化文書内で、一般公開可能な情報と限定された範囲内のユーザのみに公開可能な情報とを混在させることもできる。
【0384】
なお、上記実施形態では、構造化文書データベースに格納されている構造化文書には、全て、文書IDが与えられていることを前提に、この文書IDを用いて、追加文書をその追加先の構造化文書に対応付けるようになっているが、この場合に限らず、ポインタを用いて対応付けることも可能である。
【0385】
この場合は、各構造化文書が文書IDを持つ必要がない(すなわち、各構造化文書には「文書ID」タグが存在しない)。例えば、(新たな構成要素を追加する編集操作が行われた)各構造化文書毎に、当該構造化文書の編集操作を行ったユーザID対応の2種類のポインタを登録したテーブルを持たせておく。このテーブルは、例えば、追加文書記憶部210に格納されていてもよい。一方のポインタ値として、例えば、当該構造化文書の構造化文書パスを格納し、他方のポインタ値として、追加文書記憶部210に記憶されている追加文書の格納領域へのポインタ値を格納すればよい。
【0386】
なお、本発明の実施の形態に記載した本発明の手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク(フロッピーディスク、ハードディスクなど)、光ディスク(CD−ROM、DVDなど)、半導体メモリなどの記録媒体に格納して頒布することもできる。
【0387】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。さらに、上記実施形態には種々の段階の発明は含まれており、開示される複数の構成用件における適宜な組み合わせにより、種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題(の少なくとも1つ)が解決でき、発明の効果の欄で述べられている効果(のなくとも1つ)が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【0388】
【発明の効果】
以上説明したように、本発明によれば、構造化文書を提供する側(例えば、構造化文書管理システムおよびWWWサーバ)の構成は一切変更することなく、しかも、構造化文書データベースに対しては何ら操作を行う必要なく、書き換えが許可されていない構造化文書データべース上の構造化文書への編集(加工)と、その編集した結果を含めた構造化文書の検索が容易に行える。
【図面の簡単な説明】
【図1】本発明の実施形態に係る構造化文書管理システムの構成例を示した図。
【図2】図1に示した構造化文書管理システムの一利用形態を示したもので、WWWのバックエンドで、構造化文書管理システムが動作している場合を示した図。
【図3】XMLで記述された構造化文書の一例を示した図。
【図4】図3の構造化文書の文書構造を模式的に示した図。
【図5】追加コマンドの機能を説明するための図で、構造化文書データベースの初期状態に追加コマンドを実行した場合について示している。
【図6】図5(b)に示した状態の構造化文書データベースに対し、取得コマンドを実行した場合の処理結果を示した図。
【図7】図5(b)に示した状態の構造化文書データベースに対し、追加コマンドを実行して1つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図8】図5(b)に示した状態の構造化文書データベースに対し、追加コマンドを実行して3つの「特許」情報の文書オブジェクトツリーを追加した場合を示している。
【図9】要素名生起インデックスの格納例を示した図。
【図10】データ生起インデックスの格納例を示した図。
【図11】図8に示した状態の構造化文書データベースに対して、3つの「特許」情報を取り出すための取得コマンドを実行した場合の実行結果を示した図。
【図12】XML文書の文書構造を定義するスキーマの一例を示した図。
【図13】図8に示した状態の構造化文書データベースに、スキーマ格納コマンドを実行して、図12に示したスキーマを追加格納(設定)した場合を示した図。
【図14】スキーマが設定されて、スキーマが存在している旨の属性値のセットされた文書オブジェクトツリーを示した図。
【図15】各オブジェクトファイルに、スキーマが存在している旨の属性値が格納されている様子を概念的に示した図。
【図16】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図17】必要に応じて検索で使用される概念階層を構造化文書で表現した例を示した図。
【図18】図8に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図16,図17に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図19】図8に示した状態の構造化文書データベースに対し、追加コマンドを実行して、図16,図17に示した「概念」情報の文書オブジェクトツリーを追加した場合を示した図。
【図20】図1の構造化文書管理システムの文書格納処理動作について説明するためのフローチャート。
【図21】図20のステップS9の処理(合成文書作成部の処理)について説明するためのフローチャート
【図22】追加コマンド中のパラメータの格納文書の文書オブジェクトツリーを構造化文書データベースから取得した文書オブジェクトツリーに挿入して得られた合成文書の文書オブジェクトツリーをXML文書に変換した結果であって、テンポラリファイルAに格納される合成文書の一例を示した図。
【図23】テンポラリファイルBに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図24】テンポラリファイルAに格納される合成文書の他の例を示した図。
【図25】テンポラリファイルBに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図26】図1の構造化文書管理システムの文書取得処理動作について説明するためのフローチャート。
【図27】図1の構造化文書管理システムの文書削除処理動作について説明するためのフローチャート。
【図28】図27のステップS46の処理(合成文書作成部の処理(削除コマンド用))について説明するためのフローチャート。
【図29】テンポラリファイルAに格納される合成文書のさらに他の例であって、削除コマンドの実行時に作成される合成文書の一例を示した図。
【図30】テンポラリファイルBに格納される、構造化文書データベースから取得されたスキーマ文書の一例を示した図。
【図31】ユーザインタフェースとしての画面の表示例を示した図。
【図32】文書の格納/削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図33】文書の格納/削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図34】文書の格納/削除を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図35】妥当性のチェックでエラーとなっときにクライアント端末へ返すメッセージの表示例を表示例を示した図。
【図36】文書の格納/削除を行うためのユーザインタフェースとしての画面の表示例を示したもので、文書取得動作を説明するための図。
【図37】スキーマの設定を行うためのユーザインタフェースとしての画面の表示例を示したもので、スキーマの設定動作を説明するための図。
【図38】スキーマの取得するためのユーザインタフェースとしての画面の表示例を示したもので、取得されたスキーマの表示例を示している。
【図39】クエリ(XML文書)の一例を示した図。
【図40】単純検索のクエリ(XML文書)の一例を示した図。
【図41】図40の単純検索のクエリを用いた検索結果(XML文書)を示した図。
【図42】概念検索のクエリ(XML文書)の一例を示した図。
【図43】図1の構造化文書管理システムの文書検索処理動作について説明するためのフローチャート。
【図44】文書検索を行うためのユーザインタフェースとしての画面の表示例を示した図。
【図45】図44に示した画面上から入力された情報に基づき作成されるクエリを示した図。
【図46】図42に示したクエリの構造化文書データベース内における格納例を示した図。
【図47】文書検索を行うためのユーザインタフェースとしての画面の表示例であって、スキーマの検索処理動作を説明するための図。
【図48】スキーマ検索のクエリの一例を示した図。
【図49】クエリを検索するためのクエリの一例を示した図。
【図50】特許調査における構造化文書データベースの一例を示した図。
【図51】概念検索のための入力画面の表示例を示した図。
【図52】図51に示した入力画面上の入力情報に対応するクエリを示した図。
【図53】図52に示したクエリに対応する検索結果としてのXML文書を示した図。
【図54】特許マップの一例を示した図。
【図55】第2の実施形態に係るクライアント端末の構成例であって、構造化文書データべースに対しては何ら操作を行わずに、構造化文書への編集(加工)が行え、その編集した結果を含めて、文書の検索を可能にする構造化文書編集機能を有したクライアント端末の構成例を示した図。
【図56】構造化文書データベースの一例を示した図。
【図57】構造化文書の一例であって、「特許」情報を示した図。
【図58】ユーザタグ登録画面の表示例を示した図。
【図59】ユーザタグ記憶部のユーザタグの記憶例を示した図。
【図60】検索画面の表示例を示した図。
【図61】検索結果一覧画面の表示例を示した図。
【図62】検索結果閲覧画面の表示例を示した図。
【図63】文書編集画面の表示例を示した図。
【図64】検索条件として、ユーザタグや、その値を指定する際に表示されるリストボックスの表示例を示した図。
【図65】追加文書の一例を示した図。
【図66】追加文書記憶部の追加文書を格納するためのデータ構造を示した図。
【図67】拡張文書検索画面の表示例を示した図。
【図68】拡張クエリの一例を示した図。
【図69】図68の拡張クエリから生成された通常のクエリを示した図。
【図70】検索要求分離部が記憶する追加文書用クエリのテンプレートの一例を示した図。
【図71】検索要求分離部が記憶する追加文書用クエリのテンプレートの他の例を示した図。
【図72】図68の拡張クエリから生成された追加文書用クエリを示した図。
【図73】拡張文書の一例を示した図。
【図74】検索結果一覧画面の表示例を示した図。
【図75】検索結果閲覧画面の表示例であって、拡張文書の表示例を示した図。
【図76】文書編集処理動作を説明するためのフローチャート。
【図77】拡張文書の検索処理動作を説明するためのフローチャート。
【図78】構造化文書編集装置の位置づけを説明するための図。
【図79】クライアント端末と構造化文書編集装置の構成例を示した図。
【符号の説明】
1…要求制御部
2…アクセス要求処理部
3…検索要求処理部
4…データアクセス部
5…文書記憶部
6…インデックス記憶部
11…受付要求部
12…結果処理部
21…文書格納部
22…文書取得部
23…文書削除部
41…文書オブジェクトツリー格納部
42…文書オブジェクトツリー削除部
43…文書オブジェクトツリー取得部
44…文書文字列取得部
45…パスから文書オブジェクトツリー取得部
46…文書パーサ
47…合成文書作成部
48…インデックス更新部
100…構造化文書管理システム
101…WWWサーバ
102…クライアント端末
103…WWWブラウザ
201…ユーザタグ登録部
202…検索要求入力部
203…検索結果表示処理部
204…文書編集部
205…拡張文書検索要求入力部
206…ユーザタグ記憶部
207…追加文書抽出部
208…検索要求分離部
209…追加文書検索部
210…追加文書記憶部
211…文書合成部
301…構造化文書編集装置
Claims (4)
- 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに複数のノードをリンクし、当該複数のノードのうちの1つに、各構造化文書の各要素の記憶エリアを前記文書構造に従ってリンクした論理構造により前記複数の構造化文書を管理する構造化文書データベースと、
要素名及び当該要素名の要素の値に含まれる語が指定された検索条件を含む検索要求文に基づき、前記論理構造から前記検索条件を満たす要素を含む構造化文書を検索する検索手段と、
を備えた構造化文書管理装置の前記検索手段で検索された構造化文書を編集するための構造化文書編集方法であって、
前記検索手段で検索された構造化文書中の予め定められた位置に追加された新たな要素を、当該構造化文書に対応付けて記憶手段に記憶するステップと、
前記複数の構造化文書中の要素の要素名及び当該要素の値に含まれる語が指定された第1の検索条件と、前記新たな要素の要素名及び当該新たな要素の値が指定された第2の検索条件とを入力する入力ステップと、
前記第1の検索条件を含む前記構造化文書データベースに対する第1の検索要求文と、前記第2の検索条件を含む前記記憶手段に対する第2の検索要求文とを生成する生成ステップと、
前記検索手段が、前記第1の検索要求文に基づき、前記第1の検索条件を満たす構造化文書を検索する第1の検索ステップと、
前記第2の検索要求文に基づき前記記憶手段から、前記第2の検索条件を満たす新たな要素を検索する第2の検索ステップと、
前記第1の検索ステップで検索された構造化文書中の前記予め定められた位置に、前記第2の検索ステップで検索された新たな要素のうち当該構造化文書に対応付けられている新たな要素を追加することにより、拡張文書を生成するステップと、
前記拡張文書を表示手段で表示するステップと、
を有する構造化文書編集方法。 - 前記入力ステップは、前記新たな要素の要素名と、当該新たな要素のとり得る値とを記憶するユーザタグ記憶手段で記憶されている要素名及び値のうち、選択された要素名及び値を、前記第2の検索条件として入力することを特徴とする請求項1記載の構造化文書編集方法。
- 複数の要素を含む文書構造を有する複数の構造化文書を記憶するとともに、ルートノードに複数のノードをリンクし、当該複数のノードのうちの1つに、各構造化文書の各要素の記憶エリアを前記文書構造に従ってリンクした論理構造により前記複数の構造化文書を管理する構造化文書データベースと、
要素名及び当該要素名の要素の値に含まれる語が指定された検索条件を含む検索要求文に基づき、前記論理構造から前記検索条件を満たす要素を含む構造化文書を検索する第1の検索手段と、
を備えた構造化文書管理装置と、
前記第1の検索手段で検索された構造化文書中の予め定められた位置に追加された新たな要素を、当該構造化文書に対応付けて記憶する第1の記憶手段と、
前記複数の構造化文書中の要素の要素名及び当該要素の値に含まれる語が指定された第1の検索条件と、前記新たな要素の要素名及び当該新たな要素の値が指定された第2の検索条件とを入力する入力手段と、
前記第1の検索条件を含む前記構造化文書データベースに対する第1の検索要求文と、前記第2の検索条件を含む前記第1の記憶手段に対する第2の検索要求文とを生成する生成手段と、
前記第1の検索要求文を前記構造化文書管理装置へ送信する手段と、
前記第2の検索要求文に基づき前記第1の記憶手段から、前記第2の検索条件を満たす新たな要素を検索する第2の検索手段と、
前記構造化文書管理装置から、前記第1の検索手段で前記第1の検索要求文に基づき検索した結果得られた構造化文書を受信する手段と、
前記第1の検索要求文に基づき検索した結果得られた構造化文書中の前記予め定められた位置に、前記第2の検索手段で検索された新たな要素のうち当該構造化文書に対応付けられている新たな要素を追加することにより拡張文書を生成する手段と、
前記拡張文書を表示手段で表示する手段と、
を備えた構造化文書編集装置と、
を含むことを特徴とする構造化文書編集システム。 - 前記構造化文書編集装置は、
前記新たな要素の要素名と、当該新たな要素のとり得る値とを入力する手段と、
入力された新たな要素の要素名と、当該新たな要素のとり得る値とを記憶する第2の記憶手段と、
をさらに備え、
前記入力手段は、前記第2の記憶手段で記憶されている要素名及び値のうち選択された要素名及び値を、前記第2の検索条件として入力することを特徴とする請求項3記載の構造化文書編集システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001098189A JP3842576B2 (ja) | 2001-03-30 | 2001-03-30 | 構造化文書編集方法及び構造化文書編集システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001098189A JP3842576B2 (ja) | 2001-03-30 | 2001-03-30 | 構造化文書編集方法及び構造化文書編集システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002297662A JP2002297662A (ja) | 2002-10-11 |
JP3842576B2 true JP3842576B2 (ja) | 2006-11-08 |
Family
ID=18951864
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001098189A Expired - Fee Related JP3842576B2 (ja) | 2001-03-30 | 2001-03-30 | 構造化文書編集方法及び構造化文書編集システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3842576B2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11379881B1 (en) * | 2017-03-03 | 2022-07-05 | Servemotion, Inc. | Systems and methods for providing video header bidding to a publisher |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1467289A1 (en) * | 2003-04-07 | 2004-10-13 | Deutsche Thomson-Brandt Gmbh | database model for hierarchical data formats |
JP2008090404A (ja) * | 2006-09-29 | 2008-04-17 | Just Syst Corp | 文書検索装置、文書検索方法および文書検索プログラム |
JP4404930B2 (ja) * | 2006-12-28 | 2010-01-27 | キヤノンマーケティングジャパン株式会社 | 情報処理装置、その制御方法、情報処理システム、プログラム及びコンピュータ読み取り可能な記録媒体 |
JP2008282114A (ja) * | 2007-05-09 | 2008-11-20 | Profield Co Ltd | 情報処理装置、サーバ装置、情報処理システム、情報処理方法、およびプログラム |
JP7044967B2 (ja) * | 2017-07-21 | 2022-03-31 | 富士通株式会社 | 格納制御プログラム、格納制御装置及び格納制御方法 |
-
2001
- 2001-03-30 JP JP2001098189A patent/JP3842576B2/ja not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11379881B1 (en) * | 2017-03-03 | 2022-07-05 | Servemotion, Inc. | Systems and methods for providing video header bidding to a publisher |
Also Published As
Publication number | Publication date |
---|---|
JP2002297662A (ja) | 2002-10-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3842573B2 (ja) | 構造化文書検索方法、構造化文書管理装置及びプログラム | |
JP3842577B2 (ja) | 構造化文書検索方法および構造化文書検索装置およびプログラム | |
US5835712A (en) | Client-server system using embedded hypertext tags for application and database development | |
US7363581B2 (en) | Presentation generator | |
US7624114B2 (en) | Automatically generating web forms from database schema | |
JP3754253B2 (ja) | 構造化文書検索方法、構造化文書検索装置及び構造化文書検索システム | |
Frischmuth et al. | Ontowiki–an authoring, publication and visualization interface for the data web | |
US20080183689A1 (en) | Search method and apparatus for plural databases | |
JPH07319917A (ja) | 文書データべース管理装置および文書データべースシステム | |
JP3914081B2 (ja) | アクセス権限設定方法および構造化文書管理システム | |
JP3842576B2 (ja) | 構造化文書編集方法及び構造化文書編集システム | |
Liu et al. | An XML-enabled data extraction toolkit for web sources | |
JP3842572B2 (ja) | 構造化文書管理方法および構造化文書管理装置およびプログラム | |
JP5056384B2 (ja) | 検索プログラム、方法及び装置 | |
Yu et al. | Metadata management system: design and implementation | |
JPH10187680A (ja) | 単語、文、部分の粒度で管理するドキュメントリポジトリ装置 | |
CN1326078C (zh) | 包装器的生成方法 | |
JP3842574B2 (ja) | 情報抽出方法および構造化文書管理装置およびプログラム | |
JP2003316783A (ja) | 異種半構造化情報源統合検索装置、方法、プログラム及び該プログラムを記録した記録媒体 | |
US7487439B1 (en) | Method and apparatus for converting between data sets and XML documents | |
JP3842575B2 (ja) | 構造化文書検索方法、構造化文書管理装置及びプログラム | |
JP2003288365A (ja) | 付加情報管理方法及び付加情報管理システム | |
JP2004118543A (ja) | 構造化文書検索方法、検索支援方法、検索支援装置および検索支援プログラム | |
JP3910901B2 (ja) | 文書構造検索方法、文書構造検索装置および文書構造検索プログラム | |
JP2003288332A (ja) | 構造化文書作成支援方法及び構造化文書作成支援システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051111 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051115 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060116 |
|
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: 20060808 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060810 |
|
LAPS | Cancellation because of no payment of annual fees |