JP2004502993A - 訓練可能で拡張可能な自動化データ/知識翻訳機 - Google Patents
訓練可能で拡張可能な自動化データ/知識翻訳機 Download PDFInfo
- Publication number
- JP2004502993A JP2004502993A JP2001567526A JP2001567526A JP2004502993A JP 2004502993 A JP2004502993 A JP 2004502993A JP 2001567526 A JP2001567526 A JP 2001567526A JP 2001567526 A JP2001567526 A JP 2001567526A JP 2004502993 A JP2004502993 A JP 2004502993A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- data
- user
- rules
- knowledge
- 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.)
- Withdrawn
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/02—Knowledge representation; Symbolic representation
- G06N5/022—Knowledge engineering; Knowledge acquisition
- G06N5/025—Extracting rules from data
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Evolutionary Computation (AREA)
- Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Computational Linguistics (AREA)
- Mathematical Physics (AREA)
- Data Mining & Analysis (AREA)
- Artificial Intelligence (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Stereophonic System (AREA)
- Magnetic Resonance Imaging Apparatus (AREA)
- Measurement And Recording Of Electrical Phenomena And Electrical Characteristics Of The Living Body (AREA)
- Machine Translation (AREA)
Abstract
訓練可能で拡張可能な自動化データ/知識翻訳機が記載されている。本発明の一局面は、コンピュータ化システムによりデータの処理を統治する、ユーザによって指定された規則を格納する少なくとも1つのリポジトリと、その規則に従ってデータを処理し且つそのデータから知識を生成する少なくとも1つの処理モジュールとを有するコンピュータ化システムを含む。本発明の別の局面は、データを知識に翻訳する、コンピュータ化された方法である。コンピュータ化された方法は、データを知識に翻訳するコンピュータ化システムの挙動を統治するためユーザによって指定された規則を設けるステップと、データを前記規則に従って処理して知識を生成するステップとを含む。本発明の更なる局面は、コンピュータ可読媒体に格納され、データを知識に翻訳する方法を実行するコンピュータ実行可能命令を有する上記コンピュータ可読媒体である。そのコンピュータ化された方法は、データを、非構造化された形式で受け取るステップと、データを中立形式に変換するステップと、ユーザによって指定された規則に従ってデータを処理してデータを中立形式から知識に翻訳するステップと、知識を知識リポジトリにエクスポートするステップとを備える。
【選択図】図1
【選択図】図1
Description
【0001】
発明の分野
本発明は、コンピュータ・システムに関し、特にデータを知識に翻訳するコンピュータ・システムに関する。
【0002】
発明の背景
決定支援システムのような多くの製品は、知的決定をするため知識を必要とする。決定支援システムは、知識、解析ツール及びモデルを組み合わせて、決定者を支援するコンピュータ・ベースのシステムである。決定支援システムは通常、知識データベース又は知識リポジトリを含む。知識は、決定を支援するため、知識データベース又は知識リポジトリから抽出され、解析ツール及びモデルを用いて解析される。決定支援システムに対して有効であるため、データは、知識データベースに格納される前に、解析され、翻訳され、そして構造化され意味のある知識に編成されねばならない。
【0003】
多くの場合、データは、人間が読める文書の形式であり、決定支援システムに対するその形式は、非構造化された意味のないデータとして見える。データは、情報、生の事実及び類似のものを意味する。データは、紙の書類、又はディジタルの書類におけるような様々な形式で存在し得る。データそれ自体は、決定支援システムに対して意味を持たない。決定支援システムがデータを処理するため、データは、最初に、決定支援システムが処理できる形式に翻訳されねばならない。
【0004】
本明細書で用いられているように、知識は、決定支援システムにより処理されることができる情報を意味する。知識の集合は知識ベース又は知識リポジトリと呼ばれる。標準一般化マーク付け言語(SGML)又は拡張可能なマーク付け言語(XML)のような構造化データ・フォーマットでさえもが、必要とされる知識の全てが必ずしもマークアップ(マーク付け)によりタグを付けられ得るのではないので、決定支援システムに対して不適切である場合がある。データから知識への人間の翻訳は、特に、周期的に更新されるデータ・ソースにとって、労力を要し、費用がかかり、そして誤りを起こしがちである。特別目的の知識ベース構成プログラムが、多くの場合余りに柔軟性に欠けているので直接適用できなく、また余りにコストがかかるので新しい種類のデータ及び/又は知識リポジトリに対して修正できない。
【0005】
必要とされることは、人間が使える情報のような非構造化された意味のないデータを構造化された意味のある知識、即ちマシンが使える知識に変換する仕方である。
【0006】
発明の概要
訓練可能で拡張可能な自動化データ/知識翻訳機が記載されている。本発明の一局面は、コンピュータ化システムによりデータの処理を統治する、ユーザによって指定された規則を格納する少なくとも1つのリポジトリと、その規則に従ってデータを処理し且つそのデータから知識を生成する少なくとも1つの処理モジュールとを有するコンピュータ化システムを含む。本発明の別の局面は、データを知識に翻訳する、コンピュータ化された方法である。そのコンピュータ化された方法は、データを知識に翻訳するコンピュータ化システムの挙動を統治するためユーザによって指定された規則を設けるステップと、データを前記規則に従って処理して知識を生成するステップとを含む。本発明の更なる局面は、コンピュータ可読媒体に格納され、データを知識に翻訳する方法を実行するコンピュータ実行可能命令を有する上記コンピュータ可読媒体である。前記コンピュータ化された方法は、データを、非構造化された形式で受け取るステップと、前記データを中立形式に変換するステップと、ユーザによって指定された規則に従ってデータを処理して前記データを中立形式から知識に翻訳するステップと、前記知識を知識リポジトリにエクスポートするステップとを備える。
【0007】
実施形態の説明
好適な実施形態の以下の詳細な説明において、この出願の一部を形成し、且つ本発明を実施し得る例示な特定の実施形態が例示により示されている添付図面が参照される。本発明の範囲を逸脱することなく、他の実施形態を用い得て、そして構造的変更を行い得ることが理解されるべきである。
システム・レベルの概要
図1Aは、本発明の一実施形態に従ったデータ/知識翻訳システム100の高レベルブロック図である。データ入力フォーマット及び知識出力要件における広い変化のため、本発明のデータ/知識(D2K)システムの一実施形態の論理的アーキテクチャは、図1Aに示されるようにデータ・ソース入力と知識リポジトリ出力とを分離する3層構造のシステムである。層1のソフトウエア構成要素102は、ソース・データ101を中立フォーマットにインポートする。一旦データが中立フォーマットになると、層2のソフトウエア構成要素104は、データを解析し、編成(organize)し、処理する。最後に、層3のソフトウエア構成要素106は、処理されたデータ(知識)を知識リポジトリ108にエクスポートし、そこにおいて、希望する場合には、更なる処理が行われてもよい。この3層構造のアーキテクチャは、ツールを特定のデータ・フォーマット又は全体に異なるドメインに適用するに必要とされる開発量を低減することによりD2Kシステムの拡張性を最大にする。各層は十分に定義されたインタフェースにより分離され、それにより1つの層に対する内部変化は隣接の層に対する変化を必要としない。この3層構造に加えて、D2Kシステムはシステム・エグゼクティブ110を含み、そのシステム・エグゼクティブ110は、3層の各層内及び各層間でアクティビティを調整すること、並びにユーザとの対話及びエラーの報告のようなグローバル機能を与える。
【0008】
しかしながら、D2Kシステムは3層構造のシステムに限定されるものではない。一代替実施形態においては、1つ又はそれより多い追加の層が、図1に示されるD2K翻訳システム100の論理的アーキテクチャに追加され得る。更に別の実施形態においては、論理的アーキテクチャは、2つの層又は単一の層としてさえ動作するようスケール変更することができる。
【0009】
図1Bは、D2K翻訳システム100の代替実施形態の高レベルブロック図である。図1Bに示されるように、D2K翻訳システム100は、コンピュータ化されたシステム100によりデータの処理を統治する、ユーザによって指定された規則を格納するための少なくとも1つのリポジトリ114を備える。D2K翻訳システム100はまた、その規則に従ってデータを処理し且つデータから知識を生成するための少なくとも1つの処理モジュール112を備える。
【0010】
図1Cは、D2K翻訳システム100の追加の実施形態の高レベルブロック図である。図1Cに示されるように、D2K翻訳システム100は、少なくとも1つのリポジトリ114及び少なくとも1つの処理モジュール112を備える。D2K翻訳システム100は更に、少なくとも1つのリポジトリ及び少なくとも1つの処理モジュールを制御するためのシステム・エグゼクティブ110を備える。
【0011】
図1Dは、D2K翻訳システム100の別の実施形態の高レベルブロック図である。図1Dに示されるように、D2K翻訳システム100は、少なくとも1つのリポジトリ114、少なくとも1つの処理モジュール112及びシステム・エグゼクティブ110を備える。D2K翻訳システム100はまた、ユーザがユーザによって指定された規則を作成し、修正し、削除するのを可能にするユーザ・インタフェースを備える。
【0012】
多くのデータ・フォーマットがソース・データ101に対して存在する。非構造化データは、文書、画像、データベース、図表、略図及び類似のものの形式であり得るが、これらに限定されるものではない。一般にデータを単一のフォーマットに変換することが常に可能(好都合)というわけではないので、D2Kシステムは、様々なソース・データ・フォーマットをサポートする。層1のソフトウエア構成要素102は、データをその生来のフォーマットで処理し、そして関連の情報を中立フォーマットに変換する。換言すると、インポート層(層1)102は、ソース・データ・フォーマットの詳細及び複雑さを処理層(層2)104の処理構成要素から分離する。層2のルーチン104は、インポートされたデータを解析し、編成し、処理する。処理ルーチン104は、非構造化された意味のないデータを構造化された意味のある知識に変換する。処理構成要素は、正規表現検索エンジン、自然言語処理アルゴリズム及びグラフィックス識別アルゴリズムのような様々な技術を用いる。層3のソフトウエア構成要素106は、知識を知識リポジトリ108にエクスポートする。丁度データが多くのソース・フォーマットで存在し得るように、知識も幾つかのリポジトリ・フォーマットで表され得る。従って、エクスポート層106(層3)は、知識リポジトリ・フォーマットの詳細及び複雑さを処理ルーチンから分離する。要約すると、インポート層102及びエクスポート層104の構成要素は、処理層106の構成要素がデータ・ソース又は知識リポジトリのフォーマットを考慮する必要なしにそれらのタスクを実行するのを可能にする。
例示実施形態の物理的アーキテクチャ
図2は、図1に示されるD2Kシステムを実現するための物理的アーキテクチャの例示実施形態のブロック図である。図2に示される長方形202、206、212、210、216は、変換構成要素を表す。変換構成要素は、ある種類の入力を受け取り、それを変換して、ある種類の出力を生成する。図2に示される封筒は、本明細書では「パケット」と呼ばれるデータ構造体を表す。パケットは、変換構成要素が互いに通信をするため用いるインタフェース・メカニズムである。図2に示される円柱は、D2Kシステムの構成、変換構成要素の挙動を統治する規則、訓練データ、エラー・メッセージ及び類似のもののような様々な情報を格納するリポジトリを表す。最後に、図2に示される人々は、グラフィック・ユーザ・インタフェース(GUI)を表す。ユーザは、GUIを介して対話して、D2Kシステムの挙動をカスタマイズする。
【0013】
図2に示される例示の物理的アーキテクチャは、図1に示される論理的アーキテクチャに対して次のようにマップする。インポート・フィルタ202は、インポート・フィルタ規則リポジトリ204と共に、図1に示されるインポート層(層1)を構成する。テキスト抽出モジュール206は、テキスト抽出規則リポジトリ208及びカスタム処理モジュール210と共に、図1に示される処理層(層2)を構成する。パケット・エクスポート・モジュール212は、パケット・エクスポート規則リポジトリ214と共に、図1に示されるエクスポート層(層3)を構成する。パケット・ディスパッチャ216は、パケット・ディスパッチ規則リポジトリ218、GUI及び構成モジュール(図示せず)と共に、図1に示されるシステム・エグゼクティブを構成する。パケットは、図1に示される3つの層間及びそれら3つの層内での通信を容易にするインタフェース・オブジェクトである。
【0014】
図2に示されるD2Kシステム200の例示実施形態のデータの流れは次のとおりである。インポート・フィルタ202は、データ・ソース201を読み取り、それをインポート・フィルタ規則204に従ってパケットに離散化する。インポート・フィルタ202は次いで、これらのパケットをパケット・ディスパッチャ216に通し、そのパケット・ディスパッチャ216は、パケットをパケット・ディスパッチ規則218に従って適切な処理モジュールにディスパッチする。処理モジュールはパケットを処理する。パケット・エクスポート・モジュール212のような幾つかの処理モジュールは、追加のパケットを生成しない端末処理モジュールである。テキスト抽出モジュール206のような他の処理モジュールは、より精細な解像度の幾つかのパケットを生成する。これらの非端末処理モジュールは、それらが生成するパケットをパケット・ディスパッチャ216に通し、そのパケット・ディスパッチャ216は、次いで、パケットを適切な処理モジュールへディスパッチし、そしてサイクルが継続する。一実施形態においては、少なくとも1つの処理モジュールは、パケットを知識リポジトリにエクスポートする。このプロセスは、図4に図示されている。図4に示されるプロセスは、データ・ソースの全体が解析(構文解析)されるまで継続する。
例示実施形態のシステム構成要素
このセクションは、図2に示される例示実施形態の次のシステム構成要素、即ち、パケット、パケット辞書、パケット・ファクトリ(工場)、インポート・フィルタ、パケット・ディスパッチャ、パケット処理モジュール、テキスト抽出モジュール、パケット・エクスポート・モジュール、コンピュータ・グラフィック・メタファイル(CGM)処理モジュール及びメッセージ・ログをより詳細に説明する。
【0015】
パケット. 図2に示されるパケットは、情報の包括的集合である。図5は、図2に示されるパケット・データ構造のより詳細な図である。パケット500は、図5に示されるように、タイプ、コンテンツ及びコンテキストのためのフィールドを含むデータ構造である。パケットのタイプ502は、エンティテイ又はオブジェクトの名前である。タイプは、典型的にはパケットのコンテンツを記述するタイプである。パケットのコンテンツ504はゼロ又はそれより多いラベルから成り、各ラベルはゼロ又は1に関連した値を有する。コンテンツ・ラベルは、エンティテイ又はオブジェクトの関連属性である。コンテント値は、典型的には、パケット処理モジュールにより処理され、及び/又は知識リポジトリへエクスポートされる。他方、パケット・コンテキスト506は、ゼロ又はそれより多いラベルから成り、各ラベルは、ゼロ又は1つの関連値を有する。コンテキスト値は、コンテンツの意味を増補する(augment)か、又はコンテンツが生成される仕方を記載するかのいずれかである情報を含む。コンテント値のように、コンテキスト値も知識リポジトリへエクスポートされることができる。
【0016】
処理モジュールが子のパケットを生成するとき、処理モジュールは通常、親のコンテキストをコピーし、そしてそれを子に割り当てる。換言すると、子は、親のコンテキストを受け継ぐ。その結果として、固有の識別子を有するパケットを識別することが望ましい場合、人はその識別子をコンテキストとして格納する。子パケットが彼らの親の固有の識別子を受け継ぐので、親パケットと子パケットの関係が生成される。
【0017】
一例として、人がレシピ(調理法)をパケットとして表す仕方を考えて見る。パケットのタイプがパケット・コンテンツを記述するタイプであり、そしてパケットがレシピを表すので、単語「レシピ」は、パケットのタイプを求めることに対して明白な選定である。全てのレシピの関連属性は、名前、材料のリスト、及び調理/クッキング指示である。その結果として、我々のレシピ・パケットは、名前、材料及び命令のコンテンツを含むであろう。名前のコンテンツは、単一の値、即ちレシピの名前を含むであろう。他方、材料及び指示のコンテンツは、複数の値を含むであろう。換言すると、各材料及び指示ステップは、材料及び指示のコンテンツの別々の値としてそれぞれに格納されるであろう。最後に、1人前の数、1人前当たりのカロリーの数字及び栄養学的情報のような情報が、コンテキストとして格納されることができるであろう。
【0018】
一実施形態において、パケットは、図2に示されるインポート・フィルタ202のようなインポート・フィルタにより生成される。インポート・フィルタは、パケットを、図2に示されるパケット・ディスパッチャ216のようなパケット・ディスパッチャへ通す。パケット・ディスパッチャは、パケットをパケット処理モジュールにルート付けし、そのパケット処理モジュールは次いで、追加のパケットの情報がよりアトミック的(原子的)であるその追加のパケットを生成し得る。パケット・ディスパッチャはまた、パケットを、図2のパケット・リポジトリ220のようなパケット・リポジトリに格納し得る。最後に、全てのアトミック・パケットは、図2のパケット・エクスポート・モジュール212のような端末パケット処理モジュールにルート付けされ、その端末パケット処理モジュールは、パケットを知識リポジトリに、又はパケットを捨てるヌル・プロセッサにエクスポートする。
【0019】
パケット辞書 一実施形態において、図2に示されるパケット辞書222のようなパケット辞書は、合法のパケットのマスタ・リストを保持する。幾つかのD2Kシステム機能は、パケット辞書を用いて、データ破損を緩和する。例えば、一部の実施形態においては、訓練ユーザ・インタフェースは、パケット辞書を用いて、リスト・ボックス選択を制限して、ユーザに、有効でない訓練規則を作成するのを禁止し、一方、他の実施形態においては、パケット・ファクトリは、パケット辞書を用いて、合法のパケットのみが生成されるのを保証する。
【0020】
パケット辞書は、D2Kシステムのインポート・フィルタ及びパケット処理モジュールの登録中に占有される。一実施形態において、パケットを生成するいずれのD2Kシステム構成要素は、それが生成することができる各タイプのパケットのプロトタイプを登録する。概念的には、パケットのプロトタイプは、いずれの値も持たないパケットである。換言すると、パケット・プロトタイプは、どのコンテンツ及びコンテキストのラベルが所与のパケットのタイプにとって合法的であるかを指定する。
【0021】
パケット・ファクトリ パケット・ファクトリの目的は、パケットをパケット・リポジトリから読み出しそしてパケットをパケット・リポジトリに書き込むような1組のパケット関連のサービスを与えることである。更に、パケット・ファクトリは、パケット(それらはパケット・リポジトリに中で長く持続されていた)をインスタンス生成し、そしてそれらパケットをコンテンツ・ディスパッチャに通し、それによりそれらパケットがパケット処理モジュールにルート付けされることができるようにするサービスを提供する。最後に、パケット・ファクトリは、パケットを作るための幾つかのサービス、並びにパケットのコンテキストのクローンを作って、その親のコンテキストを受け継ぐ新しい子のパケットを生成するメカニズムを提供する。
【0022】
インポート・フィルタ 一実施形態においては、インポート・フィルタは、インポート・フィルタ規則リポジトリと共に、図1の層1を構成する。図2に示されるインポート・フィルタ202のようなインポート・フィルタの目的は、データ・フォーマットの複雑さを取り扱い、そしてこれらの詳細を処理モジュールから隠すことである。インポート・フィルタは、関連のソース・データをパケットに離散化する。なお、それらのパケットはD2Kシステムの中立データ・フォーマットである。データ・ソースに応じて、このプロセスを起こすメカニズムは異なる。例えば、SGML又はXMLのような階層的に構造化されたデータにとって、パケット構造規則は、階層の各ノードに対して関連付けられ得る。別の実施形態においては、マイクロソフトのワード(登録商標)文書に格納されたデータにとって、Visual Basic for Applications(登録商標)スクリプト(BVAスクリプト)が、パケットを生成するため書き込まれてもよい。
【0023】
データの構造のアウトラインが、捕捉され、データベースに格納される。SGML文書の場合、そのアウトラインは、それが要素及び属性の階層を含む点で文書タグ定義(DTD)に似ている。しかしながら、一実施形態においては、アウトラインは、実際の文書に示されるDTDの一部を含むだけである。
【0024】
一旦データ構造のアウトラインが形成されると、パケット構成規則が、本発明の一実施形態に従って階層の中の各ノードに適用される。パケット構成規則は、ユーザがノードに対応するデータを用いて次のことを行うのを可能にする。
【0025】
1.データを無視する。
2.データを無視し、新しいパケットを生成する。
3.新しいパケットを生成し、データをパケットにコンテンツとして挿入する。
【0026】
4.データを現在のパケットにコンテンツとして挿入する。
5.データを現在のパケットにコンテンツとして添付する。
6.データを現在のパケットにコンテキストとして挿入する。
一実施形態において、規則に応じて、ユーザはまた、パケット・タイプ、コンテンツ・ラベル及び/又はコンテキスト・ラベルを指定し得る。更に、6個の規則は、階層の中の全てのノードに適用可能でないかも知れない。例えば、パケットを生成する祖先を持たないノードにおいてデータを現在のパケットにコンテンツとして挿入することは無効である。(一実施形態においては、インポート・フィルタ訓練ユーザ・インタフェースは、ユーザがいずれの規制に違反することを可能にしないので、ユーザが、全ての規制の経験的知識に基づくことは必要でないことに注目されたい。)
前述したように、一旦データ・ソースのアウトラインがデータベースに格納されると、パケット構成規則は、階層の中の各ノードに対して関連付けられる。規則のタイプは、インポート・フィルタ規則リポジトリの中に存在する情報に依存する。所与のノードが既に規則リポジトリの中に存在する場合、それは、同じ規則を既存のノードとして割り当てられる。ノードが既にデータベースの中に存在しない場合、それは、「データを無視する」規則を割り当てられる。本質的に、ユーザは、過去の訓練、即ちノードへの規則の適用を失うことなしに、幾つかのデータ・ソースの構造を併合することができる。更に、ユーザは、規則リポジトリ内に存在するが、しかし最近アウトラインを形成されたデータ・ソースの中に存在しないいずれのノードを削除する能力を与えられる。これら2つのメカニズムは、訓練要件を最小にしながら、ユーザが幾つかのデータ・ソースのためのパケット構成規則を1つ又はそれより多い規則リポジトリに格納することを可能にする。
【0027】
一実施形態においては、インポート・フィルタが訓練された後で、インポート・フィルタが登録される。インポート・フィルタを登録することは、インポート・フィルタがデータ・ソースを解析しながら作成することができるパケットのプロトタイプを用いてパケット辞書をポピュレートする。一実施形態においては、ユーザがインポート規則をインポート・フィルタ・ユーザ・インタフェースを介して訓練した後で、GUIは自動的にインポート・フィルタを登録する。一旦インポート・フィルタが登録されると、インポート・フィルタは、パケット構成規則を適用してパケットを構成することによりデータ・ソースを解析し得る。
【0028】
一例として、図6に示されるサンプルSGMLテキストを考えて見る。図6は、本発明のインポート・フィルタに適用される例示ソース・データを示す。図7は、図6に示される例示ソース・データに適用される例示インポート・フィルタ規則を示す。図7に示されるように、要素はボックスの中の文字「E」により識別され、一方、属性はボックスの中の文字「A」により識別される。要素及び属性の名前がボックスの中の文字に直ぐに続き、そしてインポート・フィルタ規則が省略符号に続く。「データを無視する」規則は、明示的規則無しでアイテムに対して暗黙に定義される。
【0029】
SGMLインポート・フィルタは、適切なインポート・フィルタ規則(これはまた「パケット構成規則」とも呼ばれる。)を適用して、サンプル・テキストを要素毎に解析する。図6に示されるサンプルSGMLテキストにおいて、インポート・フィルタは、最初に、マスタ障害テーブル(MSTFLTAB)要素を解析する。この要素に対応する図7における規則は、要素のデータを無視することになるので、インポート・フィルタは、障害行(FLTROW)要素を解析することを進める。この要素に対応する図7における規則は、インポート・フィルタに対して、タイプが「障害コード(Fault Code)」のパケットを生成するよう命令する。次に、インポート・フィルタは、FLTROW要素の属性を解析する。章番号(CHAPNBR)、セクション番号(SECTNBR)及び固有キー(KEY)の属性に対応する図7における規則は、インポート・フィルタに対して、3つのコンテキスト・ラベル−値の対を障害コード・パケットに加えるよう指示する。CHAPNBR、SECTNBR及びKEYの属性の値、即ち、「29」、「24」及び「EN29240001−00001001」は、図8のパケットに示されるように、章番号、セクション番号及び固有キーそれぞれの値になる。図8は、インポート・フィルタが図6のSGMLテキストの障害記述(FLTDESC)要素を解析する前の障害コード・パケットのスナップショットである。次の3つの要素に対応する規則が、パーサに対して、要素のデータを無視するよう命令するので、インポート・フィルタは、障害記述(FLTDESC)要素を解析することを進める。
【0030】
FLTDESC要素に対応する図7における規則は、インポート・フィルタに対して、タイプが「障害徴候(Fault Symptom)」の第2のパケットを生成するよう命令する。次に、インポート・フィルタは、カテゴリ(CATEG)属性の値を図9に示される障害徴候パケットに障害徴候タイプ・コンテンツとして挿入する。次いで、障害タイプ(FLTYPE)属性の値は、障害徴候タイプ・コンテンツの現在の値に添付される。FLTYPE属性に対応する規則が、インポート・フィルタに対して、属性のデータを障害徴候タイプ・コンテンツに添付するよりむしろ挿入することを命令した場合、インポート・フィルタは、このデータを第2の値として挿入したであろう。FLTDESC要素及びその属性を解析した後で、インポート・フィルタは、障害メッセージ(FLTMSG)及びATA ECAM(ATAECAM)要素を解析する。インポート・フィルタは、図9に示されるように、これらの要素の値を障害徴候パケットに障害徴候テキスト及びECAM ATAとして挿入する。次に、インポート・フィルタは、FLTDESC終了タグに遭遇する。その結果として、それは、障害徴候の親パケット即ち障害コード・パケットのコンテキストのクローンを作り、そして障害徴候パケットをパケット・ディスパッチャに通す。図9は、インポート・フィルタが図6のサンプルSGMLテキストの中の障害徴候(FLTDESC)終了タグに遭遇した後の障害徴候パケットのスナップショットである。
【0031】
パケット・ディスパッチャから戻ると直ぐに、インポート・フィルタは、図6のSGMLテキストのタスク参照(TASKREF)要素を解析する。インポート・フィルタは、図10に示されるように、この要素の値を障害コード・パケットにFIP K12参照コンテンツとして挿入する。インポート・フィルタは、次の要素を無視し、次いで、FLTROW終了タグに遭遇する。このタグに遭遇すると直ぐに、インポート・フィルタは、障害コード・パケットをコンテンツ・ディスパッチャに通す。パケット・ディスパッチャから戻ると直ぐに、インポート・フィルタは、MSFLTAG終了タグに遭遇し、そして終了する。図10は、インポート・フィルタが図6のサンプルSGMLテキストの中の障害行(FLTROW)終了タグに遭遇した後の障害コード・パケットのスナップショットである。要約すると、図7のパケット構成規則を、図6のサンプルSGMLに適用することは、図10に示されるような障害コード・パケット、及び図9に示されるような障害徴候パケットを生成する。
【0032】
パケット・ディスパッチャ 図2のパケット・ディスパッチャ216のようなパケット・ディスパッチャは、D2Kシステムの前半分(即ち、インポート層)と後ろ半分(即ち、処理層及びエクスポート層)との間のヒンジ(蝶番)点であり、パケット「traffic cop」として機能する。一実施形態においては、パケット・ディスパッチャは、3つのモードで動作する。その正常モードの動作においては、パケット・ディスパッチャは、パケットをパケット・マッチ仕様規則に従ってパケット処理モジュールにルート付けする。なお、そのパケット・マッチ仕様規則は、図2のパケット・ディスパッチ規則データベース218のようなパケット・ディスパッチ規則データベースに格納されている。第2のモードにおいては、ユーザは、パケットをディスパッチすることを使用不能にすることができ、そしてパケット・ディスパッチャを構成して、パケットを、図2のパケット・リポジトリ220のようなパケット・リポジトリに単にセーブすることができる。第3のモードにおいては、ユーザは、パケット・ディスパッチャを構成して、パケットをパケット処理モジュールにディスパッチし、且つパケットをパケット・リポジトリに格納することの両方を行うことができる。この最後のモードは、デバッギング支援として有効であり、そしてユーザにパケット監査トレイルを与える。
【0033】
一実施形態においては、パケット・ディスパッチャは、インポート・フィルタ、パケット・ディスパッチャ、パケット処理モジュール三者間の順序付けの2つのモード、即ち、シングルスレッドされるのとマルチスレッドされるのとをサポートする。シングルスレッド・モードにおいては、インポート・フィルタは、パケットを生成し、そしてそのパケットをパケット・ディスパッチャに通し、そのパケット・ディスパッチャは、それを適切なパケット処理モジュールに通す。パケット処理モジュールは、そのパケットを処理し、そして次いで追加のパケットを作成してもよい。なお、その追加のパケットは子パケットを呼ばれる。次に、パケット処理モジュールは、順次的に各子パケットをパケット・ディスパッチャに通し、そのパケット・ディスパッチャは、その子パケットを適切なパケット処理モジュールに通す。このサイクルは、元の情報の中の全ての関連情報が処理され且つエクスポートされてしまうまで継続する。この時点で、インポート・フィルタは、別のパケットを生成するため、入力データを解析するのを随意に再開する。要約すると、シングルスレッド・モードの動作において一旦インポート・フィルタがパケットを生成すると、インポート・フィルタは、そのインポート・フィルタが入力データを解析するそのタスクを再開する前にこのパケット並びに全てのその子孫パケットが処理されるまで待つ。マルチスレッドされたモードにおいては、インポート・フィルタは、ディスパッチャがその処理を再開する前にパケットを処理するのを待つ必要がない。生のパケットがパケット・ディスパッチャにおいてキューされ、そして第2の実行スレッドによりシリアルに処理される。これにより、インポート・フィルタが連続的に作業することが可能になる。マルチスレッド動作は、D2Kシステムがマルチプロセッサ・コンピュータ・システム上でホストされるとき有利である。
【0034】
前述したように、パケット・ディスパッチャは、パケット・ディスパッチ規則データベースに格納されたパケット・マッチ仕様規則に従ってパケットをパケット処理モジュールにルート付けする。一実施形態においては、パケット・マッチ仕様規則は、パケット・マッチ仕様(本明細書では「マッチ仕様(マッチスペック)」と呼ぶ。)をパケット処理モジュール(「パケット・プロセッサ」と呼ぶ。)に対してマップする。マッチ仕様は、パケットのタイプ、オプションの処理引数、及びゼロ又はそれより多いコンテキスト・ラベル−値の対から成る。マッチ仕様は、次の2つの例外を持つパケットに似ている。
・マッチ仕様はパケット・プロセッサ引数を含む。
・マッチ仕様はコンテンツを含まない。
一実施形態においては、ヌル・プロセッサ・モジュールを除いて、パケット処理モジュールは、それらのグローバル固有識別子(GUID)により指定される。GUIDなしの処理モジュールは、ヌル・プロセッサ・モジュールであると想定される。
【0035】
図11は、パケット・ディスパッチャにより使用の例示パテント・マッチ仕様規則を図示する。図11において、3つのマッチ仕様1102、1104、1106は、2つのパケット・プロセッサ1108、1110に対してマップされている。第1のマッチ仕様1102は、ヌル・モジュール1108がタイプ「障害トピック(Fault Topic)」の全てのパケットを処理することができることを指示する。第2のマッチ仕様1104は、引数「障害(Fault)」を持つテキスト抽出モジュール1110がタイプ「障害トピック」のパケットを処理できることを指示する。なお、その障害トピック・タイプ・コンテキストは、「障害分離(FAULT ISOLATION)」に等しい。第3のマッチ仕様1106は、引数「あり得る原因(Possible Causes)」を持つテキスト抽出モジュール1110がタイプ「あり得る原因」の全てのパケットを処理することができることを指示する。一実施形態においては、次のガイドラインをマッチ仕様に適用する。
・マッチ仕様は、唯1つののみのパケット・プロセッサに対してマップしなければならない。
・幾つかのマッチ仕様は、同じパケット・プロセッサに対してマップしてよい。
・同じパケット・タイプを持つマッチ仕様は、それらが異なるコンテキスト・ラベル−値の対を持つ限り異なるパケット・プロセッサに対してマップしてよい。
【0036】
どのパケット・プロセッサがパケットを処理すべきかを決定するため、パケット・ディスパッチャは、最初にどのマッチ仕様がパケットをマッチするかを決定する。次いで、このリストから、パケット・ディスパッチャは、最良のマッチ仕様を決定する。マッチ仕様がパケットをマッチするため、2つの要件が適合されねばならない。第1に、マッチ仕様は、パケットと同じタイプでなければならない。第2に、マッチ仕様のコンテキストは、それが存在する場合、パケットに存在しなければならない。進行ステートメント(進行命令文)は、マッチ仕様がマッチするため、パケットがマッチ仕様と同じコンテキストの全てを持たねばならないことを含意しない。マッチ仕様に存在しないコンテキストを持つパケットは、そのパケットがマッチ仕様により指定されたコンテキストを持つ限り相変わらずマッチ仕様をマッチする。換言すると、パケットのコンテキストは、マッチするためマッチ仕様のコンテキストのスーパセット(superset)でなければならない。一旦パケット・ディスパッチャがパケットをマッチする全てのマッチ仕様のリストを決定すると、パケット・ディスパッチャは、大部分のコンテンツを有するマッチ仕様を最良のものとして選定する。一度最良のマッチ仕様が決定されると、パケット・ディスパッチャは、パケット及び対応する処理引数を、最良のマッチ仕様に対してマップされているパケット・プロセッサに通す。
【0037】
例えば、図11に示される実例を考えて見る。「障害確認(FAULT CONFIRMATION)」に等しい障害トピック・タイプ・コンテキストを持つタイプ「障害トピック」のパケットは、第1のマッチ仕様1102によりマッチされるのみであろう。続いて、これらのパケットは、ヌル・モジュール1108にディスパッチされるであろう。「障害分離(FAULT ISOLATION)」に等しい障害トピック・タイプ・コンテキストを持つタイプ「障害トピック」のパケットは、第1のマッチ仕様1102及び第2のマッチ仕様1104の両方によりマッチされるであろう。パケット・ディスパッチャは、第2のマッチ仕様1104が第1のマッチ仕様1102より多くのコンテキスト・ラベル−値対を持つので、このパケットをテキスト抽出モジュール1110にディスパッチするであろう。
【0038】
パケット処理モジュール パケット処理モジュール、又はそれはまたパケット・プロセッサとも言われるそのパケット・プロセッサの目的は、パケットを解析し、編成し、処理することである。一実施形態においては、パケット・プロセッサは、2つのグループ、即ち、汎用パケット・プロセッサとカスタム・パケット・プロセッサとに分類され得る。汎用パケット・プロセッサは、データ・ソースに関係なく用いられそうであるパケット・プロセッサである。他方、カスタム・パケット・プロセッサはデータ・ソース特有である。更に、パケット・プロセッサはまた、端末か又は非端末かで分類され得る。端末パケット・プロセッサはパケット・コンシューマである。それらは、パケットを処理するが、しかし子パケットを生成しない。非端末パケット・プロセッサはパケット・プロデューサである。それらは、パケットを処理し、そして子パケットを作成する。
【0039】
本発明の一実施形態においては、3つの汎用パケット・プロセッサ、即ち、テキスト抽出モジュール、パケット・エクスポート・モジュール及びヌル・モジュールがある。テキスト抽出モジュール及びパケット・エクスポート・モジュールは、次のセクションで詳細に説明されるであろう。ヌル・プロセッサは端末パケット・プロセッサである。ヌル・プロセッサはパケットを処理しない。その目的は、単純にパケットを消費することである。一実施形態においては、ヌル・プロセッサはまた、それが実行を持たない点で独特である。パケット・ディスパッチャは、その機能を実効的に実行する。パケットを物理的ヌル・プロセッサにルート付けする代わりに、パケット・ディスパッチャは単純にそれらを破壊する。
【0040】
一実施形態においては、パケット・プロセッサがパケットを解析し編成し処理する前に、それらパケットは登録される。パケット・プロセッサの登録は、2つのことで達成される。第1に、記録、これはパケット・プロセッサに対応するが、この記録は、記録が既に存在しない場合処理モジュール・リポジトリに挿入される。第2に、パケットのプロトタイプ、これをパケット・プロセッサが生成し得るが、このパケットのプロトタイプはパケット辞書に登録される。第1の機能は、パケット・ディスパッチャのような他の構成要素に、パケット・プロセッサ自身であることを気付かせる。第2の機能は、他の構成要素に、パケット・プロセッサが生成し得るパケットを気付かせる。
【0041】
テキスト抽出モジュール 図2のテキスト抽出モジュール206のようなテキスト抽出モジュール(TEM)は、汎用非端末パケット・プロセッサである。テキスト抽出モジュールの目的は、ユーザによって指定されたテキスト・エンティテイを識別し且つフォーマット化することである。指図された維持ドメインに関連した一実施形態においては、テキスト・エンティテイの例は、文書参照(文書基準)、部品番号、観察報告及び障害を含む。全てのパケット・プロセッサの場合のように、TEMは、パケット及びプロセッサ引数を通される。プロセッサ引数は、どのテキスト抽出規則の集合が入力テキストに適用されるべきかを指定する。入力テキストは、ユーザによって指定されたパケット・コンテンツの値を含む。
【0042】
TEMは、パケットを処理するとき次の動作を実行する。最初に、TEMは、テキスト抽出規則により指定されたエンティテイを識別する。2番目に、TEMは、エンティテイをテキスト抽出フォーマット化規則に従ってフォーマット化する。最後に、TEMは、そのTEMが識別してフォーマット化した各エンティテイのため1つ又はそれより多くのパケットを出力する。
【0043】
TEMは、エンティテイを次のように識別する。最初に、TEMは、入力テキストをトークンのリストに変換するためその入力テキストについて字句解析を実行する。トークンは、1つ又はそれより多くの拡張された正規表現により、又は前に指定されたエンティテイにより指定される。しかしながら、トークンの仕様は網羅的である必要はない。ユーザは、直接エンティテイの識別に寄与しないテキストに対して正規の表現を指定する必要がない。従って、トークン化は、2つのステップで実行される。TEMは、ユーザが指定した全てのトークンを見つけ、次いでユーザによって指定されたフィルタをユーザ指定トークン間のテキストに適用することによりデフォルトのトークンを生成する。一旦入力テキストがトークン化されてしまうと、TEMは、エンティテイを識別するため、トークン化された入力テキストについて第2の字句解析を実行する。エンティテイは、1つ又はそれより多くのプロダクション(production)により指定される。プロダクションは、そのアトミック単位が1トークンである拡張された正規表現である。要約すると、エンティテイ識別プロセスは、2解析の字句解析である。第1の解析は、入力テキストをトークンのリストに、キャラクタの拡張された正規表現を介して変換する。第2の解析は、トークン化された入力テキストの中のエンティテイを、トークンの拡張された正規表現を介して識別する。
【0044】
図12のサンプル入力テキスト、及び図13のエンティテイ、トークン及び正規表現を考えて見る。図12は、テキスト抽出モジュールにより処理されることとなるサンプル入力テキストである。図13は、テキスト抽出モジュール規則の集合の階層的表示である。図13におけるボックスの中の文字は、規則階層の中のアイテムを識別する。文字「C」はアイテムが収集であることを示し、「E」はエンティテイを、「T」はトークンを、「R」は正規表現を、「P」はプロダクションを、「F」はフォーマットをそれぞれ示す。例えば、図12のサンプル・テキストの中のEquipmentNumber(装置番号)エンティテイを識別するため、TEMは、最初に、EquipmentNumberエンティテイにおいて定義されたトークンを見つける。この例においては、EquipmentNumberエンティテイは、1つのトークン、即ち、2以上の数字が続く1文字とマッチする単一の正規表現[A−Z][0−9]{2,}を持つEquipNumを定義するのみである。図12のサンプル・テキストにおいて、TEMは、EquipNumトークン、即ちW121、W122及びW123を識別する。次に、TEMは、EquipmentNumberエンティテイ・アイテムについて指定されたキャラクタ・フィルタを用いて、残りのテキストをフィルタリングする。この例では、キャラクタ・フィルタは、スペース「 」、開きの括弧「(」、閉じの括弧「)」及びコンマ「,」を含む。フィルタは、先頭及び遅れている(lagging)キャラクタ(これらはフィルタ内にある。)をテキストの残りのブロックから取り除くことにより適用される。フィルタを適用した後で、そのテキストの残りのブロックがデフォルト・トークンに成る。
【0045】
例えば、図12において、EquipNumトークンW122及びW123、即ちコンマ及びスペース間のテキストを考えて見る。これらのキャラクタの両方がフィルタ内にあるので、それらは取り除かれ、その結果として、これらのEquipNumトークン間にデフォルト・トークンは作られない。他方、図12において、W123のEquipNumトークンと、入力テキストの終わり即ち、「)(DOC21−51−11,−22,−33)」との間のテキストを考えて見る。TEMは最初に、フィルタ内ある先頭のキャラクタを取り除く。第1のキャラクタが閉じの括弧(フィルタ内にあるキャラクタ)であるので、それは取り除かれ、そして次のキャラクタが検査される。それがスペースであるので、それもまた取り除かれる。これは、テキスト抽出モジュールがフィルタ内にないキャラクタに遭遇するまで継続する。最初のそのようなキャラクタは、文字「D」である。次いで、TEMは、フィルタ内にある遅れているキャラクタを取り除く。最後のキャラクタがピリオド、即ちフィルタ内にないキャラクタであるので、そのキャラクタは残ったままで、検索は終了する。最後のキャラクタがフィルタ内にある場合、TEMは、このキャラクタを取り除き、そして最後のキャラクタから1つ前にあるキャラクタを検査するであろう。このプロセスは、TEMがフィルタ内に無かったキャラクタに遭遇するまで継続するであろう。テキスト「DOC21−51−11,−22,−23)」が先頭及び遅れているキャラクタをフィルタリングした後に残ったままであるので、それがデフォルト・トークンとなる。以下の表1は、テキスト抽出モジュールが字句解析を実行して、サンプル・テキストの中のEquipmentNumberエンティテイを識別することから結果として得られたEquipNumトークン及びデフォルト・トークンのリストを提供している。
【0046】
.
この時点で、サンプル入力テキストは、5つのトークン、即ち、デフォルト、FIN、FIN、FIN及びデフォルトにトークン化される。次に、TEMは、第2の字句解析を実行して、EquipmentNumberエンティテイのプロダクションを見つける。この例では、1つのプロダクション、即ちFIN+のみがあり、それは1つ又はそれより多くのEquipNumトークンとマッチする。(FINはEquipNumの省略形である。)その結果として、テキスト抽出モジュールは、1個のエンティテイ、即ち、図14に示されるように3つのEquipNumトークンを見つける。
【0047】
一旦エンティテイが入力テキストの中で識別されると、それは、1つ又はそれより多くのフィールドの中にフォーマット化される。次いで、エンティテイは、パケットとしてパッケージ化され、そしてパケット・ディスパッチャに送られる。TEMはエンティテイを次のようにフォーマット化する。最初に、TEMは、マッチされたプロダクションのトークンをそれらのタイプに従ってビンの中に置く。第2に、TEMは、ビンの中のトークンについて全拡張又はレベル拡張を実行する。第3に、TEMは、マッチング・プロダクションのフォーマットのそれぞれに対してフィールドを生成する。最後に、TEMは、パケットを生成し、そしてそのフィールドをパケットにコンテンツとして挿入する。
【0048】
再び、DocumentReferenceエンティテイのサンプル入力テキスト及び規則を考えて見る。2レベルの字句解析を適用する際、TEMは、図15に示されるように、1つのCahpterSectionトークン(CS)、3つのサブジェクト(Subject)トークン(SUB)及び2つのセパレータトークン(SEP)を識別する。更に、TEMは、図15に示されるように、第2のプロダクション、即ち、VOL? CS SS(SEP SS)*とマッチする1つのエンティテイを識別する。マッチされたプロダクションの6個のトークンは、CS、SUB、SEP、SUB、SEP及びSUBである。TEMはここで、リストされたトークンの値をそれらのタイプに従ってビンの中に置く。一実施形態においては、値をビンの中に置く前に、TEMは最初に、ビンが空き場所を有することを検証する。
【0049】
図16は、ビンの中にソート(分類)された(図13の例示テキスト抽出規則により定義されるように)DocumentReferenceプロダクションに対するトークン値を示す。例えば、第1のトークンの値は「21−51」であり、そしてそのタイプはChapterSection(CS)である。CSトークンの定義がビンの深さを指定しなかったので、そのビンの深さは無限であると想定される。従って、値「21−51」はCSビン1602に挿入される。第2のトークンの値は「−11」であり、そしてそのタイプはサブジェクト(SUB)である。サブジェクトのビン深さもまた無限であるので、値「−11」はSUBビン1604に挿入される。第3のトークンの値は「,」であり、そしてそのタイプはセパレータ(SEP)である。セパレータのビン深さは、図13に示されるように、ゼロであるので、TEMは、このトークンの値をSEPビン1606に挿入しない。そうすることは、ビンの中の値の数にその深さを超えさせるであろう。TEMが全てのトークン値をビンの中に置くよう試みた後で、TEMはいずれのビンが空であるかをチェックする。ビンが空であり且つその対応するトークン規則がデフォルト値を指定する場合、そのデフォルト値がビンに挿入される。現在の事例では、ボリューム(VOL)ビン1600及びセパレータ(SEP)ビン1606は空である。VOLトークンがデフォルト値「DOC」を指定するので、「DOC」は図16に示されるようにVOLビン1600に挿入される。
【0050】
マッチ・プロダクションのトークン値が図16に示されるようにビンに挿入された後で、TEMは、ビンのコンテンツについてレベル拡張又は全拡張を実行する。図17は、図16のビンについて全拡張を実行することにより形成されたトークン値のセットをリストする。レベル拡張の間に、TEMは、各ビンのi番目の値を1つの組(セット)にグループ化する(ここで、インデックスiは任意のビンの中の1から値の最大数字までの範囲に及ぶ。)。前のステートメントは、複数の値を含むビンに適用するのみである。単一の値を含むビンに対して、第1の値は、各組にグループ化される。等しくない個数の値を持つ複数の値を付けられたビンの値が拡張される場合、幾つかの組は値を見失っているであろう。全拡張の間に、TEMは、値の全ての組み合わせを複数の組にグループ化する。現在の事例では、マッチされたプロダクション規則は全拡張を指定する。その結果として、TEMは、図17に示されるように3つのグループを形成する。
【0051】
マッチされたプロダクションのトークン値が複数の組にグループ化された後で、各組は1つ又はそれより多くのフィールドにフォーマット化される。図18は、マッチされたプロダクションのボリューム(Volume)及びブックマーク(Bookmark)のフォーマットを図17の複数の組の値に適用することから結果として得られるフィールド・ラベル及び値を示す。マッチされたプロダクションのフォーマットの数は、フィールドの数を決定する。フォーマットは、ラベル及びフォーマット仕様を含む。一実施形態においては、フォーマット仕様は、次のシンタクスを有する。
【0052】
【数1】
”prefix”TOK1”suffix”‖”prefix”TOK2”suffix”‖…‖”prefix”TOKn”suffix”
(“接頭辞”TOK1“接尾辞”‖“接頭辞”TOK2“接尾辞”‖…‖“接頭辞”TOKn“接尾辞”)
垂直線間の情報は、トークン・フォーマット・グループと見なされる。各グループは、トークンをその省略形により指定しなければならず、そしてオプションの接頭辞及び接尾辞を含み得る。このトークンは、フォーマット・トークンと呼ばれる。接頭辞及び接尾辞は、引用符により囲まれたテキストである。TEMは、フォーマットを各組のトークン値に対して次のように適用する。各フォーマット・トークン・グループに対して、TEMは、上記の組がフォーマット・トークンの値を含むか否かをチェックする。それが含む場合、TEMは、トークン・フォーマット・グループの接頭辞のテキスト、フォーマット・トークン値、及びトークン・フォーマット・グループの接尾辞をフィールド・バッファに添付する。フォーマット仕様がプロダクションの中の各トークンに対してトークン・フォーマット・グループを有する必要がないことに注目すべきである。有限状態マシンがフォーマット仕様を、上記で概要を説明したアルゴリズムを適用するに適した形式に解析する。このマシンに対する有限状態が図17にリストされている。
【0053】
例えば、マッチされたプロダクションのブックマーク・フォーマット、即ち、VOL“”‖CS‖SS、及び図17における第1の組の値を考えて見る。第1のトークン・フォーマット・グループは、VOLフォーマット・トークン及び接尾辞を含む。その組がVOLフォーマット・トークンの値を含むので、値「DOC」及び「接尾辞」がフィールド・バッファに添付される。残りの2つのトークン・フォーマット・グループは、トークンCS及びSUBを含む。これらのグループは接頭辞又は接尾辞を含まない。上記組がCS及びSUBの両方のフォーマット・トークンの値を含むので、値「21−25」及び「−11」がフィールド・バッファに添付される。そのフォーマットを適用した後で、フィールド・バッファは、テキスト「DOC21−51−11」を含む。マッチされたプロダクションのボリューム及びブックマーク・フォーマットを図17における複数の組の値に適用することは、図18により示される3組のフィールドをもたらす。
【0054】
最後に、TEMが複数の組のフォーマット化されたフィールド(図18に示されるように)を生成した後で、TEMは、各組のフィールドに対してパケットを次のように生成する。最初に、TEMは、テキスト「Tem」、エンティテイの名前及びテキスト「Entity(エンティテイ)」を連結して、パケット・タイプを形成する。第2に、TEMは、そのラベルが「EntityId」であり且つその値がこのタイプのパケットのための固有の識別子であるそのコンテンツ・ラベル−値対を加える。第3に、TEMは、各フォーマットされたフィールドのためコンテンツ・ラベル−値対を加える。コンテンツのラベルはフィールドのラベルであり、そしてコンテンツの値はフィールドの値である。第4に、TEMは、入力パケット(そのコンテンツは入力テキストであった。)からコンテキスト・ラベル−値対のクローンをエンティテイのパケットに対して作る。最後に、TEMは、4つの追加のコンテキスト・ラベル−値対を加える。これらのコンテキストは、「TemParentPacketType」、「TemParentContentLabel」、「TemCollectionName」及び「TemEntityName」のラベルが付される。「TemParentPacketType」及び「TemParentContentLabel」コンテキストの値は、パケットのコンテンツが入力テキストであったそのパケットのパケット・タイプ及びコンテンツ・ラベルである。「TemCollectionName」及び「TemEntityName」コンテキストの値は、集合及びエンティテイの規則がエンティテイを識別し且つフォーマット化するため用いられるその集合及びエンティテイのそれぞれの名前である。サンプル・テキスト内のDocumentReferenceエンティテイに対応するパケット1902、1904、1906が、図19に示されている。図19は、図18のフィールド・ラベル及び値から生成される例示パケットを図示する。図18における例示実施形態において、サンプル・テキストが「障害分離要素(Fault Isolation Elemenet)」パケットの「障害分離テキスト」コンテンツから来たと仮定する。また、「障害分離要素」パケットが「章番号」及び「セクション番号」コンテキストを持ったと仮定する。
【0055】
入力テキストを処理するとき、TEMは、処理引数により指定された集合のエンティテイを検索する。一実施形態においては、エンティテイは、それらが集合内で指定された順序で検索される。現在の事例においては、TEMは、図13に示されるように、最初にEquipmentNumberエンティテイを、次いでDocumentReferenceエンティテイを、最後にFaultエンティテイを識別する。DocumentReferenceエンティテイのEquipmentNumberにおいて、全てのトークンは、1つ又はそれより多くの正規表現により指定された。しかしながら、これは、図13に示されたようにFaultエンティテイが真でない。その4つのトークンのうち、これらのトークンのうちの1つ、即ち動作トークンは、それが正規表現により指定される点でEquipmentNumber及びDocumentReferenceトークンに類似している。しかしながら、残りのトークンは異なる。EquipNum及びDocRefトークンは、EquipmentNumber及びDocumentReferenceエンティテイのそれぞれにより指定され、一方、EquipDescトークンはデフォルト・トークンである。EquipNum及びDocRefトークンは、前に識別されたEquipmentNumber及びDocumentReferenceエンティテイとマッチするであろう。現在の事例では、EquipNumトークンは、テキスト「W121(W122,W123)」とマッチし、一方、DocRefトークンは、テキスト「21−51−11,−22,−33」とマッチする。EquipDescは、ActionトークンとEquipNumトークンとの間のフィルタリングされたテキスト、即ち、図20に示される「THE L(R,C)WIDGET」とマッチする。図20は、サンプル入力テキストにおいてテキスト抽出モジュールが図13の例示テキスト抽出規則により定義されたFault(障害)エンティテイを識別したそのサンプル入力テキストである。EquipDescトークンは、FaultエンティテイがEquipDescトークンを指定しない場合にデフォルト・トークンになるであろう。曖昧さを避けるため、エンティテイは、そのトークンのうちの1つをデフォルト・トークンとして指定するのみである。
【0056】
EquipmentNumber及びDocumentReferenceエンティテイの場合のように、TEMは、図21に示されるようにFaultエンティテイに対してTemFaultEntityパケットを生成する。マッチイング・プロダクションが4つのフォーマット・アイテムを指定するので、TemFaultEntityは、動作(Action)、装置記述(Equipment Description)、装置番号(Equipment Number)及び修理手続き(Repair Procedure)コンテンツを全体的EntityIdコンテンツに加えて含み、それは、TEMが生成する全てのパケットに存在する。予測されるように、動作及び装置記述コンテンツの値は、「REPLACE(置換)」及び「THE L(R,C) WIDGET」のそれぞれである。しかしながら、装置番号及び修理手続きコンテンツの値は、「W121(W122,123)」及び「21−51−11,−22,−33」でない。代わりに、装置番号及び修理手続きコンテンツの両方が、前に生成されたTemEquipmentNumberEntity及びTemDocumentReferenceEntityパケットのEntityIdコンテンツの値に対応する3つの値を有する。従って、前に定義されたエンティテイにより指定されるトークンの値は、対応するパケットのEntityIdコンテンツの値である。この特徴は、TEMによりパックされ、作成されたものを互いにリンクする1つの方法を提供する。例えば、図21は、TemFaultEntityパケットとTemDocumentReferenceEntity及びTemEquipmentNumberEntityパケットとの関係を図示する。TemFaultEntityパケットの装置番号及び修理手続きコンテンツの両方は、それらがコンマで分離されたリストとして説明されるが、3つの値を有することに注目されたい。
【0057】
パケット・エクスポート・モジュール パケット・エクスポート・モジュール(PEM)は、汎用端末パケット・プロセッサである。換言すると、このモジュールは、何の子パケットも生成しないし、また特定の知識リポジトリ・スキーマに対して特有でない。パケット・エクスポート・モジュールの目的は、パケットを知識リポジトリにエクスポートすることであり、その知識リポジトリは、オープン・データベース接続性(ODBC)に準拠している。インポート・フィルタ及びPEMは、同じ属性の多くを共用する。インポート・フィルタは、訓練可能であり、そしてデータ・ソースの構造体に、訓練の前にインポートされることを要求し、そしてパケット処理モジュールをデータ・ソースの複雑さから守る。同様に、PEMは、訓練可能であり、そして知識リポジトリの構造体(スキーマ)に、訓練の前にインポートされることを要求し、そしてパケット処理モジュールを知識リポジトリの複雑さから守る。
【0058】
PEMの挙動は、パケット・エクスポート規則により統治され、そのパケット・エクスポート規則は、パケット・コンテンツ及びコンテキストをデータベース・テーブルのフィールドに対してマップする。丁度、パケット構成規則を訓練する前に、入力データの構造の概要が形成され、そしてインポート・フィルタ規則リポジトリにインポートされなければならないように、知識リポジトリのスキーマは、パケット・エクスポート規則を訓練する前に、解析され、そしてパケット・エクスポート規則リポジトリの中にインポートされねばならない。
【0059】
例えば、そのデータベース・スキーマが図22に示されているサンプル知識リポジトリを考えて見る。図22は、それに対してパケットがエクスポートされるサンプル知識ベースのデータベース・スキーマを図示するブロック図である。図22に示されるサンプル知識リポジトリは、5つのテーブルから成る。PemDocRef2202、PemEquipNum2204及びPemFault2206のテーブルは、情報をTemDocumentReferenceEntity、TemEquipmentNumberEntity及びTemFaultEntityパケットそれぞれに格納する。TemFaultHasDocRefs2208及びPemFaultHasEquipNums2210は、多対多関係テーブルであり、その多対多関係テーブルは、関係情報をTemFaultEntityパケットに格納する。知識リポジトリのデータベース・スキーマがパケット・エクスポート規則の中にインポートされた後で、ユーザは、パケット・エクスポート規則を指定し得る。知識ベースのデータベース・スキーマが修正され、続いて再インポートされる場合、PEMは、前のスキーマと現在のスキーマとの相違にタグ付けする。インポートは、既存のパケット・エクスポート規則が保存されるように実行される。
【0060】
図23は、図21に示されるパケットと図22に示されるデータベース・テーブルとの間のサンプル・マッピングである。パケット・コンテンツが複数の値を有し得る一方、データベース・テーブルのフィールドがせいぜい1つの値を格納し得るので、拡張は、これらの値を知識ベースへエクスポートされる組にグループ化するため、パケット値について実行されねばならない。これらの拡張方法は、トークン・ビンの中の値を複数の組にグループ化するためテキスト抽出モジュールにより用いられた拡張方法に類似している。
【0061】
1個のデータベース・テーブルに対してマップされている全てのパケット・コンテンツ及びコンテキストの値を考えて見る。レベル拡張の場合、PEMは、多値化されたパケット・コンテンツのそれぞれからのi番目の値、並びに単値化されたコンテンツ及び全コンテキストのそれぞれの値を複数の組にグループ化し、そしてこれらの値を知識リポジトリにエクスポートする。全拡張の場合、PEMは、複数のパケット・コンテンツ及びコンテキスト値の全ての組み合わせを複数の組にグループ化し、そしてこれらの値を知識リポジトリにエクスポートする。
【0062】
サンプル・パケット・エクスポート規則においてパケット・コンテンツ及びコンテキストの隣に文字「R」が付いた円を有するそのパケット・コンテンツ及びコンテキストに注目されたい。このアイコンは、これらのコンテンツ及びコンテキストがそれらの値のいずれかをエクスポートするためそれらの値を有することが要求されることを示す。換言すると、単一のデータベース・テーブルに対してマップされている、要求されたコンテンツ及びコンテキストのいずれかが、少なくとも1つの値を含まない場合、PEMは、値のいずれの組もデータベース・テーブルにエクスポートしないであろう。ここで、いずれの値も含まない非要求のコンテンツ及びコンテキストがデータベース・テーブルのフィールドにエクスポートされるとき、PEMが行うことを考えて見る。そのフィールドがヌル可能(nullable)である、即ち、それがヌルを格納することができる場合、PEMはヌルをエクスポートする。フィールドがヌル可能でないとき、PEMは、フィールドが数値データを格納する場合0をエクスポートし、又はフィールドがテキストを格納する場合ゼロ長のストリングをエクスポートする。フィールドがヌル可能でなく且つゼロ長ストリングを格納することができない場合、PEMは、パケット・エクスポート・エラー・メッセージを発行する。
【0063】
一例として、PEMが、図23に示されるパケット・エクスポート規則を用いて、図21のパケットを知識リポジトリ(その知識リポジトリのスキーマは図22に示されている。)にエクスポートするであろう仕方を考えて見る。最初に、TemDocumentReferenceEntityパケットを考えて見る。パケットのEntityId、ボリューム(Volume)及びブックマーク(Bookmark)のコンテンツは、EntityId、ボリューム及びブックマークのフィールドに対してマップされ、一方、パケットの章番号(Chapter Number)及びセクション番号(Section Number)コンテキストは、PemDocRefテーブルのChapterNumber及びSectionNumberフィールドに対してマップされる。パケット・エクスポート規則はまた、(i)パケット内の値は、複数の組にレベル拡張され、そしてデータベース記録としてエクスポートされるであろうこと、及び(ii)マップされたパケット・コンテンツ及びコンテキストのそれぞれに対する値を含む組のみがエクスポートされるであろうことを述べる。(第2の観測結果は、要求されているパケット・コンテンツ及びコンテキストのそれぞれの結果である)。図21のTemDocumentReferenceEntityパケットの全てのコンテンツが単一の値を持つので、レベル拡張は取るに足らないものである。各パケットは、図24に示されるようにPemDocRefテーブルへの記録としてエクスポートされる単一の組の値を発生する。Idフィールドの値は、このフィールドがAutoNumberタイプであるので、自動的に発生されることに注目されたい。
【0064】
ここで図21の残りのパケットを考えて見る。TemEquipmentNumberEntity及びTemDocumentReferenceEntityパケットが知識リポジトリに同じ要領でエクスポートされるので、TemFaultEntityパケットについて焦点を合わせて見る。パケット・エクスポート規則に従って、TemFaultEntityパケットは、3つのテーブル、即ち、PemFault、TemFaultHasDocRefs及びPemFaultHasEquipNumsに対してマップされる。TemFaultEntity対PemFaultマッピングは、TemDocumentReference対PemDocRefマッピングと1つの例外を有して類似している。TemFaultEntityの装置記述コンテンツは要求されない。従って、PEMは、たとえパケットが装置記述値を含まない場合でも、1組の値を知識リポジトリへTemFault記録としてエクスポートするであろう。換言すると、TemFaultパケットが装置記述コンテンツを有する場合、その値は、他の値と共にエクスポートされるであろう。しかしながら、TemFaultパケットが装置記述コンテンツを有しない場合、他の値がエクスポートされ、そして装置記述フィールドがヌルか又はゼロ長ストリングかのいずれかであろう。
【0065】
最後に、TemFaultEntity対PemFaultHasDocRefsマッピングを考えて見る。パケットのEntityId及び修理手続き(Repair Procedure)コンテンツが、PemFaultHasDocRefsテーブルのFaultKey及びDockRefKeyフィールドのそれぞれにマップされる。図21のTemFaultEntityパケットのEntityId及び修理手続きコンテンツの値は、1及び1、2及び3のそれぞれである。(EntityIdコンテンツは、1個の値を有し、そして修理手続きコンテンツは、3個の値を有する。)パケット・エクスポート規則は、これらの値が記録としてPemFaultHasDocRefsテーブルにエクスポートされる組を作成するため十全に拡張されるべきであることを指定する。3個の組の値は図25に示すように作成され且つエクスポートされる。
【0066】
要約すると、図23に示されるパケット・エクスポート規則を用いて、図21のパケットを知識リポジトリにエクスポートするとき、PEMは次のデータベース記録を作成する。
・3つのPemDocRef記録、各TemDocumentReferenceパケットから1個
・3つのPemEquipNum記録、各TemEquipmentNumberEntityパケットから1個
・1つのPemFault記録、3つのPemFaultHasDocRefs、及びTemFaultEntityパケットから3つのPemFaultHasEquipNumsパケット
CGM処理モジュール 純粋にテキスト的なデータに加えて、D2Kツールはまた、グラフィック・ファイルをコンピュータ・グラフィックス・メタファイル(CGM)フォーマットで処理することができる。CGMファイルは、グラフィック要素の集合であり、各グラフィック要素は、それを並びにそれを定義する或るデータを識別する命令コードを含む。一実施形態においては、D2KにおけるCGM処理は、3層プロセスを通して達成される。ベースで、CGMパーサ・モジュールは、CGMグラフィック・ファイルをロードし、そしてそれが新しいグラフィック要素を識別するときは常にコールバックを発火する。この最低のレベルで、パーサは、データのいずれの処理を行わないで、それは、ファイルのグラフィック・コンテンツを列挙するのみである。中間層で、ソフトウエア・モジュールは、最低レベルを用いて、コンテンツを列挙するが、しかしこの時それは、全てのテキスト要素、及びボックスを形成する線セグメントを維持する。一旦それらのエンティテイ全てが格納されてしまうと、モジュールは、テキストをそれらの境界を示す長方形(四角い枠)と関連させるよう試みる。この中間層は、ユーザ・レベルがこれらのボックス、並びにそれらが含むテキストを列挙するのを可能にするインタフェースを与える。最高の層は、障害分離図と呼ばれるCGM図面からD2Kパケットを生成する。障害分離図は、グラフィックのif/then図面であり、取るべき結論又は動作がページの右側のボックスにリストされている。この最高の層は、中間層を用いて文書を処理する。次いで、それは、最も右の列にボックスを列挙し、そしてそれらのボックス内にテキストを含むパケットを生成する。次いで、それらのパケットは、D2Kにより、あたかもそれらがインポート・フィルタから生じたかのように処理される。
【0067】
ウェブ・エグゼクティブ 図26は、ウェブ・エグゼクティブのためのユーザ・インタフェースの例示実施形態である。図26に示されるように、ヘッダ・フレームは、アプリケーションのロゴスを表示する。ナビゲーション・フレームは、複数のグループのボタンを含み、それら複数のグループのボタンは、押されたとき、対応するウェブ・ページでもってメイン・フレームを更新する。メイン・フレーム内のウェブ・ページ、及びそれらの上にホストされた制御部は、命令を表示し、メカニズムによりユーザがD2Kと対話することができるそのメカニズムを与え、そしてエラー報告、オプションのセッティング及び構成のローディング/セービングのようなグローバル機能を管理する。
【0068】
一実施形態においては、ナビゲーション・フレームは、5グループのボタン、即ち、エグゼクティブ、インポート・フィルタ、パケット・ディスパッチャ、テキスト抽出モジュール及びパケット・エクスポート・モジュールを備える。エグゼクティブ・グループのボタンは、ユーザが文書をブラウズし、構成をロード及びセーブし、データベース及びセッティングを指定し、ツールを動作させるのを可能にするウェブ・ページをロードする。残りのグループのボタンは、ユーザがインポート・フィルタ、パケット・ディスパッチャ、テキスト抽出モジュール及びパケット・エクスポート・モジュールを訓練するのを可能にするウェブ・ページをロードする。
【0069】
一実施形態においては、ウェブ・ページ上にホストされた構成要素は、クライアント側で動作する。しかしながら、D2K構成要素は、サーバ側で動作するよう修正されることができ、それによりクライアントは、単純にHTMLストリームを受け取りそして表示する。これは、ユーザがウェブ・ブラウザを動作させることができる任意のマシンからD2Kと対話するのを可能にする。
【0070】
ユーザ・インタフェース 以下のセクションはD2Kユーザ・インタフェースを説明する。最初に、インポート・フィルタ・ユーザ・インタフェースを説明する。この説明に、パケット・ディスパッチャ・ユーザ・インタフェース、テキスト抽出ユーザ・インタフェース、そして最後にパケット・エクスポート・ユーザ・インタフェースが続く。
【0071】
インポート・フィルタ・ユーザ・インタフェース 一実施形態においては、ユーザは、インポート・フィルタをインポート・フィルタ・ユーザ・インタフェースを介して訓練する。ユーザ・インタフェースは、ユーザがSGML文書のような階層構造化データ・ソースのためのパケット構成規則を作成し、修正し、削除するのを可能にする。インポート・フィルタ・ユーザ・インタフェースの便益は、それによりユーザがデータ・ソースの階層構造を視覚化するのを可能にすることである。ユーザ・インタフェースは、メイン・エディタ・ウインドウ及びモードレス(modeless)ウインドウから成り、それは、選択されたパケットのパケットを表示する。これらのウインドウのそれぞれは更に詳細に説明されるであろう。
【0072】
図27は、インポート・フィルタ・エディタの一実施形態のスクリーン・キャプチャである。インポート・フィルタ・エディタは、図27に示されるように階層構造化データをトリーとして表示する。データ・ソースの要素はフォルダとして表示され、一方、属性は文書として表示される。例えば、ユーザがノード上を右クリックして(又はさもなければノードを選択して)、その動作を変える。要素及び属性の名前は、アイコンの隣に表示される。省略符号(...)及びパケット構成規則が名前に続く。クラッターを避けるため、パケット構成規則が「データを無視する」ことである場合、それは示されない。
【0073】
ユーザは、検索ダイアログ・ボックスを呼び出すことにより、テキストを見つけるようトリーを検索することができ、その検索ダイアログ・ボックスが図28に示されている。そうするため、ユーザは、エディタにおいて右クリックし、そしてポップアップ・メニューから「…検索」コマンドを選択する。
【0074】
「テキスト場所」制御により、ユーザは、彼らがそれらの検索を属性、要素、パケット・タイプ、コンテンツ又はコンテキストに制限することに関心があるか否かを指定することが可能になる。ユーザは、前述のアイテムの全てを同様に検索することができる。更に、ユーザが、トリーの全てのノードか又は現在のノードのまさに子かのいずれかを「検索ノード」制御を介して検索する。所望の検索パラメータを入力した後で、ユーザは、「検索」ボタンを押して検索を実行する。次いで、検索の結果がリスト図に表示される。ユーザは、そのリストの中の要素をダブルクリックして、それをインポート・フィルタ・エディタ内で、即ちメイン・ウインドウ内で選択する。検索ウインドウは、その大きさを変更及び移動することができる。ダイアログ・サイズ及び位置は使用の間持続する。
【0075】
テキストを検索するのに加えて、ユーザは、クリア、編集、次に、及びブックマークのような、図30に示されるように、ポップアップ・メニューから他のコマンドを呼び出し得る。ユーザは、現在選択されているノード及びその子孫(派生)の全ての動作を、「クリア」コマンドを選択することによりクリアすることができる。このコマンドは、影響を受けた全てのノードの動作を「無視」にリセットする。ユーザは、現在選択されているノードの規則を、「編集」コマンドを選択することにより編集することができる。「編集」コマンドは、図29に示されている「パケット構成特性」ダイアログ・ボックスを呼び出す。図29は、インポート・フィルタ・エディタのパケット構成特性ダイアログ・ボックスの一実施形態である。このダイアログ・ボックスはまた、あるノードをダブルクリックすることにより呼び出すことができる。
【0076】
ユーザは、規則の動作を、そしてその規則に応じて、その規則に関連のパケット・タイプ、コンテンツ・ラベル及びコンテキスト・ラベルを編集し得る。パケット・コンテンツ及びコンテキストは、パケット・タイプと一貫性が保たれ、そしてドロップダウン・コンボ・ボックス(drop down combo boxes)からアイテムを選定することにより選択されることができる。新しいパケット・タイプ、コンテンツ・ラベル又はコンテキスト・ラベルを生成するため、ユーザは、新しい名前を単純に適切なコンボ・ボックスの中にタイプすることができる。
【0077】
トリー図をナビゲートする従来の方法に加えて、ユーザは、図30に示される「次の(Next)」メニューを選択し得る。図30は、インポート・フィルタ・エディタの「次の」メニューの一実施形態である。「次の」メニュー内のコマンドにより、ユーザが、指定された動作を有する次のノード、又は指定された相違フラグを有する次のノードを選択するのを可能にする。例えば、次ぎの|パケット生成コマンド(Next|Create a Packet command)を選択することにより、ユーザは、次のノードの規則がパケットを生成するその次のノードの位置を迅速に捜し出す。
【0078】
最後に、ユーザは、トリー図の中のノードをブックマークすることができ、それによりそれらが重要なノード間で迅速にナビゲートするのを可能にする。現在選択されているノードがブックマークされなかった場合、ユーザは、図31に示されている、ブックマーク・サブメニュー上の「セット」コマンドを選択することができる。図31は、インポート・フィルタ・エディタの「ブックマーク(Bookmark)」メニューの一実施形態である。現在選択されているノードが前にブックマークされ済みであった場合、ユーザは、そのマークを、「クリア」コマンドを選択することによりクリアすることができる。全てのブックマークを取り除くため、ユーザは、「全てをクリア」コマンドを選択することができる。ブックマークは、編集セッション間で保持される。こうして、ユーザは、異なるデータ・ソースに対してパケット構成規則を作成するとき特に、もはや必要のないブックマークを場合によってはクリアすることを希望し得る。ユーザが9より多くのノードをブックマークした場合、最初の9個のみに番号付けされる。
【0079】
「現在のパケット情報」というタイトルを付されたモードレス・ウインドウは、現在選択されているモードのパケット・プロトタイプを表示する。図32は、インポート・フィルタ・ユーザ・インタフェースのモードレス「現在のパケット情報」ウインドウの一実施形態である。このウインドウは、ユーザがパケットの構造を視覚化するのを可能にし、そのパケットの構造をインポート・フィルタは、現在選択されているパケット構成規則及びその適用可能な隣の規則を適用することにより発生するであろう。このモードレス・ウインドウは、デスクトップ上の任意の場所で大きさを変更し及び位置決めされ得る。
【0080】
インポート・フィルタ・エディタはまた、パケットの構造を視覚化する追加の方法を与える。トリー図内の任意のノードの上でマウス・カーソルを一時的に停止させる(hover)ことにより、ポップアップ・ヒント・ウインドウが一時的に現れるであろう。このヒント・ウインドウのコンテンツは、パケットの構造を表示し、そのパケットの構造をインポート・フィルタは、マウス・カーソルにより選択されたノードと関連した規則を適用することにより、部分的に作成するであろう。
【0081】
パケット・ディスパッチャ・ユーザ・インタフェース ユーザは、パケット・ディスパッチャをパケット・ディスパッチャ・ユーザ・インタフェースを介して訓練し得る。そのインタフェースは、2つのパネル間でサイズの変更可能なスプリッタ・バーを有するその2つのパネルに分割される。各パネルがより詳細に説明される。
【0082】
図33は、パケット・ディスパッチャ・ユーザ・インタフェースのプロセッサ及びパケット選択パネルの一実施形態である。プロセッサ及びパケット選択パネルは、図33に示されるトリー図として実現される。このパネルは、全ての登録された処理モジュールを含む。特定のプロセッサ(processor)上にマウスを一時的に停止させることにより、ユーザは、そのプロセッサに対してマップされている全てのパケット(及びそれらの対応パケット処理引数)を見ることができる。それに対応して、トリー図は、全ての登録されたパケット・タイプ並びにそれらの合法のコンテキスト・ラベルを含む。特定のパケット・タイプ上にマウスを一時的に停止させることにより、ユーザは、それに対してパケットがマップされる全てのプロセッサを見ることができる。新しいマッチ仕様を生成するため、ユーザは、パケット・タイプをプロセッサ上へドラッグしてドロップし得る。この動作は、新しいマッチ仕様(マッチスペック)をマッチ仕様パネルの中に挿入する。なお、そのことは次ぎに説明される。
【0083】
図34は、パケット・ディスパッチャ・ユーザ・インタフェースのマッチ仕様パネルの一実施形態である。マッチ仕様パネルは、図34に示されるリスト図として実現される。リスト図は、全てのマッチ仕様(マッチスペック)、即ち、パケットをパケット処理モジュールに対してマップするパケット・ディスパッチ規則を示す。ユーザは、複数のマッチ仕様(マッチスペック)をパケット・タイプ、プロセッサ、引数又はコンテキストに従って、対応の列ヘッディング上をクリックすることによりソート(分類)することができる。同じ列を2度目にクリックすることにより、列は反対方向にソートされる。ユーザは、リスト図のフォーマットを、「図(View)」を右クリック及び選択することにより変えることができる。
【0084】
マッチ仕様(マッチスペック)を作成するため、ユーザは、プロセッサ、パケット・タイプ又はパケット・コンテキストをプロセッサ及びパケット選択パネルからマッチ仕様パネル内の空の行上へドラッグし得る。この動作は、新しいマッチ仕様(マッチスペック)を生成し、それは、ドロップされたアイテムを含む。他方、ユーザがアイテムをプロセッサ及びパケット選択パネルからマッチ仕様パネル内のマッチ仕様(マッチスペック)上へドラッグする場合、マッチ仕様(マッチスペック)は、ドロップされたアイテムを組み込むことにより修正されるであろう。ユーザはまた、要素を右又はダブルクリックして、マッピング特性ダイアログ・ボックスを持ち出すことができる。
【0085】
ユーザは、図35に示される「マッチ仕様特性(Match Spcfication Property)」ダイアログ・ボックスを呼び出すことにより、即ちそれらをダブルクリックすることによりマッチ仕様(マッチスペック)を編集し得る。代替として、ユーザは、マッチ仕様(マッチスペック)上を右クリックして、「特性…(Property...)」コマンドのポップメニュー及び選択を呼び出し得る。「マッチ仕様特性」ダイアログ・ボックスを介して、ユーザは、マッチ仕様のプロセッサ、引数及びパケット・タイプをセットし得る。更に、ユーザは、「追加…(Add...)」及び「削除(Delete)」ボタンを用いて、パケット・コンテキスト値の対をマッチ仕様に挿入し得る。ユーザがコンテキスト値の対を有する、マッチ仕様のパケット・タイプを変える場合、エディタは、いずれの無効の対、即ち、新しいパケット・タイプに対して有効でない対を取り除くであろう。
【0086】
最後に、ユーザは、マッチ仕様パネル内のマッチ仕様(マッチスペック)を右クリックし、そして「削除」コマンドをポップアップ・メニューから選択することによりそのマッチ仕様(マッチスペック)を削除し得る。代替として、ユーザは、単純にマッチ仕様(マッチスペック)を選択し、そして削除キーを押してもよい。
【0087】
テキスト抽出ユーザ・インタフェース ユーザは、テキスト抽出ユーザ・インタフェースを介してテキスト抽出モジュール(TEM)を訓練し得る。ユーザ・インタフェースは、ユーザがテキスト抽出規則、例えば、収集、エンティテイ、トークン、正規表現、プロダクション及びフォーマットを作成し、修正し、削除するのを可能にする。テキスト抽出ユーザ・インタフェースの1つの便益は、それによりユーザがそれらがリアルタイムで作成し、修正し、又は削除するいずれの規則の衝撃を直ちに「見る」のを可能にすることである。ユーザ・インタフェースは、ダイアログ・バー、規則パネル、注釈パネル及びグリッド・パネルから成る。これらの構成要素のそれぞれが更に詳細に説明されるであろう。
【0088】
図36に示されるテキスト抽出ユーザ・インタフェース・ダイアログ・バーは、ユーザがユーザ・インタフェース制御の頂部に存在し、そして次の機能を実行するのを可能にする10個のボタンを含む。
・パケット・コンテンツの「ページ」をナビゲートする機能
・ファイル・モードからパケット・モードへ切り換える機能
・規則をテキスト抽出モジュール規則データベースから再ロードする機能
・現在のセッション中に行われる変化をセーブする機能
・パケット・モードからファイル・モードへ切り換える機能、及び
・ヘルプを呼び出す機能。
【0089】
最初の4個のボタン、即ち、矢印ボタンにより、ユーザがパケット・コンテンツの最初の「ページ」、前の「ページ」、次の「ページ」、及び最後の「ページ」へ行くのを可能にする。パケット・コンテンツは、パケット・データベースから読み出される。(パケット・データベースは、選択された「パケットをデータベースにセーブする」処理オプションを有するツールを動作させることにより占拠される。)「ページ」は、注釈ペイン(pane)に表示され、そして規則ペインにおいて現在選択されているエンティテイの識別されたトークン及びプロダクションを表示することにより注釈される。第5のボタン、即ち「パケットを再ロードする(Reload Packet)」ボタンは、注釈ペインをファイル・モードからパケット・モードへ切り換える、即ち注釈ペインにおけるテキストは、パケット・データベースから読み出される。第6のボタン、即ち「データベースを再ロードする(ReloadDB)」ボタンは、テキスト抽出規則をテキスト抽出規則リポジトリから再ロードする。ユーザは、現在の変化が廃棄されるであろうことを警告されるであろう。第7のボタン、即ち「データベースをセーブする(SaveDB)」ボタンは、テキスト抽出規則に対する変化をコミット(commit)し、そしてそれらをテキスト抽出規則リポジトリへ書き込む。第8のボタン、即ち「ファイルを開ける(OpenFile)」ボタンは、注釈ペインをパケット・モードからファイル・モードへ切り換える、即ち、注釈ペインにおけるテキストは、ユーザによって選択されたファイルから読み出される。第9のボタン、即ち「〜について(About)」ボタンは、テキスト抽出ユーザ・インタフェースについての関連情報を表示する。最後に、第10のボタン、即ち「ヘルプ(Help)」ボタンは、テキスト抽出ユーザ・インタフェース・ヘルプアプリケーションを起動する。
【0090】
規則パネルは、図37に示されるように階層トリー図内のテキスト抽出規則を表示する。トリー・ノードは、収集、エンティテイ、トークン、正規表現、プロダクション又はフォーマットのうちのいずれかであり得る。これらのノードの1つを表すアイコンは、ボックスで囲まれた黒の大文字である。その文字は、ノード・タイプの最初の文字、例えば、収集に対するC、エンティテイに対するE等に対応する。更に、どの収集がどのパケット・コンテンツを処理するかを指定するノードがまた、トリー内に存在する。ボックスで囲まれた黒丸はこれらのノードを表す。
【0091】
ノードのテキストはそのタイプに依存する。収集ノードに対するテキストは収集の名前であり、それに括弧内にあるその省略形が続く。エンティテイ・ノードに対するテキストはエンティテイの名前であり、それに括弧内にあるその省略形が続く。同様に、トークン・ノードに対するテキストはトークンの名前であり、それに括弧内にあるその省略形が続く。しかしながら、トークンが前に識別されたエンティテイに言及する場合、参照エンティテイの名前及び省略形が続くテキスト「エンティテイ(Entity.)」は、四角括弧により囲まれ、そしてトークン・テキストへ添付される。正規表現ノードのテキストは正規表現自体であり、一方、プロダクション・ノードのテキストはプロダクションの文法である。フォーマット・ノードのテキストはフォーマットのラベルの名前である。最後に、「収集がパケット・コンテンツを処理する(collection processes packet content)」ノードのテキストは、ピリオドにより分離された、パケット・タイプ及びコンテンツ・ラベルである。
【0092】
ユーザは、規則を作成すること、規則を削除すること、規則をコピーすること、又は規則を移動することのような、規則パネル内の幾つかの操作を実行することができる。ユーザは、それらのノードをドラッグしてそれを別のノード上にドロップすることにより規則をコピー又は移動することができる。ユーザがノードを1つの収集からドラッグし、そしてそれを異なる収集の中にドロップする場合、ノード及びその系統がコピーされる。ユーザがノードを1つの収集からドラッグし、それを異なる位置であろうとも同じ収集の中にドロップする場合、ユーザは、彼/彼女がノード及びその子をコピーし又は移動するのを欲するかどうかについて、ポップアップ・ダイアログを介して、促される。ユーザはマウスがノード上にない間に規則パネルを右クリックする場合、ユーザが収集を生成するのを可能にするポップアップ・メニューが現れる。しかしながら、ユーザは、マウスがノード上にある間に右クリックする場合、ユーザが「選択された」ノードを削除し、又は子ノードを作成するのを可能にするポップアップ・メニューが現れる。例えば、ユーザは、マウスがエンティテイ上にあるとき右クリックする場合、ユーザがエンティテイを削除し、又はトークンを生成し、あるいはプロダクションを作成するのを可能にするポップアップ・メニューが現れる。ユーザは、マウスが正規表現ノード上にあるとき右クリックする場合、ユーザが正規表現を削除するのみを可能にするポップアップ・メニューが現れる。
【0093】
注釈パネルは、図38に示されるようにスクロール可能な図であり、そのスクロール可能な図は、現在のエンティテイのトークン及びプロダクションを識別することによりサンプル・テキストを注釈する。規則図の中の現在選択されているアイテムがエンティテイである場合、現在のエンティテイは、選択されたアイテムである。規則図の中の現在選択されているアイテムがエンティテイでない場合、現在のエンティテイは、その子孫が選択されたアイテムの中にあるエンティテイである。サンプル・テキストは、テキスト・ファイルから読み出されるか、又はパケット・リポジトリ内のデータからロードされ得る。サンプル・テキストが多くのラインを含む場合、注釈ペインは、異なるページの中の注釈されたテキストを表示する。ユーザは、ダイアログ・バー上のボタン「ダイアログ・バー」を介してページをナビゲートし得る。
【0094】
サンプル・テキストの各ラインに対して、現在のエンティテイのトークン及びプロダクションが注釈される。トークン及びプロダクションは、テキストの上及びその下のそれぞれの水平方向の括弧の片方により識別される。トークンは更に、それらの省略された名前を括弧の頂部上に表示することにより注釈される。省略形がトークンの上で適合することができない場合、星印が代わりに表示される。マウスを星印の上で一時的に停止させることにより、ユーザは、省略形を表示するヒント・ウインドウを呼び出すであろう。同様の要領で、プロダクションは更に、選択されたエンティテイの名前を括弧の下に表示することにより注釈される。マウスをエンティテイの名前の上で一時的に停止することにより、ユーザは、プロダクションのフォーマット・ラベル及び値を表示するヒントを呼び出すであろう。
【0095】
ユーザは、規則をグリッド・パネルを介して生成、修正及び削除することができる。グリッド・パネルは、図39に示されるように複数の行及び列を含む。グリッドの最初の行は、規則図の中で現在選択されている、ノードのコンテンツを表示する。グリッドの中間の行は、現在選択されているノードの同胞である、ノードのコンテンツを表示する。星印
【0096】
【表2】
【0097】
がマークされている、グリッドの最後の行は、空であり、そしてユーザが新しい規則を作成するのを可能にする。列並びに列ヘッダの数は、現在選択されているノードのタイプに依存する。
【0098】
新しい規則を作成するため、ユーザは、適切な情報を最後の行の各列に入れ、そしてカーソルを異なる行へナビゲートしなければならない。ユーザは、グリッド上のいずれの列のコンテンツを編集することができる。現在編集されつつある行には記号がマークされる。行に対する変化をコミットするため、ユーザは、カーソルを異なる行へマウス又は矢印キー
【0099】
【表3】
【0100】
によりナビゲートしなければならない。規則を削除するため、ユーザは、最も左の(編集できない)列上をクリックすることにより行を選択し、そして削除キーを押さなければならない。ユーザが確認すると直ちに、行(及び対応する規則)は削除されるであろう。
【0101】
パケット・エクスポート・ユーザ・インタフェース ユーザは、パケット・エクスポート・モジュール(PEM)をパケット・エクスポート・ユーザ・インタフェースを介して訓練し得る。ユーザ・インタフェースは、ユーザがパケット・エクスポート規則、例えば、パケット・コンテンツ/コンテキスト対データベース・テーブル・フィールド間でマッピングすることを作成、修正及び削除するのを可能にする。パケット・エクスポート・ユーザ・インタフェースの1つの便益は、それによりユーザがパケット・エクスポート規則を意味のある要領で視覚化するのを可能にすることである。ユーザ・インタフェースは、2つのパネル、即ち選択パネル及びグラフィックス・パネル、並びにステータス・バーから成る。各パネルは更に詳細に説明されるであろう。更に、ユーザが知識リポジトリ・スキーマをパケット・エクスポート規則データベースにインポートするのを可能にする制御が説明されるであろう。
【0102】
パケット・コンテンツ/コンテキストをデータベース・テーブル・フィールドに対してマッピングする前に、ユーザは、データベース・スキーマをパケット・エクスポート規則データベースに知識リポジトリ・スキーマ・インポート制御を介してインポートする。インポート制御は、2つのボタン及び2つのペインを含む。知識リポジトリ・スキーマをパケット・エクスポート規則データベースにインポートするため、ユーザは、インポート・ボタンを押すべきである。図40に示されるように、知識リポジトリのテーブルが左ペインに表示され、一方現在選択されているテーブルのフィールドが右ペインに表示される。ユーザは、適切なテーブルをマウス又は矢印キーを介して選択することによりいずれのテーブルのフィールドをブラウズし得る。データベース・テーブル及びフィールドは、ステータス・アイコンにより処理され得る。新しいテーブル及びフィールド、即ち、前のインポート中に知識リポジトリの中に存在しなかったそれらのものは、緑プラス・アイコンによりフラグを立てられる。使われていないテーブル及びフィールド、即ち、前のインポート以来知識リポジトリから削除されたそれらのものは、赤の文字「x」アイコンによりフラグを立てられる。修正されたフィールド、即ち、それらのタイプ及び/又は属性が前のインポート以来変化されたそれらのものは、黄色のチェックマーク・アイコンによりフラグを立てられる。使われていないテーブル及びフィールドの使われていないスキーマを削除するため、ユーザは、消去(purge)ボタンを押すべきである。
【0103】
選択パネル(selection panel)は、図41に示されるようにトリー図の中の2つのリストを表示する。最初のリストは、システムに対して知られているパケット、即ち、パケット辞書に登録されているパケットを表示する。第2のリストは、知識リポジトリ・テーブルを表示する。グラフィックス・パネルの中のパケット又はテーブルを表示するため、ユーザは、トリー図の中の対応するアイテムをダブルクリックすべきである。ユーザがパケットを1つ又はそれより多いテーブルに対してマップする規則を有するそのパケットをダブルクリックする場合、マップされたテーブルはまた、マッピング規則と共に、グラフィックス・パネルの中に表示される。
【0104】
図42に示されるようにグラフィックス・パネルは、その上でパケット・エクスポート規則が作成され、修正され又は削除され得るキャンバスである。パケットはウインドウとして表される。パケット・タイプは、ウインドウのタイトル・バーの中に表示される。コンテンツ及びコンテキスト・ラベルは、ウインドウの内側にリストされる。コンテンツ及びコンテキスト・ラベルは、異なるアイコンにより進められる。類似の要領で、知識リポジトリ・テーブルはウインドウとして表される。テーブルの名前は、ウインドウのタイトル・ボードの中に表示され、そしてテーブル・フィールドは、ウインドウの内側にリストされる。
【0105】
パケット又はテーブルをキャンバスに加えるため、選択パネルの中の対応するアイテム上をダブルクリックする。ユーザが、パケットを1つ又はそれより多いテーブルに対してマップする規則を有するそのパケットをダブルクリックする場合、マップされたテーブルはまた、マッピング規則と共に、グラフィックス・パネルの中に表示される。パケット又はテーブルをキャンバスから取り除くため、パケット又はテーブル・ウインドウの上右手隅の中の小さい「x」ボタン上をクリックする。パケットがキャンバスから取り除かれる場合、それに対してマップされる全ての規則も同様に取り除かれる。テーブル・ウインドウは、それらに対してマップされる規則が無い限りのみ取り除かれることができる。従って、1つのマップは、最初に、テーブル・ウインドウに対してマップされているパケット・ウインドウを取り除く。ウインドウ及び規則をキャンバスから取り除くことは、それらを削除するものではない。対応するパケット・エクスポート規則は、依然パケット・エクスポート規則データベースの中に存在する。
【0106】
パケットとデータベース・テーブルとの間の新しいパケット・エクスポート(マッピング)規則を作成するため、ユーザは、最初に、パケット・ウインドウの中のコンテンツ又はコンテキストの上をクリックすることによりそのコンテンツ又はコンテキストを選択し、次いでデータベース・テーブル・ウインドウの中のフィールドの上をクリックすることによりそのフィールドを選択しなければならない。一旦前述の手順が実行されると、パケット・エクスポート・ユーザ・インタフェースは、マッピング規則を表すため、2つの選択されたアイテム間にラインを引く。最近選択されたコンテキスト又はコンテンツ・ラベルを持つ別のエクスポート規則を作成するため、パケット・ウインドウの中のラベルをダブルクリックし、次いで新しいデータベース・テーブル・フィールドを選択する。
【0107】
ユーザがマッピング規則即ちラインの上で左又は右マウス・ボタンをクリックするとき、そのラインは、規則が選択されたことを示すため太く表示される。これは、ユーザが規則の属性を変えるか、又はそれを削除するかを可能にする。規則が生成されるとき、それらの拡張方法は、「レベル」にセットされ、そしてパケット・コンテンツ/コンテキストは、記録セットを知識リポジトリにエクスポートするため必要とされない。しかしながら、規則がマップする対応するパケット及びデータベース・テーブルが既に規則を有する、即ち、ラインが既にそれらの間に引かれている場合、拡張レベルは、既存の規則のそれにセットされる。一実施形態において、規則の拡張方法が「レベル」であるその規則が1つの色で引かれ、これに対して、規則の拡張方法が「フル」であるその規則は異なる色で引かれる。ユーザがパケット及びデータベースをマップする規則の拡張方法を変えるとき、このパケットとデータベース・テーブルとの間の全規則の拡張方法が変えられる。最後に、ユーザがパケット・ウインドウ、データベース・テーブル・ウインドウ及び規則を除いて、キャンバス上の任意の位置を右クリックする場合、ユーザがマッピング規則をパケット・エクスポート規則データベースにセーブするのを可能にするポップアップ・メニューが現れる。
【0108】
リポジトリ 次のセクションにおいて、D2Kデータベースは、次の順序、即ち、インポート・フィルタ規則リポジトリ、パケット辞書リポジトリ、処理モジュール・リポジトリ、パケット・ディスパッチ規則、パケット・リポジトリ、テキスト抽出規則リポジトリ、パケット・エクスポート規則リポジトリ、メッセージ・ログ・リポジトリ及び知識ベースの順序で説明される。各データベースが簡単に記載される。
【0109】
一実施形態において、ユーザは、D2Kデータベースに格納されているデータを直接編集しない。代わりに、ユーザは、D2Kユーザ・インタフェースと対話し、次いでD2Kユーザ・インタフェースは、データベースのコンテンツを修正するであろう。
【0110】
インポート・フィルタ規則リポジトリ 動作(Action)テーブルは、パケット構成規則動作、即ち、データを無視する、データを無視し且つ新しいパケットを生成すること、新しいパケットを生成し且つデータをパケットの中にコンテンツとして挿入すること、データを現在のパケットの中にコンテンツとして挿入する、データを現在のパケットの中にコンテンツとして添付すること、及びデータを現在のパケットの中にコンテキストとして挿入することを格納する。
【0111】
フィールド・タイプ(FieldType)テーブルは、データ・フィールドの全体の及び省略形の名前を格納する。SGMLインポート・フィルタの場合、データ・フィールドは、要素又は属性のいずれかである。
【0112】
IDマップ系統(IdMap,_Lineage)テーブル及び作業空間(Workspace)テーブルは、データ構造のインポート及びパケット登録中にインポート・フィルタ規則により作成される。その系統テーブルは、コンテキストの承継(inheritance)を促進するため各ノード子孫のマップをキャッシュする。
【0113】
パケット・タイプ(PacketType)テーブル、コンテキスト・ラベル(ContextLable)テーブル及びコンテンツ・ラベル(ContentLabel)テーブルは、パケット構成規則により生成されるパケットのパケット・タイプ、コンテンツ・ラベル及びコンテキスト・ラベルを格納する。
【0114】
文書構造(DocumentStructure)テーブルは、データ・ソースの構造が格納され処理される一時的バッファである。
パケット構成(PacketConstruction)テーブルは、パケット構成規則を格納する。テーブル内のデータは、入力データ・ソースの構造をインポートするプロセスにより生成され、そしてインポート・フィルタ・ユーザ・インタフェースにより修正される。
【0115】
パケット辞書リポジトリ 一実施形態において、パケット辞書データベースは6個のテーブルから成り、その1つは、一時的作業空間である。主テーブルは、PacketType、ContentLabel、ContextLabel、PacketAllowsContent、及びPacketAllowsContextである。これらのテーブル内のデータは、合法のパケットのプロトタイプを指定する。幾つかの重要な(vital)D2K機能は、パケット辞書を用いる。例えば、D2K訓練ユーザ・インタフェースは、パケット辞書を用いて、リスト・ボックス選択を制限し、それによりユーザが有効でない訓練規則を発生するのを禁止し、一方パケット・ファクトリは、パケット辞書を利用して、合法のパケットのみが生成されることを保証する。更に、幾つかの他のデータベースは、図43に示されるようにパケット辞書テーブルへのリンクを含む。
【0116】
プロトタイプ登録(PrototypeRegistration)テーブルは作業空間であり、その作業空間は、パケット・プロトタイプを構成するため、幾つかのD2K構成要素により用いられる。次いで、パケット・プロトタイプは、パケット辞書を用いて登録される。
【0117】
パケット・タイプ(PacketType)テーブル、コンテキスト・ラベル(ContextLable)テーブル及びコンテンツ・ラベル(ContentLabel)テーブルは、合法のパケット・タイプ、コンテンツ・ラベル及びコンテキスト・ラベルをそれぞれ格納する。「パケットによるコンテンツの許可(PacketAllowsContent)」テーブル、及び「パケットによるコンテキストの許可(PacketAllowsContext)」テーブルは、どのコンテンツ及びコンテキスト・ラベルがどのパケットにおいて合法的であるかを指定する。
【0118】
パケット・モジュール・リポジトリ 処理モジュール・リポジトリは、登録された処理モジュールのリスト、並びにそれらを呼び出すため必要とされる情報を格納する。この情報は、プロセッサ(Processor)テーブルに格納される。更に、リポジトリは、どのパケットを各処理モジュールが生成することができるかを格納する。この情報は、「プロセッサにより登録されたコンテンツ(ProcessorRegisteredContent)テーブル、及び「プロセッサにより登録されたコンテキスト(ProcessorRegisteredContex)テーブルに格納される。一実施形態において、インポート・フィルタが処理モジュールでないにも拘わらず、このリポジトリは、どのパケットをインポート・フィルタが同様に生成することができるかを格納する。
【0119】
パケット・ディスパッチャ規則リポジトリ パケット・ディスパッチャ規則リポジトリはパケット・ディスパッチ規則を格納する。マッチ仕様(MatchSpec)は、マッチ仕様(MatchSpec)テーブル、及び「マッチ仕様によるコンテキストの所持(MatchSpecHasContext)」テーブルに格納される。作業空間(Workspace)テーブルは、パケット・ディスパッチャ・インタフェースにより用いられる一時的作業空間である。
【0120】
パケット・リポジトリ パケット・リポジトリは、パケットが継続され得るデータベースである。パケット・ディスパッチャは、パケットをリポジトリの中に存続させ、ユーザは、「パケットをデータベースにセーブする(Save Packet in Database)」チェックボックスをエグゼクティブ・ウェブ・ページ上にセットする。パケットは、4つのテーブル、即ち、パケット(Packet)テーブル、「パケットによるコンテンツの所持(PacketHasContent)」テーブル、「コンテンツによる値の所持(ContentHasValues)」テーブル、及び「パケットによるコンテキストの所持(PacketHasContext)」テーブルに格納される。
【0121】
テキスト抽出規則リポジトリはテキスト抽出規則を格納し、そのテキスト抽出規則スキーマが図44に示されている。トークンとエンティテイとの関係に注目されたい。全てのトークンは、その親エンティテイに対する関係を有する。直線はこの関係を示す。しかしながら、トークンが1つ又はそれより多い正規表現から成り得て、又はそれらが前に4つのエンティテイであり得ることを思い出されたい。トークンが後者のケースに入る場合、オプションの関係、即ち曲線は、非ヌルであり、そして前に見つけられたエンティテイを参照するであろう。
【0122】
収集(collection)は1つ又はそれより多いエンティテイを有するので、エンティテイは1つ又はそれより多いトークンを有し、トークンは1つ又はそれより多い正規表現等を有し、これらの1対多の関係を実現する仕方に関して判断がなされる。2つのコマンド表示が図45に示されている。これらの表示を説明するため、トークンと正規表現エンティテイとを考えて見る。トークンは、1つ又はそれより多い正規表現を有し得て、例えば、文書ボリューム・トークンは、「FIN」、「(MM)|(AMM)」及び「(WM)|(WDM)」のような正規表現を有し得る。前述の例は、図45のオプションAにより示されるように1対多のマッピングを意味する。代替のマッピングは、各正規表現が図45のオプションBに示されるように1つのトークンと関連付けられることである。第1のアプローチの利点は、正規表現が異なるトークンにより再使用され得ることであるが、これに対して、その欠点は、追加のデータベース・テーブルがその関係を格納するため必要とされることである。第2のアプローチの利点は、関係を別々のデータベース・テーブルに格納する必要がないことであり、これに対して、このアプローチの欠点は、データベースが、同じ正規表現が2つ以上のトークンにより参照されるため複写を含むことである。非技術的制約のため、本発明者は、後者のアプローチ、即ちオプションBを選定する。
【0123】
ビン拡張方法(BinExpansionMethod)テーブルは、ビン拡張タイプ、即ち、「レベル」及び「フル(全)」の合法の値を含むルックアップ・テーブルである。
プロトタイプ(Prototype)テーブルは作業空間であり、そしてテキスト抽出モジュールは、その作業空間を用いて、それが生成することができるパケットのプロトタイプを構成する。
【0124】
Collection、Entity、Token、RegExpr、Production及びFormatの各テーブルは、収集、エンティテイ、トークン、正規表現、プロダクション及びフォーマットのそれぞれを格納する。
【0125】
EntityNameテーブル及びTokenNameテーブルは、エンティテイ及びトークンの名前を格納する。エンティテイ(Entity)及びトークン(Token)の両方のテーブルは、これらのテーブルからのエンティテイ及びトークンのそれぞれを参照する。これらの名前は、収集によるエンティテイの名前の正確な再使用及びエンティテイによるトークン名の正確な再使用をサポートするためそれら自体のテーブルに分離される。
【0126】
CollectionProcessesPacketContentテーブルは、どのパケット・コンテンツがどの収集により処理されるかのリストを格納する。より正確であるため、テキスト抽出モジュールは、指定されたパケット・コンテンツの値を、規則の指定された収集に従って処理する。
【0127】
パケット・エクスポート規則リポジトリ パケット・エクスポート規則リポジトリは、パケット・エクスポート規則を格納する。パケット・エクスポート・モジュールの挙動はこれらの規則により統治され、それらの規則はパケット・コンテンツ及びコンテキストをデータベース・テーブルのフィールドに対してマップする。パケット構成規則を訓練する前に、入力データの構造がその輪郭を描かれ、そしてインポート・フィルタ規則リポジトリにインポートされなければまさにならないように、知識リポジトリのスキーマは、パケット・エクスポート規則を訓練する前に、解析され、そしてパケット・エクスポート規則リポジトリにインポートされなければならない。
【0128】
拡張方法(ExpansionMethod)テーブルは、ビン拡張タイプ、即ち、「レベル」及び「フル」の合法の値を含むルックアップ・テーブルである。
BufDBFieldテーブル及びBufDBTableテーブルは一時的バッファであり、その一時的バッファに知識ベースのスキーマが、格納されそして処理される。これらのテーブル内のデータは、どのテーブル及び/又はフィールドが知識リポジトリ・スキーマの最後のインポート以来追加されたか、又は削除されたか、あるいは修正されたかを決定するためDBTableテーブル及びDBFieldテーブル内のデータと比較される。
【0129】
DBTableテーブル及びDBFieldテーブルは、知識ベースのスキーマを格納する。これらのテーブルの両方は、スキーマ・インポート同士の間の差のフラグを立てるため、IsAdddedフィールド及びIsRemovedフィールドを有する。更に、DBFieldテーブルはIsModifiedフィールドを同様に有する。
【0130】
MapPacketType2DBTableテーブル及びMapPacketInfo2DBFieldテーブルは、パケット・エクスポート・マッピング規則を格納する。MapPacketType2DBTableは、どのパケットがどのデータベース・テーブルに対してマップされるかのリストを格納する。更に、値拡張方法はこのテーブルに格納される。MapPacketInfo2DBFieldテーブルは、どのパケット・コンテンツ/コンテキストがどのデータベース・テーブル・フィールドに対してマップされるかのリストを格納する。更に、コンテント値又はコンテキスト値が記録セットをエクスポートするため要求されるか否かを指定するフラグが、このテーブルに格納される。
【0131】
メッセージ・ログ・リポジトリ D2Kは、メッセージ・ログ・リポジトリの中のエラー、警告及びデバッグ・メッセージを持続させる。メッセージ・ログは3つのテーブルを有する。ModuleTypeテーブルは、メッセージを生成することができるD2K構成要素のリストを格納する。Severity(重大さ)テーブルは、致命的、エラー、警告、メッセージ及びデバッグのようなエラーのクラスのリストを格納する。最後に、MessageLog(メッセージ・ログ)テーブルはメッセージを格納する。
【0132】
知識ベース 知識リポジトリのスキーマは、各D2Kアプリケーションに対して特有である。パケット・エクスポート・モジュールを訓練する前に、知識リポジトリ・スキーマは、パケット・エクスポート規則リポジトリにインポートされる。一旦インポートされると、ユーザは、パケット・コンテンツ及びコンテキストの値から成る記録セットをエクスポートするようパケット・エクスポート・モジュールを訓練する。
ハードウエア及び操作環境
図46は、本発明のどの例示実施形態が実現され得るかに関連したコンピュータ化システムのブロック図である。コンピュータ90は、プロセッサ92、ランダム・アクセス・メモリ(RAM)94、読み出し専用メモリ(ROM)96、及びハード・ディスク・ドライブ、フロッピー・ディスク(登録商標)ドライブ(その中にフロッピー・ディスク(登録商標)を挿入することができる。)、光ディスク・ドライブ、テープ・カートリッジ・ドライブ等のような1つ又はそれより多い記憶装置98を含む。RAM94及びROM96は、コンピュータのメモリを集約的に指している。メモリ、ハード・ドライブ、フロッピー・ディスク(登録商標)、CD−ROM等は、コンピュータ可読媒体のタイプである。コンピュータ可読媒体は、プロセッサ92により実行される命令を格納する。命令は、プロセッサ92にバスを介して与えられる。本発明は、コンピュータ90のいずれかのタイプに特に限定されない。そのようなコンピュータの構成及び動作は、当該技術では周知である。
【0133】
一実施形態においては、データ/知識(D2K)翻訳機が、コンピュータ90のようなコンピュータ上で実行するソフトウエアの中に組み込まれている。一実施形態においては、D2Kシステムは、C++コンピュータ言語を用いてソフトウエアで実現され、そして構成要素オブジェクト・モデル(COM)構成要素の集合としてパッケージされ、それは、ウェブ・ブラウザでインスタンス化(例示)され、且つHTMLウェブ・ページに埋め込まれたマイクロソフト・ビジュアル・ベーシック(Microsoft Visual Basic)(登録商標)及びJava(登録商標)スクリプトを介して接続される。しかしながら、当業者は、他の互換性のあるハードウエア及びプログラミング言語を、本発明の範囲から外れることなく採用し得ることを認めるであろう。
【0134】
特定の実施形態が本明細書で説明され記載されたが、同じ目的を達成するため計算されたいずれの構成が、示された特定の実施形態に代わり得ることが当業者に認められるであろう。この出願は、本発明のいずれの適応又は変形をカバーすることを意図するものである。従って、本発明は特許請求の範囲及びその均等物によってのみ制限されることを明白に意図するものである。
【図面の簡単な説明】
【図1】
図1Aは、本発明の一実施形態に従ったデータ/知識翻訳システムの高レベル・ブロック図である。
図1B、図1C及び図1Dは、データ/知識(D2K)翻訳システムの代替実施形態の高レベル・ブロック図である。
【図2】
図2は、図1に示されるデータ/知識翻訳機(D2K)システムを実行するための物理的アーキテクチャの例示実施形態のブロック図である。
【図3】
図3は、本発明の一実施形態に従ったD2K翻訳機を訓練するプロセスのフロー・チャートである。
【図4】
図4は、本発明の一実施形態に従った、D2K翻訳機を有する知識ベースを構成するためデータ・ソースを解析するプロセスのフロー・チャートである。
【図5】
図5は、図2に示されるパケットのためのパケット・データ構造の一実施形態のより詳細な図である。
【図6】
図6は、図2に示されるインポート・フィルタのような、本発明の一実施形態のインポート・フィルタに印加されることになる例示ソース・データを示す。
【図7】
図7は、図6の例示ソース・データに適用されることなる例示インポート・フィルタ規則を示す。
【図8】
図8は、図7に示される例示インポート・フィルタ規則を図6に示されるソース・データに適用することにより生成される第1のパケットの例示一実施形態を示す。
【図9】
図9は、図7に示される例示インポート・フィルタ規則を図6に示されるソース・データに適用することにより生成される第2のパケットの例示一実施形態を示す。
【図10】
図10は、図7に示される例示インポート・フィルタ規則を図6に示されるソース・データに印加することにより生成される第1のパケットの代替の例示実施形態を示す。
【図11】
図11は、図2のパケット・ディスパッチャにより使用の例示で親マッチ仕様規則を図示する。
【図12】
図12は、図2のテキスト抽出モジュールにより処理されることになるサンプル入力テキストである。
【図13】
図13は、テキスト抽出モジュールの集合の階層表示である。
【図14】
図14は、例示入力テキストの中でテキスト抽出モジュールが図13の例示テキスト抽出規則により定義されるようなEquipmentNumber(装置番号)エンティテイを識別したその例示入力テキストである。
【図15】
図15は、例示入力テキストの中でテキスト抽出モジュールが図13の例示テキスト抽出規則により定義されるようなDocumentReference(文書基準)エンティテイを識別したその例示入力テキストである。
【図16】
図16は、ビンの中にソートされたDocumentReferenceプロダクション(図13の例示テキスト抽出規則により定義されたように)に対するトークン値を示す。
【図17】
図17は、図16のビンについての全拡張を実行することにより形成されたトークン値のセットを示す。
【図18】
図18は、マッチされたプロダクションのボリューム及びブックマーク・フォーマットを図17のトークン値のセットに適用することから生じるフィールド・ラベル及び値を示す。
【図19】
図19は、図18のフィールド・ラベル及び値から作成されるパケットの例示実施形態を示す。
【図20】
図20は、サンプル入力テキストの中でテキスト抽出モジュールが図13の例示テキスト抽出規則により定義されるようなFaultエンティテイを識別したそのサンプル入力テキストである。
【図21】
図21は、TemFaultEntityパケットとTemDocumentReferenceEntity及びTemEquipmentNumberEntityパケットとの関係を図示する。
【図22】
図22は、サンプル知識ベースに対してパケットがエクスポートされるそのサンプル知識ベースのデータベース・スキーマを図示するブロック図である。
【図23】
図23は、例示エンティテイを例示テーブルに対してマップするパケット・エクスポート規則の図的表示である。
【図24】
図24は、図19のTemDocumentReferenceEntityパケットをエクスポートした後の例示テーブルである。
【図25】
図25は、図19のパケットをエクスポートした後の5個の例示テーブルを示す。
【図26】
図26は、ウェブ・エグゼクティブに対するユーザ・インタフェースの例示実施形態である。
【図27】
図27は、インポート・フィルタ・エディタの一実施形態のスクリーン・キャプチャである。
【図28】
図28は、インポート・フィルタ・エディタの検索ダイアログ・ボックスの一実施形態である。
【図29】
図29は、インポート・フィルタ・エディタのパケット構成特性ダイアログ・ボックスの一実施形態である。
【図30】
図30は、インポート・フィルタ・エディタの「Next(次の)」メニューの一実施形態である。
【図31】
図31は、インポート・フィルタ・エディタの「Bookmark(ブックマーク)」メニューの一実施形態である。
【図32】
図32は、インポート・フィルタ・ユーザ・インタフェースのモードレスの「Current Packet Information(現在のパケット情報)」の一実施形態である。
【図33】
図33は、パケット・ディスパッチャ・ユーザ・インタフェースのプロセッサ及びパケット選択パネルの一実施形態である。
【図34】
図34は、パケット・ディスパッチ・ユーザ・インタフェースのマッチ仕様パネルの一実施形態である。
【図35】
図35は、パケット・ディスパッチ・ユーザ・インタフェースの一実施形態の「マッチスペックification Propertes(マッチ仕様特性)」ダイアログ・ボックスである。
【図36】
図36は、テキスト抽出ユーザ・インタフェースのダイアログ・バーの一実施形態である。
【図37】
図37は、規則パネルの一実施形態のスクリーン・キャプチャである。
【図38】
図38は、注釈パネルの一実施形態のスクリーン・キャプチャである。
【図39】
図39は、グリッド・パネルの一実施形態のスクリーン・キャプチャである。
【図40】
図40は、知識リポジトリ・スキーマ・インポート制御の一実施形態のスクリーン・キャプチャである。
【図41】
図41は、パケット・エクスポート選択パネルの一実施形態のスクリーン・キャプチャである。
【図42】
図42は、グラフィックス・パネルの一実施形態のスクリーン・キャプチャである。
【図43】
図43は、パケット、パケット辞書、処理モジュール及びパケット・ディスパッチ規則データベース間の関係を図示するブロック図である。
【図44】
図44は、テキスト抽出規則データベースの一実施形態に対するスキーマのエンティテイ関係図である。
【図45】
図45は、「1対多」の関係を表す2つの方法を図示する。
【図46】
図46は、それに関連して本発明の例示実施形態が実行され得るコンピュータ化システムのブロック図である。
発明の分野
本発明は、コンピュータ・システムに関し、特にデータを知識に翻訳するコンピュータ・システムに関する。
【0002】
発明の背景
決定支援システムのような多くの製品は、知的決定をするため知識を必要とする。決定支援システムは、知識、解析ツール及びモデルを組み合わせて、決定者を支援するコンピュータ・ベースのシステムである。決定支援システムは通常、知識データベース又は知識リポジトリを含む。知識は、決定を支援するため、知識データベース又は知識リポジトリから抽出され、解析ツール及びモデルを用いて解析される。決定支援システムに対して有効であるため、データは、知識データベースに格納される前に、解析され、翻訳され、そして構造化され意味のある知識に編成されねばならない。
【0003】
多くの場合、データは、人間が読める文書の形式であり、決定支援システムに対するその形式は、非構造化された意味のないデータとして見える。データは、情報、生の事実及び類似のものを意味する。データは、紙の書類、又はディジタルの書類におけるような様々な形式で存在し得る。データそれ自体は、決定支援システムに対して意味を持たない。決定支援システムがデータを処理するため、データは、最初に、決定支援システムが処理できる形式に翻訳されねばならない。
【0004】
本明細書で用いられているように、知識は、決定支援システムにより処理されることができる情報を意味する。知識の集合は知識ベース又は知識リポジトリと呼ばれる。標準一般化マーク付け言語(SGML)又は拡張可能なマーク付け言語(XML)のような構造化データ・フォーマットでさえもが、必要とされる知識の全てが必ずしもマークアップ(マーク付け)によりタグを付けられ得るのではないので、決定支援システムに対して不適切である場合がある。データから知識への人間の翻訳は、特に、周期的に更新されるデータ・ソースにとって、労力を要し、費用がかかり、そして誤りを起こしがちである。特別目的の知識ベース構成プログラムが、多くの場合余りに柔軟性に欠けているので直接適用できなく、また余りにコストがかかるので新しい種類のデータ及び/又は知識リポジトリに対して修正できない。
【0005】
必要とされることは、人間が使える情報のような非構造化された意味のないデータを構造化された意味のある知識、即ちマシンが使える知識に変換する仕方である。
【0006】
発明の概要
訓練可能で拡張可能な自動化データ/知識翻訳機が記載されている。本発明の一局面は、コンピュータ化システムによりデータの処理を統治する、ユーザによって指定された規則を格納する少なくとも1つのリポジトリと、その規則に従ってデータを処理し且つそのデータから知識を生成する少なくとも1つの処理モジュールとを有するコンピュータ化システムを含む。本発明の別の局面は、データを知識に翻訳する、コンピュータ化された方法である。そのコンピュータ化された方法は、データを知識に翻訳するコンピュータ化システムの挙動を統治するためユーザによって指定された規則を設けるステップと、データを前記規則に従って処理して知識を生成するステップとを含む。本発明の更なる局面は、コンピュータ可読媒体に格納され、データを知識に翻訳する方法を実行するコンピュータ実行可能命令を有する上記コンピュータ可読媒体である。前記コンピュータ化された方法は、データを、非構造化された形式で受け取るステップと、前記データを中立形式に変換するステップと、ユーザによって指定された規則に従ってデータを処理して前記データを中立形式から知識に翻訳するステップと、前記知識を知識リポジトリにエクスポートするステップとを備える。
【0007】
実施形態の説明
好適な実施形態の以下の詳細な説明において、この出願の一部を形成し、且つ本発明を実施し得る例示な特定の実施形態が例示により示されている添付図面が参照される。本発明の範囲を逸脱することなく、他の実施形態を用い得て、そして構造的変更を行い得ることが理解されるべきである。
システム・レベルの概要
図1Aは、本発明の一実施形態に従ったデータ/知識翻訳システム100の高レベルブロック図である。データ入力フォーマット及び知識出力要件における広い変化のため、本発明のデータ/知識(D2K)システムの一実施形態の論理的アーキテクチャは、図1Aに示されるようにデータ・ソース入力と知識リポジトリ出力とを分離する3層構造のシステムである。層1のソフトウエア構成要素102は、ソース・データ101を中立フォーマットにインポートする。一旦データが中立フォーマットになると、層2のソフトウエア構成要素104は、データを解析し、編成(organize)し、処理する。最後に、層3のソフトウエア構成要素106は、処理されたデータ(知識)を知識リポジトリ108にエクスポートし、そこにおいて、希望する場合には、更なる処理が行われてもよい。この3層構造のアーキテクチャは、ツールを特定のデータ・フォーマット又は全体に異なるドメインに適用するに必要とされる開発量を低減することによりD2Kシステムの拡張性を最大にする。各層は十分に定義されたインタフェースにより分離され、それにより1つの層に対する内部変化は隣接の層に対する変化を必要としない。この3層構造に加えて、D2Kシステムはシステム・エグゼクティブ110を含み、そのシステム・エグゼクティブ110は、3層の各層内及び各層間でアクティビティを調整すること、並びにユーザとの対話及びエラーの報告のようなグローバル機能を与える。
【0008】
しかしながら、D2Kシステムは3層構造のシステムに限定されるものではない。一代替実施形態においては、1つ又はそれより多い追加の層が、図1に示されるD2K翻訳システム100の論理的アーキテクチャに追加され得る。更に別の実施形態においては、論理的アーキテクチャは、2つの層又は単一の層としてさえ動作するようスケール変更することができる。
【0009】
図1Bは、D2K翻訳システム100の代替実施形態の高レベルブロック図である。図1Bに示されるように、D2K翻訳システム100は、コンピュータ化されたシステム100によりデータの処理を統治する、ユーザによって指定された規則を格納するための少なくとも1つのリポジトリ114を備える。D2K翻訳システム100はまた、その規則に従ってデータを処理し且つデータから知識を生成するための少なくとも1つの処理モジュール112を備える。
【0010】
図1Cは、D2K翻訳システム100の追加の実施形態の高レベルブロック図である。図1Cに示されるように、D2K翻訳システム100は、少なくとも1つのリポジトリ114及び少なくとも1つの処理モジュール112を備える。D2K翻訳システム100は更に、少なくとも1つのリポジトリ及び少なくとも1つの処理モジュールを制御するためのシステム・エグゼクティブ110を備える。
【0011】
図1Dは、D2K翻訳システム100の別の実施形態の高レベルブロック図である。図1Dに示されるように、D2K翻訳システム100は、少なくとも1つのリポジトリ114、少なくとも1つの処理モジュール112及びシステム・エグゼクティブ110を備える。D2K翻訳システム100はまた、ユーザがユーザによって指定された規則を作成し、修正し、削除するのを可能にするユーザ・インタフェースを備える。
【0012】
多くのデータ・フォーマットがソース・データ101に対して存在する。非構造化データは、文書、画像、データベース、図表、略図及び類似のものの形式であり得るが、これらに限定されるものではない。一般にデータを単一のフォーマットに変換することが常に可能(好都合)というわけではないので、D2Kシステムは、様々なソース・データ・フォーマットをサポートする。層1のソフトウエア構成要素102は、データをその生来のフォーマットで処理し、そして関連の情報を中立フォーマットに変換する。換言すると、インポート層(層1)102は、ソース・データ・フォーマットの詳細及び複雑さを処理層(層2)104の処理構成要素から分離する。層2のルーチン104は、インポートされたデータを解析し、編成し、処理する。処理ルーチン104は、非構造化された意味のないデータを構造化された意味のある知識に変換する。処理構成要素は、正規表現検索エンジン、自然言語処理アルゴリズム及びグラフィックス識別アルゴリズムのような様々な技術を用いる。層3のソフトウエア構成要素106は、知識を知識リポジトリ108にエクスポートする。丁度データが多くのソース・フォーマットで存在し得るように、知識も幾つかのリポジトリ・フォーマットで表され得る。従って、エクスポート層106(層3)は、知識リポジトリ・フォーマットの詳細及び複雑さを処理ルーチンから分離する。要約すると、インポート層102及びエクスポート層104の構成要素は、処理層106の構成要素がデータ・ソース又は知識リポジトリのフォーマットを考慮する必要なしにそれらのタスクを実行するのを可能にする。
例示実施形態の物理的アーキテクチャ
図2は、図1に示されるD2Kシステムを実現するための物理的アーキテクチャの例示実施形態のブロック図である。図2に示される長方形202、206、212、210、216は、変換構成要素を表す。変換構成要素は、ある種類の入力を受け取り、それを変換して、ある種類の出力を生成する。図2に示される封筒は、本明細書では「パケット」と呼ばれるデータ構造体を表す。パケットは、変換構成要素が互いに通信をするため用いるインタフェース・メカニズムである。図2に示される円柱は、D2Kシステムの構成、変換構成要素の挙動を統治する規則、訓練データ、エラー・メッセージ及び類似のもののような様々な情報を格納するリポジトリを表す。最後に、図2に示される人々は、グラフィック・ユーザ・インタフェース(GUI)を表す。ユーザは、GUIを介して対話して、D2Kシステムの挙動をカスタマイズする。
【0013】
図2に示される例示の物理的アーキテクチャは、図1に示される論理的アーキテクチャに対して次のようにマップする。インポート・フィルタ202は、インポート・フィルタ規則リポジトリ204と共に、図1に示されるインポート層(層1)を構成する。テキスト抽出モジュール206は、テキスト抽出規則リポジトリ208及びカスタム処理モジュール210と共に、図1に示される処理層(層2)を構成する。パケット・エクスポート・モジュール212は、パケット・エクスポート規則リポジトリ214と共に、図1に示されるエクスポート層(層3)を構成する。パケット・ディスパッチャ216は、パケット・ディスパッチ規則リポジトリ218、GUI及び構成モジュール(図示せず)と共に、図1に示されるシステム・エグゼクティブを構成する。パケットは、図1に示される3つの層間及びそれら3つの層内での通信を容易にするインタフェース・オブジェクトである。
【0014】
図2に示されるD2Kシステム200の例示実施形態のデータの流れは次のとおりである。インポート・フィルタ202は、データ・ソース201を読み取り、それをインポート・フィルタ規則204に従ってパケットに離散化する。インポート・フィルタ202は次いで、これらのパケットをパケット・ディスパッチャ216に通し、そのパケット・ディスパッチャ216は、パケットをパケット・ディスパッチ規則218に従って適切な処理モジュールにディスパッチする。処理モジュールはパケットを処理する。パケット・エクスポート・モジュール212のような幾つかの処理モジュールは、追加のパケットを生成しない端末処理モジュールである。テキスト抽出モジュール206のような他の処理モジュールは、より精細な解像度の幾つかのパケットを生成する。これらの非端末処理モジュールは、それらが生成するパケットをパケット・ディスパッチャ216に通し、そのパケット・ディスパッチャ216は、次いで、パケットを適切な処理モジュールへディスパッチし、そしてサイクルが継続する。一実施形態においては、少なくとも1つの処理モジュールは、パケットを知識リポジトリにエクスポートする。このプロセスは、図4に図示されている。図4に示されるプロセスは、データ・ソースの全体が解析(構文解析)されるまで継続する。
例示実施形態のシステム構成要素
このセクションは、図2に示される例示実施形態の次のシステム構成要素、即ち、パケット、パケット辞書、パケット・ファクトリ(工場)、インポート・フィルタ、パケット・ディスパッチャ、パケット処理モジュール、テキスト抽出モジュール、パケット・エクスポート・モジュール、コンピュータ・グラフィック・メタファイル(CGM)処理モジュール及びメッセージ・ログをより詳細に説明する。
【0015】
パケット. 図2に示されるパケットは、情報の包括的集合である。図5は、図2に示されるパケット・データ構造のより詳細な図である。パケット500は、図5に示されるように、タイプ、コンテンツ及びコンテキストのためのフィールドを含むデータ構造である。パケットのタイプ502は、エンティテイ又はオブジェクトの名前である。タイプは、典型的にはパケットのコンテンツを記述するタイプである。パケットのコンテンツ504はゼロ又はそれより多いラベルから成り、各ラベルはゼロ又は1に関連した値を有する。コンテンツ・ラベルは、エンティテイ又はオブジェクトの関連属性である。コンテント値は、典型的には、パケット処理モジュールにより処理され、及び/又は知識リポジトリへエクスポートされる。他方、パケット・コンテキスト506は、ゼロ又はそれより多いラベルから成り、各ラベルは、ゼロ又は1つの関連値を有する。コンテキスト値は、コンテンツの意味を増補する(augment)か、又はコンテンツが生成される仕方を記載するかのいずれかである情報を含む。コンテント値のように、コンテキスト値も知識リポジトリへエクスポートされることができる。
【0016】
処理モジュールが子のパケットを生成するとき、処理モジュールは通常、親のコンテキストをコピーし、そしてそれを子に割り当てる。換言すると、子は、親のコンテキストを受け継ぐ。その結果として、固有の識別子を有するパケットを識別することが望ましい場合、人はその識別子をコンテキストとして格納する。子パケットが彼らの親の固有の識別子を受け継ぐので、親パケットと子パケットの関係が生成される。
【0017】
一例として、人がレシピ(調理法)をパケットとして表す仕方を考えて見る。パケットのタイプがパケット・コンテンツを記述するタイプであり、そしてパケットがレシピを表すので、単語「レシピ」は、パケットのタイプを求めることに対して明白な選定である。全てのレシピの関連属性は、名前、材料のリスト、及び調理/クッキング指示である。その結果として、我々のレシピ・パケットは、名前、材料及び命令のコンテンツを含むであろう。名前のコンテンツは、単一の値、即ちレシピの名前を含むであろう。他方、材料及び指示のコンテンツは、複数の値を含むであろう。換言すると、各材料及び指示ステップは、材料及び指示のコンテンツの別々の値としてそれぞれに格納されるであろう。最後に、1人前の数、1人前当たりのカロリーの数字及び栄養学的情報のような情報が、コンテキストとして格納されることができるであろう。
【0018】
一実施形態において、パケットは、図2に示されるインポート・フィルタ202のようなインポート・フィルタにより生成される。インポート・フィルタは、パケットを、図2に示されるパケット・ディスパッチャ216のようなパケット・ディスパッチャへ通す。パケット・ディスパッチャは、パケットをパケット処理モジュールにルート付けし、そのパケット処理モジュールは次いで、追加のパケットの情報がよりアトミック的(原子的)であるその追加のパケットを生成し得る。パケット・ディスパッチャはまた、パケットを、図2のパケット・リポジトリ220のようなパケット・リポジトリに格納し得る。最後に、全てのアトミック・パケットは、図2のパケット・エクスポート・モジュール212のような端末パケット処理モジュールにルート付けされ、その端末パケット処理モジュールは、パケットを知識リポジトリに、又はパケットを捨てるヌル・プロセッサにエクスポートする。
【0019】
パケット辞書 一実施形態において、図2に示されるパケット辞書222のようなパケット辞書は、合法のパケットのマスタ・リストを保持する。幾つかのD2Kシステム機能は、パケット辞書を用いて、データ破損を緩和する。例えば、一部の実施形態においては、訓練ユーザ・インタフェースは、パケット辞書を用いて、リスト・ボックス選択を制限して、ユーザに、有効でない訓練規則を作成するのを禁止し、一方、他の実施形態においては、パケット・ファクトリは、パケット辞書を用いて、合法のパケットのみが生成されるのを保証する。
【0020】
パケット辞書は、D2Kシステムのインポート・フィルタ及びパケット処理モジュールの登録中に占有される。一実施形態において、パケットを生成するいずれのD2Kシステム構成要素は、それが生成することができる各タイプのパケットのプロトタイプを登録する。概念的には、パケットのプロトタイプは、いずれの値も持たないパケットである。換言すると、パケット・プロトタイプは、どのコンテンツ及びコンテキストのラベルが所与のパケットのタイプにとって合法的であるかを指定する。
【0021】
パケット・ファクトリ パケット・ファクトリの目的は、パケットをパケット・リポジトリから読み出しそしてパケットをパケット・リポジトリに書き込むような1組のパケット関連のサービスを与えることである。更に、パケット・ファクトリは、パケット(それらはパケット・リポジトリに中で長く持続されていた)をインスタンス生成し、そしてそれらパケットをコンテンツ・ディスパッチャに通し、それによりそれらパケットがパケット処理モジュールにルート付けされることができるようにするサービスを提供する。最後に、パケット・ファクトリは、パケットを作るための幾つかのサービス、並びにパケットのコンテキストのクローンを作って、その親のコンテキストを受け継ぐ新しい子のパケットを生成するメカニズムを提供する。
【0022】
インポート・フィルタ 一実施形態においては、インポート・フィルタは、インポート・フィルタ規則リポジトリと共に、図1の層1を構成する。図2に示されるインポート・フィルタ202のようなインポート・フィルタの目的は、データ・フォーマットの複雑さを取り扱い、そしてこれらの詳細を処理モジュールから隠すことである。インポート・フィルタは、関連のソース・データをパケットに離散化する。なお、それらのパケットはD2Kシステムの中立データ・フォーマットである。データ・ソースに応じて、このプロセスを起こすメカニズムは異なる。例えば、SGML又はXMLのような階層的に構造化されたデータにとって、パケット構造規則は、階層の各ノードに対して関連付けられ得る。別の実施形態においては、マイクロソフトのワード(登録商標)文書に格納されたデータにとって、Visual Basic for Applications(登録商標)スクリプト(BVAスクリプト)が、パケットを生成するため書き込まれてもよい。
【0023】
データの構造のアウトラインが、捕捉され、データベースに格納される。SGML文書の場合、そのアウトラインは、それが要素及び属性の階層を含む点で文書タグ定義(DTD)に似ている。しかしながら、一実施形態においては、アウトラインは、実際の文書に示されるDTDの一部を含むだけである。
【0024】
一旦データ構造のアウトラインが形成されると、パケット構成規則が、本発明の一実施形態に従って階層の中の各ノードに適用される。パケット構成規則は、ユーザがノードに対応するデータを用いて次のことを行うのを可能にする。
【0025】
1.データを無視する。
2.データを無視し、新しいパケットを生成する。
3.新しいパケットを生成し、データをパケットにコンテンツとして挿入する。
【0026】
4.データを現在のパケットにコンテンツとして挿入する。
5.データを現在のパケットにコンテンツとして添付する。
6.データを現在のパケットにコンテキストとして挿入する。
一実施形態において、規則に応じて、ユーザはまた、パケット・タイプ、コンテンツ・ラベル及び/又はコンテキスト・ラベルを指定し得る。更に、6個の規則は、階層の中の全てのノードに適用可能でないかも知れない。例えば、パケットを生成する祖先を持たないノードにおいてデータを現在のパケットにコンテンツとして挿入することは無効である。(一実施形態においては、インポート・フィルタ訓練ユーザ・インタフェースは、ユーザがいずれの規制に違反することを可能にしないので、ユーザが、全ての規制の経験的知識に基づくことは必要でないことに注目されたい。)
前述したように、一旦データ・ソースのアウトラインがデータベースに格納されると、パケット構成規則は、階層の中の各ノードに対して関連付けられる。規則のタイプは、インポート・フィルタ規則リポジトリの中に存在する情報に依存する。所与のノードが既に規則リポジトリの中に存在する場合、それは、同じ規則を既存のノードとして割り当てられる。ノードが既にデータベースの中に存在しない場合、それは、「データを無視する」規則を割り当てられる。本質的に、ユーザは、過去の訓練、即ちノードへの規則の適用を失うことなしに、幾つかのデータ・ソースの構造を併合することができる。更に、ユーザは、規則リポジトリ内に存在するが、しかし最近アウトラインを形成されたデータ・ソースの中に存在しないいずれのノードを削除する能力を与えられる。これら2つのメカニズムは、訓練要件を最小にしながら、ユーザが幾つかのデータ・ソースのためのパケット構成規則を1つ又はそれより多い規則リポジトリに格納することを可能にする。
【0027】
一実施形態においては、インポート・フィルタが訓練された後で、インポート・フィルタが登録される。インポート・フィルタを登録することは、インポート・フィルタがデータ・ソースを解析しながら作成することができるパケットのプロトタイプを用いてパケット辞書をポピュレートする。一実施形態においては、ユーザがインポート規則をインポート・フィルタ・ユーザ・インタフェースを介して訓練した後で、GUIは自動的にインポート・フィルタを登録する。一旦インポート・フィルタが登録されると、インポート・フィルタは、パケット構成規則を適用してパケットを構成することによりデータ・ソースを解析し得る。
【0028】
一例として、図6に示されるサンプルSGMLテキストを考えて見る。図6は、本発明のインポート・フィルタに適用される例示ソース・データを示す。図7は、図6に示される例示ソース・データに適用される例示インポート・フィルタ規則を示す。図7に示されるように、要素はボックスの中の文字「E」により識別され、一方、属性はボックスの中の文字「A」により識別される。要素及び属性の名前がボックスの中の文字に直ぐに続き、そしてインポート・フィルタ規則が省略符号に続く。「データを無視する」規則は、明示的規則無しでアイテムに対して暗黙に定義される。
【0029】
SGMLインポート・フィルタは、適切なインポート・フィルタ規則(これはまた「パケット構成規則」とも呼ばれる。)を適用して、サンプル・テキストを要素毎に解析する。図6に示されるサンプルSGMLテキストにおいて、インポート・フィルタは、最初に、マスタ障害テーブル(MSTFLTAB)要素を解析する。この要素に対応する図7における規則は、要素のデータを無視することになるので、インポート・フィルタは、障害行(FLTROW)要素を解析することを進める。この要素に対応する図7における規則は、インポート・フィルタに対して、タイプが「障害コード(Fault Code)」のパケットを生成するよう命令する。次に、インポート・フィルタは、FLTROW要素の属性を解析する。章番号(CHAPNBR)、セクション番号(SECTNBR)及び固有キー(KEY)の属性に対応する図7における規則は、インポート・フィルタに対して、3つのコンテキスト・ラベル−値の対を障害コード・パケットに加えるよう指示する。CHAPNBR、SECTNBR及びKEYの属性の値、即ち、「29」、「24」及び「EN29240001−00001001」は、図8のパケットに示されるように、章番号、セクション番号及び固有キーそれぞれの値になる。図8は、インポート・フィルタが図6のSGMLテキストの障害記述(FLTDESC)要素を解析する前の障害コード・パケットのスナップショットである。次の3つの要素に対応する規則が、パーサに対して、要素のデータを無視するよう命令するので、インポート・フィルタは、障害記述(FLTDESC)要素を解析することを進める。
【0030】
FLTDESC要素に対応する図7における規則は、インポート・フィルタに対して、タイプが「障害徴候(Fault Symptom)」の第2のパケットを生成するよう命令する。次に、インポート・フィルタは、カテゴリ(CATEG)属性の値を図9に示される障害徴候パケットに障害徴候タイプ・コンテンツとして挿入する。次いで、障害タイプ(FLTYPE)属性の値は、障害徴候タイプ・コンテンツの現在の値に添付される。FLTYPE属性に対応する規則が、インポート・フィルタに対して、属性のデータを障害徴候タイプ・コンテンツに添付するよりむしろ挿入することを命令した場合、インポート・フィルタは、このデータを第2の値として挿入したであろう。FLTDESC要素及びその属性を解析した後で、インポート・フィルタは、障害メッセージ(FLTMSG)及びATA ECAM(ATAECAM)要素を解析する。インポート・フィルタは、図9に示されるように、これらの要素の値を障害徴候パケットに障害徴候テキスト及びECAM ATAとして挿入する。次に、インポート・フィルタは、FLTDESC終了タグに遭遇する。その結果として、それは、障害徴候の親パケット即ち障害コード・パケットのコンテキストのクローンを作り、そして障害徴候パケットをパケット・ディスパッチャに通す。図9は、インポート・フィルタが図6のサンプルSGMLテキストの中の障害徴候(FLTDESC)終了タグに遭遇した後の障害徴候パケットのスナップショットである。
【0031】
パケット・ディスパッチャから戻ると直ぐに、インポート・フィルタは、図6のSGMLテキストのタスク参照(TASKREF)要素を解析する。インポート・フィルタは、図10に示されるように、この要素の値を障害コード・パケットにFIP K12参照コンテンツとして挿入する。インポート・フィルタは、次の要素を無視し、次いで、FLTROW終了タグに遭遇する。このタグに遭遇すると直ぐに、インポート・フィルタは、障害コード・パケットをコンテンツ・ディスパッチャに通す。パケット・ディスパッチャから戻ると直ぐに、インポート・フィルタは、MSFLTAG終了タグに遭遇し、そして終了する。図10は、インポート・フィルタが図6のサンプルSGMLテキストの中の障害行(FLTROW)終了タグに遭遇した後の障害コード・パケットのスナップショットである。要約すると、図7のパケット構成規則を、図6のサンプルSGMLに適用することは、図10に示されるような障害コード・パケット、及び図9に示されるような障害徴候パケットを生成する。
【0032】
パケット・ディスパッチャ 図2のパケット・ディスパッチャ216のようなパケット・ディスパッチャは、D2Kシステムの前半分(即ち、インポート層)と後ろ半分(即ち、処理層及びエクスポート層)との間のヒンジ(蝶番)点であり、パケット「traffic cop」として機能する。一実施形態においては、パケット・ディスパッチャは、3つのモードで動作する。その正常モードの動作においては、パケット・ディスパッチャは、パケットをパケット・マッチ仕様規則に従ってパケット処理モジュールにルート付けする。なお、そのパケット・マッチ仕様規則は、図2のパケット・ディスパッチ規則データベース218のようなパケット・ディスパッチ規則データベースに格納されている。第2のモードにおいては、ユーザは、パケットをディスパッチすることを使用不能にすることができ、そしてパケット・ディスパッチャを構成して、パケットを、図2のパケット・リポジトリ220のようなパケット・リポジトリに単にセーブすることができる。第3のモードにおいては、ユーザは、パケット・ディスパッチャを構成して、パケットをパケット処理モジュールにディスパッチし、且つパケットをパケット・リポジトリに格納することの両方を行うことができる。この最後のモードは、デバッギング支援として有効であり、そしてユーザにパケット監査トレイルを与える。
【0033】
一実施形態においては、パケット・ディスパッチャは、インポート・フィルタ、パケット・ディスパッチャ、パケット処理モジュール三者間の順序付けの2つのモード、即ち、シングルスレッドされるのとマルチスレッドされるのとをサポートする。シングルスレッド・モードにおいては、インポート・フィルタは、パケットを生成し、そしてそのパケットをパケット・ディスパッチャに通し、そのパケット・ディスパッチャは、それを適切なパケット処理モジュールに通す。パケット処理モジュールは、そのパケットを処理し、そして次いで追加のパケットを作成してもよい。なお、その追加のパケットは子パケットを呼ばれる。次に、パケット処理モジュールは、順次的に各子パケットをパケット・ディスパッチャに通し、そのパケット・ディスパッチャは、その子パケットを適切なパケット処理モジュールに通す。このサイクルは、元の情報の中の全ての関連情報が処理され且つエクスポートされてしまうまで継続する。この時点で、インポート・フィルタは、別のパケットを生成するため、入力データを解析するのを随意に再開する。要約すると、シングルスレッド・モードの動作において一旦インポート・フィルタがパケットを生成すると、インポート・フィルタは、そのインポート・フィルタが入力データを解析するそのタスクを再開する前にこのパケット並びに全てのその子孫パケットが処理されるまで待つ。マルチスレッドされたモードにおいては、インポート・フィルタは、ディスパッチャがその処理を再開する前にパケットを処理するのを待つ必要がない。生のパケットがパケット・ディスパッチャにおいてキューされ、そして第2の実行スレッドによりシリアルに処理される。これにより、インポート・フィルタが連続的に作業することが可能になる。マルチスレッド動作は、D2Kシステムがマルチプロセッサ・コンピュータ・システム上でホストされるとき有利である。
【0034】
前述したように、パケット・ディスパッチャは、パケット・ディスパッチ規則データベースに格納されたパケット・マッチ仕様規則に従ってパケットをパケット処理モジュールにルート付けする。一実施形態においては、パケット・マッチ仕様規則は、パケット・マッチ仕様(本明細書では「マッチ仕様(マッチスペック)」と呼ぶ。)をパケット処理モジュール(「パケット・プロセッサ」と呼ぶ。)に対してマップする。マッチ仕様は、パケットのタイプ、オプションの処理引数、及びゼロ又はそれより多いコンテキスト・ラベル−値の対から成る。マッチ仕様は、次の2つの例外を持つパケットに似ている。
・マッチ仕様はパケット・プロセッサ引数を含む。
・マッチ仕様はコンテンツを含まない。
一実施形態においては、ヌル・プロセッサ・モジュールを除いて、パケット処理モジュールは、それらのグローバル固有識別子(GUID)により指定される。GUIDなしの処理モジュールは、ヌル・プロセッサ・モジュールであると想定される。
【0035】
図11は、パケット・ディスパッチャにより使用の例示パテント・マッチ仕様規則を図示する。図11において、3つのマッチ仕様1102、1104、1106は、2つのパケット・プロセッサ1108、1110に対してマップされている。第1のマッチ仕様1102は、ヌル・モジュール1108がタイプ「障害トピック(Fault Topic)」の全てのパケットを処理することができることを指示する。第2のマッチ仕様1104は、引数「障害(Fault)」を持つテキスト抽出モジュール1110がタイプ「障害トピック」のパケットを処理できることを指示する。なお、その障害トピック・タイプ・コンテキストは、「障害分離(FAULT ISOLATION)」に等しい。第3のマッチ仕様1106は、引数「あり得る原因(Possible Causes)」を持つテキスト抽出モジュール1110がタイプ「あり得る原因」の全てのパケットを処理することができることを指示する。一実施形態においては、次のガイドラインをマッチ仕様に適用する。
・マッチ仕様は、唯1つののみのパケット・プロセッサに対してマップしなければならない。
・幾つかのマッチ仕様は、同じパケット・プロセッサに対してマップしてよい。
・同じパケット・タイプを持つマッチ仕様は、それらが異なるコンテキスト・ラベル−値の対を持つ限り異なるパケット・プロセッサに対してマップしてよい。
【0036】
どのパケット・プロセッサがパケットを処理すべきかを決定するため、パケット・ディスパッチャは、最初にどのマッチ仕様がパケットをマッチするかを決定する。次いで、このリストから、パケット・ディスパッチャは、最良のマッチ仕様を決定する。マッチ仕様がパケットをマッチするため、2つの要件が適合されねばならない。第1に、マッチ仕様は、パケットと同じタイプでなければならない。第2に、マッチ仕様のコンテキストは、それが存在する場合、パケットに存在しなければならない。進行ステートメント(進行命令文)は、マッチ仕様がマッチするため、パケットがマッチ仕様と同じコンテキストの全てを持たねばならないことを含意しない。マッチ仕様に存在しないコンテキストを持つパケットは、そのパケットがマッチ仕様により指定されたコンテキストを持つ限り相変わらずマッチ仕様をマッチする。換言すると、パケットのコンテキストは、マッチするためマッチ仕様のコンテキストのスーパセット(superset)でなければならない。一旦パケット・ディスパッチャがパケットをマッチする全てのマッチ仕様のリストを決定すると、パケット・ディスパッチャは、大部分のコンテンツを有するマッチ仕様を最良のものとして選定する。一度最良のマッチ仕様が決定されると、パケット・ディスパッチャは、パケット及び対応する処理引数を、最良のマッチ仕様に対してマップされているパケット・プロセッサに通す。
【0037】
例えば、図11に示される実例を考えて見る。「障害確認(FAULT CONFIRMATION)」に等しい障害トピック・タイプ・コンテキストを持つタイプ「障害トピック」のパケットは、第1のマッチ仕様1102によりマッチされるのみであろう。続いて、これらのパケットは、ヌル・モジュール1108にディスパッチされるであろう。「障害分離(FAULT ISOLATION)」に等しい障害トピック・タイプ・コンテキストを持つタイプ「障害トピック」のパケットは、第1のマッチ仕様1102及び第2のマッチ仕様1104の両方によりマッチされるであろう。パケット・ディスパッチャは、第2のマッチ仕様1104が第1のマッチ仕様1102より多くのコンテキスト・ラベル−値対を持つので、このパケットをテキスト抽出モジュール1110にディスパッチするであろう。
【0038】
パケット処理モジュール パケット処理モジュール、又はそれはまたパケット・プロセッサとも言われるそのパケット・プロセッサの目的は、パケットを解析し、編成し、処理することである。一実施形態においては、パケット・プロセッサは、2つのグループ、即ち、汎用パケット・プロセッサとカスタム・パケット・プロセッサとに分類され得る。汎用パケット・プロセッサは、データ・ソースに関係なく用いられそうであるパケット・プロセッサである。他方、カスタム・パケット・プロセッサはデータ・ソース特有である。更に、パケット・プロセッサはまた、端末か又は非端末かで分類され得る。端末パケット・プロセッサはパケット・コンシューマである。それらは、パケットを処理するが、しかし子パケットを生成しない。非端末パケット・プロセッサはパケット・プロデューサである。それらは、パケットを処理し、そして子パケットを作成する。
【0039】
本発明の一実施形態においては、3つの汎用パケット・プロセッサ、即ち、テキスト抽出モジュール、パケット・エクスポート・モジュール及びヌル・モジュールがある。テキスト抽出モジュール及びパケット・エクスポート・モジュールは、次のセクションで詳細に説明されるであろう。ヌル・プロセッサは端末パケット・プロセッサである。ヌル・プロセッサはパケットを処理しない。その目的は、単純にパケットを消費することである。一実施形態においては、ヌル・プロセッサはまた、それが実行を持たない点で独特である。パケット・ディスパッチャは、その機能を実効的に実行する。パケットを物理的ヌル・プロセッサにルート付けする代わりに、パケット・ディスパッチャは単純にそれらを破壊する。
【0040】
一実施形態においては、パケット・プロセッサがパケットを解析し編成し処理する前に、それらパケットは登録される。パケット・プロセッサの登録は、2つのことで達成される。第1に、記録、これはパケット・プロセッサに対応するが、この記録は、記録が既に存在しない場合処理モジュール・リポジトリに挿入される。第2に、パケットのプロトタイプ、これをパケット・プロセッサが生成し得るが、このパケットのプロトタイプはパケット辞書に登録される。第1の機能は、パケット・ディスパッチャのような他の構成要素に、パケット・プロセッサ自身であることを気付かせる。第2の機能は、他の構成要素に、パケット・プロセッサが生成し得るパケットを気付かせる。
【0041】
テキスト抽出モジュール 図2のテキスト抽出モジュール206のようなテキスト抽出モジュール(TEM)は、汎用非端末パケット・プロセッサである。テキスト抽出モジュールの目的は、ユーザによって指定されたテキスト・エンティテイを識別し且つフォーマット化することである。指図された維持ドメインに関連した一実施形態においては、テキスト・エンティテイの例は、文書参照(文書基準)、部品番号、観察報告及び障害を含む。全てのパケット・プロセッサの場合のように、TEMは、パケット及びプロセッサ引数を通される。プロセッサ引数は、どのテキスト抽出規則の集合が入力テキストに適用されるべきかを指定する。入力テキストは、ユーザによって指定されたパケット・コンテンツの値を含む。
【0042】
TEMは、パケットを処理するとき次の動作を実行する。最初に、TEMは、テキスト抽出規則により指定されたエンティテイを識別する。2番目に、TEMは、エンティテイをテキスト抽出フォーマット化規則に従ってフォーマット化する。最後に、TEMは、そのTEMが識別してフォーマット化した各エンティテイのため1つ又はそれより多くのパケットを出力する。
【0043】
TEMは、エンティテイを次のように識別する。最初に、TEMは、入力テキストをトークンのリストに変換するためその入力テキストについて字句解析を実行する。トークンは、1つ又はそれより多くの拡張された正規表現により、又は前に指定されたエンティテイにより指定される。しかしながら、トークンの仕様は網羅的である必要はない。ユーザは、直接エンティテイの識別に寄与しないテキストに対して正規の表現を指定する必要がない。従って、トークン化は、2つのステップで実行される。TEMは、ユーザが指定した全てのトークンを見つけ、次いでユーザによって指定されたフィルタをユーザ指定トークン間のテキストに適用することによりデフォルトのトークンを生成する。一旦入力テキストがトークン化されてしまうと、TEMは、エンティテイを識別するため、トークン化された入力テキストについて第2の字句解析を実行する。エンティテイは、1つ又はそれより多くのプロダクション(production)により指定される。プロダクションは、そのアトミック単位が1トークンである拡張された正規表現である。要約すると、エンティテイ識別プロセスは、2解析の字句解析である。第1の解析は、入力テキストをトークンのリストに、キャラクタの拡張された正規表現を介して変換する。第2の解析は、トークン化された入力テキストの中のエンティテイを、トークンの拡張された正規表現を介して識別する。
【0044】
図12のサンプル入力テキスト、及び図13のエンティテイ、トークン及び正規表現を考えて見る。図12は、テキスト抽出モジュールにより処理されることとなるサンプル入力テキストである。図13は、テキスト抽出モジュール規則の集合の階層的表示である。図13におけるボックスの中の文字は、規則階層の中のアイテムを識別する。文字「C」はアイテムが収集であることを示し、「E」はエンティテイを、「T」はトークンを、「R」は正規表現を、「P」はプロダクションを、「F」はフォーマットをそれぞれ示す。例えば、図12のサンプル・テキストの中のEquipmentNumber(装置番号)エンティテイを識別するため、TEMは、最初に、EquipmentNumberエンティテイにおいて定義されたトークンを見つける。この例においては、EquipmentNumberエンティテイは、1つのトークン、即ち、2以上の数字が続く1文字とマッチする単一の正規表現[A−Z][0−9]{2,}を持つEquipNumを定義するのみである。図12のサンプル・テキストにおいて、TEMは、EquipNumトークン、即ちW121、W122及びW123を識別する。次に、TEMは、EquipmentNumberエンティテイ・アイテムについて指定されたキャラクタ・フィルタを用いて、残りのテキストをフィルタリングする。この例では、キャラクタ・フィルタは、スペース「 」、開きの括弧「(」、閉じの括弧「)」及びコンマ「,」を含む。フィルタは、先頭及び遅れている(lagging)キャラクタ(これらはフィルタ内にある。)をテキストの残りのブロックから取り除くことにより適用される。フィルタを適用した後で、そのテキストの残りのブロックがデフォルト・トークンに成る。
【0045】
例えば、図12において、EquipNumトークンW122及びW123、即ちコンマ及びスペース間のテキストを考えて見る。これらのキャラクタの両方がフィルタ内にあるので、それらは取り除かれ、その結果として、これらのEquipNumトークン間にデフォルト・トークンは作られない。他方、図12において、W123のEquipNumトークンと、入力テキストの終わり即ち、「)(DOC21−51−11,−22,−33)」との間のテキストを考えて見る。TEMは最初に、フィルタ内ある先頭のキャラクタを取り除く。第1のキャラクタが閉じの括弧(フィルタ内にあるキャラクタ)であるので、それは取り除かれ、そして次のキャラクタが検査される。それがスペースであるので、それもまた取り除かれる。これは、テキスト抽出モジュールがフィルタ内にないキャラクタに遭遇するまで継続する。最初のそのようなキャラクタは、文字「D」である。次いで、TEMは、フィルタ内にある遅れているキャラクタを取り除く。最後のキャラクタがピリオド、即ちフィルタ内にないキャラクタであるので、そのキャラクタは残ったままで、検索は終了する。最後のキャラクタがフィルタ内にある場合、TEMは、このキャラクタを取り除き、そして最後のキャラクタから1つ前にあるキャラクタを検査するであろう。このプロセスは、TEMがフィルタ内に無かったキャラクタに遭遇するまで継続するであろう。テキスト「DOC21−51−11,−22,−23)」が先頭及び遅れているキャラクタをフィルタリングした後に残ったままであるので、それがデフォルト・トークンとなる。以下の表1は、テキスト抽出モジュールが字句解析を実行して、サンプル・テキストの中のEquipmentNumberエンティテイを識別することから結果として得られたEquipNumトークン及びデフォルト・トークンのリストを提供している。
【0046】
.
この時点で、サンプル入力テキストは、5つのトークン、即ち、デフォルト、FIN、FIN、FIN及びデフォルトにトークン化される。次に、TEMは、第2の字句解析を実行して、EquipmentNumberエンティテイのプロダクションを見つける。この例では、1つのプロダクション、即ちFIN+のみがあり、それは1つ又はそれより多くのEquipNumトークンとマッチする。(FINはEquipNumの省略形である。)その結果として、テキスト抽出モジュールは、1個のエンティテイ、即ち、図14に示されるように3つのEquipNumトークンを見つける。
【0047】
一旦エンティテイが入力テキストの中で識別されると、それは、1つ又はそれより多くのフィールドの中にフォーマット化される。次いで、エンティテイは、パケットとしてパッケージ化され、そしてパケット・ディスパッチャに送られる。TEMはエンティテイを次のようにフォーマット化する。最初に、TEMは、マッチされたプロダクションのトークンをそれらのタイプに従ってビンの中に置く。第2に、TEMは、ビンの中のトークンについて全拡張又はレベル拡張を実行する。第3に、TEMは、マッチング・プロダクションのフォーマットのそれぞれに対してフィールドを生成する。最後に、TEMは、パケットを生成し、そしてそのフィールドをパケットにコンテンツとして挿入する。
【0048】
再び、DocumentReferenceエンティテイのサンプル入力テキスト及び規則を考えて見る。2レベルの字句解析を適用する際、TEMは、図15に示されるように、1つのCahpterSectionトークン(CS)、3つのサブジェクト(Subject)トークン(SUB)及び2つのセパレータトークン(SEP)を識別する。更に、TEMは、図15に示されるように、第2のプロダクション、即ち、VOL? CS SS(SEP SS)*とマッチする1つのエンティテイを識別する。マッチされたプロダクションの6個のトークンは、CS、SUB、SEP、SUB、SEP及びSUBである。TEMはここで、リストされたトークンの値をそれらのタイプに従ってビンの中に置く。一実施形態においては、値をビンの中に置く前に、TEMは最初に、ビンが空き場所を有することを検証する。
【0049】
図16は、ビンの中にソート(分類)された(図13の例示テキスト抽出規則により定義されるように)DocumentReferenceプロダクションに対するトークン値を示す。例えば、第1のトークンの値は「21−51」であり、そしてそのタイプはChapterSection(CS)である。CSトークンの定義がビンの深さを指定しなかったので、そのビンの深さは無限であると想定される。従って、値「21−51」はCSビン1602に挿入される。第2のトークンの値は「−11」であり、そしてそのタイプはサブジェクト(SUB)である。サブジェクトのビン深さもまた無限であるので、値「−11」はSUBビン1604に挿入される。第3のトークンの値は「,」であり、そしてそのタイプはセパレータ(SEP)である。セパレータのビン深さは、図13に示されるように、ゼロであるので、TEMは、このトークンの値をSEPビン1606に挿入しない。そうすることは、ビンの中の値の数にその深さを超えさせるであろう。TEMが全てのトークン値をビンの中に置くよう試みた後で、TEMはいずれのビンが空であるかをチェックする。ビンが空であり且つその対応するトークン規則がデフォルト値を指定する場合、そのデフォルト値がビンに挿入される。現在の事例では、ボリューム(VOL)ビン1600及びセパレータ(SEP)ビン1606は空である。VOLトークンがデフォルト値「DOC」を指定するので、「DOC」は図16に示されるようにVOLビン1600に挿入される。
【0050】
マッチ・プロダクションのトークン値が図16に示されるようにビンに挿入された後で、TEMは、ビンのコンテンツについてレベル拡張又は全拡張を実行する。図17は、図16のビンについて全拡張を実行することにより形成されたトークン値のセットをリストする。レベル拡張の間に、TEMは、各ビンのi番目の値を1つの組(セット)にグループ化する(ここで、インデックスiは任意のビンの中の1から値の最大数字までの範囲に及ぶ。)。前のステートメントは、複数の値を含むビンに適用するのみである。単一の値を含むビンに対して、第1の値は、各組にグループ化される。等しくない個数の値を持つ複数の値を付けられたビンの値が拡張される場合、幾つかの組は値を見失っているであろう。全拡張の間に、TEMは、値の全ての組み合わせを複数の組にグループ化する。現在の事例では、マッチされたプロダクション規則は全拡張を指定する。その結果として、TEMは、図17に示されるように3つのグループを形成する。
【0051】
マッチされたプロダクションのトークン値が複数の組にグループ化された後で、各組は1つ又はそれより多くのフィールドにフォーマット化される。図18は、マッチされたプロダクションのボリューム(Volume)及びブックマーク(Bookmark)のフォーマットを図17の複数の組の値に適用することから結果として得られるフィールド・ラベル及び値を示す。マッチされたプロダクションのフォーマットの数は、フィールドの数を決定する。フォーマットは、ラベル及びフォーマット仕様を含む。一実施形態においては、フォーマット仕様は、次のシンタクスを有する。
【0052】
【数1】
”prefix”TOK1”suffix”‖”prefix”TOK2”suffix”‖…‖”prefix”TOKn”suffix”
(“接頭辞”TOK1“接尾辞”‖“接頭辞”TOK2“接尾辞”‖…‖“接頭辞”TOKn“接尾辞”)
垂直線間の情報は、トークン・フォーマット・グループと見なされる。各グループは、トークンをその省略形により指定しなければならず、そしてオプションの接頭辞及び接尾辞を含み得る。このトークンは、フォーマット・トークンと呼ばれる。接頭辞及び接尾辞は、引用符により囲まれたテキストである。TEMは、フォーマットを各組のトークン値に対して次のように適用する。各フォーマット・トークン・グループに対して、TEMは、上記の組がフォーマット・トークンの値を含むか否かをチェックする。それが含む場合、TEMは、トークン・フォーマット・グループの接頭辞のテキスト、フォーマット・トークン値、及びトークン・フォーマット・グループの接尾辞をフィールド・バッファに添付する。フォーマット仕様がプロダクションの中の各トークンに対してトークン・フォーマット・グループを有する必要がないことに注目すべきである。有限状態マシンがフォーマット仕様を、上記で概要を説明したアルゴリズムを適用するに適した形式に解析する。このマシンに対する有限状態が図17にリストされている。
【0053】
例えば、マッチされたプロダクションのブックマーク・フォーマット、即ち、VOL“”‖CS‖SS、及び図17における第1の組の値を考えて見る。第1のトークン・フォーマット・グループは、VOLフォーマット・トークン及び接尾辞を含む。その組がVOLフォーマット・トークンの値を含むので、値「DOC」及び「接尾辞」がフィールド・バッファに添付される。残りの2つのトークン・フォーマット・グループは、トークンCS及びSUBを含む。これらのグループは接頭辞又は接尾辞を含まない。上記組がCS及びSUBの両方のフォーマット・トークンの値を含むので、値「21−25」及び「−11」がフィールド・バッファに添付される。そのフォーマットを適用した後で、フィールド・バッファは、テキスト「DOC21−51−11」を含む。マッチされたプロダクションのボリューム及びブックマーク・フォーマットを図17における複数の組の値に適用することは、図18により示される3組のフィールドをもたらす。
【0054】
最後に、TEMが複数の組のフォーマット化されたフィールド(図18に示されるように)を生成した後で、TEMは、各組のフィールドに対してパケットを次のように生成する。最初に、TEMは、テキスト「Tem」、エンティテイの名前及びテキスト「Entity(エンティテイ)」を連結して、パケット・タイプを形成する。第2に、TEMは、そのラベルが「EntityId」であり且つその値がこのタイプのパケットのための固有の識別子であるそのコンテンツ・ラベル−値対を加える。第3に、TEMは、各フォーマットされたフィールドのためコンテンツ・ラベル−値対を加える。コンテンツのラベルはフィールドのラベルであり、そしてコンテンツの値はフィールドの値である。第4に、TEMは、入力パケット(そのコンテンツは入力テキストであった。)からコンテキスト・ラベル−値対のクローンをエンティテイのパケットに対して作る。最後に、TEMは、4つの追加のコンテキスト・ラベル−値対を加える。これらのコンテキストは、「TemParentPacketType」、「TemParentContentLabel」、「TemCollectionName」及び「TemEntityName」のラベルが付される。「TemParentPacketType」及び「TemParentContentLabel」コンテキストの値は、パケットのコンテンツが入力テキストであったそのパケットのパケット・タイプ及びコンテンツ・ラベルである。「TemCollectionName」及び「TemEntityName」コンテキストの値は、集合及びエンティテイの規則がエンティテイを識別し且つフォーマット化するため用いられるその集合及びエンティテイのそれぞれの名前である。サンプル・テキスト内のDocumentReferenceエンティテイに対応するパケット1902、1904、1906が、図19に示されている。図19は、図18のフィールド・ラベル及び値から生成される例示パケットを図示する。図18における例示実施形態において、サンプル・テキストが「障害分離要素(Fault Isolation Elemenet)」パケットの「障害分離テキスト」コンテンツから来たと仮定する。また、「障害分離要素」パケットが「章番号」及び「セクション番号」コンテキストを持ったと仮定する。
【0055】
入力テキストを処理するとき、TEMは、処理引数により指定された集合のエンティテイを検索する。一実施形態においては、エンティテイは、それらが集合内で指定された順序で検索される。現在の事例においては、TEMは、図13に示されるように、最初にEquipmentNumberエンティテイを、次いでDocumentReferenceエンティテイを、最後にFaultエンティテイを識別する。DocumentReferenceエンティテイのEquipmentNumberにおいて、全てのトークンは、1つ又はそれより多くの正規表現により指定された。しかしながら、これは、図13に示されたようにFaultエンティテイが真でない。その4つのトークンのうち、これらのトークンのうちの1つ、即ち動作トークンは、それが正規表現により指定される点でEquipmentNumber及びDocumentReferenceトークンに類似している。しかしながら、残りのトークンは異なる。EquipNum及びDocRefトークンは、EquipmentNumber及びDocumentReferenceエンティテイのそれぞれにより指定され、一方、EquipDescトークンはデフォルト・トークンである。EquipNum及びDocRefトークンは、前に識別されたEquipmentNumber及びDocumentReferenceエンティテイとマッチするであろう。現在の事例では、EquipNumトークンは、テキスト「W121(W122,W123)」とマッチし、一方、DocRefトークンは、テキスト「21−51−11,−22,−33」とマッチする。EquipDescは、ActionトークンとEquipNumトークンとの間のフィルタリングされたテキスト、即ち、図20に示される「THE L(R,C)WIDGET」とマッチする。図20は、サンプル入力テキストにおいてテキスト抽出モジュールが図13の例示テキスト抽出規則により定義されたFault(障害)エンティテイを識別したそのサンプル入力テキストである。EquipDescトークンは、FaultエンティテイがEquipDescトークンを指定しない場合にデフォルト・トークンになるであろう。曖昧さを避けるため、エンティテイは、そのトークンのうちの1つをデフォルト・トークンとして指定するのみである。
【0056】
EquipmentNumber及びDocumentReferenceエンティテイの場合のように、TEMは、図21に示されるようにFaultエンティテイに対してTemFaultEntityパケットを生成する。マッチイング・プロダクションが4つのフォーマット・アイテムを指定するので、TemFaultEntityは、動作(Action)、装置記述(Equipment Description)、装置番号(Equipment Number)及び修理手続き(Repair Procedure)コンテンツを全体的EntityIdコンテンツに加えて含み、それは、TEMが生成する全てのパケットに存在する。予測されるように、動作及び装置記述コンテンツの値は、「REPLACE(置換)」及び「THE L(R,C) WIDGET」のそれぞれである。しかしながら、装置番号及び修理手続きコンテンツの値は、「W121(W122,123)」及び「21−51−11,−22,−33」でない。代わりに、装置番号及び修理手続きコンテンツの両方が、前に生成されたTemEquipmentNumberEntity及びTemDocumentReferenceEntityパケットのEntityIdコンテンツの値に対応する3つの値を有する。従って、前に定義されたエンティテイにより指定されるトークンの値は、対応するパケットのEntityIdコンテンツの値である。この特徴は、TEMによりパックされ、作成されたものを互いにリンクする1つの方法を提供する。例えば、図21は、TemFaultEntityパケットとTemDocumentReferenceEntity及びTemEquipmentNumberEntityパケットとの関係を図示する。TemFaultEntityパケットの装置番号及び修理手続きコンテンツの両方は、それらがコンマで分離されたリストとして説明されるが、3つの値を有することに注目されたい。
【0057】
パケット・エクスポート・モジュール パケット・エクスポート・モジュール(PEM)は、汎用端末パケット・プロセッサである。換言すると、このモジュールは、何の子パケットも生成しないし、また特定の知識リポジトリ・スキーマに対して特有でない。パケット・エクスポート・モジュールの目的は、パケットを知識リポジトリにエクスポートすることであり、その知識リポジトリは、オープン・データベース接続性(ODBC)に準拠している。インポート・フィルタ及びPEMは、同じ属性の多くを共用する。インポート・フィルタは、訓練可能であり、そしてデータ・ソースの構造体に、訓練の前にインポートされることを要求し、そしてパケット処理モジュールをデータ・ソースの複雑さから守る。同様に、PEMは、訓練可能であり、そして知識リポジトリの構造体(スキーマ)に、訓練の前にインポートされることを要求し、そしてパケット処理モジュールを知識リポジトリの複雑さから守る。
【0058】
PEMの挙動は、パケット・エクスポート規則により統治され、そのパケット・エクスポート規則は、パケット・コンテンツ及びコンテキストをデータベース・テーブルのフィールドに対してマップする。丁度、パケット構成規則を訓練する前に、入力データの構造の概要が形成され、そしてインポート・フィルタ規則リポジトリにインポートされなければならないように、知識リポジトリのスキーマは、パケット・エクスポート規則を訓練する前に、解析され、そしてパケット・エクスポート規則リポジトリの中にインポートされねばならない。
【0059】
例えば、そのデータベース・スキーマが図22に示されているサンプル知識リポジトリを考えて見る。図22は、それに対してパケットがエクスポートされるサンプル知識ベースのデータベース・スキーマを図示するブロック図である。図22に示されるサンプル知識リポジトリは、5つのテーブルから成る。PemDocRef2202、PemEquipNum2204及びPemFault2206のテーブルは、情報をTemDocumentReferenceEntity、TemEquipmentNumberEntity及びTemFaultEntityパケットそれぞれに格納する。TemFaultHasDocRefs2208及びPemFaultHasEquipNums2210は、多対多関係テーブルであり、その多対多関係テーブルは、関係情報をTemFaultEntityパケットに格納する。知識リポジトリのデータベース・スキーマがパケット・エクスポート規則の中にインポートされた後で、ユーザは、パケット・エクスポート規則を指定し得る。知識ベースのデータベース・スキーマが修正され、続いて再インポートされる場合、PEMは、前のスキーマと現在のスキーマとの相違にタグ付けする。インポートは、既存のパケット・エクスポート規則が保存されるように実行される。
【0060】
図23は、図21に示されるパケットと図22に示されるデータベース・テーブルとの間のサンプル・マッピングである。パケット・コンテンツが複数の値を有し得る一方、データベース・テーブルのフィールドがせいぜい1つの値を格納し得るので、拡張は、これらの値を知識ベースへエクスポートされる組にグループ化するため、パケット値について実行されねばならない。これらの拡張方法は、トークン・ビンの中の値を複数の組にグループ化するためテキスト抽出モジュールにより用いられた拡張方法に類似している。
【0061】
1個のデータベース・テーブルに対してマップされている全てのパケット・コンテンツ及びコンテキストの値を考えて見る。レベル拡張の場合、PEMは、多値化されたパケット・コンテンツのそれぞれからのi番目の値、並びに単値化されたコンテンツ及び全コンテキストのそれぞれの値を複数の組にグループ化し、そしてこれらの値を知識リポジトリにエクスポートする。全拡張の場合、PEMは、複数のパケット・コンテンツ及びコンテキスト値の全ての組み合わせを複数の組にグループ化し、そしてこれらの値を知識リポジトリにエクスポートする。
【0062】
サンプル・パケット・エクスポート規則においてパケット・コンテンツ及びコンテキストの隣に文字「R」が付いた円を有するそのパケット・コンテンツ及びコンテキストに注目されたい。このアイコンは、これらのコンテンツ及びコンテキストがそれらの値のいずれかをエクスポートするためそれらの値を有することが要求されることを示す。換言すると、単一のデータベース・テーブルに対してマップされている、要求されたコンテンツ及びコンテキストのいずれかが、少なくとも1つの値を含まない場合、PEMは、値のいずれの組もデータベース・テーブルにエクスポートしないであろう。ここで、いずれの値も含まない非要求のコンテンツ及びコンテキストがデータベース・テーブルのフィールドにエクスポートされるとき、PEMが行うことを考えて見る。そのフィールドがヌル可能(nullable)である、即ち、それがヌルを格納することができる場合、PEMはヌルをエクスポートする。フィールドがヌル可能でないとき、PEMは、フィールドが数値データを格納する場合0をエクスポートし、又はフィールドがテキストを格納する場合ゼロ長のストリングをエクスポートする。フィールドがヌル可能でなく且つゼロ長ストリングを格納することができない場合、PEMは、パケット・エクスポート・エラー・メッセージを発行する。
【0063】
一例として、PEMが、図23に示されるパケット・エクスポート規則を用いて、図21のパケットを知識リポジトリ(その知識リポジトリのスキーマは図22に示されている。)にエクスポートするであろう仕方を考えて見る。最初に、TemDocumentReferenceEntityパケットを考えて見る。パケットのEntityId、ボリューム(Volume)及びブックマーク(Bookmark)のコンテンツは、EntityId、ボリューム及びブックマークのフィールドに対してマップされ、一方、パケットの章番号(Chapter Number)及びセクション番号(Section Number)コンテキストは、PemDocRefテーブルのChapterNumber及びSectionNumberフィールドに対してマップされる。パケット・エクスポート規則はまた、(i)パケット内の値は、複数の組にレベル拡張され、そしてデータベース記録としてエクスポートされるであろうこと、及び(ii)マップされたパケット・コンテンツ及びコンテキストのそれぞれに対する値を含む組のみがエクスポートされるであろうことを述べる。(第2の観測結果は、要求されているパケット・コンテンツ及びコンテキストのそれぞれの結果である)。図21のTemDocumentReferenceEntityパケットの全てのコンテンツが単一の値を持つので、レベル拡張は取るに足らないものである。各パケットは、図24に示されるようにPemDocRefテーブルへの記録としてエクスポートされる単一の組の値を発生する。Idフィールドの値は、このフィールドがAutoNumberタイプであるので、自動的に発生されることに注目されたい。
【0064】
ここで図21の残りのパケットを考えて見る。TemEquipmentNumberEntity及びTemDocumentReferenceEntityパケットが知識リポジトリに同じ要領でエクスポートされるので、TemFaultEntityパケットについて焦点を合わせて見る。パケット・エクスポート規則に従って、TemFaultEntityパケットは、3つのテーブル、即ち、PemFault、TemFaultHasDocRefs及びPemFaultHasEquipNumsに対してマップされる。TemFaultEntity対PemFaultマッピングは、TemDocumentReference対PemDocRefマッピングと1つの例外を有して類似している。TemFaultEntityの装置記述コンテンツは要求されない。従って、PEMは、たとえパケットが装置記述値を含まない場合でも、1組の値を知識リポジトリへTemFault記録としてエクスポートするであろう。換言すると、TemFaultパケットが装置記述コンテンツを有する場合、その値は、他の値と共にエクスポートされるであろう。しかしながら、TemFaultパケットが装置記述コンテンツを有しない場合、他の値がエクスポートされ、そして装置記述フィールドがヌルか又はゼロ長ストリングかのいずれかであろう。
【0065】
最後に、TemFaultEntity対PemFaultHasDocRefsマッピングを考えて見る。パケットのEntityId及び修理手続き(Repair Procedure)コンテンツが、PemFaultHasDocRefsテーブルのFaultKey及びDockRefKeyフィールドのそれぞれにマップされる。図21のTemFaultEntityパケットのEntityId及び修理手続きコンテンツの値は、1及び1、2及び3のそれぞれである。(EntityIdコンテンツは、1個の値を有し、そして修理手続きコンテンツは、3個の値を有する。)パケット・エクスポート規則は、これらの値が記録としてPemFaultHasDocRefsテーブルにエクスポートされる組を作成するため十全に拡張されるべきであることを指定する。3個の組の値は図25に示すように作成され且つエクスポートされる。
【0066】
要約すると、図23に示されるパケット・エクスポート規則を用いて、図21のパケットを知識リポジトリにエクスポートするとき、PEMは次のデータベース記録を作成する。
・3つのPemDocRef記録、各TemDocumentReferenceパケットから1個
・3つのPemEquipNum記録、各TemEquipmentNumberEntityパケットから1個
・1つのPemFault記録、3つのPemFaultHasDocRefs、及びTemFaultEntityパケットから3つのPemFaultHasEquipNumsパケット
CGM処理モジュール 純粋にテキスト的なデータに加えて、D2Kツールはまた、グラフィック・ファイルをコンピュータ・グラフィックス・メタファイル(CGM)フォーマットで処理することができる。CGMファイルは、グラフィック要素の集合であり、各グラフィック要素は、それを並びにそれを定義する或るデータを識別する命令コードを含む。一実施形態においては、D2KにおけるCGM処理は、3層プロセスを通して達成される。ベースで、CGMパーサ・モジュールは、CGMグラフィック・ファイルをロードし、そしてそれが新しいグラフィック要素を識別するときは常にコールバックを発火する。この最低のレベルで、パーサは、データのいずれの処理を行わないで、それは、ファイルのグラフィック・コンテンツを列挙するのみである。中間層で、ソフトウエア・モジュールは、最低レベルを用いて、コンテンツを列挙するが、しかしこの時それは、全てのテキスト要素、及びボックスを形成する線セグメントを維持する。一旦それらのエンティテイ全てが格納されてしまうと、モジュールは、テキストをそれらの境界を示す長方形(四角い枠)と関連させるよう試みる。この中間層は、ユーザ・レベルがこれらのボックス、並びにそれらが含むテキストを列挙するのを可能にするインタフェースを与える。最高の層は、障害分離図と呼ばれるCGM図面からD2Kパケットを生成する。障害分離図は、グラフィックのif/then図面であり、取るべき結論又は動作がページの右側のボックスにリストされている。この最高の層は、中間層を用いて文書を処理する。次いで、それは、最も右の列にボックスを列挙し、そしてそれらのボックス内にテキストを含むパケットを生成する。次いで、それらのパケットは、D2Kにより、あたかもそれらがインポート・フィルタから生じたかのように処理される。
【0067】
ウェブ・エグゼクティブ 図26は、ウェブ・エグゼクティブのためのユーザ・インタフェースの例示実施形態である。図26に示されるように、ヘッダ・フレームは、アプリケーションのロゴスを表示する。ナビゲーション・フレームは、複数のグループのボタンを含み、それら複数のグループのボタンは、押されたとき、対応するウェブ・ページでもってメイン・フレームを更新する。メイン・フレーム内のウェブ・ページ、及びそれらの上にホストされた制御部は、命令を表示し、メカニズムによりユーザがD2Kと対話することができるそのメカニズムを与え、そしてエラー報告、オプションのセッティング及び構成のローディング/セービングのようなグローバル機能を管理する。
【0068】
一実施形態においては、ナビゲーション・フレームは、5グループのボタン、即ち、エグゼクティブ、インポート・フィルタ、パケット・ディスパッチャ、テキスト抽出モジュール及びパケット・エクスポート・モジュールを備える。エグゼクティブ・グループのボタンは、ユーザが文書をブラウズし、構成をロード及びセーブし、データベース及びセッティングを指定し、ツールを動作させるのを可能にするウェブ・ページをロードする。残りのグループのボタンは、ユーザがインポート・フィルタ、パケット・ディスパッチャ、テキスト抽出モジュール及びパケット・エクスポート・モジュールを訓練するのを可能にするウェブ・ページをロードする。
【0069】
一実施形態においては、ウェブ・ページ上にホストされた構成要素は、クライアント側で動作する。しかしながら、D2K構成要素は、サーバ側で動作するよう修正されることができ、それによりクライアントは、単純にHTMLストリームを受け取りそして表示する。これは、ユーザがウェブ・ブラウザを動作させることができる任意のマシンからD2Kと対話するのを可能にする。
【0070】
ユーザ・インタフェース 以下のセクションはD2Kユーザ・インタフェースを説明する。最初に、インポート・フィルタ・ユーザ・インタフェースを説明する。この説明に、パケット・ディスパッチャ・ユーザ・インタフェース、テキスト抽出ユーザ・インタフェース、そして最後にパケット・エクスポート・ユーザ・インタフェースが続く。
【0071】
インポート・フィルタ・ユーザ・インタフェース 一実施形態においては、ユーザは、インポート・フィルタをインポート・フィルタ・ユーザ・インタフェースを介して訓練する。ユーザ・インタフェースは、ユーザがSGML文書のような階層構造化データ・ソースのためのパケット構成規則を作成し、修正し、削除するのを可能にする。インポート・フィルタ・ユーザ・インタフェースの便益は、それによりユーザがデータ・ソースの階層構造を視覚化するのを可能にすることである。ユーザ・インタフェースは、メイン・エディタ・ウインドウ及びモードレス(modeless)ウインドウから成り、それは、選択されたパケットのパケットを表示する。これらのウインドウのそれぞれは更に詳細に説明されるであろう。
【0072】
図27は、インポート・フィルタ・エディタの一実施形態のスクリーン・キャプチャである。インポート・フィルタ・エディタは、図27に示されるように階層構造化データをトリーとして表示する。データ・ソースの要素はフォルダとして表示され、一方、属性は文書として表示される。例えば、ユーザがノード上を右クリックして(又はさもなければノードを選択して)、その動作を変える。要素及び属性の名前は、アイコンの隣に表示される。省略符号(...)及びパケット構成規則が名前に続く。クラッターを避けるため、パケット構成規則が「データを無視する」ことである場合、それは示されない。
【0073】
ユーザは、検索ダイアログ・ボックスを呼び出すことにより、テキストを見つけるようトリーを検索することができ、その検索ダイアログ・ボックスが図28に示されている。そうするため、ユーザは、エディタにおいて右クリックし、そしてポップアップ・メニューから「…検索」コマンドを選択する。
【0074】
「テキスト場所」制御により、ユーザは、彼らがそれらの検索を属性、要素、パケット・タイプ、コンテンツ又はコンテキストに制限することに関心があるか否かを指定することが可能になる。ユーザは、前述のアイテムの全てを同様に検索することができる。更に、ユーザが、トリーの全てのノードか又は現在のノードのまさに子かのいずれかを「検索ノード」制御を介して検索する。所望の検索パラメータを入力した後で、ユーザは、「検索」ボタンを押して検索を実行する。次いで、検索の結果がリスト図に表示される。ユーザは、そのリストの中の要素をダブルクリックして、それをインポート・フィルタ・エディタ内で、即ちメイン・ウインドウ内で選択する。検索ウインドウは、その大きさを変更及び移動することができる。ダイアログ・サイズ及び位置は使用の間持続する。
【0075】
テキストを検索するのに加えて、ユーザは、クリア、編集、次に、及びブックマークのような、図30に示されるように、ポップアップ・メニューから他のコマンドを呼び出し得る。ユーザは、現在選択されているノード及びその子孫(派生)の全ての動作を、「クリア」コマンドを選択することによりクリアすることができる。このコマンドは、影響を受けた全てのノードの動作を「無視」にリセットする。ユーザは、現在選択されているノードの規則を、「編集」コマンドを選択することにより編集することができる。「編集」コマンドは、図29に示されている「パケット構成特性」ダイアログ・ボックスを呼び出す。図29は、インポート・フィルタ・エディタのパケット構成特性ダイアログ・ボックスの一実施形態である。このダイアログ・ボックスはまた、あるノードをダブルクリックすることにより呼び出すことができる。
【0076】
ユーザは、規則の動作を、そしてその規則に応じて、その規則に関連のパケット・タイプ、コンテンツ・ラベル及びコンテキスト・ラベルを編集し得る。パケット・コンテンツ及びコンテキストは、パケット・タイプと一貫性が保たれ、そしてドロップダウン・コンボ・ボックス(drop down combo boxes)からアイテムを選定することにより選択されることができる。新しいパケット・タイプ、コンテンツ・ラベル又はコンテキスト・ラベルを生成するため、ユーザは、新しい名前を単純に適切なコンボ・ボックスの中にタイプすることができる。
【0077】
トリー図をナビゲートする従来の方法に加えて、ユーザは、図30に示される「次の(Next)」メニューを選択し得る。図30は、インポート・フィルタ・エディタの「次の」メニューの一実施形態である。「次の」メニュー内のコマンドにより、ユーザが、指定された動作を有する次のノード、又は指定された相違フラグを有する次のノードを選択するのを可能にする。例えば、次ぎの|パケット生成コマンド(Next|Create a Packet command)を選択することにより、ユーザは、次のノードの規則がパケットを生成するその次のノードの位置を迅速に捜し出す。
【0078】
最後に、ユーザは、トリー図の中のノードをブックマークすることができ、それによりそれらが重要なノード間で迅速にナビゲートするのを可能にする。現在選択されているノードがブックマークされなかった場合、ユーザは、図31に示されている、ブックマーク・サブメニュー上の「セット」コマンドを選択することができる。図31は、インポート・フィルタ・エディタの「ブックマーク(Bookmark)」メニューの一実施形態である。現在選択されているノードが前にブックマークされ済みであった場合、ユーザは、そのマークを、「クリア」コマンドを選択することによりクリアすることができる。全てのブックマークを取り除くため、ユーザは、「全てをクリア」コマンドを選択することができる。ブックマークは、編集セッション間で保持される。こうして、ユーザは、異なるデータ・ソースに対してパケット構成規則を作成するとき特に、もはや必要のないブックマークを場合によってはクリアすることを希望し得る。ユーザが9より多くのノードをブックマークした場合、最初の9個のみに番号付けされる。
【0079】
「現在のパケット情報」というタイトルを付されたモードレス・ウインドウは、現在選択されているモードのパケット・プロトタイプを表示する。図32は、インポート・フィルタ・ユーザ・インタフェースのモードレス「現在のパケット情報」ウインドウの一実施形態である。このウインドウは、ユーザがパケットの構造を視覚化するのを可能にし、そのパケットの構造をインポート・フィルタは、現在選択されているパケット構成規則及びその適用可能な隣の規則を適用することにより発生するであろう。このモードレス・ウインドウは、デスクトップ上の任意の場所で大きさを変更し及び位置決めされ得る。
【0080】
インポート・フィルタ・エディタはまた、パケットの構造を視覚化する追加の方法を与える。トリー図内の任意のノードの上でマウス・カーソルを一時的に停止させる(hover)ことにより、ポップアップ・ヒント・ウインドウが一時的に現れるであろう。このヒント・ウインドウのコンテンツは、パケットの構造を表示し、そのパケットの構造をインポート・フィルタは、マウス・カーソルにより選択されたノードと関連した規則を適用することにより、部分的に作成するであろう。
【0081】
パケット・ディスパッチャ・ユーザ・インタフェース ユーザは、パケット・ディスパッチャをパケット・ディスパッチャ・ユーザ・インタフェースを介して訓練し得る。そのインタフェースは、2つのパネル間でサイズの変更可能なスプリッタ・バーを有するその2つのパネルに分割される。各パネルがより詳細に説明される。
【0082】
図33は、パケット・ディスパッチャ・ユーザ・インタフェースのプロセッサ及びパケット選択パネルの一実施形態である。プロセッサ及びパケット選択パネルは、図33に示されるトリー図として実現される。このパネルは、全ての登録された処理モジュールを含む。特定のプロセッサ(processor)上にマウスを一時的に停止させることにより、ユーザは、そのプロセッサに対してマップされている全てのパケット(及びそれらの対応パケット処理引数)を見ることができる。それに対応して、トリー図は、全ての登録されたパケット・タイプ並びにそれらの合法のコンテキスト・ラベルを含む。特定のパケット・タイプ上にマウスを一時的に停止させることにより、ユーザは、それに対してパケットがマップされる全てのプロセッサを見ることができる。新しいマッチ仕様を生成するため、ユーザは、パケット・タイプをプロセッサ上へドラッグしてドロップし得る。この動作は、新しいマッチ仕様(マッチスペック)をマッチ仕様パネルの中に挿入する。なお、そのことは次ぎに説明される。
【0083】
図34は、パケット・ディスパッチャ・ユーザ・インタフェースのマッチ仕様パネルの一実施形態である。マッチ仕様パネルは、図34に示されるリスト図として実現される。リスト図は、全てのマッチ仕様(マッチスペック)、即ち、パケットをパケット処理モジュールに対してマップするパケット・ディスパッチ規則を示す。ユーザは、複数のマッチ仕様(マッチスペック)をパケット・タイプ、プロセッサ、引数又はコンテキストに従って、対応の列ヘッディング上をクリックすることによりソート(分類)することができる。同じ列を2度目にクリックすることにより、列は反対方向にソートされる。ユーザは、リスト図のフォーマットを、「図(View)」を右クリック及び選択することにより変えることができる。
【0084】
マッチ仕様(マッチスペック)を作成するため、ユーザは、プロセッサ、パケット・タイプ又はパケット・コンテキストをプロセッサ及びパケット選択パネルからマッチ仕様パネル内の空の行上へドラッグし得る。この動作は、新しいマッチ仕様(マッチスペック)を生成し、それは、ドロップされたアイテムを含む。他方、ユーザがアイテムをプロセッサ及びパケット選択パネルからマッチ仕様パネル内のマッチ仕様(マッチスペック)上へドラッグする場合、マッチ仕様(マッチスペック)は、ドロップされたアイテムを組み込むことにより修正されるであろう。ユーザはまた、要素を右又はダブルクリックして、マッピング特性ダイアログ・ボックスを持ち出すことができる。
【0085】
ユーザは、図35に示される「マッチ仕様特性(Match Spcfication Property)」ダイアログ・ボックスを呼び出すことにより、即ちそれらをダブルクリックすることによりマッチ仕様(マッチスペック)を編集し得る。代替として、ユーザは、マッチ仕様(マッチスペック)上を右クリックして、「特性…(Property...)」コマンドのポップメニュー及び選択を呼び出し得る。「マッチ仕様特性」ダイアログ・ボックスを介して、ユーザは、マッチ仕様のプロセッサ、引数及びパケット・タイプをセットし得る。更に、ユーザは、「追加…(Add...)」及び「削除(Delete)」ボタンを用いて、パケット・コンテキスト値の対をマッチ仕様に挿入し得る。ユーザがコンテキスト値の対を有する、マッチ仕様のパケット・タイプを変える場合、エディタは、いずれの無効の対、即ち、新しいパケット・タイプに対して有効でない対を取り除くであろう。
【0086】
最後に、ユーザは、マッチ仕様パネル内のマッチ仕様(マッチスペック)を右クリックし、そして「削除」コマンドをポップアップ・メニューから選択することによりそのマッチ仕様(マッチスペック)を削除し得る。代替として、ユーザは、単純にマッチ仕様(マッチスペック)を選択し、そして削除キーを押してもよい。
【0087】
テキスト抽出ユーザ・インタフェース ユーザは、テキスト抽出ユーザ・インタフェースを介してテキスト抽出モジュール(TEM)を訓練し得る。ユーザ・インタフェースは、ユーザがテキスト抽出規則、例えば、収集、エンティテイ、トークン、正規表現、プロダクション及びフォーマットを作成し、修正し、削除するのを可能にする。テキスト抽出ユーザ・インタフェースの1つの便益は、それによりユーザがそれらがリアルタイムで作成し、修正し、又は削除するいずれの規則の衝撃を直ちに「見る」のを可能にすることである。ユーザ・インタフェースは、ダイアログ・バー、規則パネル、注釈パネル及びグリッド・パネルから成る。これらの構成要素のそれぞれが更に詳細に説明されるであろう。
【0088】
図36に示されるテキスト抽出ユーザ・インタフェース・ダイアログ・バーは、ユーザがユーザ・インタフェース制御の頂部に存在し、そして次の機能を実行するのを可能にする10個のボタンを含む。
・パケット・コンテンツの「ページ」をナビゲートする機能
・ファイル・モードからパケット・モードへ切り換える機能
・規則をテキスト抽出モジュール規則データベースから再ロードする機能
・現在のセッション中に行われる変化をセーブする機能
・パケット・モードからファイル・モードへ切り換える機能、及び
・ヘルプを呼び出す機能。
【0089】
最初の4個のボタン、即ち、矢印ボタンにより、ユーザがパケット・コンテンツの最初の「ページ」、前の「ページ」、次の「ページ」、及び最後の「ページ」へ行くのを可能にする。パケット・コンテンツは、パケット・データベースから読み出される。(パケット・データベースは、選択された「パケットをデータベースにセーブする」処理オプションを有するツールを動作させることにより占拠される。)「ページ」は、注釈ペイン(pane)に表示され、そして規則ペインにおいて現在選択されているエンティテイの識別されたトークン及びプロダクションを表示することにより注釈される。第5のボタン、即ち「パケットを再ロードする(Reload Packet)」ボタンは、注釈ペインをファイル・モードからパケット・モードへ切り換える、即ち注釈ペインにおけるテキストは、パケット・データベースから読み出される。第6のボタン、即ち「データベースを再ロードする(ReloadDB)」ボタンは、テキスト抽出規則をテキスト抽出規則リポジトリから再ロードする。ユーザは、現在の変化が廃棄されるであろうことを警告されるであろう。第7のボタン、即ち「データベースをセーブする(SaveDB)」ボタンは、テキスト抽出規則に対する変化をコミット(commit)し、そしてそれらをテキスト抽出規則リポジトリへ書き込む。第8のボタン、即ち「ファイルを開ける(OpenFile)」ボタンは、注釈ペインをパケット・モードからファイル・モードへ切り換える、即ち、注釈ペインにおけるテキストは、ユーザによって選択されたファイルから読み出される。第9のボタン、即ち「〜について(About)」ボタンは、テキスト抽出ユーザ・インタフェースについての関連情報を表示する。最後に、第10のボタン、即ち「ヘルプ(Help)」ボタンは、テキスト抽出ユーザ・インタフェース・ヘルプアプリケーションを起動する。
【0090】
規則パネルは、図37に示されるように階層トリー図内のテキスト抽出規則を表示する。トリー・ノードは、収集、エンティテイ、トークン、正規表現、プロダクション又はフォーマットのうちのいずれかであり得る。これらのノードの1つを表すアイコンは、ボックスで囲まれた黒の大文字である。その文字は、ノード・タイプの最初の文字、例えば、収集に対するC、エンティテイに対するE等に対応する。更に、どの収集がどのパケット・コンテンツを処理するかを指定するノードがまた、トリー内に存在する。ボックスで囲まれた黒丸はこれらのノードを表す。
【0091】
ノードのテキストはそのタイプに依存する。収集ノードに対するテキストは収集の名前であり、それに括弧内にあるその省略形が続く。エンティテイ・ノードに対するテキストはエンティテイの名前であり、それに括弧内にあるその省略形が続く。同様に、トークン・ノードに対するテキストはトークンの名前であり、それに括弧内にあるその省略形が続く。しかしながら、トークンが前に識別されたエンティテイに言及する場合、参照エンティテイの名前及び省略形が続くテキスト「エンティテイ(Entity.)」は、四角括弧により囲まれ、そしてトークン・テキストへ添付される。正規表現ノードのテキストは正規表現自体であり、一方、プロダクション・ノードのテキストはプロダクションの文法である。フォーマット・ノードのテキストはフォーマットのラベルの名前である。最後に、「収集がパケット・コンテンツを処理する(collection processes packet content)」ノードのテキストは、ピリオドにより分離された、パケット・タイプ及びコンテンツ・ラベルである。
【0092】
ユーザは、規則を作成すること、規則を削除すること、規則をコピーすること、又は規則を移動することのような、規則パネル内の幾つかの操作を実行することができる。ユーザは、それらのノードをドラッグしてそれを別のノード上にドロップすることにより規則をコピー又は移動することができる。ユーザがノードを1つの収集からドラッグし、そしてそれを異なる収集の中にドロップする場合、ノード及びその系統がコピーされる。ユーザがノードを1つの収集からドラッグし、それを異なる位置であろうとも同じ収集の中にドロップする場合、ユーザは、彼/彼女がノード及びその子をコピーし又は移動するのを欲するかどうかについて、ポップアップ・ダイアログを介して、促される。ユーザはマウスがノード上にない間に規則パネルを右クリックする場合、ユーザが収集を生成するのを可能にするポップアップ・メニューが現れる。しかしながら、ユーザは、マウスがノード上にある間に右クリックする場合、ユーザが「選択された」ノードを削除し、又は子ノードを作成するのを可能にするポップアップ・メニューが現れる。例えば、ユーザは、マウスがエンティテイ上にあるとき右クリックする場合、ユーザがエンティテイを削除し、又はトークンを生成し、あるいはプロダクションを作成するのを可能にするポップアップ・メニューが現れる。ユーザは、マウスが正規表現ノード上にあるとき右クリックする場合、ユーザが正規表現を削除するのみを可能にするポップアップ・メニューが現れる。
【0093】
注釈パネルは、図38に示されるようにスクロール可能な図であり、そのスクロール可能な図は、現在のエンティテイのトークン及びプロダクションを識別することによりサンプル・テキストを注釈する。規則図の中の現在選択されているアイテムがエンティテイである場合、現在のエンティテイは、選択されたアイテムである。規則図の中の現在選択されているアイテムがエンティテイでない場合、現在のエンティテイは、その子孫が選択されたアイテムの中にあるエンティテイである。サンプル・テキストは、テキスト・ファイルから読み出されるか、又はパケット・リポジトリ内のデータからロードされ得る。サンプル・テキストが多くのラインを含む場合、注釈ペインは、異なるページの中の注釈されたテキストを表示する。ユーザは、ダイアログ・バー上のボタン「ダイアログ・バー」を介してページをナビゲートし得る。
【0094】
サンプル・テキストの各ラインに対して、現在のエンティテイのトークン及びプロダクションが注釈される。トークン及びプロダクションは、テキストの上及びその下のそれぞれの水平方向の括弧の片方により識別される。トークンは更に、それらの省略された名前を括弧の頂部上に表示することにより注釈される。省略形がトークンの上で適合することができない場合、星印が代わりに表示される。マウスを星印の上で一時的に停止させることにより、ユーザは、省略形を表示するヒント・ウインドウを呼び出すであろう。同様の要領で、プロダクションは更に、選択されたエンティテイの名前を括弧の下に表示することにより注釈される。マウスをエンティテイの名前の上で一時的に停止することにより、ユーザは、プロダクションのフォーマット・ラベル及び値を表示するヒントを呼び出すであろう。
【0095】
ユーザは、規則をグリッド・パネルを介して生成、修正及び削除することができる。グリッド・パネルは、図39に示されるように複数の行及び列を含む。グリッドの最初の行は、規則図の中で現在選択されている、ノードのコンテンツを表示する。グリッドの中間の行は、現在選択されているノードの同胞である、ノードのコンテンツを表示する。星印
【0096】
【表2】
【0097】
がマークされている、グリッドの最後の行は、空であり、そしてユーザが新しい規則を作成するのを可能にする。列並びに列ヘッダの数は、現在選択されているノードのタイプに依存する。
【0098】
新しい規則を作成するため、ユーザは、適切な情報を最後の行の各列に入れ、そしてカーソルを異なる行へナビゲートしなければならない。ユーザは、グリッド上のいずれの列のコンテンツを編集することができる。現在編集されつつある行には記号がマークされる。行に対する変化をコミットするため、ユーザは、カーソルを異なる行へマウス又は矢印キー
【0099】
【表3】
【0100】
によりナビゲートしなければならない。規則を削除するため、ユーザは、最も左の(編集できない)列上をクリックすることにより行を選択し、そして削除キーを押さなければならない。ユーザが確認すると直ちに、行(及び対応する規則)は削除されるであろう。
【0101】
パケット・エクスポート・ユーザ・インタフェース ユーザは、パケット・エクスポート・モジュール(PEM)をパケット・エクスポート・ユーザ・インタフェースを介して訓練し得る。ユーザ・インタフェースは、ユーザがパケット・エクスポート規則、例えば、パケット・コンテンツ/コンテキスト対データベース・テーブル・フィールド間でマッピングすることを作成、修正及び削除するのを可能にする。パケット・エクスポート・ユーザ・インタフェースの1つの便益は、それによりユーザがパケット・エクスポート規則を意味のある要領で視覚化するのを可能にすることである。ユーザ・インタフェースは、2つのパネル、即ち選択パネル及びグラフィックス・パネル、並びにステータス・バーから成る。各パネルは更に詳細に説明されるであろう。更に、ユーザが知識リポジトリ・スキーマをパケット・エクスポート規則データベースにインポートするのを可能にする制御が説明されるであろう。
【0102】
パケット・コンテンツ/コンテキストをデータベース・テーブル・フィールドに対してマッピングする前に、ユーザは、データベース・スキーマをパケット・エクスポート規則データベースに知識リポジトリ・スキーマ・インポート制御を介してインポートする。インポート制御は、2つのボタン及び2つのペインを含む。知識リポジトリ・スキーマをパケット・エクスポート規則データベースにインポートするため、ユーザは、インポート・ボタンを押すべきである。図40に示されるように、知識リポジトリのテーブルが左ペインに表示され、一方現在選択されているテーブルのフィールドが右ペインに表示される。ユーザは、適切なテーブルをマウス又は矢印キーを介して選択することによりいずれのテーブルのフィールドをブラウズし得る。データベース・テーブル及びフィールドは、ステータス・アイコンにより処理され得る。新しいテーブル及びフィールド、即ち、前のインポート中に知識リポジトリの中に存在しなかったそれらのものは、緑プラス・アイコンによりフラグを立てられる。使われていないテーブル及びフィールド、即ち、前のインポート以来知識リポジトリから削除されたそれらのものは、赤の文字「x」アイコンによりフラグを立てられる。修正されたフィールド、即ち、それらのタイプ及び/又は属性が前のインポート以来変化されたそれらのものは、黄色のチェックマーク・アイコンによりフラグを立てられる。使われていないテーブル及びフィールドの使われていないスキーマを削除するため、ユーザは、消去(purge)ボタンを押すべきである。
【0103】
選択パネル(selection panel)は、図41に示されるようにトリー図の中の2つのリストを表示する。最初のリストは、システムに対して知られているパケット、即ち、パケット辞書に登録されているパケットを表示する。第2のリストは、知識リポジトリ・テーブルを表示する。グラフィックス・パネルの中のパケット又はテーブルを表示するため、ユーザは、トリー図の中の対応するアイテムをダブルクリックすべきである。ユーザがパケットを1つ又はそれより多いテーブルに対してマップする規則を有するそのパケットをダブルクリックする場合、マップされたテーブルはまた、マッピング規則と共に、グラフィックス・パネルの中に表示される。
【0104】
図42に示されるようにグラフィックス・パネルは、その上でパケット・エクスポート規則が作成され、修正され又は削除され得るキャンバスである。パケットはウインドウとして表される。パケット・タイプは、ウインドウのタイトル・バーの中に表示される。コンテンツ及びコンテキスト・ラベルは、ウインドウの内側にリストされる。コンテンツ及びコンテキスト・ラベルは、異なるアイコンにより進められる。類似の要領で、知識リポジトリ・テーブルはウインドウとして表される。テーブルの名前は、ウインドウのタイトル・ボードの中に表示され、そしてテーブル・フィールドは、ウインドウの内側にリストされる。
【0105】
パケット又はテーブルをキャンバスに加えるため、選択パネルの中の対応するアイテム上をダブルクリックする。ユーザが、パケットを1つ又はそれより多いテーブルに対してマップする規則を有するそのパケットをダブルクリックする場合、マップされたテーブルはまた、マッピング規則と共に、グラフィックス・パネルの中に表示される。パケット又はテーブルをキャンバスから取り除くため、パケット又はテーブル・ウインドウの上右手隅の中の小さい「x」ボタン上をクリックする。パケットがキャンバスから取り除かれる場合、それに対してマップされる全ての規則も同様に取り除かれる。テーブル・ウインドウは、それらに対してマップされる規則が無い限りのみ取り除かれることができる。従って、1つのマップは、最初に、テーブル・ウインドウに対してマップされているパケット・ウインドウを取り除く。ウインドウ及び規則をキャンバスから取り除くことは、それらを削除するものではない。対応するパケット・エクスポート規則は、依然パケット・エクスポート規則データベースの中に存在する。
【0106】
パケットとデータベース・テーブルとの間の新しいパケット・エクスポート(マッピング)規則を作成するため、ユーザは、最初に、パケット・ウインドウの中のコンテンツ又はコンテキストの上をクリックすることによりそのコンテンツ又はコンテキストを選択し、次いでデータベース・テーブル・ウインドウの中のフィールドの上をクリックすることによりそのフィールドを選択しなければならない。一旦前述の手順が実行されると、パケット・エクスポート・ユーザ・インタフェースは、マッピング規則を表すため、2つの選択されたアイテム間にラインを引く。最近選択されたコンテキスト又はコンテンツ・ラベルを持つ別のエクスポート規則を作成するため、パケット・ウインドウの中のラベルをダブルクリックし、次いで新しいデータベース・テーブル・フィールドを選択する。
【0107】
ユーザがマッピング規則即ちラインの上で左又は右マウス・ボタンをクリックするとき、そのラインは、規則が選択されたことを示すため太く表示される。これは、ユーザが規則の属性を変えるか、又はそれを削除するかを可能にする。規則が生成されるとき、それらの拡張方法は、「レベル」にセットされ、そしてパケット・コンテンツ/コンテキストは、記録セットを知識リポジトリにエクスポートするため必要とされない。しかしながら、規則がマップする対応するパケット及びデータベース・テーブルが既に規則を有する、即ち、ラインが既にそれらの間に引かれている場合、拡張レベルは、既存の規則のそれにセットされる。一実施形態において、規則の拡張方法が「レベル」であるその規則が1つの色で引かれ、これに対して、規則の拡張方法が「フル」であるその規則は異なる色で引かれる。ユーザがパケット及びデータベースをマップする規則の拡張方法を変えるとき、このパケットとデータベース・テーブルとの間の全規則の拡張方法が変えられる。最後に、ユーザがパケット・ウインドウ、データベース・テーブル・ウインドウ及び規則を除いて、キャンバス上の任意の位置を右クリックする場合、ユーザがマッピング規則をパケット・エクスポート規則データベースにセーブするのを可能にするポップアップ・メニューが現れる。
【0108】
リポジトリ 次のセクションにおいて、D2Kデータベースは、次の順序、即ち、インポート・フィルタ規則リポジトリ、パケット辞書リポジトリ、処理モジュール・リポジトリ、パケット・ディスパッチ規則、パケット・リポジトリ、テキスト抽出規則リポジトリ、パケット・エクスポート規則リポジトリ、メッセージ・ログ・リポジトリ及び知識ベースの順序で説明される。各データベースが簡単に記載される。
【0109】
一実施形態において、ユーザは、D2Kデータベースに格納されているデータを直接編集しない。代わりに、ユーザは、D2Kユーザ・インタフェースと対話し、次いでD2Kユーザ・インタフェースは、データベースのコンテンツを修正するであろう。
【0110】
インポート・フィルタ規則リポジトリ 動作(Action)テーブルは、パケット構成規則動作、即ち、データを無視する、データを無視し且つ新しいパケットを生成すること、新しいパケットを生成し且つデータをパケットの中にコンテンツとして挿入すること、データを現在のパケットの中にコンテンツとして挿入する、データを現在のパケットの中にコンテンツとして添付すること、及びデータを現在のパケットの中にコンテキストとして挿入することを格納する。
【0111】
フィールド・タイプ(FieldType)テーブルは、データ・フィールドの全体の及び省略形の名前を格納する。SGMLインポート・フィルタの場合、データ・フィールドは、要素又は属性のいずれかである。
【0112】
IDマップ系統(IdMap,_Lineage)テーブル及び作業空間(Workspace)テーブルは、データ構造のインポート及びパケット登録中にインポート・フィルタ規則により作成される。その系統テーブルは、コンテキストの承継(inheritance)を促進するため各ノード子孫のマップをキャッシュする。
【0113】
パケット・タイプ(PacketType)テーブル、コンテキスト・ラベル(ContextLable)テーブル及びコンテンツ・ラベル(ContentLabel)テーブルは、パケット構成規則により生成されるパケットのパケット・タイプ、コンテンツ・ラベル及びコンテキスト・ラベルを格納する。
【0114】
文書構造(DocumentStructure)テーブルは、データ・ソースの構造が格納され処理される一時的バッファである。
パケット構成(PacketConstruction)テーブルは、パケット構成規則を格納する。テーブル内のデータは、入力データ・ソースの構造をインポートするプロセスにより生成され、そしてインポート・フィルタ・ユーザ・インタフェースにより修正される。
【0115】
パケット辞書リポジトリ 一実施形態において、パケット辞書データベースは6個のテーブルから成り、その1つは、一時的作業空間である。主テーブルは、PacketType、ContentLabel、ContextLabel、PacketAllowsContent、及びPacketAllowsContextである。これらのテーブル内のデータは、合法のパケットのプロトタイプを指定する。幾つかの重要な(vital)D2K機能は、パケット辞書を用いる。例えば、D2K訓練ユーザ・インタフェースは、パケット辞書を用いて、リスト・ボックス選択を制限し、それによりユーザが有効でない訓練規則を発生するのを禁止し、一方パケット・ファクトリは、パケット辞書を利用して、合法のパケットのみが生成されることを保証する。更に、幾つかの他のデータベースは、図43に示されるようにパケット辞書テーブルへのリンクを含む。
【0116】
プロトタイプ登録(PrototypeRegistration)テーブルは作業空間であり、その作業空間は、パケット・プロトタイプを構成するため、幾つかのD2K構成要素により用いられる。次いで、パケット・プロトタイプは、パケット辞書を用いて登録される。
【0117】
パケット・タイプ(PacketType)テーブル、コンテキスト・ラベル(ContextLable)テーブル及びコンテンツ・ラベル(ContentLabel)テーブルは、合法のパケット・タイプ、コンテンツ・ラベル及びコンテキスト・ラベルをそれぞれ格納する。「パケットによるコンテンツの許可(PacketAllowsContent)」テーブル、及び「パケットによるコンテキストの許可(PacketAllowsContext)」テーブルは、どのコンテンツ及びコンテキスト・ラベルがどのパケットにおいて合法的であるかを指定する。
【0118】
パケット・モジュール・リポジトリ 処理モジュール・リポジトリは、登録された処理モジュールのリスト、並びにそれらを呼び出すため必要とされる情報を格納する。この情報は、プロセッサ(Processor)テーブルに格納される。更に、リポジトリは、どのパケットを各処理モジュールが生成することができるかを格納する。この情報は、「プロセッサにより登録されたコンテンツ(ProcessorRegisteredContent)テーブル、及び「プロセッサにより登録されたコンテキスト(ProcessorRegisteredContex)テーブルに格納される。一実施形態において、インポート・フィルタが処理モジュールでないにも拘わらず、このリポジトリは、どのパケットをインポート・フィルタが同様に生成することができるかを格納する。
【0119】
パケット・ディスパッチャ規則リポジトリ パケット・ディスパッチャ規則リポジトリはパケット・ディスパッチ規則を格納する。マッチ仕様(MatchSpec)は、マッチ仕様(MatchSpec)テーブル、及び「マッチ仕様によるコンテキストの所持(MatchSpecHasContext)」テーブルに格納される。作業空間(Workspace)テーブルは、パケット・ディスパッチャ・インタフェースにより用いられる一時的作業空間である。
【0120】
パケット・リポジトリ パケット・リポジトリは、パケットが継続され得るデータベースである。パケット・ディスパッチャは、パケットをリポジトリの中に存続させ、ユーザは、「パケットをデータベースにセーブする(Save Packet in Database)」チェックボックスをエグゼクティブ・ウェブ・ページ上にセットする。パケットは、4つのテーブル、即ち、パケット(Packet)テーブル、「パケットによるコンテンツの所持(PacketHasContent)」テーブル、「コンテンツによる値の所持(ContentHasValues)」テーブル、及び「パケットによるコンテキストの所持(PacketHasContext)」テーブルに格納される。
【0121】
テキスト抽出規則リポジトリはテキスト抽出規則を格納し、そのテキスト抽出規則スキーマが図44に示されている。トークンとエンティテイとの関係に注目されたい。全てのトークンは、その親エンティテイに対する関係を有する。直線はこの関係を示す。しかしながら、トークンが1つ又はそれより多い正規表現から成り得て、又はそれらが前に4つのエンティテイであり得ることを思い出されたい。トークンが後者のケースに入る場合、オプションの関係、即ち曲線は、非ヌルであり、そして前に見つけられたエンティテイを参照するであろう。
【0122】
収集(collection)は1つ又はそれより多いエンティテイを有するので、エンティテイは1つ又はそれより多いトークンを有し、トークンは1つ又はそれより多い正規表現等を有し、これらの1対多の関係を実現する仕方に関して判断がなされる。2つのコマンド表示が図45に示されている。これらの表示を説明するため、トークンと正規表現エンティテイとを考えて見る。トークンは、1つ又はそれより多い正規表現を有し得て、例えば、文書ボリューム・トークンは、「FIN」、「(MM)|(AMM)」及び「(WM)|(WDM)」のような正規表現を有し得る。前述の例は、図45のオプションAにより示されるように1対多のマッピングを意味する。代替のマッピングは、各正規表現が図45のオプションBに示されるように1つのトークンと関連付けられることである。第1のアプローチの利点は、正規表現が異なるトークンにより再使用され得ることであるが、これに対して、その欠点は、追加のデータベース・テーブルがその関係を格納するため必要とされることである。第2のアプローチの利点は、関係を別々のデータベース・テーブルに格納する必要がないことであり、これに対して、このアプローチの欠点は、データベースが、同じ正規表現が2つ以上のトークンにより参照されるため複写を含むことである。非技術的制約のため、本発明者は、後者のアプローチ、即ちオプションBを選定する。
【0123】
ビン拡張方法(BinExpansionMethod)テーブルは、ビン拡張タイプ、即ち、「レベル」及び「フル(全)」の合法の値を含むルックアップ・テーブルである。
プロトタイプ(Prototype)テーブルは作業空間であり、そしてテキスト抽出モジュールは、その作業空間を用いて、それが生成することができるパケットのプロトタイプを構成する。
【0124】
Collection、Entity、Token、RegExpr、Production及びFormatの各テーブルは、収集、エンティテイ、トークン、正規表現、プロダクション及びフォーマットのそれぞれを格納する。
【0125】
EntityNameテーブル及びTokenNameテーブルは、エンティテイ及びトークンの名前を格納する。エンティテイ(Entity)及びトークン(Token)の両方のテーブルは、これらのテーブルからのエンティテイ及びトークンのそれぞれを参照する。これらの名前は、収集によるエンティテイの名前の正確な再使用及びエンティテイによるトークン名の正確な再使用をサポートするためそれら自体のテーブルに分離される。
【0126】
CollectionProcessesPacketContentテーブルは、どのパケット・コンテンツがどの収集により処理されるかのリストを格納する。より正確であるため、テキスト抽出モジュールは、指定されたパケット・コンテンツの値を、規則の指定された収集に従って処理する。
【0127】
パケット・エクスポート規則リポジトリ パケット・エクスポート規則リポジトリは、パケット・エクスポート規則を格納する。パケット・エクスポート・モジュールの挙動はこれらの規則により統治され、それらの規則はパケット・コンテンツ及びコンテキストをデータベース・テーブルのフィールドに対してマップする。パケット構成規則を訓練する前に、入力データの構造がその輪郭を描かれ、そしてインポート・フィルタ規則リポジトリにインポートされなければまさにならないように、知識リポジトリのスキーマは、パケット・エクスポート規則を訓練する前に、解析され、そしてパケット・エクスポート規則リポジトリにインポートされなければならない。
【0128】
拡張方法(ExpansionMethod)テーブルは、ビン拡張タイプ、即ち、「レベル」及び「フル」の合法の値を含むルックアップ・テーブルである。
BufDBFieldテーブル及びBufDBTableテーブルは一時的バッファであり、その一時的バッファに知識ベースのスキーマが、格納されそして処理される。これらのテーブル内のデータは、どのテーブル及び/又はフィールドが知識リポジトリ・スキーマの最後のインポート以来追加されたか、又は削除されたか、あるいは修正されたかを決定するためDBTableテーブル及びDBFieldテーブル内のデータと比較される。
【0129】
DBTableテーブル及びDBFieldテーブルは、知識ベースのスキーマを格納する。これらのテーブルの両方は、スキーマ・インポート同士の間の差のフラグを立てるため、IsAdddedフィールド及びIsRemovedフィールドを有する。更に、DBFieldテーブルはIsModifiedフィールドを同様に有する。
【0130】
MapPacketType2DBTableテーブル及びMapPacketInfo2DBFieldテーブルは、パケット・エクスポート・マッピング規則を格納する。MapPacketType2DBTableは、どのパケットがどのデータベース・テーブルに対してマップされるかのリストを格納する。更に、値拡張方法はこのテーブルに格納される。MapPacketInfo2DBFieldテーブルは、どのパケット・コンテンツ/コンテキストがどのデータベース・テーブル・フィールドに対してマップされるかのリストを格納する。更に、コンテント値又はコンテキスト値が記録セットをエクスポートするため要求されるか否かを指定するフラグが、このテーブルに格納される。
【0131】
メッセージ・ログ・リポジトリ D2Kは、メッセージ・ログ・リポジトリの中のエラー、警告及びデバッグ・メッセージを持続させる。メッセージ・ログは3つのテーブルを有する。ModuleTypeテーブルは、メッセージを生成することができるD2K構成要素のリストを格納する。Severity(重大さ)テーブルは、致命的、エラー、警告、メッセージ及びデバッグのようなエラーのクラスのリストを格納する。最後に、MessageLog(メッセージ・ログ)テーブルはメッセージを格納する。
【0132】
知識ベース 知識リポジトリのスキーマは、各D2Kアプリケーションに対して特有である。パケット・エクスポート・モジュールを訓練する前に、知識リポジトリ・スキーマは、パケット・エクスポート規則リポジトリにインポートされる。一旦インポートされると、ユーザは、パケット・コンテンツ及びコンテキストの値から成る記録セットをエクスポートするようパケット・エクスポート・モジュールを訓練する。
ハードウエア及び操作環境
図46は、本発明のどの例示実施形態が実現され得るかに関連したコンピュータ化システムのブロック図である。コンピュータ90は、プロセッサ92、ランダム・アクセス・メモリ(RAM)94、読み出し専用メモリ(ROM)96、及びハード・ディスク・ドライブ、フロッピー・ディスク(登録商標)ドライブ(その中にフロッピー・ディスク(登録商標)を挿入することができる。)、光ディスク・ドライブ、テープ・カートリッジ・ドライブ等のような1つ又はそれより多い記憶装置98を含む。RAM94及びROM96は、コンピュータのメモリを集約的に指している。メモリ、ハード・ドライブ、フロッピー・ディスク(登録商標)、CD−ROM等は、コンピュータ可読媒体のタイプである。コンピュータ可読媒体は、プロセッサ92により実行される命令を格納する。命令は、プロセッサ92にバスを介して与えられる。本発明は、コンピュータ90のいずれかのタイプに特に限定されない。そのようなコンピュータの構成及び動作は、当該技術では周知である。
【0133】
一実施形態においては、データ/知識(D2K)翻訳機が、コンピュータ90のようなコンピュータ上で実行するソフトウエアの中に組み込まれている。一実施形態においては、D2Kシステムは、C++コンピュータ言語を用いてソフトウエアで実現され、そして構成要素オブジェクト・モデル(COM)構成要素の集合としてパッケージされ、それは、ウェブ・ブラウザでインスタンス化(例示)され、且つHTMLウェブ・ページに埋め込まれたマイクロソフト・ビジュアル・ベーシック(Microsoft Visual Basic)(登録商標)及びJava(登録商標)スクリプトを介して接続される。しかしながら、当業者は、他の互換性のあるハードウエア及びプログラミング言語を、本発明の範囲から外れることなく採用し得ることを認めるであろう。
【0134】
特定の実施形態が本明細書で説明され記載されたが、同じ目的を達成するため計算されたいずれの構成が、示された特定の実施形態に代わり得ることが当業者に認められるであろう。この出願は、本発明のいずれの適応又は変形をカバーすることを意図するものである。従って、本発明は特許請求の範囲及びその均等物によってのみ制限されることを明白に意図するものである。
【図面の簡単な説明】
【図1】
図1Aは、本発明の一実施形態に従ったデータ/知識翻訳システムの高レベル・ブロック図である。
図1B、図1C及び図1Dは、データ/知識(D2K)翻訳システムの代替実施形態の高レベル・ブロック図である。
【図2】
図2は、図1に示されるデータ/知識翻訳機(D2K)システムを実行するための物理的アーキテクチャの例示実施形態のブロック図である。
【図3】
図3は、本発明の一実施形態に従ったD2K翻訳機を訓練するプロセスのフロー・チャートである。
【図4】
図4は、本発明の一実施形態に従った、D2K翻訳機を有する知識ベースを構成するためデータ・ソースを解析するプロセスのフロー・チャートである。
【図5】
図5は、図2に示されるパケットのためのパケット・データ構造の一実施形態のより詳細な図である。
【図6】
図6は、図2に示されるインポート・フィルタのような、本発明の一実施形態のインポート・フィルタに印加されることになる例示ソース・データを示す。
【図7】
図7は、図6の例示ソース・データに適用されることなる例示インポート・フィルタ規則を示す。
【図8】
図8は、図7に示される例示インポート・フィルタ規則を図6に示されるソース・データに適用することにより生成される第1のパケットの例示一実施形態を示す。
【図9】
図9は、図7に示される例示インポート・フィルタ規則を図6に示されるソース・データに適用することにより生成される第2のパケットの例示一実施形態を示す。
【図10】
図10は、図7に示される例示インポート・フィルタ規則を図6に示されるソース・データに印加することにより生成される第1のパケットの代替の例示実施形態を示す。
【図11】
図11は、図2のパケット・ディスパッチャにより使用の例示で親マッチ仕様規則を図示する。
【図12】
図12は、図2のテキスト抽出モジュールにより処理されることになるサンプル入力テキストである。
【図13】
図13は、テキスト抽出モジュールの集合の階層表示である。
【図14】
図14は、例示入力テキストの中でテキスト抽出モジュールが図13の例示テキスト抽出規則により定義されるようなEquipmentNumber(装置番号)エンティテイを識別したその例示入力テキストである。
【図15】
図15は、例示入力テキストの中でテキスト抽出モジュールが図13の例示テキスト抽出規則により定義されるようなDocumentReference(文書基準)エンティテイを識別したその例示入力テキストである。
【図16】
図16は、ビンの中にソートされたDocumentReferenceプロダクション(図13の例示テキスト抽出規則により定義されたように)に対するトークン値を示す。
【図17】
図17は、図16のビンについての全拡張を実行することにより形成されたトークン値のセットを示す。
【図18】
図18は、マッチされたプロダクションのボリューム及びブックマーク・フォーマットを図17のトークン値のセットに適用することから生じるフィールド・ラベル及び値を示す。
【図19】
図19は、図18のフィールド・ラベル及び値から作成されるパケットの例示実施形態を示す。
【図20】
図20は、サンプル入力テキストの中でテキスト抽出モジュールが図13の例示テキスト抽出規則により定義されるようなFaultエンティテイを識別したそのサンプル入力テキストである。
【図21】
図21は、TemFaultEntityパケットとTemDocumentReferenceEntity及びTemEquipmentNumberEntityパケットとの関係を図示する。
【図22】
図22は、サンプル知識ベースに対してパケットがエクスポートされるそのサンプル知識ベースのデータベース・スキーマを図示するブロック図である。
【図23】
図23は、例示エンティテイを例示テーブルに対してマップするパケット・エクスポート規則の図的表示である。
【図24】
図24は、図19のTemDocumentReferenceEntityパケットをエクスポートした後の例示テーブルである。
【図25】
図25は、図19のパケットをエクスポートした後の5個の例示テーブルを示す。
【図26】
図26は、ウェブ・エグゼクティブに対するユーザ・インタフェースの例示実施形態である。
【図27】
図27は、インポート・フィルタ・エディタの一実施形態のスクリーン・キャプチャである。
【図28】
図28は、インポート・フィルタ・エディタの検索ダイアログ・ボックスの一実施形態である。
【図29】
図29は、インポート・フィルタ・エディタのパケット構成特性ダイアログ・ボックスの一実施形態である。
【図30】
図30は、インポート・フィルタ・エディタの「Next(次の)」メニューの一実施形態である。
【図31】
図31は、インポート・フィルタ・エディタの「Bookmark(ブックマーク)」メニューの一実施形態である。
【図32】
図32は、インポート・フィルタ・ユーザ・インタフェースのモードレスの「Current Packet Information(現在のパケット情報)」の一実施形態である。
【図33】
図33は、パケット・ディスパッチャ・ユーザ・インタフェースのプロセッサ及びパケット選択パネルの一実施形態である。
【図34】
図34は、パケット・ディスパッチ・ユーザ・インタフェースのマッチ仕様パネルの一実施形態である。
【図35】
図35は、パケット・ディスパッチ・ユーザ・インタフェースの一実施形態の「マッチスペックification Propertes(マッチ仕様特性)」ダイアログ・ボックスである。
【図36】
図36は、テキスト抽出ユーザ・インタフェースのダイアログ・バーの一実施形態である。
【図37】
図37は、規則パネルの一実施形態のスクリーン・キャプチャである。
【図38】
図38は、注釈パネルの一実施形態のスクリーン・キャプチャである。
【図39】
図39は、グリッド・パネルの一実施形態のスクリーン・キャプチャである。
【図40】
図40は、知識リポジトリ・スキーマ・インポート制御の一実施形態のスクリーン・キャプチャである。
【図41】
図41は、パケット・エクスポート選択パネルの一実施形態のスクリーン・キャプチャである。
【図42】
図42は、グラフィックス・パネルの一実施形態のスクリーン・キャプチャである。
【図43】
図43は、パケット、パケット辞書、処理モジュール及びパケット・ディスパッチ規則データベース間の関係を図示するブロック図である。
【図44】
図44は、テキスト抽出規則データベースの一実施形態に対するスキーマのエンティテイ関係図である。
【図45】
図45は、「1対多」の関係を表す2つの方法を図示する。
【図46】
図46は、それに関連して本発明の例示実施形態が実行され得るコンピュータ化システムのブロック図である。
Claims (25)
- コンピュータ化システムによりデータの処理を統治する、ユーザによって指定された規則を格納する少なくとも1つのリポジトリと、
前記規則に従ってデータを処理し且つ当該データから知識を生成する少なくとも1つの処理モジュールと
を備えるコンピュータ化システム。 - 前記少なくとも1つのリポジトリ及び前記少なくとも1つの処理モジュールを制御するシステム・エグゼクティブを更に備える、請求項1記載のコンピュータ化システム。
- ユーザがユーザによって指定された規則を作成し、修正し、削除するのを可能にするユーザ・インタフェースを更に備える、請求項1記載のコンピュータ化システム。
- 前記ユーザによって指定された規則はパケット構成規則である、請求項3記載のコンピュータ化システム。
- 前記ユーザによって指定された規則はテキスト抽出規則である、請求項3記載のコンピュータ化システム。
- 前記ユーザによって指定された規則はパケット・エクスポート規則である、請求項3記載のコンピュータ化システム。
- 前記ユーザによって指定された規則はパケット・ディスパッチ規則である、請求項3記載のコンピュータ化システム。
- 前記少なくとも1つの処理モジュールはテキスト抽出モジュールである、請求項1記載のコンピュータ化システム。
- 前記少なくとも1つの処理モジュールはパケット・エクスポート・モジュールである、請求項1記載のコンピュータ化システム。
- データを中立フォーマットに変換するインポート・フィルタを更に備える、請求項1記載のコンピュータ化システム。
- 知識を知識リポジトリにエクスポートするエクスポート・モジュールを更に備える、請求項1記載のコンピュータ化システム。
- データを知識に翻訳する、コンピュータ化された方法において、
データを知識に翻訳するコンピュータ化システムの挙動を統治するためユーザによって指定された規則を設けるステップと、
データを前記規則に従って処理して、知識を生成するステップと
を備えるコンピュータ化された方法。 - 既存の処理構成要素を修正することなしに、追加の規則に従ってデータを処理するステップを更に備える、請求項12記載のコンピュータ化された方法。
- 前記ユーザによって指定された規則はパケット構成規則である、請求項12記載のコンピュータ化された方法。
- 前記ユーザによって指定された規則はパケット・ディスパッチ規則である、請求項12記載のコンピュータ化された方法。
- 前記ユーザによって指定された規則はテキスト抽出規則である、請求項12記載のコンピュータ化された方法。
- 前記ユーザによって指定された規則はパケット・エクスポート規則である、請求項12記載のコンピュータ化された方法。
- データを規則に従って処理する前記ステップは更に、テキストを前記データから抽出するステップを備える、請求項12記載のコンピュータ化された方法。
- データを規則に従って処理する前記ステップは更に、知識を知識リポジトリにエクスポートするステップを備える、請求項12記載のコンピュータ化された方法。
- データを規則に従って処理する前記ステップは更に、データを中立フォーマットに変換するステップを備える、請求項12記載のコンピュータ化された方法。
- コンピュータ可読媒体に格納され、データを知識に翻訳する方法を実行するコンピュータ実行可能命令を有するコンピュータ可読媒体において、
前記のコンピュータ化された方法は、
データを、非構造化された形式で受け取るステップと、
前記データを中立形式に変換するステップと、
ユーザによって指定された規則に従ってデータを処理して、前記データを中立形式から知識に翻訳するステップと、
前記知識を知識リポジトリにエクスポートするステップと
を備える、コンピュータ可読媒体。 - データを中立形式に変換する前記ステップは、ユーザによって指定されたパケット構成規則を前記データに適用するステップを備える、請求項21記載のコンピュータ可読媒体。
- ユーザによって指定された規則に従ってデータを処理する前記ステップは、ユーザによって指定されたパケット・ディスパッチ規則を前記データに適用して、前記パケットをパケット処理モジュールにルート付けするステップを備える、請求項21記載のコンピュータ可読媒体。
- ユーザによって指定された規則に従ってデータを処理する前記ステップは、ユーザによって指定されたテキスト抽出規則を前記データに適用するステップを備える、請求項21記載のコンピュータ可読媒体。
- データを知識リポジトリにエクスポートするステップは、ユーザによって指定されたパケット・エクスポート規則をデータに適用するステップを備える、請求項21記載のコンピュータ可読媒体。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/522,483 US7096210B1 (en) | 2000-03-10 | 2000-03-10 | Trainable, extensible, automated data-to-knowledge translator |
PCT/US2001/007652 WO2001069527A2 (en) | 2000-03-10 | 2001-03-09 | Trainable, extensible, automated data-to-knowledge translator |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004502993A true JP2004502993A (ja) | 2004-01-29 |
Family
ID=24081047
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001567526A Withdrawn JP2004502993A (ja) | 2000-03-10 | 2001-03-09 | 訓練可能で拡張可能な自動化データ/知識翻訳機 |
Country Status (7)
Country | Link |
---|---|
US (1) | US7096210B1 (ja) |
EP (1) | EP1323129A2 (ja) |
JP (1) | JP2004502993A (ja) |
CN (1) | CN1650327A (ja) |
AU (1) | AU2001245578A1 (ja) |
CA (1) | CA2402919A1 (ja) |
WO (1) | WO2001069527A2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009525003A (ja) * | 2006-01-26 | 2009-07-02 | ソニー株式会社 | ユーザにデイリーズ(dailies)および編集済みビデオを提供するための方法およびシステム |
Families Citing this family (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8037193B2 (en) * | 1999-12-24 | 2011-10-11 | Telstra Corporation Limited | Virtual token |
WO2001077885A1 (en) * | 2000-04-10 | 2001-10-18 | Innovit Pty Ltd | Electronic catalogue |
WO2001086485A2 (en) * | 2000-05-09 | 2001-11-15 | Fair, Isaac And Company | Approach for re-using business rules |
US8510083B2 (en) * | 2003-07-31 | 2013-08-13 | The Boeing Company | Method, apparatus and computer program product for constructing a diagnostic network model |
US20050128952A1 (en) * | 2003-12-11 | 2005-06-16 | International Business Machines Corporation | Executing and implementing a service for establishing network connections |
US20050144287A1 (en) * | 2003-12-11 | 2005-06-30 | International Business Machines Corporation | Computer product and system for establishing network connections |
US7444328B2 (en) | 2005-06-06 | 2008-10-28 | Microsoft Corporation | Keyword-driven assistance |
US8631005B2 (en) | 2006-12-28 | 2014-01-14 | Ebay Inc. | Header-token driven automatic text segmentation |
US9014047B2 (en) * | 2007-07-10 | 2015-04-21 | Level 3 Communications, Llc | System and method for aggregating and reporting network traffic data |
US20090037360A1 (en) * | 2007-08-01 | 2009-02-05 | International Business Machines Corporation | Auto-Triggered Incremental Execution of Object Business Rules in Database Applications |
US8140991B2 (en) * | 2007-10-31 | 2012-03-20 | International Business Machines Corporation | Drag and drop rule topology |
WO2009132442A1 (en) | 2008-05-01 | 2009-11-05 | Sweeney Peter | Method, system, and computer program for user-driven dynamic generation of semantic networks and media synthesis |
US8504718B2 (en) | 2010-04-28 | 2013-08-06 | Futurewei Technologies, Inc. | System and method for a context layer switch |
US8452774B2 (en) | 2011-03-10 | 2013-05-28 | GM Global Technology Operations LLC | Methodology to establish term co-relationship using sentence boundary detection |
US8527441B2 (en) | 2011-03-10 | 2013-09-03 | GM Global Technology Operations LLC | Developing fault model from service procedures |
US9542376B2 (en) * | 2013-12-11 | 2017-01-10 | Sehul S. SHAH | System and method for creating, editing, and navigating one or more flowcharts |
US10740505B2 (en) | 2014-08-01 | 2020-08-11 | Riffyn, Inc. | Systems and methods for process design and analysis |
CN105205537B (zh) * | 2015-10-28 | 2017-08-01 | 武汉开目信息技术有限责任公司 | 一种基于本体的特征加工工艺知识表达推理的装置及方法 |
US10817494B2 (en) * | 2015-12-04 | 2020-10-27 | Riffyn, Inc. | Systems and methods for parsing data in order to form structured data tables |
CN105721842B (zh) * | 2016-04-08 | 2018-08-24 | 海尔优家智能科技(北京)有限公司 | 具有投影功能的机器人的投影方法、装置及机器人 |
US10592749B2 (en) | 2016-11-14 | 2020-03-17 | General Electric Company | Systems and methods for analyzing turns at an airport |
CN106918847A (zh) * | 2017-02-21 | 2017-07-04 | 武汉盛华伟业科技有限公司 | 一种基于知识库的井场录井解释方法及智能化解释系统 |
US10834336B2 (en) | 2018-01-29 | 2020-11-10 | Ge Aviation Systems Llc | Thermal imaging of aircraft |
US11018953B2 (en) | 2019-06-19 | 2021-05-25 | International Business Machines Corporation | Data center cartography bootstrapping from process table data |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS62206628A (ja) | 1986-03-07 | 1987-09-11 | Hitachi Ltd | 知識の蓄積方式 |
US5359509A (en) * | 1991-10-31 | 1994-10-25 | United Healthcare Corporation | Health care payment adjudication and review system |
JP2002517040A (ja) | 1998-05-27 | 2002-06-11 | マスターズ イノベーションズ エルティーディー オーワイ | 情報の機械翻訳に対する処理と方法 |
US6236977B1 (en) * | 1999-01-04 | 2001-05-22 | Realty One, Inc. | Computer implemented marketing system |
-
2000
- 2000-03-10 US US09/522,483 patent/US7096210B1/en not_active Expired - Lifetime
-
2001
- 2001-03-09 WO PCT/US2001/007652 patent/WO2001069527A2/en active Application Filing
- 2001-03-09 EP EP01918509A patent/EP1323129A2/en not_active Withdrawn
- 2001-03-09 AU AU2001245578A patent/AU2001245578A1/en not_active Abandoned
- 2001-03-09 CA CA002402919A patent/CA2402919A1/en not_active Abandoned
- 2001-03-09 CN CNA018090222A patent/CN1650327A/zh active Pending
- 2001-03-09 JP JP2001567526A patent/JP2004502993A/ja not_active Withdrawn
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009525003A (ja) * | 2006-01-26 | 2009-07-02 | ソニー株式会社 | ユーザにデイリーズ(dailies)および編集済みビデオを提供するための方法およびシステム |
US9196304B2 (en) | 2006-01-26 | 2015-11-24 | Sony Corporation | Method and system for providing dailies and edited video to users |
Also Published As
Publication number | Publication date |
---|---|
CA2402919A1 (en) | 2001-09-20 |
EP1323129A2 (en) | 2003-07-02 |
AU2001245578A1 (en) | 2001-09-24 |
CN1650327A (zh) | 2005-08-03 |
US7096210B1 (en) | 2006-08-22 |
WO2001069527A2 (en) | 2001-09-20 |
WO2001069527A3 (en) | 2003-03-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7096210B1 (en) | Trainable, extensible, automated data-to-knowledge translator | |
EP1672537B1 (en) | Data semanticizer | |
Chaudhri et al. | XML data management: native XML and XML-enabled database systems | |
Sahuguet et al. | Building intelligent web applications using lightweight wrappers | |
US6182092B1 (en) | Method and system for converting between structured language elements and objects embeddable in a document | |
JP5073494B2 (ja) | 文書処理装置および文書処理方法 | |
US20050022115A1 (en) | Visual and interactive wrapper generation, automated information extraction from web pages, and translation into xml | |
JP2010532897A (ja) | 知的なテキスト注釈の方法、システム及びコンピュータ・プログラム | |
US20090083300A1 (en) | Document processing device and document processing method | |
de Boer et al. | Enterprise architecture analysis with xml | |
Raposo et al. | The wargo system: Semi-automatic wrapper generation in presence of complex data access modes | |
EP1830274A1 (en) | Server device and name space issuing method | |
JP2006202308A (ja) | グラフィカルユーザインターフェース方法、グラフィカルユーザインターフェース装置、及び記録媒体 | |
Jupp et al. | A flexible API and editor for SKOS | |
Liu et al. | An XML-enabled data extraction toolkit for web sources | |
US20080005085A1 (en) | Server Device and Search Method | |
US20090083620A1 (en) | Document processing device and document processing method | |
JP2002297662A (ja) | 構造化文書編集方法および構造化文書編集装置および端末装置およびプログラム | |
Gnörlich | MultiNet-WR: a Knowledge Engineering Toolkit for Natural Language Information | |
Bompani et al. | XML-based hypertext functionalities for Software Engineering | |
JPH02108130A (ja) | 知識整理エディタにおける文章知識編集方法 | |
JP2007233631A (ja) | テキストデータのコンピュータ処理用操作ボタン生成方法 | |
Tunçer et al. | Document decomposition by content as a means for structuring building project information | |
Zafeiris et al. | An infrastructure for manipulating multidimensional semistructured data | |
Tuncer et al. | (Re) presentation of architectural analyses: Two prototype applications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080205 |
|
A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20091014 |