私は実際にセマンティック Web サービス、より具体的には WS 構成を扱っています。
Web サービスにセマンティクスを追加するために、2 つのパス (owl-s または wsdl-s を使用) を見つけましたが、各ソリューションの制限は何ですか?
私は実際にセマンティック Web サービス、より具体的には WS 構成を扱っています。
Web サービスにセマンティクスを追加するために、2 つのパス (owl-s または wsdl-s を使用) を見つけましたが、各ソリューションの制限は何ですか?
私の意見では、OWL-S と WSDL-S はどちらも同じように時代遅れです。両方のアプローチは、重いサービス記述が Web サービス アーキテクチャを構築するための最良の方法であると考えられていたときに考案されました。現在、一部の社内開発チームを除いて、Web サービス API は一般に、ペイロードとして JSON (通常) または XML (あまり使用されません) を使用する、かなり単純な HTTP ベースのアプローチに基づいています。サービスを定義するための基礎として REST を使用すると主張することがよくありますが、多くの場合、この用語が正しく使用されているかどうかは明らかではありません。概して、これらのサービスは、サービス記述言語の処理を伴う面倒な半自動化されたプロセスではなく、開発者が API ドキュメントを読み、コードを記述することによって呼び出されます。
上記で説明した形式の最新の Web サービスのメタデータを記述するために使用できる、広く使用されている手法を私は知りません。json-serviceなどのアプローチもありますが、どれくらい広く使われているのかわかりません。
真実は、第一級のオブジェクトとして豊富なサービス記述を持つことは、人々が期待したり、望んでいたほど有用であることが決して証明されなかったということだと思います。特に、サービス コレオグラフィやエージェント ベースの Web サービスで想定されている単純なコンポーネント サービスから複雑なサービスを柔軟かつ動的に構成することはできませんでした。呼び出し時にサービスが何をするかを記述することは、初期の研究調査が予想したよりもはるかに困難な問題であることが判明し、標準化の時期尚早な試みが実際に問題を改善するどころか悪化させた、ということもまた真実だと思います。
Web サービスの構成に興味がある場合は、開発者が実際に解決したいと考えている問題を解決するために試みた (そして失敗した) 努力の規模を理解するために、広範な研究文献を読むことを強くお勧めします。次に、対処しようとしているユーザーの問題を自問してください。テクノロジーを発明して、それが何に役立つかを考えようとするのではなく、そのアプローチが試みられています。
SWSはまだまだ先が長いです。WSDL 2.0: RDF マッピング W3C 仕様は、WSDL 2.0 - OWL マッピングを定義します。主な問題は、オントロジーでサービスを記述する方法ではなく、型システムをどうするかです。Linked Data は、XML スキーマのメッセージ記述とはかなり異なる DL モデル (OWL2) に基づいています。OWL 1/2 は部分的に XML データ型を採用していますが、OWL2/XML シリアライゼーションだけを使用することはできません。OWL/RDF メッセージを直接使用することはできますが (個人に対応するデータを渡す)、WSDL でこのパターンを定義する標準的な方法はありません。XML スキーマは、ここでのもう 1 つのブレーキです。複数の継承をサポートしていないため、OWL と XML の間のマッピングはそれほど簡単ではありません (公平を期すために、XML には継承の概念がまったくありません)。
私見の解決策は、新しい XML スキーマ言語を作成し、型システムを維持しながら、構造仕様を「Linked Data に適した」ものに変更することです。次に、たとえば「XML Schema 2.0」仕様に基づく新しい OWL シリアライゼーション形式を提供します。この形式では、すべてのデータ型と個人が直接表現されるため、構造的に XML で表現できます。明らかに、多くの質問がある可能性があります - XML Schema QNames で OWL IRI を表現するにはどうすればよいですか?
敬具、
D.