JP5367947B2 - 用語データベース拡張のための方法およびシステム - Google Patents

Description

本発明は、ビジネスソリューションソフトウェアプログラムにおけるラベルのマージおよび開発に関する。詳細には、本発明は、ビジネスソリューションソフトウェアのモジュールにおけるラベルの開発およびマージに際して使用されるラベルデータベースおよびラベルダイアログに関する。

ビジネスソリューションソフトウェアプログラムは、通常は企業であるエンドユーザに、ユーザの様々な取引先との接続性をサポートする、カスタマイズ可能で、拡張性があり、グローバルな企業リソース計画ソリューションを提供する。多くのビジネスソリューションソフトウェアプログラムは、そのソフトウェアの基本的機能を、それを実施する企業のニーズをさらに満たすように元の製品を上回って拡張することができるようになっている。この新規の、または追加の機能は、そのビジネスソリューションソフトウェアに含まれる既存の諸機能および既存のデータを利用するために書かれた追加モジュールによって提供される。これらの追加モジュールは、しばしば、ソフトウェアおよび既存のデータを、そのビジネスソリューションソフトウェアの新旧両方の機能と自動的に同期させる。

いくつかのビジネスソリューションソフトウェアは、様々な国々で、多数の言語にわたって、多数の通貨で業務を行うことができるようにする。ビジネスソリューションソフトウェアで提供される多言語機能の使用により、送り状などの書類を、受取人にとって好ましい言語で送ることが可能である。しかしながら、現行のシステムで書類の言語を変更するには、そのビジネスソリューションソフトウェアに新しい言語をロードし、システムの全運用言語を変更する必要がある。

ビジネスソリューションソフトウェアの様々な利用可能言語での通信は、複数のラベルの使用によって処理される。ラベルは、ユーザインターフェースコンポーネント上に、または印刷文書に表示されるテキストである。しかしながら、ラベルは、イメージ、ビットマップ、アイコン、動画、あるいは他の言語においては異なるはずの任意の種類のデータとすることもできる。ラベルはメニュー、ボタン、ダイアログボックスなどを含み得る。さらに、ラベルは、「ラベル」、「ヘルプ」、「キャプション」、「ツールチップ」などのラベル属性を持つコントロール上でも使用され得る。現在のビジネスソリューションソフトウェアにおけるラベルは、そのビジネスソリューションソフトウェアによって使用される各言語ごとに１つのリソースファイルが専用に確保される、別々のリソースファイルに格納される。さらに、ビジネスソリューションソフトウェア中の各モジュールは、他のモジュール、またはそのビジネスソリューションソフトウェア自体と共用されないそれ自体のリソースファイルを持つ。

これまでのビジネスソリューションソフトウェアの開発全体を通して、開発者の間には既存のラベルを再利用することを望む強い要望があった。しかしながら、既存のラベルを再利用することは有利でないことが認められている。というのは、ラベルの様々な属性が異なる使用状況の間で変化し、あるいはラベルの意味が開発者間で異なり得るからである。これは、用語が変更されるときに問題を生じ得る。例えば、１つのラベルテキストが、あるアプリケーション上のメニュー、および別のアプリケーション上のボタンとして使用され、そのために各ラベルごとに異なる属性を生じることがある。大部分の開発者らが望んだのは、システム上の様々なモジュールにラベルを開発することに伴うコストを削減するために、それらのラベルを含む用語またはテキストを再利用することであった。

前述のように、通常、ビジネスソリューションソフトウェアモジュールでは、ラベルはリソースファイルに保持される。しかしながら、現在のビジネスソリューションソフトウェアは、構造化照会言語（ＳＱＬ）表などのデータベースメタデータストアを介して、あるいはＷｅｂサービスを介して利用可能な汎用リソースファイルを使用しない。通常、これらのラベルは、ビジネスソリューションソフトウェアでは、モジュールに固有のものであり、そのモジュールにある各言語ごとに１つのリソースファイルが専用に確保される専有リソースファイルに格納される。専有リソースファイルを使用することに伴う１つの問題は、開発者が、１つのモジュール中のラベルの一部を、別のリソースファイルに含まれる新しい情報または属性を用いて置換または編集しようとするときに、開発システムが、所望のラベルと同じラベル属性および／または用語法を持つそのビジネスソリューションソフトウェアの他のモジュール中の別のラベルを検索しないことである。さらに、リソースファイルの使用は、ソフトウェアソリューション中に存在するラベルが多数であるために、ラベルの管理を極めて困難にする。しかしながら、ビジネスソリューション環境では、ビジネスソリューションソフトウェアには、複数のベンダによって開発されるいくつかの異なるソリューションを処理することが必要とされる。これらのモジュールの開発者らは、しばしば、そのビジネスソリューションソフトウェア中の他のモジュールのために開発されたラベルとオーバーラップするラベルを開発することがある。ラベルを開発し、それらのラベルを（多言語サポートが求められるときに）翻訳することに伴うコストは、特に、ラベルとその翻訳がすでにそのビジネスソリューションソフトウェアの他の部分に存在する場合には、非常に高くつき、時間を要するものになる。したがって、各ベンダが所望のラベルごとに独自のラベルを開発することを必要とする完全に独自のシステムに対して、様々なモジュールベンダの貢献を組み合わせたものを使用するラベルシステムを備えることが望ましい。さらに、それは、既存のラベルテキストをサーチすることを可能にし、そのテキストを再利用できるようにするシステムのためにも望ましい。

ラベルをサーチするとき、名前空間およびカテゴリの選択について、開発者にとってその正しいカテゴリを選択することは困難である。開発者は、しばしば、現在の環境に位置するラベルのサブセットが現在の必要を満たすものであるかどうか知らないことがある。したがって、開発者は、所望のラベルを保持するデータベース中でどんなラベルが利用可能であるか知ることを求めている。さらに、開発者は、その用法のための正しい情報およびそのラベル中の用語に適した翻訳を含むラベルを作成することも求めている。

本発明の用語データベースは、追加機能を提供することによりラベルシステムを拡張する。これらの追加機能は、翻訳者または標準機構によって制御される。これらの機能は、そのラベルの実際に求められる用法に符合するラベルの検索に役立つように、ラベルダイアログに追加のサーチ基準を加えることを可能にする。これらの機能が活動化されると、追加の対象に関連する結果が開発者に返されて、ラベルに正しい用語を選択するのに役立つ。開発者らは、自分自身の母国語で考えようとするため、これらの機能は、その開発者の母国語での１つの単語が別の言語での複数の単語に翻訳され得るときに、ラベルで使用される用語を標準化するのに役立つ。

本発明の一実施形態は、開発者がビジネスソリューションソフトウェアに新しいモジュールを開発し、またはその既存のモジュールを編集している状況に対処する。本発明は、開発者が、ダイアログ開発ツールを介して既存の用語を識別できるようにする。まず、開発者は開発ディスプレイでユーザインターフェースを開く。このディスプレイは開発者に、用語テキストデータベースのサーチおよび利用可能な用語すべてへのアクセスを可能にするサーチ機能を表示する。次いで、開発者は、サーチエンジンに、所望の用語のテキストを入力する。このテキストは、通常の表現を用いて、その全体としても、所望の用語の一部としても入力され得る。開発者は、当該の用語の所望の用法も指示する。

入力されたデータに基づき、サーチエンジンは、用語テキストデータベースおよび用語領域をサーチし、所望のテキストに最も近くマッチするテキストを持つ用語、およびその用語の所望の用法に類似の意味を持つ用語を識別する。識別された用語はサーチエンジンディスプレイで開発者に返され、データグリッドとして表示され得る。その結果は、所望のテキストに最も近くマッチするテキストを含む用語が最初に表示され、そうでない用語が最後に表示されるなど、所定の方法に従ってランク付けされる。次いで、開発者は、返された所望のテキストを含む結果から１つの結果を検索することができる。結果の１つが新しい用語の所望のテキストを含む場合、開発者はその結果から所望の用語を選択することができ、それを新しいラベルに複写する。

結果を選択すると、開発者には、データベースに含まれるその特定の用語に関する詳細情報が提示される。選択された用語の用法は開発者には知られていないため、開発者はその用語を新しいラベルに複写する。

選択された用語が新しいラベルに複写されると、その新しいラベルにＧＵＩＤが生成され、新しいラベルのレコード中に、このラベルに複写された用語のＧＵＩＤを示すエントリが生成される。このエントリが提供されるのは、その親用語のテキストが変更されるときにその新しい用語のテキストも更新され得るようにするためである。さらに、ある用語が新しいラベルに複写されると、任意の関連する翻訳などの情報がその新しいラベルの用語テキスト表に複写される。これは、その新しいラベルを利用可能な諸言語に翻訳することに伴うどんな追加コストも招くことなく、ビジネスソリューションソフトウェアシステムの完全な言語機能が新しい用語に引き継がれることを可能にする。別の実施形態では、その用語の翻訳バージョンが更新されると、同じマスタ用語を共用するすべての関連するラベルが、その翻訳された用語の新バージョンを用いて更新される。これは、一般に、プログラムがラベルを更新するように実行されたときに行われる。

ダイアログの特定の用法機能を介して、開発者は、用語の所望の用法に最もマッチする用語を、迅速かつ容易に識別することができる。この機能は、開発者が、結果で、自分の母国語での同じ単語を複数のカテゴリとして提示されたときに特に重要である。ある言語における単語は、しばしば、第２言語において複数の同義語を持つことがあるため、その特定の方法は、開発者が、所望の用法に最も適した関連する翻訳を持つラベルを選択するのに役立つであろう。本システムの第２の利点は、開発者が、データベースをサーチするときに、その意図する用語以外の用語も提示されることである。これらの単語は、他の開発者によってすでに使用され、他の言語に翻訳されている単語または用語を表すものである。開発者がこれらの用語を使用し始めた場合、各モジュールで使用される用語が標準化され、結果として開発者にかかるコストが削減されることになる。

