ISO 15926とセマンティクス：セマンティックモデルの比較分析

企業情報システムでセマンティックモデルを使用するという考えは長い間存在していましたが、それらを使用するための持続可能なプラクティスはまだ形成されていません。 セマンティックモデルは、データ統合、分析、知識管理に使用できます。 しかし、それらの有用性の評価にどのようにアプローチするか、およびそのようなモデルをどのような方法で構築する必要があるかについて、一般に受け入れられている意見はまだありません。

この記事の目的は、実用的な例で、統合標準ISO 15926のルールに従って構築されたモデルの分析の可能性を比較することです。これは、モデルを表現し操作するためのOWLとSPARQLの使用と、この標準を使用せずに構築された「通常の」セマンティックモデルです。 この問題の解決策により、ISO 15926のようなセマンティックモデリングの高レベルパラダイムを適用することが推奨される解決策の範囲のタスクを選択できるようになります。

問題文

問題の歴史、およびISO 15926と「通常の」セマンティクスの関係の本質を簡潔に強調する必要があります。 ISO 15926は、業界（主に石油とガス）での使用を目的とした情報交換標準です。 歴史的に、標準の開発における重点は、さまざまな組織間でのデータの交換、つまり 異なる情報インフラストラクチャ間。 その主な機能は、オブジェクトの時間コンポーネント（4Dモデリング）、システムのライフサイクル（システムの現在の状態だけでなく）をシミュレートする機能を考慮した、オブジェクトとその関係の分類に対する特定のアプローチです。 この標準には、オントロジーコアが含まれており、共通の参照データライブラリを使用して、適用される情報モデルを作成することを意味します。 これらはすべて、その利点（システムのライフサイクルの高品質で関連するモデルを作成する能力、共通の「オントロジーディクショナリ」を使用して異なる組織間で情報を使用する優れた可能性）、および欠点（結果のモデルの複雑性の増加、標準とその使用法を習得するために必要な知識のレベル）。

標準の開発は1990年代に開始されました。 セマンティックWebテクノロジーの出現により、2000年代半ばに、ISO 15926に従ってデータを表現するための技術的基礎として承認されました。したがって、セマンティックWebの出現前に標準の基本概念が定められましたが、これらのテクノロジーの出現のみが、必要な技術的基礎を提供しました真に広く普及する可能性のある標準に従ってデータを表現する方法を作成する。 これらの技術のアイデンティティではなく、イデオロギー的な近接性が、私たちが解決したい「矛盾」の基礎を築きました。 ISO 15926に従ってモデリングが実行される原則は、オブジェクトを表す原則や、たとえばOWL言語でのオブジェクト間の関係に完全に対応していないため、これら2つの技術の組み合わせはやや総合的であることが判明しました。 ISO 15926に従って構築されたデータは、基本要素（RDFトリプレット）に分解できますが、SPARQLを使用してこの形式で提示されたモデルの情報オブジェクト間の関係の分析は困難です。

したがって、私たちが明らかにしようとしている矛盾の本質は次のとおりです。ISO15926に従って構築されたセマンティックモデルは、「通常の」セマンティックWebテクノロジーによってのみ、このような高レベルのマニュアルなしで構築されたセマンティックモデルと質的に異なると主張されています。 したがって、これらのモデルは根本的に異なる性質を持っています（少なくともイデオロギー）。 これら2つのタイプのセマンティックモデル間で競合が発生する可能性があり、「通常の」モデルに対しては1つの引数しか存在できないと主張されています。 他のすべての指標については、ISO 15926モデルがより正確で便利です。



以下では、ISO 15926と「通常の」セマンティックモデルの関係、類似点、および相違点を明確に示すために設計された実用的な例に基づいて、これらのステートメントを詳細に検討します。 それまでは、セマンティックデータモデルの作成と適用のイデオロギーに目を向けます（ISO 15926に準拠しないで構築された「通常の」セマンティクスモデルと呼びます）。

セマンティックモデルとその応用

