.NETおよびJavaのオントロジーを操作するためのフレームワークの比較分析

セマンティックWebに関連するプロジェクトの大部分がJavaで開発されていることは周知の事実です。 セマンティックオントロジーフレームワークも例外ではありません。すべての主要プロジェクト（Jena、OWL API、Sesameなど）は、特にJavaで記述されています。 .NETを使用する唯一の主要な代表者は、 RDF GatewayとSemantics.SDKを備えたIntellidimensionです。



この記事では、上記のフレームワークでの経験を説明し、テスト結果を共有します。

エントリー

この記事は、上記のフレームワークの包括的な概要ではありません。 この記事は、オントロジーのロード、論理的推論、SPARQLクエリの実行など、フレームワークの基本機能のパフォーマンスを分析することを目的としています。



技術的な詳細を説明する前に、Intellidimensionのフレームワークについて（Java指向のコミュニティで最も知られていない製品として）いくつかの言葉をお話しします。 この記事で説明するオープンソースプロジェクトである他のフレームワークとは異なり、RDF GatewayとSemantics.SDKはクローズドソースコードで配布され、かなりの費用がかかります。 したがって、RDF Gateway 3.0 Enterpriseだけで10,000ドルかかります（ただし、バージョン2.0のコストは「わずか」2,000ドルです）。 ちなみに、テストで使用された囚人PelletとOwlimも無料ではありません。Pelletはデュアルライセンスで配布され、Owlimはメモリ内で無料で動作するバージョンのみを提供しています。 ストレージバージョンは、使用するプロセッサコアごとに700ユーロかかります。

テスト中

私の仕事は、.NETのプロジェクトを実装するためのフレームワークを選択することでした。そのため、純粋な形式のJavaプロジェクトは私には興味がありませんでした（最初はテストするつもりもありませんでした）。 Javaと.NETの間の相互運用ツールを選択する必要がありました。 私の選択はikvm.netでした 。これにより、jarを.NET dllに変換できます。 .NETバージョンのJena、OWL API、およびSesameを受け取ったので、テストを開始しました。 ただし、ネイティブ環境でJavaフレームワークをテストした結果が含まれていない場合、テストは不完全になります。 したがって、テストには以下が関係します。IntellidimensionSemantics.SDK 1.0、OWL API 2.2.0 + Pellet 2.0rc5（Javaおよび.NETの両方）、Jena 2.5.7 + Pellet2.0rc5（Javaおよび.NET）および部分的にSesame 2.24 + SwiftOwlim 3.0b9。



OwlimのセマンティックSDKおよびPellet（OwlimはSesameとともに使用される主要な囚人）の論理的推論のポリシーのため、Sesameは初期テストから除外する必要がありました。 したがって、PelletとSemantic SDKは、クエリ中の出力（クエリ時の推論）を目的としていますが、早期出力の手段が含まれています。 Owlimは完全な実体化を目指しています。 これについては、「囚人に関する一般情報」のセクションで説明します。



NCI Instituteのシソーラス09.02dオントロジーがテストとして選択されました。 確かに、その純粋な形式には、多くの矛盾が含まれています。 サポートサービスと通信した後、矛盾が特定されました。 変更したバージョン09.02d（私のDropboxからダウンロードできます ）を使用しましたが、バージョン09.04dが使用可能になり、矛盾はありません。



テストのために、次の状況がシミュレートされました。

1.最初に、ファイルのオントロジーがモデルにロードされました。

2.次に、このモデルに対して3つのSparQLクエリが順次実行されました（クエリテキストはこちらからダウンロードできます ）。



最初に、第1段階のテスト結果を検討します。









.NET / ikvmフレームワークはJavaの同等のものよりも2〜3倍遅いという事実にもかかわらず、Intellidimensionよりも高速です。



メモリを操作するという点では、.NETはより快適な印象を残しました。 Javaガベージコレクターは、ヒープに割り当てることができるRAMの最大量を指定する必要があります（Xmxパラメーター）。 私の意見では、.NETはより論理的なポリシーを使用します。必要なだけメモリを消費します（制限が指定されていない限り）。 Xmxを介した制限は非常に古い「バグ」ですが、残念ながらまだ修正されていません。 解決策として、Xmxを単にマージンで指定することをお勧めします（もちろん、RAMの量が許す場合）。ただし、この場合（テストはXmx：12gで行われました）、ガベージコレクターは気にしません（テスト結果からわかります）。 別の方法でも構いません-特定の入力データの最小Xmx値を選択します（ただし、OutOfMemoryExceptionが発生するリスクがあります）。 したがって、JVMが消費するメモリ量を同様のCLRインジケータに近づけることができます（ただし、ガベージコレクションが頻繁に発生するとパフォーマンスがさらに低下します）。