本発明の第２の実施形態は、本発明の特定の用法サーチをサポートするデータ構造を対象とする。このデータ構造は、用語ＩＤ表、ラベルテキスト表、およびラベル領域表を含む。用語ＩＤ表は、その識別子、一般的用法のカテゴリ（ボタン、ラベル）、および状態フィールドを含むその用語に関連する情報を保持する。状態フィールドは、その用語の出典または状況を示す。用語テキスト表は、様々な言語に及ぶその用語テキストの様々なバージョンを保持する。用語領域表は、用語およびその用語の用法の記述に関連付けられたラベルの特定の用法を含む。これらの表は、開発者が、ある用語が所望の用法に適しているかどうか正確に判定することを可能にする。

図１に、本発明が実施され得る適当なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は、適当なコンピューティング環境の一例にすぎず、本発明の用途または機能の範囲についてのどんな限定を示唆するためのものでもない。また、コンピューティング環境１００は、例示的動作環境１００に示す構成要素のいずれか１つまたはそれらの組み合わせに関連するどんな依存関係または要件を有するものであるとも解釈すべきではない。

本発明は、他の多数の汎用または専用コンピューティングシステム環境または構成と共に動作する。本発明と共に使用するのに適し得るよく知られているコンピューティングシステム、環境、および／または構成の例には、それだけに限らないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ機器、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれる。

本発明は、コンピュータにより実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで説明され得る。一般に、プログラムモジュールには、個々のタスクを実行し、または個々の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本発明は、タスクが通信ネットワークを介してリンクされたリモート処理装置によって実行される分散コンピューティング環境でも実施され得る。分散コンピューティング環境では、プログラムモジュールは、記憶装置を含むローカルとリモート両方のコンピュータ記憶媒体に位置し得る。

図１を参照すると、本発明を実施する例示的システムは、コンピュータ１１０の形で汎用コンピューティングデバイスを含む。コンピュータ１１０の構成要素には、それだけに限らないが、処理装置１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステム構成要素を処理装置１２０に結合するシステムバス１２１が含まれ得る。システムバス１２１は、様々なバスアーキテクチャのいずれかを使用したメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかの種類のバス構造のいずれでもよい。例をあげると、それだけに限らないが、そのようなアーキテクチャには、インダストリスタンダードアーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、エンハンスドＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダードアソシエーション（ＶＥＳＡ）ローカルバス、およびメザニンバスとも呼ばれるペリフェラルコンポーネントインターコネクト（ＰＣＩ）バスが含まれる。

コンピュータ１１０は、通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０からアクセスし得る任意の使用可能な媒体とすることができ、それには揮発性媒体と不揮発性媒体の両方、取り外し可能媒体と取り外し不能媒体の両方が含まれる。例をあげると、それだけに限らないが、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体が含まれ得る。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータなどの情報を記憶するための任意の方法または技術で実施された、揮発性と不揮発性両方、取り外し可能と取り外し不能両方の媒体が含まれる。コンピュータ記憶媒体には、それだけに限らないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリなどのメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）などの光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶などの磁気記憶装置、あるいは所望の情報の記憶に使用することができ、コンピュータ１１０からアクセスし得る他の任意の媒体が含まれる。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュールまたはその他のデータを、搬送波または他の搬送機構などの変調されたデータ信号中に具現化し、任意の情報伝達媒体を含む。「変調されたデータ信号」という用語は、その特性の１つまたは複数が、その信号に情報を符号化するような方式で設定または変更されている信号を意味する。例をあげると、それだけに限らないが、通信媒体には、有線ネットワークや直接配線接続などの有線媒体、および音響、ＲＦ、赤外線、その他の無線媒体などの無線媒体が含まれる。上記のいずれかの組み合わせも、コンピュータ可読媒体の範囲内に含むべきである。

システムメモリ１３０は、読み出し専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形でコンピュータ記憶媒体を含む。始動時などに、コンピュータ１１０内の要素間の情報転送を支援する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３は、通常、ＲＯＭ１３１に記憶される。ＲＡＭ１３２は、通常、処理装置１２０から直ちにアクセス可能であり、かつ／またはそれによって現在処理されているデータおよび／またはプログラムモジュールを含む。例として、それだけに限らないが、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０は、他の取り外し可能／取り外し不能、揮発性／不揮発性コンピュータ記憶媒体も含み得る。例にすぎないが、図１に、取り外し不能、不揮発性磁気媒体との間で読取りまたは書込みを行うハードディスクドライブ１４１、取り外し可能、不揮発性磁気ディスク１５２との間で読取りまたは書込みを行う磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭや他の光媒体などの取り外し可能、不揮発性光ディスク１５６との間で読取りまたは書込みを行う光ディスクドライブ１５５を示す。例示的動作環境で使用され得る他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体には、それだけに限らないが、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４１は、通常、インターフェース１４０などの取り外し不能メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取り外し可能メモリインターフェースによってシステムバス１２１に接続される。

前述の、図１に示す各ドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ可読命令、データ構造、プログラムモジュールおよびその他のデータの記憶を提供する。図１では、例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同じでも、異なっていてもよいことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともそれらが異なるコピーであることを示すために、図では異なる番号を付してある。

ユーザは、キーボード１６２や、マイクロホン１６３や、マウス、トラックボール、タッチパッドといったポインティングデバイス１６１などの入力装置を介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどが含まれ得る。上記およびその他の入力装置は、しばしば、システムバスに結合されたユーザ入力インターフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）といった他のインターフェースおよびバス構造によっても接続され得る。モニタ１９１または他の種類の表示装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタ以外に、コンピュータは、スピーカ１９７やプリンタ１９６など他の周辺出力装置を含むこともでき、それらは、出力周辺インターフェース１９５を介して接続され得る。

コンピュータ１１０は、リモートコンピュータ１８０など、１つまたは複数のリモートコンピュータへの論理接続を使用したネットワーク化環境で動作し得る。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルド機器、サーバ、ルータ、ネットワークＰＣ、ピアデバイスなどの一般的ネットワークノードとすることができ、通常は、コンピュータ１１０に関連して上で説明した要素の多くまたはすべてを含む。図１に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークも含まれ得る。そのようなネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットではよく見られるものである。

ＬＡＮネットワーク環境で使用されるとき、コンピュータ１１０はネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーク環境で使用されるとき、コンピュータ１１０は、通常、モデム１７２またはインターネットなどのＷＡＮ１７３を介して通信を確立する他の手段を含む。モデム１７２は、内蔵でも外付けでもよく、ユーザ入力インターフェース１６０または他の適当な機構を介してシステムバス１２１に接続され得る。ネットワーク化環境では、コンピュータ１１０に関連して示すプログラムモジュール、またはその一部は、リモート記憶装置にも格納し得る。例として、それだけに限らないが、図１に、リモートアプリケーションプログラム１８５を、リモートコンピュータ１８０上にあるものとして示す。図示のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立する他の手段も使用され得ることが理解されるであろう。

一実施形態では、システム１００は、一般会計および業務諸機能を特定のアプリケーションモジュールと統合し得る業務管理ソリューションを生成するソフトウェアを含む。これらのモジュールには、財務、取引、ロジスティックス、生産、顧客サービス、プロジェクトおよび人事の各モジュールが含まれ得る。しかしながら、この業務管理ソリューションでは、他のモジュールタイプも使用され得る。本発明のソリューションは、複数の通貨（ユーロ、ドル、円、ウオンなど）、複数の言語（英語、独語、仏語、デンマーク語、ロシア語、日本語、中国語など）および（複数の税務当局に対応するエンドユーザによる使用のための）複数の課税形式をサポートするように構成され得る。

業務管理ソリューションで使用される各モジュールは、多種多様なソースから開発され得る。一実施形態では、これらのモジュールすべての間の共通リンクは、ラベルの使用である。ラベルは、識別子で表されるテキストである。ラベルは、ダイアログボックス、テキストストリング、またはユーザに情報を伝えるのに使用される任意のテキストを含み得る。ラベルは、一般には、グラフィカルユーザインターフェイス、すなわちＧＵＩなどのリソースを介してユーザに提示される。しかしながら、ラベルは、ユーザにテキストを提示する他の任意の手段によってもユーザに提示され得る。さらに、ラベルは、「ラベル」、「ヘルプ」、「キャプション」、「ツールチップ」などのラベル属性を持つコントロール上でも使用され得る。以前のビジネスソリューションソフトウェアでは、各モジュールごとのラベルが別々のリソースファイルに保持される。しかしながら、これらのリソースファイルは、一般に、特定のモジュールに専用の単層ファイルアーキテクチャ（ｆｌａｔ ｆｉｌｅ ａｒｃｈｉｔｅｃｔｕｒｅ）として保持された。各モジュールの開発プロセス中しばしば、開発者は、現在作成されているラベルの要件を満たす別のモジュール中のラベルについて知っていることがある。しかしながら、従来技術のシステムの専有ファイルソース構造は、開発者が、あるモジュールからのラベルを別のモジュールで使用するのを妨げ、ラベルをサーチすることも不可能であった。

図２は、本発明の一実施形態による、ビジネスソリューションシステム２００におけるラベルを構成する様々なコレクション間の関係を示すエンティティ関係図である。図２のエンティティ関係図は、言語表２１０（またはシステムで利用可能な言語の他の指示）、マスタ２２０、ラベルＩＤ表２３０、およびラベルテキスト表２４０を含む。一実施形態では、これらのコレクションは表に構成された構造化照会言語（ＳＱＬ）メタデータストアとして編成される。しかしながら、これらのコレクションでの他の構成および他のデータベースも使用され得る。ラベルＩＤ表２３０およびラベルテキスト表２４０について、図３Ａおよび３Ｂを参照してより詳細に説明する。