セマンティックテクノロジーを作成する際の主なアイデアは、コンピューターアルゴリズムによるデータの意味（セマンティクス）の「理解」を確保する必要性でした。 したがって、これらのテクノロジーの最初のタスクは分析でした。関連する情報セットから知識を抽出する機会を提供します。

これらの技術の開発、さまざまな分野での応用の実験により、異なる構造のソースからのデータを結合（リンク）するのに非常に便利であることがわかりました。 これから、セマンティックネットワークのアイデアに基づいたツール開発の第2の方向、つまり情報システムの統合が生まれました。

セマンティクスの分析アプリケーションと統合アプリケーションの間に矛盾はありません。 それどころか、彼らは密接に結びついています。 結局、統合の目標は、原則として、結合されたセットからいくつかの新しい知識を抽出することです。そのような知識は、各ソースから個別に取得することはできませんでした。 ある情報システムから別の情報システムへの情報の転送を簡素化するタスクは、セマンティックテクノロジーの助けを借りて解決することもできますが、開発の追加ボーナスです。



アプリケーションの多くの分野で、セマンティック情報分析テクノロジーを使用して、大きなブレークスルーが達成されました。 特に説得力があるのは、これらの医学とバイオテクノロジーの進歩です。 たとえば、セマンティックテクノロジーでは、医薬品とその効果、臨床履歴、および遺伝情報に関する情報を組み合わせた基盤が構築されます。 こうしたデータベースの分析は、研究者が新薬を作成するのに役立ちます。 これは、リレーショナルデータベースが情報オブジェクト間の関係の多様性を適切に反映できず、これらの関係を分析するためのツールを提供できない状況の良い例です。 セマンティックデータベースは、ヘルスケア（病気の広がりを分析するため）やその他の多くのアプリケーションでも使用されます。

セマンティック技術を使用して情報を分析するツールも日常生活に含まれています。 たとえば、Facebook Graph Searchの開発者は、セマンティック検索（分析）の基本的な新規性を通常のレベルで示すことができる素晴らしい例を思い付きました。テキストでの検索の原則に基づいて構築された既存の検索エンジンのいずれも、「どのレストランが好きですか？」という質問に答えることができないことは明らかです友達に？」、または「親“はどの都市に住んでいますか？」 情報オブジェクト（人々、レストラン、都市）の形式化されたセットとそれらの間の関係（住んでいるなど）を使用したグラフ検索は、正しい答えを迅速かつ正確に与えることができます。 さらに、クエリの条件は、オントロジーが許可する制限内で変化させることができます（情報オブジェクトの種類とそれらの間の関係）。レストランについてではなく、映画について、親relativeについてではなくクラスメートについて同様の質問をすることができます。 Facebookのソーシャルネットワークのコンテンツ全体が、数十億のノードと接続を持つ巨大な単一の情報グラフであることは明らかです。 これらの関係を分析して使用する能力はすべてその価値であり、リソースの所有者にはよく理解されています。



上記に基づいて、セマンティックテクノロジの原理に基づいて構築された情報モデルに提示する必要がある基準を決定できます。 これらの基準の一部は、モデルの一般的な要件に基づいており、一部は、実用的な有用性の条件に関連する技術の仕様に基づいています。 それらをリストします。

1.実際のシステムとモデルで何らかのアクションを実行した結果は一致する必要があります（モデルと初期状態と最終状態のシステム間の類似性関係は、同じ規則で記述されます）。 この要件は、モデルの予測可能性を提供します。モデルが満たされる場合、システムの開発をシミュレートし、シミュレーション結果を実装できます。

2.モデルは、既存のテクノロジー（SPARQLなど）を使用してモデルから知識を抽出できるように、オブジェクトのプロパティとオブジェクト間の関係を反映する必要があります。 これは純粋に実用的な要件であり、分析に対するモデルの適合性を保証します。 実際、モデルで計算を実行する機能を宣言しています。