使用されるメモリの最大量の制限に関して、かなり奇妙なケースが発生しました。 .NETに変換された.NET OWL APIを使用してシソーラスオントロジーを正常にロードした後、このオントロジーをProtége（同じバージョンのOWL APIに基づく）で開き、その構造に慣れることにしました。 ただし、概念とインスタンスのツリーの代わりに、OutOfMemoryExceptionが発生しました（十分な空きメモリがあるにもかかわらず）。 Xmx属性の値を増やすことで問題は解決しましたが、Javaのガベージコレクターのこのような非独立性は満足できません。 おもしろいことに、Javaアプリケーションはネイティブ環境で（JVMで踊ることなく）起動しないという事実にもかかわらず、ikvmを使用して.NETに変換した後、動作します。



次に、テストの2番目のポイントであるSPARQLクエリの実行に進みましょう。 残念ながら、この段階では、最初のテストのリーダーであるOWL APIを残す必要があります。 実際には、囚人が実装するOWL APIには、SPARQLクエリを実行するためのメソッドが含まれていません。 これは、SPARQLがRDFグラフのクエリ言語として作成された（そして、OWLにあまり馴染みがない）という事実によるものであり、OWL APIは、その名が示すように、OWL専用です。 現在、SPARQL-DL標準に関する作業が進行中であり、おそらく、そのサポートはOWL APIの次のバージョンの1つで実装される予定です。 現時点では、マンチェスター構文を使用してクエリを記述できるクラス式のみを使用します。 クラス式はもちろんSPARQLではありませんが、ほとんどのタスクでは十分です。



したがって、テスト結果：









最初に、Intellidimension列のダッシュについてコメントします。 テストアプリケーションの起動から6時間が経過し、プロセスの重量は約6 GBでしたが、結果はありませんでした。 私はもっ​​と長く待つ忍耐を持っていませんでした。 Semantics.SDKの技術的敗北を数えざるを得ません。 公平に言えば、Semantics.SDKが小さなオントロジーを管理することは注目に値します。しかし、結論を導き、要求を処理します...しかし、結果をJena + Pelletと比較すると、Semantics.SDKが常に完全な結果を与えるとは言えません。



しかし、Pelletは非常に合理的な時間で結論を処理しました（要求は簡単ではありませんでした）。テストの最初の段階と同様に、.NET / ikvmフレームワークはIntellidimensionよりも望ましいようです。



これでテスト段階が完了しました。 要約すると、勝者はJena + Pelletシステムであり、OWL API + Pelletはオーサーシップ賞を受賞したと言えます。

囚人に関する一般情報

一般に、論理推論の実装には2つのアプローチがあります：ルールに基づく（ 前方連鎖および/または後方連鎖アルゴリズムを使用する）およびセマンティックスコアボードに基づく（ セマンティックタブロー ）。 規則に基づいて、Semantics.SDKとOwlimが実装され、セマンティックスコアボードのPelletに基づいています。



私の知る限り、ルールベースの囚人は表現力の低い言語に有利であり、スコアボードベースの表現は表現力の高い言語に有利です。 ペレット（OWL-DL）とOwlim（OWL-Tiny）がこの観察を確認した場合（バリケードの反対側にある）、Semantics.SDK（OWL-FULL）は例外です（パフォーマンステストによると、この例外については何も良いことはありません） 。



Owlimの公式Webサイトの図cを考えてみましょう。







ご覧のとおり、OwlimはOWL Tinyのみをサポートしています。 この機能により、彼は非常に高いパフォーマンスを実現できます。



Owlimは、（レビューした）マルチスレッド出力をサポートする唯一の囚人です。 したがって、Owlimは、セマンティックスコアボードに対するルールベースのシステムの利点-並列化の可能性を実現しています（セマンティックスコアボードの構築プロセスを並列化するアルゴリズムはまだありません）。 Semantics.SDKの開発者は、出力も並列化されていると主張しています...しかし、これは試用版では実装されていません（私の意見では、これは試用版の良い制限ではありません）。 テストのための短期ライセンスを私に与えるという要求は答えられなかったので、開発者の言葉を受け取らなければなりません。



理想的な世界では、オントロジを分析するときに表現力のレベルを決定し、対応するアルゴリズムを使用してそれを導き出す、囚人が確実に存在する必要があります。 現時点では、そのようなリゾナーは存在せず、彼が登場することはまずありません。

おわりに

この記事では、パフォーマンスに重点を置いていますが、特定のプロジェクトのセマンティックフレームワークを選択するときは、まず機能（（非リレーショナル）ストレージのサポート、OWL2のサポートなど）に重点を置く必要があります。 これらの問題の議論は、この記事の範囲を超えています（そして、私はそのような分析を行うための各フレームワークにあまり精通していません）。 機能の面では、Intellidimensionの製品を賞賛したかったのです。RDFGatewayとSemantics.SDKバンドルは、Javaの世界には類を見ない非常に強力なフレームワークです...しかし、そのリゾナーのトリックはこのフレームワークに対する気持ちを冷やしました。



PSパベル・クリノフへの記事の執筆中に提供された教育プログラムに感謝します。

PP S. 私のブログのオリジナル記事 。