言語表２１０は少なくとも２つのサブフィールドを含む表である。言語表２１０中の２つのサブフィールドとは、言語ＩＤフィールド２１１および言語名フィールド２１２である。言語ＩＤフィールド２１１は特定の言語を示すコードを保持し、それはビジネスソリューションソフトウェアプログラムによって理解可能である。言語名フィールド２１２は、言語の名前を保持するテキストフィールドである。例えば、利用可能な言語の１つが英語（ＵＳ）である場合、その言語ＩＤフィールド２１１は、例えば、「０１」とすることができ、ＡＳＣＩＩ標準を使用する場合は、「ｅｎ−ｕｓ」とすることもできる。しかしながら、言語ＩＤフィールド２１１には他のＩＤタイプも使用され得る。このエントリのメタデータ表の言語名フィールド２１２は、例えば、「英語（ＵＳ）」などになるはずである。代替として、このエントリは、特定のソリューションによってこのソリューションが提供された場合には特定の言語テキストを持つラベルとすることもできるであろう。

言語表２１０に格納された情報は、ユーザがシステムの運用言語を確認し、または変更しようとするときに、ラベルダイアログディスプレイでユーザに表示され得る。言語表２１０は、ラベルテキスト表２４０と１：ｎの関係にある。この関係（１：ｎ）が発生するのは、システム２００から利用可能な各言語での異なるラベルを表す複数のラベルテキストが存在し得るからである。

マスタ２２０は、一実施形態では、システム２００における各ラベルの１バージョンを含む表である。一実施形態では、マスタ２２０は、そのラベルの元のバージョンを元の言語および形式で保持する。しかしながら、マスタ２２０にはそのラベルの他のバージョンも格納され得る。例えば、最良実施例の指針が使用される場合、システム２００は、マスタ２２０に、英語（ＵＳ）のラベルを格納することができる。最良実施例の指針とは、特定のカテゴリタイプ、記述、および言語を用いてラベル開発を標準化する一連の手順である。システム２００の各ラベルは、マスタ２２０に１つの関連するエントリを持つ。マスタによって表されるラベルは、ラベルの翻訳が更新されるとき、そのラベルが現在選択されている（アクティブな）言語に翻訳されていないとき、あるいはそれが何らかの理由でシステム２００からアクセス不能になったときに使用される。しかしながら、別の実施形態では、マスタ２２０に格納された情報は、マスタラベルのラベルＩＤを示すラベル表２３０または言語表２４０中の１つまたは複数のフィールドとして格納され得る。さらに、マスタ２２０は、どの言語ラベルが作成されたかに関する情報を保持するだけの単純なフィールドとすることもできる。このフィールドはラベルＩＤ表２３０に位置することができる。

各マスタは、ラベルＩＤ表２３０中の１エントリに対応する。ラベルＩＤ表２３０は、翻訳者（そのテキストを翻訳する者）がそのラベルを正しく翻訳するのに役立つ様々な属性を含む。これらの属性は、開発者がラベルを適正に使用するのにも役立つ。複数のラベルＩＤが同じマスタを共用し得るため、マスタとラベルＩＤ表２３０の間の関係は１：ｎである。

ラベルテキスト表２４０は、ラベルＩＤによって識別される各ラベルごとのテキストを含むエントリを含む。ラベルテキスト表２４０は、各ラベルＩＤごとの様々な言語での翻訳を含むエントリも含む。ラベルＩＤ表２３０とラベルテキスト表２４０の間の関係、ならびに言語表２１０とラベルテキスト表２３０の間の関係は１：ｎである。これは、ラベルＩＤ表２３０では１つのラベルに１つのエントリがあるが、１つのラベルのテキストは複数の言語で存在し得るからである。しかしながら、本発明の他の実施形態では、ラベルＩＤとラベルテキストの間の関係は、１：１（またはテキストが存在しない場合は１：０）になることがあり、その場合、マスタラベルの各翻訳は、ラベルＩＤ表２３０に独自の一意のラベルＩＤおよびエントリを持つ。

図３Ａに、本発明の一実施形態によるラベルＩＤ表２３０を構成する各フィールドを示す。ラベルＩＤ表２３０は、ＩＤフィールド２３１、名前空間フィールド２３２、カテゴリフィールド２３４、および記述フィールド２３５を含む。他の実施形態では、ラベルＩＤ表２３０は、ラベルＩＤ表中のエントリが別のラベルから複写されているかどうか、あるいはその表中の別のエントリに複写されているかどうか指示するフィールド２３６を含み得る。

通常、ラベルはリソースファイルに保持される。本ビジネスソリューションシステムは、ＳＱＬ表などのデータベースメタデータストアを介して利用可能な汎用リソースファイルを使用しない。本ビジネスソリューションシステムでは、これらのラベルは、専有リソースファイルに格納される。専有リソースファイルを用いることに伴う１つの問題は、開発者が、システム中の１つまたは複数のラベルの一部を、そのファイルのリソースのすべてを含むファイルで置き換えようとするとき、システムが、現在のラベルと同じラベル属性または用語法を持つそのシステム中の別のファイルを検索しないことである。しかしながら、ビジネスソリューション環境では、ビジネスソリューションシステムは、複数のベンダによって開発される同じまたは類似の問題へのいくつかの異なるソリューションを処理することが必要とされる。したがって、本発明のラベルシステム２００は、様々なベンダによって行われた貢献すべての総和を使用することができる。

ＩＤ２３１フィールドは、システム２００で特定のラベルを識別するのに使用される。一実施形態では、このＩＤはグローバルに一意な識別子すなわちＧＵＩＤである。ＧＵＩＤは、２つのベンダが２つの無関係なラベルに同じ識別番号を選択しているために生じる問題を回避するのに使用される。一実施形態におけるＧＵＩＤは、一意の識別子が必要とされる場合はいつでもすべてのコンピュータおよびネットワークにわたって使用され得る１２８ビットの整数（１６バイト）である。そのような識別子システムの使用は、２つのラベルが同じＩＤを持つことになる可能性を低減する。ＧＵＩＤは、一実施形態では、ストリングとして表され、以下のパターンに従ってフォーマットされる。
ｘｘｘｘｘｘｘｘ−ｘｘｘｘ−ｘｘｘｘ−ｘｘｘｘ−ｘｘｘｘｘｘｘｘｘｘｘ
その場合、ＧＵＩＤの値は、８桁、４桁、４桁、４桁、１２桁のグループとしてハイフンで区切られた、一連の小文字の１６進数として表される。例えば、行３０１のエントリでのＧＵＩＤ戻り値は、３８２ｃ７４ｃ３−７２１ｄ−４ｆ３４−８０ｅ５−５７６５７ｂ６ｃｂｃ２７とすることができる。しかしながら、ＩＤフィールド２３１には他のフォーマットタイプも使用され得る。新しいラベルが作成されるたびに、それに新しいＧＵＩＤが割り当てられる。一実施形態では、新しいラベルは、単に既存のラベルの翻訳としてではなく、システム２００にとって新規のラベルとして定義される。しかしながら、他の実施形態では、既存のラベルの翻訳にＩＤフィールド２３１の新しいエントリが生成される。

ＧＵＩＤの使用は、現在のシステムを上回るさらなる利益を提供する。第１に、各ラベルを複数の言語に分ける必要がない。さらに、ＧＵＩＤは、各ラベルが、行番号の使用によるなど他の方法でその一意性を制御しなくとも、一意に識別されるようにする。第２に、ＧＵＩＤは、ラベルの物理的記憶が、専有リソースファイルから、Ｗｅｂサービス上のメタデータデータベースなどの共通リソースファイルに変更されることを可能にする。

ラベルＩＤ表２３０の名前空間フィールド２３２は、翻訳者が、ラベルテキストをマスタ言語から目標言語に翻訳するときに、そのラベルの正しい用語を獲得するのを支援するためにラベルＩＤに入力される特別なフィールドである。現行のラベルシステムでは、プログラム中のどこで特定のラベルが使用されているかを簡単に調べることは不可能である。さらに、そのラベルがどの領域で使用されているか調べることも容易ではない。したがって、そのプログラムが翻訳者のコンピュータ上にインストールされており、そのラベルがどこに使用されているか調べることができるのでない限り、翻訳者がラベルの正しい用語を獲得することは、不可能とは言わないまでも、極めて困難である。名前空間フィールド２３２は、プログラムを翻訳者のマシンにインストールすることを必要とせずに、そのラベルが使用されている領域を調べることを可能にする。名前空間フィールドに含まれる情報は、新しいラベルが作成されるときに（自動的に、または手動で）開発者によって提供され、特定のラベルの用法に関連する情報を提供する。例えば、図３Ａの行３０２のエントリでは、名前空間フィールド２３２は、翻訳者または開発者に、このラベルが課金モジュールで使用されていることを知らせる。

ラベルＩＤ表２３０のカテゴリフィールド２３４は、そのラベルがプログラムのどのコンポーネントで使用されているかを示す特別なフィールドである。さらに、カテゴリフィールド２３４の使用は、開発者が、ラベルテキストの作成中に、そのラベルを正しく書くのに役立つ。カテゴリは、そのラベルのノードタイプと属性の組み合わせである。ノードタイプは、そのラベルの特定の属性である。これらのラベル属性の一部は、「ラベル」、「ヘルプ」、「キャプション」などを含み得る。ゆえに、カテゴリフィールド２３４は、ラベルが所望のプログラムで適正に使用されるよう保証することができる。さらに、カテゴリは、システムに存在するコントロールすべてのマッピングである。したがって、所望のラベルのタイプまたはカテゴリに基づいて、既存のラベルのデータベースをサーチすることが可能である。本発明では、システム２００によって実行される各規則またはコントロールごとに１つのカテゴリが作成される。モジュールの開発中に、特定のラベルテキストに特別な規則が必要とされる場合は、追加のカテゴリが作成され得る。例えば、ノードフィールド２３４は、エントリ３０３のラベルが、ユーザをそのモジュール中の別のポイントに誘導するためにモジュールのメニューバーで使用されていることを知らせるエントリとすることができる。各カテゴリは、システム２００での特定の機能にマップされる。

