ドメイン内の項目の諸クラスの構造、どの項目がどのクラスに属するかおよびどのオペレーションを各クラスがサポートするかを指示するオントロジー文書を生成する、コンピュータ実装される方法であって:ドメイン内の項目および項目間の関係についての情報を含むドメイン記述を処理エンジンに入力する段階と;前記処理エンジンがデータ構造およびオペレーション構造にアクセスする段階であって、データ構造は前記ドメイン記述において記述される項目を諸クラスに分けて特徴づけるための項目および項目間関係のドメイン独立なモデルであり、データ構造は諸項目のクラスとして少なくとも親項目を含み、各親項目は該親項目がそれに対して呼び出されたオペレーション構造からのオペレーションを受け容れる結果として該親項目によって生成される子孫項目だけを含むことができ、オペレーション構造は、ドメイン記述に適用されたときに諸項目の諸クラスについての処理規則を定義するオペレーションの、ドメイン独立なリストを含む、段階と;前記処理エンジンが前記データ構造および前記オペレーション構造を前記ドメイン記述に適用して、ソフトウェア製品を生成するのに使うオントロジー文書を生成する段階とを含む、方法。親項目の各インスタンスは、項目の特定のクラスのインスタンスである子孫項目だけを含むことができる、請求項1記載のコンピュータ実装される方法。前記オントロジー文書に基づいてURIテンプレートを前記処理エンジンにおいて生成し、該処理エンジンから出力する段階をさらに含み、前記URIテンプレートは、ランタイムにおけるドメイン内のリソースの各インスタンスがHTTPURIを介した参照により取得可能であることを保証するために使うことができ、リソースはフィールドおよび他のリソースへのリンクをもつ項目のクラスを総称する用語である、請求項1または2記載のコンピュータ実装される方法。前記オントロジー文書は、管理可能な包含者のクラスを定義し、該管理可能な包含者クラスのインスタンスは状態親項目を含み、状態親項目が含むことのできる子孫項目は、管理可能な包含者のクラスのオペレーティング状態のあらかじめ定義されたリストのうちの一つを指示するために使われる項目の状態クラスのインスタンスである子孫項目のみである、請求項1ないし3のうちいずれか一項記載のコンピュータ実装される方法。前記データ構造およびオペレーション構造が制約されたエディタによってアクセスされ、前記制約されたエディタは、ユーザーを、前記データ構造およびオペレーション構造が前記ドメイン記述に適用されるような仕方で前記ドメイン記述を入力することに制約する編集環境である、請求項1ないし4のうちいずれか一項記載のコンピュータ実装される方法。前記オントロジー文書を使って生成されるインターフェース明細は、RESTアーキテクチャスタイルにおけるインターフェースの原理と整合する、請求項1ないし5のうちいずれか一項記載のコンピュータ実装される方法。ソフトウェア製品を生成するコンピュータ実装される方法であって、請求項1ないし7のうちいずれか一項記載のオントロジー文書を生成する方法を含み、さらに:前記処理エンジンにおいて、前記データ構造および前記オペレーション構造に基づく規則のセットを前記オントロジー文書に適用してソフトウェア製品を生成する段階を含む、コンピュータ実装される方法。請求項8または9記載のコンピュータ実装される方法であって、前記オントロジー文書は、管理可能な包含者のクラスを定義し、前記管理可能な包含者クラスのインスタンスは状態親項目を含み、前記状態親項目が含むことのできる子孫項目は、管理可能な包含者のクラスのオペレーティング状態のあらかじめ定義されたリストのうちの一つを指示するために使われる項目の状態クラスのインスタンスである子孫項目のみであり、それにより、ランタイムにおける前記管理可能な包含者クラスのインスタンスのオペレーティング状態は、前記管理可能な包含者クラスの前記インスタンスに含まれる前記状態親項目に前記状態クラスのインスタンスを追加することによって管理されるよう動作可能であり、ランタイムにおける前記管理可能な包含者クラスの前記インスタンスの前記状態は、前記管理可能な包含者クラスの前記インスタンスに含まれる前記状態親項目に対する前記状態クラスの最も最近追加されたインスタンスによって指示され、それにより、前記状態親項目に含まれる子孫項目は、前記管理可能な包含者クラスの前記インスタンスの状態履歴である、方法。前記管理可能な包含者クラスのインスタンスは、仮想コンピューティングシステムである、請求項10または11記載のコンピュータ実装される方法。前記ソフトウェア製品が定義された受け容れ制約条件を含み、前記受け容れ制約条件は、ランタイムにおいて、親項目に対してオペレーションが呼び出された結果として該親項目のインスタンスによって生成されることのできる子孫項目の個別的なインスタンスを制約し、前記受け容れ制約条件はクライアントツールに対して利用可能である、請求項8ないし12のうちいずれか一項記載のコンピュータ実装される方法。現在のところ、APIを書き、潜在的可能性としてはそれに続いてそのAPIの個別的実装をするサービス開発者が取っているアプローチは、そのAPIが生成されるドメインに固有で、特定のデータフォーマットに好適な言語の修正または適応されたバージョンを定義することでありうる。たとえば、言語はJSONまたはXMLに基づくことがありうる。このデータフォーマット固有のアプローチは、異なるデータフォーマットは異なる処理規則に従って機能するので、問題である。各ドメインおよび各データフォーマットについてカスタムコードが必要とされるので、共通の処理規則セットを使ってすべてのAPIにアクセスすることができる汎用クライアントの実現は不可能になる。本発明の諸実施形態は、ドメイン内の項目の諸クラスの構造、どの項目がどのクラスに属するかおよびどのオペレーションを各クラスがサポートするかを指示するオントロジー文書を生成する、コンピュータ実装される方法であって、ドメイン内の項目および項目間の関係についての情報を含むドメイン記述を入力する段階と;データ構造およびオペレーション構造にアクセスする段階であって、データ構造は当該ドメイン記述において記述される項目を諸クラスに分けて特徴づけるための項目および項目間関係のドメイン独立なモデルであり、データ構造は諸項目のクラスとして少なくとも親項目を含み、各親項目は該親項目がそれに対して呼び出されたオペレーション構造からのオペレーションを受け容れる結果として該親項目によって生成される子孫項目だけを含むことができ、オペレーション構造は、ドメイン記述に適用されたときに諸項目の諸クラスについての処理規則を定義するオペレーションの、ドメイン独立なリストを含む、段階と;前記データ構造および前記オペレーション構造を前記ドメイン記述に適用して、ソフトウェア製品を生成するのに使うオントロジー文書を生成する段階とを含む、方法を提供する。本発明の発明者は、クライアントとサーバーの間のインターフェースのランタイムでの信頼性を改善するには、プログラマーの活動を単に自動化するだけでは十分ではなく、この目的のために、ドメインをモデリングするオントロジー文書を生成することに向けたアプローチの根本的な再定式化を使うことができるという驚くべき認識に至った。本発明の方法は、この新しいアプローチを具現するものであり、コアとなるドメイン独立なデータ構造およびオペレーション構造をドメイン記述に適用してオントロジー文書を生成する。オントロジーの概念を、ドメイン従属およびドメイン独立な構造および記述に分解することにより、ドメインを横断してのアプローチの一貫性が保証され、任意のドメインについてのオントロジー文書に適用できる想定を、ドメイン独立な構造においてすることが許容される。オントロジー文書は、フォーマットによって制約されず、ドメイン内の諸項目の諸クラスの構造、どの個々の項目がどのクラスに属するかおよびたとえば各クラスがどのオペレーションをサポートするかを指示する情報を含みうる。オントロジー文書はOWLウェブオントロジー言語で書かれてもよい。あるいはまた、オントロジー文書は、単一の文書として形式的にformally呈示されなくてもよく、ドメインのオントロジーの表現に寄与する情報の任意の集合であってよい。本発明を具現する方法によって生成されるオントロジー文書は、ソフトウェア製品artefact生成物を生成するのに使うのに好適である。ソフトウェア製品はコンピュータプログラムまたはコンピュータプログラムのコードまたはソフトウェアコードまたはコンピュータプログラムを生成するために直接使うことのできるプロトコルまたは明細である。ソフトウェア製品は、次のうちの一つまたは複数を含んでいてもよい:クライアントアプリケーション、API、クライアント実装、サーバー側実装、ウェブページ、アプリケーションスケルトンまたは好ましくはインターフェース明細。インターフェース明細interfacespecificationの用語は、ドメイン内のサービスおよび公開されているデータにアクセスするためのプロトコルを含みうる。データおよびサービスは、ドメイン内の項目およびリソースの表現がクライアントアプリケーションまたはサーバー側マッシュアップに関してクライアントの役割を演じるピアサーバーアプリケーションに対して利用可能になっている限り公開されていることができる。その代わりまたはそれに加えて、ドメインまたは完全なポートフォリオサービスにおけるデータおよびサービスは、クライアントアプリケーションによって管理可能である限り公開されていることができる。好ましくは、インターフェース明細の用語は、特定のドメインとの関連付けを含むが、該インターフェースをいかなる特定のクライアントアプリケーションに関連付けたり、該インターフェースをAPIのような明細の特定の実装に制約したりするものではない。インターフェース明細は、たとえば、次のうちの任意のものまたは全部を含んでいてもよい:URIテンプレート;諸項目の諸クラスを含むデータフォーマット;含む、受け容れるおよびその他の型に範疇分けされる、クラス間のリンク;各クラスについての許容可能なHTTPメソッド;どのデータオブジェクトが各クラス上で編集可能か;インスタンスに対してHTTPGETオペレーションが実行されたときに返される、クラスのインスタンスの表現;各クラスの新しいインスタンスを生成できるエンティティ。生成は、POST要求の有効な受け手に対するPOSTオペレーションを介してであってもよい。これはまた、包含者内のどの子リソースが生成されることをクライアントが期待するかを含め、各クラスのインスタンスの生成オペレーションをどのように処理するかについてのサーバー側への汎用命令をも含んでいてもよい;どのクラスが管理可能manageableであるか。インターフェースの用語は、クライアントとサーバーの間のインターフェースを含んでいてもよい。クラスのインスタンスの用語は、ランタイムにおいてドメインに存在する項目であって、そのクラスのテンプレートに従うものを含んでいてもよい。テンプレートは、データ構造およびオペレーション構造をドメイン記述に適用することによって定義される。よって、各インスタンスはクラスに属する。同様に、サブクラスのインスタンスは、そのサブクラスおよび該サブクラスが発生するもとになったクラスに属するインスタンスを含みうる。リソースは、他のリソースへのリンクをもち、フィールドをもち、任意的に削除されることができる項目の汎用クラスを含んでいてもよい。ドメイン記述は、少なくとも、該ドメイン内の項目およびそれらの項目間の関係についての情報を含んでいてもよく、ドメインオントロジーを含んでいてもよい。好ましくは、ドメイン記述は、ドメイン内の利用可能なクラスおよびそれがサポートするメソッドの完全なまたは実質的に完全な表現を含むオントロジー文書が生成されることを許容する仕方で呈示される十分な情報を含む。したがって、オントロジー文書は、該オントロジー文書から、ソフトウェア製品として、少なくとも部分的インターフェース明細が導出される帰納される、演繹されるまたは表面化することを許容する。たとえば、ドメイン記述は、該ドメイン記述内に存在する各クラスおよびサブクラスに属するリソースの包含階層構造がオントロジー文書において表現されることができるような仕方で呈示されてもよい。データ構造の用語は、処理エンジン内で任意的に与えられる、あるいはオントロジー文書を生成する際にアクセスされるデータ構造をいうが、項目および項目間関係のドメイン独立なモデルを含んでいてもよく、ドメイン独立なデータモデルまたはコアデータモデルを含むと考えられることができる。用語データ構造はデータ構造オントロジーを含んでいてもよい。データ構造は、ポスト可能Postable、集合Collection、共有可能Shareable、状態State、削除可能Deletableおよび管理可能Manageableのようなコアとなるドメイン独立なクラスを提供してもよい。処理エンジンにおいてドメイン構造がデータ記述に適用されると、ドメイン内のリソースは、ドメイン独立なクラスまたはそれらのドメイン独立なクラスから発生し、よって該ドメイン独立なクラスの属性を継承するサブクラスのインスタンスとして特徴づけられることができる。オペレーション構造の用語は、処理エンジン内で与えられる、あるいはオントロジー文書を生成する際にアクセスされるオペレーション構造をいうが、ドメイン記述に適用されたときに、所定のクラスに属するリソースに対して実行されるオペレーションをどのように扱うかをサーバーに伝える処理規則を定義するオペレーションのドメイン独立なリストを含んでいてもよく、ここで、これらの処理規則がリソースの状態に基づいて変わることが可能である。用語オペレーション構造はオペレーショナルオントロジーを含んでいてもよい。オペレーション構造は、オペレーションモデルと考えられることができる。オペレーション構造およびデータ構造は、ドメイン独立な情報モデルと称されることができる。ひとたびオペレーション構造およびデータ構造がドメイン記述に適用されると、ドメイン固有情報モデルまたはオントロジー文書が取得されることができ、これはインターフェース明細のようなソフトウェア製品の基礎をなすのに好適である。リソースresourceの用語は、クラスリソースResourceの項目を含んでいてもよい。クラスリソースは、他のリソースへのリンクをもち、フィールドをもち、任意的に削除されることができる項目の汎用クラスである。用語包含者containerは、クラス包含者Containerの項目を含んでいてもよい。クラス包含者は、クラスリソースを拡張しクラスリソースのサブクラスであり、他のリソースを含むことができるクラスである。包含者に対する削除オペレーションは、その包含者およびそれに含まれるすべてのリソースを除去する。用語親progenitorは、クラス親Progenitorの項目を含んでいてもよい。クラス親は、クラス包含者を拡張しクラス包含者のサブクラスであり、子孫Progeny項目を生成することができるクラスである。子孫項目自身も親のインスタンス内でのリソースのサブクラスであり、たとえば親クラスのインスタンスに対して呼び出された実行されたポストpostオペレーションの結果である。クラス親は、データ構造の一部であり、ドメイン独立な概念である。これは、アプリケーション明細を生成するときにドメイン内のどのリソースが親として分類されるかを推定または他の技法を使って識別するためにドメイン記述に適用されることができる。有利には、親項目を含むデータ構造に基づいてオントロジー文書を生成することは、結果として、オペレーション上の用語の誤用により生じる問題が避けられるソフトウェア製品アプリケーション明細のようなの基礎をなすことのできるオントロジー文書を生成する。たとえば、HTTPオペレーションGETおよびPUTの誤用によって生じうるAPIまたは他のソフトウェア製品は、共通の処理規則に従わない、よって特殊なクライアントアプリケーションが、当該APIが生成された対象のドメイン内での公開されたデータおよびサービスにアクセスすることを必要とする。POSTオペレーションオペレーション構造の一部に応答しての親項目データ構造の一部の振る舞いは、親項目自身生成によって新しい項目が追加される包含者であるの性質から自明である。今や親と分類され、POSTオペレーションに応答してのよく定義された振る舞いをもつ当該ドメインの諸部分は、当該ドメインのうち、当該ドメインのためのAPIを生成する開発者によるGETおよびPUTの誤用およびPUTオペレーションの誤用に影響を受けやすかったであろう部分である。本発明の方法により生成されるオントロジー文書に基づくインターフェース明細を実装するインターフェースのようなソフトウェア製品のランタイム信頼性は、従来のインターフェースに対して改善される。任意的に、本発明を具現する方法において、ドメイン記述が処理エンジンに入力され、データ構造およびオペレーション構造が処理エンジンによりアクセスされ、データ構造およびオペレーション構造が処理エンジンにおいてドメイン記述に適用され、オントロジー文書が処理エンジンによって生成される。処理エンジンは、プロセッサを有するコンピューティング装置で実行されたときに、該コンピューティング装置に、ドメイン記述を入力として受け容れる段階と、データ構造およびオペレーション構造をドメイン記述に適用する段階と、インターフェース明細を出力として生成する段階とを実行させるソフトウェアとして実現されてもよい。あるいはまた、処理エンジンは、ドメイン記述を入力として受け容れ、データ構造およびオペレーション構造をドメイン記述に適用してインターフェース明細を出力として生成するよう動作可能なコンピューティング装置であってもよい。あるいはまた、この側面における処理エンジンは、のちに詳述する制約されたエディタとして実行する機能があってもよい。有利には、処理エンジンを使ってデータ構造およびオペレーション構造をドメイン記述に適用する方法を提供することにより、オントロジー文書を生成するアプローチの一貫性が改善できる。好ましい諸実施形態では、親項目の各インスタンスは、項目の特定のクラスのインスタンスである子孫項目を含むことができるだけである。親項目のメンバーシップはさらに所定のクラスの特定の諸サブクラスに、あるいはクラスまたはサブクラス内の個々のものに制約されてもよい。この意味での個々のものとは、所定のクラス内の項目の型である。有利には、このようにして親項目のメンバーシップを制約することは、親項目を扱うために必要とされる処理規則を単純化する。それにより、オントロジー文書が提供するドメインの表現においては、該オントロジー文書に基づいてインターフェース明細を実装するインターフェースのようなソフトウェア製品を走らせる際に使われるべき処理規則は単純であり、よく定義されている。本発明を具現する好ましい諸実施形態は、さらに、オントロジー文書に基づいてURIテンプレートを処理エンジンにおいて生成し、処理エンジンから出力することを含んでいてもよい。ここで、URIテンプレートは、ランタイムにおけるドメイン内の各リソースがHTTPURIを介した参照により取得可能であることを保証するために使うことができる。形式的には不透明であるが、URI普遍的リソース識別子テンプレートは、オントロジー文書に基づくインターフェース明細の実装のようなソフトウェア製品において使用されるURIがオントロジー文書において取り込まれ、ドメイン記述から導出される包含階層構造を反映することを保証するので、有用である。処理エンジンは、先述したのと同じ処理エンジンであってもよい。処理エンジンは、のちに詳述する制約されたエディタおよび変換エンジンの組み合わせとして機能できる追加的な機能をもつ制約されたエディタであってもよい。好ましくは、URIテンプレートのフルセットが生成される。それにより、ドメイン内の項目の各クラスについてのURIテンプレートが利用可能にされる。好ましい諸実施形態では、オントロジー文書は、管理可能な包含者manageablecontainerのクラスを定義する。該管理可能な包含者クラスのインスタンスは状態親項目statesprogenitoritemを含み、状態親項目が含むことのできる子孫項目は、管理可能な包含者のクラスのオペレーティング状態のあらかじめ定義されたリストのうちの一つを指示するために使われる項目の状態stateクラスのインスタンスである子孫項目progenyitemのみである。このようにして管理可能な包含者を定義するオントロジー文書が提供する機構によって、クライアントは、簡単なデータオブジェクト新しい状態項目を状態親項目にポストすることによって、ドメイン内の諸項目の状態を管理できる。たとえば、仮想システムドメイン内の親サーバーserversは、クライアントがPOSTオペレーションを実行する結果として子孫項目サーバーserverを生成できてもよい。この場合、受け容れ制約条件は、オペレーションPOSTについては、子孫項目サーバーが生成されるというものであり、これは、環境変数に関わりなく真であり続ける。別の例では、管理可能なリソースは親状態statesを有していてもよい。親状態は、それに対してクラス状態Stateのサブクラスを指定するPOSTオペレーションが呼び出されるときに、子孫項目として新状態リソースを生成できる。状態親statesprogenitorが状態オフを含むとき、クラス状態のサブクラスであるリソースオンを指定するPOSTオペレーションだけを受け容れるのでもよい。これらの制約条件をクライアントツールに利用可能にすることによって、インターフェース明細は事実上、これらの受け容れ制約条件がクライアントツールに広告されることのできる手段を提供する。広告は、問い合わせに応答してであってもよいし、それ以外であってもよい。たとえば、クライアントツールは、APIを介してアクセスされているドメイン内のリソースが管理可能であることを識別し、該管理可能なリソースの状態を修正するためにどの状態項目が状態親において生成されることができるかを見出すべくサーバーに問い合わせを提出してもよい。上述したように、制約されたエディタは代替的には、処理エンジンの機能として自動化されてもよい。任意的に、データ構造およびオペレーション構造は制約されたエディタによってアクセスされる。制約されたエディタは、ユーザーを、データ構造およびオペレーション構造がドメイン記述に適用されるような仕方でドメイン記述を入力することに制約する編集環境である。制約されたエディタは、オントロジー文書ontologydocumentを生成するために必要とされる専門知識を減らすためにグラフィカルインターフェースを含んでいてもよい。制約されたエディタは、ソフトウェアとして実現されるとき、それ自身が本稿に記載される方法を使って導出されたものでもよく、オントロジー表現ontologyrepresentationがグラフまたは図またはマップといったグラフィカルなフォーマットで構築されることを許容することによってユーザーの行動を制約してもよく、そうしたグラフィカルなフォーマットにおいて、どの段階においても、オントロジー表現に対する許容される追加はデータ構造およびオペレーション構造と整合するものだけである。さらに、制約されたエディタは、連続的にまたは間欠的に、あるいはユーザーの要求の際に、データ構造およびオペレーション構造との整合性を保証するためにオントロジー表現を見直してもよい。入力は、ドメイン記述情報を、制約されたエディタをホストするコンピュータ端末あるいは制約されたエディタはウェブアプリケーションまたはデバイスであってもよいに入力することを含んでいてもよく、ドメイン記述を生成することを含んでいてもよい。好ましい諸実施形態では、オントロジー文書を使って生成されるソフトウェア製品は、RESTアーキテクチャスタイルにおけるインターフェースの原理と整合する。分散式ハイパーメディアシステムのためのRESTアーキテクチャスタイルは、ウェブにおける参加者の適正な振る舞いを支配する、クライアントとサーバーの役割の明確な分離のために、ウェブ開発において好まれている。RESTアーキテクチャスタイルは望ましいが、該スタイルと整合するクライアントとサーバーの間のインターフェースを生成することは時間がかかり、誤りを起こしやすい。本発明のオントロジー文書を導出することに向けたアプローチの再定式化は、オントロジー文書がインターフェース明細を生成する際に使うのに好適であり、RESTアーキテクチャスタイルまたは他のRESTフルなソフトウェア製品に準拠するインターフェースを生じることを、データ構造およびオペレーション構造自身が保証する方法を提供する。ユーザーはREST制約およびスタイルを意識する必要はなく、単にデータ構造およびオペレーション構造に従うことによってREST準拠の明細を生成する際に使うためのオントロジー文書を生成できる。データ構造およびオペレーション構造におけるドメイン独立なレベルでのある種の想定をすることによって、それらの想定項目のある種のクラスに対して実行されるある種のオペレーションの組み合わせについての処理規則のようなは、本発明の方法を使って生成されたすべてのソフトウェア製品を横断して伝わる。データ構造およびオペレーション構造は、許容されるオペレーションと、RESTアーキテクチャスタイルと整合し、よってRESTフルなAPIの生成につながるドメイン内のリソースの表現の仕方とを定義する。本発明に基づく方法は、RESTフルなAPI、RESTフルなソフトウェア製品およびインターフェース明細を開発し、生成するプロセスに対して、データフォーマットおよび対話セマンティクスの使用に関して一貫性を保証する系統的なアプローチを提供する。好ましい諸実施形態はさらに、処理エンジンにおいて、データ構造およびオペレーション構造に基づく規則のセットをオントロジー文書に適用してソフトウェア製品を生成することを含んでいてもよい。本発明の方法を使って生成されたオントロジー文書の内容に基づいて、インターフェース明細を生成するために、オントロジー文書において明示的に述べられていない項目間の関係のような、追加的な属性および情報を推定し、導出するために、規則のセットが適用できる。データ構造およびオペレーション構造をドメイン記述に適用するプロセス全体も処理エンジン内で行われるのであってもよい。それにより、シングルクリックプロセスによってユーザーはドメイン記述からソフトウェア製品を生成できる。この場合のオントロジー文書は、複数のオントロジー情報として実現されてもよく、このオントロジー情報に対して、ソフトウェア製品を生成する際に規則が適用される。あるいはまた、データ構造およびオペレーション構造を取り込むオントロジー文書が、ユーザーにより記憶可能でありアクセス可能である単一のエンティティであり、ソフトウェア製品を生成するために処理エンジンに入力するのであってもよい。この点に関して、処理エンジンは、先に定義された処理エンジンの一部として、変換エンジンを含んでいてもよい。任意的に、本発明を具現する方法は、処理エンジンにおいて、データ構造およびオペレーション構造に基づく規則のセットを入力オントロジー文書に適用してソフトウェア製品を生成することを含む方法であってもよい。オントロジー文書は、形式的なOWL文書として入力されてもよいし、あるいはドメインのオントロジーを表す複数の情報として処理エンジンに供給されてもよい。オントロジー文書は、本発明を具現する方法に基づいて生成されたものであってもよい。さらに、本発明を具現する方法によって生成されたオントロジー文書およびインターフェース明細は、ドメイン独立な構造が適用されるため、異なる型のメディアを扱うことに向けたアプローチの一貫性を保証できる。それにより、リソースの表現を扱うためのXMLスキーマは必要とされない。汎用クライアントツールを任意のドメインとのインターフェースをもつために使うことができることは、本発明を具現する方法の追加的な効果である。すなわち、諸ドメインの範囲を横断して公開されるデータおよびサービスにアクセスするためのクライアントツールであって、各ドメイン内のリソースの表現を扱うための個別の処理規則を必要としないものが、実現できる。ドメイン独立なデータ構造およびオペレーション構造は、クライアントツールが、ドメインから情報を得るために汎用の言語、問い合わせおよび要求を使うことができ、ドメイン内のリソースの表現を扱うために汎用の処理規則を使うことができるというものである。生成されたソフトウェア製品がインターフェース明細であるとき、インターフェース明細はRESTアーキテクチャスタイルにおけるインターフェースのための原理に従ってインターフェースを定義する。ある好ましい実施形態では、ドメイン記述はユーザーによってコンピュータ端末に入力されてもよく、データ構造およびオペレーション構造はコンピュータ上で走っているプログラムによってアクセスされあるいはコンピュータによってリモートアクセスされる、制約された編集環境において入力されたドメイン記述に適用されてもよい。次いで、指定されたフォーマットにおける中間オントロジー文書が生成されてもよく、これ自身も、オントロジー文書に規則のセット推定オペレーションおよび導出オペレーションを適用してインターフェース明細または他のソフトウェア製品を生成するよう動作可能な変換エンジン任意的にはコンピュータ上で実行されるプログラムに入力されることができる。形式的なオントロジー文書の中間生成は省略されることができ、それによりオントロジー文書は形式的な文書ではなく、むしろ制約された編集環境においてデータ構造およびオペレーション構造をドメイン記述に適用した産物となる。インターフェース明細および他の出力が、制約された編集環境内で利用可能にされる。任意的に、本発明の諸実施形態において、データ構造およびオペレーション構造は、生成されたソフトウェア製品がRESTアーキテクチャスタイルにおけるインターフェースのための原理と整合することを保証する。RESTアーキテクチャスタイルの恩恵は十分に文献に示されているが、RESTの制約条件および原理に従うインターフェースおよびインターフェース明細のコーディングは時間がかかり、誤りが起こりやすいものである。本発明の諸実施形態は、ユーザーが、ドメイン記述を生成するためのドメイン知識だけを使ってインターフェース明細を生成する際に使うためのインターフェース明細または文書を生成することを可能にする。本発明のアプローチは、それを、インターフェースについてのオペレーション上の詳細におけるユーザーコントロールおよび柔軟性も最適化されることができるような仕方で行う。ドメイン独立なデータ構造およびオペレーション構造は、それらの構造と整合するオントロジー文書またはインターフェース明細が生成され、それらの構造の恩恵がオントロジー文書において表されている情報モデルに内在的であるようにするために、ドメイン記述に適用される。したがって、ユーザーは、基本的なドメイン独立なデータ構造およびオペレーション構造に内在する恩恵を損なうことなく、一連のアプリケーションにおいてオントロジー文書またはインターフェース明細を自由に利用できる。好ましい諸実施形態では、オントロジー文書は、管理可能な包含者のクラスを定義する。管理可能な包含者クラスのインスタンスは状態親項目を含み、状態親項目が含むことのできる子孫項目は、管理可能な包含者のクラスのオペレーティング状態のあらかじめ定義されたリストのうちの一つを指示するために使われる項目の状態クラスのインスタンスである子孫項目のみである。それにより、ソフトウェア製品またはソフトウェア製品の実装のランタイムにおける管理可能な包含者クラスのインスタンスの状態は、管理可能な包含者クラスのインスタンスに含まれる状態親項目に状態クラスのインスタンスを追加することによって管理されるよう動作可能である。有利には、オントロジー文書が上に定義されたように管理可能な包含者を定義する本発明の諸実施形態は、クライアントツールまたはアプリケーションが、単純なHTTPまたは等価なオペレーションを使ってサーバー側で項目の状態を管理することを許容する。このアプローチは、RESTアーキテクチャスタイルにおけるインターフェースのための原理に準拠する。好ましい諸実施形態では、ランタイムにおける管理可能な包含者クラスのインスタンスの状態は、管理可能な包含者クラスのインスタンスに含まれる状態親項目に対する状態クラスの最も最近追加されたインスタンスによって指示される。それにより、状態親項目に含まれる子孫項目は、管理可能な包含者クラスのインスタンスの状態履歴である。このようにして状態を管理することは、何ら追加的な処理や記憶を必要とすることなく、状態履歴が利用可能になるという驚くべき、望ましい効果をもつ。状態親statesprogenitorにおける状態のリストがHTTPGETオペレーションが状態親項目statesprogenitoritem上で実行されるのに応答して返されるのであってもよい。状態親項目内に保持される状態の数は制約されてもよい。任意的に、管理可能な包含者クラスのインスタンスは、仮想コンピューティングシステムである。仮想ネットワークおよび仮想コンピューティングシステムは、状態管理を必要とし、これはクライアントツールまたはクライアントアプリケーションからであってもよい。有利には、仮想コンピュータシステムが管理可能な包含者クラスとして扱われ、このようにしてオントロジー文書および結果として得られるインターフェース明細において分類される本発明の諸実施形態では、クライアントは、仮想コンピューティングシステムを、RESTアーキテクチャスタイルに準拠する仕方で管理できる。好ましくは、ソフトウェア製品は、定義された受け容れ制約条件を含む。該受け容れ制約条件は、該ソフトウェア製品または該ソフトウェア製品の実装のランタイムにおいて、それに対してオペレーションが呼び出された結果として親項目のインスタンスによって生成されることのできる子孫項目の個別的なインスタンスを制約する。受け容れ制約条件は汎用クライアントツールに対して利用可能である。親項目がクライアントアプリケーションに対して広告できる動的受け容れ制約を定義することが望ましいことがありうるクライアント要求に応答してサーバーが一部またはすべての受け容れ制約条件の詳細を返すことになる。たとえば、状態親項目の次の状態は現在状態に依存することがあり、よって、ある種の状態がある種の他の状態の次にくることがあり、ある種の状態は排除されることがありうる。任意的に、ドメインはクラウドコンピューティング環境であり、ソフトウェア製品はサービスとしてのインフラストラクチャーAPIとして実装されることのできるインターフェース明細であり、あるいはソフトウェア製品はサービスとしてのインフラストラクチャーAPIである。クラウドコンピューティングはインターネットベースのコンピューティングである。デバイスは、互いにリソースを共有し、サービスを提供し合うことができる。デバイスおよびサービスは、公共施設のようにオンデマンド式にアクセスされることができる。実際、本発明の諸実施形態は、サービスとしてのソフトウェアAPI、サービスとしてのプラットフォームAPI、サービスとしてのソフトウェアAPIを生成するためにも使われることができる。具体的に、サービスとしてのインフラストラクチャーでは、コンピュータインフラストラクチャーはインターネット上で利用可能なリソースとして提供される。有利には、本発明を具現する方法によって生成されるインターフェース明細およびオントロジー文書は、RDFResourceDescriptionFramework[リソース記述枠組み]に基づいてデータをモデル化するために作られることができる。RDFは、多様なシンタックスフォーマットを使う、ウェブリソースにおいて実装される情報の概念的な記述またはモデリングのための一般的な方法である。本発明の実施形態によって生成されるオントロジー文書およびソフトウェア製品のRDFバックグラウンドのおかげで、汎用問い合わせ機能がクラウドIaaSAPIまたはクラウドPaaSAPIに追加されることができ、クラウド内の環境条件およびオペレーティング条件に関するライブの情報が、ランタイムにおいて前記汎用問い合わせ機能を用いるクライアントアプリケーションによってアクセスされることを可能にする。本発明は、ドメイン内の項目の諸クラスの構造、どの項目がどのクラスに属するかおよびどのオペレーションを各クラスがサポートするかを指示するオントロジー文書を生成するよう構成されたコンピューティング装置であって、ドメイン内の項目および項目間の関係についての情報を含むドメイン記述を入力する入力手段と;データ構造およびオペレーション構造にアクセスするアクセス手段であって、データ構造は当該ドメイン記述において記述される項目を諸クラスに分けて特徴づけるための項目および項目間関係のドメイン独立なモデルであり、データ構造は諸項目のクラスとして少なくとも親項目を含み、各親項目は該親項目がそれに対して呼び出されたオペレーション構造からのオペレーションを受け容れる結果として該親項目によって生成される子孫項目だけを含むことができ、オペレーション構造は、ドメイン記述に適用されたときに諸項目の諸クラスについての処理規則を定義するオペレーションの、ドメイン独立なリストを含む、手段と;前記データ構造および前記オペレーション構造を前記ドメイン記述に適用して、ソフトウェア製品を生成するのに使うオントロジー文書を生成する生成手段とを有する装置として具現されてもよい。入力手段は、たとえば別のプログラムまたは装置からまたはユーザーから入力を受け容れるための手段を含んでいてもよい。コンピューティング装置は、本稿の他所で記述される制約されたエディタであってもよい。図1は、本発明を具現する方法において使用されるアプローチの概念マップである。抽象的なオントロジー10はいかなるアドレッシング可能な形において存在するのでもなく、オントロジーの一般化された概念であるオントロジーとは存在するものである。抽象的なオントロジー10から延びる矢印は、オントロジーの抽象化から実際のオントロジーこれはたとえばドメインを定義できるに移行するためには、ドメインオントロジー、データ構造オントロジーおよびオペレーショナルオントロジーの三つの側面が考慮されることができるという発想を表している。換言すれば、何らかのドメインに存在しているものは、本発明を具現する方法によって拡張され、ドメインオントロジー、データ構造オントロジーおよびオペレーショナルオントロジーを用いて考えられることができる。ドメインオントロジーはドメイン固有言語、項目および関係であり、これらはドメイン記述によって何らかの可読なまたは使用可能な形で記述されてもよい。好ましくは、それはユーザーによって入力されるドメイン固有情報である。特に、ドメインオントロジーは、ドメイン内の項目を、項目のクラスおよび項目のサブクラスならびにそれらのクラスおよびサブクラスが関係している関係の性質として記述してもよい。オペレーショナルオントロジーおよびデータ構造オントロジーは、すべてのドメインについての汎用の関係、規則および想定を定義するドメイン独立な側面である。データ構造オントロジーおよびオペレーショナルオントロジーのコンポーネントは、拡張されたドメインについての完全な情報モデルを与えるために使われることのできる構成ブロックのためのテンプレートと考えられることができる。データ構造オントロジーは、項目のクラスどうしの間の関係リンクの、含む受け容れるおよびその他への範疇分けを含んでいてもよい。すなわち、項目のクラスAと項目のクラスBとの間の関係は、含むと範疇分けされうる。これはすなわちAがBを含むことを意味する。ドメインにおいて、項目aクラスAに属するおよび項目bクラスBに属するは、リンクされていれば、aがbを含むという関係を介してリンクされることができる。換言すれば、クラスAはクラスBの項目を含みうる包含者containerである。項目のクラスAが受け容れると範疇分けされる関係を介して項目のクラスBにリンクされ、したがって、そのドメインにおいて、項目aが項目bを受け容れることができるということが真であることもある。換言すれば、クラスAの項目はクラスBの項目を受け容れることができる。データ構造オントロジーのコンポーネントは、スロットと称される項目のクラス上で公開される単純なデータ項目を含む属性であってもよい。この意味における公開とは、スロット内にあるデータ項目が、編集するために編集可能なスロットあるいは単に表現を取得するために読み出し専用スロットクライアントによってアクセス可能であることを意味する。データ構造オントロジーの他のコンポーネントは次のものであってもよい:項目のクラス上でどのHTTPメソッドが許容されるかのリスト;リソース上でHTTPGETオペレーションが実行されるときに返される該リソースの表現;特定のリソースの新しいインスタンスを生成する役割を担うエンティティ。これはそのリソースが生成されるPOSTオペレーション要求を有効に受領することのできるリソースであってもよい有効な受領者はクラス親Progenitorおよび集合Collectionのものである。推定により、そのような有効な受領者がデータ構造オントロジーに親としてフィットすることがわかる;一般に、包含者内に新しいリソースを生成する効果をもつオペレーションをサーバーがどのように処理するべきか;どのリソースが削除可能か;どのリソースが管理可能manageableか。オペレーショナルオントロジーは、GET、POST、DELETEおよびPUTのような、メソッドの、コアのドメイン独立なリストと、これらがサーバーによってどのように扱われるべきかについての処理規則とを提供する。任意的に、オペレーショナルオントロジーは、当然のこととしてはドメイン記述に適用されないが特定のドメインについて必要とされる場合には使用されうる追加的なメソッドまたはオペレーションを含んでいてもよい。しかしながら、RESTアーキテクチャスタイルの原理と整合する本発明の諸実施形態では、オペレーションGET、POST、DELETEおよびPUTはオペレーショナルオントロジーに含まれることが含意されている。オペレーショナルオントロジーはより多くのオペレーションをもって拡張されてもよいが、異なるオペレーションの数を最小限に保つことが望ましい。データ構造オントロジーおよびオペレーショナルオントロジーはブラックボックス中でドメインオントロジーに適用される。ブラックボックスは、処理エンジンの役割を実行し、オントロジーの諸側面を取り入れて、インターフェース明細抽象API30を生成する。ブラックボックス内の手順は自動化されることができるが、ある種の段階ではユーザー入力が必要とされることも可能である。ドメイン独立なデータ構造オントロジーおよびオペレーショナルオントロジーをドメインオントロジーに適用する、ブラックボックス内で生起する機構は、次のうちの一つまたは複数を含む技術的プロセスである:ドメインオントロジーならびにドメイン独立なデータ構造オントロジーおよびオペレーショナルオントロジーから導出可能な推定規則に基づく、ドメインについての追加的情報を推定するための推定オペレーション――追加的情報はドメインオントロジーにおいて明示的に与えられていないがそれから導出可能である;集合として表された項目のクラスのメンバーシップ基準を計算するための、ドメインオントロジーにおいて表されている属性からの推論;クラス等価属性を使って、ブラックボックスはドメイン内の項目の各クラスについてクラス等価を計算する。これは、ブラックボックスが、たとえば、あるクラスが親クラスであると推定することを許容する。すると、ブラックボックスは、インターフェース明細および他のコード製品のような出力を生成するときに特定のパターンをたどることを知る;項目の各クラスにどのスロットが存在するかを計算することを含む、各クラスのビューの構築。項目の各クラスについて、関連付けられた属性の列挙が計算される。スーパークラス属性から継承された属性についてすなわち、クラスAが属性Xをもち、クラスA1がAのサブクラスであり、よってクラスA1は属性Xを継承する、最も導出された属性だけが選択される。ブラックボックス内でドメイン独立なオペレーショナルオントロジーおよびデータ構造オントロジーをドメインオントロジーに適用するプロセスの一部は、再帰的なプロセスとして記述できる。該再帰的プロセスにおいては:ドメインオントロジー内の項目の各クラスについて、そのクラスが親クラスであれば、生成側面をもつオペレーションPost[ポスト]、Copy[コピー]、Move[移動]をそのクラスに関連付け、あるいは非生成オペレーションGet[ゲット]、Put[プット]およびDelete[削除]を非親項目に関連付ける;項目のクラスが親クラスであれば、生成側面をもつ各オペレーションについて、その親がいつオペレーションを受け容れるかに関連付けられた何らかの基準を同定する;問題の親の子孫項目を生成するために必要とされる情報を含む、そのオペレーションに関連付けられた引数型を定義する。コード生成器40は本発明の実施形態に任意的に含まれるもので、ブラックボックス20によって生成されるインターフェース明細抽象API30に基づいてXMLコード、APIまたは他のソフトウェア製品のうちの一つまたは複数を生成できる。図2は、クラスの型どうしの間の関係とそれらがサポートするオペレーションを示す図である。図2では、クラスは楕円の外形を、インスタンスは長方形の外形を与えられている。矢印はクラス間またはクラスとオペレーションの間のリンクを表し、単語は関係の型を範疇分けするものである。図2から、クラスオペレーションがあることが見て取れる。オペレーションの型はget、post、putおよびdeleteである。クラスGetableは型getのオペレーションをサポートする。つまり、クラスGetableに属する項目は、getオペレーションが実行されることができる。クラスGetableがgetオペレーションをサポートするのと等価な仕方でpostオペレーションをサポートするクラスPostableがある。同様に、クラスPutableはputオペレーションをサポートし、Deletableはdeleteオペレーションをサポートする。ResourceリソースはGetableのサブクラスである。すなわち、クラスResourceに属する項目resourceは、上位クラスGetableからオペレーションgetをサポートする属性を継承しているので、本来的にGetableである。ResourceのサブクラスであるクラスContainer包含者が与えられており、よってその上位クラスResourceからオペレーションgetをサポートする属性を継承する。クラスContainerに属する項目は、含む関係によってクラスResourceに属する項目にリンクされることができる。すなわち、container項目はresource項目を含むことができる。クラスProgenitor親は、クラスContainerのサブクラスであり、よってやはりオペレーションgetをサポートする属性を継承する。クラスProgenitorはクラスPostableのサブクラスでもあり、よってオペレーションpostをサポートする属性を継承する。クラスProgenitorのこれら二つのサブクラス関係は、クラスProgenitorの項目がPostableContainerポスト可能な包含者とも呼ばれることができることを意味する。Progenitorクラスは、resource項目を含むことができるのは、resource項目が、そのprogenitor項目についての子孫項目として定義されるresourceの型またはresourceのサブクラスである場合にのみであるという点で、Resourceクラスと特別な関係をもつ。その関係は、hasprogeny子孫をもつ関係であり、よってprogenitorはresourceを子孫progenyとしてもつ。この関係を支配する処理規則は、含むリンクを支配する処理規則とは異なる。さらに、クラスProgenitorはクラスResourceにacceptsprogeny子孫を受け容れと記される関係を介してリンクされている。この関係は、progenitor項目が、特定の型またはサブクラスのresource項目がprogenitor項目にポストされることを要求するpostオペレーションを受け容れることができることを表し、それに応答してprogenitor項目は子孫項目として問題のresource項目の型のインスタンスを生成できる。クラスResourceは、クラスContainerと同様、HTTPオペレーションGET、DELETEおよびPUTをサポートする。クラスProgenitorはHTTPオペレーションGET、DELETE、PUTおよびPOSTをサポートする。図3は、ドメイン固有知識1をインターフェース明細6に転換するプロセスおよび中間段階を表す図である。最初、ドメイン知識1が操作されて諸オントロジー3にされる。ドメイン知識1と諸オントロジー3の間の相違は、事実上、オントロジー3はドメイン知識1を取り込み、それをドメイン独立なデータ構造およびオペレーション構造と整合する仕方で呈示するということである。変換エンジン4これは図1のブラックボックス20およびコード生成40を組み込んでいるは、データ構造オントロジーおよびオペレーショナルオントロジーから導出された規則のセットをオントロジー3に適用してアプリケーションスケルトン5およびインターフェース明細6を生成することができる。ドメイン知識1からオントロジー3を形成するプロセスは、インターフェース明細6を生成するために十分なドメイン知識1があることを保証するためにも使われることができる。ドメイン知識1からオントロジー3を生成するプロセスは、制約されたエディタ2を使って実行されてもよい。ドメイン知識は、クラス定義およびクラス間のリンクを記述する仕方を含んでいてもよい。クラス間のリンクを記述する仕方はリンクの属性を含む。オントロジー3はドメイン独立データ構造およびオペレーション構造と整合する。実際、オントロジー3は、ドメインオントロジー、データ構造オントロジーおよびオペレーショナルオントロジーであってもよい図1に示されるように。すなわち、ドメイン内の諸項目の諸クラスおよびそれらの間の関係およびそれらがサポートするオペレーションは、図2に例示したデータ構造およびオペレーション構造および/または図1に関係してデータ構造オントロジーおよびオペレーショナルオントロジーとして記述された構造に基づいている。形式的に、諸オントロジー3は統一され、OWLウェブオントロジー言語で呈示されてもよい。制約されたエディタ2は、ユーザーが、オントロジー文書をどのようにして形式的に構築すべきかを知る必要なしに、何らかの文献記載されたフォーマットで、たとえばOWL文書としてオントロジー3を生成することを許容する編集環境である。制約されたエディタ2はグラフィカルインターフェースを含んでいてもよく、該グラフィカルインターフェースにおいて、ドメイン知識が、事実上構築ブロックを形成する基本的クラスのセットに適用されることができる。制約されたエディタは、ユーザーを、ドメイン独立なデータ構造および/またはオペレーション構造と整合するオントロジー3を生成することに拘束することができ、あるいはオントロジー3がそのように生成されることを強制してもよい。諸オントロジー3は概念的に異なっているドメイン独立なオントロジーとドメイン従属なオントロジーがあるが、これらのオントロジーを統合する単一の文書として、あるいはドメイン独立なオントロジーおよびドメイン従属なオントロジーの組み合わせから帰結する多数の情報として呈示されてもよい。普遍的な対話セマンティクスおよびモデリングパターンがドメイン独立なデータ構造およびオペレーション構造これらはまとめてコアオントロジーまたは一般オントロジーと称されることもできるに取り込まれる。特定のドメインについてのオントロジー3を生成することは、データ構造およびオペレーション構造をインポートし、参照することを含んでいてもよい。オントロジー3から実装可能なインターフェース明細6および他の製品5サーバー側実装コードの諸ビットへのステップは、変換エンジン4内で行われる自動化されたプロセスであってもよい。対話セマンティクスinteractionsemanticsは、ドメインの全体的なランタイム状態をインターフェース明細を実装するAPIのインターフェースを介していかにして変更できるかを指定する規則と考えることができる。ドメインのランタイム状態はグラフたとえばリソースおよびリソース間のリンクのマップによって表現できる。普遍的な対話セマンティクスは、一般的な用語において、グラフの形を変えるためにクライアントができることを取り込み、これらはその後、たとえば制約されたエディタ2によって、特定のドメインに適用されることができる。対話セマンティクスの例は、どのクラスが削除されることができるかおよびどのようにして新しいリソースが追加できるかを指示することを含む。制約されたエディタ2は、ドメイン独立なデータ構造およびオペレーション構造の制約およびパターンをエンコードおよび表現できるグラフィカルエディタとして実現されてもよい。その際、オントロジー3において取り込まれるユーザーのドメイン知識が、データ構造およびオペレーション構造の規約に従う。制約されたエディタ2を用いるユーザーは、OWLのような言語を使ってドメインを表現するオントロジー文書を生成する複雑さから効果的に隔離される。制約されたエディタをバイパスする場合、ユーザーは自分で、データ構造およびオペレーション構造の制約条件が従われていることを保証する必要がある。変換エンジン4による変換のプロセスは、アプリケーションスケルトンのコードおよびインターフェース明細を生成してもよい。アプリケーションスケルトンは、インターフェース明細の機能する実装に向けての出発点として使用できる。そのような実装のプログラミングスタイルはイベント駆動であり、オントロジー3のクラスにイベントハンドラが取り付けられる。ここで、本願では、ドメインdomainは環境environmentの一般的な型を表すために使われていることを注意しておくことが有用であることがありうる。特定のプロバイダーのドメインは環境と称されることになる。よって、ドメインは環境の抽象化である。ドメイン独立なデータ構造およびオペレーション構造の確立は、異なるドメインを横断して繰り返し生起する観察から、構造中に組み込まれるべきパターンを抽出することによって可能にされる。データ構造およびオペレーション構造はこれらのパターンを形式化する。データ構造およびオペレーション構造において形式化されるいくつかの有意なパターンについてこれから述べる。図4のAでは、クラスおよびサブクラスの性質が示されており、属性受け容れるおよび含むが例示されている。図4のAないしCにおいて、長方形はクラスを示し、角丸のボックスはクラスのインスタンスを表す。図4のAにおいて、Bはクラスであり、サブクラスBxおよびByはクラスBに属する。Aは図4のAには示されていないクラスであるが、項目aはクラスAのインスタンスである。項目b1およびb2はクラスByのインスタンスである。図4のAのオブジェクト間の関係は、矢印および付随するテキストによって表されている。先述したように、クラスBxおよびByはクラスBのサブクラスである。クラスAのインスタンスは、この時点で、クラスBx内の項目を受け容れる。しかしながら、それより前の時点では、AはクラスByを受け容れた。項目aはクラスAのインスタンスであり、オペレーションメソッドGETおよびPOSTをサポートする。つまり、クラスAはゲット可能getableかつポスト可能postableなサブクラスである。項目aは項目b1およびb2を含む包含者である。b1およびb2はいずれもクラスByのインスタンスである。項目b1およびb2はオペレーションGETをサポートし、リソースもそうである。含むは属性であり、二つの項目間の関係の型である。包含の原理は、所与のドメインに内在する階層構造を画定する。属性含むは、同じドメインのサブクラスに適用されるべきであり、どの項目が何を含むことができるかの範囲は、問題のドメインに依存してさらに制約されてもよい。属性としての包含者の使用は、二つのクラスの間の関係の包含特性を示す。含まれる項目要素へのリンクのセットをホストするリソースは、暗黙的に包含者である。図4のAにおいて、項目aはクラスAのリソースであるそれはオペレーションGETをサポートする。ドメインのオントロジー図4のAにおけるドメインは抽象的であるは、クラスAとそれが含むことのできるリソースの型との間の含む関係を宣言する。この場合、クラスAは、クラスBおよびそのサブクラスをもつリソースを含むことができるこのことは図4のAだけから導出できるものではないが。項目aはGETおよびPUTの両方をサポートするので、親項目である。項目の集合collectionであるほか、包含者は、該集合に新しい要素を受け容れることもできてもよい。包含者aがPOSTをサポートし、よってクラス親に属すると分類することは、クラスAのインスタンスが諸項目を受け容れることができると指定する。要求はエンティティであり、要求はPOSTオペレーションを介して親によって受領される。要求エンティティは、親aにおける集合中に入れられるべきリソースを記述する。受け容れられる場合受け容れる関係に適用される基準があってもよい、新しい実際のリソースが生成され、集合中に入れられる。いくつかの場合には、受け容れポリシー要求エンティティに適用される基準がランタイムにおいて、たとえば環境変数およびリソースの状態に基づいて、さらに制約されることができる。しかしながら、含むポリシーは、何が集合内のメンバーとして現れるかについての設計時の制約である。たとえば、管理可能なリソースのライフサイクルがリソースに関連付けられた状態の集合を通じて制御されるとき、状態集合は一般に状態stateリソースクラス状態Stateのリソースを含むことができ、そのライフサイクルの特定の時点において、それを開始するstartためのStartStateリソースStateのサブクラスを受け容れることができる。属性受け容れるは、所与のポスト可能な包含者postablecontainer親リソースについて、このランタイムのメンバーシップ情報を宣伝するために使われる。図4のBは、リンクするクラスの概念を示している。図4のBにおいて、項目aはクラスAのインスタンスであり、オペレーションGETおよびPOSTをサポートする。項目aは、オペレーションGETおよびPOSTをサポートするので親項目である。項目blink点滅はリンクするクラスのインスタンスである。項目bはクラスBのインスタンスである。項目aは項目blinkを含み、blinkは項目bにリンクされている。包含は、含まれるリソースの観点からは、二つの項目の間の関係に、排他性があることを含意する。二つの別個のリソースが論理的に同じ特定のリソースを含みうるように見える場合には、モデルは因子分解され直す必要がある。この状況を扱うためのアプローチが、リンクするクラスを導入することである。図4のBに示される例では、各blinkリソースはクラスAをもつ単一のリソース内に排他的に含まれる。その結果、クラスBをもつリソースbはクラスAの複数のインスタンスに関連付けられることができる。図4のCは、非均一な要素の包含を宣言するクラスを扱うために包含の追加的な層を使う概念を示している。図4のCにおいて、項目aはクラスAのインスタンスであり、オペレーションPOSTをサポートする。項目bはクラスBのインスタンスであり、オペレーションPOSTをサポートする。項目cはクラスCのインスタンスであり、オペレーションPOSTをサポートする。項目aは項目bおよびcを含む包含者である。項目cは項目c2を含む包含者であり、項目bは項目d1およびd2を含む包含者である。非均一な項目の包含を宣言するクラスについては、本発明のデータ構造およびオペレーション構造はオントロジーを、その階層構造中に、包含者クラスの追加的なセットを含むよう制約してもよい。包含者内部の要素が均一であることを保証するためである。これは、均一なクラスのインスタンスが、ランタイムにおいて共通の処理規則を使って扱うことができるので、有利である。包含者において要求すべき均一性のレベルに関する決定は、データ構造中に変更できないよう組み込まれてもよいし、あるいはユーザーアプリケーション開発者に任されてもよい。しばしば、包含者中への有効なエントリーを指定するために、有効なスーパークラスが使われる。データ構造およびオペレーション構造は、情報モデリング空間においてこれらのパターンを使うことオントロジー生成プロセスに向けたアプローチを形式化し、それによりオペレーションレベルでのソフトウェア製品たとえばHTTPベースのAPIが許容される。オントロジーからインターフェース明細および他の製品への変換は、インターフェース明細を構築するために、推定inferencingおよび推論reasoningといったいくつかの内部プロセスを必要とする規則のセットがオントロジーに適用される。図5Aないし図5Dは、オントロジー生成へのアプローチが、仮想システムのグループについてオントロジーを生成する場合にどのように適用されうるかを例示している。VSYSs100は親項目であり、その子孫項目はVSYS110a~cの項目である。VSYSs100の表現を受け取るHTTPGETオペレーションは、たとえば、VSYSs100に含まれるVSYS子孫項目110a~cのリストを返してもよい。VSYSs項目100に対して実行されるHTTP削除オペレーションは、含まれるVSYS項目110a~cのすべてを再帰的に除去し、VSYSs100項目を除去してもよい。図5Bは、VSYSs項目100に対して実行されるHTTPPOSTオペレーションを示している。クライアントアプリケーションが、HTTPPOSTオペレーションを使った要求エンティティ111をVSYSs項目100に提出する。要求エンティティ111のボディは、生成されVSYSs項目100内に含まれることを望む子孫項目この場合VSYS項目を記述する。次いでサーバーは、親VSYSs100内に新しいVSYS項目100dを生成し、その新しい項目にURLを割り当てる。VSYSs100は、その子孫項目はクラスVSYSの項目であるという制約条件をもつ親項目である。図5Aないし図5Dに表されるオントロジーが生成される仮想コンピューティングドメインのコンテキストでは、新しいVSYS子孫項目をポストすることは、現実には、コンピューティングリソースの既存のグループ内に仮想システムを創り出してもよく、該仮想システムは、クライアントアプリケーションによって完全なVSYS仮想システムとして扱われてもよい。図5Cは、クラスVSYS110の項目についての枠組みを与えている。VSYS100仮想システムは、五つの親progenitor、ネットワークNetworks120、スナップショットSnapshots130、EFMs140、VサーバーVServers150および状態States160を含む包含者項目である。VSYS110はまた、他の項目へのリンクのリスト180を含んでいてもよい。該リンクは図5CのVSYS110の場合には、VSYSDescriptor項目へのリンクであり、basedOnクローズclauseによって特徴づけられている。さらに、VSYS110は、単純なデータオブジェクトを含むフィールドのリスト190を含む。これらのフィールドはスロットとも称されることができる。フィールドは編集可能であっても、読み出し専用であってもよい。この例では、creationTime生成時刻フィールドは読み出し専用であり、その一方、description説明フィールドは編集可能である。descriptionフィールドの編集を可能にするために、VSYS項目110上で編集リンクが公表される。編集リンクは、descriptionと呼ばれる編集可能なフィールドがあるという事実を、クライアントアプリケーションに利用可能にする。次いで、HTTPPUTオペレーションを使ってフィールド値を編集できる。図5Dは、状態States親項目160を詳細に示している。状態親項目160はVSYS包含者110に含まれる。状態親項目160は、それが含まれているVSYSインスタンス項目110の状態を管理するためのリソースである。状態親項目160に追加された最も最近の状態項目はRunning実行状態162であった。状態親項目160は、クラス状態Stateに属する項目を生成する要求のみを受け容れることができることによって、制約される。したがって、VSYS110は、状態項目Runningに関連付けられた状態にある。クラス状態に属する項目の二つの例は、実行162および移行Migrating163である。状態親項目160内にクラス状態の新しい項目を生成し、よって状態親項目160を含んでいるVSYS項目110の状態を変えるために、状態親項目161に対してPOSTオペレーションが実行されることができる。クライアントアプリケーションは、HTTPPOSTオペレーションを使って要求エンティティ161を状態親項目160に提出することによって、VSYS項目110の状態を管理できる。要求エンティティ161のボディは、生成されることを望む子孫項目この場合、移行状態項目を記述する。状態親項目160は、要求エンティティ161を受け容れ、状態親項目160内に新しい移行状態項目163を生成できる。ひとたび移行状態項目163が生成されると、VSYS110は移行状態になる。実行状態項目162は、状態親項目160内に保持されるので、VSYS110の状態をこのようにして管理することにより、状態親項目160内で状態履歴が維持される。新しい状態のオペレーション詳細はサーバーによってホストされてもよく、よって要求エンティティ161は、新しい状態の有効な名前しか含まないことができる。任意的に、非瞬間的な状態変化をサポートする非同期的な状態管理が想定される。図6は、クラウドコンピューティングドメインにおけるコンピューティングシステムがどのようにしてデータ構造に基づいて表現されうるかの例である。システムリソース200はネットワークリソース210これはネットワークへのリンクである、名前フィールド220これは読み出し専用であるおよびサーバーServerリソース231a~cを含むサーバーServers親項目230を含んでいる。サーバー親項目230は、新しいサーバー項目をPOSTする要求を受け容れ、応答して、新しいサーバーリソースを生成する。サーバー230は、サーバー数に対する所定の限界に達したときに新しいサーバーをPOSTする要求を受け容れるのを止めてもよい。図7Aないし7Cは、本発明の諸実施形態に方法を実行するためのコンピュータプログラムによって出力される表示の表現を呈示している。表現されているドメインは、クライアントが、要求を介してサーバー上の集合にノートPostieを追加できるドメインである。サーバーは集合Posties中にノートを記憶する。図7AないしCにおける、オントロジー文書およびインターフェース明細が生成されたドメインは、二つのクラスPostieおよびPostiesが存在する単純なドメインである。この例におけるドメイン知識は、ドメインを記述する単純事実の呈示であってもよい。たとえば:postie項目はposties包含者に記憶されることができる;postie項目は削除されることができる;postie項目はposties包含者内に生成される;postiesおよびpostie両方の表現がクライアントに返されることができる、といったことである。図7Aは、ドメインビューを表している。これは、グラフィカルドメインオントロジー表現301を探索するためのルート表示である。これは、上に詳述した単純な事実の一部またはすべてを取り込む、OWL文書または他の何らかのオントロジー文書から導出されたものであってもよい。ドメインビュー表現301は、本発明のデータ構造およびオペレーション構造が適用されたドメイン知識を表現する。図7Aないし7Cに描かれるビューは、インターフェース明細の最終的なビューを表していることを注意しておく。これは、コード生成コード生成器40または変換エンジン4のいずれかからの出力の可能な形を例示する。メニューバー340は、ドメインオントロジー表現301の、特定のクラスまたは他の要素に焦点を当てる他のビューへのリンクを含む。ビューの右側では、説明文領域351がそのドメインを要約する何らかのテキストを表示する。メニューバー340において、すべて表示ボタン341は、図7Aに表示されるドメインビューにリンクし、Postiesボタンは図7CのPostiesビューにリンクし、Postieボタンは図7BのPostieビューにリンクする。メニューバー340はすべてのビューにおいてアクセス可能である。ドメインビューにおいて、ユーザーがそのドメインの全体的な記述を与えることのできる説明文領域351が設けられる。ドメインオントロジー表現が生成されたプロセスに依存して、以前の何らかの段階でユーザーによって入力されたドメイン記述に基づいて、コンピュータプログラムが自分で説明文領域のためのテキストを導出できるのであってもよい。この例では、説明文351はたとえばこれは単なる例。個々のpostieを含むpostieの集合がある。Postiesは親であり、postie項目を生成する命令を受け容れることができる。といったものであってもよい。ドメインオントロジー表現301には項目の二つのクラスがある。Posties300はHTTPGETおよびPOSTオペレーションの両方をサポートする親である。ハイライター330は単に、Postiesが現在選択されており、リターンキーを押すとPostiesビューに移行することを表している。矢印310はPosties300をPostie320にリンクする。これは、これらのクラスの間に関係があることを示している。クラスとしてのPostie320はHTTPオペレーションGETおよびDELETEをサポートする。Posties300およびPostie320についてのボックスは、ビュー間で移動するためにメニューバーと同様の仕方で使われてもよい。図7Bは、クラスPostieのクラスビューであるPostieビューを表している。ドメインオントロジー表現301はスケールダウンされているが、ドメインビューと同じ情報を含んでいる。同様に、メニューバー340はドメインビューと同じである。クラスヘッダ352およびクラスサブヘッダ353は、クラスの名前およびその当該ドメイン内での役割の非常に短い要約を示す。サブヘディングの内容はユーザーによって入力されてもよいし、あるいはドメイン記述またはオントロジー文書からコンピュータプログラムによって導出されてもよい。この場合、クラスヘッダ352はPostieとなっており、サブヘッダ353はPostiesの子孫となっている。明細セクション350aは、処理エンジンの出力を表示する。処理エンジンは、この実施形態では、前記コンピュータプログラムの一部である。これらの出力は、ユーザーにより、APIまたは他のソフトウェア製品として容易に実装できる。URIテンプレート領域354は、ユーザーのために、クラスヘッダ352によって示されるクラスの項目についてのURIテンプレートを提供する。この例では、URIテンプレート領域354はテキスト:URIテンプレートこれは単に提案PostiesPostieを含んでいてもよい。テキストPostiesは、Postiesビューへのクリック可能なリンクであってもよい。オペレーションプロトコル領域355は、ユーザーに、クラスヘッダ352によって示されるクラスの項目についてのHTTPオペレーションの要求の処理をどのようにコーディングするかを案内するテキストを与える。今の例では、クラスとしてのPostieはHTTPオペレーションGETおよびDELETEをサポートするので、オペレーションプロトコルは:OperationsGETdateTimestringDELETEと書かれていてもよい。すなわち、オペレーションGETについて、要求は、引数を必要とせずブランク要求、上に詳述したタグ付けされたテキストまではこの要求に応答してサーバーによって生成される応答のフォーマットを表す。応答は、GETオペレーションが実行される対象のpostieのストリングだけでなく、postieの生成時刻を表すdateTimeというデータオブジェクトをも含む。同様に、DELETEは引数を必要とせず、サーバーも応答を生成しない。よって、DELETEオペレーションに関しては何のテキストもない。属性Properties領域356は、各クライアントがどの属性をもつかおよびこれらの属性がどの単純なデータオブジェクトであるかについてユーザーに案内するためのテキストを与える。今の例では、テキストはPropertiesドットは読み出し専用を示すdatedateTimetextstringと書かれていてもよい。図7Cは、クラスPostiesのクラスビューであるPostiesビューを表している。ドメインオントロジー表現301はスケールダウンされているが、ドメインビューと同じ情報を含んでいる。同様に、メニューバー340はドメインビューと同じである。クラスヘッダ352およびクラスサブヘッダ353は、クラスの名前およびその当該ドメイン内での役割の非常に短い要約を示す。サブヘディングの内容はユーザーによって入力されてもよいし、あるいはドメイン記述またはオントロジー文書からコンピュータプログラムによって導出されてもよい。この場合、クラスヘッダ352はPostiesとなっており、サブヘッダ353はPostieの親となっている。明細セクション350bは、処理エンジンの出力を表示する。処理エンジンは、この実施形態では、前記コンピュータプログラムの一部である。これらの出力は、ユーザーにより、APIまたは他のソフトウェア製品として容易に実装できる。URIテンプレート領域354は、ユーザーのために、クラスヘッダ352によって示されるクラスの項目についてのURIテンプレートを提供する。この例では、URIテンプレート領域354はテキスト:URIテンプレートこれは単に提案Postiesを含んでいてもよい。オペレーションプロトコル領域355は、ユーザーに、クラスヘッダ352によって示されるクラスの項目についてのHTTPオペレーションの要求の処理をどのようにコーディングするかを案内するテキストを与える。今の例では、クラスとしてのPostiesはHTTPオペレーションGETおよびPOSTをサポートするので、オペレーションプロトコルは:OperationsGETPOSTこの集合内のPostie子リソースを生成stringここでもまた、GETオペレーションは引数を必要とせず、GETに続くテキストまでの間は、Posties親に対するGET要求を受領するサーバーによって生成される応答のフォーマットを表す。オペレーションPOSTのほうは引数stringをもち、POSTに続くまでの間のテキストは実は、POSTオペレーションを介して新しいpostieを生成する要求が取るべきフォーマットであるstringはpostieについてのストリング。任意的に、そのような要求に対する応答についてのフォーマットを表すテキストが表示されることができる。しかしながら、そのような応答のフォーマットが上に詳述したPostieクラスについてのものと同じであり、dateTimestringの形をもつ応答がPosties親における各postie項目について生成されることはユーザーによって知られているであろう。属性Properties領域356は、各クライアントがどの属性をもつかについてユーザーに案内するためのテキストを与える。ただし、この場合、親項目はPostie項目しか含まず、追加的なフィールドはもたない。よって、属性領域356はブランクである。クラスPostiesは親クラスなので、追加的なテキスト領域、子領域357が設けられる。子領域357は、クラスヘッダ352によって示されるクラスが親となるクラスの詳細を与える。この例では、テキストは、ProgenitorofpostiePostieと書かれていてもよい。ここで、テキストの第二の部分PostieはPostieビューへのリンクである。図8のAおよびBは、それぞれクラスPostieおよびPostiesに関係する明細セクション350aおよび350bの詳細なビューを与える。クラスヘッダ352およびクラスサブヘッダ353領域も各例において表示されている。オペレーショナルオントロジーのオペレーションは、HTTPオペレーションであってもよいが、これは任意的である。上記の側面のいずれにおいても、さまざまな特徴がハードウェアにおいて、あるいは一つまたは複数のプロセッサ上で走るソフトウェアモジュールとして実装されうる。ある側面の特徴は、他の側面のいずれに適用されてもよい。本発明はまた、本稿に記載された方法のいずれかを実行するためのコンピュータプログラムまたはコンピュータプログラムプロダクトならびに本稿に記載された方法のいずれかを実行するためのプログラムを記憶しているコンピュータ可読媒体をも与える。本発明を具現するコンピュータプログラムは、コンピュータ可読媒体上に記憶されてもよいし、あるいはたとえば、インターネットウェブサイトから提供されるダウンロード可能なデータ信号のような信号の形であることもできるし、他の任意の形であることもできる。特に、プロセッサを有するコンピューティングデバイスによって実行されたときに、該コンピューティングデバイスに本発明を具現する方法を実行させるコンピュータプログラムが提供されてもよい。付記以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。付記1ドメイン内の項目の諸クラスの構造、どの項目がどのクラスに属するかおよびどのオペレーションを各クラスがサポートするかを指示するオントロジー文書を生成する、コンピュータ実装される方法であって:ドメイン内の項目および項目間の関係についての情報を含むドメイン記述を入力する段階と;データ構造およびオペレーション構造にアクセスする段階であって、データ構造は前記ドメイン記述において記述される項目を諸クラスに分けて特徴づけるための項目および項目間関係のドメイン独立なモデルであり、データ構造は諸項目のクラスとして少なくとも親項目を含み、各親項目は該親項目がそれに対して呼び出されたオペレーション構造からのオペレーションを受け容れる結果として該親項目によって生成される子孫項目だけを含むことができ、オペレーション構造は、ドメイン記述に適用されたときに諸項目の諸クラスについての処理規則を定義するオペレーションの、ドメイン独立なリストを含む、段階と;前記データ構造および前記オペレーション構造を前記ドメイン記述に適用して、ソフトウェア製品を生成するのに使うオントロジー文書を生成する段階とを含む、方法。付記2前記ドメイン記述が処理エンジンに入力され、前記データ構造およびオペレーション構造が前記処理エンジンによりアクセスされ、前記データ構造およびオペレーション構造が前記処理エンジンにおいて前記ドメイン記述に適用され、前記オントロジー文書が前記処理エンジンによって生成される、付記1記載のコンピュータ実装される方法。付記3親項目の各インスタンスは、項目の特定のクラスのインスタンスである子孫項目だけを含むことができる、付記1または2記載のコンピュータ実装される方法。付記4前記オントロジー文書に基づいてURIテンプレートを処理エンジンにおいて生成し、該処理エンジンから出力する段階をさらに含み、前記URIテンプレートは、ランタイムにおけるドメイン内のリソースの各インスタンスがHTTPURIを介した参照により取得可能であることを保証するために使うことができ、リソースはフィールドおよび他のリソースへのリンクをもつ項目のクラスを総称する用語である、付記1ないし3のうちいずれか一項記載のコンピュータ実装される方法。付記5前記オントロジー文書は、管理可能な包含者のクラスを定義し、該管理可能な包含者クラスのインスタンスは状態親項目を含み、状態親項目が含むことのできる子孫項目は、管理可能な包含者のクラスのオペレーティング状態のあらかじめ定義されたリストのうちの一つを指示するために使われる項目の状態クラスのインスタンスである子孫項目のみである、付記1ないし4のうちいずれか一項記載のコンピュータ実装される方法。付記6前記データ構造およびオペレーション構造が制約されたエディタによってアクセスされ、前記制約されたエディタは、ユーザーを、前記データ構造およびオペレーション構造が前記ドメイン記述に適用されるような仕方で前記ドメイン記述を入力することに制約する編集環境である、付記1ないし5のうちいずれか一項記載のコンピュータ実装される方法。付記7前記オントロジー文書を使って生成されるインターフェース明細は、RESTアーキテクチャスタイルにおけるインターフェースの原理と整合する、付記1ないし6のうちいずれか一項記載のコンピュータ実装される方法。付記8ソフトウェア製品を生成するコンピュータ実装される方法であって、付記1ないし7のうちいずれか一項記載のオントロジー文書を生成する方法を含み、さらに:処理エンジンにおいて、前記データ構造および前記オペレーション構造に基づく規則のセットを前記オントロジー文書に適用してソフトウェア製品を生成する段階を含む、コンピュータ実装される方法。付記9前記データ構造および前記オペレーション構造が、生成されるソフトウェア製品がRESTアーキテクチャスタイルにおけるインターフェースの原理と整合することを保証する、付記8記載のコンピュータ実装される方法。付記10付記8または9記載のコンピュータ実装される方法であって、前記オントロジー文書は、管理可能な包含者のクラスを定義し、前記管理可能な包含者クラスのインスタンスは状態親項目を含み、前記状態親項目が含むことのできる子孫項目は、管理可能な包含者のクラスのオペレーティング状態のあらかじめ定義されたリストのうちの一つを指示するために使われる項目の状態クラスのインスタンスである子孫項目のみであり、それにより、ランタイムにおける前記管理可能な包含者クラスのインスタンスのオペレーティング状態は、前記管理可能な包含者クラスの前記インスタンスに含まれる前記状態親項目に前記状態クラスのインスタンスを追加することによって管理されるよう動作可能である、方法。付記11ランタイムにおける前記管理可能な包含者クラスの前記インスタンスの前記状態は、前記管理可能な包含者クラスの前記インスタンスに含まれる前記状態親項目に対する前記状態クラスの最も最近追加されたインスタンスによって指示され、それにより、前記状態親項目に含まれる子孫項目は、前記管理可能な包含者クラスの前記インスタンスの状態履歴である、付記10記載のコンピュータ実装される方法。付記12前記管理可能な包含者クラスのインスタンスは、仮想コンピューティングシステムである、付記10または11記載のコンピュータ実装される方法。付記13前記ソフトウェア製品が定義された受け容れ制約条件を含み、前記受け容れ制約条件は、ランタイムにおいて、親項目に対してオペレーションが呼び出された結果として該親項目のインスタンスによって生成されることのできる子孫項目の個別的なインスタンスを制約し、前記受け容れ制約条件はクライアントツールに対して利用可能である、付記8ないし12のうちいずれか一項記載のコンピュータ実装される方法。付記14ドメインはクラウドコンピューティング環境であり、前記ソフトウェア製品はサービスとしてのインフラストラクチャーAPIとして実装されることのできるインターフェース明細である、あるいは前記ソフトウェア製品はサービスとしてのインフラストラクチャーAPIである、付記8ないし13のうちいずれか一項記載のコンピュータ実装される方法付記15ドメイン内の項目の諸クラスの構造、どの項目がどのクラスに属するかおよびどのオペレーションを各クラスがサポートするかを指示するオントロジー文書を生成するよう構成されたコンピューティング装置であって:ドメイン内の項目および項目間の関係についての情報を含むドメイン記述を入力するための入力手段と;データ構造およびオペレーション構造にアクセスするアクセス手段であって、データ構造は前記ドメイン記述において記述される項目を諸クラスに分けて特徴づけるための項目および項目間関係のドメイン独立なモデルであり、データ構造は諸項目のクラスとして少なくとも親項目を含み、各親項目は該親項目がそれに対して呼び出されたオペレーション構造からのオペレーションを受け容れる結果として該親項目によって生成される子孫項目だけを含むことができ、オペレーション構造は、ドメイン記述に適用されたときに諸項目の諸クラスについての処理規則を定義するオペレーションの、ドメイン独立なリストを含む、手段と;前記データ構造および前記オペレーション構造を前記ドメイン記述に適用して、ソフトウェア製品を生成するのに使うオントロジー文書を生成する生成手段とを有する、装置。