3.モデルは、そのオントロジーの核を修正することなく、拡張とスケーリング（拡大と詳細化）の可能性を提供する必要があります。 この要件により、オブジェクトを分類し、オブジェクトとそのプロパティを区別するためのメソッドの選択に制限が課されます。 この要件は非常に詳細に設定できます。

例：「通常の」セマンティックモデルの作成と分析

ここで、モデルを構築する2つの「競合する」方法を検討し、上記の基準に基づいてモデルの実用性を評価します。 業界の例、つまり議論中の規格の「ネイティブ」を取り上げます。



イベントに関するセマンティックモデル情報の形式で、パイプラインへのポンプのインストールについて説明しましょう。 モデルには次の情報が含まれている必要があります。

• ポンプの設置場所（プラント図の特定の識別子で示されます。以下、ISO 15926の用語に従って「機能場所」と呼びます）。
• 特定の時点で特定のシリアル番号が割り当てられた特定のタイプの物理オブジェクトとしてのポンプ自体。
• このポンプがこの場所に適しているという情報（インストールすることができます）;
• インストールの日付と時刻。

まず、ISO 15926に依存せずにこの情報構造をモデル化します（もちろん、さまざまな方法で作成できます。任意に選択します）。







イベントに対応するオブジェクトは黄色で、マテリアルオブジェクトは緑色で、リテラルはフレームなしで表示されます。 クラス定義は点線のボックスで囲まれ、原則として、特定のモデルではなく参照データを参照します。 矢印は、オブジェクト同士の関係、およびリテラル（プロパティ）を持つオブジェクト-グラフの端の関係を示します。

このオントロジーをSPARQLにインポートした結果、16個のトリプレット（グラフのエッジ）のセットが得られます。 これらは、図に示されている線に加えて、各オブジェクトのタイプに1つのトリプレットに対応しています。 もちろん、スキームは単純化されています。たとえば、「モデル」はリテラルではなく、対応するオブジェクトへの参照である必要があります。



このリンクを使用すると、このモデルのRDF表現と、SPARQLアクセスポイントへのインポート後に変換されるトリプレットのセットをダウンロードできます。



このモデルの分析を検討してください。 たとえば、シリアル番号がわかっているポンプが設置されている場所を知りたいとします。 これを行うには、次の単純なクエリのシーケンスが必要です。