記述フィールド２３５は、ユーザまたは開発者にそのラベルがどのように使用されているかを記述する、表２３０中のエントリである。例えば、記述フィールド２３５は、エントリ３０３のラベルが元帳の一事例で使用されていることを知らせるエントリとすることができる。この記述は、言葉（プレーンテキスト）で表すことも、所定のコードリストに照らしてコード化することもできる。

複写元フィールド２３６は、そのエントリの関連するラベルがラベルシステム中の別のラベルから複写されているかどうかを示す。そのラベルが別のラベルから複写されている場合、複写元フィールド２３６は、親またはマスタラベル２２０からのＩＤを含む。一実施形態では、このＩＤは親のＧＵＩＤである。しかしながら、フィールド２３６には他のＩＤも使用され得る。ラベルが別のラベルの複写バージョンではない場合、複写元フィールド２３６は空白であり、またはヌルに設定される。さらに、ラベルのテキストまたは他の任意の情報がコピー後にマスタラベルのテキストから変更される場合、複写元フィールド２３６はヌルに設定され、それによって、マスタラベル２２０とこの特定の子ラベルの間のどんなリンクも削除される。しかしながら、このエントリへの他の変更は、複写元フィールド２３６をリセットさせることになる。別の実施形態では、図３ＡのラベルＩＤ表２３０は、どのラベルＩＤが複写されたラベルを含むかを示すフィールドを含む。ＩＤ表２３０中のラベルはマスタラベルまたは子ラベルである。

図３Ｂに、特定のラベルのラベルテキスト表２４０を埋める各フィールドを示す。ラベルテキスト表２４０エントリは、少なくとも３つの異なるフィールド、すなわち、ラベルＩＤフィールド２４４、ラベルテキストフィールド２４１および編集日付２４２を含む。本発明の別の実施形態では、ラベルテキスト表２４０にその他のフィールドが付加され得る。これらのフィールドには、テキストが書き込まれる言語を示すフィールド２４３、またはラベルテキスト表中のテキストの各バージョンのエントリ識別子を識別するフィールドが含まれる。

ラベルテキスト表２４０のテキストフィールド２４１は、システムのすべての利用可能言語でのそのラベルのテキストの最新バージョンを含む。しかしながら、テキストフィールド２４１には、言語別アイコン、ビットマップビデオなど、他の情報も格納され得る。ラベルのラベルテキスト表２４０中の第１のエントリ３５１は、そのラベルが書かれた元の、またはマスタ言語によるものである。このテキストをマスタテキストという。ラベルが最良実施例の指針に従って開発される場合、マスタテキストは英語（ＵＳ）で書かれることになる。しかしながら、他の言語をマスタ言語として使用することもでき、最良実施例の指針に従う必要はない。一般に、マスタ言語は、システムがそれによって運用されている現在の言語に対応する。

ラベルテキストがマスタ言語から別の言語に翻訳される際、３５２や３５３などの新しいラベルテキストエントリがラベルテキスト表に作成される。これらのエントリは、元のラベルテキストのそれぞれの言語での翻訳バージョンを含む。例えば、ラベルの元のテキストが「Do you want to save the changes you made to（あなたが行った変更を保存しますか）」である場合、このテキストは、ラベルテキスト表２４０の第１行３５１に格納される。その後、このテキストが独語、デンマーク語および仏語に翻訳されるときに、それらの翻訳が、ラベルテキスト表の、そのマスタテキストエントリの下の各エントリに入力される。これらの追加された翻訳を、エントリ３５２、３５３、３５４によって示す。

編集日付フィールド２４２は、そのラベルのテキストが、ラベルテキスト表中のその特定のエントリに関連付けられた言語で最後に変更されたのがいつかを開発者が知るために、ラベルテキスト表２４０に設けられる。さらに、「変更者」フィールドなど、検証情報を含む他のフィールドも付加され得る。この日付は、テキストの翻訳が提供される場合、それが、その翻訳のすでにより新しいバージョンを置き換えないようにするのに役立つ。翻訳がシステムに自動的にロードされるとその翻訳日付が比較され、そのエントリ中バージョンが提示されたエントリより新しい場合には、提示されたエントリは表に入力されない。また、編集日付フィールド２４２は、開発者が、その翻訳が、マスタテキストエントリの最新バージョンでの最新のものかどうかチェックすることを可能にする。一実施形態では、マスタテキストエントリ３２１の編集日付は、望ましくは、特定のラベルのラベルテキスト表２４０中の最も古い日付である。

いくつかの実施形態では、ラベルテキスト表２４０は、言語フィールドエントリ２４３を含む。言語フィールドエントリ２４３は、開発者がその言語を話さず、または理解しない場合であっても、開発者にラベルテキスト表中の特定のエントリの特定の言語を示す。この言語フィールドエントリ２４３の言語標識は、その言語の数値表現とすることができ、またはその言語の名前として、あるいはその他の任意の種類の言語識別子として書き込むこともできる。

数値表現を用いて言語が識別される場合、その言語の参照番号またはエントリは、例えば、ＡＳＣＩＩ言語コードやＩＳＯ６３９といった公知の標準に準拠することができる。しかしながら、他のコードを用いてテキストエントリの言語を識別することもできる。言語の名前がフィールド２４３に入力される場合、その言語の名前は、例えば、公知の標準（すなわち英語での言語名）に従って書き込むことができる。しかしながら、他の形式も使用され得る。

ラベルテキスト表２４０は、特定のラベルテキストのラベルＩＤ２３１を識別するエントリフィールド２４４も含む。このエントリは、開発者が、現在のテキストがどのラベルＩＤ２３１に関連するか知ることができるようにする。ラベルテキスト表２４０の別の実施形態は、テキストＩＤ２４５のエントリを含む。このテキストＩＤ２４５は、ラベルテキスト表２４０において、各テキストラベルを独自のエントリとして個々に識別するために提供される。テキストＩＤ２４５エントリは、ＧＵＩＤとすることもでき、ラベルテキスト表の構成と一致する他の任意の識別法とすることもできる。別の実施形態では、ラベルテキスト表２４０およびラベルＩＤ表２３０は１つの表またはデータベースにマージされ得る。この実施形態では、ラベルを管理し、モジュールが実行されるときに正しいラベル言語テキストが表示されることを保証するために、別の一連のフィールドが必要とされる。さらに、ラベルのロードを管理するための索引も付加されるはずである。

図４は、ラベルシステムインターフェース４００を構成するコンポーネントを示すブロック図である。ラベルシステムインターフェース４００は、開発者４０１をメタデータストア４０９にリンクさせ、開発者がシステム２００の新しいモジュールを開発するときに既存のラベルを操作できるようにするインターフェースである。ラベルシステムインターフェース４００は、ラベルダイアログ４０２、ラベルダイアログ論理コンポーネント４０３、拡張言語インターフェース４０４、およびラベルインターフェース４０５を含む。

開発者は、ラベルダイアログ４０２を介してラベルシステムインターフェース４００と対話する。ラベルダイアログ４０２は、開発者が、ラベルシステムインターフェースの諸機能にアクセスすることができるようにするユーザインターフェースである。一実施形態では、ラベルダイアログ４０２は、ユーザが、特定のラベルの用法を確認し、管理することができるようにするウィンドウである。ラベルダイアログ４０２は、このメタデータストアへのインターフェースを用いてラベルを処理し、利用可能な言語すべてでそのラベルに利用可能なコマンドのフルセットにアクセスする。これらの機能を提供するために、ラベルダイアログインターフェース４０２は、ラベルシステム４００において各ラベルごとに利用可能な言語すべてへのアクセスを必要とする。

しかしながら、ラベルダイアログ４０２は、あるラベルが特定の状況で使用され得るかどうか判定するためのどんな論理も含まない。すべてのコントロールはラベルインターフェースまたはラベルダイアログ論理コンポーネント４０３を制御するクラスに渡される。ラベルダイアログ論理コンポーネント４０３は、ラベルダイアログ４０２と共に使用されるように設計されるが、それはラベルダイアログ４０２の論理すべてを含むため、ラベルダイアログ論理のいくつかの機能は他の領域で再利用され得る。さらに、ラベルダイアログ論理コンポーネント４０３は、各ラベルが、そのラベルの名前空間およびカテゴリの正しい組み合わせと整合するように使用されることを保証する。この論理は、最初に新しいマスタラベルを作成せずに、ラベルを異なる領域で意図せずに使用することを防ぐ。

拡張言語インターフェース４０４は、ラベルダイアログインターフェース４００に、システムで利用可能な言語すべてへのアクセスを提供する。拡張言語インターフェース４０４は、別のクラスを用いて、ラベルダイアログ論理コンポーネント４０３およびラベルダイアログ４０２から複数の言語を利用できるようにする。拡張言語インターフェース４０４は、システム中の複数の言語に共通の方法だけを備える（利用可能な言語リストを返し、現在の言語のＩＤも返す）。１つの言語だけに関連する方法は、直接ラベルクラス４０５上に位置する。ラベルクラスは、メタデータ中のラベルへの接続を可能にする。各利用可能言語にはラベルクラスの１つのインスタンスがある。しかしながら、場合によっては、特定のクラスのインスタンスがないこともある。

