問題タブ [topbraid-composer]

TopBraid Free Edition を使用して、SPIN ルールで OWL オントロジーを作成しています。オントロジーと SPIN ルールを Sesame OpenRDF Workbench にロードしています。

簡単なテスト オントロジーを作成しました。これには、1 つの SPIN ルールと 1 つのデータ型プロパティを持つ 1 つのクラスがあります。

SPIN ルールはxsd:dateTime、テスト クラスのテスト インスタンスにタイムスタンプを追加します。これは、クラス、データ型プロパティ、およびルール (短い) を含むテスト オントロジー全体の RDF です。

そのため、Sesame の SPIN リポジトリをクリアし、ワークベンチの [Modify/Add] コマンドを使用します (バグを回避するために重要な [use base URI as context identifier] ボックスをオフにして)。次に、SPARQL Update クエリを使用して、クラスのテスト インスタンスを作成します。

次に、結果の bugsi:aTimeStampBug_test1 を個別に調べて、SPIN:rule が複数回実行され、複数のタイムスタンプが生成されたことを確認します。タイムスタンプの数は、テストごとに異なります。結果の一例を次に示します。

そのため、私の SPIN:rule は、クラスの 1 つのインスタンス化に対して数回実行されました。クラスのインスタンス化のために SPIN:rule を何回実行する必要がありますか? 一度だけ実行されると思っていましたが、間違っているようです。

この投稿の長さをお詫び申し上げます。この遅いルールの問題を再現できるようにしています。

TopBraid Composer FE を使用して、オントロジーと SPIN コンストラクターを含む RDF ファイルを作成しています。SPIN コンストラクターの目的は、オントロジーで定義されたクラスの個々のインスタンス化におけるコンプライアンスをチェックすることです。SPIN コンストラクターの実行が非常に遅いことがわかりました。その理由を知りたいです。

SPIN コンストラクタを含むオントロジー SXIComplianceCheck18.rdf

リポジトリ (RDFS+SPIN をサポートするメモリ内ストア) を変更/クリアし、このオントロジーを RDF4J ワークベンチにロードします。

次に、2 つの SPARQL Update クエリを順番に使用して、オントロジー (上記の RDF ファイル) で定義されたクラスの個々を作成し、実行中の SPIN コンストラクターを刺激します。

最初の SPARQL Update クエリ (個々のデータ項目をインスタンス化し、必要に応じて解析コンストラクターを呼び出します... すばやく実行されます):

2 番目の SPARQL Update クエリ (最初のクエリによってインスタンス化されたデータ項目を結合する提案をインスタンス化し、コンプライアンス チェック コンストラクターを実行します... 非常に遅く、私のコンピューターでは約 20 秒実行されます):

この 2 番目のクエリの実行には、約 20 秒と長い時間がかかります。これは、他のコンプライアンス チェックと一致しません (この RDF には含まれていません)。この 1 つのルールは、他の 13 の同様のルール (主に文字列の解析と比較) の中から分離しました。

（正しいが遅れた）結果：

問題の SPIN コンストラクター (sxxicc:Pub7Proposalクラス用):

このコンストラクターが最新の PC (AMD クアッド コア 2.3 GHz、16 GB の物理メモリで Windows 8 を実行し、追加のアプリケーションの読み込みがほとんどない) で実行速度が非常に遅いのはなぜですか? 他のコンストラクターは、同じマシン上ですばやく実行され、同じ事実を使用して、明らかに同様のことを行います。

この例を実行したときの Java VisualVM Sampler の出力は次のとおりです。

RDF4J org.eclipse.rdf4j.common.concurrent.locks.LockManager$1.release() および org.eclipse.rdf4j.common.concurrent.locks.LockManager.createLock() が Self Time を支配します。どうして？？この時間の消費を避けるためにルールを書き直すためにできることはありますか?

ノート：

1. ?this は自動的に設定されるため、SPIN コンストラクターでは WHERE 句の最初のトリプルは必要ありません。ただし、このコンストラクターをワークベンチの SPARQL クエリ (Explore/Query) にコピーしてデバッグを容易にするために、これを含めます。また、CONSTRUCT 句を "SELECT DISTINCT *" に置き換え、コンストラクターのデバッグ用に WHERE 句をそのままにしておくと便利です。
2. このコンストラクターの WHERE 句の唯一の目的は、CONSTRUCT 句の固定エラー メッセージのエラー条件が存在することを示すグラフ パターンの一致を提供することです。WHERE 句から CONSTRUCT 句に引き継がれるバインディングはありませんが、WHERE 句は引き続き CONSTRUCT 句のトリプルのアサーションを制御します。

アップデート

コンストラクターから 1 つの FILTER と関連するトリプルを削除して、コンストラクターを変更しました。

これにより、TBC FE で以下に示すコンストラクターが生成されます。

同じ 2 つの SPARQL 更新クエリで同じテストを実行すると、2 番目のクエリの実行時間は 20 秒以上から 2 秒未満に非常に非線形に短縮されます。繰り返しますが、これは正しくないようです。

TopBraid Composer Free Edition (5.1.3) を使用して、SPIN 制約を含むオントロジーを作成しています。次に、結果の RDF ファイルを RDF4J (2.0.1) にロードし、RDF4J Workbench を使用してテストします。

私はSPIN制約に取り組んでいます。CRO2:SignalRateクラスに追加した負でない信号レートを確認する例を次に示します。

そこで、次の SPARQL 更新クエリを使用して、RDF4J ワークベンチでこの制約をテストしています。

このテスト インスタントは、上記の制約に違反しています。spin:violationLevelトリプルを省略し、これをデフォルトで aspin:Errorにすると、クエリからエラー メッセージが表示され、テスト インスタンスが期待どおりにアサートされません。示されているように実行すると、制約違反は であるspin:Warningため、inst:aSignalRate_test個人はデータ値 -10.0 で作成されます。 私の質問は、制約のCONSTRUCT句のアサーションはどこに行くのですか? spin:violationLevel影響行動 の変更以来、それらは主張されていると思います。独自のプロパティを使用して空のノードに結び付けようとしましたsoo:hasConstraintViolationが、これは機能しません。CONSTRUCT トリプルは他のコンテキスト/グラフでアサートされていますか? すべてにデフォルト/グラフを使用しています。

RDF4J Workbench の Explore と SPARQL クエリの両方を使用して、予想されるトリプルを探しています。たとえば、次のクエリは、 I assert my errant の後、何も返しませんCRO2:SignalRate。

この動作は、TopBraid Composer FE と RDF4J Workbench でのアサート間で一貫しています。

私の目標は、できれば SPARQL クエリを使用してそのような診断を見つけることにより、SPIN 制約違反の場合にアサートされる診断メッセージを見つけて使用することです。合理的なようです。何かが足りない。

ありがとう。