I'm using TopBraid Composer Free Edition (5.1.3) to create ontologies including SPIN constraints. I then load the resulting RDF files into RDF4J (2.0.1) and use RDF4J Workbench for testing.
I'm working on SPIN constraints. Here's an example to check for non-negative signal rates that I've added to the CRO2:SignalRate
class:
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) .
}
So, I'm testing this constraint in RDF4J workbench using the following SPARQL update query:
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 .
}
This test instant violates the constraint shown above. If I omit the spin:violationLevel
triple and allow this to default to a spin:Error
, then I get an error message from the query and the test instance is not asserted, as expected. When executed as shown, the constraint violation is a spin:Warning
, so the inst:aSignalRate_test
individual is created with data value -10.0. My question is, where do the assertions in the constraint's CONSTRUCT
clause go? I believe they're being asserted since the change in the spin:violationLevel
impacts behavior. Note that I've tried to tie into the blank node with my own soo:hasConstraintViolation
property, but this doesn't work. Are the CONSTRUCT triples asserted in some other context/graph? I'm just using the default/graph for everything.
I'm looking for the expected triples both using RDF4J Workbench's Explore and using SPARQL queries. For example, the following query returns nothing after I assert my errant CRO2:SignalRate
:
PREFIX spin: <http://spinrdf.org/spin#>
SELECT DISTINCT *
WHERE {
?s spin:violationRoot ?o .
}
This behavior is consistent between asserting in TopBraid Composer FE and RDF4J Workbench.
My goal is to find and use the diagnostic messages asserted in case of SPIN constraint violations, preferably by using SPARQL queries to find such diagnostics. Seems reasonable. I'm missing something.
Thanks.
The short answer: you can't.
SPIN constraints are intended to detect violations and report them. In RDF4J, that reporting mechanism is the log.
The relevant part of the SPIN spec (http://spinrdf.org/spin.html#spin-constraints) :
[...] if an ASK constraint evaluates to true for one instance, then the instance violates the condition. Optionally, CONSTRUCT queries can create instances of a spin:ConstraintViolation class that provide details on a specific violation.
Note that there is no requirement on the reasoner to do anything with the data that a CONSTRUCT-based constraint produces - it's merely for optional "additional information".
It's perhaps worth seeing if we could add an enhancement to the reasoner to report such triples back in one form or another, but in the current system, only SPIN rules (using DELETE/INSERT etc) modify the database.