言語インターフェースコンポーネント４０４は、利用可能な言語へのアクセスも制御する。言語インターフェースコンポーネント４０４は、ラベルのインスタンスのマップを含む。また、言語インターフェースコンポーネント４０４には、現在のラベルでの利用可能な追加言語クラスそれぞれへのインターフェースもある。

図５は、開発者が、モジュールの新しいラベルを、そのモジュールの一部の開発中に作成するときに実行される諸ステップの一例を示す流れ図である。例えば、開発者が、あるモジュールに「ｃｕｓｔｏｍｅｒ（顧客）」の入力を表すラベルを作成しようとする場合。その開発者は、そのラベルがそのモジュールでどのように使用されるか決定しなければならない。「ｃｕｓｔｏｍｅｒ」という用語は多くの異なる意味を持つ。例えば、顧客は、当事者から財貨およびサービスを購入する相手を意味することもあり、当事者が取引を行う相手を意味することもある。この単語の用法は、他の言語のテキストに影響を及ぼすことになる。これを図５にブロック５０１に示す。

次に、開発者はラベルダイアログプログラムを開く。開かれるラベルダイアログは、例えば、図６に示すラベルダイアログ６００に類似のものである。しかしながら、他のインターフェースも使用され得る。提示されるインターフェースは、開発者がそのラベルのために求める特定のテキストを入力できるようにする。ラベルダイアログを開くことを図５にブロック５０２に示す。

ラベルダイアログが開かれると、開発者は、次いで、行６０２にラベルのための所望のテキストを入力する。代替として、開発者は、行６０２に、ラベルのための所望のテキストの一部を入力することもできる。例えば、開発者はそのテキスト部分に「ｃｕｓｔｏｍｅｒ」と入力することも、「ｃｕｓｔ」と入力することもできる。さらに開発者は、その新しいラベルがどのように使用されるかを示すデータを、インターフェースの行６０３および６０４に入力する。このデータは、ラベルシステム中の既存のラベルをサーチするのに使用され、または新しいラベルを作成するときに使用され得る。例えば、開発者が販売を管理するモジュールを作成しており、「ｃｕｓｔｏｍｅｒ」という用語を使用して購買者のラベルを生成しようとする場合、開発者は、行６０４に購買者のカテゴリコードを入力するはずである。このコードは、プルダウンメニューによって手動で入力することも、現在のシステム設定を用いて自動で入力することもできる。このカテゴリコードは、この機能によって使用されるプロセスの残りの部分を制御する。一般に、ラベルダイアログ中のカテゴリコードおよび名前空間エントリは、ラベルシステムの現在の設定に従う。データの入力を、図５のブロック５０４に示す。このデータは、通常の表現として入力される。さらに、別の実施形態では、開発者は、サーチを選択されたカテゴリに限定するチェックボックスを選択することによって、サーチを制御することができる。

開発者は、ボタン６５０を選択することによってサーチ機能をアクティブ化する。しかしながら、他の技法を用いてラベルサーチ機能をアクティブ化することもできる。サーチエンジンのアクティブ化を図５にブロック５０５に示す。

ラベルダイアログは、次いで、データベースをサーチして入力されたテキストにマッチするデータベース中のエントリを検索する。サーチプロセスの間、ユーザに進捗標識が表示され得る。１つの進捗標識を、図６に参照番号６４０で示す。サーチが完了すると、進捗表示が消え、ダイアログは開発者に、選択された言語での最初の照会にマッチしたラベルすべての表示を返す。これをブロック５０６に示す。

インターフェース６００は、一実施形態では、図６に示すように識別されたマッチを表示するために拡大される。この実施形態では、表示されるマッチのリストは、ラベルＩＤ表２３０に含まれる情報、ならびにラベルテキスト表２４０からの情報の一部を含み得る。結果ビューは、選択された言語でのテキストを、表２３０への関係を介して利用可能な追加情報と組み合わせて表示する。このサーチの結果は、ＧＵＩＤによる昇順で開発者に提示される。結果の一例が図６の領域６１０に表示されている。しかしながら、テキストマッチングによる昇順など、他の順序付け技法も使用され得る。次いで、開発者は、ラベルテキストのいずれかが所望のテキストにマッチするかどうかチェックする。これをブロック５２０に示す。新しいラベルの所望のテキストにマッチするテキストが見つかった場合、開発者は、所望のラベルテキストにマッチする特定のラベルを強調表示し、あるいは別の方法でそれを指示する。これをブロック５０７に示す。ラベルの翻訳も、必要に応じて６２０に示され得る。

次に、システムは、選択されたラベルカテゴリおよび名前空間が、新しいラベルのカテゴリと同じであるかどうかチェックする。これをブロック５０８に示す。選択されたラベルと新しいラベルの間でラベルカテゴリおよび名前空間が同じである場合、選択されたラベルの情報が新しいラベルに使用される。これを図５にブロック５０９に示す。

ラベルの名前空間およびカテゴリが、新しいラベルの所望の用法と同じでない場合、そのラベルは複製されなければならない。複製された情報は、選択されたラベルのすべての翻訳バージョンも含む。ラベルが新しいラベルに複製されると、ラベルＩＤ表２３０でその新しいラベルに、それがそこから複製されたラベルのＧＵＩＤを示すエントリが作成される。これをブロック５１０に示す。これは、そのマスタラベルテキストが変更されるときに、その新しいラベルのテキストを容易に更新することができるようにする。この変更時の更新は、典型的な検索置換プロトコルを実行することによって、または他の任意の自動化方法によって行われ得る。

サーチの間にマッチが見つからなかった場合、開発者はその新しいラベルに新しいオブジェクトを生成しなければならない。新しいオブジェクトの生成をブロック５２１に示す。ラベルの生成時に、そのラベルの特定の特性がラベルＩＤ表２３０およびラベルテキスト表２４０に格納される。ラベルのテキストが完全でない場合、開発者は、所望のテキストの残りの部分をラベルダイアログ６００に入力する。名前空間およびカテゴリコードは、ラベルシステムの現在の設定に基づいて入力される。開発者は、任意の所望の言語でのそのラベルの翻訳も生成しなければならない。また、ラベルの現在の運用言語のＩＤもマスタ言語として格納される。これらの翻訳の追加または生成およびラベル属性の入力をブロック５２２に示す。

要約すると、各言語ごとに１つのリソースファイルを備えるのではなく、その情報が１：：ｎの関係に分割される。この関係の「１」の側は、ラベル識別子および他の実際的な一般のラベル情報を保持する。この関係の「ｎ」の側は、特定の言語でのラベルテキストを保持する。このようにラベルを構成することにより、実行時にすべての言語でのラベルにアクセスすることが可能になる。

新しいラベルの開発時に、そのラベルは、システム中の既存のラベルを用いて、または新しいラベルを最初から作成することによって複製され得る。ラベルをサーチするとき、式を入力することが可能である（例えば、「＜Ｌｅｄｇｅｒ（元帳）」はＬｅｄｇｅｒで始まるすべての利用可能なラベルをもたらす。しかしながら、システムがどこで実施されるかに応じて、異なる構文が使用され得る。）。サーチされる特定の名前空間またはカテゴリを選択することによりヒット数を低減することが可能である。サーチは、用語データベースを用いることによっても実行され得る。新しいラベルも、用語データベース（Ｗｅｂサービス）を使用することによって作成され得る。用語データベースに入る際には、現在のサーチ基準を、ラベルが使用される実際の状況を記述する追加の基準と組み合わせることが可能である。これは、正しい用語が使用されることを保証するためである。用語データベースでラベルが見つかると、それが新しいラベルに複写される。用語データベースは、すべてのサポート言語についての翻訳を含み、または含むことができる。ラベルが使用されるとき、それはサーチ結果に存在し、実際の名前空間およびカテゴリにマッチする必要がある。これが該当する場合、その特定のラベルを選択することが可能である。これが該当しない場合、手入力で、または用語データベースの別の名前空間／カテゴリからそのラベルを複写することによって新しいラベルが作成される。ラベルを複写することにより、現在の名前空間およびカテゴリに関連する新しい識別子がもたらされる。すべてのテキストおよびその他一般の情報が複写される。

ラベルの管理はラベルダイアログを使用して行われ、これは、直接その特定のラベル属性から呼び出される。このダイアログは、ラベルを維持し、特定の属性で使用するために特定のラベルを選択することを可能にする。コードを介したラベルシステムの使用は、必要とされる機能をもたらすラベルインターフェースを介して行われる。これは、ラベルが格納される仕方を変更することを可能にする。この記憶は、ＳＱＬメタデータストアや、リソースファイルや、Ｗｅｂサービスとすることができる。実際には、それは、Ｗｅｂへの特定のアクセスに応じたすべての種類の記憶の組み合わせとすることができるはずである。

ラベルダイアログは、ラベルが正しい状況で使用されることを保証する。ラベルシステムへのカテゴリの導入は、ラベルが正しく使用されることを保証する。しかし、この機能は別の目的も持つ。ラベルを翻訳するとき、名前空間情報およびカテゴリの組み合わせによって、ラベルがどこで使用されるか調べることが可能である。これは、使用される正しい用語を検索することを可能にする。ラベルがどこで使用されるか知ることは、最良実施例の枠組みにより多くの最良実施例チェックを付加することを可能にする。ラベルダイアログは、既知の（または未知の）翻訳ツールに適合する特定の翻訳ファイルの生成を可能にする。翻訳ファイルに日付情報をエクスポートすることにより、それらの翻訳をインポートするときにその日付をチェックすることが可能になる。これは、進行中の翻訳プロセスが、そのシステムでの最新の変更をとり入れていることを保証するためである。更新された相互参照システムを用いて、特定のラベルがどこで使用されているか調べることが可能である。また、特定のラベルへの変更を調べることも可能である。この機能は翻訳者にとって関係があり、特定のラベルへの変更が単純なもの（例えば、行末に「．（ピリオド）」が付加されたなど）であるかどうか翻訳者が判定できる可能性をもたらすものである。

