CONSTRUCTを使用したSPIN制約：CONSTRUCTのトリプルはどこに行きますか？

Question

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

私はSPIN制約に取り組んでいます。ここで私はCRO2:SignalRateクラスに追加した非負の信号レートをチェックする例です：だから

CONSTRUCT { 
    ?this soo:hasConstraintViolation _:b0 . 
    _:b0 a spin:ConstraintViolation . 
    _:b0 rdfs:label "Non-Positive SignalRate" . 
    _:b0 spin:violationRoot ?this . 
    _:b0 spin:violationPath Nuvio:hasDataValue . 
    _:b0 spin:violationLevel spin:Warning . 
} 
WHERE { 
    ?this Nuvio:hasDataValue ?signalRate . 
    FILTER (?signalRate <= 0.0) . 
} 

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

PREFIX inst: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Sharing/Instantiations#> 
PREFIX Nuvio: <http://cogradio.org/ont/Nuvio.owl#> 
PREFIX CRO2: <http://cogradio.org/ont/CRO2.owl#> 

INSERT DATA { 
    inst:aSignalRate_test a CRO2:SignalRate ; 
    Nuvio:hasDataValue "-10"^^xsd:long . 
} 

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

RDF4J WorkbenchのExploreとSPARQLクエリの両方を使用して、予想されるトリプルを探しています。

PREFIX spin: <http://spinrdf.org/spin#> 

SELECT DISTINCT * 
WHERE { 
    ?s spin:violationRoot ?o . 
} 

この動作はTopBraid作曲FEとRDF4J Workbenchでアサートの間で一貫性がある：たとえば、次のクエリは、私は私の誤ったCRO2:SignalRateを主張した後、何も返しません。

私の目標は、SPIN制約違反の場合には、好ましくはSPARQLクエリを使用してそのような診断を見つけることによって、診断メッセージを見つけて使用することです。合理的だと思う。私は何かを欠いている。

ありがとうございました。

Answer 1

短い答え：できません。

SPIN制約は、違反を検出して報告するためのものです。 RDF4Jでは、その報告メカニズムがログです。

SPIN仕様（http://spinrdf.org/spin.html#spin-constraints）の要部：

[...] ASK制約する場合は、インスタンス条件に違反一 例えば真と評価します。オプションで、 CONSTRUCTクエリは、特定の違反に関する詳細を提供するspin：ConstraintViolation クラスのインスタンスを作成できます。

CONSTRUCTベースの制約によって生成されるデータを推論する必要はないことに注意してください。これはオプションの「追加情報」にすぎません。

これは、データベースを変更し、我々は戻って1つのフォームまたは別で、このようなトリプルを報告する推論に機能拡張を追加することができれば見て、おそらく価値があるのですが、現在のシステムでは、唯一の（DELETE/INSERTなどを使用して）ルールスピン。

Answer 2

したがって、上記の@JeenBroekstraのコメントと私の応答のコメントに続いて、エラー情報が目に見えるものとして残るようにconstuctorsを使用するように切り替えました。私はスピンの私の独自のサブプロパティのいくつかを作成しました：順序を維持するためにコンストラクタ。また、これらのコンストラクタの実行順序を指定して、これらのチェックが他のルールより先に実行されるようにしました（たとえば、負の信号レート）。このアプローチの

利点：

• エラー詳細アーチファクト（例えばスピン：violationRoot）はトリプルストアに表示されたまま。これはマシンツーマシンを含む私のアプリケーションでは非常に重要です。
• すべての適合性チェックが行われるので、複数の問題を持つ個人は、インスタンス化をブロックする最初の違反だけでなく、すべての問題を個別のhasConstraintViolationのプロパティとしてリストします。このアプローチの

短所：

• 誤った個人がまだインスタンス化されます。
• これは標準的な動作ではないため、ログに制約成果物を探すためのツールはおそらく見つからないでしょう。

ここではスピンのサブプロパティとして実装例のルールのスクリーンショットです：コンストラクタ：