AP226 Ship Mechanical Systemsは、英国LRのZabi Bazari氏を中心に開発が進められ2002年4月にCD投票に入ったが、この1〜2年位前からLRによる資源の供給がままならぬ状態になり、非常に苦戦していた。結果としてCDドキュメント、特にディクショナリの完成度は甚だ良くなく、またCDの時点ではDIS、ISと継続していけるだけのファイナンスの裏付けがない状態に陥った。

　一方、我が国は船舶のAPの中でも機関部が尤も現実のビジネス現場に近いという判断から、ここ数年力を入れて来た。初期よりマッピングの開発ワークショップヘの参加やプロトタイプの開発などに取り組み、ドキュメントの解読も尤も進んでいた。その様な背景からCD投票に当たっては、ディクショナリの部分が現実にそぐわないことを指摘し、この個所をformativeからinformativeにすべきと主張した。

　これに対してヨーロッパ勢は、（ファイナンスの枯渇を最大の原因として）これ以上現行のAP226の開発を継続する事は出来ないという判断やRDLを使いたいという半ば政治的な判断^注1から、AP226開発の中止とPLiBからRDLへの変更を持ち掛けてきた。そしてその解決策としてAP227 Plant spatial configurationの一部として組み込むことを主張し、結果的に米国がこれに応じたことで、方向性は決定的なものとなった。日本は規格開発に直接関与するだけの人・資金的な裏付けを持たない現実に基づいてこの方向転換に従わざるを得ない状況になった。

　

　RDLとは、Reference Data Libraryを意味していて、POSC/CAESARのプロジェクトで実証されたもので、現在は主としてISO 15926 Oil and Gasのプロトコルで、改良が加えられているものである。またISO10303-221のプラントのプロトコルでも利用されることになっている。歴史的にはAP221は独自にLibraryの開発を進めていたが、ハーモナイズの立場からも開発資源の立場からも強い要請を受けて、両者が統合していく方向が確認されている。なお、AP221側の立場では旧来STEP Libraryという表現が主流であったこともあり、今日でもSTEPlibと呼ばれる場合が多く、両者には若干仕様の差異があるようだが、本質的には同じであり何れは統合されるものと考えられる。PLiBが製品カタログの表現を前面に出しているのに対して、RDLではむしろ製品モデリングの概念が強いのが特徴である。つまりExpress言語によるエンティティ定義による表現に対して、オブジェクトとオブジェクトの関連を記述することによって、製品の表現を実現しようというものであり、その意味においてPLiBとは大きく異なるといってよい。逆にいうならPLiBは、比較的開発し易くまた利用者にも分かり易いのに対して、RDLは製品モデリングそのものに帰着する故に、開発にはそれなりの見識と知見が必須であり、このために利用者から見てそれほど理解し易いものではないといえよう。

　先に述べたように、RDLはOil and Gasを中心に欧州のプラント企業などが強く関わっていることもあり、欧州の企業や軍およびサプライヤもこれをサポートする（せざるを得ない）方向にあるのは事実のようである。ただ米海軍は今日でもPLiBを使う姿勢を崩している訳ではなく、AP227としては何れのライブラリでも参照できる仕組みが求められていることになる。

　下記は現在考えられている、AP227によるRDLを外部参照する基本の仕組みである。この様なメカニズムをAP227に付加することによって、AP227の本来のスキーマを使ってShip Mechanical Systemsを実現しようとしている。原則的にはこの仕組みに何ら問題点は無い様に思えるが、既存のAP227のスキーマは、必ずしもこの様な拡張には向いていないと判断される。それは何といっても主体が「配管」にある為である。

　5.2にRDLの基本概念を詳説しているが、この様な外部ライブラリを上手く使うには、本体側のスキーマが相当しっかり（それに合うようなもの）している必要があると考える。

　

　

　

　今日一般に行われているデータモデリングの手法は、”エンティティ型”（”オブジェクト型”といってもよい）とそれらに関係する”属性型”並びにエンティティ型相互の関係を駆使したものである。これらの関係は特別の属性型で表現されていて、”foreign key”と呼ばれている。オブジェクト指向によるモデリングでは、幾つかの付加的な概念が使われて、その一つに”メソッド”がありオブジェクトのビヘイビアーをイベントとサブタイプを用いて記述する、ここにサブタイプとは、オブジェクト型の間でスーパー／サブの関係を定義するものでその属性やビヘイビアーを下位のオブジェクト型（子オブジェクト）に上位の型（親オブジェクト）から継承を定義するものである。

　この手法のもう一つの基本的なものは、”インスタンス”である。インスタンスとはデータベースの利用者によって入力されるもので、属性型のインスタンスとして保存され、インスタンスというエンティティ型にグルーピングされるものである。

　これらの概念は、ITの専門家（データモデリング家）によって用いられ、”データモデル”として記憶されデータベースの構造を決定する。そのデータモデルは、実データを解釈するためのセマンティクスを定義し、利用者が属性のインスタンスを保存するのに供する。

　

　今日一般的になっているデータモデリングに共通した特徴は、データモデルの定義が2つに明確かつ強固に分けられていることで、一つはデータ構造でセマンティクスやユーザデータの意味を定義している、もう一つはユーザデータである。その結果として、この手法では、セマンティクスルールの定義には、一般のデータベースのアプリケーション利用者の立場ではアクセスできないし拡張もできず、通常は”ユーザインターフェイス”を用いることで隠蔽されている。この為に統合やお互いのシナジー効果が発揮できてない。このことは、人間の一般的なコミュニケーションと大きく異なっているといえる、というのも交換データが表現されているのと同じ言語で、解釈のルールを提供することが出来るからである。

　

　また今日の手法の別の制約として、一旦データベースの設定が終了すると、そのデータモデルが固定され、ユーザデータを解釈するセマンティクスが固定されてしまうことがある。このセマンティクスを拡張するには、データベースの構造を再定義して、古いデータを新しいものに移してやらなければならない。

　今の手法に対するもう一つの制約は、データモデルのスコープが制限されていても、あるいはデータモデルが大きくなったり、あるいは汎用的になっても、それを修正することが容易ではない。データモデルの汎用化はセマンテイックの確かさを失うことにつながる。

　最後に、データモデルは、それぞれ異なっていて、異なるシステム間のデータ交換は、特定のデータ構造毎に行われなければならないことである。これは今日のデータモデリング手法が、システマティックではなく、既存のものを再利用する為の標準化されたアプローチではないことを意味する。

　

　本報では、こういったユーザデータとITモデルデータの間で制約や障壁を持たない方法論を簡潔に紹介する。反面、それは沢山の拡張可能なセマンティクスを定義するもので、データベースそのものに保存され20,000エンティティとそれに関係する属性からなるデータモデルに等しい。

　セマンティクスの柔軟性は、次の事柄によって達成される；

　図5.2は一般的な手法と本報で述べるGellish手法との本質的な概念を比較している。

　

　アプリケーションにGellish Methodologyを適用すると、データモデルは柔軟性に富み拡張性も持つことができる、それはユーザのknowledgeを保存するもので、ユーザにはメタなモデルに見える。

　Libraryに定義されているSTEPlibとGellish言語は、このMethodologyを実装したものである、一方STEPlib Browserはアプリケーションソフトウエアで、knowledgeや個々のオブジェクトをビューイングするもので、このMethodologyの素晴らしさを体験できるものである。

　より詳しい情報については、次のものを参照されたい；

　何れも、www.steplib.comより入手可能である