ラベルをサーチするときに、開発者が、現在のアプリケーションで役立つ可能性のある既存のラベルを識別することは難しい。開発者は、しばしば、そのデータベースにおいて、他の領域に存在する所望のテキストを保持するどんなラベルが利用可能であるか知らないことがある。さらに、開発者は、その用法の正しい情報、およびそのラベルでの用語の適当な翻訳を含むラベルを作成しようとする。

本発明の用語データベースは、追加機能を提供することによってラベルシステムを拡張する。これらの追加機能は、翻訳者または標準機構によって制御され得る。これらの機能は、そのラベルの実際に求められる用法に符合するラベルの検索に役立つように、ラベルダイアログに追加サーチ基準を加えることを可能にする。これらの機能があると、さらに多くの結果が開発者に返され、そのラベルの正しい用語を選択するのに役立つ。開発者は自分の母国語で考えようとするので、これらの機能は、開発者の母国語での１つの単語が別の言語での複数の単語に翻訳され得るときに、ラベルで使用される用語を標準化するのに役立つことになる。

図７は、本発明の一実施形態による、ラベルシステムで使用するための用語データベースを構成する様々なコレクションの間の関係を示すエンティティ関係図である。ラベルシステムは、一実施形態では、前述の図１〜図６で論じたラベルシステムとすることもでき、ワードプロセッサ、Ｗｅｂブラウザなど、用語およびラベルを利用する他の任意のシステムまたはアプリケーションでも使用され得る。用語データベースは、ラベルシステムに類似のものであるが、その他の情報を含む。図７のエンティティ関係図は、図２にエンティティ関係図に類似のものである。用語データベースシステム７００は、言語表７１０、マスタ関係７２０、用語ＩＤ表７３０、および用語テキスト表７４０を含む。一実施形態では、これらのコレクションは、表に構成された構造化照会言語（ＳＱＬ）メタデータストアとして編成される。しかしながら、オブジェクト指向データベースなど、これらのコレクションの他の構成および他のデータベースも使用され得る。

言語表７１０は、少なくとも２つのサブフィールドを含む表である。さらに、言語表７１０は、図２のラベルシステムでの言語表２１０に類似のものである。言語表７１０の２つのサブフィールドは、言語ＩＤフィールド７１１および言語名フィールド７１２である。言語ＩＤフィールド７１１は、特定の言語を示すコードを保持し、ビジネスソリューションソフトウェアプログラムによって理解可能である。言語名フィールド７１２は、言語の名前を保持するテキストフィールドである。例えば、利用可能な言語の１つが英語（ＵＳ）である場合、その言語ＩＤフィールド７１１は、例えば、「０１」とすることができ、ＡＳＣＩＩ標準を使用する場合には、「ｅｎ−ｕｓ」とすることもできる。しかしながら、言語ＩＤフィールド７１１には他のＩＤタイプも使用され、言語をＩＤとして表す言語表とは別個の他の任意の方法も使用され得る。

言語表７１０は、用語テキスト表７４０と１：ｎの関係にある。この関係（１：ｎ）は、データベース７００から利用可能な各言語ごとに１つのラベルテキストエントリを持つことを可能にする。

マスタ７２０は、一実施形態では、ラベル７００のマスタ言語に関連する情報を含む関係である。別の実施形態では、マスタ７２０は、用語の元のバージョンをその元の言語および形式で格納する。マスタ７２０が表である場合、データベース７００中の各用語は、マスタ表７２０に１つの関連するエントリを持つ。各マスタ用語は、マスタ表７２０においてその一意の識別子によって識別される。マスタ７２０と言語表７１０の間の関係は１：１関係であり、用語ＩＤ表７３０もやはり１：１関係にある。というのは、マスタ表７２０中の１つのエントリは、各ラベルごとに１つの言語でのみ存在し得るからである。別の実施形態では、マスタ７２０は、マスタ用語の一意のＩＤを示す用語表７３０の一部である１つまたは複数のフィールドとすることができる。さらに、マスタ言語関係は、一実施形態では、マスタ言語ＩＤと呼ばれるＩＤ表７３０上の１つのフィールドとすることもできる。

用語テキスト表７４０は、ラベルテキスト表２４０と類似のものであり、用語ＩＤによって識別される各用語ごとのテキストを含むエントリを含む。用語テキスト表７４０は、様々な言語での各用語ＩＤごとの翻訳を含むエントリを含む。用語ＩＤ表７３０と用語テキスト表７４０の間の関係、ならびに言語表７１０と用語テキスト表７３０の間の関係は１：ｎである。これは、用語ＩＤ表７３０には各用語ごとに１つのエントリがあるが、１つの用語の各バージョンのテキストは、いくつかの言語で存在し得るからである。しかしながら、本発明の他の実施形態では、用語ＩＤと用語テキストの間の関係は、１：１（またはテキストが存在しない場合は１：０）とすることができ、その場合、マスタ用語の各翻訳は、用語ＩＤ表７３０に独自の一意の用語ＩＤおよびエントリを持つ。

用語ＩＤ表７３０は、本発明の一実施形態によれば、ＩＤフィールド７３１、カテゴリフィールド７３４、記述フィールド７３５、複写元フィールド７３６および状態フィールド７３７を含む。用語ＩＤ表７３０の一例を図７Ｂに示す。

ＩＤ７３１フィールドは、データベース７００中の特定の用語を識別するのに使用される。一実施形態では、このＩＤは、グローバルに一意な識別子すなわちＧＵＩＤである。新しい用語が生成されるたびに、それに新しいＧＵＩＤが割り当てられる。一実施形態では、新しい用語は、単に既存の用語の翻訳としてではなく、データベース７００にとっての新しい用語として定義される。しかしながら、他の実施形態では、ＩＤフィールド７３１の新しいエントリは、既存の用語の翻訳として生成される。

用語ＩＤ表７３０のカテゴリフィールド７３４は、プログラムのどのコンポーネントでその用語が使用されているかを示す特別なフィールドである。さらに、カテゴリフィールド７３４の使用は、開発者が、ラベルテキストを作成するときに、その用語を正しく使用するのに役立つ。カテゴリは、その用語のノードタイプおよび属性に対応する。ノードタイプは、その用語の特定の属性である。ゆえに、カテゴリフィールド７３４は、用語が所望のプログラムに適正に使用されるよう保証することを可能にする。カテゴリは、所望の用語のタイプまたはカテゴリに基づいて、既存の用語のデータベースをサーチすることを可能にする。

記述フィールド７３５は、ユーザまたは開発者に、その用語が特定の状況でどのように使用されているかを記述する表７３０のエントリである。例えば、記述フィールド７３５は、その用語が医療関係の顧客の元帳で使用されていることを知らせるエントリとすることができる。この記述は、言葉で表すこともでき、所定のコードのリストに照合してコード化することもできる。その用語がどのように見つかったかにかかわらず、その使用領域は、領域フィールドを介して入手可能になる。

複写元フィールド７３６は、そのエントリの関連する用語が用語データベース中の別の用語からコピーされ、複写されているかどうかを示す。用語が別の用語から複写されている場合、複写元フィールド７３６は、親またはマスタ用語７２０のＩＤ７３１を含む。一実施形態では、このＩＤは親のＧＵＩＤである。しかしながら、フィールド７３６では他のＩＤも使用され得る。用語が別の用語の複写バージョンではない場合、複写元フィールド７３６は空白であり、またはヌルに設定される。さらに、用語のテキストまたは任意のデータが、複写後にマスタ用語のテキストから変更された場合、複写元フィールド７３６はヌルに設定され、そのため、マスタ用語７２０とこの特定の子用語の間のリンクが削除される。しかしながら、このエントリへの他の変更は、複写元７３６フィールドをリセットさせることになる。別の実施形態では、用語ＩＤ表７３０は、どの用語ＩＤが複写された用語を含むかを示すフィールドを含む。ＩＤ表７３０中の用語は、マスタ用語または子である。用語の各翻訳が独自の一意のＩＤを持つときには、その用語の元の形だけがマスタ用語である。他のすべてのバージョンは子用語である。複写元フィールド７３６が割り当てられているラベルは、特定のＩＤによって表されるマスタに基づいて自動的に更新され得る。

状態フィールド７３７は、用語データベース中の用語の状態を示すフィールドである。用語の状態は、開発者にとって、用語データベースを用いてデータベース中の選択された用語の有用性および信頼性を判定する際に役に立つ。状態フィールド７３７は、用語およびそれに関連する翻訳が、規格協会などのソースと照合して校正されているかどうかを示すことができる。状態フィールド７３７は、その用語を用語データベースに提案したのがだれかも示し得る。これは、開発者が、特定の機関によって作成され、または提案された用語だけを用いようとする場合に役立ち得る。しかしながら、用語ＩＤ表７３０の状態フィールド７３７には、用語データベース中の用語の開発に関連し、またはその用語の信頼性に関連する他の情報も格納され得る。

用語領域７６０は、用語データベース中の特定の用語の用法または領域を定義する領域である。用語領域は、名前フィールド７６１と領域フィールド７６２の２つのフィールドを含む。名前キー７６１は、開発者および翻訳者が、どの領域でその用語が使用されているか調べるのに役立つ。名前キー７６１に含まれる情報は、新しい用語が作成されるときに開発者によって提供され、その特定の用語の用法に関連する情報を提供する。例えば、名前キー７６１は、開発者に、その用語が元帳で、あるいは生産において使用されることを知らせることができる。領域フィールド７６２は、開発者に、その用語が文書またはアプリケーションで使用されている領域に関連する情報を提供する。例えば、領域フィールドは、特定の用語が生産環境で、または医療プログラムで使用されていることを知らせることができる。他の領域では、記述フィールドが、用語の用法に関連する他の情報を提供する。