SELECT * WHERE { ?pump <http://example.org/DC#Model> "Centrifugal Pump Model AB-123C"^^<http://www.w3.org/2001/XMLSchema#string> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクエリは、ポンプに関する情報を含むオブジェクトの識別子を返します。 これで、オブジェクト「pump installation」が見つかりました。

 SELECT * WHERE { ?installation <http://example.org/DC#InstalledItem> <http://example.org/DC#DE-1234F> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インストール場所を見つけることは残っています：

 SELECT * WHERE { <http://example.org/OurInstallation> <http://example.org/DC#InstalledPlace> ?place }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

グラフの3つのエッジを見ました。 もちろん、これらのクエリは1つにまとめることができます。

例：ISO 15926に従ってモデルを作成および分析する

ISO 15926規格に従って、イベント-ポンプのインストール-は、InstallationOfTemporalPartMaterializedPhysicalObjectInFunctionPlaceテンプレートで説明する必要があります。 簡略化された形式では、このテンプレートのロール構造は、上記の例に示されている情報とほぼ同等の情報を表すことができますが、次のように表すことができます。







この図では、パターンのインスタンスは黄色、オブジェクトのインスタンスは緑色です。

必要な最小限のデータ（注釈なし）で満たされたこのような構造は、SPARQLにインポートされると、アクセスポイントは36のトリプレットになります（ このリンクからOWLと結果のトリプレットセットをダウンロードできます）。 トリプレットでのこのデータの構造は非常に合理的であり、標準を使用しないモデルの構造とそれほど変わらないことに注意してください。 「通常の」セマンティックモデルと比較したトリプレットの数の増加は、新しい情報オブジェクトの追加、およびそれらの多くに含まれる基本型の定義へのリンクにより、2倍以上になります。 ただし、参照データをトリプレット、特にテンプレート定義に変換すると、グラフの構造を最適化するという点ではるかに悪い結果が得られます。 したがって、1つのInstallationOfTemporalPartMaterializedPhysicalObjectInFunctionPlaceテンプレートの定義は148トリプレットであり、その多くには空白ノード（独自の識別子を持たないグラフノード）が含まれます。 含めて、多くのトリプレットは2つの空白ノードを相互に接続します。 SPARQLを使用してこのような構造を操作することは非常に困難です。 実際には、これにより、テンプレートを作成または表示する機能を実装するソフトウェアの複雑さが大幅に増加します。 比較のために、同じデータの「通常の」セマンティックモデルは38のトリプレットのみに収まります。つまり、ISO 15926モデルよりも1桁コンパクトです（上記の148のトリプレットが1つのテンプレートのみを記述し、この例では4つあることを忘れないでください、必要な標準タイプの定義に加えて）。 もう1つの重要な違いは、ISOモデルには、現在のオントロジーが存在するアクセスポイントの外部にある外部要素へのリンクが含まれていることです。特に、RDL（参照データライブラリ、参照データディレクトリ。以下に戻ります）ディレクトリ）。



ISO 15926のルールに従って構築されたモデルを分析する可能性を検討してください。「通常の」セマンティックモデルについて上記で説明したのと同じタスクを実行します。 シリアル番号がわかっているポンプが設置されている場所を知りたいと思います。 ISOモデルでは、次の単純なクエリのシーケンスが必要です。

 SELECT * WHERE { ?temporalpart <http://standards.iso.org/iso/15926/tpl#valIdentifier> "S/N DE-1234F"^^<http://www.w3.org/2001/XMLSchema#string> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果は、ClassifiedIdentificationOfTemporalPartテンプレートのインスタンスの識別子です。 次に、このテンプレートがどの物理オブジェクト「ポンプ」に関連付けられているかを尋ねます。

 SELECT * WHERE { <http://example.com/tpl#CITP456> <http://standards.iso.org/iso/15926/tpl#hasTemporalWhole> ?pump }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポンプ（MaterializedPhysicalObject型のオブジェクト）の識別子を取得します。 これで、ポンプのインストールを説明するテンプレートのインスタンスのリストを取得できます。

 SELECT * WHERE { ?installation <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfInstallable> <http://example.com/tpl#MPO456> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

InstallationOfTemporalPartMaterializedPhysicalObjectInFunctionPlaceテンプレートインスタンスのインスタンスIDを取得しました。 ここで、インストールが行われた機能的な場所を確認します。

 SELECT * WHERE { <http://example.com/tpl#T123> <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfFunctionPlace> ?place }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、グラフの4つのエッジを通過する必要がありました。 これらの要求を作成するには、プログラマーがISO 15926の原則を十分に理解し、注釈付きのテンプレートライブラリ（実際にはパブリックドメインではない）を持っていることが非常に重要です。

モデルの分析可能性の比較

このグラフの分析のもう1つの興味深い側面は、時間に関連しています（時間的な側面を考慮することは、ISO 15926の長所の1つです）。 特定の時間に特定の機能場所にどのポンプが設置されたかを知りたい場合、SPARQL日付を操作するあまり便利ではない手段を使用してこれを行う必要があります。 必要なリクエストを作成します。

機能場所の識別子を知って、ポンプ設置エピソードを取得します。

 SELECT * WHERE { ?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfFunctionPlace> <http://example.com/tpl#FP123>. }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポンプの識別子を取得します-さまざまな例のために、同じクエリでこれを行います：

 SELECT * WHERE { ?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfFunctionPlace> <http://example.com/tpl#FP123>. ?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfInstallable> ?pump. }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポンプから、ほとんどの場合、RDLでのそのタイプへのリンクがあります-その助けを借りて、どのポンプであるかを見つけることができます。 ただし、モデルのこの部分は例の外に残しました。 リクエストにインストール日に関する条件を追加することは残ります。

 SELECT ?pump WHERE { ?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfFunctionPlace> <http://example.com/tpl#FP123>. ?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfInstallable> ?pump. ?inst <http://standards.iso.org/iso/15926/tpl#valStartTime> ?time. FILTER (?time < "2013-05-09T12:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>) } ORDER BY DESC (?time) LIMIT 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

FILTER条件を設置日で使用し、ORDER BYをソートし、出力結果の数を制限することにより、希望する結果が1つだけ得られます。指定した日付より前のポンプ設置のエピソードを選択できます。



「通常の」セマンティックモデルでは、このクエリの構造と要素の数はまったく同じです。

 SELECT ?pump WHERE { ?inst <http://example.org/DC#InstalledPlace> <http://example.org/DC#R4598459832>. ?inst <http://example.org/DC#InstalledItem> ?pump. ?inst <http://example.org/DC#Created> ?time. FILTER (?time < "2013-05-09T12:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>) } ORDER BY DESC (?time) LIMIT 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ISO 15926に従って構築されたモデルを使用するもう1つの興味深い側面は、RDLの使用（参照データライブラリ）に関連しています。 デバイスタイプ、機能などの定義を保存します。 これらのライブラリは、通常は業界団体が所有する外部SPARQLアクセスポイントで利用できます。 コラムにはRDLへのリンクが1つあります。これは、機能オブジェクトのタイプの定義であり、ポンプ機能を備えたデバイスである必要があることを示しています。 使用しているFunctionalPhysicalObjectのタイプに関する情報を要求した場合、

 SELECT * WHERE {<http://example.com/tpl#FP123> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?rdl }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、RDLへのリンクを取得します：< rdl.example.org/sampleReferenceData#R4598459832 >（同時に、機能オブジェクトはWholeLifeIndividualクラスに属し、他のいくつかのISO 15926ルートクラスは非常に有用な情報ではないことがわかります）。 この定義の意味を知りたい場合は、このRDLが保存されている別のアクセスポイントに照会する必要があります。

 SELECT * WHERE { <http://example.com/tpl#FP123> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?a. SERVICE <http://rdl.example.org/sparql> { ?a ?b ?c. }. }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのようなリクエストは、このタイプのデバイスのRDLにあるすべての情報を私たちに返します。 RDLとして、業界団体や規制機関が管理する参照ライブラリ（カタログ）、および特定の機器のサプライヤなどのプライベートカタログを使用できます。

「通常の」セマンティックモデルでは、フェデレーションクエリも使用できます。 機器などの共通カタログを作成し、オープンアクセスポイントに配置できます。 全体の質問は、その「権限」がそのような情報のリポジトリによってサポートされることだけです。 ディレクトリへの権限の付与は、さまざまな関連付けの機能です。 同時に、もしあなたがチートをしなければ、ガイドの1つまたは別の規格への対応または不適合は、その「権限」に実質的に何も追加しません。 たとえば、機器のサプライヤなど、特定の会社のカタログをRDLとして使用する場合、「権限」の存在の問題はまったく意味がありません。

「通常の」セマンティクスとISO 15926の類似点と相違点

セマンティックモデルの使用の考慮された例からの結論は非常に明白です。

1.技術的な観点から、「通常の」セマンティックモデルは、設計データ（特定のシステムとプロセスに関する情報を表現する）について言えば、ISO 15926モデルと非常に対称的です。 ISOモデルはより複雑であり、このギャップは、「通常の」モデルと比較して、線形法則に従ってモデルのボリュームに応じて拡大します。 これは、オブジェクトの一時的な部分を表現するための個別のエンティティの存在、および最上位タイプの分類子に従ってオブジェクトを分類する必要があるためです。

2.これらのモデルの計算可能性の観点から、それらの計算は「通常の」セマンティクスよりもやや複雑ですが、違いは急進的ではありません。 さらに重要なのは、クエリを作成するには、モデルに精通しているだけでなく、ISO 15926の概念に関する知識、およびテンプレートナビゲーターの存在も必要であるということです（これは、私たちの知る限り、公開されていません。望みにもほど遠い）。

3.参照データと高レベルエンティティISO 15926のシステムは、「通常の」セマンティクスと比較して非常に複雑です（モデルを表現するのに必要なトリプレットの数を10倍以上とすると）。 これは、テンプレートなどの高レベルのエンティティのライブラリに特に当てはまります。 定義を操作します（インスタンスではありません！）これらのエンティティのセマンティックテクノロジーによる手段は非常に複雑です。 ただし、ユーザーがテンプレートを操作し、その低レベルの表現を「非表示」にする機能をユーザーに提供するアプリケーションには、そのような作業（テンプレート定義の検索と表示、作成と編集、入力）に対する幅広い機能が必要です。 この問題の部分的な解決策は、RDFストレージではトリプレットとしてではなくOWLファイルとして表現されるテンプレートを使用することです。

4.ノウハウと見なされ、この標準の特別な価値を提供するISO 15926の概念—フェデレーションアクセスとRDLライブラリの使用、時間的部分の考慮—は、「通常の」セマンティクスでも利用できます。 それはすべて、データモデルの構築方法、および設計データと参照データへのデータ分離の実装方法に依存します。 ちなみに、ISO 15926に準拠して構築されたRDLライブラリを、それに対応しないデータモデルを使用するアプリケーションで使用する場合、実際的な障害はありません。

5.標準の真の価値は、まず、標準としてのステータスです。 一般に受け入れられている分類方法と分類器自体（およびその管理方法）は、異なる企業間の統合の標準を使用する可能性を提供しますが、モデルの計算タスクのパフォーマンスを多少複雑にします。 これは自然な状況です。あらゆる汎用性を高速で支払う必要があります。



したがって、ISO 15926標準は、セマンティックモデルを構築する方法の1つであり、高レベルの形式主義よりも少ない他の方法と比較して、特定の長所と短所があります。 実用的な実装と使用の可能性の観点から、標準と他の技術としてそれらを比較することを可能にする他の方法の間に根本的な違いはありません。 このような違いの存在を宣言することは、「実際の」現在のように「通常の」セマンティックテクノロジーに精通している専門家にとって困難な役割を果たさない場合、標準を広めるためのマーケティングデバイスと考えることができます。 さらに、技術レベルでのISO 15926と「通常の」セマンティクスの違いをIT専門家ではないが、特定のソフトウェアインフラストラクチャの作成について決定を下す人々に説明することは非常に困難です。



この標準を使用する場合と使用しない場合の両方で、システムの高品質モデルを作成できます。 その使用に関する決定は、まず、開発された情報システムのアプリケーションのコンテキストに基づいて、統合プロセスにモデルを含める可能性の観点から、およびモデルで計算を実行するための要件の観点から行われるべきです。 標準に従うことは一般的な推奨事項として述べることができますが、特定の状況下では、モデルでの高速計算の必要性により、より合理的なオントロジーの実装が必要になる場合があります。 原則として、ハードウェアのみでコンピューティングを最適化するという問題を解決することは非合理的です。

標準の普及に対する主な障害を考慮する必要があります。

• 高い「エントリのしきい値」-この技術の使用を成功させるために必要な知識の量。
• 本格的な方法論的基盤の欠如、文書化、開発された支援コミュニティ、使用例のコレクション。
• 標準に従って構築されたデータモデルを操作する機能を提供する、幅広いユーザーが利用できるソフトウェアの欠如。
• 標準の成功した使用の説得力のあるオープンな例の欠如（そのような会社がそのような目的のためにそれを使用するという単純な宣言の範囲を超えて）

これらの問題により、標準をベストプラクティスとして広めることによって戦わなければなりません。 「通常の」セマンティックテクノロジーに対する人為的な反対は、このプロセスでマイナスの役割しか果たすことができません。



psモデル例ISO 15926を明確にしてくれたVictor Agroskinに感謝します。