用語テキスト表７４０は、少なくとも３つの異なるフィールド、すなわち用語ＩＤフィールド７４４、用語テキストフィールド７４１および編集日付７４２を含む。用語テキスト表７４０の一例を図７Ｃに示す。本発明の別の実施形態では、言語別アイコン、ビットマップ、音声、動画などのためのその他のフィールドも用語テキスト表７４０に付加され得る。これら他のフィールドは、そのテキストが書かれている言語を示すフィールド７４３、または用語テキスト表中のテキストの各バージョンのエントリ識別子を識別するフィールドを含み得る。

用語ＩＤフィールド７４４は、特定の用語テキストの用語ＩＤ７３１を識別するフィールドである。このエントリは、開発者およびシステムが、現在のテキストがどの用語ＩＤ７３１に関連するか知ることができるようにする。用語テキストはマスタ言語（または他の任意の言語）から別の言語に翻訳されるので、新しい用語テキストエントリが用語テキスト表に作られる。これらのエントリは、元の用語テキストのそれぞれの言語での翻訳バージョンを含む。編集日付フィールド７４２は、その用語のテキストが、その用語表中の特定のエントリに関連付けられた言語で最後に変更されたのがいつかを開発者が知るために、用語テキスト表７４０に提供される。この日付は、あるテキストの翻訳が提供された場合、それがその翻訳のすでにより新しいバージョンを置き換えないようにするのに役立つ。翻訳が、ジョブまたは他の手段を介してシステムに自動的にロードされるとき、その翻訳日付は比較され、そのエントリのバージョンが提示されたエントリより新しい場合、提示されたエントリは表に入力されない。また、編集日付フィールド７４２は、開発者が、その翻訳がマスタテキストエントリの最新バージョンによるものであるかどうかチェックすることも可能にする。

図８は、本発明の一実施形態による、用語データベースにアクセスしてラベルの所望の用語を検索するときに開発者によって実行される諸ステップを示す流れ図である。本発明の一実施形態では、開発者は、用語データベースへの全アクセス権限を持ち、そのデータベースの用語にアクセスし、それを提案し、付加し、あるいはそこから用語を削除することができる。他の実施形態では、用語データベースへのアクセスは、用語を作成することのできる用語作成者に提供される。この実施形態では、開発者によって用語として提案されたラベルは、用語作成者によって検討され、正しい領域の新しい用語として付加される。

用語データベースでの用語のサーチは、前述の図５のラベルシステム２００によって実行されるサーチと類似のものである。しかしながら、本発明の追加のサーチパラメータは、所望のテキストとマッチしないテキストにもかかわらず、トピック別の結果が表示されることを可能にする。開発者は、普通、前述の図６に示したラベルダイアログと類似の（またはそれと同じ）ダイアログを介して用語データベースにアクセスする。図９に、本発明で使用され得るダイアログウィンドウの一例を示す。しかしながら他のインターフェースを用いて用語データベース７００にアクセスすることもできる。開発者は、ブロック８００でダイアログ９００を開く。

開発者は、ダイアログ９００に、ラベルの所望の用語法またはその一部、ならびにそのラベルのカテゴリおよび領域を入力することによって用語データベースにアクセスし始める。これを図８のブロック８０１に示す。ダイアログ９００でのカテゴリおよび領域の選択は、例えば、プルダウンメニューやチェックボックスの使用によって手動で行うこともでき、カテゴリおよび領域フィールドを設定するためのシステムの現在のコントロールを用いて自動で行うこともできる。また、開発者はこの時点において、例えば、医療状況や生産状況などにおける、その用語の特定の用法を選択することもできる。次に、開発者は、ダイアログウィンドウ上でボタン９５０などのボタンを選択することによってサーチ機能にアクセスする。サーチ機能のアクティブ化を図８のブロック８０２に示す。サーチ機能は、用語データベースを進み、そのラベルの所望のテキストとマッチする用語データベース中のエントリを識別する。

サーチ機能は、結果として用語データベース中の識別されたエントリを集める。サーチ結果はダイアログ９００のセクション９４０で開発者に提示される。次いでその結果が、所定の方法に従って順序付けされ、またはソートされる。一実施形態では、この用語の配列は、テキストマッチングによるものである。しかしながら、特定の使用領域によるソートなど、別のソート方法も使用され得る。ユーザへの結果の提示をブロック８０３に示す。別の実施形態では、開発者はサーチ結果を、所定の状態を持つ用語、すなわち特定のソースによって提案され、または作成された用語に限定することができる。

次いで、開発者は、その結果に所望の用語があるかどうか判定するために結果を検討する。これを図８のブロック８０４に示す。結果が、所望のラベルの正しい用語およびカテゴリとマッチする用語を含む場合、開発者は、ラベルの用語に全く調整を加えずにラベルでその用語を使用することができる。次いで、ブロック８０５でラベルが複写される。正しい用語が結果にはあるが、正しいカテゴリにはない場合、開発者は、どの用語が所望の用語への最も正しいマッチであるか決定しなければならない。その場合開発者は、その用語エントリの記述フィールドに含まれる情報を確認することができる。このフィールドは、開発者にその用語の一般的用法を知らせる。この情報の検討をブロック８０６に示す。

さらに、開発者が結果を検討しているとき、開発者は、用語領域表７６０に含まれる、その用語の特定の用法に関連する情報を確認することができる。開発者が複写される用語を検討しているときには、結果に同じ用語が複数回出現し得る。これは、所望の用語がサーチする言語で複数の意味を持つときにしばしば起こる。例えば、ある英語の単語がスペイン語では複数の同義語を持つことがある。その場合、開発者は、データベースで提供される情報に基づいてどの用語を使用すべきか選択しなければならない。用語領域表７６０の領域フィールド７６２は、開発者に、選択されたカテゴリでのその用語の特定の用法に関する情報を提供する。例えば、英語の「ｃｕｓｔｏｍｅｒ」という語は、その用語の用法に応じて異なる意味を持ち得る。店舗の設定では、「ｃｕｓｔｏｍｅｒ」とは、その店舗から商品を買う人である。しかしながら、医療の状況では、「ｃｕｓｔｏｍｅｒ」とは患者である。したがって、用語領域の使用によって、開発者は、使用すべき正しい「ｃｕｓｔｏｍｅｒ」を選択し、ゆえに、その用語の意図する用法に基づき、所望の用語法によりマッチする用語への翻訳を獲得することができる。用語の特定の情報の検討をブロック８０７に示す。

その用語の用法に基づいて、その用語が開発者の意図にマッチする場合、開発者は、その用語の１つを選択し、その用語を新しいラベルに複写することによって新しいラベルを作成することができる。用語が複写されると、用語ＩＤ表７３０に新しいレコードが生成される。さらに、用語テキスト表中の翻訳すべてがその新しいレコードに複写される。また、元の用語の一意のＩＤも複写元フィールドに格納される。これは、開発者などが、この用語が別の領域に由来するものであることを知るのに役立つ。また、これは、例えば、開発者によってジョブが呼び出されるときなど、マスタ用語が更新されるときに、その用語および関連する翻訳が更新されることも可能にする。この用語の複写を図８のブロック８０８に示す。

所望の用語またはその用語の用法が用語データベース７００のサーチで見つからなかった場合。その場合、開発者は、ブロック８１６で、所望のテキストの独自の拡張を用いて新しいラベルを作成する。開発者は、データベースにその新しい用語を提案することもできる。一般に、開発者は、事実上一般的な用語をデータベースに提案する。開発者は、カテゴリ情報、記述情報、用語領域に関連する関連情報を提供するなど、その用語の要件すべてを記入することによって、用語データベース７００に単語を提案する。これを図８のブロック８２０に示す。

開発者がダイアログ９００上で提案ボタン９５１を選択するとき。これは用語データベースのその新しい用語を送る。用語データベースで用語を受け取ると、用語データベースに提案された用語の新しいエントリが作成される。この時、状態フィールド７３７は提案されているに設定される。後で、この用語が検討されてから、この用語の状態は、検討済みまたはこの用語が用語データベースによって容認されていることを示す他の指示に変更され得る。またこの時、開発者は、その用語の任意の既存の翻訳も用語データベースに提供し、あるいは、翻訳は、後で翻訳によって用語データベースに追加され得る。テキストのすべてがその新しい用語の用語テキスト表エントリに格納される。用語の用語データベースへの提案を、図８のブロック８２０に示す。提案プロセス時に、開発者は、現在提供されている翻訳がその用語の特定の用法について的確ではない場合、既存の用語の更新された翻訳を提供して、データベースを更新することができる。

以上、本発明を特定の実施形態を参照して説明したが、本発明の精神および範囲を逸脱することなく形態および細部において変更が加えられ得ることを、当業者であれば理解されよう。

本発明が使用され得る１つの例示的環境を示すブロック図である。 ラベルシステムを構成する表を示すブロック図である。 ラベルＩＤ表中の各フィールドを示す図である。 ラベルテキスト表中の各フィールドを示す図である。 ラベルシステムのコンポーネント間の関係を示すブロック図である。 新しいラベルが作成されるときに実行される諸ステップを示す流れ図である。 ラベルデータベースを開発し、サーチするときにユーザによって呼び出されるユーザインターフェースの一例を示す図である。 本発明の用語データベースを構成する諸表を示すブロック図である。 用語ＩＤ表中の各フィールドを示す図である。 用語テキスト表中の各フィールドを示す図である。 ラベルの新しい用語をサーチし、または作成するときに実行される諸ステップを示す流れ図である。 用語データベースを開発し、サーチするときにユーザによって呼び出されるユーザインターフェースの一例を示す図である。

Claims (21)

1. 用語データベースを用いて所望の用語を識別する方法であって、前記用語データベースは、
   用語識別（ＩＤ）テーブルと、
   ここで、該用語識別（ＩＤ）テーブルは、サーチ可能な複数の用語について、該複数の用語のうちの各用語に関する用語ＩＤフィールドと、用語がプログラムのどのコンポーネントで使用されているかを示すカテゴリフィールドと、前記複数の用語のうちの各用語が前記プログラムのどのコンポーネントでどのように使用されているかを示す記述フィールドとを含み、
   前記複数の用語のうちの各用語について、用語ＩＤフィールドと、用語テキストフィールドと、言語フィールドとを含む用語テキストテーブルと、
   用語領域テーブルと
   を含み、
   ここで、該用語領域テーブルは、前記用語データベース中に定義された前記複数の用語のうちの各用語について、名前フィールドと、アプリケーションのどこで前記各用語が使用されているかを示す領域フィールドを含み、
   該方法は、コンピュータにより処理されるコンピュータ実行命令であって、
   ダイアログインターフェースを開くステップと、
   前記ダイアログインターフェースにおいてデータを受け取るステップであって、該受信したデータは、前記所望の用語の所望のテキストを示す第１の情報と、前記所望の用語の特定の用法に関連する第２の情報とを含み、
   前記受け取ったデータを用いて前記用語データベースをサーチし、その結果を前記ダイアログインターフェースに表示するステップと、
   前記ダイアログインターフェースに表示された結果の中から、前記記述フィールドを参照して、前記所望の正しい用語と判断され、前記所望の用語の前記テキストにマッチするテキストを有するが、正しいカテゴリではない用語が見つかった場合に、その用語の指定を受け付けるステップと、
   指定された用語を前記所望の用語として前記用語データベースの前記用語テキストテーブルから当該見つかった用語の前記第１の情報に関連する情報を前記用語識別（ＩＤ）テーブル内の新しいラベルに係るフィールドに複写するステップと、
   前記ダイアログインターフェースに表示された結果の中に、前記所望の用語の前記テキストにマッチするテキストを有する用語が見つからなかった場合、前記所望の用語の特定の用法にマッチする用法の用語が見つかった場合には、該用語の指定を受け付けるステップと、
   指定された用語を前記所望の用語として前記用語データベースの前記用語識別（ＩＤ）テーブルから当該見つかった用語の前記第２の情報に関連する情報を前記用語識別（ＩＤ）テーブル内の新しいラベルに係るフィールドに複写するステップと、
   前記ダイアログインターフェースに表示された結果の中に前記所望の用語の特定の用法にマッチする用法を有する用語が見つからなかった場合、前記用語データベースからのデータ以外の新しい用語として、前記所望の用語を前記用語データベース内に格納するステップと
   を具えたことを特徴とする方法。
2. 前記用語データベース内に前記所望の用語の前記テキストにマッチするテキストを有する用語が見つからなかった場合、前記用語データベースをサーチするステップは、前記所望の用語の特定の用法とマッチする用語を求めて前記用語データベースをサーチするステップをさらに具えたことを特徴とする請求項１記載の方法。
3. 前記受信したデータは、
   前記用語のカテゴリコードと、
   前記用語の記述と
   をさらに含むことを特徴とする請求項１記載の方法。
4. 前記所望の用語を前記用語データベース内に格納するとき、前記用語データベースに前記所望の用語の前記テキストの各バージョンを編集日付に基づいて格納するステップをさらに具えたことを特徴とする請求項１記載の方法。
5. 前記用語データベースをサーチするステップは、
   前記用語データベースに格納されたテキストの少なくとも一部を選択するステップと、
   前記選択されたテキストにおいて、該選択されたテキストがどのように使用されているかの指示を識別するステップと、
   前記選択されたテキストの前記指示された用法を前記新しい用語の指示された用法と比較するステップと、
   前記新しい用語の前記テキストおよび指示された用法とのマッチに基づいて前記選択されたテキストを前記選択のために順序付けするステップと
   をさらに具えたことを特徴とする請求項１記載の方法。
6. 前記用語データベース中の、前記新しい用語と類似の特定の用法を有するテキストを前記順序付けに従って選択するステップをさらに具えたことを特徴とする請求項５記載の方法。
7. ユーザインターフェース上に、前記マッチする用語を前記所望の用語を選択するために表示するステップをさらに具えたことを特徴とする請求項６記載の方法。
8. 前記所望の用語を選択したとき、前記用語データベースのテキストに含まれる各識別されたエントリごとに用語を表示するステップをさらに具えたことを特徴とする請求項７記載の方法。
9. 前記用語識別（ＩＤ）テーブルは、前記用語が複写元フィールドに格納された別の用語の複写であることを示すフィールドをさらに具えたことを特徴とする請求項１記載の方法。
10. 前記カテゴリフィールドは、
    用語のノードタイプと、
    用語が使用されるプログラムと、
    用語の属性名と
    をさらに具えたことを特徴とする請求項１記載の方法。
11. 前記用語識別（ＩＤ）フィールドは、ＧＵＩＤであることを特徴とする請求項１記載の方法。
12. 前記複写元フィールドは、現在の用語がそこから複写された用語の前記用語識別（ＩＤ）フィールドを含むことを特徴とする請求項９記載の方法。
13. 前記用語識別（ＩＤ）テーブルは、前記用語が前記用語データベースの別の用語から複写されていることを示すマスタ用語であるかどうかを示すフィールドを含むことを特徴とする請求項１記載の方法。
14. 前記用語識別（ＩＤ）テーブルは、前記用語が規格データとしてのソースデータと照合して校正されているかどうかを示す状態フィールドを含むことを特徴とする請求項１記載の方法。
15. 前記用語テキストテーブルは、
    前記用語テキストフィールドに含まれる元の言語でのテキスト表現エントリと、
    前記テキスト表現エントリの、前記複数の言語の少なくとも１つへの翻訳と
    を具えたことを特徴とする請求項１記載の方法。
16. 前記用語テキストテーブルは、
    前記用語テキストテーブル中の各エントリごとにそのエントリが作成された日付を示す編集日付をさらに具えたことを特徴とする請求項１記載の方法。
17. 前記用語テキストテーブルは、
    前記用語テキストテーブル中の各エントリごとの用語ＩＤフィールドと、
    前記用語が前記用語データベースの別の用語から複写されていることを示すマスタ用語の一意のＩＤを保持するフィールドと
    をさらに具えたことを特徴とする請求項１記載の方法。
18. 前記用語識別（ＩＤ）テーブル、前記用語テキストテーブル、および前記用語領域テーブルは、単一の表にあることを特徴とする請求項１記載の方法。
19. 請求項１ないし１８のいずれかに記載の方法をコンピュータによって実行することが可能なコンピュータ実行命令を有するコンピュータプログラム。
20. コンピュータにより、請求項１ないし１８のいずれかに記載の方法を実行することが可能なコンピュータ実行命令を有するコンピュータプログラムを記録したコンピュータ読取り可能な記録媒体。
21. 用語データベースを用いて所望の用語を識別するシステムであって、前記用語データベースは、
    用語識別（ＩＤ）テーブルと、
    ここで、該用語識別（ＩＤ）テーブルは、サーチ可能な複数の用語について、該複数の用語のうちの各用語に関する用語ＩＤフィールドと、用語がプログラムのどのコンポーネントで使用されているかを示すカテゴリフィールドと、前記複数の用語のうちの各用語が前記プログラムのどのコンポーネントでどのように使用されているかを示す記述フィールドとを含み、
    前記複数の用語のうちの各用語について、用語ＩＤフィールドと、用語テキストフィールドと、言語フィールドとを含む用語テキストテーブルと、
    用語領域テーブルと
    を含み、
    ここで、該用語領域テーブルは、前記用語データベース中に定義された前記複数の用語のうちの各用語について、名前フィールドと、アプリケーションのどこで前記各用語が使用されているかを示す領域フィールドを含み、
    該システムは、
    プロセッサと、
    コンピュータ実行命令を有するメモリと
    を具え、
    前記プロセッサにより処理される前記コンピュータ実行命令は、
    ダイアログインターフェースを開くことと、
    前記ダイアログインターフェースにおいてデータを受け取ることであって、該受信したデータは、前記所望の用語の所望のテキストを示す第１の情報と、前記所望の用語の特定の用法に関連する第２の情報とを含み、
    前記受け取ったデータを用いて前記用語データベースをサーチし、その結果を前記ダイアログインターフェースに表示することと、
    前記ダイアログインターフェースに表示された結果の中から、前記記述フィールドを参照して、前記所望の正しい用語と判断され、前記所望の用語の前記テキストにマッチするテキストを有するが、正しいカテゴリではない用語が見つかった場合に、その用語の指定を受け付けることと、
    指定された用語を前記所望の用語として前記用語データベースの前記用語テキストテーブルから当該見つかった用語の前記第１の情報に関連する情報を前記用語識別（ＩＤ）テーブル内の新しいラベルに係るフィールドに複写することと、
    前記ダイアログインターフェースに表示された結果の中に、前記所望の用語の前記テキストにマッチするテキストを有する用語が見つからなかった場合、前記所望の用語の特定の用法にマッチする用法の用語が見つかった場合には、該用語の指定を受け付けることと、
    指定された用語を前記所望の用語として前記用語データベースの前記用語識別（ＩＤ）テーブルから当該見つかった用語の前記第２の情報に関連する情報を前記用語識別（ＩＤ）テーブル内の新しいラベルに係るフィールドに複写することと、
    前記ダイアログインターフェースに表示された結果の中に前記所望の用語の特定の用法にマッチする用法を有する用語が見つからなかった場合、前記用語データベースからのデータ以外の新しい用語として、前記所望の用語を前記用語データベース内に格納することと
    を実行するように構成したことを特徴とするシステム。

Images